Проверка скорости сайта: инструменты, метрики и как мерить правильно

Коротко. Проверка скорости сайта делится на два класса. Лабораторные прогоны (Lighthouse, PageSpeed Insights, GTmetrix, WebPageTest) гоняют страницу на синтетическом устройстве с искусственным каналом. Полевые данные (CrUX, Search Console, свой RUM) собираются у живых посетителей. Расхождение «в PSI 95, а люди жалуются» — это именно разница между лабораторией и полем, а не ошибка инструмента.

Эта статья — не список ссылок «топ-10 сервисов». Это разбор того, что каждый класс инструментов действительно измеряет, почему два прогона подряд дают разные цифры, какие метрики смотреть в 2026 году и как построить замер, которому можно верить. Оптимизация вынесена в отдельные материалы — здесь только измерение и его интерпретация.

Что измеряют инструменты проверки скорости сайта

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

• Доставка байтов. Сколько времени сервер думает над ответом и сколько данных прилетает в браузер: TTFB, объём страницы, число запросов, наличие сжатия. Отвечает бэкенд, хостинг, CDN.
• Отрисовка. Когда пользователь видит хоть что-то (FCP) и когда видит главное (LCP), насколько плавно страница наполняется (Speed Index). Отвечает критический путь рендеринга: CSS, шрифты, изображения.
• Интерактивность и стабильность. Отвечает ли страница на клики (TBT в лаборатории, INP в поле) и не прыгает ли вёрстка под пальцем (CLS). Отвечает JavaScript и разметка.

Сайт может отдавать HTML за 80 мс и при этом быть невыносимо медленным, потому что три мегабайта JS блокируют главный поток на две секунды. И наоборот: тяжёлый TTFB на сервере в другой стране губит даже идеально свёрстанную страницу. Поэтому один агрегированный балл почти бесполезен без разбивки по метрикам — с этого и начинается чтение любого отчёта.

Правило. Никогда не сравнивайте «баллы» между разными инструментами. Lighthouse, GTmetrix и любой самописный чекер считают итоговую оценку по своим формулам и своим весам. Сравнивать можно только одинаковые метрики, снятые одинаковым способом.

Лабораторные и полевые данные: главное различие

Это то место, где у большинства ломается картина мира. Разберём по частям.

Что такое лабораторный прогон

Лаборатория (lab data, синтетика) — это один прогон страницы в контролируемых условиях: конкретный браузер, заданный профиль сети, заданная мощность процессора, холодный кэш, отсутствие расширений и отсутствие живого пользователя. Инструмент открывает страницу, ждёт затухания активности и выдаёт метрики. Так работают Lighthouse, лабораторная часть PageSpeed Insights, GTmetrix, WebPageTest и любой синтетический мониторинг.

Сильная сторона: воспроизводимость и диагностика. Вы получаете трассировку, водопад запросов, список конкретных ресурсов и можете проверить эффект правки за минуту. Слабая сторона: это не ваши пользователи. Это гипотетический пользователь на устройстве, которого вы выбрали.

Что такое полевые данные

Поле (field data, RUM — real user monitoring) — это метрики, снятые в браузерах реальных посетителей и агрегированные. Основной публичный источник для Chrome — набор данных CrUX, из которого поле берут и PageSpeed Insights, и отчёт Core Web Vitals в Search Console. Важные свойства этих данных:

• Агрегация идёт по скользящему окну примерно в 28 дней — то есть данные всегда «запаздывают» и не покажут вчерашний релиз.
• Метрика оценивается по 75-му перцентилю: «хорошо» означает, что три четверти загрузок уложились в порог, а не среднее значение.
• В выборку попадают только пользователи Chrome, согласившиеся на отправку статистики. Safari, Firefox и корпоративные сборки с отключённой телеметрией в CrUX не видны.
• Если у конкретного URL мало трафика, данных по нему не будет — инструмент подставит агрегат по всему домену (origin) или скажет, что данных недостаточно.

Почему «в PSI 95, а пользователи жалуются»

Типовые причины расхождения, от самой частой к редкой:

• INP в лаборатории не измеряется вообще. Это метрика взаимодействия: чтобы её получить, нужен человек, который кликает. Лабораторный прогон использует суррогат — TBT. Страница с зелёным лабораторным баллом может иметь ужасный INP в поле.
• Аудитория тяжелее синтетического профиля. Лабораторный «средний мобильник» может оказаться быстрее реальных устройств вашей аудитории, а канал в дата-центре — быстрее мобильного интернета в пригороде.
• Лаборатория не видит вашего кода после согласия на куки. Баннеры согласия, чаты поддержки, пиксели рекламных сетей и A/B-скрипты часто грузятся только после действия пользователя или только для части трафика.
• Разные страницы. Вы гоняете главную, а жалуются на карточку товара с двадцатью изображениями и фильтром.
• Залогиненные пользователи. Личный кабинет обычно тяжелее публичной части, а в лабораторию он не попадает.

Обратный случай: «в PSI 40, а в поле зелено»

Тоже нормальная ситуация. Мобильный лабораторный прогон намеренно жестокий: слабый процессор и медленный канал. Если ваша реальная аудитория — офисные десктопы на проводном интернете, поле будет зелёным при низком лабораторном балле. Вывод: низкий балл — повод посмотреть, что именно тормозит, а не повод паниковать. Решение о приоритете принимается по полю.

Практическое правило. Поле отвечает на вопрос «есть ли проблема и у кого». Лаборатория отвечает на вопрос «почему и что чинить». Использовать нужно оба: только поле — вы знаете о боли, но не знаете причину; только лаборатория — вы чините то, что никого не беспокоит.

Метрики скорости: LCP, INP, CLS, TTFB, FCP, TBT

Актуальный набор Core Web Vitals состоит из трёх метрик: LCP, INP и CLS. Метрика FID (First Input Delay) выведена из состава Core Web Vitals весной 2024 года — её заменил INP. Если инструмент или чек-лист до сих пор предлагает «улучшить FID», он устарел; ориентироваться нужно на INP. Подробный разбор новой метрики — в материале про INP в Core Web Vitals, а общий свод показателей — в гайде по Web Vitals.

Метрика	Что измеряет	Типичная причина ухудшения	Куда смотреть
LCP (Largest Contentful Paint)	Момент отрисовки самого крупного видимого элемента: героического изображения, баннера или блока текста	Тяжёлая картинка без современного формата, ленивая загрузка на LCP-элементе, шрифт, блокирующий текст, медленный TTFB	Водопад: какой ресурс является LCP-элементом и когда он начал грузиться. Проверить preload и приоритет
INP (Interaction to Next Paint)	Задержку между действием пользователя и следующей отрисовкой; берётся худшее взаимодействие за визит	Длинные задачи JavaScript, тяжёлые обработчики событий, синхронный рендер больших списков, сторонние виджеты	Только поле или ручной тест в DevTools. В лаборатории косвенно — по TBT и long tasks
CLS (Cumulative Layout Shift)	Суммарный сдвиг вёрстки за время жизни страницы	Изображения и iframe без указанных размеров, поздние баннеры и куки-панели, подмена шрифта, вставки рекламы	Performance в DevTools, слой Layout Shift Regions; в отчёте инструмента — список сдвинувшихся элементов
TTFB (Time to First Byte)	Время до первого байта ответа: DNS, TCP, TLS, обработка на сервере, сеть	Медленный бэкенд или база, отсутствие кэша, промах CDN, редиректы, географическая удалённость	Терминал: curl -w с полным таймингом. Дальше — логи и профилирование приложения
FCP (First Contentful Paint)	Момент, когда пользователь видит первый фрагмент контента	Блокирующий CSS и JS в head, тяжёлый шрифт, высокий TTFB	Водопад: что стоит между HTML и первой отрисовкой
TBT (Total Blocking Time)	Суммарное время, на которое главный поток был заблокирован задачами дольше 50 мс	Крупные бандлы, гидратация SPA, аналитика и теги в менеджере тегов, полифилы	Вкладка Performance, раздел Long Tasks; в Lighthouse — «Reduce JavaScript execution time»
Speed Index	Насколько быстро визуально заполняется первый экран	Поздние изображения, анимация появления, отложенный рендер контента	Видеозапись загрузки и филмстрип в WebPageTest или GTmetrix

Какие значения считаются нормальными

