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

Часть 1 из 6 · Серия «Скорость сайта без магии»

Владелец интернет-магазина открывает главную страницу на ноутбуке:

Раз — и готово.

Затем вставляет адрес в PageSpeed Insights и получает:

Производительность: 38

Через минуту запускает проверку снова:

Производительность: 47

Разработчик проверяет тот же сайт у себя и присылает скриншот:

Производительность: 91

Кому верить?

Всем троим — если они измеряли разные условия. Но ни один результат сам по себе ещё не отвечает на главный вопрос:

Что именно мешает посетителю быстро увидеть страницу и начать ею пользоваться?

Оценка от 0 до 100 удобна как сигнал тревоги. Она плохо подходит для диагноза. Если смотреть только на число, легко потратить неделю на косметическое исправление, поднять балл с 72 до 79 и не ускорить действие, ради которого человек пришёл на сайт.

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

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

«У меня сайт открывается быстро» — не измерение

Браузер владельца находится в привилегированном положении.

Он уже мог сохранить в кэше:

• логотип;
• таблицы стилей;
• JavaScript;
• шрифты;
• фотографии;
• DNS-ответ;
• часть данных приложения.

Сам владелец часто проверяет сайт с современного ноутбука через домашний Wi‑Fi. Посетитель может открыть ту же страницу на недорогом телефоне в мобильной сети. Для него браузеру придётся впервые загрузить ресурсы, распаковать их, разобрать JavaScript и нарисовать интерфейс на гораздо более слабом процессоре.

Поэтому ощущение «быстро у меня» полезно, но описывает только один сценарий:

знакомый сайт
прогретый кэш
быстрое устройство
хорошая сеть

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

Сначала выберите страницу

У сайта нет одной общей скорости.

Главная страница может состоять из текста и одной фотографии. Каталог — из десятков карточек. Карточка товара загружает галерею, отзывы, рекомендации, онлайн-чат и виджет оплаты. Личный кабинет ждёт API и строит таблицы в JavaScript.

Результат главной ничего не гарантирует карточке товара.

Для первого цикла выберите одну страницу, которая одновременно:

1. получает заметный трафик;
2. участвует в важном действии пользователя;
3. вызывает жалобы или выглядит подозрительно медленной.

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

Запишите точный адрес:

https://example.ru/catalog/product-name

Не заменяйте его в следующем замере главной страницей. Иначе сравнение потеряет смысл.

Мобильный и десктопный тест отвечают на разные вопросы

PageSpeed Insights отдельно показывает мобильный и десктопный результат. Это не два оформления одного отчёта.

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

Десктопный результат обычно выше, потому что:

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

Сравнение:

мобильный 42 → десктопный 88

не означает, что мобильный тест «неправильный». Оно говорит, что страница сильно зависит от возможностей устройства или от ресурсов мобильной версии.

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

Что именно измеряет PageSpeed

У PageSpeed Insights есть два разных типа данных.

Лабораторные данные

Lighthouse открывает страницу в контролируемых условиях и измеряет конкретный запуск. Такой тест полезен для диагностики: можно повторить его после исправления и посмотреть, какая часть загрузки изменилась.

Лаборатория отвечает на вопрос:

Что произошло с этой страницей в одном смоделированном запуске?

Именно из лабораторных метрик и аудитов собирается знакомая оценка производительности.

Полевые данные

Если у страницы или сайта достаточно трафика от пользователей Chrome, PageSpeed может показать агрегированный опыт реальных посетителей из Chrome UX Report. Согласно документации PageSpeed Insights, это история за предыдущие 28 дней, а не результат только что запущенного теста.

Поле отвечает на другой вопрос:

Как страница работала у реальных людей на разных устройствах и соединениях?

Отсюда два важных следствия.

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

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

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

Почему оценка меняется от запуска к запуску

Лабораторный тест контролирует условия, но не превращает интернет в математическую константу.

На результат влияют:

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

Поэтому серия:

45 → 52 → 48

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

Не сравнивайте лучший результат «до» с худшим результатом «после». Сделайте несколько замеров в одинаковых условиях и смотрите на середину серии.

Например:

До:    41, 47, 45  → типичный результат 45
После: 61, 58, 63  → типичный результат 61

Такое изменение уже похоже на эффект исправления. Разница:

До:    41, 47, 45
После: 46, 43, 48

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

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

Балл — обложка отчёта, а не сам отчёт

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

Это нормально.

Пользователь не видит балл PageSpeed. Он замечает события:

• долго пусто до появления основного содержимого;
• крупная картинка приходит слишком поздно;
• кнопка не реагирует после нажатия;
• текст прыгает из-за баннера или шрифта;
• форма появляется, но пользоваться ею ещё нельзя.

Именно с такими событиями связаны метрики, которые мы разберём в следующих частях:

• LCP — когда появился главный элемент страницы;
• INP — насколько быстро интерфейс отвечает на действия;
• CLS — насколько сильно содержимое сдвигается.

Не нужно запоминать сокращения в первый день. Достаточно понять принцип:

Сначала ищем задержку, которую чувствует человек. Затем находим ресурс или код, который её создаёт. Только после этого выбираем исправление.

Как превратить длинный отчёт в три задачи

Классический отчёт Lighthouse умеет находить много вещей. Анализ скорости сайта почти никогда не упирается в нехватку подсказок — проблема в их количестве.

В одном списке могут соседствовать:

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

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

Для первого цикла выберите не больше трёх причин:

1. с высоким влиянием на видимую задержку;
2. подтверждённых измерением;
3. находящихся под вашим контролем;
4. достаточно независимых, чтобы проверить эффект.

Например:

1. Главное изображение первого экрана загружается поздно.
2. Файл изображения в четыре раза шире отображаемого размера.
3. Виджет чата запускает тяжёлый JavaScript до появления содержимого.

Это уже план. Формулировка:

Улучшить PageSpeed до зелёной зоны.

планом не является.

Как проверить скорость сайта онлайн: исходный замер в Turbo

Turbo использует мобильный замер PageSpeed, а затем переводит найденные причины в более короткий отчёт:

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

Для исходной точки:

1. откройте turbo.siteko.net;
2. вставьте точный адрес выбранной страницы;
3. дождитесь готового отчёта;
4. сохраните ссылку;
5. выпишите три верхних приоритета;
6. повторите проверку ещё два раза, если собираетесь оценивать небольшое изменение.

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

Сделайте сайт побыстрее, PageSpeed ругается.

можно отправить исходный отчёт и договориться, какое наблюдаемое место исправляем первым.

Чего не делать после первого теста

Не ставить цель «100 любой ценой»

Зелёная зона удобна как ориентир. Идеальная сотня не гарантирует ни верхних позиций в поиске, ни рост конверсии.

Google подтверждает, что Core Web Vitals используются системами ранжирования, но отдельно предупреждает: хорошие показатели сами по себе не гарантируют высокую позицию. Релевантность, содержание и общий опыт страницы никуда не исчезают.

Если последние пять баллов требуют удалить нужный калькулятор, аналитику или часть интерфейса, решение должно быть продуктовым, а не арифметическим.

Не устанавливать пять плагинов оптимизации сразу

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

Сначала одна гипотеза, затем одно изменение и повторная проверка.

Не удалять всё, что отчёт назвал неиспользуемым

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

«Не использовалось во время теста» не всегда означает «не используется на сайте».

Не менять хостинг по одному низкому баллу

Сервер влияет на скорость, особенно на время до первого байта. Но тяжёлые изображения, блокирующие стили и сторонний JavaScript не исчезнут после переезда на более дорогой тариф.

Сначала определите участок задержки. До времени ответа сервера мы доберёмся в шестой, заключительной части серии и свяжем диагностику с материалами о PHP-FPM, MySQL и кэшировании.

Чек-лист правильного первого замера

Перед оптимизацией у вас должно быть записано:

[ ] точный URL страницы
[ ] мобильный или десктопный сценарий
[ ] дата и время проверки
[ ] ссылка на исходный отчёт
[ ] несколько повторных результатов
[ ] три главные причины
[ ] действие пользователя, которое хотим ускорить

Последний пункт важнее, чем кажется.

Для карточки товара целью может быть не «получить 90», а:

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

Такую цель можно проверить и глазами, и метриками, и аналитикой.

Короткие ответы на частые вопросы

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

Выберите одну важную страницу и запишите её точный адрес. Запустите мобильный замер в PageSpeed Insights или Turbo, сохраните ссылку на отчёт и повторите проверку два-три раза. Дальше работайте не с баллом, а с тремя главными причинами задержки из отчёта.

Чем проверить скорость сайта онлайн?

Достаточно браузера. PageSpeed Insights показывает лабораторный отчёт Lighthouse и, если у страницы хватает трафика, полевые данные Chrome. Turbo запускает тот же мобильный замер и переводит результат в короткий список причин с постоянной ссылкой на отчёт. Устанавливать программы не нужно.

Как измерить скорость сайта, чтобы результату можно было верить?

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

Что даёт анализ скорости сайта, если балл и так виден?

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

Почему проверка скорости загрузки сайта каждый раз даёт разный результат?

На лабораторный тест влияют время ответа сервера, состояние кэша, сторонние скрипты, реклама и обычная погрешность измерения. Разброс в несколько баллов — норма. Изменение стоит считать реальным, когда сдвинулась вся серия замеров, а не когда один запуск оказался удачным.

Что дальше

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

Проверить выбранную страницу и сохранить исходный отчёт можно бесплатно на turbo.siteko.net.