PageSpeed 100 из 100 в 2026: как и зачем

«У нас 38 баллов на мобиле» – самая частая фраза, с которой ко мне приходят клиенты после SEO-аудита. PageSpeed – не «модный показатель», а реальный фактор ранжирования с 2021 года. В этой статье – что такое Core Web Vitals, реалистичный план как разогнать сайт с 40 до 90+ за неделю, и почему гнаться за 100/100 не обязательно.

Зачем вообще ускорять сайт

Три прагматичных причины – без идеологии «потому что Google так сказал».

• SEO-фактор. Google учитывает Core Web Vitals как фактор ранжирования с 2021. На конкурентных запросах быстрый сайт обходит медленный, при прочих равных.
• Конверсия. Каждые +1 секунды загрузки уменьшают конверсию на 5-7%. На e-commerce – больше. Прямые потери денег.
• Стоимость рекламы. Google Ads даёт скидку на CPC для быстрых лендингов и наоборот штрафует медленные. Бюджет – реально влияет.

Core Web Vitals: LCP, INP, CLS

Это три метрики, которые Google измеряет у реальных пользователей через Chrome (CrUX-данные). С 2021 они – часть алгоритма ранжирования.

LCP (Largest Contentful Paint)

За сколько появляется самый большой элемент на первом экране – обычно главное изображение или большой заголовок. Хорошо: < 2.5s. Плохо: > 4s.

Главные виновники плохого LCP: тяжёлые hero-картинки без `fetchpriority="high"`, отсутствие `preload`, медленный сервер (TTFB), блокирующие скрипты в head.

INP (Interaction to Next Paint)

Заменил FID в 2024. Измеряет, насколько быстро страница реагирует на клик/тап/нажатие клавиши. Хорошо: < 200ms. Плохо: > 500ms.

Главные виновники плохого INP: тяжёлый JS на main thread, синхронные обработчики событий, длинные `setTimeout` цепочки. Это «современный» хедач: даже если страница быстро загрузилась, она может «залипать» на клик из-за плохого JS.

CLS (Cumulative Layout Shift)

Сумма «прыжков» вёрстки во время загрузки. Когда баннер сверху подгрузился – и весь текст сдвинулся вниз = плохой CLS. Хорошо: < 0.1. Плохо: > 0.25.

Главные виновники: изображения без указанной width/height, шрифты, которые меняют размер при подгрузке, рекламные блоки, динамически вставляемые элементы.

7 главных факторов скорости

Это базовый чек-лист. В 90% случаев именно эти пункты дают 70-90% прироста PageSpeed.

• Картинки в WebP/AVIF + lazy load. 80% «тяжести» страниц – это картинки. Конвертация PNG/JPG в WebP даёт -40-60% по размеру. AVIF ещё лучше, но поддержка немного хуже.
• Минификация и compression (Brotli). CSS/JS должны быть минифицированы. Сервер должен отдавать с Brotli (или хотя бы gzip). Cloudflare делает это автоматически.
• Удалить неиспользуемый CSS/JS. Любой `bootstrap.css` или `jquery.js`, если не используется хотя бы 30% – удалить. PurgeCSS + tree-shaking в bundler-е.
• Шрифты с font-display: swap. Без этого пользователь видит белый экран, пока шрифт грузится 1-2 секунды. С swap – сначала системный шрифт, потом подменяется.
• Preload главного hero-image + preconnect к CDN. `` уменьшает LCP на 0.5-1.5 секунды.
• CDN (Cloudflare). Если сайт хостится в России, а клиенты из EU – без CDN страница грузится 3-5 секунд только из-за географии. Cloudflare бесплатно решает эту проблему.
• HTTP/2 или HTTP/3. Современный протокол с мультиплексированием. Включается одной галочкой на хостинге или в Cloudflare. Без него браузер качает файлы последовательно вместо параллельного.

План оптимизации за неделю

Реалистичный график разгона сайта с 40-50 баллов Mobile до 90+:

1. Аудитдень 1
2. Картинкидень 2-3
3. CSS/JSдень 4
4. CDN/HTTPдень 5
5. Финишдень 6-7

День 1 – аудит. Прогон через PageSpeed Insights + Lighthouse в DevTools. Записываете текущие LCP/INP/CLS, TBT, размер страницы. Это базовая точка для замеров. Параллельно – WebPageTest для waterfall-анализа.

День 2-3 – картинки. Все JPG/PNG конвертируете в WebP (массово через `cwebp` CLI или Squoosh.app). Добавляете `width`/`height` атрибуты ко всем `` (борьба с CLS). Hero-картинку – с `fetchpriority="high"` и preload в ``. Остальные – `loading="lazy"`.

День 4 – CSS/JS. Минификация (если ещё не сделана). Удаление неиспользуемого CSS через PurgeCSS. Скрипты, которые не нужны в первом экране – с `defer`. Аналитика и счётчики – асинхронно или после `DOMContentLoaded`.

День 5 – CDN и HTTP/3. Подключаете Cloudflare (если ещё нет) – бесплатно, 5 минут. Включаете Brotli, HTTP/3, Auto Minify, Rocket Loader (осторожно – может ломать JS). Настраиваете cache rules для статики (1 год для assets с hash в названии).

День 6-7 – финиш. Повторный прогон PageSpeed. Точечные исправления оставшихся проблем: third-party скрипты в iframe, шрифты с font-display, удаление ненужных preconnect. Финальный замер. Если 90+ Mobile – цель достигнута.

7 типичных ошибок

Видел эти грабли регулярно – у клиентов с предыдущим подрядчиком или после самостоятельных попыток.

1. Оптимизировать Desktop, забыть про Mobile. Mobile-first indexing с 2019. Google ранжирует на основе мобильной версии. Desktop 95 + Mobile 45 = ранжируется как 45.
2. Тестировать только в Lighthouse, не смотреть field-data. Lighthouse – лабораторные данные. Search Console показывает реальные CWV у реальных пользователей. Они могут отличаться.
3. «Помогает плагин WP-Optimize, ставим». Плагины-оптимизаторы часто конфликтуют, делают непредсказуемое. Лучше один грамотно настроенный, чем три «помогающих» друг другу.
4. Lazy load hero-картинки. Самая большая ошибка. Lazy load для картинки выше fold = увеличение LCP. Lazy load – только для картинок ниже первого экрана.
5. Тяжёлые шрифты без preload и font-display. 800-шрифт с поддержкой 5 языков = 200KB. Без font-display: swap – белый экран 1-2 секунды. С preload – LCP сокращается.
6. Third-party скрипты в head. Yandex.Metrika + Google Analytics + Facebook Pixel + Hotjar + ... в head синхронно – TBT (Total Blocking Time) уезжает в красную зону. Перенос в footer или асинхронно.
7. Игнорировать Server-Side performance. TTFB (Time to First Byte) – часто проблема серверной стороны: медленный PHP, неоптимизированные SQL-запросы, отсутствие кэширования на сервере. Оптимизация только клиента не поможет, если сервер сам отдаёт за 2 секунды.

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