Как проверить скорость сайта: PageSpeed, GTmetrix и Вебмастер дают три разные цифры

Проверить скорость сайта тремя сервисами — и получить три разные цифры по одной и той же странице. PageSpeed, GTmetrix и Вебмастер при этом честны все трое. Владелец открывает PageSpeed Insights, видит 90 на десктопе, радуется. Открывает GTmetrix — 62 и красная буква C. Заходит в Яндекс.Вебмастер, а там раздел «Скорость сайта» спокойно сообщает: «медленно». Дальше начинается самое дорогое — попытки «поднять баллы», которые не меняют ничего для живого посетителя.

Расхождение возникает не из-за того, что кто-то врёт. Сервисы измеряют разные вещи, на разном железе, из разных точек мира и в разные моменты времени. Пока вы не понимаете, что именно стоит за каждой цифрой, вы будете чинить не то. Ниже — механика расхождения, разбор каждого инструмента и рабочий протокол замера, которым я пользуюсь на проектах с 2005 года. Если после разбора станет ясно, что сайт правда тормозит и это стоит вам заявок, приходите — я занимаюсь этим предметно, и SEO-продвижение сайта в Яндексе начинается ровно с такой технической ревизии.

Три сервиса, три цифры — и все три честные

Скорость сайта — это не одно число. Это распределение. У одной и той же страницы есть время загрузки для человека с iPhone 15 на городском Wi-Fi, для человека с бюджетным Android на LTE в области и для робота, который зашёл с дата-центра в двух километрах от вашего сервера. Разброс между этими сценариями легко достигает пяти-шести раз.

Любой сервис измерения делает одно из двух: либо сам открывает вашу страницу в контролируемых условиях и засекает время (это лабораторный замер), либо собирает статистику по тому, как страница грузилась у реальных людей (это полевые данные). Первое — воспроизводимый эксперимент, второе — правда о вашей аудитории. Эти две вещи почти никогда не совпадают, и в этом нет ошибки.

Классическая картина, из-за которой владельцы и приходят с вопросом «кому верить»:

• PageSpeed Insights, десктоп: 90–95. Google прогнал вашу страницу на эмуляции мощного десктопа с быстрым каналом. Ничего не мешало.
• PageSpeed Insights, мобильные: 45–60. Тот же самый URL, но эмулируется слабый телефон с искусственно замедленным процессором и каналом уровня медленного 4G. Разница в 40 баллов между вкладками — норма, а не баг.
• GTmetrix: 62. Тест шёл из другого города и другой страны, с другим набором настроек по умолчанию, и сетевая задержка до вашего сервера была втрое больше.
• Яндекс.Вебмастер: «медленно». А здесь вообще нет тестового прогона. Здесь агрегированные данные о реальных визитах на ваш сайт — и это совсем другой жанр.

Первый вывод, который экономит недели: сравнивать баллы разных сервисов между собой бессмысленно. Сравнивать имеет смысл только один сервис с самим собой во времени — было 62, стало 78 после конкретной правки.

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

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

Полевые данные (field data) — это телеметрия с реальных браузеров. У Google такой набор называется CrUX (Chrome User Experience Report): анонимная статистика от пользователей Chrome, которые включили синхронизацию и не отключили отправку статистики. Считается скользящее окно за 28 дней, и показывается не среднее, а 75-й процентиль — то есть значение, лучше которого оказались 75% визитов. Плюс: это правда о вашей аудитории. Минусы: данные запаздывают почти на месяц, показываются только при достаточном трафике, и учитывают только Chrome — то есть Safari на айфонах, Яндекс.Браузер и Firefox туда не попадают.

Отсюда самая частая путаница в PageSpeed Insights. Наверху отчёта — блок «Оценка реального пользовательского опыта» (это CrUX, полевые). Ниже — «Диагностика» с большим цветным числом от 0 до 100 (это Lighthouse, лабораторные). Люди смотрят на цветное число, потому что оно крупнее, а решения по ранжированию Google принимает на основании верхнего блока. Если верхнего блока у вас нет вовсе — значит, трафика мало, и Google просто не набрал статистики по вашему домену.

Ещё одна ловушка: если полевого блока по конкретному URL нет, PageSpeed может показать данные по всему домену (origin). Вы смотрите на цифры главной, думая, что смотрите на карточку товара. Проверяйте подпись над графиками.

