Как оптимизировать PageSpeed Insights и поднять скорость сайта до 100

Когда бизнес говорит «поднять скорость гугл спид до 90–100», речь почти всегда про зелёную зону в Google PageSpeed Insights для мобильной и десктопной версий. Проблема в том, что большинство проектов застревает на 50–70 баллах: картинки уже сжали, кэш включили, но отчёт всё равно красный или жёлтый. Эта статья для владельцев сайтов и интернет-магазинов, маркетологов и продактов, а также технических специалистов, которым нужно честно объяснить бизнесу, что реально, а что — маркетинговый миф. Ниже — разбор метрик Google, алгоритм чтения отчёта, практический чек-лист по фронтенду, бэкенду и инфраструктуре, а ещё критерии, по которым можно выбрать исполнителя и понять, когда проще переписать проект, чем бесконечно подкручивать мелочи.

«Скорость Google Speed»: разбор метрики без мифов

Под «скоростью гугл спид» обычно подразумевают совокупность метрик Google PageSpeed Insights, в том числе Core Web Vitals. Основные показатели:

• LCP (Largest Contentful Paint) — за сколько секунд появляется главный контент «над фолдом»;
• FID/INP — насколько быстро интерфейс реагирует на первое действие пользователя;
• CLS (Cumulative Layout Shift) — насколько сильно «прыгает» вёрстка при загрузке.

Итоговый балл 0–100 в google pagespeed insights — это агрегированная оценка набора метрик, плюс симуляция загрузки через Lighthouse. Поэтому мобильный и десктопный результат часто сильно различаются: эмуляция медленной сети и слабого процессора на мобильном беспощадно «наказывает» тяжёлый javascript и картинки.

Важно понимать, что PageSpeed не измеряет «качество сайта» в целом и сам по себе не является прямым рейтингом в SEO. Это сигнал для Google о том, насколько комфортно пользователю. Ошибка — стремиться к «ровно 100», игнорируя реальные сценарии. Лендинг-брошюра без сложной логики почти всегда можно довести до 95–100. Крупный интернет-магазин с фильтрами, рекомендациями и интеграциями часто честно живёт в диапазоне 75–90, и это нормально, если пользовательские сценарии быстрые и стабильные.

Как читать отчёт PageSpeed Insights и выделять главное

Отчёт Google PageSpeed Insights делится на два типа данных. Field data — статистика реальных пользователей из Chrome User Experience Report. Если трафика мало, этот блок может отсутствовать или быть неполным, и тогда приходится опираться в основном на Lab data — лабораторные измерения Lighthouse в момент проверки.

В блоке Core Web Vitals вам нужно смотреть, проходите ли вы пороговые значения. Цветовая индикация проста:

• зелёная зона — метрика в норме, Google считает сценарий комфортным;
• жёлтая — пограничное состояние, которое ещё терпимо, но может тормозить рост;
• красная — реальные проблемы: пользователи видят медленный или «дёргающийся» интерфейс.

Блоки «Возможности» и «Диагностика» часто пугают количеством пунктов. Важно не выполнять их по списку, а оценивать вклад каждой рекомендации в speed. Одни пункты экономят секунды (оптимизация LCP, удаление блокирующего javascript, сжатие изображений), другие — доли процента (например, микрооптимизации CSS без заметного влияния на UX).

Для приоритизации удобно разделить задачи на три группы:

1. Дающие быстрый прирост: вес картинок, lazy load, отключение лишних виджетов, критический CSS.
2. Требующие архитектурных изменений: переразбивка бандлов, пересмотр рендера, оптимизация запросов к API.
3. Косметика: незначительные правки, которые почти не влияют на LCP и время до интерактивности.

Мини-алгоритм работы с отчётом такой: выбрать рекомендации с наибольшей потенциальной экономией времени, затем сгруппировать их по зонам ответственности — фронтенд, бэкенд, инфраструктура. Это позволяет сразу понять, кого подключать: верстальщика, backend-разработчика, devops или всех одновременно.

Практический чек-лист: как поднять сайт до 90–100

Ниже — концентрированный список шагов, с которыми можно идти к разработчикам или подрядчику по оптимизации под google pagespeed.

1. Аудит текущего состояния

• Прогоняем страницу в Google PageSpeed Insights минимум дважды: отдельно мобильная и десктоп.
• Выделяем ключевые шаблоны:
• главная;
• карточка товара или услуги;
• каталог/список (фильтры, пагинация, сортировка);
• самый «тяжёлый» сценарий: корзина, личный кабинет, сложная форма.
• Фиксируем: LCP, время до первого контента, общий вес страницы, количество запросов, размер javascript-бандлов.

2. Фронтенд-оптимизация: быстрые победы

Картинки — частый главный виновник низкого балла.

