PageSpeed Insights показывает 30 баллов: что чинить в первую очередь

Балл в PageSpeed складывается из нескольких метрик, и вытягивают его три: LCP, CLS и INP. Поднять оценку с 30 до 60 обычно можно за день: сжать картинку первого экрана, убрать блокирующие скрипты, задать размеры изображениям, включить кэш и сжатие.

Кто-то прислал ссылку на PageSpeed Insights, и в графе Mobile горит красная цифра 30. Реакция типичная: либо паника и желание срочно всё переписать, либо вторая крайность — «у нас же сайт работает, плевать на эти ваши баллы». Истина посередине. PageSpeed это не самоцель, но 30 баллов на мобильном это объективно медленный сайт, который теряет посетителей и позиции в поиске. Разберём, как читать отчёт, какие три-пять правок дают мгновенный прирост, и в какой момент пора звать разработчика.

Что в отчёте PageSpeed важно, а что декорация

Открываем pagespeed.web.dev, вбиваем URL, ждём 20-30 секунд. На выходе одна страница с кучей блоков. По важности они разные.

Lab data и Field data: главное различие

Сверху две большие колонки: данные по реальным пользователям (Field data, или CrUX) и лабораторный замер (Lab data, или Lighthouse).

Field data это среднее по всем пользователям Chrome за последние 28 дней, чьи устройства передавали телеметрию. Это правда о вашем сайте. Если поле пустое и написано «недостаточно данных», значит, у вас меньше нескольких сотен пользователей в Chrome за месяц. Это нормально для маленьких сайтов, но Google по этой колонке вас и оценивает в поисковой выдаче.

Lab data это симуляция: Lighthouse на машине Google с эмуляцией среднего Android-устройства и 4G-соединения с дросселированием загружает вашу страницу один раз и измеряет. Этот замер удобен для дебага: его можно повторить и сравнить до и после правок. Но он не равен тому, что видят реальные пользователи.

Цифра 30 баллов сверху это именно Lab data. Field data может показывать совсем другую картину: если у вас аудитория с быстрых десктопов и хорошим интернетом, реальный Core Web Vitals может быть зелёным даже при сером Lighthouse-балле.

Цветные кружки

Ниже идёт блок Core Web Vitals: четыре метрики с цветным индикатором.

Метрика	Хорошо (зелёный)	Плохо (красный)
LCP	до 2.5 с	от 4.0 с
INP	до 200 мс	от 500 мс
CLS	до 0.1	от 0.25
FCP	до 1.8 с	от 3.0 с

Зелёный кружок не означает «всё идеально». Это означает «Google не считает вас откровенно медленным». Сайт с LCP 2.4 секунды формально зелёный, но субъективно ощутимо медленнее, чем сайт с LCP 1.0 секунды.

Diagnostics и Opportunities

Ниже Lighthouse даёт два блока: возможности (что можно улучшить, с оценкой потенциальной экономии в секундах) и диагностика (что сделано неправильно, без явной оценки эффекта).

Из этих двух блоков стоит читать в первую очередь Opportunities, отсортированные по убыванию. Если сверху «Eliminate render-blocking resources» обещает 1.8 секунды экономии, начинать надо с него, а не с «Avoid serving legacy JavaScript to modern browsers» с экономией 0.1 секунды.

Игнорируйте на старте: рекомендации про preconnect, preload, defer-атрибуты на конкретных тегах. Это микрооптимизации на 50-200 мс. До них доходят, когда крупные правки сделаны.

Какие три метрики двигают балл

Lighthouse считает балл по взвешенной формуле. Веса в актуальной версии:

• LCP — 25%,
• TBT (Total Blocking Time, прокси для INP в лабораторных условиях) — 30%,
• CLS — 25%,
• FCP — 10%,
• Speed Index — 10%.

То есть основной вес у LCP и TBT. CLS даёт 25%, но обычно или у вас правильно проставлены размеры картинок и баннеров (CLS зелёный) или нет (CLS красный) — средних значений мало.

LCP: где смотреть

Largest Contentful Paint это момент, когда отрисовался самый крупный видимый элемент на первом экране. Обычно это hero-картинка, баннер или большой заголовок.

Что найти: в отчёте PageSpeed раскройте блок «Largest Contentful Paint element». Lighthouse покажет конкретный HTML-тег. Дальше задача понятна: ускорить именно этот элемент.

Типовые случаи: — LCP это hero-картинка. Сделать её WebP, поставить fetchpriority="high", убрать loading="lazy". — LCP это заголовок H1. Странно, но бывает — если стиль текста огромный. Проверить шрифт: подключен ли через font-display: swap, не блокирует ли рендер. — LCP это видео. Заменить на постер-картинку с воспроизведением по клику.

INP: куда смотреть

Interaction to Next Paint измеряется только в Field data. В Lab отчёте вы видите TBT, который коррелирует, но не равен.

Высокий INP означает, что когда пользователь жмёт кнопку или ссылку, между нажатием и видимой реакцией проходит 200+ мс. Причина почти всегда одна: тяжёлый JS блокирует main thread.

В отчёте смотрим: — Total Blocking Time. Если больше 600 мс, это очень плохо. — Reduce JavaScript execution time. Скажет, какие скрипты дольше всего парсятся и исполняются. — Avoid long main-thread tasks. Покажет конкретные функции, которые задерживают рендер.

Главные виновники в моей практике: счётчик Метрики (особенно с настроенными целями), тяжёлый плагин типа Elementor Pro в WordPress, чат-виджеты Jivo и Carrot quest, реклама Google AdSense.

CLS: что чинить

Cumulative Layout Shift это сумма смещений элементов после первой отрисовки. Если страница «прыгает», когда грузится баннер или подгружается шрифт, CLS будет красный.

Главные источники: — Картинки и видео без явных width и height в HTML. — Шрифты без font-display: optional или с разной метрикой — текст переверстывается, когда подгружается реальный шрифт. — Динамически вставляемые блоки (виджеты, реклама, баннеры с куки-согласием) без зарезервированного места.

Лечится в большинстве случаев за час: проставить размеры всем картинкам, добавить min-height контейнерам с динамическим контентом, использовать font-display: optional или swap с правильным fallback-шрифтом.

Топ-5 правок, которые поднимают балл с 30 до 60 за день

Это работает почти на любом сайте. Делается за один день, не требует разработчика, не ломает дизайн.

1. Конвертация картинок в WebP

Самая частая причина медленного LCP и большого общего веса страницы. На главной обычной корпоративной страницы 5-15 МБ изображений. После конвертации в WebP с качеством 80 — 1-2 МБ.

Для WordPress: плагин ShortPixel, Imagify или EWWW. Прогнать Bulk optimization, подождать. Бесплатные тарифы дают 100-300 картинок, дальше 5-15 долларов разово.

Для Битрикса: модуль «WebP конвертер» из маркетплейса или вручную через cwebp в консоли с правкой .htaccess.

Для Tilda: WebP сейчас включается в настройках сайта галочкой. Раньше надо было через CDN-обёртку.

Для статических сайтов и кастомных CMS: пакетная конвертация через cwebp или sharp (Node.js) и подмена в шаблонах.

После конвертации обязательно проверить, что: — Браузеры, поддерживающие WebP, получают WebP. — Браузеры без поддержки получают JPG fallback. — Размеры не сменились в попиксельном плане (CLS не вырос).

Эффект: +10-20 баллов в Lighthouse за этот пункт.

2. Lazy loading картинок ниже первого экрана

Браузеры умеют лениво грузить картинки нативно. Для всех картинок, которые НЕ на первом экране, добавляем loading="lazy":

<img src="/images/photo.webp" loading="lazy" width="800" height="600" alt="...">

Для картинок на первом экране НЕ ставить lazy, наоборот — ставить fetchpriority="high" для LCP-картинки:

<img src="/images/hero.webp" fetchpriority="high" width="1200" height="600" alt="...">

WordPress с версии 5.5 ставит loading="lazy" автоматически на все картинки кроме первой. Битрикс не ставит, надо добавить через шаблон или плагин. На статических сайтах добавить руками или через build-pipeline.

