Дата публикации: 28.10.2025

Как ускорить сайт: от Core Web Vitals до реальной производительности

Скорость — это не «цифра в PageSpeed». Это то, как быстро пользователь видит контент, может ли он кликнуть без задержки и не дёргается ли интерфейс при загрузке. Google давно подтвердил: Core Web Vitals влияют на ранжирование, а задержка >3 сек увеличивает отказы на 40–60%.

Три метрики, которые реально важны

МетрикаЧто измеряетЦель (2024–2026)
LCP (Largest Contentful Paint)Время отрисовки главного контента≤ 2.5 сек
INP (Interaction to Next Paint)Задержка реакции на клик/тап≤ 200 мс
CLS (Cumulative Layout Shift)Визуальная стабильность≤ 0.1

⚠️ PageSpeed Insights даёт оценку, но не диагноз. Всегда сверяйтесь с WebPageTest и Chrome DevTools (Performance tab).

Где прячутся тормоза

  1. Изображения: WebP/AVIF не используются, нет srcset, тяжёлые баннеры в hero-секции.
  2. JavaScript: синхронная загрузка, блокирующие скрипты, неиспользуемый код, тяжёлые библиотеки (jQuery, lodash без tree-shaking).
  3. CSS: блокирующий рендеринг, отсутствие critical CSS, дубликаты, неиспользуемые стили.
  4. Сервер: медленный TTFB (>800ms), отсутствие кэширования, HTTP/1.1, нет GZIP/Brotli.
  5. Сторонние сервисы: 3–5 чатов, аналитика, виджеты соцсетей — каждый добавляет 0.2–0.5 сек.

Пошаговая оптимизация

1. Быстрые победы (1–3 дня)

  • Конвертация изображений в WebP/AVIF, сжатие без потери качества
  • Включение loading="lazy" для off-screen изображений/iframe
  • Дефер/асинк для не критичных скриптов (defer, async, type="module")
  • Включение Brotli/GZIP, кэширование статики (Cache-Control, ETag)

2. Архитектурные улучшения (1–2 недели)

  • Выделение Critical CSS (inline первых 14KB), остальное — async
  • Удаление неиспользуемого JS/CSS (PurgeCSS, tree-shaking)
  • Настройка CDN (Cloudflare, BunnyCDN) + HTTP/3
  • Оптимизация БД: индексы, очистка логов, object caching (Redis/Memcached)

3. Продвинутые техники

  • Предзагрузка ключевых ресурсов: <link rel="preload">, prefetch, preconnect
  • Разделение кода (code splitting), динамический импорт
  • Service Worker для офлайн-кэширования (если применимо)
  • Перенос тяжёлой логики на edge/serverless

Чего делать не стоит

❌ Гнаться за 100/100 в Lighthouse в ущерб функционалу.
❌ Удалять аналитику и чаты без оценки бизнес-потерь.
❌ Оптимизировать только фронтенд, игнорируя TTFB и БД.
❌ Использовать «оптимизаторы-плагины» без понимания, что они делают.

Чек-лист проверки скорости

  • LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1
  • TTFB ≤ 800ms (желательно ≤ 400ms)
  • Все изображения в WebP/AVIF + srcset
  • JS/CSS: defer, async, critical CSS inline, удаление unused
  • CDN + HTTP/2/3 + Brotli
  • Кэширование статики и объектное кэширование БД
  • Мониторинг: RUM (Real User Monitoring), алерты при деградации

Итог

Быстрый сайт — это не магия, а дисциплина: измерьте → найдите bottleneck → устраните → мониторьте. Начните с метрик Core Web Vitals, уберите блокирующие ресурсы, настройте кэширование и CDN. Результат будет заметен в конверсии, а не только в отчётах.

Если сайт работает медленно, можно провести оптимизацию и найти узкие места.