Проходите чек-лист в порядке, который подсказывают данные
Этот чек-лист из 47 пунктов — рабочий аудит для сайтов на WordPress. Он не обещает определённого времени загрузки или оценки: хостинг, контент, устройства посетителей и бизнес-требования различаются. Начните с проблемного пользовательского опыта, выберите подходящие проверки и проверяйте по одному типу изменений за раз.
Устраняйте измеренные узкие места раньше, чем занимаетесь тонкой настройкой сервера. Изменение, которое экономит небольшой запрос, но ломает оформление заказа, — это регрессия, даже если лабораторная оценка выросла.
Зафиксируйте исходную точку
- Выберите типовые URL главной, статьи, архива, товара и оформления заказа; включите авторизованные и анонимные сессии.
- Записывайте регион хостинга, устройство, условия сети, браузер и версию релиза, чтобы последующие замеры были сопоставимы.
- Запускайте воспроизводимые лабораторные тесты несколько раз и сохраняйте диапазон, а не только самый быстрый результат.
- Смотрите LCP, INP и CLS реальных пользователей, если есть полевые данные; отличайте данные URL от данных источника.
- Изучите запрос документа и разделите задержки DNS, соединения и ответа сервера.
- Запишите трассировку основного потока, воспроизводя медленное взаимодействие, а не только первоначальную загрузку.
- Найдите фактический элемент LCP и цепочку запросов, нужную для его отображения.
- Сделайте восстанавливаемую резервную копию и определите ключевые пользовательские сценарии, которые должны работать после изменений.
Сократите работу исходного сервера
- Используйте поддерживаемую и совместимую с сайтом версию PHP; проверяйте обновления на тестовом стенде перед продакшеном.
- Проверьте состояние и объём OPcache. Не отключайте проверку временных меток, если деплой явно не сбрасывает кеш.
- Профилируйте медленные участки PHP и повторяющиеся запросы к базе данных, прежде чем менять настройки сервера.
- Проверьте запросы к удалённым API во время рендеринга страницы; используйте подходящее кеширование и ограниченные тайм-ауты.
- Уточните у хостера наличие постоянного объектного кеша и проверьте инвалидацию при изменении контента.
- Кешируйте публичный HTML только там, где это безопасно; исключайте авторизованные ответы, корзину, оформление заказа и персонализированные ответы.
- Убедитесь, что два разных пользователя не могут получить кешированные данные друг друга.
- Проверьте загрузку процессора, памяти и воркеров под типичной нагрузкой, прежде чем увеличивать параллелизм.
- Проверьте выполнение запланированных задач. Если переносите WP-Cron на системный планировщик, отслеживайте пропущенные и неудачные задачи.
- Изучите планы запросов, прежде чем добавлять индексы; оцените нагрузку на запись и тестируйте на репрезентативной копии данных.
- Разберите слишком большие автозагружаемые опции вместе с плагином, которому они принадлежат. Сделайте резервную копию перед точечной очисткой.
- Используйте постраничную выборку для больших запросов и не загружайте в память неограниченные коллекции.
Улучшите рендеринг и взаимодействие
- Удаляйте неиспользуемые скрипты и стили только после проверки меню, форм, оформления заказа и требований редактора.
- Откладывайте совместимые скрипты с сохранением порядка зависимостей; async не заменяет упорядоченного выполнения.
- Изучите стили, блокирующие рендеринг. Проверяйте любой подход с критическим CSS на всех шаблонах и размерах экрана.
- Оставляйте изображение LCP обнаруживаемым в исходном HTML, а не вставляйте его позже через JavaScript.
- Не применяйте ленивую загрузку к изображению LCP. Используйте высокий приоритет загрузки выборочно, а затем проверяйте водопад запросов.
- Разбивайте тяжёлый JavaScript на измеренные части и при необходимости возвращайте управление браузеру между ними.
- Группируйте чтение и запись макета, чтобы избежать повторных принудительных перерасчётов.
- Удаляйте ненужные сторонние виджеты; откладывайте необязательные, только если их поведение и правила согласия это позволяют.
- Резервируйте размеры изображений, встраиваемого контента и рекламы до загрузки их ресурсов.
- Проверьте метрики резервного шрифта и сдвиги макета; используйте font-display осознанно.
- Сохраняйте интерактивные элементы доступными при навигации с клавиатуры и при уменьшенной анимации.
- Тестируйте длинные страницы и маломощные устройства; быстрая главная страница не доказывает, что быстр каждый шаблон.
Отдавайте ресурсы подходящего размера
- Выбирайте ширину изображения по месту, где оно отображается, и ожидаемой плотности пикселей.
- Сравнивайте AVIF, WebP и существующие форматы на реальном файле, а не рассчитывайте на фиксированную экономию.
- Предоставляйте адаптивные варианты srcset и значение sizes, отражающее макет.
- Применяйте ленивую загрузку к изображениям за пределами экрана и асинхронное декодирование, где это уместно.
- Оставляйте важные подписи и пояснения в HTML; мелкий текст внутри изображений трудно читать.
- Размещайте шрифты на своём сервере или иначе сокращайте запросы шрифтов; загружайте только нужные сайту начертания и наборы символов.
- Предзагружайте только действительно критичные ресурсы, предварительно проверив водопад запросов.
- Проверьте сжатие gzip или Brotli для текстовых ресурсов и не пережимайте уже сжатые изображения.
- Используйте долгосрочное кеширование для версионированных статических ресурсов и меняйте их URL при изменении содержимого.
- Загружайте видео осознанно. Скрытие видео только средствами CSS не гарантирует, что загрузка остановится.
Проверьте релиз
- Протестируйте вход, поиск, контактные формы, корзину и оформление заказа после включения любой оптимизации.
- Проверьте заголовки кеширования и инвалидацию контента на отредактированных страницах.
- Повторите исходные лабораторные тесты в тех же условиях и зафиксируйте как улучшения, так и регрессии.
- Отслеживайте полевые метрики со временем; релиз не отражается сразу в скользящем окне данных.
- Установите бюджеты производительности и ведите журнал изменений, чтобы будущую регрессию можно было связать с релизом.
Частые вопросы
Что исправлять в первую очередь?
Если медленно приходит исходный документ, профилируйте источник и поведение кеша. Если документ приходит быстро, а основной контент появляется поздно, изучите ресурс LCP и путь рендеринга. Если после загрузки клики ощущаются медленными, исследуйте работу JavaScript и макета во время взаимодействия. Отражайте это различие в заметках аудита.
Приводит ли низкая оценка Lighthouse к фиксированному понижению в поиске?
Ни одно опубликованное правило не назначает фиксированного понижения в Google за оценку Lighthouse ниже определённого числа. Используйте оценку, чтобы находить технические возможности, а полевые данные — чтобы понимать реальных посетителей.
Нужно ли применять все 47 проверок к каждому сайту на WordPress?
Нет. Используйте чек-лист, чтобы определить нужные проверки, а затем в первую очередь устраняйте узкое место, влияющее на важный путь клиента. У сайта-визитки и нагруженного магазина на WooCommerce разные требования. Записывайте, почему проверка применима, отложена или не нужна.
Что тестировать после изменения настроек кеша или скриптов?
Проверьте меню, поиск, формы, вход и оформление заказа, если оно есть. Протестируйте разные сессии, отредактируйте и снимите с публикации контент, чтобы проверить инвалидацию, и сравните производительность с исходной точкой. Держите наготове откат на случай, если оптимизация сломает нужное взаимодействие.
Источники и дополнительное чтение
Читайте дальше
Разберитесь в диагностике TTFB и Core Web Vitals и доставке адаптивных изображений.
Leave a Reply