Что меряет каждый сервис: сравнение

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

Параметр	PageSpeed Insights	GTmetrix	WebPageTest	Яндекс.Вебмастер
Тип данных	И лабораторные (Lighthouse), и полевые (CrUX)	Только лабораторные	Только лабораторные	Только полевые
Что показывает по сути	Балл 0–100 + реальные Core Web Vitals за 28 дней	Grade A–F, детальный водопад и структура страницы	Тайминги, видео загрузки, повторный прогон с кэшем	Как быстро сайт открывался у живых посетителей
Откуда тестирует	Дата-центры Google, точку не выбрать	По умолчанию Канада, регион меняется в настройках	Десятки локаций и реальные устройства на выбор	Не тестирует, собирает статистику
Мобильные	Жёсткая эмуляция слабого телефона и медленного канала	Эмуляция устройств доступна в настройках	Есть реальные телефоны в ряде локаций	Разделение на десктоп и мобильные визиты
Учитывает ли аудиторию из РФ	Нет: только Chrome, преимущественно зарубежные точки	Нет, если не выбрать ближайший регион	Да, если выбрать релевантную локацию	Да, это его главное преимущество
Годится для отчёта клиенту	Да, полевой блок — как основной показатель	Да, водопад — как доказательство причины	Скорее для диагностики, чем для отчёта	Да, для проектов под Яндекс — обязателен
Главный риск неверной трактовки	Смотрят на балл вместо полевых метрик	Тестируют из-за океана и пугаются задержки	Утонуть в деталях и не сделать вывод	Ждут «баллов», а там качественная оценка

Практический вывод из таблицы: инструменты не конкуренты, у каждого своя роль. PageSpeed отвечает на вопрос «есть ли проблема у реальных пользователей». GTmetrix и WebPageTest отвечают на вопрос «где именно она в коде». Вебмастер отвечает на вопрос «видит ли эту проблему Яндекс».

Откуда берётся оценка в Яндекс.Вебмастере и почему она про другое

Раздел «Скорость сайта» в Яндекс.Вебмастере не запускает никаких тестов. Он показывает агрегированную статистику по тому, как ваши страницы открывались у реальных пользователей — на основании данных браузера. Поэтому там нет ни баллов Lighthouse, ни Core Web Vitals в привычном виде, а есть распределение визитов по категориям и разбивка по типам устройств и по группам страниц.

Три следствия, о которых нужно помнить:

1. Данные накапливаются. Вы ускорили сайт вчера — раздел покажет улучшение через недели, когда наберётся новая статистика. Не паникуйте на третий день.
2. Аудитория российская. Если ваш хостинг за границей, Вебмастер увидит именно ту задержку, которую видит клиент из Новосибирска, а не ту, которую видит сервер Google. Это самый честный источник для проектов под Яндекс.
3. Порог там не про баллы. Яндекс интересует, дожидается ли человек контента. Отдельного «рейтинга скорости» в ранжировании нет, но есть поведенческие последствия: ушёл до загрузки — плохой сигнал. Механику я подробно разбирал в материале медленный сайт = низкие позиции.

Отдельно про источник задержки. Если Вебмастер говорит «медленно», а лабораторные тесты дают приличные цифры, почти всегда проблема в ответе сервера для российских посетителей: время до первого байта. Это не картинки и не скрипты, это инфраструктура. Диагностика — в разборе куда исчезает секунда до первого байта.

Почему один и тот же сервис даёт 90 и 62 в двух прогонах подряд

Это отдельный источник паники: человек жмёт «Проверить» три раза и получает три разных числа. Причины конкретные и все воспроизводимые.

