Види кешування в WordPress: особливості та проблеми

WordPress Cache

Кешування WordPress часто розуміють неправильно. В результаті сайти працюють повільніше, ніж могли б. У цій статті я спробую розвінчати деякі з існуючих помилок і внести велику ясність у питання кешування. Сподіваюся, до кінця цієї статті ви зрозумієте, як різні рівні кешування беруть участь у оптимізації WordPress.

Що таке кешування і чому воно важливе

Кеш – рівень зберігання, на якому містяться часові копії файлів і даних з одного запиту, щоб наступні запити могли швидше отримати доступ до цього контенту. У WordPress це може означати будь-що, починаючи від кешування всієї сторінки і закінчуючи результатами запиту до бази даних.

Перш ніж ми заглибимося в різні механізми кешування, розглянемо всі переваги цього підходу. Кешування виконує два основні завдання:

  1. Покращує продуктивність програм. Для WP це означає, що сайт буде завантажуватись швидше і користувачі отримають кращий досвід взаємодії.
  2. Збільшується пропускна здатність програми. Це означає, що ваш сайт зможе обробляти більше трафіку.

Також кешування дозволяє підвищити продуктивність та пропускну здатність додатків без збільшення витрат на хостинг. Тобто, вам потрібно набагато менше системних ресурсів (ЦП, пам’ять) для розміщення сайту, якщо він був правильно кешований. Найкраща продуктивність може бути корисною для SEO, оскільки швидкість сторінок є одним з факторів ранжирування, що використовуються пошуковими системами. Це справді безпрограшна стратегія (якщо все налаштовано грамотно).

Рівні кешування

WordPress – це CMS із базою даних, тобто. обробка одного запиту задіяє чимало різних ділянок. У своїй стандартній збірці система WP спочатку повинна буде надіслати запит до БД та сформувати сторінку, після чого ця сторінка вже буде передана користувачеві. Це здійснюється при кожному запиті, що вкрай неефективно, особливо коли контент сторінки не змінювався. Типовий запит буде виглядати приблизно так:

Кэширование в WordPress: виды, особенности функционирования и распространенные проблемы

Як правило, чим більше ділянок задіяно в обробці запиту, тим довше користувач чекатиме відповіді, тим більше використовується системних ресурсів. Щоб боротися з цим, до кожного окремого рівня застосовується кешування. У результаті ми маємо три основні рівні:

  1. Браузерне кешування.
  2. Сторінне кешування.
  3. Об’єктне кешування.

Почнемо ми з браузерного кешування.

Браузерне кешування

Хоча браузерне кешування і не завжди допомагає покращити час відгуку або пропускну здатність (особливо WordPress), воно залишається найважливішим рівнем у контексті скорочення обсягу даних, що передаються з сервера в браузер. В результаті ваш сайт може стати більш чуйним, оскільки статичні ресурси (CSS, JS, зображення) виводяться швидше, якщо вони кешуються браузером.

Щоб зрозуміти, як працює браузерний кеш, достатньо відкрити вкладку Network в інструментах браузера. Давайте подивимося, як кеш функціонуватиме наживо. При завантаженні першої сторінки жодних ресурсів у кеші не з’явиться.

Показники, що цікавлять нас, – це обсяг переданих даних і загальні ресурси.

У результаті ви можете бачити, який тип ресурсів займає більшу частину пропускної смуги.

Обсяг переданих даних буде завжди меншим, ніж загальний обсяг ресурсів, навіть якщо це перше завантаження сторінки браузером. На те є кілька причин:

  1. Ресурси, кешовані браузером, нікуди не пересилаються.
  2. Ресурси, такі як HTML, CSS та JS, повинні бути стиснуті (Gzip) сервером перед відправкою до браузера. Потім вони вже розпаковуються браузером перед відображенням користувачів.

Отже, якщо кешування налаштовано правильно, то в такому разі при наступних завантаженнях сторінки має передаватися менше даних. Ви можете переконатись у цьому самі, просто перезавантаживши сторінку.

Обсяг даних, що передаються, впав з 1.2 Мб до 118 Кб, що є суттєвою економією! Ви також можете бачити, що показник навантаження знизився з 893 до 573 мс.

Ви можете налаштувати поведінку браузерного кешування за допомогою заголовків cache-control та expires, які додаються до відповіді сервера (при запиті статичних ресурсів). Заголовок cache-control буде мати пріоритет над старішим expires. Але зазвичай застосовуються обидва заголовки для забезпечення сумісності з деякими застарілими проксі-сервісами.

Ви можете перевірити заголовки ресурсів за допомогою інструментів розробника або команди cURL:

$ curl -I https://spinupwp.com/wp-content/themes/spinupwp/assets/images/video-screenshot.png
HTTP/2 200
server: nginx
date: Mon, 18 Jan 2021 21:10:09 GMT
content-type: image/png
content-length: 46753
last-modified: Tue, 13 Oct 2020 12:58:40 GMT
etag: "5f85a480-b6a1"
expires: Tue, 18 Jan 2022 21:10:09 GMT
cache-control: max-age=31536000

Заголовок cache-control має значення max-age=<seconds> , Що дає браузеру установку кешувати файл терміном, що не перевищує seconds. У результаті ви запобігти повторному завантаженню ресурсу при наступних запитах. У наведеному вище випадку файл буде кешований браузером терміном до 1 року.

Поширені проблеми з браузерним кешуванням

Інвалідація (анулювання) кешу ускладнюється. Як тільки браузер кешував ресурс за допомогою cache-control: max-age=<seconds>, ви вже не можете попросити браузер прибрати його з кешу – принаймні без зміни URL. Ось чому WordPress додає рядок запиту версії до запитуваних ресурсів. Приклад:

https://spinupwp.com/wp/wp-includes/css/dashicons.min.css?ver=5.2.2

Інструменти перевірки швидкості сайту, такі як Pingdom, скаржаться на недовговічні заголовки терміну дії. Часто ці попередження з’являються через сторонні ресурси, такі як Google Analytics. Пов’язано це з тим, що зовнішні послуги прагнуть гарантувати актуальність своїх ресурсів через вже згадані проблеми з інвалідністю кешу.

Cache-control і expires – далеко не єдині заголовки, які використовуються браузером з метою розуміння того, чи потрібно отримувати ресурс із сервера. Наприклад, після закінчення часу, вказаного в cache-control: max-age=<seconds>, буде використовуватися заголовок etag. Він містить валідаційний токен (за аналогією з кешем MD5 ресурсу, що запитується), який порівнюється з токеном ресурсу, що зберігається на сервері. Якщо значення etag збігається, то ресурс повертає відповідь «304 Not Modified». Браузер розуміє, що кешований ресурс не змінився, тому для нього слід продовжити термін дії, заданий в cache-control: max-age=<seconds>.

Сторінне кешування

Сторінне кешування дає найкращий результат у контексті часу відгуку програми та пропускної спроможності. Сторінний кеш перетворює WordPress (CMS з базою даних) на статичний HTML-сайт, крім PHP та MySQL з обробки запитів.

Щоб продемонструвати потужність кешування, я вдаюся до чистої установки WordPress 5.6.2. Всі тести будуть проводитись за допомогою ApacheBench. У цих тестах я скористаюся стеком у вигляді SpinupWP з 8 GB, 4 vCPU DigitalOcean-дроплетом, заточеним під WP. Некешовані результати – це WordPress без кешування (крім PHP OPcache, який використовує стандартні значення для PHP 7.4). Кешовані результати – це WordPress зі сторінковим кешуванням, включеним до SpinupWP.

Почнемо з кількості запитів на секунду (що більше, тим краще, оскільки від цього залежить пропускна спроможність).

Тут ми маємо 10-кратний приріст пропускної спроможності. Однак якщо ці запити виконуватимуться повільно, то в такому разі наша метрика втратить будь-яку суть. Тому важливо також виміряти середній час відгуку (чим менше, тим краще):

Показник середнього часу відгуку в 5 разів краще з увімкненим сторінковим кешуванням.

Поширені проблеми зі сторінковим кешуванням

Сторінне кешування надзвичайно складно налаштувати, коли на сайтах виводиться персональний контент. Наприклад, це інтернет-магазини, форуми та ін. Найчастіше для таких ресурсів або повністю відключається сторінки кеш, або задаються правила для виключення деяких сторінок з кешу (наприклад, сторінки /checkout).

Інвалідація кешу може стати досить хитромудрим завданням. Через динамічну природу WordPress досить складно визначити, які сторінки слід видаляти з кеша при оновленні контенту (особливо якщо задіяні архіви, пагінація та віджети). Ось чому очищення всієї сторінкового кешу найчастіше є кращим підходом при зміні контенту.

Використання кількох рішень для кешування сторінок лише погіршує продуктивність. Цей підхід не рекомендований, оскільки може вести до інкогерентності кешу (у різних кешах зберігаються різні версії вашого сайту), що значно ускладнить його очищення.

Сторінне кешування зазвичай відключається для зареєстрованих користувачів (тому переважним є об’єктне кешування, яке ми розглянемо далі).

Об’єктне кешування

Як було зазначено вище, не всі сторінки можна кешувати. Це особливо вірно щодо інтернет-магазинів, сайтів спільнот і т.д., де часто виводиться персоналізований контент. Те саме і з адмінкою WordPress. Якби такі динамічні сторінки були кешовані, користувачі побачили б нерелевантний персоналізований контент.

WordPress використовується вбудоване об’єктне кешування, яке дозволяє зберігати в пам’яті такі дані, як запити до БД. Тому кілька викликів, скажімо, get_posts приводять тільки до одного запиту до БД. Однак об’єктний кеш за замовчуванням не є постійним (персистентним). Він живе після запиту. На щастя, WP можна інтегрувати із постійним сховищем Redis, що має вирішальне значення для масштабування динамічних сторінок. Об’єктний кеш розташований між PHP та базою даних, що прискорює виконання PHP та скорочує навантаження на БД за рахунок кешування запитів у пам’яті. Ви можете побачити вплив об’єктного кешу, встановивши плагін Query Monitor. Завантаження сторінки кошика WooCommerce без об’єктного кешування дає 32 запити до БД:

При включеному об’єктному кешуванні кількість запитів до БД для цієї сторінки скорочується до 2, а час генерації сторінки знижується з 0,085 с до 0,053 с.

Ці тести були виконані з використанням PHP 7.3, чистої установки WordPress 5.2.2, WooCommerce 3.6.4 і теми Storefront.

Поширені проблеми

Щоб зробити об’єктний кеш постійним, потрібен додатковий серверний софт, як Redis або Memcached. Ви можете встановити його самостійно, якщо у вас свій сервер.

Об’єктний кеш не дозволяє позбавитися бази даних, яка є найвужчим місцем у WP. Пов’язано це з тим, що SQL-запити для побудови індексу записів виконуватимуться завжди, оскільки результати не кешуються.

Плагіни кешування в WordPress

Популярні плагіни кешування в WordPress – WP Rocket, W3 Total Cache або WP Super Cache – є поширеним способом додавання кешування на сайт. Проте плагіни не завжди потрібні. Хороші хостинг-провайдери пропонують рішення для кешування на рівні сервера. Правда, у такому разі у вас має бути доступ до сервера.

Прокоментувати

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *