Как проверить скорость сайта и как читать отчёт
Проверить скорость сайта можно за две минуты: открываешь PageSpeed Insights, вставляешь адрес, жмёшь Enter. Проблема не в том, как запустить замер. Проблема в том, что сервис выдаёт экран из цифр, полосок и непонятных аббревиатур, и человек закрывает вкладку с мыслью «ну красное и красное, а что делать». Вопрос «как проверить скорость сайта» на самом деле состоит из двух: чем замерить и как прочитать результат. Первое просто. Второе решает всё.
Меня зовут Евгений Волков, я fullstack-разработчик, и скорость я меряю на каждом проекте, прежде чем что-то трогать. В этой статье покажу две вещи. Сначала разберём, чем проверять скорость сайта, включая инструменты, которые нормально работают из России и которые почему-то забывают все гайды. Потом научимся читать отчёт: что значат LCP, INP, CLS и TTFB, где зелёная зона, а где пора паниковать. Чинить сайт тут не будем, это отдельная большая работа со ссылкой в конце. Наша задача сейчас: замерить и понять, что показал замер.
Чем проверить скорость: инструменты
Сервисов проверки скорости десятки, но по делу нужны несколько, и выбор зависит от того, откуда твоя аудитория. Ключевое деление, которое сразу расставляет всё по местам: одни инструменты дают лабораторные данные (синтетический прогон в идеальных условиях), другие полевые (скорость реальных посетителей). Про эту разницу будет отдельный раздел, а пока держи её в голове, читая таблицу.
| Инструмент | Что показывает | Цена | Доступ из России | Тип данных |
|---|---|---|---|---|
| PageSpeed Insights | Балл Lighthouse + полевые CrUX, моб/десктоп | Бесплатно | Работает | Lab + field |
| Lighthouse (в Chrome DevTools) | Прогон прямо в браузере, локально | Бесплатно | Работает | Lab |
| Яндекс.Вебмастер | Скорость в разрезе индексации Яндексом | Бесплатно | Заточен под РФ | Field |
| Яндекс.Метрика | Реальные Core Web Vitals посетителей из РФ | Бесплатно | Заточен под РФ | Field |
| GTmetrix | Наглядный водопад, видео загрузки | Free / платно | Иногда VPN, зарубежные точки | Lab |
| pr-cy | Комплексный аудит, русский интерфейс | Free / платно | Работает | Lab |
| WebPageTest | Глубокий разбор, много локаций и устройств | Бесплатно | Часто нужен VPN, точек РФ мало | Lab |
Пройдусь по тем, которыми пользуюсь сам.
PageSpeed Insights. Мой первый инструмент почти всегда. Веб-сервис Google, вставляешь URL и получаешь сразу два блока: полевые данные реальных пользователей сверху (если у сайта есть трафик) и лабораторный прогон Lighthouse снизу. Отдельно мобайл и десктоп. Бесплатно, без регистрации, за полминуты. Для первого взгляда лучше не придумали.
Lighthouse в Chrome DevTools. Тот же движок, что внутри PageSpeed, только прямо в браузере. Удобно, когда крутишь правки локально и не хочешь выкладывать сайт наружу после каждого чиха. Открыл DevTools, вкладка Lighthouse, погнал.
Яндекс.Метрика и Яндекс.Вебмастер. Вот тут главная дыра почти всех статей про скорость. Они перечисляют западные сервисы и молчат про Яндекс, а для рунета это основной инструмент, не запасной. Метрика показывает реальные Core Web Vitals твоих живых посетителей из России. Вебмастер следит за скоростью в контексте того, как Яндекс индексирует сайт. Если аудитория российская, смотреть надо в первую очередь сюда, потому что замер из американского дата-центра не расскажет, как грузится сайт у человека с телефоном в Перми.
+Плюсы
- PageSpeed Insights: полевые данные Google из коробки, честный мобильный профиль, бесплатно и быстро. Показывает, как у реальных людей, а не только в лаборатории.
- GTmetrix: наглядный водопад запросов и видеозапись загрузки, видно кадр за кадром, где именно застряло. Приятно разбирать один прогон по деталям.
−Минусы
- PageSpeed Insights: одна страница за раз, нет подробного водопада, полевые данные появляются только при заметном трафике. Молодому сайту покажет лишь лабораторный прогон.
- GTmetrix: нет полевых данных Google, дефолтная точка замера часто зарубежная и не отражает российскую скорость, часть функций за платным тарифом.
Про зарубежные инструменты скажу честно. WebPageTest мощный, у него куча локаций, устройств и глубина разбора, но точек внутри России мало, и часть работы упирается в VPN. GTmetrix и Uptrends тоже иногда капризничают из РФ. Пользоваться ими можно и нужно для международных проектов, но для сайта под российскую аудиторию я строю замер вокруг PageSpeed плюс Яндекс, а зарубежные подключаю точечно, когда нужен именно их разбор.
Как запустить проверку за пару минут
Инструменты выбрали. Теперь пошагово, без воды.
PageSpeed Insights
- Заходишь на pagespeed.web.dev.
- Вставляешь полный адрес страницы (не только домен, а конкретный URL, который проверяешь).
- Жмёшь «Анализировать» и ждёшь секунд двадцать-тридцать.
- Смотришь результат отдельно для мобильных и для десктопа, переключатель вверху.
Вот про пункт четыре отдельно. Проверяй в первую очередь мобильную вкладку. Больше половины трафика в рунете это телефоны, часто недорогие, на нестабильной сети. И поисковики оценивают скорость именно по мобильной версии. Красивый десктопный балл при красном мобильном это самообман. Если у сайта есть трафик, вверху появится блок полевых данных: вот это правда о твоих пользователях, смотри на него внимательнее, чем на лабораторный балл ниже.
Lighthouse в Chrome
- Открываешь свой сайт в Chrome.
- Жмёшь F12 (или правой кнопкой, «Просмотреть код»), открывается DevTools.
- Находишь вкладку Lighthouse (может прятаться под стрелочкой «больше вкладок»).
- Выбираешь режим Mobile, категорию Performance, жмёшь Analyze.
Один нюанс, который экономит нервы. Один прогон Lighthouse шумный: цифры прыгают от запуска к запуску на десяток-другой баллов, потому что на результат влияет фоновая нагрузка машины и расширения браузера. Гоняй в режиме инкогнито, чтобы расширения не мешали, и смотри медиану из трёх-пяти прогонов, а не один удачный. И обязательно в Mobile с троттлингом, а не на голом десктопе, иначе получишь оптимистичную картинку, которая развалится на первом же посетителе с телефоном.
Как читать отчёт: что значат цифры
Дошли до главного. Замер запустить умеет каждый, а вот прочитать результат и понять, что с ним делать, умеют немногие. Разберём цифры, которые встретишь в любом отчёте.
Сердце отчёта это Core Web Vitals: три метрики Google, которыми измеряют реальный опыт пользователя. Плюс к ним TTFB, диагностический показатель ответа сервера. Вот нормы на 2026 год и человеческий смысл каждой.
| Метрика | Что измеряет простыми словами | Зелёная зона | На что смотреть |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Как быстро появился главный элемент экрана: крупная картинка или заголовок | ≤ 2,5 с | Тяжёлые картинки, медленный сервер, блокирующий CSS/JS |
| INP (Interaction to Next Paint) | Насколько быстро сайт отвечает на клик, тап, ввод | ≤ 200 мс | Тяжёлый JavaScript, долгие задачи в потоке |
| CLS (Cumulative Layout Shift) | Насколько «прыгает» вёрстка, пока страница грузится | ≤ 0,1 | Картинки без размеров, поздние баннеры, шрифты |
| TTFB (Time to First Byte) | Как быстро сервер отдал первый байт ответа | ≤ 0,8 с | Медленный бэкенд, нет кеша, далёкий сервер |
Теперь по-человечески, что стоит за каждой буквой.
LCP отвечает на вопрос «когда пользователь увидел то, ради чего пришёл». Это самый крупный элемент первого экрана: фото товара, баннер, большой заголовок. Если LCP четыре секунды, человек четыре секунды пялится в полупустой экран. Норма до 2,5 секунды.
INP это про отзывчивость. Ты нажал кнопку, а сайт ответил через полсекунды: вот это плохой INP. Метрика ловит задержку между действием пользователя и реакцией интерфейса. Раздражает сильнее всего именно она, потому что «висящая» после клика страница ощущается как сломанная. Норма до 200 миллисекунд.
CLS про визуальную стабильность. Знаешь, когда читаешь, а текст вдруг прыгает вниз, потому что сверху догрузился баннер, и ты промахиваешься по ссылке. Вот это CLS. Метрика без единиц измерения, просто число, и чем ближе к нулю, тем стабильнее. Норма до 0,1.
TTFB это не Core Web Vitals, а диагностика. Показывает, как быстро ответил сервер. Если TTFB большой, тормозит бэкенд или хостинг, и никакая оптимизация картинок не поможет, потому что проблема раньше по цепочке. Норма до 0,8 секунды.
Отдельно про FID, и это важно. Старую метрику отзывчивости First Input Delay Google убрал в марте 2024 и заменил на INP. Если сервис, статья или чек-лист всё ещё меряют FID, они устарели, и я такое встречаю в топе выдачи регулярно. Забудь про FID, смотри INP. Это тот случай, где половина рунета транслирует прошлогодний снег.
Цвета в отчётах читаются одинаково везде: зелёный это хорошо, жёлтый (оранжевый) это «нужно поработать», красный это плохо. Ориентир по трём метрикам держи перед глазами.
И ещё одно, обо что спотыкаются новички. Балл Lighthouse от 0 до 100 это не то же самое, что зелёные Core Web Vitals. Балл это взвешенная оценка синтетического прогона, а Vitals это отдельные метрики, в идеале полевые. Бывает балл 95 и красный LCP в поле, бывает наоборот. Не гонись за сотней баллов, гонись за тем, чтобы три метрики были зелёными у реальных людей.
Мобильная скорость важнее десктопной
Ещё один источник «двух разных цифр», который сбивает с толку: тот же PageSpeed показывает отличный результат на десктопе и красный на мобильных. Люди пугаются и не понимают, какой считать настоящим. Отвечаю прямо: настоящий тот, что на мобильных.
Причин две. Первая техническая. Мобильный прогон эмулирует слабый телефон с урезанным процессором и медленной сетью, а десктопный гоняет по быстрому каналу без троттлинга. Один и тот же сайт на этих двух профилях грузится за секунду и за пять. Разница не в сайте, а в условиях замера, и мобильные условия ближе к реальному человеку в метро, чем стерильный десктоп.
Вторая причина решает всё. И Google, и Яндекс давно ранжируют по мобильной версии сайта: это называется mobile-first. Поисковик смотрит на скорость твоего мобайла, а не десктопа. Плюс больше половины трафика в рунете это телефоны, и часто не флагманы, а бюджетные Android на нестабильной сети. Тот, кто оценивает сайт по красивому десктопному баллу, оценивает то, что поиск почти не учитывает.
Практический вывод простой. Открыл PageSpeed, первым делом переключился на мобильную вкладку и работаешь с ней. Десктоп смотришь вторым, для полноты. Если мобильный красный, а десктопный зелёный, у тебя проблема, а не «ну на компьютере же быстро». Смотри на сайт глазами человека с телефоном, потому что это и есть твой посетитель.
Lab и field: почему две цифры не сходятся
Самая частая путаница после «что такое LCP» звучит так: «PageSpeed показывает одно, а GTmetrix другое, кому верить». Ответ в разнице между лабораторными и полевыми данными, и её не объясняет почти никто.
Лабораторные данные (lab). Это Lighthouse, синтетический прогон PageSpeed, GTmetrix, WebPageTest. Инструмент берёт одно устройство, один канал, прогоняет загрузку один раз в стерильных условиях. Плюс: результат воспроизводимый, удобно отлаживать и сравнивать до и после правки. Минус: твои пользователи сидят не на эталонном канале робота, поэтому lab показывает потолок, а не реальность.
Полевые данные (field). Это CrUX у Google (его и показывает PageSpeed сверху) и отчёты Яндекс.Метрики. Здесь нет одного прогона: сервис агрегирует скорость тысяч живых посетителей за реальный период, обычно по 75-му перцентилю. То есть «у 75% людей было не хуже вот этого». Это правда о сайте, а не лабораторная модель.
Почему цифры расходятся, теперь понятно. GTmetrix померил один раз с десктопа из зарубежного дата-центра. PageSpeed прогнал мобильный профиль со слабым CPU. Метрика собрала реальных людей на разных телефонах и сетях. Три разных мира, три разных числа. Пытаться свести их к одному бессмысленно.
Правило, которым я пользуюсь. Если lab зелёный, а field красный, верь field и чини то, что видят люди, а не робот. Лаба нужна, чтобы быстро проверять гипотезы во время работы. Поле нужно, чтобы знать правду. А для сравнения «стало лучше или хуже» меряй сайт сам с собой в одном инструменте, с одинаковыми настройками, до и после изменения. Тогда цифры сопоставимы.
Оговорюсь про молодые сайты. Если трафика мало, полевых данных ещё нет: PageSpeed честно напишет, что данных CrUX недостаточно, и покажет только лабораторный прогон. Это нормально, паниковать не нужно. Пока поле не накопилось, ориентируйся на Lighthouse в мобильном режиме с троттлингом, помня, что он оптимист.
Плохой результат: куда копать
Допустим, замерил и увидел красное. Прежде чем чинить, полезно понять, куда вообще смотреть. Причин у медленного сайта немного, и они повторяются от проекта к проекту. Пробегусь по частым виновникам, по одной строке на каждого, чтобы ты соотнёс их со своим отчётом.
- Тяжёлые картинки. Самый частый и самый жирный тормоз. Несжатые JPEG и PNG, десктопные размеры на телефоне. Бьёт по LCP.
- Блокирующий рендер JavaScript и CSS. Скрипты и стили, которые браузер обязан скачать и обработать до первой отрисовки. Бьёт по LCP.
- Тяжёлый JavaScript-бандл. Один огромный кусок кода, который надолго занимает поток и держит страницу «мёртвой» после появления. Бьёт по INP.
- Нет кеша. Каждый запрос собирается заново, браузер и сервер не запоминают статику. Раздувает TTFB и повторные загрузки.
- Шрифты. Кастомные начертания без подготовки блокируют текст и дёргают вёрстку. Бьёт по LCP и CLS.
- Сторонние скрипты. Чаты, пиксели, счётчики, карты. Чужой код в твоём потоке, которым ты не управляешь. Бьёт по INP.
- Медленный сервер или хостинг. Если высокий TTFB, а картинки лёгкие, проблема глубже, в бэкенде.
Тут я сознательно останавливаюсь. Как именно чинить каждый пункт, найти тормоз руками в DevTools, работать с бандлом, кешем и архитектурой, это большая инженерная тема, и я разложил её подробно в отдельном материале про то, как ускорить сайт. Там воркфлоу в панелях Performance и Network, разбор code splitting, реальные числа до и после. Эта пара статей так и работает: тут ты замеряешь и ставишь диагноз, там чинишь по шагам. Смешивать не буду, иначе получится каша.
Как следить за скоростью постоянно
Разовый замер это фотография. Скорость же живёт во времени и деградирует незаметно: добавили баннер, подключили ещё один счётчик, обновили библиотеку, и LCP тихо уполз в жёлтую зону. Поэтому за скоростью не «прогоняют PageSpeed раз в полгода», а следят, и следят именно по полевым данным, потому что они про реальных людей.
Яндекс.Метрика. Для российской аудитории это основной монитор. Она собирает реальные метрики скорости твоих посетителей, и там же видно, если после обновления что-то поехало. Настроил, заглядываешь раз в неделю, ловишь регрессию до того, как она стоила тебе позиций.
CrUX и PageSpeed. Для международного и Google-трафика. Полевые Core Web Vitals по 75-му перцентилю обновляются, и если метрика пробила порог, ты это увидишь.
Практический смысл один: договорись с собой о порогах (LCP ≤ 2,5 с, INP ≤ 200 мс, CLS ≤ 0,1) и реагируй, когда метрика их пробивает. Один тяжёлый скрипт, добавленный «на пять минут», способен откатить месяцы работы. Насколько серьёзно это работает на масштабе, видно на реальном проекте. Международную контентную платформу на 1000+ страниц с двумя языками я вёл с постоянным контролем Core Web Vitals, и это часть того, почему органика там росла, а не проседала. Разбор проекта собран в кейсе платформы калькуляторов: масштаб индексации, скорость и структура под поиск.
Если замерил, увидел красное и не хочешь разбираться сам, это нормально. Диагностика скорости входит в моё техническое SEO, оно стартует от 10 000 ₽. Начинаем честно: я замеряю, показываю на твоих цифрах, где именно теряются секунды, и мы вместе решаем, что чинить в первую очередь. Не оптимизацию ради красивого балла, а конкретные секунды, которые видит твой покупатель и учитывает поиск.
