Хостинг і продуктивність
Як ми пришвидшуємо 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. Коли фронтенд-відповідь підлягає кешуванню, вебсервер маркує її заголовками cache-control та тегами LiteSpeed, і LiteSpeed віддає повну сторінку безпосередньо під час наступного запиту — без запуску процесу PHP та виконання запитів MySQL. Це найпотужніший важель для покращення WordPress TTFB, оскільки він повністю виключає завантаження застосунку з критичного шляху.
Оскільки LSCache працює всередині вебсервера, а не у плагіні PHP, він починає діяти раніше у життєвому циклі запиту та зберігає сторінки у формі, яку сервер може миттєво вивантажити. Сканер кешу підтримує популярні сторінки в актуальному стані, тож перший відвідувач після очищення не змушений чекати на повторну генерацію сторінки. У результаті ви отримуєте помітно нижчий та стабільніший показник TTFB порівняно з кешем на основі лише плагіна, доданим до стандартного стека, де кеш усе одно розташовується за PHP.
Наш власний плагін кешування репозиторного рівня постачається попередньо встановленим і автоматично оновлюється на кожному сайті, налаштовуючи WordPress для роботи з LSCache правильно "з коробки". На джерелі, що не використовує LiteSpeed, він просто не надсилає заголовки повної сторінки та не заважає роботі, тоді як об'єктний кеш і правила виключень продовжують виконувати свої функції — тож мігрований сайт ніколи не залишається в пошкодженому, напівналаштованому стані.
Зберігати високу швидкість без застарілого вмісту: ESI та інтелектуальне автоочищення
Агресивне кешування цілих сторінок має два класичні сценарії збою: показ залогіненому користувачу чужої сторінки та показ будь-кому сторінки, яка мала б змінитися. Обидві проблеми вирішуються на рівні кешування, а не шляхом зменшення обсягів кешу.
ESI (Edge Side Includes) дозволяє кешувати сторінку, залишаючи динамічні частини для елементів, які мають оновлюватися в реальному часі. У магазині на базі WooCommerce каталог, сторінки товарів і категорій обслуговуються за допомогою кешування всієї сторінки для максимально швидкого TTFB, тоді як ESI відображає фрагмент кошика, загальну суму мінікошика та стан облікового запису для кожного запису. Кошик, оформлення замовлення, мій обліковий запис, а також будь-які сторінки з nonce або сеансами виключено за замовчуванням. Покупці завжди бачать свій власний кошик і працюючу сторінку оформлення замовлення, тоді як вітрина магазину завантажується з кешу для всіх.
Свіжість забезпечується розумним автоочищенням. Хуки очищення спрацьовують автоматично під час зміни вмісту, товарів, цін або замовлень, тож відповідні кешовані сторінки оновлюються одразу, а не за таймером, а також ви можете виконувати очищення на вимогу з панелі керування або всередині WordPress. Очищення на основі тегів означає, що редагування однієї публікації очищує цю публікацію та її архіви, а не весь кеш, тому єдине редагування не спричиняє холодний запуск усього сайту.
Об'єктний кеш Redis для окремих сайтів: для того, що не може бути повною сторінкою
Не кожен запит може бути статичною повною сторінкою. Авторизовані сесії, панель керування WordPress, кошики WooCommerce, пошук та динамічні фрагменти, які залишає ESI, мають виконувати PHP. Для них мета змінюється з «пропустити застосунок» на «пропустити базу даних».
Кожний сайт отримує власний ізольований об'єктний кеш Redis. WordPress кешує результати повторюваних читань бази даних — параметри, транзієнти, пошуки записів і термінів, дані товарів і сесій 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. Чесний хостинг робить внесок сервера фактично безкоштовним і стабільним, а далі вже сам сайт має дбати про те, щоб його інтерфейс залишався легким.
Цей поділ праці є корисною ментальною моделлю. Ми гарантуємо, що запит доходить до браузера швидко і залишається швидким за умов трафіку; ви дбаєте про те, щоб корисне навантаження було невеликим і стабільним. Саме там, де вони перетинаються — розігрів кешу, доставка на рівні edge та підтримка швидкої реакції бази даних, щоб динамічні сторінки не зависали — наш стек налаштовано найкращим чином, і саме це робить керований 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 днів — без картки. Переносите наявну мережу? Першу міграцію ми беремо на себе.
Почати безплатно