Скорость загрузки сайта можно проверить бесплатно двумя способами: запустить PageSpeed Insights (pagespeed.web.dev) для конкретной страницы или открыть в Яндекс Метрике отчёт «Время загрузки страниц» - если счётчик уже установлен (установка разобрана в статье как установить Яндекс Метрику на сайт). Ниже - как запустить обе проверки, что означают LCP, INP, CLS, FCP и TTFB, чем лабораторные данные отличаются от полевых и что делать, если данных о реальных посетителях пока нет. Связаться в Telegram: t.me/billioniks.
Что покажет проверка скорости загрузки сайта?
Коротко: один бесплатный инструмент, PageSpeed Insights, даёт и лабораторный прогон страницы, и (если данных достаточно) сводку реального опыта посетителей; второй, отчёт Метрики, показывает этапы загрузки именно у ваших реальных посетителей.
PageSpeed Insights (PSI) анализирует производительность страницы и на мобильных, и на десктопе, предлагает варианты улучшения на основе лабораторных и реальных данных. Лабораторные данные PSI получает через Lighthouse - симуляцию загрузки страницы в контролируемой среде; полевые данные - из отчёта Chrome User Experience Report (CrUX), то есть от реальных пользователей Chrome за предыдущие 28 дней (about PageSpeed Insights). Отчёт Метрики «Время загрузки страниц» устроен иначе: без симуляции, он показывает, как страница грузилась в браузерах ваших реальных посетителей, с разбивкой по этапам (Яндекс Метрика, «Время загрузки страниц»).
Как запустить проверку в PageSpeed Insights?
Коротко: открыть pagespeed.web.dev, вставить адрес страницы в поле и нажать «Анализировать» (в английском интерфейсе - «Analyze») - отдельно для мобильной и для десктопной версии.
На странице pagespeed.web.dev есть поле для ввода адреса (в русском интерфейсе подсказка «Введите действительный URL.», в английском - «Enter a valid URL») и кнопка «Анализировать» (в английском интерфейсе - «Analyze»). Проверяется конкретный URL, например https://example.ru/uslugi - результат покажет отдельные вкладки для мобильной версии и для десктопа, потому что у страницы на телефоне и на компьютере разная производительность.
- Откройте pagespeed.web.dev.
- Вставьте в поле адрес одной конкретной страницы (её полный URL).
- Нажмите Анализировать (Analyze в английском интерфейсе).
- Посмотрите результат сначала для мобильной вкладки, потом для десктопной - пороги одинаковые, но условия лабораторного теста разные: для мобильной версии эмулируется более слабое устройство (об этом - в следующем разделе).
Чем лабораторные данные отличаются от полевых?
Коротко: лабораторные данные - это единичный симулированный прогон на фиксированном устройстве и сети; полевые - история реальных посещений в разных условиях, поэтому цифры расходятся, и обе стороны от этого не становятся неправильными.
Официальная справка PSI объясняет, почему лабораторные и полевые данные могут расходиться: «The field data is a historical report about how a particular URL has performed (...) The lab data is based on a simulated load of a page on a single device and fixed set of network conditions. As a result, the values may differ» - «Полевые данные - это отчёт о том, как определённый URL показывал себя в прошлом (...) Лабораторные данные основаны на симулированной загрузке страницы на одном устройстве и с фиксированным набором сетевых условий. В результате значения могут различаться» (about PageSpeed Insights, FAQ, перевод дословного фрагмента наш).
Лабораторный тест PSI запускается через Lighthouse. Для мобильной версии эмулируется среднее по мощности устройство (Moto G4) на мобильной сети, для десктопной - условный компьютер с проводным соединением. Сам тест выполняется в одном из дата-центров Google (Северная Америка, Европа или Азия) - место видно в блоке environment отчёта (about PageSpeed Insights, FAQ).
Что означают LCP, INP, CLS, FCP и TTFB?
Коротко: пять метрик по официальной таблице PageSpeed Insights и три из них - Core Web Vitals (LCP, INP, CLS); статус каждой считается на 75-м процентиле загрузок.
PSI делит опыт пользователя на три категории - хорошо, нужно улучшить, плохо - и устанавливает пороги в соответствии с инициативой Web Vitals (about PageSpeed Insights). Английская версия страницы - канонический источник названий: русская версия PSI переведена машинным переводом и путает термины («ФКП» вместо FCP, «Бедный» вместо Poor), поэтому в таблице ниже - английские аббревиатуры и перевод статусов по смыслу.
| Метрика | Что измеряет | Хорошо | Нужно улучшить | Плохо |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | скорость загрузки - время отрисовки самого крупного заметного элемента | 0-2500 мс | 2500-4000 мс | более 4000 мс |
| INP (Interaction to Next Paint) | скорость реакции на действия пользователя | 0-200 мс | 200-500 мс | более 500 мс |
| CLS (Cumulative Layout Shift) | визуальная стабильность - насколько элементы «прыгают» при загрузке | 0-0,1 | 0,1-0,25 | более 0,25 |
| FCP (First Contentful Paint) | момент, когда на странице появляется первый контент | 0-1800 мс | 1800-3000 мс | более 3000 мс |
| TTFB (Time to First Byte, экспериментальная) | время до первого байта ответа сервера | 0-800 мс | 800-1800 мс | более 1800 мс |
Core Web Vitals - это подмножество из трёх метрик: LCP, CLS и INP (about PageSpeed Insights, «Core Web Vitals»). Web.dev формулирует эти же три порога так: LCP должен укладываться в 2,5 секунды с начала загрузки страницы, INP - не более 200 миллисекунд, CLS - не больше 0,1 (web.dev, «Web Vitals»). Отдельная техническая деталь: Lighthouse физически не может измерить INP, потому что в симуляции нет реального ввода пользователя - вместо этого лабораторный отчёт показывает Total Blocking Time (TBT) как косвенный показатель (web.dev, «Web Vitals»).
Как читать 75-й процентиль и статус Good/Needs Improvement/Poor?
Коротко: PSI показывает 75-й процентиль - показатель, хуже которого страница загружалась только у четверти посетителей, а не среднее значение по всем загрузкам.
75-й процентиль, по справке PSI, выбран, чтобы разработчики понимали самый неудачный опыт пользователей на сайте, а цель - чтобы страницы работали хорошо для большинства пользователей, в том числе в самых сложных условиях устройства и сети (about PageSpeed Insights, раздел о распределении метрик и FAQ). Агрегация - по странице или по всему сайту - проходит проверку Core Web Vitals, если 75-й процентиль всех трёх метрик (LCP, CLS, INP) попадает в категорию «хорошо». Если данных по INP недостаточно, проверка идёт только по LCP и CLS (about PageSpeed Insights, «Core Web Vitals»).
Что делать, если полевых данных по странице нет?
Коротко: если у конкретной страницы мало реальных посещений, PSI показывает данные по всему домену; если не хватает и их - полевых данных не будет вовсе, и это ожидаемо для небольшого сайта, инструмент здесь ни при чём.
Чтобы страница попала в отчёт CrUX с полевыми данными, у неё должно быть достаточно уникальных посещений. Если страница новая или посещений слишком мало, PSI переключается на данные всего сайта (origin-level); если недостаточно данных даже на уровне всего сайта, PSI вообще не покажет полевые данные - останется только лабораторный прогон (about PageSpeed Insights, «Real-user experience data»). Для небольшого сайта с малым трафиком это нормальная ситуация: лабораторных данных (Lighthouse) в любом случае достаточно, чтобы увидеть диагностику страницы.
Как посмотреть скорость у реальных посетителей в Яндекс Метрике?
Коротко: путь в интерфейсе - «Отчеты → Мониторинг → Время загрузки страниц», данные показаны по этапам загрузки и с настраиваемым квантилем.
Если счётчик Метрики уже установлен и стоит на сайте, отчёт открывается по пути «Отчеты → Мониторинг → Время загрузки страниц» (Яндекс Метрика, «Время загрузки страниц»). Установка счётчика в этой статье не разбирается - это отдельный шаг, описанный в статье как установить Яндекс Метрику на сайт.
Отчёт раскладывает загрузку страницы на этапы. Справка называет их дословно: «DNS» (обработка запросов к DNS), «Редиректы» (обработка редиректов), «Продолжительность установки соединения», «Ответ сервера», «Время загрузки и парсинга HTML», «Время до загрузки DOM», «Время до отрисовки» (Яндекс Метрика, «Время загрузки страниц»). Показателем полной загрузки страницы справка называет именно «Время до загрузки DOM» - время от начала перехода на страницу до момента, когда она полностью загружена со всеми компонентами и доступна для взаимодействия; максимальное отображаемое значение этой метрики - 30 секунд. Про «Время до отрисовки» справка отдельно поясняет: «Именно это значение субъективно воспринимается посетителем как скорость загрузки сайта. Обычно оно занимает не более двух секунд» (Яндекс Метрика, «Время загрузки страниц»).
Данные в отчёте оцениваются через квантиль - по умолчанию 50%: это значит, что в половине случаев время загрузки будет не больше указанного в отчёте. Квантиль можно менять, например на 90%, тогда цифра будет показывать время, которое не превышается уже в 90% случаев (Яндекс Метрика, «Время загрузки страниц»). Если нужна скорость загрузки по регионам, справка советует нажать «Группировки → Аудитория → География» и отметить нужные показатели, например «Город», «Страна» (Яндекс Метрика, «Время загрузки страниц»).
Как скорость страницы связана с местом в поиске Google?
Коротко: Google формулирует это так - показатели Core Web Vitals отражают, какие страницы поощряют его основные системы ранжирования, и рекомендует следить за ними. Про влияние скорости на позиции в Яндексе в этой статье ничего не утверждается: среди её источников такой официальной формулировки нет.
Страница Google Search Central о Core Web Vitals формулирует роль этих показателей так: «Удобство оценивается по показателям Core Web Vitals, таким как скорость загрузки, интерактивность и визуальная стабильность (...) Эти, а также и другие показатели взаимодействия со страницей отражают, какие страницы поощряют наши основные системы ранжирования» (Google Search Central, «Основные сведения о показателях Core Web Vitals и результатах поиска Google»).
Там же названы те же три порога, что и в таблице выше: LCP менее 2,5 секунды с начала загрузки страницы, INP менее 200 мс, CLS менее 0,1.
Что показывает отчёт Core Web Vitals в Search Console?
Коротко: ещё один бесплатный источник полевых данных - он группирует похожие страницы под общим статусом «Низкая скорость», «Нужно увеличить скорость» или «Хорошо».
Справка Search Console описывает отчёт так: «В отчете о показателях Core Web Vitals приводятся данные об эффективности страниц, сгруппированные по статусу (...), показателям (CLS, INP и LCP) и группам URL» (Search Console, «Отчет о показателях Core Web Vitals»). Если у группы URL получено достаточно данных по LCP и CLS, но, например, низкий показатель CLS при высоком INP, статус присваивается по худшему из показателей. Данные, как и в PSI, приходят из CrUX - реальных браузеров реальных посетителей; если у группы URL данных мало, Search Console укрупняет отчёт до уровня всего источника (домена).
После того как проблема исправлена, можно нажать «Начать отслеживание»: Search Console 28 дней наблюдает, не проявится ли проблема снова, и если не обнаружит её ни по одному из URL, она будет считаться решённой (Search Console, «Отчет о показателях Core Web Vitals»).
Почему цифры PageSpeed Insights, Метрики и Search Console расходятся?
Коротко: у каждого инструмента свой набор данных и своя единица наблюдения - этим и объясняется расхождение цифр, без поломки на чьей-либо стороне.
PSI на одной странице показывает две разные вещи: лабораторный прогон (единичная симуляция) и полевые данные CrUX (история реальных посещений за 28 дней, если их хватает). Отчёт Метрики строится только на реальных посетителях этого конкретного сайта - без симуляции и без чужой выборки. Отчёт Search Console агрегирует данные CrUX по группе похожих страниц, поэтому цифра по конкретному адресу в PSI может не совпасть с цифрой его группы в Search Console (Search Console, «Отчет о показателях Core Web Vitals»). Добавьте к этому: PSI обновляет полевые данные ежедневно, а Метрика по умолчанию показывает квантиль 50% (PSI - 75-й процентиль). По её справке скорость загрузки может зависеть от браузера, поэтому она рекомендует смотреть данные в разбивке по браузерам - вот почему цифры трёх источников не совпадают.
Что передать разработчику по итогам проверки?
Коротко: PSI сам формирует список диагностики (раздел с аудитами Lighthouse) - его и стоит передать разработчику, без домыслов о коде и без обещанных цифр эффекта.
После лабораторного прогона PSI показывает раздел с аудитами Lighthouse по категориям Performance, Accessibility, Best Practices и SEO - именно там перечислено, что конкретно тормозит страницу (about PageSpeed Insights, «Lab diagnostics»). Этот список - готовая инструкция для разработчика: что показал инструмент, то и передаётся, без домысливания технических деталей и без чисел вроде «ускорит загрузку на N секунд» - таких цифр справка не даёт, и предполагать их не стоит.
Если по итогам проверки нужна постоянная работа с сайтом в поиске, на странице продукта BLKHT SEO в составе услуги перечислены «Технический и поисковый анализ», «Работа с существующими и новыми страницами» и «Контент, публикация и перелинковка». Связаться в Telegram: t.me/billioniks.
Если вместо разовой проверки скорости страницы нужно ещё и отслеживать позиции сайта по запросам, это отдельный отчёт Яндекс Вебмастера - он разобран в статье как узнать позиции сайта по запросам. А если сайт в Вебмастер ещё не добавлен и права не подтверждены, первый шаг - в статье как добавить сайт в Яндекс Вебмастер.
Источники
- «About PageSpeed Insights» (Google for Developers) - https://developers.google.com/speed/docs/insights/v5/about (проверено 27.09.2026)
- «Web Vitals» (web.dev) - https://web.dev/articles/vitals?hl=ru (проверено 27.09.2026)
- «Основные сведения о показателях Core Web Vitals и результатах поиска Google» (Google Search Central) - https://developers.google.com/search/docs/appearance/core-web-vitals?hl=ru (проверено 27.09.2026)
- «Отчет о показателях Core Web Vitals» (Справка Search Console) - https://support.google.com/webmasters/answer/9205520?hl=ru (проверено 27.09.2026)
- «Время загрузки страниц» (Яндекс Метрика) - https://yandex.ru/support/metrica/ru/reports/timing.md (проверено 27.09.2026)
- PageSpeed Insights - https://pagespeed.web.dev/ (проверено 27.09.2026)
- «BLKHT SEO - рост органического трафика» (BLKHT) - https://blkht.ru/seo/ (проверено 27.09.2026)
Рабочий контакт BLKHT - Telegram t.me/billioniks.