Пороги ниже — общепринятые ориентиры, которые используют публичные инструменты. Они оцениваются по 75-му перцентилю полевых данных, а не по одному прогону. Разделять мобильные и десктопные значения обязательно: одна и та же страница почти всегда попадает в разные категории.

Метрика	Хорошо	Требует внимания	Плохо	Где доступна
LCP	до 2,5 с	2,5–4,0 с	больше 4,0 с	лаборатория и поле
INP	до 200 мс	200–500 мс	больше 500 мс	только поле
CLS	до 0,1	0,1–0,25	больше 0,25	лаборатория и поле
TTFB	до 0,8 с	0,8–1,8 с	больше 1,8 с	лаборатория, поле, терминал
FCP	до 1,8 с	1,8–3,0 с	больше 3,0 с	лаборатория и поле
TBT	до 200 мс	200–600 мс	больше 600 мс	только лаборатория

Важно. TTFB не входит в Core Web Vitals и сам по себе не влияет на оценку страницы напрямую. Но он входит в LCP как слагаемое: пока сервер думает секунду, у вас остаётся полторы секунды на всё остальное. Именно поэтому TTFB меряют отдельно и чинят первым.

Почему балл Lighthouse — это не «скорость»

Число в цветном кружке — не время загрузки и не «процент качества». Это взвешенная композиция нескольких лабораторных метрик, переведённых в баллы по нелинейной кривой. В актуальных версиях Lighthouse вклад распределён примерно так: TBT около 30%, LCP около 25%, CLS около 25%, FCP и Speed Index — по 10%. Точные веса меняются от версии к версии, и это одна из причин, почему балл «сам собой» меняется после обновления инструмента.

Из устройства балла следуют неочевидные вещи:

• INP в балл не входит. Совсем. Балл Lighthouse может быть зелёным на странице, которая реагирует на клик через полсекунды.
• Одна метрика топит всё. Треть веса у TBT: один тяжёлый сторонний скрипт способен обрушить балл при отличных LCP и CLS.
• Кривая нелинейна. Поднять балл с 30 до 55 обычно дёшево, с 90 до 95 — дорого и почти незаметно для пользователя. Гнаться за 100/100 — плохая экономика.
• Балл — не метрика для отчёта руководству. Он не переводится в секунды. Для отчётности берите LCP и INP по полю: их можно объяснить в терминах «пользователь ждёт столько-то».

Почему два прогона подряд дают разные баллы и как мерить правильно

Откуда берётся разброс

Разброс (variance) в 5–15 баллов между двумя прогонами одной и той же неизменной страницы — норма, а не поломка. Источники:

• Ресурсы машины. Локальный Lighthouse делит процессор с вашими вкладками, сборщиком фронтенда и антивирусом. Публичные сервисы делят инфраструктуру с другими пользователями.
• Троттлинг симулируется. Режим по умолчанию не режет трафик физически, а пересчитывает тайминги по модели. Модель чувствительна к тому, как реально прошёл прогон.
• Ваш сайт не детерминирован. A/B-тесты, ротация баннеров, разные рекламные креативы, случайные товары в блоке рекомендаций — всё это меняет вес страницы от прогона к прогону.
• Кэши. Первый прогон попадает в холодный кэш CDN и холодный кэш приложения, второй — в горячий. Разница в TTFB бывает кратной.
• Сторонние домены. Аналитика и виджеты живут своей жизнью; их задержка целиком вне вашего контроля.

Как мерить правильно

• Делайте не меньше пяти прогонов, лучше девять или одиннадцать (нечётное число упрощает медиану).
• Берите медиану, а не среднее: один аномальный прогон сдвигает среднее и не сдвигает медиану.
• Фиксируйте профиль: одно и то же устройство, один и тот же режим троттлинга, один и тот же регион.
• Гоняйте ровно один URL с одними и теми же query-параметрами. UTM-метка может отключить кэш и изменить поведение.
• Сравнивайте «до» и «после» в одном окне времени. Замер до релиза утром и после релиза вечером сравнивать нельзя.
• Фиксируйте версию инструмента. Обновление Lighthouse меняет веса и пересчитывает историю в вашей голове, но не в архиве.

Мобильный прогон против десктопного

Мобильный режим — это не просто узкий экран. Инструмент дополнительно замедляет процессор (обычно в четыре раза относительно машины, на которой идёт прогон) и ограничивает канал профилем медленного мобильного интернета с заметной задержкой. Смысл в том, чтобы смоделировать бюджетный Android, а не флагман.