Эффект: +5-15 баллов.

3. Удаление неиспользуемого JavaScript

Зайдите в DevTools → Coverage (Cmd+Shift+P, «Show Coverage»). Перезагрузите страницу. Coverage покажет, какие JS-файлы выполнены и сколько процентов их кода реально использовано на текущей странице.

Если видите файл размером 200 КБ, в котором использовано 8% кода, это кандидат на удаление или замену.

Конкретные действия: — Снести виджеты, которыми не пользуются (старая поделочная карточка с поделиться, выключенные комментарии Disqus, неактивный чат). — Заменить тяжёлые слайдер-плагины на CSS-only решения или статичную картинку. — Убрать счётчики, которые задвоились (бывает: код Метрики стоит и в шапке, и в плагине Site Kit). — Заменить jQuery-плагины на vanilla JS, если jQuery вообще можно убрать.

Эффект: +5-15 баллов, плюс заметное улучшение TBT и INP.

4. Page cache

Если сайт на WordPress, Битрикс, OpenCart, MODX и каждый запрос проходит через PHP с обращением к базе, TTFB будет 500-2000 мс. Это убивает FCP и LCP.

Решение: page cache в виде статических HTML-файлов, которые отдаются без запуска CMS.

• WordPress: WP Rocket (платный), LiteSpeed Cache (бесплатный, если хостинг на LiteSpeed), W3 Total Cache, WP Super Cache.
• Битрикс: встроенный composite cache. Включить и настроить, добавить mod_rewrite-правило для статической отдачи.
• OpenCart: модуль OCcache или Pretty cache.
• Tilda: уже работает по умолчанию, не лезть.

После настройки замерить TTFB. Должно упасть с 1500 до 100-300 мс. Это +10-20 баллов в Lighthouse и заметное ускорение для пользователей.

5. Шрифты

Если сайт грузит Google Fonts с CDN, в России это тёмная история: часть пользователей видит белый экран на 1-3 секунды.

Решение: скачать шрифты, положить локально, подключить через @font-face с font-display: swap:

@font-face {
    font-family: "Inter";
    src: url("/fonts/inter-regular.woff2") format("woff2");
    font-weight: 400;
    font-style: normal;
    font-display: swap;
}

font-display: swap означает: показать текст fallback-шрифтом сразу, заменить на кастомный, когда загрузится. Это исключает белый экран и улучшает FCP.

Для WordPress есть плагин OMGF (Optimize My Google Fonts), который автоматически качает Google Fonts и подменяет ссылки на локальные. Для остальных CMS делается руками.

Эффект: +3-10 баллов плюс субъективно более быстрый сайт.

Что вытащит ещё 20-30 баллов и стоит дороже

После пятёрки выше балл обычно стабилизируется в 60-80. Чтобы залезть в зелёную зону 90+, нужны более глубокие правки. Они требуют разработчика или хотя бы понимания фронтенда.

Inline критического CSS

Браузер не отрисует страницу, пока не загрузит весь подключенный CSS. Если CSS файл 200 КБ, а нужен для первого экрана только 15 КБ, тратится 1-2 секунды.

Решение: сгенерировать критический CSS для первого экрана и встроить его прямо в <head> через тег <style>. Остальной CSS подгружается асинхронно через media="print" хак или rel="preload".

Инструменты: critical (npm-пакет), Penthouse, Sitelocity Critical CSS. Для WordPress есть плагин Autoptimize с этой функцией, для Битрикса — модули с маркетплейса или ручная сборка.

Эффект: +5-15 баллов, особенно к FCP и LCP.

Разделение JS-бандла

Современные сборщики (Webpack, Vite, Rollup) умеют разделять JS на чанки и грузить только то, что нужно для текущей страницы. Если у вас один общий bundle.js на 800 КБ, который используется на 30%, это плохо.

Делается это переписыванием сборки, а не настройкой плагина. На WordPress с темами типа Twenty Twenty Four уже сделано из коробки. На кастомных темах и старых проектах нет.

Эффект: +5-10 баллов, плюс улучшение INP.

Server-side rendering для SPA

Если ваш сайт это React или Vue без SSR, первый запрос отдаёт пустой HTML и тяжёлый JS-бандл. LCP уходит в красную зону неизбежно.

Решение: переезд на Next.js (для React), Nuxt (для Vue), Astro (если контент в основном статический). Это существенный рефакторинг, сроки от 40 часов и выше.

Эффект: +20-40 баллов, плюс резкое улучшение LCP, FCP, TTI.

Бюджет производительности

Когда сайт уже зелёный, начинают следить, чтобы не съехал. Бюджет это документ или конфиг, в котором написано: HTML до 50 КБ, JS до 200 КБ, картинок не больше 1 МБ на странице, шрифтов не больше двух семейств. Сборка падает, если правка превышает бюджет.

В Lighthouse есть опция --budget-path, можно подключить в CI и не пускать в продакшн коммиты, которые ломают скорость. Это уже инженерная зрелость, нужна на больших проектах.

Когда зелёные баллы уже не помогают

Если у сайта объективные проблемы с UX (запутанная навигация, нелогичные формы, долгая регистрация), 90+ в PageSpeed их не починит. Бывало так: добивался 95 баллов на главной интернет-магазина, а конверсия не двигалась, потому что чекаут требовал шесть шагов и регистрацию.

Точно так же: сайт с LCP 1.8 секунды и сайт с LCP 1.0 секунды визуально различаются для пользователя на 800 мс. Это заметно. Сайт с LCP 1.0 и LCP 0.6 для пользователя на смартфоне с не очень быстрым интернетом неотличимы.

Поэтому правило: дотягиваем до зелёного по Core Web Vitals (LCP до 2.5, INP до 200, CLS до 0.1). Дальше смотрим на бизнес-метрики — конверсию, отказы, глубину просмотра. Если они в порядке, не тратим больше времени на гонку за 95 баллами.

План действий на эту неделю

Если сегодня PageSpeed показывает 30 баллов, реальный таймлайн до 70-80:

1. День 1, 1 час. Замерить текущий PageSpeed мобильной и десктопной версий. Сохранить скриншоты. Зайти в Search Console → Core Web Vitals и посмотреть, что там по реальным пользователям.
2. День 1-2, 2-4 часа. Конвертация картинок в WebP, проставление lazy loading.
3. День 2-3, 2-3 часа. Настройка page cache, перенос Google Fonts локально, удаление неиспользуемых плагинов и виджетов.
4. День 3, 1 час. Повторный замер. Должно быть 60-75 в Mobile и 80-90 в Desktop.
5. День 7-14, 4-8 часов. Inline критического CSS, тонкая настройка кэша, удаление неиспользуемого JS. Балл стабилизируется на 80-90.

Если такой работой заниматься некогда или хочется, чтобы кто-то взял ответственность за результат, напишите через форму на /#contact. Делаю аудит за 1-2 часа, по итогам говорю реальный план с оценкой эффекта в баллах. Стоимость разовой оптимизации скорости и абонентки, в которую профилактика производительности входит постоянно, есть на странице тарифов. Другие материалы про скорость и Core Web Vitals лежат в рубрике блога.

Частые вопросы

Что делать, если PageSpeed показывает 30 баллов

Начать с картинок первого экрана и блокирующих скриптов. Эти две правки дают самый большой сдвиг. Дальше кэш, сжатие и размеры у изображений.

Насколько важен сам балл

Он удобен для отчёта, но чинить надо не балл, а метрики. Сайт с зелёным баллом и плохим LCP у реальных посетителей проигрывает сайту с жёлтым баллом и быстрым первым экраном.

Почему у лаборатории и у людей разные цифры

Лабораторный замер идёт на эмуляции одного устройства и одной сети. Данные поля собираются с реальных посетителей за 28 дней. Расхождение это норма, а не ошибка инструмента.

Когда зелёные баллы уже не помогают

Когда проблема не в скорости, а в содержании и структуре. Быстрый сайт, который не отвечает на вопрос посетителя, конверсию не поднимет.