Аудит скорости загрузки сайта по PageSpeed: как читать результаты

За последние пару лет я прогнал через PageSpeed Insights не меньше сотни сайтов клиентов - от лендингов на Tilda до интернет-магазинов на WooCommerce и SaaS на React. Аудит скорости загрузки сайта по PageSpeed - первое, что я делаю перед тем как обещать клиенту ускорение: без него правки идут вслепую, а бюджет тратится не на те 20% проблем, которые дают 80% эффекта. Разберу, как читать отчет построчно - от общего балла до конкретных рекомендаций, и что из найденного реально стоит чинить, а что можно смело игнорировать.

Как запустить аудит скорости загрузки сайта в PageSpeed Insights

Иду на pagespeed.web.dev и вставляю не главную страницу с минимумом контента для чистоты эксперимента, а реальную посадочную, куда идет трафик: карточку товара, лендинг с формой заявки, страницу услуги. Балл главной часто врет, потому что на ней меньше виджетов и скриптов, чем на страницах с оплатой или каталогом.

Сервис гоняет два независимых теста - mobile и desktop, и для каждого показывает два блока данных:

• Diagnose performance issues (Lab Data) - синтетический прогон Lighthouse на серверах Google с эмуляцией слабого смартфона и троттлингом сети до уровня плохого 4G;
• Discover what your real users are experiencing (Field Data) - реальные метрики из Chrome UX Report (CrUX), которые Google собирает у пользователей с включенной синхронизацией за последние 28 дней.

Если сайт получает мало трафика, блок Field Data вообще не появляется - Google не набирает достаточно данных для статистики. Тогда ориентируюсь только на Lab Data, но держу в голове, что это один прогон в тепличных условиях, а не то, что видит живой пользователь на разряженном телефоне в метро.

Запускаю проверку 3 раза подряд с интервалом в пару минут. Баллы плавают ±5-10 пунктов даже без единой правки в коде - влияет нагрузка на серверы Google, CDN, кэш браузера теста. Одна проверка - не результат, а точка в шуме.

Из чего состоит отчет: метрики и Core Web Vitals

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

Кроме трех основных Core Web Vitals в отчете есть еще четыре метрики без официальных порогов ранжирования, но они прямо влияют на итоговый балл:

• FCP (First Contentful Paint) - когда браузер отрисовал первый пиксель контента;
• TTFB (Time to First Byte) - сколько сервер думает перед тем как отдать HTML;
• TBT (Total Blocking Time) - сколько миллисекунд основной поток был заблокирован выполнением JS и не мог среагировать на клик;
• Speed Index - насколько быстро заполняется видимая область экрана.

TBT и LCP - это то, на что смотрю в первую очередь при разборе сайтов на WordPress с десятком плагинов: чаще всего именно тяжелый JS (слайдеры, попапы, аналитика, чат-виджеты) держит TBT за 600-800 мс, и это ощущается пользователем как “сайт подвис”, даже если картинка отрисовалась быстро.

Как расшифровать общий балл производительности от 0 до 100

Итоговые 0-100 - не среднее арифметическое, а взвешенная сумма, где метрики имеют разный вес. По актуальной формуле Lighthouse (v10+) вес распределен так: LCP - 25%, TBT - 30%, CLS - 25%, FCP - 10%, Speed Index - 10%. INP в формулу балла не входит вообще - эта метрика выводится отдельно и берется только из Field Data, потому что для нее нужна реальная интерактивность пользователя, а не синтетический прогон.

Отсюда практический вывод: сайт может показывать 95 баллов и одновременно иметь плохой INP у реальных пользователей, если на клик по кнопке “Добавить в корзину” вешается тяжелый обработчик. Бывает и обратное - 40 баллов в лабораторном тесте на слабом эмулированном телефоне, хотя по факту у большинства аудитории сайта современные устройства и LCP укладывается в норму по Field Data.

Ориентиры, которые использую в разговоре с клиентами:

• 90-100 - хорошо, дальше выжимать смысла обычно нет, разве что метрика нужна для других задач SEO;
• 50-89 - требует доработки, обычно 2-4 конкретные правки поднимают на 15-25 пунктов;
• 0-49 - плохо, чаще всего это или тяжелый неоптимизированный хостинг, или свалка из скриптов трекеров и виджетов, которые ставили годами без ревизии.

Для мобильной версии сайтов со сложной версткой (каталог, фильтры, много изображений) баллом 60-70 клиента не пугаю - это реалистичный диапазон без капитальной переделки фронтенда.

Типичные проблемы, которые находит PageSpeed на реальных сайтах

На Tilda

Тильда генерирует довольно чистую верстку, но проблема почти всегда в стороннем коде, который вставляют в T123 или зеро-блоки: пиксели соцсетей, виджеты обратного звонка, скрипты сравнения цен, карты СДЭК на странице доставки. Каждый такой скрипт синхронно блокирует парсинг страницы, и PageSpeed честно показывает это в разделах “Render-blocking resources” и “Reduce the impact of third-party code”.

Рабочий прием - переносить подключение виджетов на событие load с задержкой в пару секунд, вместо того чтобы грузить их сразу с первым экраном:

<script>
  window.addEventListener('load', function () {
    setTimeout(function () {
      var s = document.createElement('script');
      s.src = 'https://widget.example.com/widget.js';
      document.body.appendChild(s);
    }, 3000);
  });
</script>

Для точечных правок вроде этой обычно хватает доработки скрипта - она стоит от 3 000 ₽. Если нужно перестроить всю схему подключения трекеров, эквайринга и интеграции с СДЭК под чистую загрузку, такая работа идет от 40 000 ₽, потому что там уже приходится тестировать конверсионные сценарии, а не просто переставлять тег.

На WordPress и WooCommerce

На WooCommerce с эквайрингом Т‑Банка отчет обычно бьет по TBT и LCP одновременно - за загрузку страницы товара отвечают 15-20 плагинов, каждый тянет свой JS и CSS в head без defer. Форма оплаты Т‑Банка подгружает скрипт со стороннего домена, который PageSpeed видит как “third-party” и штрафует за него отдельно, хотя убрать его нельзя - это часть чекаута.

В таких случаях не борюсь за 100/100 на странице оплаты, а смотрю, что можно вынести без риска сломать конверсию: лишние иконки соцсетей, related products виджеты, неиспользуемые шрифты Google Fonts, картинки без lazy load и без WebP/AVIF. На реальных проектах эти четыре правки обычно снимают 300-500 мс с TBT и поднимают LCP на секунду-полторы без единой строчки правок в логике оплаты.

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

Как расставить приоритеты по рекомендациям из отчета

PageSpeed делит советы на два блока: Opportunities (конкретная экономия в миллисекундах) и Diagnostics (наблюдения без точной цифры экономии). Сортирую Opportunities по убыванию заявленной экономии и беру в работу первые 3-5 пунктов - обычно они закрывают 70-80% потенциального прироста балла.

Diagnostics читаю выборочно: пункт “Avoid large layout shifts” разбираю всегда, потому что сдвиги верстки раздражают пользователей физически (кликнул не туда, потому что баннер подгрузился и сдвинул кнопку), а вот “Serve images in next-gen formats” на сайте с десятком картинок можно отложить, если заявленная экономия там 50-80 мс - не то, ради чего стоит переделывать медиатеку в первой итерации.

Что закрываю почти всегда в первую очередь, независимо от CMS:

• сжатие и правильный размер изображений под реальный контейнер вывода;
• перенос критичного CSS в head, остального - асинхронно;
• отложенная загрузка скриптов, которые не нужны для первого экрана;
• удаление неиспользуемых плагинов и библиотек (частая находка - jQuery UI подключен целиком ради одного календаря);
• явные width/height у изображений и видео, чтобы не прыгала верстка.

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

На одном и том же сайте мобильный балл почти всегда на 20-40 пунктов ниже десктопного, и это не баг замера. Lighthouse эмулирует мобильный тест на условном среднем смартфоне с троттлингом CPU в 4 раза и сетью на уровне слабого 4G с задержкой около 150 мс. Десктопный тест эмулирует мощное железо почти без троттлинга.

Заказчики часто удивляются: “у меня же на телефоне все летает” - и это тоже правда, потому что личный смартфон последней модели на wifi не имеет ничего общего с условиями эмуляции. Для SEO важнее именно мобильный результат - у Google mobile-first индексация, и в Search Console отчет Core Web Vitals точно так же разбит по mobile и desktop раздельно.

Если аудитория сайта преимущественно десктопная (B2B-сервисы, внутренние CRM), не стоит гнаться за идеальным мобильным баллом в ущерб срокам - но полностью игнорировать мобильную часть тоже нельзя, потому что часть трафика из поиска все равно идет с телефонов даже в B2B-тематике.

Частые вопросы

Какой балл PageSpeed считается хорошим?

Google формально делит на три зоны: 90-100 - хорошо, 50-89 - нужно улучшать, 0-49 - плохо. На практике для мобильной версии реального коммерческого сайта с каталогом и виджетами ориентируюсь на 70-85 как реалистичную цель - цифра 100 на боевом сайте с оплатой, чатом и метриками почти недостижима без серьезных компромиссов в функциональности.

Почему PageSpeed показывает разные результаты при повторных проверках?

Лабораторный тест - это один прогон на серверах Google с реальной сетевой нагрузкой, кэшами CDN и соседними тестами в очереди. Разброс в 5-10 баллов между прогонами без изменений в коде - нормальная погрешность измерения, а не ошибка. Для честной оценки прогоняю сайт 3-5 раз и смотрю на медиану, а не на первый результат.

Обязательно ли добиваться 100 баллов?

Нет, и я отговариваю от этой цели. Последние 10-15 пунктов почти всегда стоят непропорционально дорого - приходится жертвовать аналитикой, чатами поддержки или функциональностью ради экономии 100 мс. Разумнее довести балл до 85-90 и остальной бюджет потратить на то, что реально двигает конверсию.

Чем PageSpeed Insights отличается от отчета Core Web Vitals в Search Console?

PageSpeed показывает данные по одному конкретному URL здесь и сейчас - и лабораторные, и, если хватает трафика, полевые. Search Console агрегирует полевые данные по группам похожих страниц сайта за 28 дней и показывает динамику, а не разовый снимок. Для точечной диагностики страницы использую PageSpeed, для отслеживания трендов по всему сайту - Search Console.