Ускорение начинается не с минификации и не с покупки сервера, а с определения симптома. Если HTML приходит через три секунды, оптимизация изображения не устранит ожидание. Если сервер отвечает быстро, но главный баннер весит несколько мегабайт, увеличение процессора не поможет пользователю.

Измеряйте реальный маршрут: DNS и соединение, ответ сервера, загрузку критичных ресурсов, отрисовку основного контента, выполнение JavaScript и реакцию на действия. Разные этапы требуют разных исправлений.

Что пользователи называют медленным сайтом

  • Долго пустой экран. Задерживается сервер, критический CSS, шрифт или начальная отрисовка.
  • Контент появляется поздно. Главное изображение или блок ждёт тяжёлые ресурсы.
  • Страница видна, но не реагирует. Основной поток занят JavaScript или длинной задачей.
  • Элементы прыгают. Не зарезервированы размеры рекламы, изображений и виджетов.
  • Медленно только иногда. Пики нагрузки, холодный кеш, фоновые задания или нестабильный внешний API.
  • Медленно в редакции. Проблема административной части, базы или сохранения, а не публичной страницы.

Зафиксируйте URL, устройство, сеть, время, действие и видео или трассировку. «Вчера всё тормозило» почти невозможно расследовать без наблюдаемости.

Лабораторные и полевые данные

Лабораторный тест повторяет загрузку в контролируемых условиях и показывает водопад запросов, блокирующие ресурсы и выполнение кода. Он удобен для диагностики конкретной версии.

Полевые данные собираются у реальных посетителей на разных устройствах и сетях. Они отвечают, испытывает ли проблему аудитория. Среднее значение скрывает медленный хвост, поэтому производительность оценивают по процентилям и сегментам.

Используйте сочетание:

  • DevTools и Lighthouse — для локальной диагностики;
  • PageSpeed Insights — для лабораторных рекомендаций и доступных полевых данных;
  • Search Console — для групп URL с проблемами Core Web Vitals;
  • собственный RUM — для маршрутов, устройств, версий и бизнес-контекста;
  • APM и серверные метрики — для запросов приложения и базы.

Один балл производительности не является диагнозом. Сохраняйте исходные метрики, водопад и условия теста, чтобы сравнивать результат после изменения.

Сервер, сеть и backend

Долгое ожидание первого байта может возникать из-за медленного приложения, внешнего API, нехватки процессов, DNS, TLS, географической удалённости или отсутствия кеша. Смотрите время на каждом уровне, а не только общую длительность.

Проверьте:

  • нагрузку CPU, память, swap, диск и сеть;
  • очередь веб-сервера и занятые worker-процессы;
  • медленные endpoint и распределение времени по зависимостям;
  • таймауты внешних API;
  • холодный старт приложения;
  • синхронную обработку изображений, почты и выгрузок;
  • географию пользователей и сервера.

Фоновые операции выносите в очередь, внешние запросы ограничивайте таймаутом и продуманным fallback. Масштабирование полезно после устранения очевидной сериализации и медленных запросов.

База данных и CMS

CMS часто замедляется не из-за «тяжёлого движка», а из-за сочетания расширений, сложных выборок и отсутствия кеша. Одна страница может выполнять сотни запросов, собирать связанные материалы и проверять права для каждого блока.

  • включите журнал медленных запросов;
  • найдите повторяющиеся запросы и проблему N+1;
  • проверьте индексы по реальному плану выполнения;
  • ограничьте выборку нужными полями и количеством записей;
  • не считайте тяжёлую статистику при каждом просмотре;
  • архивируйте разросшиеся служебные таблицы;
  • измерьте влияние каждого плагина, а не отключайте наугад.

Для контентного проекта важно разделять скорость публикации в админке и отдачу читателю. Публичную страницу можно эффективно кешировать, даже если редакционная операция остаётся сложной.

Изображения, видео и шрифты

Большая обложка часто становится элементом LCP. Не отправляйте телефонному экрану исходник шириной несколько тысяч пикселей. Генерируйте варианты, используйте srcset и sizes, выбирайте подходящий формат и разумное качество.

Главное изображение не следует лениво загружать без причины: оно должно обнаруживаться браузером рано. Для изображений ниже первого экрана lazy loading полезен. Всегда задавайте размеры или соотношение сторон, чтобы не создавать сдвиги.

Шрифты сокращайте до используемых начертаний и символов, загружайте только необходимые файлы и задавайте стратегию отображения. Один variable font иногда удобнее набора, но не автоматически легче. Видео должно иметь постер и не загружать большой файл до явного действия, если это не ключевой сценарий.

JavaScript и CSS

JavaScript конкурирует с отрисовкой и обработкой действий на основном потоке. Тяжёлый bundle, гидратация большой страницы, обработчики и сторонние SDK ухудшают отзывчивость даже после полной загрузки.

  • удаляйте неиспользуемый код и тяжёлые зависимости;
  • разделяйте bundle по маршрутам и функциям;
  • откладывайте необязательные виджеты;
  • разбивайте длинные задачи;
  • не пересчитывайте весь интерфейс из-за одного действия;
  • профилируйте реальную работу, а не размер файла отдельно.

