Lighthouse 2026: аудит и улучшение скорости сайта

Lighthouse в 2026 году — это уже не просто инструмент проверки скорости, а полноценный стандарт качества, на который смотрят и SEO-специалисты, и разработчики, и даже клиенты на приёмке проекта. Я прогоняю через него каждый сайт перед релизом, и каждый раз нахожу что-то новое — особенно после того, как Google обновил весовые коэффициенты метрик в конце 2025-го.

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

Начну с главного — версия Lighthouse 12.x, которая сейчас актуальна, серьёзно поменяла подход к взвешиванию метрик. Если раньше FCP (First Contentful Paint) тянул на себя 10% итогового балла, то сейчас акцент сместился в сторону INP (Interaction to Next Paint). Эта метрика пришла на смену FID ещё в марте 2024-го, и к 2026-му её вес в общем скоре вырос до 30%. Грубо говоря, сайт может быстро загружаться, но если кнопки "тупят" — балл будет низким.

Ещё одно изменение — более жёсткие пороговые значения для LCP (Largest Contentful Paint). Теперь "зелёная зона" — это до 1.8 секунды вместо прежних 2.5 секунд. Я недавно аудировал интернет-магазин на Битриксе, у которого LCP был 2.1 секунды — раньше это был бы "зелёный" результат, сейчас это уже "жёлтый". Клиент был в шоке, когда увидел, что его "хороший" сайт внезапно стал "требующим улучшений".

Также появились новые аудиты: проверка Speculation Rules API (предзагрузка страниц), аудит Long Animation Frames (LoAF) вместо устаревших Long Tasks, и расширенная диагностика работы с изображениями — теперь Lighthouse отдельно ругается за отсутствие fetchpriority="high" у LCP-изображения. Если вы не слышали об этом атрибуте — самое время разобраться.

Как правильно запускать аудит — и почему большинство делает это неверно

Честно говоря, я вижу одну и ту же ошибку постоянно: люди запускают Lighthouse прямо из DevTools в Chrome на своей рабочей машине и удивляются результатам. Это плохая идея по нескольким причинам. Во-первых, ваш браузер наверняка забит расширениями, которые мешают тесту. Во-вторых, ваш ноутбук мощнее среднестатистического смартфона в 4-5 раз, а Lighthouse в режиме Mobile применяет CPU throttling 4x.

Правильный подход — запускать из инкогнито-режима с отключёнными расширениями, или через CLI. Вот как я делаю это в своём рабочем процессе:

# Установка Lighthouse CLI
npm install -g lighthouse

# Запуск аудита с правильными настройками
lighthouse https://example.com \
  --output=html \
  --output-path=./report.html \
  --preset=desktop \
  --throttling-method=simulate \
  --chrome-flags="--headless --no-sandbox"

# Для мобильного аудита (по умолчанию)
lighthouse https://example.com \
  --output=json,html \
  --output-path=./report \
  --only-categories=performance,accessibility,best-practices,seo

Ещё лучше — использовать PageSpeed Insights API или web.dev/measure, потому что там тест гоняется с серверов Google, что даёт более объективный результат независимо от вашего интернет-соединения. Но для регулярного мониторинга я настраиваю автоматический запуск через CI/CD — это отдельная история, о которой я писал в статье про автоматическое тестирование сайта.

LCP: как найти виновника и что с ним делать

LCP — это моя любимая метрика для охоты. В 90% случаев LCP-элемент — это либо hero-изображение, либо большой текстовый блок. Первое, что я делаю после аудита — смотрю, какой именно элемент Lighthouse определил как LCP. Это видно прямо в отчёте в разделе "Diagnostics".

Если виновник — изображение, проблема обычно в одном из трёх: изображение не оптимизировано (нет WebP/AVIF), у него нет fetchpriority="high", или оно загружается через lazy loading. Последнее — классическая ошибка. У одного клиента на WordPress был шаблон, который ставил loading="lazy" на все изображения подряд, включая hero-баннер. LCP был 4.2 секунды. После того, как убрали lazy с первого изображения и добавили fetchpriority="high", LCP упал до 1.6 секунды. Без каких-либо других изменений.

Вот правильная разметка для LCP-изображения в 2026 году:

<!-- Плохо - убивает LCP -->
<img src="hero.jpg" loading="lazy" alt="Hero image">

