Оптимизация сайта, техническое SEO и отчёты PageSpeed Insights

Что входит в техническую оптимизацию сайта

Скорость загрузки — только часть технического состояния сайта. Полноценная техническая оптимизация обычно охватывает несколько направлений сразу:

• Производительность — скорость ответа сервера, загрузка HTML, изображений, CSS и JavaScript;
• Core Web Vitals — LCP, INP и CLS, то есть реальный пользовательский опыт;
• Индексация — robots.txt, sitemap.xml, canonical, корректные HTTP-коды;
• HTML и метаданные — title, description, заголовки, структура документа, микроразметка Schema.org;
• Мобильная версия — корректное отображение и удобное взаимодействие на маленьком экране;
• Инфраструктура — HTTPS, кэширование, сжатие, CDN.

PageSpeed Insights затрагивает часть этих направлений, но не заменяет полный технический аудит — это скорее точка входа в диагностику.

Два источника данных в одном отчёте

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

Lab Data — лабораторные данные

Это результат теста Lighthouse в контролируемых условиях — эмулируемое устройство и заданная скорость сети, зафиксированные в момент проверки. Такой тест хорошо показывает, какие именно ресурсы тормозят загрузку, но результат может немного отличаться от проверки к проверке — это нормально.

Field Data — полевые данные

Вторая часть построена на данных Chrome User Experience Report (CrUX) — это агрегированная статистика реальных посетителей сайта за последние 28 дней. Именно эти показатели ближе к тому, что видят живые пользователи, и именно на них ориентируется Google при оценке Core Web Vitals как фактора ранжирования.

Core Web Vitals: три метрики, на которые стоит смотреть в первую очередь

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

• LCP (Largest Contentful Paint) — время появления самого крупного видимого элемента (баннер, заголовок, главное изображение). Хорошо — до 2,5 секунды, плохо — свыше 4 секунд;
• INP (Interaction to Next Paint) — задержка отклика на действия пользователя: клик, тап, ввод в поле. Хорошо — до 200 мс, плохо — свыше 500 мс;
• CLS (Cumulative Layout Shift) — насколько сильно элементы страницы «прыгают» при загрузке. Хорошо — не более 0,1, плохо — свыше 0,25.

К ним часто добавляют ещё один диагностический показатель — TTFB (Time to First Byte), время до получения браузером первого байта ответа сервера. Формально он не входит в Core Web Vitals, но напрямую влияет на LCP: пока сервер не ответил, браузер физически не может начать отрисовку страницы.

LCP — от чего зависит скорость появления контента

На LCP влияет вся цепочка загрузки: скорость ответа сервера (TTFB), момент обнаружения главного ресурса браузером, собственно загрузка этого ресурса и, наконец, отрисовка. Поэтому рекомендация «улучшить LCP» сама по себе не диагноз — нужно понять, на каком именно этапе цепочки происходит задержка.

INP — почему JavaScript чаще всего виноват

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

CLS — почему страница «прыгает»

Типичная причина — изображения и блоки без заданных размеров: браузер не знает заранее, сколько места им отвести, и сдвигает уже отрисованный контент, когда ресурс наконец загружается. Исправляется чаще всего просто — явными атрибутами width/height у изображений и видео и зарезервированным местом под динамические блоки (баннеры, уведомления, рекламу).

Почему результат может меняться от проверки к проверке

«Вчера было 96 баллов, сегодня 87 — я ничего не менял» — частая ситуация, и это не ошибка инструмента. Лабораторный тест зависит от условий конкретного запуска, а на реальные показатели влияет множество факторов: нагрузка на сервер в момент запроса, сеть, устройство посетителя, состояние кэша, сторонние сервисы. Поэтому единичный запуск PageSpeed Insights не стоит воспринимать как окончательный вердикт — гораздо полезнее смотреть на повторяемый результат и динамику после конкретных изменений.

Почему не стоит гнаться за 100 баллами ради самой цифры

Легко представить страницу, которая получила 100 баллов по Performance, но при этом у неё нет нормальных метатегов, важный контент подгружается через JavaScript и недоступен поисковым роботам, а мобильная версия неудобна в использовании. Формально показатель отличный — практически сайт далёк от идеала.

Google рассматривает Lighthouse как диагностический инструмент, а не как экзамен на 100/100: значение 90+ — просто хороший результат лабораторного теста. Более полезная цель звучит иначе: не красивая цифра, а сайт, который быстро и стабильно работает для реальных посетителей.

Практический чек-лист: куда чаще всего уходит скорость

Изображения — обычно самый быстрый эффект

• переводить фотографии в современные форматы — WebP или AVIF — вместо PNG/JPEG;
• отдавать изображение реального размера отображения, а не оригинал 3000×2000 px под блок шириной 600 px;
• откладывать загрузку (loading="lazy") для всего, что не видно на первом экране;
• для главного LCP-изображения — наоборот, не откладывать загрузку и явно повышать его приоритет.

CSS и JavaScript

• определить, какой CSS нужен для первого экрана, а какой можно грузить позже или только на отдельных страницах;
• убрать неиспользуемые стили и скрипты — библиотеки, виджеты и аналитику, которые фактически не нужны на конкретной странице;
• подключать сторонние скрипты асинхронно (async/defer), чтобы они не блокировали отрисовку;
• смотреть на JavaScript в первую очередь при плохом INP — часто именно он занимает основной поток браузера.

Сервер и кэширование

• включить сжатие Gzip или Brotli — это уменьшает вес HTML, CSS и JS без изменения самого кода;
• настроить кэширование статических ресурсов (изображения, шрифты, CSS, JS), чтобы браузер не скачивал их заново при каждом визите;
• проверить TTFB отдельно — если сервер отвечает медленно, оптимизация одних только изображений не даст ожидаемого эффекта.

Техническое SEO — это не только скорость

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

• Индексацию — корректный robots.txt (важно не заблокировать в нём CSS, JS и изображения — это мешает Google оценивать рендеринг страницы), sitemap.xml, canonical, отсутствие дублей URL;
• Структуру страницы — один основной H1, логичная иерархия заголовков, понятные внутренние ссылки;
• Метаданные — title, description, Open Graph, при необходимости — микроразметка Schema.org;
• Мобильную версию — не просто «умещается» на экране смартфона, а остаётся удобной для взаимодействия: это особенно важно при mobile-first индексации Google.

Как читать отчёт по шагам

Удобнее всего работать с отчётом последовательно, а не пытаться исправить все предупреждения сразу:

1. Зафиксировать исходное состояние — мобильный и desktop результат, Core Web Vitals, TTFB, основные рекомендации;
2. Найти главную проблему — например, если LCP большой из-за высокого TTFB, проблема на стороне сервера, а не в изображениях;
3. Исправить самую дорогую по эффекту проблему — не двадцать пунктов сразу, а один-два с наибольшим потенциальным приростом;
4. Повторить измерение — желательно менять что-то одно за раз, чтобы понимать, какое изменение действительно дало результат.

Такой цикл — показатель → проблема → причина → исправление → повторное измерение — и есть по сути вся техническая оптимизация. Разовая «уборка» перед запуском помогает, но реальный эффект даёт именно повторяемый процесс.

Часто задаваемые вопросы

Что дальше

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