Критический CSS должен позволить быстро показать первый экран. Большой общий файл стилей, цепочка импортов и синхронные ресурсы задерживают отрисовку. Но механическое встраивание всего CSS в HTML увеличивает документ и лишает кеширования — оптимизируйте измеряемое узкое место.

Реклама, аналитика и внешние скрипты

На медиа сторонний код часто тяжелее собственного: рекламные аукционы, измерители, рекомендации, комментарии, видео и push. Каждый поставщик добавляет сеть, JavaScript и риск сдвига.

Составьте реестр внешних скриптов: владелец, цель, вес, момент загрузки и срок пересмотра. Удаляйте сервисы без активного владельца. Загружайте необязательное после согласия или взаимодействия, используйте sandbox для встраиваемого содержимого и резервируйте размеры рекламы.

Тестируйте сайт в двух режимах — чистый шаблон и полный рекламный стек. Так видно, что контролирует команда, а что требует переговоров с поставщиком.

Кеширование и CDN

Кеш уменьшает повторную работу, но требует правил актуальности. Уровни могут включать браузер, CDN, HTML, объектный кеш и результаты запросов. Для каждого определите ключ, срок жизни, событие очистки и поведение при ошибке.

Статическим файлам с хешем в имени можно дать долгий срок. HTML новости должен обновляться после исправления, а главная — при публикации. Полная очистка всего кеша на каждое изменение создаёт пики и сводит пользу к минимуму.

CDN сокращает путь до файлов и защищает origin от части нагрузки, но не исправляет медленный персонализированный backend. Проверяйте cache hit ratio, заголовки и варианты по cookie и query string.

Core Web Vitals

Актуальный набор включает:

  • LCP — время появления крупнейшего значимого элемента. Хорошее значение: не более 2,5 секунды.
  • INP — отзывчивость на взаимодействия. Хорошее значение: не более 200 мс.
  • CLS — неожиданные сдвиги макета. Хорошее значение: не более 0,1.

Google оценивает полевые значения на 75-м процентиле просмотров. Лабораторный тест не может полностью измерить INP без реальных взаимодействий, поэтому его диагностические показатели и полевые данные дополняют друг друга.

Хорошие Core Web Vitals полезны пользователю и учитываются системами поиска, но не заменяют релевантное содержание. Не ухудшайте функциональность ради идеального балла и не принимайте зелёный отчёт за завершённую оптимизацию.

Правильный порядок диагностики

  1. Зафиксируйте симптом, URL, устройство и время.
  2. Проверьте масштаб: одна страница, шаблон, регион или весь сайт.
  3. Сравните полевые данные по сегментам.
  4. Снимите лабораторную трассировку и водопад.
  5. Разделите время сервера, загрузки и выполнения frontend.
  6. Найдите один доминирующий фактор.
  7. Сформулируйте изменение и ожидаемую метрику.
  8. Внесите минимальное исправление и проверьте регрессию.
  9. Сравните те же условия после выкладки.
  10. Наблюдайте реальные данные после накопления выборки.

При аварийной деградации сначала восстановите сервис: отключите проблемную интеграцию, уменьшите нагрузку, включите кеш или верните версию. Причину и постоянное исправление разбирайте после стабилизации, сохранив логи и временную шкалу.

Чек-лист первичного аудита

  • Есть полевые данные, а не только один Lighthouse.
  • Измерен ответ сервера и конечный URL после редиректов.
  • Найдены LCP-элемент и критические ресурсы.
  • Проверены размеры изображений и шрифтов.
  • Определены длинные задачи JavaScript.
  • Составлен список сторонних скриптов.
  • Для рекламы и медиа зарезервированы размеры.
  • Проверены медленные запросы базы и внешние API.
  • Понятны уровни кеша и условия очистки.
  • Изменения сравниваются в одинаковых условиях.

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

Поможет ли более мощный сервер?

Если текущий упирается в CPU, память, диск или число процессов — да. Но он не уменьшит изображения, JavaScript и время внешней рекламы. Сначала подтвердите узкое место.

Почему PageSpeed каждый раз показывает разный результат?

Меняются сеть, сервер, внешние ресурсы и условия теста. Сравнивайте несколько запусков, медиану, конкретные метрики и полевые данные.

Нужно ли стремиться к 100 баллам?

Нет. Балл помогает диагностировать, но бизнесу важна реальная скорость ключевых страниц и действий. Последние пункты могут стоить дороже, чем принесут пользы.

Почему быстрый сайт имеет плохой INP?

Он может быстро показать страницу, но блокировать основной поток при клике или вводе. Загрузка и отзывчивость — разные характеристики.

Как часто проверять производительность?

Полевые метрики — постоянно, лабораторные — в CI для важных шаблонов и после значимых изменений. Рекламный и контентный стек меняется, поэтому разовый аудит быстро устаревает.

Производительность должна стать частью регулярной технической поддержки, а требования к ней — критерием при выборе CMS.

Источники: Google Search Central о Core Web Vitals и методика и пороговые значения web.dev.