Практические следствия:

• Мобильный балл почти всегда ниже десктопного, и это ожидаемо. Сравнивать mobile с desktop бессмысленно.
• Троттлинг процессора бьёт по JS-тяжёлым сайтам сильнее всего: TBT растёт в разы, а вместе с ним падает треть балла.
• Google оценивает Core Web Vitals отдельно для мобильных и десктопных пользователей. Если основной трафик мобильный, десктопный прогон вас успокаивает зря.
• Абсолютные значения троттлинга зависят от мощности машины, на которой запущен Lighthouse. Прогон на ноутбуке разработчика и на CI-раннере даст разные цифры даже при одинаковых настройках.

Как не обмануть себя при замере

Самые частые способы получить красивую, но ложную цифру:

• Прогон с прогретым кэшем браузера. Вы уже двадцать раз открывали эту страницу — статика лежит локально. Реальный посетитель приходит с пустым кэшем. Меряйте в приватном окне или через инструмент, который гарантирует чистый профиль.
• Расширения браузера. Блокировщик рекламы вырезает половину сторонних скриптов и рисует вам чужой сайт. Менеджер паролей и переводчики добавляют свои задержки. Локальный Lighthouse запускайте в чистом профиле.
• Корпоративная сеть. Гигабитный офисный канал, кэширующий прокси и близкий к сайту дата-центр дают цифры, которых нет ни у одного вашего клиента.
• Залогиненный админ. Панель администратора, отключённый кэш для авторизованных, дебаг-панель фреймворка — вы меряете совсем другую страницу.
• Дев-сборка. Несжатые бандлы, source maps, hot reload. Меряйте только продакшен-сборку на боевом домене.
• Свежий деплой. Первые минуты после релиза кэши холодные, а фоновые задачи прогревают приложение. Дайте системе устояться.

Инструменты проверки скорости загрузки сайта: сравнение по классам

Инструменты различаются не «качеством», а классом задачи. Ниже — что каждый действительно даёт и, что важнее, чего он принципиально не покажет.

Инструмент	Лаборатория или поле	Сильная сторона	Чего НЕ покажет	Кому подходит
Lighthouse в Chrome DevTools	Лаборатория	Полный аудит с трассировкой на вашей машине, работает на localhost и за авторизацией	Полевые данные, INP реальных пользователей, поведение на других устройствах	Разработчик, локальная отладка до деплоя
PageSpeed Insights	Лаборатория + поле (CrUX)	Единственная бесплатная точка, где лабораторный прогон и полевые Core Web Vitals показаны рядом	Водопад запросов, история прогонов, страницы за авторизацией и локальные сборки	Владелец сайта, SEO-специалист, быстрый первичный диагноз
WebPageTest	Лаборатория (мультирегион, реальные устройства и профили сетей)	Самый подробный водопад, connection view, филмстрип, сравнение двух прогонов бок о бок	Полевые метрики вашей аудитории; INP как метрику реальных взаимодействий	Инженер производительности, глубокая диагностика
GTmetrix	Лаборатория	Читаемый отчёт с водопадом и видео загрузки, история прогонов по расписанию	Полевые данные CrUX по вашим пользователям; поведение авторизованной зоны	Вебмастер, регулярная проверка одной-двух ключевых страниц
Chrome DevTools, вкладки Performance и Network	Лаборатория	Что именно занимает главный поток: long tasks, layout shifts по кадрам, стек вызовов	Сводный балл и любые агрегаты; данные о других пользователях	Разработчик, поиск причины после того, как факт проблемы установлен
Search Console, отчёт Core Web Vitals	Поле (CrUX)	Группы URL, которые реально плохи у пользователей, с разбивкой mobile и desktop	Причину проблемы и любую диагностику; свежие данные — окно около 28 дней	SEO, приоритизация работ по разделам сайта
Яндекс.Метрика, отчёты по времени загрузки	Поле (ваши посетители)	Данные по вашей реальной аудитории, включая браузеры и регионы, которых нет в CrUX	Core Web Vitals в том виде, в котором их считает Google	Проекты с преимущественно российской аудиторией
Собственный RUM на библиотеке web-vitals	Поле	Метрики в разрезе шаблона страницы, устройства, региона и версии релиза; данные без задержки	Причину на уровне конкретного ресурса — нужен параллельный лабораторный прогон	Продуктовая команда, которая уже прошла базовую оптимизацию
Синтетический мониторинг по расписанию	Лаборатория, регулярно	Тренд и алерт на регресс: видно, какой релиз ухудшил метрику	Опыт конкретного пользователя и редкие тяжёлые сценарии	Команда, которой нужен контроль после каждого релиза
curl и CLI-утилиты	Лаборатория, точечно	TTFB, заголовки, сжатие, редиректы — без браузера, легко встроить в CI	Рендер, выполнение JS, layout shifts, любые визуальные метрики	Администратор и DevOps, проверка серверной части

