Google PageSpeed Insights: как проверить скорость сайта и исправить ошибки

Google PageSpeed Insights – бесплатный инструмент Google, который анализирует скорость и производительность веб-страницы на смартфонах и компьютерах. Сервис показывает результаты реальных пользователей, проводит лабораторное тестирование и подсказывает, что мешает сайту работать быстрее.

Согласно исследованию Deloitte Digital Milliseconds Make Millions, ускорение мобильного сайта на 0,1 секунды сопровождалось ростом конверсии на 8,4% среди исследованных ритейлеров.

В статье расскажем, как пользоваться Google PageSpeed Insights, правильно читать отчёт, оценивать Core Web Vitals и определять, какие технические проблемы нужно исправлять в первую очередь.

Кратко

• Отчёт PSI состоит из двух частей: field data (реальные пользователи за 28 дней) и lab data (один тестовый прогон Lighthouse). Для принятия SEO-решений важнее реальные данные.
• Оценка 0–100 – это лабораторный показатель. Пользователь его не видит, а Google для Core Web Vitals учитывает LCP, INP и CLS.
• Хорошие значения: LCP до 2,5 с, INP до 200 мс, CLS до 0,1 – на 75-м перцентиле загрузок.
• Наиболее частые причины медленной работы страницы: тяжёлые изображения, блокирующие скрипты, медленный ответ сервера, лишние сторонние виджеты.
• Начинайте с LCP-элемента и кеширования: это самые быстрые исправления с заметным результатом.

Содержание

1. Что такое PageSpeed Insights и что он измеряет
2. Как проверить скорость сайта в PageSpeed Insights: пошагово
3. Метрики Core Web Vitals в отчёте
4. Как читать рекомендации: Opportunities и Diagnostics
5. Как исправить типичные ошибки
6. Реальный пример: как сайт достиг 32 тысяч пользователей в месяц
7. Почему в PageSpeed Insights меняется оценка
8. Альтернативы PageSpeed Insights
9. Влияет ли скорость на SEO и ранжирование?
10. Чек-лист оптимизации скорости
11. Типичные ошибки при оптимизации
12. Итог
13. FAQ: часто задаваемые вопросы

Что такое PageSpeed Insights и что он измеряет

Google PageSpeed Insights (PSI) – онлайн-сервис на pagespeed.web.dev для анализа производительности отдельной веб-страницы. Он оценивает её по четырём направлениям: производительность (Performance), доступность (Accessibility), лучшие практики (Best Practices) и SEO.

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

Инструмент использует два источника данных:

• Chrome User Experience Report (CrUX) – агрегированная статистика работы страниц на устройствах реальных пользователей Chrome.
• Lighthouse – автоматизированный тест, который проверяет страницу в контролируемых условиях и выявляет возможные причины низкой производительности.

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

Lab data (Lighthouse) vs Field data (CrUX)

Результаты лабораторного теста и данные реальных пользователей могут отличаться. Это объясняется условиями измерения: Lighthouse тестирует страницу по определённому сценарию, тогда как CrUX накапливает статистику с разных устройств и сетей.

Параметр	Lab data	Field data
Источник	Lighthouse, один тестовый прогон	CrUX, реальные пользователи Chrome
Период	Момент запуска теста	Скользящее окно 28 дней
Условия	Эмулируемые устройство и сеть (для мобильного – смартфон среднего класса)	Разные устройства, сети, страны
Для чего	Отладка: можно повторить и сравнить до и после исправления	Оценка реального опыта и сигнал для Google
Ограничения	Не учитывает реальных пользователей, результат колеблется	Требуется достаточный трафик, обновляется с задержкой
Что показывает	Оценку 0–100, метрики, рекомендации	LCP, INP, CLS, FCP, TTFB по реальным посещениям

Если данных для отдельного URL недостаточно, PSI может показать статистику для соответствующего источника (origin). Если их нет и там, блок с реальными данными будет пустым. Такое бывает на новых сайтах и ресурсах с небольшим трафиком. Также CrUX собирает статистику для общедоступных страниц при наличии достаточного количества данных от пользователей Chrome.

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

Почему оценка 0–100 не равна скорости для пользователя

После тестирования Google PageSpeed показывает общую оценку производительности в баллах и цвете:

• 90–100 (зелёный) – хорошая производительность;
• 50–89 (оранжевый) – требует улучшения;
• 0–49 (красный) – низкая производительность.

