Чем мерить скорость сайта: пять инструментов и что они недоговаривают

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

Владелец сайта хочет понять, как измерить скорость загрузки сайта, открывает PageSpeed Insights, видит зелёные 92 и успокаивается. Через неделю клиент пишет: «у вас страница открывается вечность». Оба правы, просто мерили разное и на разном железе. Ниже разбираю пять инструментов, которыми пользуюсь сам, что каждый честно показывает, о чём молчит, и какие пять чисел надо записать до работ по ускорению и после, чтобы разговор с подрядчиком был про факты, а не про ощущения.

Сразу оговорка: единственного правильного числа не существует. Скорость сайта это не одна цифра, а распределение. У одного посетителя с новым айфоном и оптикой страница отрисуется за 900 мс, у другого с бюджетным андроидом в метро с 3G та же страница будет собираться 6 секунд. Инструменты меряют разные точки этого распределения, поэтому и расходятся.

Лаборатория против поля: главная причина расхождений

Все замеры делятся на два типа, и путаница между ними даёт больше половины споров про скорость.

Лабораторные данные (lab data). Один синтетический прогон в контролируемых условиях: конкретный браузер, конкретный канал, конкретное железо, чистый кэш. PageSpeed Insights, WebPageTest, Lighthouse в DevTools. Плюс: воспроизводимо, можно сравнить до и после правки. Минус: это один посетитель, которого не существует в природе.

Полевые данные (field data, RUM). Реальные пользователи, реальные устройства, реальные сети. Яндекс Метрика, отчёт CrUX внутри PageSpeed, свои метрики через web-vitals. Плюс: правда о том, что видят люди. Минус: набирается неделями, на трафике в 30 человек в день статистики почти нет.

Типовой сюжет: лаборатория рисует 92 балла, потому что тест шёл из дата-центра во Франкфурте по гигабитному каналу, а половина ваших посетителей сидит в Иркутске с телефона за 12 тысяч рублей. Обратный сюжет тоже бывает: лаборатория показывает 34, а люди не жалуются, потому что 80 процентов трафика это возвраты с прогретым кэшем.

Правило, которое я применяю у себя: решение о том, что чинить, принимается по полевым данным. Проверка, что починка сработала, делается в лаборатории. Наоборот не работает.

Если базовые термины LCP, INP и CLS пока звучат как шум, начните с разбора Core Web Vitals простыми словами, дальше будет понятнее.

PageSpeed Insights: что смотреть кроме общего балла

PSI это самый популярный и самый неправильно читаемый инструмент. Общий балл вверху страницы виден всем, и почти все останавливаются на нём. Балл считается по взвешенной формуле из пяти лабораторных метрик, вес перераспределяется от версии к версии Lighthouse, поэтому сравнивать балл, снятый в марте, с баллом, снятым в октябре, бессмысленно.

Что смотреть на самом деле, по порядку сверху вниз:

1. Блок «Данные о фактическом использовании» (CrUX). Если он есть, это ваши реальные посетители за 28 дней. Если его нет, значит трафика мало и Google не набрал выборку. Этот блок важнее всего остального на странице.
2. LCP. Самый крупный видимый элемент. Обычно это баннер на первом экране или заголовок H1. Цель до 2,5 секунды на мобильном.
3. INP. Отзывчивость на клик. Цель до 200 мс. Метрика заменила FID в 2024 году и ловит совсем другие проблемы: тяжёлые обработчики, длинные задачи JS, лишние виджеты.
4. CLS. Прыжки вёрстки. Цель до 0,1. Виноваты картинки без размеров, поздние шрифты, баннеры, которые вставляются скриптом.
5. Раздел «Диагностика». Здесь конкретика: сколько весит JS, какие ресурсы блокируют отрисовку, сколько времени ушло на ответ сервера.

Отдельно про поле «Время ответа сервера» в диагностике. Это TTFB, и если он больше 600 мс, дальнейшая борьба за LCP почти бесполезна: браузер полсекунды просто ждёт первый байт. Про то, откуда берётся такая задержка и что с ней делать на дешёвом хостинге, есть отдельный текст: TTFB больше 600 мс на shared-хостинге.

