Как ускорить сайт до идеального PageSpeed в 2026
Содержание
PageSpeed — это быстрый способ понять, насколько сайт реально быстрый для пользователя. Если три метрики Core Web Vitals в зелёной зоне, страницы быстрее открываются, меньше людей уходит, а SEO и конверсия не проседают из-за тормозов.
Недавно ко мне пришел клиент с интернет-магазином на Битриксе. PageSpeed на мобильных - 23 балла. Двадцать три. Открываешь DevTools, смотришь waterfall - и сразу все понятно: картинки товаров по 3-4 МБ каждая, ни одна не в WebP. CSS-файл на 280 КБ грузится синхронно и блокирует рендер. jQuery, jQuery UI, три слайдера, два чат-виджета. LCP - 8.7 секунды. На мобильном это вечность.
Через два дня работы - 89 баллов. Без смены хостинга, без переписывания движка.
Никита Аландаренко, основатель Devorra: "За 2025 год мы оптимизировали 12 сайтов; средний прирост PageSpeed - 47 баллов. В 80% случаев хватило одного рабочего дня."
А теперь вопрос: сколько клиентов этот магазин терял каждый день, пока страницы грузились по 8 секунд? По данным Google, при росте загрузки с 1 до 3 секунд вероятность отказа увеличивается на 32%. При 5 секундах - на 90%. Для сайта, в который вложены деньги, это прямые потери.
Core Web Vitals - три метрики, которые решают все
И Google, и Яндекс (косвенно, через поведенческие) учитывают скорость при ранжировании - это один из главных трендов 2026 года. Google формализовал требования в три конкретных числа.
| Метрика | Что измеряет | Хорошо | Плохо |
|---|---|---|---|
| LCP | Загрузка основного контента | ≤ 2.5 сек | > 4.0 сек |
| INP | Отзывчивость на действия | ≤ 200 мс | > 500 мс |
| CLS | Визуальная стабильность | ≤ 0.1 | > 0.25 |
LCP чаще всего упирается в картинки и шрифты. CLS - в элементы без заданных размеров. А вот INP - самая коварная метрика.
INP заменил FID в марте 2024, и с тех пор у многих сайтов начались проблемы. FID мерил задержку только первого клика; INP отслеживает каждое взаимодействие за всю сессию и берет худшее. Внутри каждого взаимодействия три фазы: input delay (пока браузер дойдет до обработчика), processing time (сам обработчик), presentation delay (отрисовка результата). Если хоть одна фаза затянулась - INP красный.
Почему картинки - главный враг скорости?
По нашим аудитам, в 80% случаев, когда я вижу плохой PageSpeed, виноваты изображения. Не JS, не CSS. Картинки.
На том же битриксовском магазине менеджеры загружали фото товаров напрямую с камеры - 4000x3000 пикселей, JPEG без сжатия. На карточке товара отображается область 400x300, но браузер честно скачивает все 4 МБ. Умножьте на 20 товаров на странице каталога. Вот вам и LCP 8 секунд.
Что делать.
- Конвертировать в WebP или AVIF - экономия 30-50% размера без видимой потери качества
- Обязательно указывать
widthиheightдля каждого<img>; без этого CLS будет прыгать - Использовать srcset для адаптивных изображений - телефону не нужна картинка 2000 пикселей шириной
- Hero-картинку загружать через
<link rel="preload">, все остальное - черезloading="lazy"
Я обычно прогоняю картинки через Sharp на Node.js - он быстрее Squoosh при пакетной обработке и легко встраивается в CI/CD.
Critical CSS и борьба с render-blocking
Браузер не нарисует ни одного пикселя, пока не скачает и не распарсит все CSS-файлы, подключенные в head. Если ваш styles.css весит 200 КБ - все 200 КБ встанут между пользователем и контентом.
Решение - вынести CSS первого экрана прямо в <style> внутри <head>; остальное загружать асинхронно. Это дает 0.5-1.5 секунды выигрыша по LCP. Для лендинга, где CSS небольшой, имеет смысл инлайнить весь файл целиком - проще поддерживать, и разницы по скорости почти нет.
Кстати, шрифты - та же история. Если Inter (или любой другой шрифт) грузится без font-display: swap, текст будет невидимым до загрузки файла. А если еще и с Google Fonts CDN тащите - два дополнительных DNS-запроса плюс вопросы по 152-ФЗ. Self-hosted + preload + swap. Точка.
Быстрая проверка: чеклист
Прежде чем углубляться дальше - пробегитесь по этому списку; если хотя бы 3-4 пункта не закрыты, начинать нужно с них.
- Critical CSS встроен в
<head> - Шрифты -
font-display: swap+preload - Картинки в WebP/AVIF, с указанными размерами
loading="lazy"на всем ниже первого экрана- JS подключен с defer или async; минифицирован
- Gzip или Brotli на сервере
- HTTP/2 или HTTP/3
- Cache-Control для статики:
max-age=31536000, immutableдля шрифтов и картинок;no-cacheдля HTML - DOM-дерево до 1500 элементов
- Обработчики событий не длиннее 50 мс
Если все зеленое - отлично, читайте дальше про тонкости. Если нет - закройте сначала базу.
Как JavaScript тормозит сайт и что с этим делать?
Знаете, какой JS самый быстрый? Тот, которого нет.
Без шуток. На одном проекте мы убрали jQuery (использовался для одного toggle-меню), заменили анимационную библиотеку на CSS-transitions и выкинули неиспользуемый Moment.js. Минус 140 КБ gzip. PageSpeed подскочил на 15 баллов только за счет этого.
Если JS все-таки нужен - три правила. Подключать с defer (или async, если скрипт независимый); разбивать бандл через code splitting - грузить только то, что нужно на текущей странице. И tree shaking при сборке, чтобы неиспользуемый код не попадал в продакшн. Terser, esbuild, SWC - подробнее про наши инструменты в описании технологического стека.
Но главное - пересмотрите, нужна ли вообще та или иная библиотека. fetch вместо axios; IntersectionObserver вместо scroll-библиотек; CSS :has() вместо JS-логики для UI-состояний.
Что такое INP и почему он сложнее FID?
INP - боль многих SPA и тяжелых сайтов на React/Vue. Главное правило: ни одна задача в main thread не должна занимать больше 50 мс. Если обработчик клика запускает сложную логику - дробите через scheduler.yield(). Визуальные обновления - через requestAnimationFrame. Фоновые задачи - через requestIdleCallback.
И не забывайте про forced reflow. Если вы читаете offsetHeight, а потом меняете стили, а потом снова читаете - браузер пересчитывает layout на каждом чтении. Это убивает INP незаметно, но стабильно. Выносите чтение геометрии в начало, запись стилей - в конец. Или используйте CSS-анимации вместо JS - они работают в compositor thread и не блокируют main.
CDN и кеширование
CDN размещает копии статики на серверах ближе к пользователю. Для российской аудитории - Yandex Cloud CDN или Selectel. Для глобальной - Cloudflare (бесплатный план вполне рабочий). TTFB улучшается на 50-80%, и это без каких-либо изменений в коде.
Yandex Cloud CDN подходит для продакшен-проектов на российском рынке. Серверы в Москве, Питере, Владивостоке; интеграция с Object Storage для статики; HTTP/2 и Brotli из коробки. Настраивается за полчаса.
Кеширование - вторая часть. Шрифты и картинки - max-age=31536000, immutable (год, и браузер даже не будет проверять обновления). CSS и JS с хешами в имени файла - тоже год. HTML - no-cache, чтобы актуальная версия подтягивалась всегда. Service Worker поверх этого дает еще один слой; стратегия network-first для HTML, cache-first для статики.
А что Яндекс?
Яндекс не смотрит на Core Web Vitals напрямую. Но он смотрит на поведенческие, а поведенческие напрямую зависят от скорости.
Медленный сайт - больше отказов - ниже позиции. Тормозящие переходы - меньше глубина просмотра. Долгая загрузка на мобильном - пользователь не вернется. Все просто. Яндекс.Вебмастер и Яндекс.Метрика показывают скорость в отчете "Время загрузки страниц" - заглядывайте туда хотя бы раз в месяц.
Итого
Не нужно внедрять все сразу. Откройте PageSpeed Insights, посмотрите, что именно тормозит ваш сайт, и начните с самого жирного. В 80% случаев это картинки и render-blocking CSS. Закройте эти два пункта - и увидите разницу в тот же день.
А если PageSpeed уже 90+, но хочется выжать последние баллы - копайте в INP, preload-цепочки и размер DOM. Но это уже тонкая настройка, где каждый балл дается сложнее предыдущего.
Читайте также
Проведём бесплатный аудит скорости вашего сайта
Отправьте URL вашего сайта — мы проверим PageSpeed, Core Web Vitals и подготовим список рекомендаций