<!-- Хорошо - помогает LCP -->
<img 
  src="hero.webp"
  srcset="hero-480.webp 480w, hero-800.webp 800w, hero-1200.webp 1200w"
  sizes="(max-width: 768px) 100vw, 1200px"
  fetchpriority="high"
  loading="eager"
  decoding="async"
  width="1200"
  height="600"
  alt="Описание изображения"
>

<!-- Ещё лучше - preload в <head> -->
<link 
  rel="preload" 
  as="image" 
  href="hero.webp"
  imagesrcset="hero-480.webp 480w, hero-800.webp 800w"
  imagesizes="(max-width: 768px) 100vw, 1200px"
>

Подробнее об оптимизации изображений, включая настройку автоконвертации в WebP на уровне сервера, я разбирал в статье настройка WebP и оптимизация изображений на сайте в 2026. Там есть готовые конфиги для Nginx.

INP: новая боль разработчиков

INP (Interaction to Next Paint) — это метрика, с которой большинство разработчиков ещё не до конца разобрались. Она измеряет задержку между действием пользователя (клик, нажатие клавиши, тап) и следующим отрисованным кадром. Порог "зелёной зоны" — до 200 мс, жёлтый — 200-500 мс, красный — больше 500 мс.

Главные виновники плохого INP — это тяжёлые обработчики событий, блокирующий JavaScript, и слишком много работы в главном потоке. На практике я чаще всего вижу такую картину: на сайте подключены 3-4 сторонних скрипта (чат, аналитика, пиксели соцсетей), которые суммарно занимают главный поток на 800-1200 мс при первой интеракции.

Решение — переносить тяжёлые скрипты в Web Workers, использовать scheduler.postTask() для приоритизации задач, и откладывать загрузку некритичных скриптов. Вот пример правильной загрузки аналитики и чат-виджета:

// Плохо - грузим всё сразу
document.addEventListener('DOMContentLoaded', () => {
  loadChatWidget();
  loadAnalytics();
  loadPixels();
});

// Хорошо - откладываем некритичное
// Аналитика - после загрузки страницы
window.addEventListener('load', () => {
  // Небольшая задержка чтобы не конкурировать с LCP
  setTimeout(() => {
    loadAnalytics();
  }, 1000);
});

// Чат - только при первом взаимодействии
let chatLoaded = false;
const loadChatOnInteraction = () => {
  if (chatLoaded) return;
  chatLoaded = true;
  loadChatWidget();
};

['mousedown', 'touchstart', 'keydown', 'scroll'].forEach(event => {
  document.addEventListener(event, loadChatOnInteraction, { once: true, passive: true });
});

// Speculation Rules API для предзагрузки страниц (новинка 2024-2026)
if (HTMLScriptElement.supports && HTMLScriptElement.supports('speculationrules')) {
  const script = document.createElement('script');
  script.type = 'speculationrules';
  script.textContent = JSON.stringify({
    prerender: [{
      where: { href_matches: '/*' },
      eagerness: 'moderate'
    }]
  });
  document.head.appendChild(script);
}

По Speculation Rules API отдельно скажу: это реально работает. На одном проекте на Laravel включение этой фичи дало субъективно мгновенные переходы между страницами. Lighthouse это напрямую не измеряет, но пользователи замечают разницу.

CLS: борьба с прыжками вёрстки

CLS (Cumulative Layout Shift) — метрика, которую легко испортить и сложно починить, если не знаешь причин. Порог "зелёной зоны" — до 0.1. Самые частые виновники в моей практике:

• Изображения без указанных width и height атрибутов
• Шрифты, которые загружаются и вызывают FOUT (Flash of Unstyled Text)
• Баннеры и рекламные блоки, которые вставляются динамически
• Кнопки "Принять cookies", появляющиеся поверх контента
• Контент, который догружается через AJAX после основной отрисовки

С изображениями всё просто — всегда указывай размеры. Браузер резервирует место под изображение ещё до его загрузки. Со шрифтами хитрее. Я использую font-display: optional или font-display: swap в зависимости от критичности шрифта, и обязательно предзагружаю основные шрифты через <link rel="preload">.

/* В CSS */
@font-face {
  font-family: 'MyFont';
  src: url('/fonts/myfont.woff2') format('woff2');
  font-weight: 400;
  font-style: normal;
  font-display: optional; /* Не вызывает CLS - не показывает шрифт пока не загрузится */
}

/* В HTML head */
/* <link rel="preload" as="font" href="/fonts/myfont.woff2" crossorigin> */