Важная особенность PSI, о которой не пишут в интерфейсе: мобильный прогон эмулирует Moto G Power с четырёхкратным замедлением процессора и каналом 1,6 Мбит/с с задержкой 150 мс. Это сознательно пессимистичный сценарий. Он не про среднего посетителя, он про нижнюю четверть аудитории. Именно поэтому мобильный балл всегда сильно ниже десктопного, и гоняться за зелёной зоной на мобильном для сайта на WordPress с двумя десятками плагинов занятие дорогое. Если у вас там 30 баллов и хочется понять, что вообще исправимо за разумные деньги, я разбирал этот случай в статье про PageSpeed Insights и 30 баллов.

Ещё одна ловушка: PSI меряет одну страницу. Главная может быть быстрой, а карточка товара с галереей и отзывами вдвое тяжелее. Прогоняйте минимум четыре типа страниц: главную, страницу услуги или категории, карточку товара или статью, страницу контактов с картой.

Отчёт по скорости в Яндекс Метрике: ваши реальные посетители

Для российского сайта Метрика важнее PSI, потому что показывает не эмуляцию, а фактические тайминги вашей аудитории. Отчёт лежит в разделе Мониторинг, называется «Время загрузки страниц». Там есть переключатель между медианой и перцентилями, и это ключевая настройка.

Смотрите на 75-й перцентиль, а не на среднее. Среднее арифметическое по таймингам врёт всегда: несколько посетителей с мёртвым интернетом и тайм-аутом в 30 секунд утягивают среднее вверх, а один и тот же показатель может улучшиться на бумаге просто потому, что в этом месяце было меньше заходов из деревни. Медиана и 75-й перцентиль устойчивы к выбросам, а порог «хорошо» в Core Web Vitals определён именно по 75-му перцентилю.

Что даёт Метрика такого, чего не даёт никто:

• разбивку по устройствам (телефон, планшет, десктоп) и по конкретным моделям,
• разбивку по регионам, что критично, если у вас клиенты за Уралом, а сервер в Москве,
• разбивку по источникам трафика: реклама часто приводит людей на тяжёлые посадочные с UTM-скриптами,
• динамику по дням, чтобы увидеть, когда именно всё сломалось.

Последний пункт стоит отдельного внимания. Когда клиент говорит «сайт стал тормозить», первое, что я делаю, это открываю график за 90 дней и ищу ступеньку. Если время загрузки скакнуло с 1,8 до 4,2 секунды в конкретный четверг, дальше вопрос простой: что делали в четверг. Обычно обновляли плагин, ставили виджет чата или включали новый пиксель.

Осторожно с самим счётчиком Метрики: он умеет замедлять сайт, если подключён неправильно. Синхронная вставка в head без defer плюс включённый Вебвизор на тяжёлой странице легко добавляют 200-400 мс к отрисовке. Проверяется это в водопаде WebPageTest: смотрите, где в цепочке стоит запрос к mc.yandex.ru и что он блокирует.

WebPageTest и водопад загрузки: как читать без специальных знаний

WebPageTest даёт то, чего нет ни в PSI, ни в Метрике: покадровое видео загрузки и водопад со всеми запросами. Бесплатной версии хватает, регистрация нужна для выбора точек тестирования.

Настройки, которые я ставлю для российского сайта:

• Test Location: ближайшая доступная точка (Frankfurt или Istanbul, российских точек в публичном WPT нет),
• Browser: Chrome,
• Connection: 4G или Cable, в зависимости от того, какой сценарий проверяем,
• Number of Tests to Run: 3, берём медианный прогон,
• Repeat View: включить, чтобы увидеть повторный заход с прогретым кэшем.

Водопад читается проще, чем кажется. Каждая строка это один запрос, длина полосы это время. Смотреть надо на три вещи.

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

Длинный первый прямоугольник. Первая строка водопада это HTML-документ. Если у неё большая зелёная часть (Time to First Byte), проблема на сервере, а не в вёрстке.

Толстые полосы внизу. Обычно это картинки в оригинальном разрешении и шрифты. Картинка на 2,4 МБ в шапке видна на водопаде сразу.

Отдельно полезен Repeat View. Если повторный заход быстрее первого в три раза, кэширование работает. Если разница минимальная, значит заголовки Cache-Control не выставлены и каждый посетитель качает всё заново.