Чего не делает ни один из них. Ни один инструмент не скажет, теряете ли вы деньги из-за скорости. Связку «метрика — конверсия» строят только на своих данных: RUM плюс аналитика, сегментация по LCP и сравнение конверсии между сегментами. Все публичные цифры «ускорение на секунду даёт X процентов» — чужие кейсы, к вашему сайту неприменимые.

Как читать водопад запросов

Водопад (waterfall) — временная диаграмма, где каждая строка это один сетевой запрос, а длина полосы — время его жизни. Полоса разбита на фазы: ожидание в очереди, DNS, установка TCP-соединения, TLS-рукопожатие, ожидание ответа сервера и собственно загрузка тела. Читать её нужно сверху вниз и слева направо.

Что искать, по убыванию частоты находок:

• Длинная фаза ожидания у самого первого запроса. Это TTFB главного документа. Пока он не закончился, браузер не знает вообще ничего о странице. Диагностика — в разделе про высокую нагрузку на сервер.
• Редиректы перед основным документом. Каждый редирект — это лишний полный цикл DNS, TCP и TLS. Цепочка «http → https → www → с завершающим слешем» стоит сотен миллисекунд на мобильном канале.
• Блокирующие ресурсы в head. Синхронные <script> и внешние CSS откладывают первую отрисовку. В водопаде это выглядит как пустая полоса до FCP, забитая парой файлов.
• Цепочки зависимостей. HTML грузит CSS, CSS через @import грузит второй CSS, тот подтягивает шрифт. Каждое звено — ещё один круг по сети. Ищите ступеньки в водопаде.
• Шрифты. Веб-шрифт, найденный только после разбора CSS, задерживает текст. Признак — полоса шрифта начинается заметно позже старта страницы.
• Отсутствие сжатия. Текстовый файл (CSS, JS, JSON, SVG, HTML) с подозрительно большим размером и без заголовка content-encoding. Разбор — в гайде по gzip и brotli.
• Изображения впереди LCP-элемента. Если браузер сначала грузит десять карточек ниже сгиба, а героическое изображение стоит в очереди двенадцатым, LCP будет плохим при любом весе файла. Рецепты — в материале про оптимизацию изображений.
• Сторонние домены. Каждый новый хост — это отдельные DNS, TCP и TLS. Пять аналитик означают пять таких циклов.

Как измерить TTFB, сжатие и кэш-заголовки из терминала

Браузерные инструменты смешивают серверное время с рендером. Когда нужно понять, тормозит сервер или фронтенд, TTFB меряют отдельно. Самый прямой способ — curl с полным разложением тайминга по фазам.

# файл формата: один раз создаём рядом со скриптом
cat > curl-format.txt <<'EOF'
dns_lookup   %{time_namelookup}s
tcp_connect  %{time_connect}s
tls_done     %{time_appconnect}s
redirects    %{time_redirect}s
ttfb         %{time_starttransfer}s
total        %{time_total}s
http_code    %{http_code}
size         %{size_download} bytes
EOF

# один замер с полным таймингом
curl -s -o /dev/null -w "@curl-format.txt" https://example.com/

Как читать вывод:

• time_namelookup — разрешение имени. Стабильно больше 50 мс означает проблему с DNS-хостингом или отсутствие кэша резолвера.
• time_connect минус time_namelookup — установка TCP. Это чистая сетевая задержка до сервера, примерно один круг.
• time_appconnect минус time_connect — TLS-рукопожатие. Обычно ещё один-два круга; на HTTP/2 с возобновлением сессии дешевле.
• time_starttransfer минус time_appconnect — чистое время генерации ответа приложением. Именно эту величину имеет смысл нести разработчику бэкенда.
• time_total минус time_starttransfer — скачивание тела. Растёт вместе с весом страницы и падает при включении сжатия.

