Google PageSpeed Insights 2026: улучшаем оценку сайта

Google PageSpeed Insights в 2026 году — это уже не просто «зелёная цифра для галочки», а реальный сигнал ранжирования, который напрямую влияет на позиции в поиске и конверсию. Я занимаюсь оптимизацией сайтов уже больше десяти лет, и за это время инструмент поменялся радикально — расскажу, что актуально прямо сейчас и как выжать из PSI максимум.

Что изменилось в PageSpeed Insights к 2026 году

Если вы последний раз открывали PSI года три назад — забудьте то, что видели. Google серьёзно переработал методологию. Теперь инструмент опирается на две группы данных одновременно: лабораторные (Lighthouse в headless Chrome) и полевые (Chrome User Experience Report, он же CrUX). И вот тут начинается самое интересное: у вас может быть 95 баллов в лабе, а полевые данные показывают «нужно улучшить». Именно полевые данные Google использует для ранжирования — это официально подтверждено.

Ключевые метрики Core Web Vitals в 2026 году — это LCP (Largest Contentful Paint), INP (Interaction to Next Paint, который заменил FID ещё в 2024-м) и CLS (Cumulative Layout Shift). К ним добавились вспомогательные: FCP (First Contentful Paint), TTFB (Time to First Byte) и TBT (Total Blocking Time). Последний особенно важен в лабораторных условиях — он коррелирует с INP. Подробнее про сами метрики я писал в статье Core Web Vitals: как улучшить показатели — там разобрал каждую цифру детально.

Ещё одно важное изменение: PSI теперь разделяет оценки для мобильных и десктопных устройств гораздо строже. Мобильный порог стал жёстче — Google симулирует медленное 4G соединение (8.75 Мбит/с) и мидрейндж устройство. На десктопе условия мягче. По моей практике, большинство клиентских сайтов имеют разрыв в 20-35 баллов между мобильной и десктопной оценкой. И работать надо именно с мобильной версией.

TTFB: начинаем с сервера, а не с фронтенда

Честно говоря, 80% владельцев сайтов начинают оптимизацию не с того конца. Они ставят плагины кеширования, сжимают картинки — и получают прирост в 5-7 баллов. А потом удивляются, почему LCP всё равно 4 секунды. Ответ почти всегда в TTFB. Если сервер отдаёт первый байт дольше 800 мс — всё остальное бесполезно.

У меня был клиент с интернет-магазином на Битриксе — 40 000 товаров, MySQL 5.7, PHP 7.4, виртуальный хостинг за 300 рублей в месяц. TTFB был 2.1 секунды. Мы переехали на VPS с PHP 8.2, MySQL 8.0, настроили Redis для сессий и кеша Битрикса — TTFB упал до 180 мс. PageSpeed с 34 баллов прыгнул до 71 только за счёт этого. Без единого изменения в коде фронтенда.

Вот базовая конфигурация Nginx, которую я использую на большинстве проектов — она серьёзно влияет на TTFB:

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

    # Буферизация для снижения TTFB
    fastcgi_buffering on;
    fastcgi_buffer_size 16k;
    fastcgi_buffers 16 16k;
    fastcgi_busy_buffers_size 32k;

    # Keepalive соединения
    keepalive_timeout 65;
    keepalive_requests 100;

    # Gzip сжатие
    gzip on;
    gzip_vary on;
    gzip_min_length 1024;
    gzip_comp_level 6;
    gzip_types
        text/plain
        text/css
        text/javascript
        application/javascript
        application/json
        application/xml
        image/svg+xml
        font/woff2;

    # Кеш статики
    location ~* \.(css|js|woff2|png|jpg|webp|avif|svg|ico)$ {
        expires 1y;
        add_header Cache-Control "public, immutable";
        access_log off;
    }

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_read_timeout 300;
    }
}

Про HTTP/2 и HTTP/3 отдельно — это тоже влияет на TTFB и параллельную загрузку ресурсов. Если у вас до сих пор HTTP/1.1 — это очень плохая идея в 2026 году. Детальную настройку протоколов разобрал в статье Настройка HTTP/2 и HTTP/3 для ускорения сайта.

LCP: главная метрика, которую все делают неправильно

LCP (Largest Contentful Paint) — время до отрисовки самого большого элемента в viewport. Цель: меньше 2.5 секунды. По данным CrUX, большинство российских сайтов на WordPress и Битриксе имеют LCP в районе 4-6 секунд на мобильных. Это провал.