Ещё в WebPageTest есть вкладка Content Breakdown: круговая диаграмма по типам ресурсов в килобайтах. Быстрый способ увидеть, что 70 процентов веса страницы это JS от четырёх виджетов.

DevTools: смотрим глазами клиента, у которого дешёвый телефон

Инструмент, который стоит ноль рублей и стоит на каждом компьютере. Открывается по F12 в Chrome. Мне он нужен для одной задачи: воспроизвести условия жалующегося посетителя.

Порядок действий:

1. Вкладка Network, галочка Disable cache (иначе меряете свой кэш, а не загрузку).
2. Выпадающий список троттлинга: выбрать Slow 4G. Fast 4G для сайта в райцентре слишком оптимистично.
3. Вкладка Performance, шестерёнка, CPU: 4x slowdown или 6x slowdown. Это моделирует бюджетный андроид.
4. Ctrl+Shift+M включает эмуляцию мобильного устройства, там же выбирается модель и разрешение.
5. Перезагрузить страницу с записью профиля и посмотреть Long Tasks в таймлайне.

Что искать в профиле Performance: красные треугольники на длинных задачах. Каждая задача дольше 50 мс блокирует интерфейс. Если после клика по кнопке меню идёт задача на 400 мс, посетитель воспринимает это как зависание. Именно такие вещи ловит INP, и внешний тест их часто пропускает, потому что там никто ни на что не кликает.

Полезный трюк для поиска виноватого скрипта: во вкладке Network отсортировать по колонке Time, посмотреть верхние пять строк, потом отсортировать по Size. Обычно виноватые находятся в одном из двух списков. Если подозрение падает на конкретное расширение CMS, дальше идёт точечная проверка отключением, про это есть отдельный разбор: какой плагин тормозит сайт.

Логи сервера: число, которого не видит ни один внешний сервис

Все инструменты выше меряют снаружи: браузер отправил запрос, дождался ответа. Но внутри этого ожидания сидит время генерации страницы движком, и его видно только в логах.

На Apache добавляется через LogFormat директиву %D (время обработки в микросекундах). Для nginx это $request_time и $upstream_response_time. Пример конфига для nginx:

log_format timed '$remote_addr - $request_time $upstream_response_time '
                 '"$request" $status $body_bytes_sent';

access_log /var/log/nginx/saitfix-timed.log timed;

Дальше по логу считается медиана и хвост. Быстрая прикидка топ-20 самых медленных URL прямо на сервере:

awk '{print $4, $7}' /var/log/nginx/saitfix-timed.log 
  | sort -rn | head -20

# среднее время генерации по всему логу
awk '{s+=$4; n++} END {print "avg:", s/n, "sec, requests:", n}' 
  /var/log/nginx/saitfix-timed.log

Если доступа к логам nginx нет (типовой shared-хостинг), время ответа снимается снаружи через curl. Это не так точно, зато работает везде:

curl -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} 
tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}n" 
  https://example.ru/

# десять замеров подряд, чтобы увидеть разброс
for i in $(seq 1 10); do
  curl -o /dev/null -s -w "%{time_starttransfer}n" https://example.ru/
done

Разброс здесь важнее среднего. Если десять прогонов дают 0,3 / 0,3 / 0,3 / 2,8 / 0,3, значит на хостинге кто-то периодически съедает CPU, и никакая оптимизация картинок эту проблему не лечит. У меня был клиент на популярном дешёвом тарифе, где раз в четыре минуты TTFB прыгал до трёх секунд: соседний аккаунт на той же машине крутил парсер. Переезд на изолированный тариф за 900 рублей в месяц решил то, чего не решили две недели правок кода.

Для WordPress отдельно полезен Query Monitor: показывает количество SQL-запросов, время их выполнения и какой плагин их породил. Норма для страницы: 30-80 запросов. Если видите 400 запросов на карточке товара, дело не в скорости сети.

Сводная таблица: кто что показывает