Один замер ничего не значит. Считаем медиану по серии:

# десять замеров TTFB подряд, вывод отсортирован, снизу медиана
for i in $(seq 1 10); do
  curl -s -o /dev/null -w "%{time_starttransfer}\n" https://example.com/
done | sort -n | awk '{v[NR]=$1} END {
  printf "min %.3f  median %.3f  max %.3f\n", v[1],
    (NR%2 ? v[(NR+1)/2] : (v[NR/2]+v[NR/2+1])/2), v[NR] }'

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

# смотрим только заголовки ответа для CSS-файла
curl -s -o /dev/null -D - \
  -H 'Accept-Encoding: br, gzip' \
  https://example.com/assets/app.css \
  | grep -i -E 'content-encoding|content-length|content-type|cache-control|etag|last-modified|vary|age|x-cache|cf-cache-status'

# сравнить размер со сжатием и без
curl -s -o /dev/null -w 'plain  %{size_download} bytes\n' \
  https://example.com/assets/app.css
curl -s -o /dev/null -w 'brotli %{size_download} bytes\n' \
  -H 'Accept-Encoding: br' https://example.com/assets/app.css

На что смотреть в заголовках: наличие content-encoding со значением br или gzip для всех текстовых типов; cache-control с длинным max-age и immutable для статики с хешем в имени; vary с упоминанием Accept-Encoding, иначе прокси может раздать сжатый ответ клиенту, который сжатие не понимает. Быстрая проверка всего набора сразу — инструментом проверки HTTP-заголовков.

Наконец, лабораторный прогон можно запускать не только кнопкой в браузере. Lighthouse ставится как CLI-утилита и встраивается в CI:

# установка (нужен Node.js и установленный Chrome)
npm install -g lighthouse

# мобильный прогон по умолчанию, отчёт в HTML
lighthouse https://example.com/ \
  --output html --output-path ./report-mobile.html \
  --chrome-flags="--headless --no-sandbox" --quiet

# десктопный профиль без троттлинга процессора
lighthouse https://example.com/ \
  --preset desktop \
  --output json --output-path ./report-desktop.json \
  --chrome-flags="--headless" --quiet

# пять прогонов подряд, чтобы потом взять медиану балла
for i in 1 2 3 4 5; do
  lighthouse https://example.com/ --quiet --chrome-flags="--headless" \
    --output json --output-path "./run-$i.json"
  node -e "const r=require('./run-'+process.argv[1]+'.json');
    console.log(Math.round(r.categories.performance.score*100))" "$i"
done

Ограничение. curl не выполняет JavaScript, не строит DOM и не рисует пиксели. Он честно ответит на вопрос «быстро ли сервер отдаёт байты» и ничего не скажет про LCP, CLS и INP. Не подменяйте браузерный замер терминальным — они отвечают на разные вопросы.

География проверки, CDN и почему точка замера меняет цифры

Скорость сайта не абсолютна: она измеряется из конкретной точки планеты. Между Москвой и Франкфуртом порядка 40–60 мс в одну сторону, между Москвой и Западным побережьем США — заметно больше. Каждое сетевое рукопожатие умножает эту задержку.

Что из этого следует:

• PageSpeed Insights гоняет прогон из инфраструктуры Google, а не из вашего города. Для сайта с российской аудиторией лабораторная часть PSI даёт систематически иную сетевую картину, чем видят посетители. Полевая часть при этом корректна: она собрана там, где живут пользователи.
• WebPageTest и GTmetrix позволяют выбрать регион прогона. Это их сильная сторона: выбирайте локацию, максимально близкую к вашей реальной аудитории, и фиксируйте её навсегда, чтобы история была сравнимой.
• CDN превращает один сайт в много разных сайтов. Посетитель из Новосибирска и посетитель из Берлина попадают на разные узлы с разным состоянием кэша. Промах кэша на далёком узле означает поход до origin через полмира.
• Первый прогон после деплоя почти всегда медленный: кэш CDN пуст. Не делайте выводов по нему.

Проверить конкретный узел CDN и отделить его от origin можно, подменив разрешение имени:

# замер через конкретный IP (узел CDN или сам origin)
curl -s -o /dev/null \
  -w "ttfb %{time_starttransfer}s  total %{time_total}s\n" \
  --resolve example.com:443:203.0.113.10 \
  https://example.com/

# показать, попал ли запрос в кэш узла
curl -s -o /dev/null -D - https://example.com/assets/app.js \
  | grep -i -E 'age|x-cache|cf-cache-status|x-served-by|server-timing'

Заголовок age с ненулевым значением и статус попадания в кэш означают, что ответ пришёл с узла. Нули и постоянные промахи говорят, что кэширование настроено неправильно — тогда CDN добавляет лишний хоп и делает хуже.

Регулярность: тренд и алерт на регресс вместо разового прогона

Разовая проверка скорости почти бесполезна. Разброс между прогонами часто больше, чем эффект от аккуратной правки, а деградация приходит не одним обвалом, а десятком мелких шагов: новый скрипт чата, дополнительный пиксель, «временный» баннер, картинка, залитая маркетологом без сжатия.

Рабочая схема выглядит так:

• Синтетика по расписанию. Одна и та же страница, один и тот же профиль, несколько раз в сутки. Хранить историю. Цель — тренд, а не абсолютное число.
• Алерт на изменение, а не на порог. Порог «LCP больше 2,5 с» будет либо всегда молчать, либо всегда орать. Полезнее алерт «медиана за сутки ухудшилась больше чем на 20% относительно прошлой недели».
• Бюджет производительности. Заранее зафиксированные лимиты: вес страницы, число запросов, объём JS, TBT. Нарушение бюджета ломает сборку в CI — дешевле, чем чинить после релиза.
• Лабораторный прогон на каждый pull request. Lighthouse CLI из примера выше запускается в пайплайне на превью-окружении. Сравнивать нужно с базовой веткой, а не с абсолютным порогом.
• RUM как источник правды. Синтетика ловит регресс быстро, поле подтверждает, что регресс реален для людей. Как это устроено — в гайде по real user monitoring.
• Привязка к релизам. Отмечайте деплои на графике метрик. Тогда вопрос «когда сломалось» превращается в вопрос «какой релиз это сделал», а он решается за минуту.

Практика. Заводите отдельный монитор на каждый тип страницы: главная, категория, карточка товара, статья, форма оформления заказа. Они деградируют независимо, и общий средний показатель по сайту скрывает падение самой денежной страницы.

Что делать с результатом

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

• Высокий TTFB при лёгкой странице → сервер, база, отсутствие кэша, промах CDN. Проверить curl -w, дальше — диагностика нагрузки на сервер.
• Плохой LCP, а LCP-элемент — картинка → формат, размер, приоритет загрузки. Разбор в материале про оптимизацию изображений.
• Большой вес текстовых ресурсов → нет сжатия или сжимается не всё. См. gzip и brotli.
• Высокий TBT и плохой INP → JavaScript. Что именно делать — в разборе INP как метрики Core Web Vitals.
• Плавающий CLS → размеры медиа, поздние баннеры, подмена шрифта. Общий контекст — гайд по Core Web Vitals.
• Всё плохо и непонятно с чего начать → системный чек-лист в оптимизации скорости сайта; если сайт стал медленным внезапно — почему сайт долго загружается и как это чинить.
• Нужен полный свод метрик и порогов → гайд по Web Vitals.

Как проверить скорость сайта инструментами enterno.io

• Проверка скорости сайта — лабораторный прогон с разбивкой по метрикам и списком проблем. Точка входа: делаете три-пять прогонов, берёте медиану.
• Проверка HTTP-заголовков — есть ли сжатие, корректен ли cache-control, нет ли лишних редиректов и не отдаёт ли сервер статику без кэша.
• Анализ HAR-файла — выгружаете водопад из DevTools и разбираете его по запросам: кто блокирует рендер, где длинные цепочки, что весит больше всего.
• Скриншот страницы — как страница выглядит в момент загрузки для внешнего наблюдателя; помогает поймать невидимый текст из-за шрифта и пустой первый экран.
• Мониторинг сайта — регулярные проверки по расписанию и оповещения, когда метрика ухудшилась после релиза. Без этого шага все предыдущие превращаются в разовый ритуал.

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

