#перформанс #PageSpeed #Core Web Vitals #приоритеты #SEO

PageSpeed Insights — что красное надо чинить, а что можно проигнорить

PageSpeed Insights показывает 25-40 пунктов, большая часть красная даже у крупных сайтов. Половина из них реально влияет на UX, половина — академические нюансы. Разбираем, что чинить в первую очередь, что во вторую и что можно спокойно игнорировать.

17 июня 2026

Открыли pagespeed.web.dev, ввели свой сайт, получили оценку 38 на мобильном с 24 красными пунктами. Где взять время и силы починить всё это? И надо ли?

Хорошая новость — нет, не надо. Из 25-40 пунктов в типовом отчёте реально критичных 5-8. Остальные либо мелкие нюансы, либо случайно сработавшие правила. Разберём приоритеты.

Главная метрика — три цифры Core Web Vitals

В отчёте всё это вверху. Это единственное, что напрямую влияет на ранжирование Google и Яндекса в 2026:

LCP (Largest Contentful Paint) — <2.5 сек хорошо, 2.5-4.0 надо чинить, >4.0 плохо.
INP (Interaction to Next Paint) — <200 мс хорошо, 200-500 средне, >500 плохо.
CLS (Cumulative Layout Shift) — <0.1 хорошо, 0.1-0.25 средне, >0.25 плохо.

Дополнительно показываются:

FCP (First Contentful Paint) — когда появилось хоть что-то.
TBT (Total Blocking Time) — сколько главный поток был блокирован JS.
SI (Speed Index) — насколько быстро визуально заполняется страница.

Все три CWV в зелёной зоне — поиск вам ничего не штрафует. Остальное — улучшения «для души».

Что в отчёте — критично

В разделе Opportunities обычно сверху самое важное. Реально критичные пункты:

1. Eliminate render-blocking resources

CSS и JS, блокирующие первичный рендер. Каждый файл в <head> без async/defer задерживает FCP.

Фиксы:

defer или async на все скрипты в head.
Inline critical CSS, остальное — через preload + onload.
Удалить ненужные блокирующие стили.

2. Properly size images

Картинки больше нужного размера. Если на странице 800×600, не нужно 3200×2400.

Фиксы:

Размер при заливке.
<img srcset> или <picture> с несколькими размерами.

3. Serve images in next-gen formats

AVIF/WebP вместо JPG/PNG. Экономия 30-60% веса.

4. Preconnect to required origins / Preload key requests

Указать браузеру, к каким доменам идти заранее. Для критичных шрифтов и hero-картинок.

5. Reduce JavaScript execution time

Тяжёлый JS. Code splitting, удаление неиспользуемых библиотек.

6. Minify CSS / JavaScript

Очевидно. Любой современный сборщик это делает.

7. Avoid an excessive DOM size

Если в HTML 5000+ узлов — браузер медленно рендерит. Часто признак SPA с тяжёлыми списками без виртуализации.

Что можно проигнорить

1. Enable text compression

В 99% случаев Gzip/Brotli уже включены на уровне веб-сервера. Если красное — серверная настройка, 10 минут.

2. Use video formats for animated content

Замечание о замене GIF на MP4. Если у вас на лендинге нет анимированных GIF — игнор.

3. Avoid serving legacy JavaScript to modern browsers

Полифилы для IE11. Если ваш сайт не для государственных порталов — отключите legacy-сборку.

4. Reduce unused CSS / JavaScript

В отчёте часто показывается, что 60% JS «не используется». Внимательно: большая часть — это код, который используется на других страницах. Удалять только если у вас многостраничный сайт без code splitting и точно есть «мёртвый» код.

5. Cache static assets with an efficient cache policy

Важно, но фикс — добавить заголовки в конфиге веб-сервера. 5 минут работы, кладите в бэклог.

6. Avoid chaining critical requests

Показывает цепочки запросов. Полезно понимать, но напрямую фиксить часто невозможно.

7. Avoid large layout shifts (в Diagnostic)

Это часть CLS. Если CLS уже в зелёной зоне — игнор. Если красная — чините.

Что не надо чинить просто потому что красное

«Use efficient cache policy» для аналитических скриптов (Метрика, Roistat) — мы не контролируем их кэш-заголовки.
«Reduce initial server response time» с цифрой <800 мс — это уже хорошо для большинства сайтов.
«Avoid an excessive DOM size» при <3000 узлов — нормально.
«Image elements do not have explicit width and height» для декоративных SVG — обычно неважно.

Mobile vs Desktop

Отчёт показывает отдельно мобильный и десктопный результат. В 2026 году:

Мобильный важнее — Google ранжирует по mobile-first индексу.
Десктоп почти всегда зелёный у нормально настроенного сайта.
Mobile-проблемы реально влияют — на 4G с пинга 200 мс всё это видно пользователю.

Сначала чините мобильный.

Field Data vs Lab Data

В верхней части отчёта два блока:

Field Data — реальные данные с 28-дневного окна от пользователей Chrome (CrUX). Это то, что видит Google для ранжирования.
Lab Data — синтетический тест из дата-центра Google.

Если Field Data зелёная, а Lab Data красная — реальные пользователи довольны, не паникуйте. И наоборот: зелёный Lab при красном Field — на ваших реальных устройствах проблемы есть.

Приоритеты на 2-3 дня работы

Минификация и Gzip/Brotli (10 минут).
Картинки в AVIF/WebP (2-4 часа).
width/height на всех картинках (2 часа).
Шрифты локально с preload + font-display: swap (2 часа).
JS на defer/async (1 час).
Кэш-заголовки на статику (30 минут).
Inline critical CSS (4-8 часов).
Lazy load картинок ниже первого экрана (1 час).

За 2-3 дня средний сайт переходит из «38 на мобильном» в «75-90». Все три CWV становятся зелёными. Этого достаточно для SEO.

Когда нужны 100/100

Никогда. Сайт со скором 95 неотличим от 100 для пользователя, и неотличим для поисковика. Гонка за идеальной оценкой — потерянные дни ради 5-10 баллов, которые не влияют ни на конверсию, ни на ранжирование.

Вывод

Из 25-40 красных пунктов PageSpeed реально критичны 5-8. Главное — три CWV в зелёной зоне (LCP, INP, CLS). Сначала мобильный, потом десктоп. Сначала Field Data, потом Lab. На 2-3 дня работы можно поднять скор с 38 до 80+. Дальше — diminishing returns.

Узнайте подробнее о наших компетенциях

Разработка, ИИ, автоматизация — что мы делаем и как.