Ещё один приём, который я активно использую — size-adjust для системного шрифта-фоллбека. Это позволяет подогнать размеры системного шрифта под размеры загружаемого, и переключение происходит практически незаметно для глаза, без скачков CLS.

JavaScript: главный враг производительности

По опыту — JavaScript это источник 60-70% всех проблем с производительностью на современных сайтах. Не изображения, не CSS, а именно JS. И проблема не только в размере бандла, но и в том, как он парсится, компилируется и выполняется.

Lighthouse показывает несколько JS-related аудитов: "Reduce unused JavaScript", "Avoid enormous network payloads", "Minimize main-thread work". Если у вас красные или жёлтые результаты по этим пунктам — дело плохо.

На проектах с WordPress я регулярно вижу ситуацию: подключены 15-20 плагинов, каждый тащит свой JS, итого на странице 2-3 МБ скриптов. После аудита и оптимизации WordPress удаётся убрать 60-70% лишнего JS просто отключением неиспользуемых плагинов и настройкой условной загрузки — чтобы скрипт слайдера не грузился на странице "Контакты".

Для более тонкой работы с JS-производительностью я настраиваю Nginx для правильного кеширования и сжатия статики. Вот мой базовый конфиг:

# Сжатие Brotli (предпочтительно) и Gzip
brotli on;
brotli_comp_level 6;
brotli_types text/plain text/css application/json application/javascript 
             text/xml application/xml text/javascript image/svg+xml;

gzip on;
gzip_comp_level 5;
gzip_min_length 256;
gzip_types text/plain text/css application/json application/javascript
           text/xml application/xml text/javascript image/svg+xml
           application/font-woff2;

# Кеширование статики
location ~* \.(js|css|woff2|webp|avif|jpg|jpeg|png|gif|svg|ico)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
    add_header Vary "Accept-Encoding";
}

# Отдельно для HTML - без долгого кеша
location ~* \.html$ {
    expires 1h;
    add_header Cache-Control "public, must-revalidate";
}

# HTTP/2 Server Push для критических ресурсов (если используете HTTP/2)
# location = / {
#     http2_push /css/critical.css;
#     http2_push /fonts/main.woff2;
# }

О настройке сжатия я подробно писал в статье настройка Gzip и Brotli для ускорения сайта — там есть бенчмарки и сравнение степеней сжатия.

TTFB и серверный ответ: когда проблема не в фронтенде

TTFB (Time to First Byte) — это то, с чего всё начинается. Lighthouse считает нормальным TTFB до 800 мс, но я целюсь в 200 мс и ниже. Если TTFB высокий — никакая фронтендная оптимизация не спасёт. Это как пытаться разогнать машину с ручником.

Причины высокого TTFB бывают разные: медленный хостинг, тяжёлые запросы к БД, отсутствие кеширования на уровне приложения, PHP 7.4 вместо 8.2/8.3. Да, версия PHP реально влияет. PHP 8.3 быстрее PHP 7.4 примерно на 20-30% на реальных нагрузках, я проверял на нескольких проектах. Если вы ещё сидите на старом PHP — это первое, что нужно исправить. Подробнее об этом в статье про обновление PHP на сервере.

Для Bitrix я настраиваю многоуровневое кеширование: HTMLCache для публичных страниц, Memcached или Redis для сессий и данных, OPcache для PHP. Правильно настроенный Bitrix отвечает за 50-80 мс вместо 800-1200 мс без кеша. Разница колоссальная. Если у вас Битрикс — обязательно прочитайте про настройку кеширования в Битрикс, там я разбираю все уровни кеша по порядку.

Для WordPress тактика похожа: WP Rocket или LiteSpeed Cache, Redis Object Cache, PHP 8.2+, и обязательно — проверка запросов к БД. Я видел WordPress-сайты, которые делали 200+ запросов к MySQL на одной странице. После оптимизации запросов TTFB падал с 1.5 секунды до 150 мс.

Accessibility и SEO в Lighthouse — не игнорируйте

Многие смотрят только на вкладку Performance и игнорируют Accessibility и SEO. Это ошибка. Во-первых, Google использует Lighthouse-аудиты как сигналы ранжирования. Во-вторых, проблемы с доступностью часто напрямую влияют на производительность — например, изображения без alt-тегов или неправильная иерархия заголовков.

