PageSpeed Insights: как читать результаты и что реально влияет на скорость

PageSpeed Insights показывает не «хороший» или «плохой» сайт, а конкретные проблемы загрузки. Сначала смотрите полевые данные и Core Web Vitals, затем LCP, INP, CLS и TTFB. Рекомендации оценивайте по возможному выигрышу во времени. Красный балл сам по себе не означает, что сайт нужно срочно переделывать целиком.

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

PageSpeed Insights проверяет одну страницу по двум источникам данных: реальному опыту пользователей и лабораторному тесту. Полевые показатели собираются примерно за последние 28 дней, если для страницы или домена накоплено достаточно данных. Лабораторный запуск проходит в заданных условиях и помогает искать причины задержек, но не описывает опыт всех посетителей.

После ввода адреса сервис обычно показывает четыре блока, которые не стоит смешивать:

• Оценка производительности от 0 до 100. Это расчётный балл лабораторного теста, а не процент скорости и не гарантия позиций в поиске.
• Данные пользователей - полевые показатели Chrome UX Report. Они описывают реальный опыт посетителей, но появляются не для каждой страницы.
• Диагностика - список технических причин: тяжёлые изображения, долгий ответ сервера, лишний JavaScript, блокирующие ресурсы.
• Аудиты доступности, SEO и best practices. Они полезны для общего контроля, но не заменяют отдельную проверку контента, структуры и конверсии.

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

Как читать результаты PageSpeed Insights

Начинайте с полевых данных, если они доступны: именно они показывают опыт реальных посетителей. Затем переходите к лабораторным метрикам и рекомендациям. Хороший результат - когда Core Web Vitals проходят свои пороги, а коммерческая страница быстро показывает первый экран, предложение, цену и способ связи на обычном смартфоне.

У PageSpeed есть цветовые зоны. Они помогают быстро оценить масштаб проблемы, но не дают готового плана работ:

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

Не складывайте напрямую значения из разных блоков. LCP из полевых данных и LCP из лаборатории могут отличаться из-за устройства, географии, сети, кэша и состава аудитории. Для проекта в Казахстане полезно сравнивать не только офисный тест, но и загрузку через мобильный интернет.

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

LCP, INP, CLS и TTFB: что означают цифры

Для коммерческой страницы в первую очередь смотрите LCP, INP и CLS. Ориентиры хорошего результата - LCP до 2,5 секунды, INP до 200 миллисекунд и CLS не выше 0,1. TTFB не входит в Core Web Vitals, но помогает понять, как быстро сервер начинает отдавать страницу и почему другие показатели могут ухудшаться.

• LCP - время появления самого крупного видимого элемента первого экрана. Им может быть заголовок, фотография товара, баннер или блок с предложением. Высокий LCP означает, что человек долго видит пустой или незавершённый экран.
• INP - задержка между действием пользователя и заметной реакцией интерфейса. Метрика учитывает взаимодействия в течение загрузки страницы, поэтому медленные меню, фильтры, корзина и формы могут ухудшать результат.
• CLS - неожиданные сдвиги элементов. Баннер загрузился и вытолкнул кнопку вниз, шрифт изменил размеры, карточки товара «прыгнули» - это типичные причины высокого CLS.
• TTFB - время до первого байта ответа сервера. На него влияют хостинг, серверная логика, база данных, кэш и расстояние до дата-центра. Если показатель стабильно высокий, проверяйте серверную часть, а не только изображения.
• FCP - время появления первого содержимого. Это вспомогательный показатель: он показывает, когда пользователь увидел хоть какой-то элемент, но не говорит, что страница уже готова к работе.

Не путайте FID и INP. FID использовался как показатель отзывчивости раньше, а сейчас для оценки взаимодействий ориентируются на INP. Если в старом отчёте или статье упоминается FID, информацию нужно сверять с актуальной методикой.