• Перевод изображений в webp/avif, особенно баннеров и фонов.
• Использование адаптивных размеров (srcset, sizes), чтобы мобильные не грузили десктопные «простыни».
• Настройка lazy load для галерей, отзывов, рекомендованных товаров и других блоков ниже первого экрана.

CSS:

• Вынос критических стилей для первого экрана в <head>, остальной CSS — отложенная загрузка.
• Удаление неиспользуемых стилей из UI-библиотек, фреймворков и старых модулей.
• Минификация и объединение, если файлы раздроблены на десятки мелких.

Javascript:

• Отключение или отложенная загрузка не критичных скриптов: онлайн-чаты, виджеты отзывов, соцкнопки, некоторые аналитические пиксели.
• Пересмотр логики: действительно ли нужен тяжёлый фронтенд-фреймворк для простого лендинга с формой?
• Code splitting: разделение бандла на модули, чтобы пользователь получал только нужный ему функционал.
• Использование атрибутов defer/async там, где это возможно без риска сломать функционал.

В наших проектах часто встречается сценарий «было/стало»: вынос сторонних виджетов ниже фолда и их отложенная инициализация дают +10–20 баллов в pagespeed на мобильных без единого изменения дизайна.

3. Бэкенд и инфраструктура

Быстрый фронтенд бессилен, если сервер полминуты собирает HTML или API отвечает по 3–5 секунд.

• Кэширование:
• кэш страниц (для лендингов, блогов, контентных разделов на CMS или contentful);
• фрагментное кэширование тяжёлых блоков каталога и виджетов;
• кэширование API-ответов с разумным TTL.
• Сервер и CDN:
• включение HTTP/2, сжатие brotli/gzip;
• подключение CDN для статики и медиаконтента — особенно, если трафик из разных регионов;
• грамотные заголовки кеширования для картинок, шрифтов, javascript и CSS.
• База данных:
• проверка тяжёлых запросов: сортировка по неиндексированным полям, «жирные» JOIN;
• индексация колонок, по которым идут фильтры и поиск в интернет-магазине;
• удаление или архивация «мусорных» записей, которые замедляют выборки.

4. Особенности разных типов проектов

• Лендинги и промо-сайты:
• оправдана почти полная статика, генерация HTML заранее (SSG), минимум javascript;
• google pagespeed 95–100 на мобильных здесь достижим без героизма.
• Интернет-магазины:
• обилие сторонних скриптов (оплата, аналитика, A/B, чаты) — важно минимизировать их влияние через отложенную загрузку и объединение;
• имеет смысл сфокусироваться на ключевых типах страниц: карточка товара, корзина, оформление заказа;
• гонка за 100 баллами на каждой вспомогательной странице редко окупается для бизнеса.
• SPA и сложные веб-сервисы:
• server-side rendering (SSR) или static generation (SSG) для публичной «витрины»;
• разделение интерфейса: лёгкая публичная часть и отдельное тяжёлое приложение после авторизации;
• особое внимание LCP и времени до первого интерактивного состояния.

5. Проверка результата

• Перезапускаем тесты в Google PageSpeed Insights и Lighthouse после каждого существенного пакета изменений.
• Сравниваем не только итоговый балл, но и конкретные показатели: LCP, INP, CLS, вес страницы, объём javascript.
• Тестируем на реальных устройствах и сетях: 3G/4G, разные модели смартфонов, а не только на мощном ноутбуке в офисе.

Ключевой вопрос здесь: «Что даёт это изменение в реальных сценариях пользователя?» Если корзина стала открываться в 2 раза быстрее, а путь до оплаты сократился на секунды — это ценнее, чем плюс 3 балла в отчёте.

Реальные ограничения, выбор исполнителя и когда пора переписывать сайт

Есть ситуации, когда цели «90–100 в google pagespeed» упираются не в настройки, а в фундамент. Тяжёлые legacy-CMS, перегруженные плагины конструкторов, самописные решения на устаревшем стеке и десятки сторонних интеграций создают потолок, пробить который без серьёзной переработки почти нереально.

Сигналы, что проще переписать ядро, чем крутить гайки:

• каждая новая оптимизация даёт +5–10 баллов, но пользователи всё равно жалуются на медленную работу;
• любой небольшой рефакторинг стоит слишком дорого и занимает недели;
• страх что-то трогать, потому что «может всё сломаться».

Выбирая исполнителя под «оптимизацию под гугл спид», имеет смысл уточнять:

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

Наша команда делает сайты, веб-сервисы, CRM-системы, мобильные приложения, игры и интернет-магазины с прицелом на скорость и стабильность, а не только на красивый отчёт. Если нужен аудит скорости, понятный план достижения целевых показателей Google Speed или комплексная разработка/переработка проекта — можем подключиться и настроить всё так, чтобы и пользователи, и google были довольны.