Хостинг і продуктивність
Як ми прискорюємо 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 кешує результати повторюваних операцій читання з бази даних — параметри, transients, пошук записів і термінів, дані про товари та сеанси WooCommerce — у пам'яті, тому один і той самий запит не виконується до MySQL під час кожного відвідування. Цей ефект найбільш помітний саме там, де кешування сторінок цілком не допомагає: швидші інформаційні панелі, швидші кошики та значно менше навантаження на базу даних за високого трафіку.
Кеш об'єктів працює окремо для кожного сайту й не є спільним, що важливо як для продуктивності, так і для ізоляції. У поєднанні з обмеженням навантаження на базу даних для кожного сайту, важкі або погано написані запити одного сайту не можуть позбавити ресурсів бази даних сусідні сайти. Ви можете дізнатися більше про те, як працює вся багаторівнева система, на нашій сторінці функцій кешування, а також про межі між клієнтами в умовах ізоляції.
Периферія та транспорт під нею
Кеш, розміщений на вихідному сервері, все одно має проходити через мережу. Перед сервером розташований край мережі CDN, тому статичні ресурси та сторінки, що підлягають кешуванню, надаються з точки присутності поруч із відвідувачем, а вихідний сервер залишається розвантаженим навіть під навантаженням. Для нашої лінійки хостингу без слідів (footprint-free) той самий край є пулом multi-CDN, розподіленим між кількома постачальниками, що слугує як меті усунення цифрового сліду, так і підвищенню продуктивності; у стандартному 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 днів — без кредитної картки. Переносите наявну мережу? Міграції безкоштовні та без обмежень.
Почати безкоштовно