Скорость загрузки сайта: как ускорить страницы и проверить Core Web Vitals

Выберите страницу и пользовательское действие

Для интернет-магазина важны открытие карточки, выбор варианта и доступность следующего действия. Для статьи — появление заголовка, основного текста, таблиц и нужной иллюстрации. Если измерить только главную, проблема вложенного шаблона может остаться незамеченной.

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

Core Web Vitals: три метрики и разные источники

В актуальном наборе LCP характеризует появление основного крупного содержимого, INP — отзывчивость взаимодействий, CLS — визуальную стабильность. Рекомендуемые хорошие пороги: LCP не более 2,5 секунды, INP не более 200 мс, CLS не более 0,1.

Полевую оценку проводят по 75-му процентилю с разделением мобильных и настольных устройств. Лабораторный запуск помогает найти причину, но не заменяет распределение реальных посещений. Отсутствие достаточных полевых данных означает отсутствие этой оценки, а не автоматический успех.

INP требует взаимодействий; статическое открытие страницы не проверяет отзывчивость всех сценариев. Скриншот готовой страницы также не показывает накопленные сдвиги во время загрузки. Выбирайте инструмент и процедуру под измеряемое свойство.

Источники: web.dev: Core Web Vitals

Бюджет ресурсов для учебного лонгрида

Ниже полностью вымышленные значения передаваемых ресурсов. Это бюджет для объяснения приоритетов, не измерение нашего сайта и не норматив Google. В реальном проекте значения берут из сетевого отчёта, сохраняя различие между исходным размером и переданными байтами.

В примере HTML даже немного увеличился из-за полезных таблиц. Основная экономия достигнута изображениями и ненужными скриптами. Поэтому требование сократить статью ради скорости могло бы ухудшить содержание, почти не затронув настоящую причину.

Сумма до: 38 + 36 + 140 + 900 + 280 + 20 = 1414 КиБ. После: 45 + 24 + 55 + 95 + 70 + 10 = 299 КиБ. Разница 1115 КиБ описывает только этот синтетический бюджет. Она не преобразуется автоматически в выигрыш LCP или продаж.

Waterfall: где возникает ожидание

Учебная последовательность ниже показывает зависимость шагов, а не результаты сетевого теста. Если LCP-картинка обнаруживается поздно, уменьшение её размера решает лишь часть задержки. Нужно также понять, когда клиент узнал об адресе и мог начать запрос.

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

Источники: web.dev: оптимизация LCP

Лёгкий шаблон статьи и работа с изображениями

Основной текст может приходить в содержательном HTML, подготовленном статически или на сервере. Выбор SSG или SSR зависит от частоты обновления и архитектуры. Само название способа не гарантирует быстрый ответ: серверные зависимости и кэш тоже нужно проверять.

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

Вероятный LCP-элемент первого экрана не следует бездумно делать lazy-loading. Проверьте его раннее обнаружение и приоритет по рекомендациям инструмента. Предзагрузка всех картинок тоже не является решением: она может конкурировать с действительно важными ресурсами.

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

Источники: web.dev: оптимизация LCP

Продолжить: Как проверить содержательный HTML и JavaScript

Карточка товара: сохраняйте основной сценарий

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

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

Как провести холодную мобильную проверку

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

Повторите несколько запусков по тому же правилу и сохраните разброс, а не только лучший результат. Затем проверьте тёплую загрузку отдельно: она отвечает на другой сценарий. Не смешивайте её с холодными запусками в одной строке «после».

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

Что должно быть в приёмке ускорения

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

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

Источники: web.dev: Core Web Vitals

Продолжить: Как выбрать длину статьи без лишних разделов