Хостинг и производительность
Как мы ускоряем WordPress: LiteSpeed Enterprise, LSCache и выделенный Redis для каждого сайта
Самый быстрый запрос WordPress — это тот, который никогда не выполняется: узнайте, как наш стек отвечает на большинство посещений из кэша еще до вызова PHP или MySQL, и что это значит для Core Web Vitals.
Самый быстрый запрос — тот, который никогда не выполняется
Стандартный запрос к WordPress ресурсоемок. Веб-сервер передает управление PHP, PHP загружает WordPress, выполняет плагины, отправляет несколько десятков запросов к MySQL, собирает HTML и только после этого отправляет байты обратно. На посещаемом сайте вся эта цепочка действий происходит для каждого посетителя, и именно на это уходит почти весь ваш time-to-first-byte.
Наш ответ заключается в том, чтобы сделать так, чтобы для большинства посещений ничего из этого вообще не происходило. На всех сайтах, которые мы размещаем — а это более 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 кэширует в оперативной памяти результаты повторяющихся операций чтения из базы данных — опции, временные данные (transients), поисковые запросы записей и таксономий, данные о товарах и сессиях WooCommerce, — благодаря чему один и тот же запрос не отправляется к MySQL при каждом обращении. Результат наиболее заметен именно там, где кэширование страниц целиком бессильно: более быстрая работа панели управления, ускорение корзины покупок и значительно меньшая нагрузка на базу данных при высоком трафике.
Кэш объектов изолирован для каждого сайта и не является общим, что важно как для производительности, так и для изоляции. В сочетании с ограничением нагрузки на базу данных на уровне сайта, тяжелые или некорректно составленные запросы одного сайта не смогут лишить ресурсов базы данных соседние сайты. Вы можете узнать больше о том, как функционирует вся многоуровневая система, на странице с описанием функций кэширования, а также о границах между арендаторами в разделе об изоляции.
Периферия и транспорт под ней
Кэшу, находящемуся на сервере-источнике, всё равно приходится проходить через сеть. Перед сервером располагается граничный узел CDN, поэтому статические ресурсы и кэшируемые страницы доставляются из точки присутствия, расположенной ближе к посетителю, а сервер-источник остаётся ненагруженным даже в моменты пикового трафика. В нашей линейке хостинга footprint-free этот же граничный узел представляет собой пул multi-CDN, распределённый по нескольким провайдерам, что решает как задачу скрытия сетевого следа (footprint), так и задачу повышения производительности; на стандартном WordPress это просто быстрый и слаженный уровень, сохраняющий серверы-источники в покое.
В основе инфраструктуры нет никаких компромиссов. Сайты работают на NVMe-накопителях с HTTP/3, поэтому байты, отправляемые кэшем, передаются по современному мультиплексированному транспорту с быстрым хранилищем на случай любого промаха кэша. Ни один из этих уровней не является платным дополнением: LiteSpeed, LSCache, отдельный Redis для каждого сайта, NVMe и HTTP/3 — это базовый стандарт в каждом тарифном плане, а не опция для апселла.
Что на самом деле влияет на Core Web Vitals
Стоит быть точными, поскольку влияние хостинга на Core Web Vitals часто переоценивают. TTFB — это часть уравнения, за которую отвечает сервер, и именно вышеупомянутый стек кэширования снижает его: полная кэшированная страница, передаваемая по протоколу HTTP/3 с пограничного узла (edge), обеспечивает практически минимально возможный TTFB. Поскольку TTFB является отправной точкой для Largest Contentful Paint, быстрый исходный сервер дает каждой последующей метрике стартовое преимущество, которое иначе получить невозможно.
Но показатели LCP, CLS и INP в основном определяются в браузере самой страницей: неоптимизированное главное изображение (hero), блокирующие рендеринг CSS и JavaScript, сдвиги макета при загрузке шрифтов и рекламы, а также высокая нагрузка на основной поток из-за плагинов. Никакое серверное кэширование не исправит главное изображение размером 2 МБ или тему, передающую мегабайты JavaScript. Честный хостинг делает влияние сервера практически неощутимым и стабильным, а дальнейшая задача сайта — сохранять фронтенд легким.
Такое разделение труда представляет собой удобную ментальную модель. Мы гарантируем, что запрос быстро достигнет браузера и сохранит скорость под нагрузкой; вы поддерживаете полезную нагрузку компактной и стабильной. Область пересечения обоих аспектов — прогрев кэша, доставка на периферии сети и поддержание отклика базы данных во избежание зависания динамических страниц — как раз то, на что настроен наш стек, и именно благодаря этому управляемый WordPress на данной платформе работает быстрее, чем тот же сайт на стандартном хостинге.
Часто задаваемые вопросы
Нужен ли мне всё ещё плагин для кэширования, такой как WP Rocket?
Нет. Кэширование страниц целиком выполняется на веб-сервере с помощью LSCache от LiteSpeed, а наш собственный плагин кэширования — предустановленный и обновляемый автоматически — правильно связывает с ним WordPress, используя объектный кэш Redis для каждого сайта. Добавление второго плагина для кэширования страниц обычно конфликтует с кэшем уровня сервера, а не помогает, поэтому оно не требуется и не рекомендуется.
Повредит ли кэширование мою корзину WooCommerce или страницы для авторизованных пользователей?
Нет. Страницы cart, checkout, my-account, а также любые страницы nonce или session по умолчанию исключены из кэша, а ESI сохраняет актуальность фрагмента корзины и итоговых сумм на кэшируемых в остальном страницах. Покупатели всегда видят свою собственную корзину и работающее оформление заказа, в то время как витрина магазина по-прежнему загружается из кэша.
Как кэш остается актуальным, когда я публикую или редактирую?
Умная автоматическая очистка срабатывает на соответствующих хуках WordPress, поэтому публикация, редактирование контента или изменение товара, цены или заказа очищает только затронутые страницы и их архивы, а не весь кэш целиком, после чего краулер прогревает их снова. Вы также можете выполнить очистку по требованию из панели управления или из самого WordPress.
Может ли один только хостинг обеспечить мне идеальные Core Web Vitals?
Это обеспечивает вам наилучший возможный TTFB, который представляет собой вклад сервера и дает преимущество для Largest Contentful Paint. Однако LCP, CLS и INP во многом определяются самой страницей: размерами изображений, блокирующими рендеринг ресурсами, стабильностью макета и JavaScript в основном потоке. Наш стек делает работу сервера быстрой и стабильной; уменьшение объема фронтенд-ресурсов — это то, что устраняет оставшийся разрыв.
Связанные
Попробуйте бесплатно в течение 14 дней
Запустите свои первые сайты бесплатно на 14 дней — без банковской карты. Переносите существующую сеть? Миграции бесплатны и не имеют ограничений.
Начать бесплатно