Проверка скорости интернета и проверка скорости сайта — это одно и то же?

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

Почему PageSpeed Insights показывает 95, а сайт всё равно «тормозит»?

Скорее всего, вы смотрите на лабораторный балл, а жалобы касаются отзывчивости. Балл Lighthouse не включает INP — метрику реакции на действия пользователя. Тяжёлые обработчики событий и длинные задачи JavaScript могут делать интерфейс липким при отличном балле. Второй вариант: вы гоняете лёгкую главную, а тормозит каталог или личный кабинет. Откройте полевую часть отчёта: если там INP красный, дело в JavaScript.

Почему два прогона подряд дают разные баллы?

Это нормальный разброс. Он складывается из загруженности машины, на которой идёт прогон, симулированного троттлинга, ротации баннеров и A/B-тестов на вашем сайте, состояния кэша CDN и поведения сторонних доменов. Разница в 5–15 баллов между прогонами неизменной страницы — ожидаемая величина. Делайте не меньше пяти прогонов и берите медиану, а не последнее значение.

FID ещё нужно улучшать?

Нет. FID выведен из состава Core Web Vitals весной 2024 года, его место занял INP. FID измерял только задержку до начала обработки первого взаимодействия и был слишком снисходительным: страница могла иметь отличный FID и при этом заметно тормозить при каждом клике. INP смотрит на всё взаимодействие целиком и берёт худший случай за визит. Если ваш чек-лист или плагин до сих пор говорит про FID, он устарел.

Какая скорость загрузки сайта считается нормальной?

Правильнее говорить не про «время загрузки», а про конкретные метрики. Ориентиры: LCP до 2,5 с, INP до 200 мс, CLS до 0,1, TTFB до 0,8 с — по 75-му перцентилю реальных загрузок, отдельно для мобильных и десктопных пользователей. Единая цифра «страница должна грузиться за 3 секунды» ничего не означает: непонятно, чем измерено, на каком устройстве и до какого события.

Нужен ли платный инструмент проверки скорости?

Для разовой диагностики — нет: бесплатных возможностей PageSpeed Insights, Lighthouse в DevTools и WebPageTest хватает с запасом. Платить обычно начинают за две вещи: регулярность (прогоны по расписанию, длинная история, алерты) и полевые данные по собственной аудитории, которых нет в публичных наборах. Если вы делаете разовую оптимизацию — бесплатных инструментов достаточно; если поддерживаете сайт постоянно — нужен мониторинг.

Можно ли ориентироваться на балл при выборе подрядчика?

Осторожно. Балл легко накрутить локально: отключить сторонние скрипты для агента проверки, отдать облегчённую версию по User-Agent, спрятать тяжёлые блоки за взаимодействием. Проверять нужно по полевым Core Web Vitals в Search Console и по своему RUM — их накрутить нельзя, потому что они снимаются у реальных пользователей. Требуйте отчёт по LCP и INP за месяц, а не скриншот кружка.

Чеклист проверки скорости сайта

• Разделили лабораторные и полевые данные и понимаете, какой вопрос закрывает каждый источник.
• Смотрите LCP, INP и CLS, а не только итоговый балл; знаете, что INP пришёл на смену FID.
• Меряете не меньше пяти прогонов и берёте медиану, а не последнее значение.
• Профиль замера зафиксирован: устройство, троттлинг, регион, один и тот же URL.
• Мобильные и десктопные результаты не смешиваете.
• Прогон идёт с холодным кэшем, в чистом профиле браузера, на продакшен-сборке, без залогиненного администратора.
• TTFB измерен отдельно через curl -w, и вы отделяете сетевую задержку от времени генерации ответа.
• Проверили, что текстовые ресурсы отдаются сжатыми, а у статики корректный cache-control.
• Регион прогона соответствует реальной географии аудитории; для сайта за CDN проверено попадание в кэш узла.
• Настроен регулярный мониторинг с алертом на ухудшение относительно прошлой недели, а не на абсолютный порог.
• Мониторится не одна главная, а каждый ключевой тип страницы.
• Результаты привязаны к релизам, чтобы искать причину регресса за минуту, а не за день.