Скорость сайта: как проверить PageSpeed и что исправлять первым

Коротко. Скорость сайта не сводится к одной оценке. Это несколько метрик: когда появляется основной контент, как быстро сайт реагирует на действия и насколько сильно страница сдвигается при загрузке. PageSpeed Insights показывает лабораторные и полевые данные, но его оценка не равна позиции в поиске.

Что значит «быстрый сайт»

Скорость складывается из нескольких вещей:

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

PageSpeed показывает сводку лабораторных проверок. Она полезна как ориентир, но не показывает, как сайт ощущается у реальных пользователей. Для этого есть полевые данные Chrome UX Report.

LCP, INP, CLS и TTFB

Пороговые значения взяты из документации web.dev. Проверяйте их актуальность перед отчётом клиенту.

• LCP показывает, когда загрузился главный элемент страницы: изображение, заголовок, блок.
• INP заменил FID и показывает, как быстро интерфейс отвечает на клики и ввод.
• CLS показывает, насколько сильно страница «прыгает» при загрузке.
• TTFB показывает скорость ответа сервера.

Как измерить скорость

Минимальный набор:

1. PageSpeed Insights: лабораторные и полевые данные для URL.
2. Chrome UX Report: реальные данные пользователей Chrome.
3. DevTools → Performance: профиль загрузки и взаимодействий.
4. WebPageTest: сценарии и разные сети, если нужен глубокий разбор.

Проверяйте мобильную версию. Google индексирует мобильную версию, а не desktop. Один замер ничего не доказывает: сделайте 3–5 прогонов и сравните.

Лабораторные и полевые данные

Лабораторные данные PageSpeed показывают, как страница грузится в управляемых условиях. Полевые данные Chrome UX Report собирают реальные измерения пользователей Chrome. Они могут расходиться: быстрый лабораторный прогон не гарантирует хороший опыт на слабом телефоне.

Смотрите на оба слоя. Если полевое значение плохое, а лабораторное хорошее, ищите разницу в устройствах, сетях, географии и сторонних скриптах.

Где теряется скорость

• Медленный сервер и высокий TTFB.
• Тяжёлые изображения без сжатия и правильных размеров.
• Большой JavaScript, который блокирует отображение.
• Много сторонних скриптов: аналитика, чаты, пиксели, виджеты.
• Шрифты, которые загружаются поздно или тянут лишние начертания.
• Отсутствие кеширования и CDN.
• Layout shift из-за картинок без размеров, баннеров и вставок.
• Блокирующий CSS.

Приоритеты

Не начинайте с косметики. Сначала уберите то, что сильнее всего влияет на метрику.

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

1. Снимите базу

Запишите LCP, INP, CLS, TTFB и оценку PageSpeed до изменений. Отдельно сохраните, какие элементы являются LCP и какие скрипты грузятся первыми.

2. Проверьте TTFB и сервер

Если TTFB высокий, оптимизация картинок не спасёт. Проверьте:

• время ответа сервера;
• кеширование страниц;
• базу и тяжёлые запросы;
• CDN;
• регион сервера.

Быстрый способ посмотреть время ответа:

curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://example.com/

3. Займитесь LCP-элементом

Найдите, что именно является LCP: изображение, заголовок или блок. Дальше:

• сожмите изображение и отдайте WebP или AVIF;
• укажите width и height;
• не ставьте loading="lazy" на LCP-изображение;
• при необходимости добавьте fetchpriority="high";
• используйте srcset и sizes, чтобы не отдавать десктопную картинку телефону;
• уберите лишние обёртки и блокирующие ресурсы.

Пример для LCP-изображения:

<img src="hero.avif" width="1200" height="630" fetchpriority="high" alt="...">

4. Уменьшите JavaScript

• Уберите неиспользуемые библиотеки.
• Разделите код по страницам.
• Отложите некритичные скрипты.
• Проверьте сторонние виджеты: часто они дороже собственного кода.
• Не подключайте тяжёлый чат или аналитику без необходимости.

Если скрипт не нужен до взаимодействия, используйте defer:

<script src="/app.js" defer></script>

5. Оптимизируйте CSS и шрифты

• Уберите неиспользуемый CSS.
• Подключите критический CSS для первого экрана.
• Ограничьте набор шрифтов и начертаний.
• Используйте font-display: swap.
• Предзагружайте только те шрифты, которые действительно нужны.

6. Настройте кеш и CDN

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

Пример для файлов с хешем в имени:

Cache-Control: public, max-age=31536000, immutable

Для HTML лучше короткий кеш или проверка актуальности, иначе пользователи будут видеть старую версию.

7. Проверьте CLS

• У картинок и видео должны быть размеры.
• Баннеры и cookie-плашки не должны сдвигать контент.
• Шрифты не должны менять размеры блоков после загрузки.
• Вставки рекламы и виджетов резервируют место заранее.

Проверка после изменений

Меняйте по одному. После каждого шага запускайте PageSpeed Insights и DevTools, сравнивайте LCP, INP, CLS и TTFB. Общая оценка может колебаться, поэтому смотрите на метрики и на повторяемость результата.

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

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

Частые ошибки

• Гнаться за 100/100 и игнорировать полевые метрики.
• Ставить loading="lazy" на LCP-изображение.
• Предзагружать всё подряд.
• Отключать кеш, чтобы «всё обновлялось».
• Проверять только desktop.
• Делать один замер и верить ему.
• Оптимизировать картинки при медленном сервере.
• Подключать новые виджеты без замера.
• Считать оценку PageSpeed прямым ranking factor.

Когда нужен редизайн, а не оптимизация

Иногда проблема не в картинках, а в архитектуре:

• сайт собирается на тяжёлом конструкторе;
• каждая страница тянет десятки скриптов;
• мобильная версия — отдельная и устаревшая;
• шаблон не позволяет управлять загрузкой ресурсов.

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

Вопросы

Оценка PageSpeed влияет на позиции?

Оценка сама по себе нет. Core Web Vitals используются как сигнал page experience, но это не единственный фактор. Смотрите на полевые метрики и общую пользу страницы.

Что важнее: LCP, INP или CLS?

Все три входят в Core Web Vitals. Начинайте с того, что хуже и что влияет на пользователя. Часто первым делом стоит TTFB и LCP.

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

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

Нужно ли стремиться к 100?

Нет. Ориентируйтесь на пороги Core Web Vitals и реальный опыт пользователей. 100/100 не гарантирует ни позиций, ни конверсии.

Может ли нейросеть ускорить сайт?

Нет. Она помогает разобрать отчёт, приоритизировать исправления и подготовить план. Изменения и замеры делаются на сайте.

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

Источники