Инструмент	Тип данных	Что показывает лучше всех	Чего не видит
PageSpeed Insights	лаборатория + CrUX	сводку по Core Web Vitals и список конкретных проблем	вашу реальную аудиторию, если трафика мало
Яндекс Метрика	поле	тайминги живых посетителей по регионам и устройствам	причину замедления, только факт
WebPageTest	лаборатория	водопад, цепочки запросов, повторный заход с кэшем	поведение реальных пользователей
DevTools	лаборатория, локально	длинные задачи JS, отзывчивость, отладку в реальном времени	статистику, это всегда один прогон
Логи и curl	сервер	время генерации страницы и разброс между запросами	всё, что происходит в браузере

Ни один из пяти не заменяет остальные. Но если выбирать два, я беру Метрику (что видят люди) и логи (сколько думает сервер). PSI при этом остаётся отчётным документом для разговора, потому что его цифры понятны всем сторонам.

Пять чисел, которые надо записать до работ и после

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

1. LCP на мобильном, 75-й перцентиль, поле. Берётся из CrUX в PSI или из Метрики. Главное число для SEO и для ощущения «долго грузится».
2. INP на мобильном, 75-й перцентиль. Показывает, залипает ли интерфейс. Замена FID, которая ловит совсем другие проблемы.
3. TTFB, медиана из 10 прогонов curl. Отделяет проблемы сервера от проблем вёрстки.
4. Вес страницы в килобайтах и число запросов. Снимается в DevTools или WebPageTest. Это то, что режется быстрее всего.
5. Число SQL-запросов на типовую страницу. Query Monitor для WordPress, отладочная панель для Битрикса.

Условия замера фиксируются жёстко, иначе сравнение бессмысленно: одна и та же страница, одно и то же время суток (не в пик), тот же инструмент, та же версия, кэш очищен. Я обычно делаю замеры во вторник утром до и через две недели, тоже во вторник утром.

Чек-лист перед тем, как нести цифры подрядчику:

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

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

Чего не стоит делать с этими цифрами

Пара вещей, которые вижу регулярно и считаю вредными.

Гнаться за 100 баллами. Балл PSI это не бизнес-метрика. Сайт с 78 баллами и LCP в 2,1 секунды работает лучше, чем сайт с 94 баллами и LCP в 3,4 секунды, потому что балл усредняет пять метрик с весами, а посетитель ждёт именно картинку на первом экране. Стоимость подъёма с 85 до 95 обычно выше стоимости подъёма с 35 до 75, а эффект для выручки меньше.

Мерить один раз. Один прогон PSI это одна точка с погрешностью в 5-10 баллов. Гоняйте три раза и берите медиану, иначе будете ловить шум и радоваться несуществующим улучшениям.

Сравнивать себя с Яндексом. У крупных порталов свои CDN, свои дата-центры и команды из полусотни человек. Ориентир для малого бизнеса это конкуренты в вашей выдаче, а не техногиганты. Прогоните пять сайтов из топ-10 по своему запросу через PSI и посмотрите, где вы среди них.

Верить в один плагин-ускоритель. Кэширующий плагин снимает нагрузку с сервера и часто даёт заметный прирост TTFB. Но если у вас на странице 4 МБ картинок и восемь сторонних скриптов, кэш не поможет: браузер всё равно будет качать эти мегабайты.

Что делать дальше

Если вы дочитали до этого места, план на ближайший час выглядит так. Открыть PSI, прогнать четыре типа страниц, выписать LCP и INP из блока с фактическими данными. Открыть Метрику, отчёт по времени загрузки, посмотреть 75-й перцентиль отдельно по мобильным. Сделать десять прогонов curl и посмотреть на разброс TTFB. Записать пять чисел в файл с датой. Этого достаточно, чтобы понять, есть ли проблема вообще, и в какой части системы она сидит.

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

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

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

Чем измерить скорость сайта

PageSpeed Insights для лабораторного замера и подсказок, отчёт по скорости в Яндекс Метрике для данных реальных посетителей, инструменты разработчика для разбора конкретной страницы, лог сервера для времени ответа.

Почему PageSpeed показывает одно, а люди жалуются на другое

Потому что инструмент мерит на своей эмуляции устройства и сети, а посетители сидят на своих. Балл 92 при половине аудитории на дешёвых телефонах в мобильной сети ничего не гарантирует.

На какие цифры смотреть

На время до первого байта, LCP, CLS и INP, и обязательно на данные за последние 28 дней у реальных посетителей. Общий балл удобен для отчёта, но по нему нельзя понять, что чинить.

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

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