Быстрый сайт на WordPress начинается с поиска медленного слоя
Медленная страница на WordPress может тратить время в нескольких местах: на загрузку изображений, ожидание PHP, запросы к базе данных или обращение к другому сервису. Установка ещё одного плагина кеширования без выявления задержки может скрыть одну проблему и создать вторую. Начните с воспроизводимого сценария и небольшого набора измерений.
Практический вывод
Измерьте фактический медленный сценарий, различите кешированные и персонализированные ответы, меняйте по одному слою за раз и подтвердите и скорость, и корректность, прежде чем оставлять оптимизацию.
Превратите «сайт медленный» в воспроизводимое наблюдение
Выберите страницу и точно опишите состояние посетителя. Первый визит к статье, вернувшийся покупатель, открывающий корзину, и администратор, сохраняющий запись, задействуют разные части WordPress. Запишите URL, авторизован ли пользователь, примерное время, устройство и сеть доступа. Повторяйте один и тот же сценарий, а не сравнивайте несвязанные страницы по памяти. Не допускайте попадания приватных данных аккаунта на скриншоты и в общие диагностические выгрузки.
Отделите ожидание первого ответа от работы, выполняемой после его получения. Браузер может быстро получить HTML и всё равно потратить несколько секунд на загрузку слишком больших изображений или выполнение сторонних скриптов. И наоборот, визуально простая страница может ждать медленной серверной работы. Отмечайте длительность ответа, переданные байты и неудавшиеся запросы вместе. Изолированная оценка менее полезна, чем понимание того, какой запрос задерживает нужную посетителям часть страницы.
| Наблюдение | Первый слой для проверки | Полезное сравнение |
|---|---|---|
| HTML приходит с задержкой | PHP, база данных или внешние вызовы | Тот же URL с тем же состоянием входа |
| HTML приходит быстро, страница остаётся тяжёлой | Изображения, шрифты и браузерные скрипты | Объём передачи и водопад запросов браузера |
| Медленно только у авторизованных посетителей | Персонализированная работа приложения | Анонимный и авторизованный сценарии по отдельности |
| Задержка появляется после обновления | Изменённый компонент или конфигурация | Записанная версия и контролируемый откат |
Знайте, что кеш на самом деле переиспользует
Кеширование страниц может переиспользовать сгенерированный ответ вместо его повторной сборки на каждый запрос. Это полезно для публичного контента, который выглядит одинаково для многих посетителей. Оно требует продуманных правил для страниц входа, корзин, оформления заказа, экранов аккаунта и других персонализированных ответов. Быстрая страница, показывающая данные не того клиента, — это неудачная оптимизация. Проверяйте поведение кеша в отдельных сессиях браузера и убеждайтесь, что приватные страницы обрабатываются так, как задумано приложением.
Кеширование объектов переиспользует данные приложения и представляет собой иной слой, нежели кеширование целой страницы. Браузерное кеширование определяет, что посетитель может переиспользовать локально. Кеш доставки контента может находиться в другом месте на пути запроса. Опишите слои, которые действительно есть в вашей установке, включая их срок действия и поведение при очистке. Не предполагайте, что панель управления, плагин или тариф хостинга включают конкретный сервис кеширования, если это не подтверждается доступной конфигурацией.
Для публичной статьи сравните первый запрос после очистки с последующими запросами. Большая разница может указывать на то, что работа по генерации переиспользуется; это не доказывает, какой слой выполнил переиспользование. Изучите соответствующую диагностику кеша или заголовки ответа, если они доступны. Для магазина отдельно проверьте изменённую цену товара и обновлённую корзину. Корректная инвалидация так же важна, как и результат замера на прогретом кеше.
Проследите некешируемую работу, прежде чем добавлять ресурсы
Изучите компоненты, задействованные в медленном сценарии. Тема может вызывать повторяющиеся запросы, плагин — обращаться к удалённой конечной точке, а запланированная задача — конкурировать с обычными запросами. Используйте диагностику, подходящую для вашей среды, и удаляйте временную диагностику после исследования. Для изоляции компонентов предпочтительна копия на стенде. Изменение нескольких плагинов на загруженном рабочем сайте затрудняет интерпретацию результата и может нарушить работу контента или заказов.
Работа с базой данных заслуживает отдельного исследования, если некэшированные запросы остаются медленными. Зафиксируйте, какие запросы часты или дороги и не повторяет ли приложение один и тот же поиск без необходимости. Изменение индекса, уменьшение результата запроса или исправленное поведение плагина могут помочь больше, чем дополнительные CPU. Если база данных ожидает блокировок, добавление воркеров PHP может усилить конкуренцию, а не повысить полезную пропускную способность. Интерпретируйте количество процессов вместе с длительностью ответа и успешными запросами.
Ресурсы хостинга по-прежнему важны, когда измерения показывают реальное ограничение. Учитывайте память, используемую всем приложением, параллельную работу PHP, активность базы данных и рост хранилища. Карточки веб-хостинга HM Bastion описывают лимиты сайта, хранилища и базы данных; это не опубликованное число гарантированных одновременных покупателей. Если проекту нужны собственные сервисы или контроль над операционной системой, сравните VPS с его фактическими ресурсами и ответственностью за администрирование, которая с ним связана.
Оставляйте изменение только после проверки всего пути
Запишите предлагаемое изменение и ожидаемый результат до его применения. Например, изменение размера слишком больших публичных изображений должно уменьшить передаваемые байты без изменения содержимого статьи. Исключение страниц аккаунта из кэша страниц должно сохранять конфиденциальность, даже если эти страницы останутся медленнее публичного контента. Сохраните актуальную резервную копию для восстановления и знайте, как отменить изменения конфигурации. После изменения используйте те же условия измерения, чтобы сравнение оставалось осмысленным.
- Проверьте публичную страницу как с пустым, так и с прогретым кэшем.
- Проверьте вход, выход, страницы аккаунта, поиск и любую корзину покупок.
- Убедитесь, что изменения контента становятся видимыми в течение предполагаемого времени.
- Сравнивайте ошибки и успешные ответы, а также скорость страниц.
- Запишите настройку, версию компонента и процедуру отката.
Ведите краткую запись производительности после немедленного улучшения. Отмечайте обычное время генерации страницы, типичные тяжёлые сценарии и объём свободной мощности, наблюдаемый во время обычных пиков. Возвращайтесь к этим наблюдениям после смены темы, крупного импорта или новой кампании. Полезный результат — сайт, поведение которого вы понимаете и можете поддерживать, а не набор пересекающихся плагинов, чья видимая скорость исчезает, когда посетитель входит в систему.