По Accessibility: самые частые проблемы в моей практике — это отсутствие alt у изображений, недостаточный контраст текста, интерактивные элементы без aria-label, и форма без связанных label. Всё это Lighthouse находит автоматически. Балл Accessibility ниже 90 — повод для серьёзного разговора с дизайнером.

По SEO-вкладке Lighthouse: это базовые технические проверки — наличие meta description, правильные canonical, отсутствие блокировки индексации, корректные hreflang. Если здесь что-то красное — это вообще первоочерёдная задача. Хотя для глубокого SEO-аудита одного Lighthouse недостаточно, там нужен отдельный инструментарий.

Автоматизация Lighthouse: встраиваем в процесс разработки

Запустить Lighthouse один раз и забыть — бессмысленно. Я настраиваю регулярный автоматический мониторинг производительности на всех своих проектах. Есть несколько подходов.

Первый — Lighthouse CI. Это официальный инструмент от Google, который интегрируется с GitHub Actions, GitLab CI или любым другим CI/CD. Настраивается через файл lighthouserc.json. Каждый пул-реквест автоматически проверяется, и если производительность упала ниже порога — мерж блокируется. Это реально спасает от случайных деградаций.

// lighthouserc.json
{
  "ci": {
    "collect": {
      "url": ["https://example.com", "https://example.com/catalog/"],
      "numberOfRuns": 3
    },
    "assert": {
      "assertions": {
        "categories:performance": ["error", {"minScore": 0.8}],
        "categories:accessibility": ["warn", {"minScore": 0.9}],
        "first-contentful-paint": ["warn", {"maxNumericValue": 2000}],
        "largest-contentful-paint": ["error", {"maxNumericValue": 2500}],
        "cumulative-layout-shift": ["error", {"maxNumericValue": 0.1}],
        "interaction-to-next-paint": ["error", {"maxNumericValue": 200}]
      }
    },
    "upload": {
      "target": "temporary-public-storage"
    }
  }
}

Второй подход — использовать сторонние сервисы мониторинга: SpeedCurve, Calibre, или бесплатный CrUX Dashboard в Google Data Studio. Они автоматически собирают реальные данные пользователей (RUM — Real User Monitoring) и показывают тренды. Это важно, потому что Lighthouse — это лабораторный тест, а реальные пользователи могут видеть совсем другие цифры.

Третий подход, который я практикую для клиентских проектов в рамках поддержки сайтов на Битриксе и поддержки WordPress — еженедельный автоматический отчёт с трендом метрик. Клиент видит, что показатели улучшаются (или не ухудшаются) после каждого обновления. Это конкретный измеримый результат работы.

Реальные цифры: до и после оптимизации

Хочу закончить конкретными кейсами, потому что абстрактные советы — это одно, а реальные результаты — другое.

Кейс 1: Интернет-магазин на Bitrix, ~5000 SKU. До оптимизации: Performance 31 (mobile), LCP 6.2s, CLS 0.28, INP 840ms, TTFB 1.8s. После трёх недель работы: Performance 78, LCP 1.9s, CLS 0.04, INP 180ms, TTFB 190ms. Что сделали: включили HTMLCache и Redis, перешли на PHP 8.2, оптимизировали изображения (WebP + правильные размеры), убрали 4 неиспользуемых плагина, вынесли статику на CDN. Конверсия выросла на 12% — клиент это отдельно замерял.

Кейс 2: Корпоративный сайт на WordPress. До: Performance 44, LCP 4.1s, много JS-блокировок. После: Performance 91, LCP 1.4s. Ключевое действие — правильная настройка WP Rocket с критическим CSS, отложенная загрузка JS, переход на PHP 8.3 и подключение Cloudflare с агрессивным кешированием. Заняло два дня работы.

Кейс 3: Лендинг на чистом HTML/CSS с несколькими JS-анимациями. Казалось бы — должно быть быстро. Performance 62 из-за неоптимизированных изображений, Google Fonts без preload, и YouTube-эмбеда в первом экране. После замены YouTube на фасадный компонент (показываем превью, iframe грузим только по клику), оптимизации шрифтов и изображений — Performance 97. YouTube-фасад — это вообще must-have приём, рекомендую всем.

Если хотите разобраться с производительностью вашего сайта профессионально — я занимаюсь доработкой и оптимизацией сайтов под ключ. Провожу полный Lighthouse-аудит, составляю приоритизированный план работ и последовательно улучшаю метрики с измеримым результатом на каждом этапе.