Удобная логика поиска причины выглядит так: высокий TTFB указывает на сервер или серверную часть, высокий LCP - на первый экран и его ресурсы, высокий INP - на JavaScript и тяжёлый интерфейс, высокий CLS - на размеры изображений, шрифты и динамические блоки. Это не окончательный диагноз, а способ выбрать следующую проверку.

Что реально влияет на скорость сайта

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

Самые частые источники задержек выглядят так:

• Изображения в PNG или JPEG размером несколько мегабайт. На первом экране достаточно одного тяжёлого файла, чтобы LCP заметно вырос.
• Чаты, пиксели, карты, коллтрекинг, отзывы и рекламные виджеты. Каждый внешний скрипт ждёт ответ стороннего сервера и добавляет работу браузеру.
• Плагины и темы CMS, которые подключают целые библиотеки ради одной кнопки, шрифта или анимации.
• Отсутствие размеров у изображений и рекламных блоков. Браузер не знает, сколько места зарезервировать, поэтому элементы сдвигаются после загрузки.
• Медленная серверная логика: тяжёлые запросы к базе, отсутствие кэша, перегруженный виртуальный хостинг или неоптимизированная генерация страницы.
• Большие файлы JavaScript, которые выполняются до того, как пользователь увидит и сможет использовать первый экран.

Для локального бизнеса есть отдельная деталь: карта 2GIS, кнопка WhatsApp, каталог в Instagram или форма внешнего сервиса могут помогать продажам, но не должны блокировать основное предложение. Сначала показывайте услугу, цену и способ связи, а второстепенные элементы подключайте после основного контента или только на нужных страницах.

Интеграция с Kaspi, онлайн-оплата и доставка тоже не обязаны загружаться на первом экране. Если платёжный модуль нужен только после добавления товара в корзину, подключайте его в этот момент. Клиент быстрее увидит карточку товара, а браузер не будет выполнять лишний код до первого взаимодействия.

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

Что можно исправить самостоятельно

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

• Конвертируйте фотографии в WebP или AVIF. Для баннера не загружайте исходник из фотостока, если на экране он отображается шириной 600 пикселей.
• Сжимайте изображения с визуальной проверкой. Слишком сильное сжатие даёт маленький файл, но может испортить доверие к магазину, клинике или строительной компании.
• Укажите width и height для изображений, баннеров и логотипов. Это резервирует место и снижает CLS.
• Для картинок ниже первого экрана включите lazy loading. Главный визуальный элемент лендинга, наоборот, не должен ждать прокрутки.
• Проверьте кэш браузера, Gzip или Brotli для HTML, CSS и JavaScript. Настройка выполняется на сервере или через панель хостинга.
• Удалите неиспользуемые плагины и виджеты. Не отключайте их вслепую на рабочем сайте: сначала проверьте меню, корзину, формы и мобильную версию.
• Сократите количество начальных шрифтов. Два начертания часто закрывают задачу лучше, чем шесть вариантов, которые долго загружаются.

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

После каждой правки запускайте PageSpeed два-три раза и сравнивайте не только балл, но и конкретные метрики. Лабораторный результат немного меняется от запуска к запуску. Если оценка выросла, а LCP и INP остались прежними, улучшение могло произойти в другом аудите и почти не повлиять на посетителя.

Когда нужен разработчик, а не ещё один плагин

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

Признаки задачи для специалиста:

• PageSpeed пишет об устранении ресурсов, блокирующих отображение, а в отчёте видны большие CSS- и JavaScript-файлы.
• Рекомендация касается сокращения неиспользуемого JavaScript или CSS. Обычно требуется разделить код по страницам и загружать функции по запросу.
• Время ответа сервера высокое даже на простой странице без тяжёлых изображений. Нужно проверить хостинг, запросы к базе, серверный кэш и настройки приложения.
• Проблема появляется только на каталоге, фильтрах или карточках товара. Вероятны лишняя логика интерфейса, тяжёлые запросы или ошибки интеграции.
• После установки чата, карты, аналитики или рекламного пикселя просели INP и LCP. Скрипт нужно отложить, заменить или подключать только на нужных страницах.
• Мобильная версия сильно отличается от десктопной. Нужна отдельная проверка адаптивной вёрстки, изображений, меню и порядка загрузки блоков.

