Начинайте с симптома, а не с плагина
Страница может отвечать быстро и всё равно казаться медленной. Time to First Byte (TTFB) показывает, сколько навигация ждёт первого байта ответа; Largest Contentful Paint (LCP) касается самого крупного видимого элемента; Interaction to Next Paint (INP) — реакции на клики, касания и клавиатуру. Улучшение одного показателя не исправляет остальные автоматически.
Это руководство по диагностике, а не отчёт об измеренном клиентском проекте. Решайте, сработало ли изменение, по собственным данным до и после.
Создайте сопоставимую исходную точку
- Выберите типовые шаблоны: статью, категорию, товар и оформление заказа. Включите авторизованные и анонимные сессии.
- Записывайте устройство, сеть, местоположение, URL, состояние кеша и развёрнутую версию. Повторяйте лабораторные тесты в одинаковых условиях, а не выбирайте лучший результат.
- Смотрите полевые данные в PageSpeed Insights или Search Console. У URL с небольшим трафиком может не быть собственных данных; данные на уровне источника шире, и их нужно так и обозначать.
- Разделяйте попадания и промахи кеша. Быстрый ответ из тёплого кеша может скрывать медленный источник во время инвалидации или пика трафика.
Безопасно сокращайте работу сервера
Изучите запрос документа на панели «Сеть» в браузере, затем профилируйте PHP, запросы к базе данных и обращения к внешним API. Медленные запросы, повторяющиеся удалённые вызовы, перегруженные процессы и удалённый источник требуют разных решений. Постоянный объектный кеш может сократить повторную работу с базой, но это не то же самое, что кеширование полного HTML-ответа.
Полностраничный кеш может помочь для анонимных редакционных страниц. Не помещайте в публичный кеш страницы аккаунта, корзины, оформление заказа, авторизованные ответы и ответы с персональными данными. Проверьте с хостинг-провайдером cookies, методы запросов, параметры URL и ключи кеша. Перед деплоем протестируйте с двумя независимыми сессиями и убедитесь, что правки контента инвалидируют соответствующий кеш.
Улучшайте то, что отрисовывает браузер
Найдите фактический элемент LCP в трассировке производительности. Если это изображение, сделайте его URL видимым в исходном HTML, отдавайте варианты подходящего размера и не применяйте к нему ленивую загрузку. Если это текст, проверьте блокирующие рендеринг стили и загрузку шрифтов. Резервируйте место под изображения и встраиваемый контент, чтобы уменьшить сдвиги макета.
Для INP воспроизведите медленное взаимодействие и изучите основной поток. Уменьшите лишнюю работу, разбейте длинные задачи и группируйте чтения макета перед записью. Перенос работы в более позднюю задачу помогает, только если эта задача сама не превращается в ещё один крупный блок.
// Yield between bounded chunks; feature-detect the scheduling API.
async function yieldToBrowser() {
if (globalThis.scheduler?.yield) {
await globalThis.scheduler.yield();
} else {
await new Promise(resolve => setTimeout(resolve, 0));
}
}
// Process a small, measured batch, yield, then process the next batch.Проверяйте опыт пользователей после деплоя
Хорошими порогами Core Web Vitals считаются LCP не более 2,5 секунды, INP не более 200 миллисекунд и CLS не более 0,1 при оценке по 75-му процентилю посещений. TTFB помогает в диагностике, но сам по себе не входит в Core Web Vitals. Тест загрузки в Lighthouse не измеряет INP реальных сессий.
Повторно проверьте оформление заказа, навигацию, инструменты согласия и сторонние виджеты. Отслеживайте полевые измерения со временем: скользящее окно сбора данных не отразит релиз сразу. Записывайте изменение и любые регрессии рядом с измерениями.
Частые вопросы
Гарантирует ли прохождение Core Web Vitals более высокие позиции?
Нет. Более быстрый сайт помогает читателям и может поддержать результаты в поиске, но релевантность, полезный контент и другие сигналы по-прежнему важны. Относитесь к скорости как к измеримому улучшению продукта, а не как к обещанию позиций.
TTFB входит в Core Web Vitals?
Нет. TTFB измеряет задержку до первого байта ответа и помогает диагностировать путь через сервер и сеть. Core Web Vitals — это LCP, INP и CLS. Используйте TTFB для расследования медленного ответа, а затем отдельно проверьте, когда появляется полезный контент и как ведут себя взаимодействия.
Почему главная страница из кеша быстрая, а оформление заказа медленное?
Публичная главная страница может повторно использовать HTML из кеша, а оформлению заказа нужна свежая работа для каждой сессии. Измерьте некешированный запрос и изучите запросы к базе данных, расширения и внешние сервисы. Не делайте оформление заказа публично кешируемым ради хорошего теста; проверьте конфиденциальность и корректность транзакций.
Как сравнить производительность до и после изменения?
Сохраняйте сопоставимыми URL, устройство, сетевой профиль и состояние кеша и повторяйте тест. Записывайте разброс результатов и проверяйте одно и то же действие клиента. Используйте полевые данные по мере их появления: один быстрый лабораторный тест не описывает всех посетителей. Чек-лист производительности предлагает более широкую последовательность проверок.
Источники и дополнительное чтение
Читайте дальше
Используйте чек-лист скорости WordPress из 47 пунктов для более широкого аудита или узнайте об услуге по ускорению сайтов.
Leave a Reply