Первое, что нужно сделать — определить, что именно является LCP-элементом. В 90% случаев это либо hero-изображение, либо крупный текстовый заголовок. Откройте DevTools → Performance → запустите запись → найдите LCP-маркер. Если это картинка — у вас три задачи: правильный формат, правильный размер и preload.

Формат — однозначно WebP или AVIF. AVIF даёт сжатие на 30-50% лучше JPEG при том же качестве. На PHP 8.1+ с GD или ImageMagick конвертация делается легко. Но главное — атрибут fetchpriority="high" на LCP-изображении. Это подсказка браузеру, что картинку надо грузить в первую очередь. И никакого loading="lazy" на LCP-элементе — это одна из самых частых ошибок, которую я вижу.

<!-- Правильная разметка LCP-изображения -->
<img
  src="/images/hero.webp"
  srcset="/images/hero-480.webp 480w,
          /images/hero-768.webp 768w,
          /images/hero-1200.webp 1200w"
  sizes="(max-width: 480px) 480px,
         (max-width: 768px) 768px,
         1200px"
  width="1200"
  height="600"
  fetchpriority="high"
  alt="Описание изображения"
  decoding="async"
>

<!-- Preload в <head> для ещё более быстрой загрузки -->
<link
  rel="preload"
  as="image"
  href="/images/hero.webp"
  imagesrcset="/images/hero-480.webp 480w,
               /images/hero-768.webp 768w,
               /images/hero-1200.webp 1200w"
  imagesizes="(max-width: 480px) 480px, 1200px"
  fetchpriority="high"
>

Если LCP-элемент — фоновое CSS-изображение, это проблема. Браузер узнаёт о нём только после парсинга CSS, что добавляет задержку. По возможности переделывайте на <img> тег. Если нельзя — используйте preload с as="image".

Ещё один момент, который часто игнорируют — шрифты. Если LCP-элемент — текст, а шрифт грузится с Google Fonts или другого CDN, браузер может показывать FOIT (Flash of Invisible Text). Решение: хостите шрифты локально + font-display: swap + preload для критических шрифтов.

CLS: боремся со сдвигами макета

CLS (Cumulative Layout Shift) — суммарный показатель нестабильности макета. Норма: меньше 0.1. На деле у большинства сайтов с рекламой, динамическим контентом и iframe это 0.3-0.5. Пользователь кликает на кнопку — а там уже реклама загрузилась и всё съехало. Раздражает неимоверно.

Главные источники CLS, которые я встречаю постоянно. Первое — изображения без указанных размеров. Браузер не знает, сколько места зарезервировать, пока картинка не загрузится. Решение банальное: всегда указывайте width и height атрибуты. Второе — рекламные блоки (особенно Google AdSense). Они загружаются асинхронно и толкают контент вниз. Решение: резервируйте место через min-height на контейнере. Третье — динамически инжектируемые баннеры и уведомления сверху страницы. Cookie-баннер, который появляется и двигает весь контент вниз — классика жанра.

Отдельная история с веб-шрифтами. Если у вас font-display: auto или вообще нет этого свойства — при замене системного шрифта на загруженный может происходить сдвиг из-за разницы в метриках. font-display: swap помогает с FOIT, но может давать CLS. Лучшее решение в 2026 году — использовать size-adjust и ascent-override для максимального совпадения метрик fallback-шрифта с загружаемым.

INP: новая метрика, к которой многие ещё не готовы

INP (Interaction to Next Paint) заменил FID в марте 2024 года, но по моим наблюдениям большинство разработчиков до сих пор не понимают разницы. FID мерил только задержку до первой реакции на ввод. INP измеряет время от любого взаимодействия (клик, тап, нажатие клавиши) до момента, когда браузер перерисовал страницу. Норма: меньше 200 мс.

Главный враг INP — длинные задачи JavaScript в основном потоке. Если у вас есть задача, которая выполняется дольше 50 мс (Long Task), она блокирует обработку пользовательского ввода. В PSI это отражается в метрике TBT (Total Blocking Time). Вот типичные источники: тяжёлые jQuery-плагины, сторонние скрипты (чаты, аналитика, виджеты), неоптимизированные обработчики событий.