Фактор	Что происходит технически	Разброс баллов	Как исключить
География тестового сервера	Каждый километр — задержка. Тест из Ванкувера до сервера в Москве даёт 150–250 мс на каждый round trip	10–25	Выбрать локацию ближе к аудитории или тестировать из нескольких точек
Прогрев кэша на сервере	Первый запрос собирает страницу с нуля: PHP, база, шаблон. Второй отдаёт готовый HTML из кэша	15–40	Прогнать дважды, брать второй результат как «горячий», первый как «холодный»
Нагрузка на сервер измерения	Виртуалка сервиса делит процессор с чужими тестами. В час пик она медленнее	5–15	Три прогона, брать медиану, а не лучший результат
Сторонние скрипты	Метрика, чат, пиксели, шрифты — загружаются с чужих серверов, которые тормозят непредсказуемо	5–20	Смотреть водопад: чей домен занял время
Версия страницы для бота	Плагины кэша и оптимизаторы отдают ботам отдельную версию, «облегчённый» вариант или наоборот некэшированный	10–30	Сравнить исходный код, полученный вашим браузером и curl с чужим User-Agent
Реклама и A/B-тесты	Разным сессиям отдаётся разный набор блоков	5–15	Тестировать страницу без рекламных вставок отдельно

Пункт про версию страницы для бота недооценивают чаще всего. У сайтов на WordPress с агрессивным кэшированием тестовый робот регулярно получает не тот HTML, который получает человек: страница либо ещё не попала в кэш, либо, наоборот, была собрана специально для «неизвестного» посетителя. Отсюда абсурдные ситуации, когда сервис измерения хвалит страницу, а живой пользователь ждёт четыре секунды. Что именно происходит с кэшем и почему вы с роботом видите разные версии — в материале про кэш в WordPress и старую страницу.

Что реально влияет на ранжирование, а что косметика

Балл Lighthouse от 0 до 100 — это не сигнал ранжирования. Ни Google, ни Яндекс не используют его в формуле. Это сводная оценка, которую придумали, чтобы разработчику было понятно, куда смотреть. В ранжировании Google участвуют три конкретные метрики Core Web Vitals, и берутся они из полевых данных, а не из лабораторного прогона.

Метрика	Что измеряет простыми словами	Хорошо	Требует улучшений	Плохо
LCP (Largest Contentful Paint)	Когда прорисовался самый крупный блок первого экрана — обычно баннер, фото или заголовок	до 2,5 с	2,5–4,0 с	больше 4,0 с
INP (Interaction to Next Paint)	Через сколько страница видимо реагирует на клик или тап. С марта 2024 заменил FID	до 200 мс	200–500 мс	больше 500 мс
CLS (Cumulative Layout Shift)	Насколько прыгает вёрстка во время загрузки: человек метит в кнопку, а попадает в рекламу	до 0,1	0,1–0,25	больше 0,25

А вот метрики, которые видно в отчётах, но которые сами по себе на позиции не влияют: FCP, Speed Index, Total Blocking Time, «количество запросов», «вес страницы» в мегабайтах, буквенный grade GTmetrix. Они полезны как индикаторы причины — например, высокий TBT почти всегда означает тяжёлый JavaScript и предсказывает плохой INP. Но требовать «сделай 100 из 100» — это платить за косметику.

Теперь про главное заблуждение. «100 из 100» в лабораторном прогоне не гарантирует быстрый сайт для реального посетителя из региона. Lighthouse тестирует одну страницу, один раз, с холодным кэшем, из дата-центра Google, без рекламы, без вашей CRM-виджета и без нагрузки на ваш сервер. Живой пользователь из Красноярска в 19:00 открывает ту же страницу, когда на сервере одновременно сидят ещё двести человек, канал у него мобильный, а между ним и вашим хостингом — половина страны. Три из трёх Core Web Vitals могут быть в красной зоне при идеальном лабораторном балле. Обратное тоже верно: балл 55 при зелёных полевых метриках означает, что чинить нечего. Подробнее логику расхождения я разбирал в статье почему привычная «скорость загрузки» вводит в заблуждение и в материале про Core Web Vitals как скрытую причину застоя в позициях.

Когда цифра не важна

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

Сайт услуг на 20 страниц с трафиком 50 человек в день. Что здесь происходит на самом деле:

• Полевых данных у вас просто нет. CrUX собирает статистику только при достаточном объёме визитов. При 50 посещениях в сутки, из которых Chrome с включённой телеметрией — дай бог половина, порог не набирается. В PageSpeed вы увидите пустой верхний блок и будете смотреть исключительно на лабораторный балл, который в ранжировании не участвует.
• Core Web Vitals — тайбрейкер, а не драйвер. Скорость влияет на позиции тогда, когда всё остальное у конкурентов равно. В нише из десяти сайтов услуг по городу решают релевантность страницы, коммерческие факторы, отзывы и ссылочный профиль. Ускорение с 3,1 до 2,4 секунды не переставит вас с восьмого места на третье.
• Экономика не сходится. Переезд на быстрый хостинг, переработка шаблона и вынос критического CSS — это десятки часов. При 50 визитах в день прирост конверсии от ускорения на полсекунды измеряется долями заявки в месяц. Те же часы, вложенные в две новые посадочные страницы под коммерческие запросы, дадут кратно больше.

Где цифра действительно важна: интернет-магазины (там каждая десятая секунды видна в корзине), сайты с мобильным трафиком больше 60%, проекты с рекламой, где вы платите за клик и теряете человека до загрузки, крупные каталоги, где скорость влияет на обход роботом. И отдельный случай — если сайт грузится больше 4–5 секунд. Это уже не оптимизация, а поломка, и её чинят при любом трафике.

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

Как измерить свой сайт правильно: рабочий протокол

Один клик по кнопке «Проверить» — это не измерение, это лотерея. Протокол, который даёт воспроизводимый результат, занимает 20 минут.

1. Выберите три страницы, а не одну. Главная, типовая внутренняя (услуга или карточка товара) и самая тяжёлая — обычно каталог или страница с галереей. Главная почти всегда оптимизирована лучше остальных и врёт про состояние сайта.
2. Сделайте по три прогона каждой страницы. Берите медиану, а не лучший и не худший результат. Разброс между прогонами сам по себе диагностичен: если он больше 20 баллов, у вас проблема с сервером или с кэшем, а не с фронтендом.
3. Меряйте в разное время суток. Утром, в районе обеда и вечером в 19:00–21:00, когда на хостинге пик. Если вечерние цифры заметно хуже, дело в нагрузке на сервер или в соседях по shared-хостингу.
4. Мобильный и десктоп — раздельно. Всегда. И решения принимайте по мобильной вкладке, если у вас больше половины трафика с телефонов. Что видит робот на мобильном, я разбирал в материале про mobile-first и взгляд робота с телефона.
5. Холодный и прогретый кэш — два отдельных замера. Первый прогон после сброса кэша показывает, что видит человек, пришедший на редкую страницу. Второй показывает, что видит человек на популярной. Разница между ними — цена вашей серверной генерации.
6. Проверьте, что робот видит ту же страницу. Откройте страницу в браузере, посмотрите исходный код, затем сделайте curl -A "Mozilla/5.0 (compatible; Googlebot/2.1)" https://ваш-сайт.ру/страница/ и сравните размер и структуру. Расхождения означают, что все ваши замеры описывают не тот HTML.
7. Зафиксируйте результат до правок. Табличка с датой, страницей, устройством, баллом и LCP. Без неё вы не докажете эффект работы ни себе, ни клиенту.

Как читать «водопад» загрузки

Водопад (waterfall) — это диаграмма всех запросов страницы в порядке их выполнения. Каждая полоска — один файл: HTML, CSS, картинка, шрифт, скрипт. Длина полоски — время, отступ слева — момент старта. Именно здесь видно настоящую причину, а не её симптом.

На что смотреть по порядку:

• Первая полоска — ваш HTML. Её тёмная часть — это ожидание ответа сервера. Если она занимает больше 600 мс, вся дальнейшая оптимизация картинок бессмысленна: вы уже потеряли полсекунды до того, как браузер увидел хоть один тег.
• Ступенька после HTML. Если ресурсы стартуют не сразу, а «лесенкой» по три-четыре, значит браузер обнаруживает их только после разбора предыдущих. Это признак цепочки зависимостей: шрифт подключается из CSS, который подключается из другого CSS.
• Длинные полоски картинок. Смотрите на вес. Фотография первого экрана на 1,2 МБ — это почти всегда и есть ваш плохой LCP. Что с этим делать, я расписал в разборе про картинки, WebP и отложенную загрузку. И там же важное предупреждение: ленивая загрузка, накинутая на изображение первого экрана, ухудшает LCP вместо того, чтобы улучшать его.
• Чужие домены. Отсортируйте запросы по хосту. Виджет чата, две системы аналитики, пиксель рекламной сети, карта и шрифты Google — каждый из них добавляет отдельное соединение с рукопожатием. Часто половина времени загрузки принадлежит не вашему сайту.
• Красные и жёлтые статусы. Редиректы внутри водопада — это удвоенное время на каждый ресурс. Особенно больно, когда в цепочку попадает сам HTML.
• Хвост после отрисовки. Всё, что грузится после того, как страница уже показана, на LCP не влияет, но влияет на INP: тяжёлый JS занимает основной поток и страница «залипает» на клик.