Это лабораторный результат Lighthouse, рассчитанный на основе пяти метрик. Согласно документации Chrome, их доли следующие:

Метрика	Вес в оценке
Total Blocking Time (TBT)	30 %
Largest Contentful Paint (LCP)	25 %
Cumulative Layout Shift (CLS)	25 %
First Contentful Paint (FCP)	10 %
Speed Index (SI)	10 %

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

Поэтому 95 баллов в Lighthouse не означают, что сайт быстро работает для всех пользователей. И наоборот, оценка 70 баллов необязательно свидетельствует о плохих Core Web Vitals по полевым данным.

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

В PageSpeed Insights также периодически обновляется движок Lighthouse, а вместе с ним могут меняться условия тестирования и оценивания. Поэтому сравнивайте результаты с учётом даты, версии инструмента и параметров проверки.

Как проверить скорость сайта в PageSpeed Insights: пошагово

Для проверки скорости сайта откройте PageSpeed Insights. Найти сервис можно по названию или запросу Google Speed Test, а для анализа достаточно указать адрес страницы.

1. Откройте pagespeed.web.dev.
2. Вставьте полный адрес страницы с https. Проверяйте не только главную: отдельно категорию, карточку товара, статью.
3. Нажмите «Анализировать» (Analyze). Тест обычно длится до минуты.
4. Переключайте вкладки Mobile и Desktop. Начинайте с мобильной: там более строгие условия, и именно она обычно позволяет выявить проблемы.
5. В верхнем блоке с реальными данными есть переключатель «Этот URL» / «Весь источник» (This URL / Origin). Первый показывает данные одной страницы, второй – всего домена.
6. Ниже видно отметку, пройдена ли оценка Core Web Vitals, и кружки с оценками по категориям.
7. Блок «Диагностика проблем с производительностью» содержит лабораторные метрики и список рекомендаций. Их можно отфильтровать по метрике (FCP, LCP, TBT, CLS), чтобы видеть только те, которые относятся к конкретному показателю.

Названия блоков зависят от языка интерфейса и версии сервиса, поэтому у вас они могут отличаться.

Перед изменениями составьте таблицу с исходными значениями (оценка, LCP, INP, CLS, TTFB) отдельно для мобильной и десктопной версий по 3–5 типовым страницам. Без этого через неделю будет непонятно, что именно улучшилось. Это основа любой проверки скорости сайта. Если нужна комплексная диагностика, команда LuxSite проведёт SEO-аудит сайта и определит приоритетность исправлений.

Метрики Core Web Vitals в отчёте

Core Web Vitals – три ключевых показателя, по которым Google оценивает скорость отображения основного контента, реакцию страницы на действия пользователя и стабильность её элементов. К ним относятся LCP, INP и CLS. Отдельно PageSpeed Insights показывает вспомогательные метрики, которые помогают выяснить причины проблем.

Метрика	Что означает	Хорошо	Требует улучшения	Плохо
LCP (Largest Contentful Paint)	Когда появился самый крупный видимый элемент: изображение, блок текста, постер видео	до 2,5 с	2,5–4 с	более 4 с
INP (Interaction to Next Paint)	Задержка между кликом, касанием или нажатием клавиши и следующим кадром	до 200 мс	200–500 мс	более 500 мс
CLS (Cumulative Layout Shift)	Насколько элементы «прыгают» во время загрузки	до 0,1	0,1–0,25	более 0,25
FCP (First Contentful Paint)	Когда появился первый контент	до 1,8 с	1,8–3 с	более 3 с
TTFB (Time to First Byte)	Сколько времени серверу требуется для передачи первого байта	до 0,8 с	0,8–1,8 с	более 1,8 с
TBT (Total Blocking Time)	Суммарное время блокировки основного потока (лабораторная метрика)	до 200 мс	не определено	не определено

Пороговые значения по web.dev: LCP до 2,5 с, INP до 200 мс, CLS до 0,1. Считается, что страница проходит оценку, если все три показателя хорошие на 75-м перцентиле загрузок, отдельно для мобильных и десктопных устройств. FCP и TTFB помогают анализировать загрузку, а TBT используют в лабораторных тестах. Если хотите подробнее узнать об этой группе метрик, у нас есть отдельная статья про факторы Core Web Vitals.

LCP: что это и как улучшить

LCP (Largest Contentful Paint) показывает, сколько времени требуется для отображения самого крупного элемента в видимой части страницы. Это может быть главное изображение товара, баннер, большой текстовый блок или постер видео. Кандидатами являются <img>, изображения внутри SVG, постер <video>, элементы с фоном через CSS url() и текстовые блоки. Хороший показатель LCP – до 2,5 секунды.

Полезный приём: чтобы найти причину задержки, разделите LCP на четыре составляющие:

1. TTFB – время ожидания первого ответа сервера.
2. Задержка начала загрузки – время до момента, когда браузер начинает получать LCP-ресурс.
3. Продолжительность загрузки – время передачи ресурса.
4. Задержка отображения – промежуток между получением ресурса и его появлением на экране.

Согласно рекомендациям web.dev, для оптимизированной загрузки LCP ориентировочное распределение времени следующее: TTFB – около 40%, задержка начала загрузки – менее 10%, передача ресурса – около 40%, задержка отображения – менее 10%. Это ориентиры для диагностики, а не обязательные нормативы.

Что делать для улучшения LCP:

• Найдите LCP-элемент в отчёте Lighthouse и проверьте, что именно задерживает его появление.
• Если это изображение, оптимизируйте его размер и формат, используйте WebP или AVIF.
• Для важного изображения при необходимости задайте fetchpriority=”high” и не используйте loading=”lazy”, чтобы не откладывать его загрузку.
• Если TTFB высокий, проверьте серверное кеширование, скорость хостинга и целесообразность использования CDN.
• Если ресурс уже загружен, но не отображается, проверьте блокирующие CSS и JavaScript.

Так можно устранить причину задержки, а не оптимизировать всё подряд.

INP заменил FID: что это

INP (Interaction to Next Paint) измеряет, насколько быстро сайт визуально реагирует на действия пользователя: нажатия кнопок, ссылок, клавиш или взаимодействие с формами. Прокрутка, наведение и масштабирование не учитываются. INP оценивает самые медленные взаимодействия во время посещения страницы с учётом количества выполненных действий. В марте 2024 года эта метрика заменила FID (First Input Delay) в составе Core Web Vitals.

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

В лабораторной части PSI INP не показывается, поскольку для него нужны реальные действия пользователя. Вместо этого смотрите на TBT и разделы «Сократите время выполнения JavaScript» и «Минимизируйте работу основного потока».

Типичные причины плохого INP: тяжёлые обработчики кликов, большие сторонние скрипты, большое количество элементов на странице, синхронные операции в основном потоке.

CLS: смещение контента

CLS (Cumulative Layout Shift) оценивает неожиданные смещения видимых элементов страницы. Например, пользователь хочет нажать кнопку, но над ней внезапно загружается рекламный баннер и сдвигает содержимое. В результате человек может нажать не туда, куда планировал.

Наиболее частые причины высокого CLS – изображения без заданных размеров, рекламные блоки без зарезервированного места, динамически добавленный контент и изменения разметки после загрузки шрифтов.

Для уменьшения CLS:

• указывайте width и height или aspect-ratio для изображений и видео;
• резервируйте место для баннеров, виджетов и другого динамического контента;
• не вставляйте новые блоки над уже отображённым содержимым;
• проверяйте, не изменяют ли загруженные веб-шрифты расположение текста.

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

Как читать рекомендации: Opportunities и Diagnostics

После измерения метрик PageSpeed Insights показывает технические рекомендации. В старых версиях Lighthouse их группировали в Opportunities («Возможности») и Diagnostics («Диагностика»). В новых отчётах используется система Performance Insights, а названия отдельных проверок могут отличаться, поэтому ориентируйтесь на суть, а не на точное название строки. Вот 10 пунктов, которые встречаются чаще всего.

Что написано в отчёте (по смыслу)	Что это означает	Что делать
Устраните ресурсы, блокирующие отображение	CSS и JS в <head> не позволяют браузеру показать страницу	Критический CSS встроить inline, остальные стили подключать асинхронно; скрипты с defer
Изображения подходящего размера и формата	Файл больше, чем нужно, или используется устаревший формат	Сжать, отдавать WebP/AVIF, использовать srcset. Подробнее: как сжать изображения для сайта
Отложенная загрузка невидимых изображений	Изображения за пределами первого экрана загружаются сразу	loading=”lazy” для всего, что ниже первого экрана
Уменьшите объём неиспользуемого JavaScript	Загружается код, который не выполняется на странице	Удалить лишние плагины, разделить бандлы, подключать скрипты только там, где нужно
Уменьшите объём неиспользуемого CSS	Тот же принцип для стилей	Удалить ненужные темы и библиотеки, разделить файлы по страницам
Эффективная политика кеширования	Статические файлы не кешируются или кешируются на короткий срок	Заголовки Cache-Control или Expires (пример ниже)
Сократите время ответа сервера	Высокий TTFB	Серверный кеш, оптимизация запросов к базе, CDN, улучшение хостинга
Избегайте чрезмерного размера DOM	Слишком много элементов на странице	Упростить вёрстку, пагинация, виртуализация длинных списков
Шрифты: отображение текста во время загрузки	Текст невидим, пока не загрузится шрифт	font-display: swap, preload критического шрифта, меньше начертаний
Влияние сторонних скриптов	Чаты, виджеты, пиксели занимают основной поток	Подключать с задержкой, удалить лишние, проверить влияние каждого

Например, если Lighthouse показывает высокий LCP из-за главного баннера, стоит сначала проверить его загрузку, а уже потом оптимизировать второстепенные иконки или стили нижней части страницы.

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

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

Нужен разбор вашего отчёта? Мы проверим LCP-элемент, сервер и скрипты и составим план исправлений по приоритетности. Оставьте заявку на SEO-продвижение и технический аудит.

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

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

Кеш браузера через .htaccess

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

Подходит для серверов Apache с включёнными модулями mod_expires и mod_headers.

<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType image/webp "access plus 1 year"
ExpiresByType image/avif "access plus 1 year"
ExpiresByType image/svg+xml "access plus 1 year"
ExpiresByType font/woff2 "access plus 1 year"
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
</IfModule>
<IfModule mod_headers.c>
<FilesMatch "\.(jpg|jpeg|png|webp|avif|svg|woff2)$">
Header set Cache-Control "public, max-age=31536000"
</FilesMatch>
</IfModule>

Устанавливайте долгий срок для CSS и JS только в том случае, если в имени файла есть версия или хеш (style.a1b2c3.css). Иначе пользователи не увидят обновлений. Для nginx и других серверов синтаксис отличается, поэтому лучше обратиться к администратору или документации сервера.

Сжатие текста

Многие хостинги уже включают сжатие (gzip или Brotli) по умолчанию. Проверьте заголовок Content-Encoding в ответе сервера, прежде чем добавлять правило.

<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/css application/javascript application/json image/svg+xml
</IfModule>

Preload и fetchpriority для LCP-изображения

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

<head>
<link rel="preload" as="image" href="/img/hero.webp" fetchpriority="high">
</head>
<img src="/img/hero.webp" width="1200" height="600"
alt="Главное фото страницы" fetchpriority="high">

Если браузер долго обнаруживает изображение, например из-за CSS или JavaScript, можно дополнительно применить preload. Для шрифта, который используется на первом экране, preload выглядит так:

<link rel="preload" as="font" type="font/woff2"
href="/fonts/main.woff2" crossorigin>

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

Атрибут crossorigin для шрифтов обязателен, даже если файл находится на том же домене.

Отложенная загрузка: loading=”lazy”

Применяйте его к изображениям и iframe ниже первого экрана. К LCP-изображению – никогда.

<img src="/img/product-12.webp" width="600" height="600"
alt="Товар" loading="lazy" decoding="async">

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

WebP и AVIF

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

С помощью элемента <picture> можно предложить браузеру несколько форматов:

<picture>
<source srcset="/img/banner.avif" type="image/avif">
<source srcset="/img/banner.webp" type="image/webp">
<img src="/img/banner.jpg" width="1200" height="500" alt="Баннер">
</picture>

Браузер выберет первый формат, который поддерживает, а JPEG останется запасным вариантом. Для конвертации JPEG в WebP можно использовать утилиту cwebp:

cwebp -q 80 banner.jpg -o banner.webp

Качество 75–85 обычно обеспечивает хороший баланс размера и внешнего вида, но проверяйте результат визуально на своих изображениях.

Скрипты и шрифты

JavaScript может задерживать отображение страницы и реакцию на действия пользователя. Если скрипт не нужен для первоначального формирования HTML, его можно подключить с атрибутом defer:

<script src="/js/app.js" defer></script>
@font-face {
font-family: "Main";
src: url("/fonts/main.woff2") format("woff2");
font-display: swap;
}

Для классических внешних скриптов defer позволяет загружать файл без блокировки разбора HTML и выполнять его после завершения разбора документа. А font-display: swap показывает текст запасным шрифтом, пока основной загружается. Удаление лишнего виджета или библиотеки иногда полезнее минимизации CSS и JavaScript.

WordPress

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

Что стоит сделать:

• Используйте кеш-плагин и серверный кеш страниц. Не устанавливайте сразу несколько плагинов-оптимизаторов: они конфликтуют.
• Современные версии WordPress добавляют loading=”lazy” к изображениям в контенте. Проверьте, не добавляет ли тема его и к главному баннеру.
• Удалите неиспользуемые плагины и темы. Каждый плагин может добавлять собственные CSS и JS на все страницы.
• Сжимайте изображения при загрузке и отдавайте WebP.

Если нужна помощь с обновлениями, кешированием или исправлением технических проблем, ознакомьтесь с материалом о технической поддержке WordPress.

OpenCart

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

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

Magento

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

• Используйте режим production, встроенный полностраничный кеш и внешний кеш (например, Redis и Varnish), если инфраструктура это позволяет.
• В разделе настроек разработчика проверьте объединение и минимизацию JS и CSS, но тестируйте после каждого переключения: на сложных темах они могут нарушать вёрстку.
• Обращайте внимание на сторонние модули: именно они добавляют лишние запросы.
• Для сложных случаев нужен разработчик.

Реальный пример: как сайт достиг 32 тысяч пользователей в месяц

Во время SEO-продвижения сайта производителя металлопластиковых окон «Линия Окон» команда LuxSite провела технический аудит, проверила скорость загрузки сайта и работу сервера. После первого этапа оптимизации команда ежемесячно отслеживала показатели PageSpeed Insights, в частности время загрузки страниц и ответа сервера. Это позволяло контролировать производительность после изменений в коде и функциональности сайта.

Результат комплексного SEO-продвижения: по данным Ahrefs, органический трафик вырос с 7 до 32 тысяч пользователей в месяц. Работы продолжались более 12 месяцев и включали техническую оптимизацию, обновление структуры и контента, перелинковку и работу со ссылками.

Кейс «Линия Окон» показывает, почему проверка скорости сайта должна быть регулярной частью технического SEO. При этом рост трафика нельзя объяснять только оптимизацией PageSpeed, поскольку это результат системной работы с сайтом.

Почему в PageSpeed Insights меняется оценка и что с этим делать

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

Что ещё влияет на разброс:

• Сервер. Если ответ сервера нестабилен (общий хостинг, пиковая нагрузка), TTFB и LCP колеблются от запуска к запуску.
• Кеш. Прогрев серверного кеша: первый запрос может быть медленным, следующие – быстрыми.
• CDN. Разная география узлов даёт разное время ответа в зависимости от того, откуда выполняется тест.
• Динамический контент. Баннеры, A/B-тесты, рекламные блоки меняют LCP-элемент.
• Сторонние скрипты. Время их ответа от вас не зависит.
• Обновления Lighthouse. Новый движок может изменить оценки без каких-либо изменений на сайте.

Что делать: запускайте тест 3–5 раз и берите медиану, не гонитесь за зелёным кружком с конкретной цифрой, а смотрите на динамику. Сравнивайте метрики до и после исправлений в один день и из одной локации. И главное: при принятии решений опирайтесь на field-данные и отчёт Core Web Vitals в Search Console, где нет разброса отдельных прогонов.

Альтернативы PageSpeed Insights

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

Инструмент	Что даёт	Когда использовать
Lighthouse в Chrome DevTools	Тот же движок, что и в PSI, но запускается локально; можно тестировать страницы после авторизации и локальные сборки	Отладка перед релизом
Отчёт Core Web Vitals в Google Search Console	Реальные данные по группам страниц сайта: какие URL имеют плохие показатели и по какой метрике	Мониторинг всего сайта, поиск проблемных шаблонов
Chrome DevTools: вкладка Performance	Подробный разбор того, что выполняет основной поток и когда	Поиск причин неудовлетворительного INP и долгих задач
WebPageTest	Тесты из разных локаций и на разных устройствах, водопадная диаграмма запросов	Глубокий анализ загрузки ресурсов
GTmetrix	Отчёты с историей изменений и выбором локации теста	Удобный мониторинг и отчёты для клиентов (условия тарифов проверяйте на сайте сервиса)
CrUX (данные Chrome UX Report)	Полевые данные по источнику и странице, в том числе через инструменты на базе CrUX	Сравнение с конкурентами, история изменений

Сочетайте инструменты: Search Console для мониторинга, PSI для проверки URL, DevTools – для диагностики.

Если нужно выбрать одну альтернативу Google PageSpeed, ориентируйтесь на задачу: разработчику полезнее Lighthouse в DevTools, SEO-специалисту – Search Console, а для углублённого анализа сетевых запросов – WebPageTest.

Обычный Speedtest Google помогает проверить скорость интернета, но не объясняет, почему страница долго загружается. Для этого используют PageSpeed Insights, Lighthouse или WebPageTest.

Влияет ли скорость на SEO и ранжирование?

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

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

Чек-лист оптимизации скорости

Используйте этот чек-лист после первичной диагностики или перед запуском обновлённого сайта.

Измерение

• Записаны исходные значения PSI (mobile и desktop) для 3–5 типовых страниц
• Проверены field-данные: по странице и по всему сайту
• Проверен отчёт Core Web Vitals в Search Console
• Определён LCP-элемент на ключевых шаблонах

Изображения

• Изображения сжаты и имеют размер, необходимый для отображения
• Используются WebP или AVIF с запасным форматом
• Указаны width и height (или aspect-ratio)
• loading=”lazy” установлен для изображений ниже первого экрана
• LCP-изображение не загружается лениво и имеет fetchpriority=”high”

Скрипты и стили

• Скрипты подключены с defer или async
• Критический CSS выделен, остальные стили загружаются без блокировки
• Удалены неиспользуемые плагины, темы и библиотеки
• Сторонние виджеты (чаты, пиксели) загружаются с задержкой или удалены

Шрифты

• Для шрифтов задан font-display: swap
• Шрифт первого экрана имеет preload, начертаний не больше, чем необходимо

Сервер и кеш

• Настроен кеш браузера для статических ресурсов
• Включено сжатие gzip или Brotli
• Включён серверный кеш страниц, проверен TTFB
• Для международной или региональной аудитории подключён CDN
• После изменений метрики измерены повторно и сравнены с исходными

Типичные ошибки

Чаще всего проблемы возникают из-за следующих решений:

• Смотрят только на одну оценку и игнорируют field-данные.
• Тестируют только главную страницу, хотя проблема в карточках товаров и статьях.
• Устанавливают loading=”lazy” для всех изображений, в том числе для LCP.
• Устанавливают несколько кеш-плагинов одновременно.
• Добавляют длительное кеширование CSS и JS без версионирования файлов.
• Пытаются довести оценку до 100 баллов, жертвуя функциональностью, необходимой бизнесу.
• Не указывают размеры изображений и получают смещения макета.
• Забывают повторно измерить результат и сравнить с исходным состоянием.

Итог

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

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

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

FAQ

Что такое PageSpeed Insights?

Это бесплатный сервис Google, который анализирует скорость страницы на мобильных устройствах и компьютерах. Он показывает реальные данные пользователей из CrUX за 28 дней, лабораторный тест Lighthouse, метрики LCP, INP, CLS и список рекомендаций. Работает по адресу pagespeed.web.dev, регистрация не требуется.

Какая оценка считается хорошей?

По шкале Google 90–100 баллов – зелёная зона, 50–89 – оранжевая, 0–49 – красная. Однако балл является лабораторным показателем. Для SEO важнее, чтобы по реальным данным LCP не превышал 2,5 с, INP – 200 мс, а CLS – 0,1 на 75-м перцентиле загрузок.

Почему mobile ниже, чем desktop?

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

Чем lab отличается от field-данных?

Lab data – результаты отдельного лабораторного теста страницы в контролируемых условиях. Field data – агрегированная статистика реальных пользователей Chrome за последние 28 дней. Первые используют для диагностики технических проблем, вторые – для оценки фактического пользовательского опыта.

Как ускорить сайт на WordPress?

Включите один кеш-плагин и серверный кеш, сжимайте изображения и отдавайте WebP, удалите неиспользуемые плагины, отложите загрузку сторонних скриптов, проверьте качество хостинга и TTFB. Не добавляйте loading=”lazy” к главному изображению первого экрана. После каждого изменения повторяйте измерение в PSI.

Влияет ли скорость на позиции?

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