О Обходчик
← Блог

Как проверить скорость загрузки сайта и правильно понять результат

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

Руслан Хуснутдинов, основатель Обходчика около 8 мин чтения

Проверить скорость сайта можно бесплатно за пару минут: вставить адрес в PageSpeed Insights и посмотреть на верхний блок с данными реальных посетителей, а не на круглый балл. Если этого блока нет, у сайта мало посещений из Chrome, и тогда ориентиром остаются лабораторный замер и ваши собственные ощущения с телефона.

Если подрядчик прислал балл «34 из 100», это оценка одной тестовой загрузки на эмулированном телефоне среднего уровня. Он полезен как список подсказок, но не отвечает на главный вопрос — медленно ли сайт открывается у ваших клиентов.

Чем проверять

Для владельца сайта хватает трёх инструментов, все бесплатные.

PageSpeed Insights от Google. Вставляете адрес страницы и получаете два отчёта: для мобильных и для компьютеров. Наверху — данные реальных пользователей Chrome за последние 28 дней, если они есть. Ниже — лабораторный замер Lighthouse с баллом от 0 до 100 и списком того, что можно улучшить.

Отчёт о Core Web Vitals в Google Search Console. Нужен, если сайт уже подтверждён в Search Console. Показывает те же метрики по реальным посещениям, причём сразу по группам похожих страниц, отдельно для телефонов и компьютеров. По нему удобно понять, проблема у всего сайта или у одного шаблона, например у карточек товаров.

Инструменты разработчика в Chrome. Клавиша F12 (на Mac — Cmd+Option+I) открывает панель, в ней две полезные вкладки:

  • Lighthouse — тот же лабораторный замер, что в PageSpeed Insights, только с вашего компьютера и вашего интернета. Нажмите «Analyze page load», отчёт появится через 30–60 секунд.
  • Network — список всего, что загружает страница. Поставьте галочку «Disable cache», чтобы увидеть сайт глазами первого посетителя, и обновите страницу. Внизу появится число запросов и общий объём. Отсортируйте по размеру — самые тяжёлые файлы окажутся сверху. В выпадающем списке скорости сети можно выбрать «Slow 4G» и почувствовать, каково открывать сайт с мобильного интернета.

Реальные посетители и лаборатория — это разные замеры

В отчёте PageSpeed Insights два блока, и их легко перепутать.

Полевые данные собирает сам Chrome у реальных пользователей (отчёт CrUX). Это то, что люди действительно видели за последние 28 дней. Google берёт 75-й процентиль: у трёх четвертей визитов результат такой же или лучше. Поэтому медленные загрузки на слабых телефонах тоже влияют на оценку.

Если реальных визитов мало, PageSpeed Insights покажет данные по всему сайту вместо отдельной страницы, а если не хватает и их — блок будет пустым. Для небольшого сайта услуг это нормально.

Лабораторные данные — одна загрузка в заданных условиях. Для мобильной версии Lighthouse эмулирует телефон среднего уровня на мобильной сети, тест идёт из дата-центра Google в Северной Америке, Европе или Азии. Именно отсюда берётся балл от 0 до 100.

Если два блока противоречат друг другу, верить стоит полевым данным: они собраны у ваших посетителей.

LCP, INP и CLS: что значат и какие пороги

Core Web Vitals — так Google называет три главные метрики. С марта 2024 года вместо FID в этот набор входит INP.

Метрика Что измеряет Хорошо Нужно улучшить Плохо
LCP Когда на экране появился главный крупный элемент: картинка или блок текста до 2,5 с 2,5–4 с больше 4 с
INP Как быстро страница отзывается на нажатия и ввод до 200 мс 200–500 мс больше 500 мс
CLS Насколько прыгает содержимое во время загрузки до 0,1 0,1–0,25 больше 0,25

Пороги взяты из справки PageSpeed Insights и описания метрик на web.dev. Страница проходит оценку, когда все три значения на 75-м процентиле в зелёной зоне. Если по INP данных мало, хватает хороших LCP и CLS.

Проще говоря, LCP — сколько ждать, пока страница выглядит загруженной. INP — нет ли паузы между нажатием на «В корзину» и реакцией. CLS — не уезжает ли кнопка из-под пальца, потому что сверху догрузился баннер.

Почему балл скачет от запуска к запуску