Если водопад плотно забит запросами от плагинов и билдера, а не вашим контентом — типичная ситуация для сайтов на конструкторах и визуальных редакторах. Механику я разбирал на примере Elementor и шести секунд загрузки. Если же водопад чистый, а сайт всё равно тормозит, причина почти наверняка на сервере — об этом материал почему WordPress тормозит не из-за плагинов.

Коротко

• Три сервиса дают три цифры, потому что меряют разные вещи: PageSpeed и GTmetrix запускают синтетический прогон, Вебмастер показывает статистику реальных визитов.
• Балл Lighthouse от 0 до 100 не участвует в ранжировании. В ранжировании участвуют полевые LCP, INP и CLS за 28-дневное окно.
• Пороги: LCP до 2,5 с, INP до 200 мс, CLS до 0,1. Оценивается 75-й процентиль, то есть три четверти визитов должны укладываться.
• Разница между мобильной и десктопной вкладкой PageSpeed в 30–40 баллов — норма: мобильная эмулирует слабый телефон и медленный канал.
• Яндекс.Вебмастер — единственный из четырёх, кто видит вашу российскую аудиторию. Для проектов под Яндекс он важнее лабораторных баллов.
• Цифры прыгают из-за географии теста, прогрева кэша, чужих скриптов и того, что роботу отдаётся не та версия страницы. Лечится тремя прогонами и медианой.
• Сайт услуг на 20 страниц с трафиком 50 человек в день не получит роста от ускорения на полсекунды — там решают релевантность и коммерческие факторы.
• Начинать ускорение нужно с ответа сервера и картинок первого экрана, а не с минификации CSS.

Чеклист: с чего начинать, если баллы низкие

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

Шаг	Что проверить	Признак проблемы	Что делать	Влияет на
1	Ответ сервера (TTFB)	Тёмная часть первой полоски водопада больше 600 мс	Включить кэш страниц, поднять версию PHP, сменить тариф или хостинг	LCP, всё остальное
2	Картинка первого экрана	Баннер весит больше 200 КБ или грузится с задержкой	Сжать, отдать в WebP, задать точные размеры, снять с неё lazy-load	LCP, CLS
3	Прыгающая вёрстка	CLS выше 0,1, контент дёргается при загрузке	Прописать width и height у картинок и рекламных мест, зарезервировать высоту баннеров	CLS
4	Сторонние скрипты	В водопаде чужих доменов больше пяти	Убрать дубли аналитики, отложить чат и карты до взаимодействия	INP, LCP
5	Шрифты	Текст появляется с задержкой или подменяется на лету	Положить шрифты локально, ограничить набор начертаний, задать font-display	LCP, CLS
6	JavaScript темы и плагинов	Total Blocking Time выше 300 мс	Отключить неиспользуемые плагины, убрать скрипты со страниц, где они не нужны	INP
7	Критический CSS	Стили блокируют отрисовку первого экрана	Вынести стили первого экрана инлайном, остальное подгружать асинхронно	LCP
8	Повторный замер	—	Прогнать протокол из трёх замеров заново и сравнить с зафиксированной таблицей «до»	Доказательство результата

И последнее. Прежде чем платить за оптимизацию, потратьте двадцать минут на протокол выше. В половине случаев выясняется, что сайт работает нормально, а страшная цифра пришла из теста, который шёл через полмира на эмуляции бюджетного смартфона. В другой половине становится видно, что проблема одна и конкретная — обычно сервер или один тяжёлый файл, — и чинится она за вечер, а не «комплексным ускорением» за три месяца. Если хочется разобрать свой случай предметно, с водопадом и цифрами на руках, приходите на SEO-консультацию — посмотрим ваши замеры вместе и решим, что из списка вам вообще нужно.