Руководства
Как проверить скорость сайта без выдуманных Core Web Vitals
Быстрый ответ HTML полезен, но это не LCP, INP или CLS, измеренные в реальном браузере.
Используйте время ответа и HTML-бюджеты для поиска рисков. Заявлять о Core Web Vitals можно только после браузерного теста и проверки полевых данных.
Начните с пути ответа и серверных метрик
Зафиксируйте DNS-резолвинг, TLS-хендшейк, время до первого байта (TTFB), цепочку редиректов, сжатие Brotli/Gzip и размер HTML-документа. Исходный HTML объёмом до 150 КБ позволяет браузеру быстро приступить к парсингу DOM. Устраните ошибки ответа, лишние 301/302 перенаправления и задержки origin-сервера перед оптимизацией вторичных ресурсов.
Не путайте бюджеты с Core Web Vitals
Размер HTML, глубина DOM (до 1500 элементов) и число скриптов — это технические инженерные ориентиры. Метрики Core Web Vitals описывают реальный пользовательский опыт и требуют измерений в настоящем браузере; полевые показатели (LCP, INP, CLS) оцениваются по 75-му перцентилю реальных сессий (CrUX), а не синтетическим пингом.
Проверьте критический путь рендеринга
Найдите блокирующие парсинг скрипты в теге head без атрибутов async, defer или type='module'. Ограничьте число внешних CSS-файлов (не более 6 критических стилей) и сократите встроенный JavaScript. Вынос inline-скриптов объёмом свыше 100 КБ во внешние кэшируемые файлы освобождает главный поток браузера.
Оптимизируйте изображения и ресурсы
Используйте нативную отложенную загрузку loading='lazy' и явные атрибуты width/height для изображений ниже первого экрана, чтобы предотвратить сдвиги макета (CLS). При этом главное LCP-изображение первого экрана должно загружаться сразу (fetchpriority='high'). Применяйте современные форматы WebP и AVIF.
Ставьте выше влияние на пользователя
Оптимизируйте тяжёлые серверные запросы к БД и блокирующие рендер ресурсы до косметической микрооптимизации. Сверяйте полевую телеметрию и автоматические тесты при троттлинге до и после каждого изменения, чтобы зафиксировать измеримый выигрыш в скорости.