Запустили проверку утром — 41, вечером — 33, ничего не меняли. Это нормально. В документации Lighthouse перечислены причины: разная реклама и A/B-тесты на странице, маршруты интернет-трафика, разная мощность компьютера, расширения браузера и антивирус. Сервер тоже отвечает с разной задержкой в зависимости от нагрузки.

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

Ещё одна деталь: балл складывается из пяти лабораторных метрик с весами. Больше всего весит время блокировки основного потока (TBT, 30 %: сколько страница была занята скриптами и не могла отвечать на нажатия), затем LCP и CLS по 25 %. INP в лабораторный балл не входит вовсе: при замере загрузки никто ничего не нажимает, поэтому INP видно только по реальным посетителям. Из-за этого балл и полевые метрики иногда расходятся.

Сам балл Google делит на три зоны: 0–49 — плохо, 50–89 — нужно улучшить, 90–100 — хорошо. 34 — красная зона. Это повод открыть список рекомендаций, но ещё не доказательство, что сайт теряет клиентов.

Мобильная версия и компьютер

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

Смотреть стоит ту версию, через которую к вам приходят. У сайта услуг для частных клиентов это обычно телефон. Долю мобильных визитов можно увидеть в Яндекс Метрике или Google Analytics — если она большая, мобильные цифры важнее десктопных.

Время ответа сервера

TTFB — время до первого байта: сколько прошло от запроса до момента, когда сервер начал отдавать страницу. Сюда входят редиректы, поиск адреса в DNS, установка защищённого соединения и работа самого сайта.

Ориентир с web.dev: до 0,8 секунды — хорошо, больше 1,8 секунды — плохо. TTFB не входит в Core Web Vitals, но из него складывается LCP: пока сервер думает, картинке и тексту не с чего начинать загрузку.

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

Что обычно тормозит сайт

Причины у небольших сайтов повторяются.

  • Тяжёлые картинки. Фото с телефона весом в несколько мегабайт на главном баннере — частая история. По вкладке Network это видно сразу: один файл может весить больше всей остальной страницы.
  • Виджеты и сторонние скрипты. Онлайн-чат, кнопка обратного звонка, карта, видео с YouTube, несколько счётчиков. Каждый загружает свой код и нагружает телефон, а тяжёлый JavaScript ухудшает INP.
  • Блоки, под которые не оставили места. Картинки без указанных размеров, рекламные вставки, всплывающие баннеры. Они догружаются и сдвигают текст — так растёт CLS.
  • Медленный сервер. Дешёвый хостинг, перегруженная база, движок без кэша, цепочка из нескольких редиректов. Видно по большому TTFB.
  • Шрифты. Пока подгружается фирменный шрифт, текст может прыгать или не показываться.

Что заказывать у подрядчика

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

  1. Цель по полевым данным. «LCP, INP и CLS на мобильных — в зелёной зоне в отчёте Search Console» или по данным PageSpeed Insights, если отчёта нет. А если полевых данных нет совсем, договоритесь о лабораторных LCP и CLS по медиане нескольких прогонов.
  2. Список причин до работ. Попросите разобрать отчёт и назвать три-пять конкретных проблем с оценкой, что даст исправление каждой. Без этого непонятно, за что платите.
  3. Замер «до» и «после» на одних и тех же страницах, с медианой нескольких прогонов.
  4. Отдельно — сервер. Если TTFB плохой, вопрос к хостингу или к движку, и решать его стоит до картинок.
  5. Срок проверки. Полевые данные копятся 28 дней, поэтому результат работ в Search Console виден не сразу. В отчёте есть кнопка «Начать отслеживание» — она запускает 28-дневную проверку исправлений.

Хорошие метрики Google рекомендует, но прямо пишет, что они не гарантируют верхних мест в выдаче: релевантный ответ важнее. Ускорять сайт стоит в первую очередь ради посетителей, особенно тех, кто открывает его с телефона.

Скорость — не единственное, что ломается

Медленный сайт хотя бы открывается. Хуже, когда он не отвечает совсем или ночью из-за проблем на хостинге отвечает в разы дольше обычного. Разовый замер днём этого не покажет. Если после перехода на HTTPS часть картинок или скриптов всё ещё грузится по HTTP, это смешанный контент: браузер может такие файлы заблокировать. Про то, почему «сервер отвечает» ещё не значит «сайт работает», — в разборе про 200 OK.

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

Проверить у себя

Бесплатно и без регистрации, по одному домену.

← Другие разборы в блоге