Решение — разбивать длинные задачи через scheduler.yield() или старый добрый setTimeout(fn, 0). Для сторонних скриптов — загружать их через async/defer или вообще откладывать до первого взаимодействия пользователя. Я обычно делаю так: Google Tag Manager грузится только после первого scroll или mousemove. PageSpeed это любит.

У одного клиента на Laravel + Vue.js был INP 680 мс — катастрофа. Разобрались: при клике на кнопку фильтрации товаров запускался синхронный пересчёт 800 элементов в DOM. Переписали на виртуальный скроллинг + дебаунс на фильтры — INP упал до 140 мс. Это прямо сказалось на конверсии: она выросла на 12% за месяц.

Оптимизация CSS и JavaScript: что реально работает

Render-blocking ресурсы — бич большинства сайтов на WordPress и Битриксе. CSS в <head> блокирует рендеринг, JS в <head> без async/defer блокирует и парсинг, и рендеринг. Грубо говоря, браузер не нарисует ни пикселя, пока не загрузит и не выполнит все блокирующие ресурсы.

Для CSS — выделяйте критический CSS (Above The Fold) и инлайните его в <style> прямо в HTML. Остальной CSS грузите асинхронно. Инструменты для автоматического извлечения critical CSS: Critical (npm-пакет), PurgeCSS для удаления неиспользуемых стилей. На WordPress это делает плагин Autoptimize или WP Rocket. На Битриксе — придётся настраивать вручную или через поддержку Битрикс.

Для JavaScript — всё что не нужно при первой загрузке, грузите с defer или type="module". Используйте code splitting: в webpack/Vite это делается через динамические импорты. Результат — браузер загружает только тот код, который нужен для текущей страницы.

