Хостинг и производительность
Как мы ускоряем WordPress: LiteSpeed Enterprise, LSCache и Redis для каждого сайта
Самый быстрый запрос WordPress — это тот, который никогда не выполняется. Вот как наш стек обслуживает большинство визитов из кеша до запуска PHP или MySQL, и что это значит для Core Web Vitals.
Самый быстрый запрос — это тот, который никогда не выполняется
Стандартный запрос WordPress требует больших ресурсов. Веб-сервер передает задачу PHP, PHP запускает WordPress, выполняет плагины, делает несколько десятков запросов к MySQL, формирует HTML и только после этого отправляет байты обратно. На активном сайте вся эта цепочка выполняется для каждого посетителя, и именно на нее уходит почти все время до получения первого байта.
Наш ответ заключается в том, чтобы сделать так, чтобы для большинства посещений ничего из этого вообще не происходило. На сайтах, которые мы размещаем — более 100 000 PBN-сайтов, а также основные управляемые сайты WordPress — подавляющее большинство просмотров страниц во фронтенде отдаются в виде предварительно отрендеренной полной страницы прямо из кэша, без вызова PHP или обращения к базе данных. Остальная часть этого поста посвящена тому, как взаимодействуют слои, которые обеспечивают это, и каково назначение каждого из них.
Суть в том, что это не конкурирующие кэши, между которыми нужно выбирать. Кэш страниц, объектный кэш и CDN-эдж обрабатывают разные классы запросов, и их главная ценность заключается в том, как они передают запросы друг другу.
LiteSpeed Enterprise + LSCache: уровень полностраничного кэширования
Каждый сайт работает на LiteSpeed Enterprise с кэшированием LSCache на уровне сервера. Когда фронтенд-ответ допускает кэширование, веб-сервер помечает его заголовками управления кэшем и тегами LiteSpeed, а LiteSpeed отдает готовую страницу напрямую при следующем запросе: без запуска процессов PHP и без выполнения запросов MySQL. Это важнейший инструмент оптимизации TTFB для WordPress, поскольку он полностью исключает инициализацию приложения из критического пути выполнения.
Поскольку LSCache работает внутри веб-сервера, а не в плагине PHP, он начинает действовать раньше в цикле запроса и сохраняет страницы в виде, который сервер может мгновенно выгрузить. Обходчик кэша поддерживает популярные страницы в актуальном состоянии, поэтому первый посетитель после очистки не тратит время на повторную генерацию страницы. Результатом является заметно более низкое и стабильное значение TTFB по сравнению с кэшем только на базе плагина, добавленным к стандартному стеку, где кэш по-прежнему находится за PHP.
Наш собственный плагин кэширования уровня репозитория поставляется предустановленным и автоматически обновляется на каждом сайте, настраивая WordPress для работы с LSCache «из коробки». На сервере без LiteSpeed он просто не генерирует заголовочные данные полной страницы и не мешает работе, в то время как кэш объектов и правила исключений продолжают выполнять свои функции — поэтому перенесенный сайт никогда не останется в нерабочем полусконфигурированном состоянии.
Сохранение высокой скорости без выдачи устаревших данных: ESI и умная автоочистка
Агрессивное полностраничное кэширование имеет два классических режима сбоя: выдача авторизованному пользователю чужой страницы и выдача кому бы то ни было страницы, которая должна была измениться. Обе проблемы решаются на уровне кэширования, а не за счет сокращения кэша.
ESI (Edge Side Includes) позволяет кэшировать страницу, оставляя динамические блоки для элементов, которые должны оставаться активными. В магазине WooCommerce каталог, страницы товаров и категорий отдаются из полностраничного кэша для максимально быстрого TTFB, в то время как ESI отображает фрагмент корзины, итоговые суммы мини-корзины и состояние аккаунта для каждого запроса. Корзина, оформление заказа, личный кабинет и любые страницы с nonce или сессией исключаются по умолчанию. Покупатели всегда видят свою корзину и работающее оформление заказа, при этом витрина магазина для всех загружается из кэша.
Свежесть данных поддерживается с помощью умной автоочистки. Хуки очистки срабатывают автоматически при изменении контента, товаров, цен или заказов, поэтому соответствующие кэшированные страницы обновляются сразу же, а не по таймеру, кроме того, вы можете выполнять очистку по требованию из панели управления или прямо из WordPress. Теговая очистка означает, что при редактировании одной публикации очищается только она и ее архивы, а не весь кэш целиком, поэтому точечное редактирование не приводит к холодному старту всего сайта.
Объектный кэш Redis для каждого сайта: для того, что не может быть целой страницей
Не каждый запрос может быть статической полноразмерной страницей. Авторизованные сессии, административная панель WordPress, корзины WooCommerce, поиск и оставляемые ESI динамические фрагменты — всё это должно запускать PHP. Для них цель меняется с «пропустить приложение» на «пропустить базу данных».
Для каждого сайта выделяется собственный объектный кэш Redis. WordPress кэширует результаты повторяющихся запросов к базе данных — опции, transient-данные, поисковые запросы записей и таксономий, а также данные товаров и сессий WooCommerce — в оперативной памяти, благодаря чему один и тот же запрос не выполняется к MySQL при каждом обращении. Этот эффект наиболее заметен именно там, где кэширование страниц не помогает: ускоряется работа панелей управления и корзин, а нагрузка на базу данных при трафике существенно снижается.
Объектный кэш является изолированным для каждого сайта и не общим, что важно как для производительности, так и для изоляции. В сочетании с ограничением нагрузки на базу данных для каждого сайта, тяжелые или неоптимизированные запросы одного сайта не могут лишить базы данных соседние сайты. Подробнее о том, как устроена вся многоуровневая система, можно прочитать на нашей странице функций кэширования, а об ограничениях между арендаторами — в разделе об изоляции.
Граничный узел и транспортная сеть под ним
Кэш, который хранится на источнике, все равно должен передаваться по сети. Перед сервером располагается пограничный узел CDN, поэтому статические ресурсы и кэшируемые страницы отдаются из точки присутствия рядом с посетителем, а сервер-источник остается свободным даже под нагрузкой. В нашей линейке хостинга без цифровых следов тот же узел представляет собой пул из нескольких CDN от разных провайдеров, что служит как задаче минимизации следов, так и росту производительности; для обычного WordPress это просто быстрый, надежно работающий слой, который разгружает исходные серверы.
Под капотом нет никаких компромиссов. Сайты работают на хранилищах NVMe с поддержкой HTTP/3, поэтому те байты, которые кэш все же отправляет, передаются по современному мультиплексированному протоколу, а в случае промаха кэша задействуется высокоскоростная память. Ни один из этих уровней не является дополнением: LiteSpeed, LSCache, Redis для каждого сайта, NVMe и HTTP/3 входят в базовый набор для любого тарифного плана, а не предлагаются в качестве платного апгрейда.
Что на самом деле улучшает показатели Core Web Vitals
Здесь стоит быть точным, потому что хостинг часто продают с преувеличением возможностей в отношении Core Web Vitals. TTFB — это та часть уравнения, за которую отвечает сервер, а расположенный выше стек кеширования позволяет снизить этот показатель: полностью кешированная страница, отданная по протоколу HTTP/3 с периферийного узла, имеет минимально возможный TTFB. Поскольку TTFB является отправной точкой для Largest Contentful Paint, быстрый источник дает каждому последующему метрическому показателю фору, которую он иначе получить не сможет.
Но LCP, CLS и INP в основном определяются в браузере, самой страницей: неоптимизированное главное изображение, блокирующие рендеринг CSS и JavaScript, макет, который смещается при загрузке шрифтов и рекламы, а также тяжелая работа плагинов в основном потоке. Никакое серверное кэширование не исправит главное изображение размером 2 МБ или тему, которая загружает мегабайты JavaScript. Честный хостинг делает вклад сервера практически нулевым и стабильным, а дальше уже сам сайт должен заботиться о том, чтобы интерфейс оставался легким.
Это разделение труда является полезной ментальной моделью. Мы гарантируем, что запрос быстро поступает в браузер и остается быстрым при росте трафика; вы следите за тем, чтобы полезная нагрузка оставалась небольшой и стабильной. Точка их пересечения — предварительный разогрев кэша, доставка с периферии и поддержание высокой отзывчивости базы данных, чтобы динамические страницы не зависали — это именно то, на что настроен наш стек, и именно это делает управляемый WordPress на нашей платформе быстрее, чем тот же сайт на обычном хостинге.
Часто задаваемые вопросы
Нужен ли мне по-прежнему плагин кэширования, такой как WP Rocket?
Нет. Кэширование целых страниц обрабатывается на уровне веб-сервера с помощью LSCache от LiteSpeed, а наш собственный плагин кэширования — предустановленный и автоматически обновляемый — правильно связывает с ним WordPress вместе с объектным кэшем Redis для каждого сайта. Установка второго плагина кэширования страниц обычно конфликтует с кэшем на уровне сервера, а не помогает, поэтому в нем нет необходимости, и мы его не рекомендуем.
Сломает ли кэширование мою корзину WooCommerce или страницы авторизованных пользователей?
Нет. Корзина, оформление заказа, личный кабинет и любые страницы с nonce или сеансами исключаются из кэша по умолчанию, а ESI поддерживает актуальность фрагмента корзины и итоговых сумм на остальных кэшированных страницах. Покупатели всегда видят собственную корзину и работающее оформление заказа, в то время как витрина по-прежнему загружается из кэша.
Как кеш обновляется при публикации или редактировании?
Интеллектуальная автоочистка срабатывает по соответствующим хукам WordPress, поэтому публикация, редактирование контента или изменение товара, цены либо заказа очищают только затронутые страницы и их архивы — а не весь кеш — а обходчик разогревает их заново. Вы также можете выполнить очистку по требованию из панели управления или прямо из WordPress.
Может ли один только хостинг обеспечить мне идеальные Core Web Vitals?
Это обеспечивает наилучший возможный показатель TTFB, который представляет собой вклад сервера и фору для Largest Contentful Paint. Но LCP, CLS и INP в значительной степени зависят от самой страницы — размеров изображений, блокирующих рендеринг ресурсов, стабильности макета и JavaScript в основном потоке. Наш стек делает вклад сервера быстрым и стабильным, а сокращение объема фронтенд-данных позволяет преодолеть оставшийся разрыв.
Похожие
Попробуйте бесплатно в течение 14 дней
Запустите свои первые сайты бесплатно на 14 дней без привязки карты. Переносите существующую сеть? Первую миграцию мы берем на себя.
Начать бесплатно