При выборе подрядчика просите не обещать «100 из 100», а показать план: какие URL проверены, какие метрики проседают, что даст наибольший эффект, какие риски есть у правок и как будет проверяться результат. Скриншот одного балла без списка конкретных файлов и действий не заменяет технический разбор.

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

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

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

Полезный рабочий порядок выглядит так:

• Составьте список из пяти URL, которые приносят заявки или продажи.
• Сохраните дату, устройство, LCP, INP, CLS, TTFB и главные рекомендации.
• Проверьте мобильную версию в PageSpeed и вручную через мобильный интернет.
• После изменений сравните одинаковые страницы, а не главную до правки с каталогом после правки.
• Отдельно отметьте бизнес-эффект: открывается ли форма, работает ли меню, быстрее ли появляются цена и кнопка связи.

Ориентиром для коммерческого сайта может быть мобильная оценка от 70 и выше при хороших Core Web Vitals, но это не универсальный норматив. Страница с 65 баллами может давать заявки, если быстро показывает предложение и не мешает действию. И наоборот, высокий балл не спасёт сайт, если клиент не находит цену, адрес или кнопку связи.

Если сайт работает на устаревшей CMS или собран из большого количества плагинов, сначала нужен аудит, а не бесконечная настройка кэша. Поддержка и доработка сайта у нас начинаются от 50 000 ₸ в месяц. Точную стоимость фиксируем после брифа, когда понятны страницы, доступы и список проблем.

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

• Нужно ли добиваться 100 баллов в PageSpeed Insights? Нет. Для бизнеса важнее стабильные Core Web Vitals, понятный первый экран и работающие формы. Погоня за идеальным баллом может ухудшить дизайн или убрать полезные функции.
• Почему мобильный результат ниже десктопного? Мобильный тест использует более ограниченные условия устройства и сети. На результат влияют тяжёлый JavaScript, крупные изображения, шрифты и сторонние виджеты.
• Поможет ли перенос сайта на другой хостинг? Если причина в медленном сервере, кэше или перегруженной базе, перенос может дать эффект. Но новый хостинг не исправит тяжёлый фронтенд и лишние скрипты.
• Влияет ли PageSpeed на SEO? Скорость и Core Web Vitals учитываются среди сигналов качества страницы, но не заменяют релевантный контент, техническое SEO и удобство сайта. Один балл не определяет позицию.
• Нужно ли проверять сайт после добавления чата или карты 2GIS? Да. Такие элементы могут замедлять первый экран, особенно если загружаются синхронно. Их лучше подключать после основного контента или только на нужных страницах.
• Можно ли ускорить старый сайт без полного редизайна? Часто можно начать с изображений, кэша, скриптов и сервера. Если ограничения заложены в теме или CMS, после аудита станет понятно, выгоднее ли доработка или новая сборка.

С чего начать

Откройте PageSpeed Insights и проверьте три страницы: главную, страницу услуги или каталога и страницу с формой. Запишите полевые данные, если они есть, затем сравните LCP, INP, CLS и TTFB в мобильном отчёте. Не исправляйте рекомендации по порядку списка - сначала найдите одну-две причины с наибольшим влиянием.

Если сайт сложно ускорить самостоятельно, мы можем провести аудит, оптимизировать текущую сборку или предложить новую. Для разработки используем Next.js и React, закладываем SEO-структуру и удобную админку с первого дня. Корпоративный сайт стоит от 500 000 ₸ и занимает от 21 дня, интернет-магазин - от 500 000 ₸ со сроком от 30 дней. Работаем из Алматы с проектами по всему Казахстану, удалённо. Домен .kz, хостинг и SSL на первый год входят в стоимость разработки; рекомендуем hoster.kz. Гарантия на проект - 12 месяцев, цена фиксируется после брифа.