<?php
// Пример правильного подключения скриптов в WordPress
function mytheme_enqueue_scripts() {
    // Критические стили - инлайн
    $critical_css = file_get_contents(get_template_directory() . '/css/critical.css');
    echo '<style>' . $critical_css . '</style>';

    // Основные стили - асинхронно
    wp_enqueue_style(
        'main-style',
        get_template_directory_uri() . '/css/main.css',
        [],
        filemtime(get_template_directory() . '/css/main.css') // версия = время изменения файла
    );

    // JS - defer по умолчанию через filter
    wp_enqueue_script(
        'main-script',
        get_template_directory_uri() . '/js/main.js',
        [],
        filemtime(get_template_directory() . '/js/main.js'),
        true // в footer
    );

    // GTM - только после взаимодействия
    wp_add_inline_script('main-script', '
        function loadGTM() {
            if (window.gtmLoaded) return;
            window.gtmLoaded = true;
            // GTM snippet здесь
        }
        document.addEventListener("scroll", loadGTM, {once: true, passive: true});
        document.addEventListener("mousemove", loadGTM, {once: true});
        document.addEventListener("touchstart", loadGTM, {once: true, passive: true});
    ');
}
add_action('wp_enqueue_scripts', 'mytheme_enqueue_scripts');

// Добавляем defer ко всем скриптам
add_filter('script_loader_tag', function($tag, $handle, $src) {
    // Исключаем скрипты, которым нужен sync
    $exclude = ['jquery-core'];
    if (in_array($handle, $exclude)) return $tag;

    return str_replace(' src=', ' defer src=', $tag);
}, 10, 3);
?>

Отдельно про неиспользуемый JavaScript — это один из топовых пунктов в рекомендациях PSI. Bootstrap целиком при использовании 10% компонентов, jQuery UI, огромные библиотеки иконок. Решение: либо tree shaking при сборке, либо замена на более лёгкие альтернативы. Alpine.js вместо Vue для простых интерактивных элементов, Vanilla JS вместо jQuery для базовых операций.

Изображения и шрифты: низко висящий фрукт

Изображения — самый очевидный, но при этом самый часто запускаемый на самотёк аспект. По моей практике, на среднестатистическом сайте изображения составляют 60-75% от общего объёма страницы. И при этом половина из них загружается в формате PNG или JPEG без какой-либо оптимизации.

В 2026 году стандарт — AVIF с fallback на WebP, и WebP с fallback на JPEG. Тег <picture> позволяет это реализовать нативно. AVIF не поддерживается в старых браузерах (IE, старый Safari), но это уже не наша аудитория. Подробную настройку конвертации и автоматической оптимизации я описывал в статье Настройка WebP и оптимизация изображений на сайте.

Lazy loading — всем изображениям, кроме LCP-элемента, ставим loading="lazy". Это нативная функция браузера, работает без JavaScript. Но есть нюанс: на длинных страницах браузер всё равно загружает изображения в пределах ~1200px от viewport. Для очень длинных страниц с десятками изображений — рассмотрите Intersection Observer для более агрессивного lazy loading.

Шрифты — отдельная история. Google Fonts — это удобно, но это дополнительный DNS lookup, TCP соединение и HTTP запрос. На мобильных это может добавить 200-400 мс к FCP. Я всегда хостирую шрифты локально. Скачиваете через google-webfonts-helper, кладёте на свой сервер, прописываете @font-face с font-display: swap. И не забудьте preconnect убрать — он больше не нужен, если шрифты локальные.

Кеширование и CDN: ускоряем повторные визиты

Кеширование — это то, что делает разницу между «сайт грузится 3 секунды» и «сайт грузится 0.8 секунды» для вернувшегося пользователя. Стратегия кеширования в 2026 году строится на нескольких уровнях.

Уровень первый — браузерный кеш. Статические ресурсы (CSS, JS, изображения, шрифты) должны кешироваться минимум на год. Для этого в Nginx прописываем expires 1y и Cache-Control: public, immutable. Чтобы при обновлении файла кеш сбрасывался — используйте версионирование в имени файла или query string. В webpack/Vite это делается автоматически через content hash в имени файла.

Уровень второй — серверный кеш страниц. Для WordPress — WP Rocket или W3 Total Cache с Redis. Для Битрикса — встроенное кеширование с хранилищем в Redis или Memcached. Для Laravel — Route::cache() и кеш конфигов. Подробно про Redis и Memcached для разных CMS разобрано в статье Настройка кеширования Redis и Memcached для сайта.

Уровень третий — CDN. Если ваша аудитория в России — используйте российские CDN (Selectel, EdgeЦентр, G-Core Labs). Если международная — Cloudflare, BunnyCDN, KeyCDN. CDN решает проблему географической задержки: пользователь из Владивостока получает статику с ближайшего узла, а не с сервера в Москве. Это может сократить TTFB на статику с 300 мс до 30 мс.

На деле, правильно настроенный CDN плюс серверный кеш даёт 40-60 баллов прироста на PageSpeed даже без изменений в коде. Был у меня корпоративный сайт на Битриксе — 28 баллов мобильных. После переезда на CDN + Redis кеш + Brotli сжатие — 74 балла. Без единой строчки переписанного кода.

Практический план улучшения: с чего начать прямо сейчас

Давать советы «оптимизируйте всё» — бесполезно. По опыту, вот последовательность действий, которая даёт максимальный результат за минимальное время.

Шаг первый — запустите PSI для мобильной версии и сохраните отчёт. Обратите внимание на раздел «Diagnostics» — там конкретные проблемы с конкретными файлами. Шаг второй — проверьте TTFB. Если он больше 600 мс — начните с сервера: хостинг, PHP версия (минимум 8.2 в 2026 году), кеширование на уровне приложения. Шаг третий — найдите LCP-элемент и убедитесь, что он загружается с высоким приоритетом, в правильном формате, с preload.

Шаг четвёртый — проверьте render-blocking ресурсы. Все CSS критические — инлайн, остальные — асинхронно. Все JS — defer/async, в footer. Шаг пятый — оптимизируйте изображения: WebP/AVIF, правильные размеры, lazy loading (кроме LCP). Шаг шестой — настройте кеширование браузера для статики. Шаг седьмой — проверьте CLS, исправьте элементы без размеров.

Если хотите сделать это системно и не тратить недели на разбирательства — можно заказать доработку сайта с фокусом на производительность. Я обычно провожу полный аудит, расставляю приоритеты по соотношению «трудозатраты/прирост» и делаю всё по очереди. Типичный результат для WordPress-сайта: с 35-45 баллов до 75-85 за 2-3 недели работы.

И последнее: PageSpeed — это не разовая акция. Каждое новое обновление темы, каждый новый плагин, каждая встроенная аналитика может ронять баллы. Настройте мониторинг производительности — есть бесплатные инструменты вроде SpeedVitals или DebugBear, которые проверяют PSI по расписанию и шлют алерты при деградации. Это сэкономит много нервов.