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

його

Які інструменти надає WordPress?

Як всі знають, дана CMS дозволяє легко розширювати свою функціональність за допомогою плагінів, але не всі знають, що є кілька типів плагінів:

  • звичайні плагіниперебувають у wp-content/pluginsадміністратор може їх вільно встановлювати, активувати та деактивувати;
  • обов'язкові плагіниперебувають у wp-content/mu-pluginsдані плагіни включаються автоматично і не можуть бути деактивовані;
  • системні плагіниперебувають у wp-contentдозволяють перевизначати класи ядра або впроваджувати в них власний функціонал; до них відносяться:
  • sunrise.phpПідвантажується на самому початку ініціалізації ядра. Найчастіше використовується для domain mapping;
  • db.phpДозволяє перевизначати стандартний клас для роботи з базою даних;
  • object-cache.phpДозволяє перевизначитися стандартний клас об'єктного кешування, наприклад, якщо захочете використовувати Memcached або Redis;
  • advanced-cache.phpДозволяє реалізувати сторінкове кешування, що нам і потрібно!

advanced-cache.php

Для того, щоб цей плагін почав функціонувати, його потрібно помістити в директоріюwp-content, а вwp-config.phpдодати рядок: Якщо заглянути в код WordPress, то можна побачити, що цей скрипт підвантажується на ранньому етапі завантаження платформи.

Також, після завантаження ядра, CMS спробує викликати функцію wp_cache_postload(), але пізніше.

Для зберігання кеша найкраще використовувати швидкі сховища, тому що від їхньої швидкості залежить швидкість віддачі контенту з кеша. Я б не радив використовувати MySql або файловуСистема, набагато краще з цим впораються Memcached, Redis або інші сховища, що використовують оперативну пам'ять.

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

Зрозуміло, це не повний перелік методів, весь список API можна вивчити на офіційному сайті, але для більшості завдань цього достатньо.

Якщо на сайті використовується прокачений об'єктний кеш (object-cache.php), то є сенс використовувати його API:

Найпростіше сторінкове кешування

Код спеціально спрощений, багато перевірки прибрані, щоб не плутати читача зайвими конструкціями і сфокусуються на логіці самого кешування. До файлуadvanced-cache.phpпрописуємо:

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

Створення ключаУ цьому випадку ключем є URL-адреса сторінки. Використання глобальної змінної$_SERVERта хешування не можна назвати найкращою практикою, але для простого прикладу підійде. Раджу додавати розділяючі ділянки рядка як «host:» та «uri:», тому що їх зручно використовувати у регулярних виразах. Наприклад, отримати всі ключі по певному хосту:Видача з кешуТут все просто, якщо кеш вже створений, то видаємо його користувачеві і завершуємо виконання.

Збереження в кешPHP функціяob_startперехоплює весь наступний виведення в буфер і дозволяє обробити його в кінці роботи скрипта. Простими словами ми отримуємо весь контент сайту у змінній $html. Далі зберігаємо дані в кеш: Є сенс зберігати не тільки HTML, але й іншу кориснуінформацію: час створення кешу та ін. Дуже рекомендую зберігати HTTP заголовки, хоча бContent-Typeі надсилати їх при видачі з кеша.

Удосконалюємо

У прикладі вище ми використовували функціюis_admin()для виключення кешування адмін панелі, але цей спосіб не дуже практичний з двох причин:

  • запити наadmin-ajax.phpне потрапляють у кеш;
  • якщо адміністратор першим відвідає сторінку, то в кеш потрапить його admin bar та інші шкідливі для користувачів речі;
Найкращим рішенням для простого сайту взагалі не використовуватиме кеш для залогінених користувачів (адміністраторів). Оскількиadvanced-cache.phpвиконується до повного завантаження ядра, ми не можемо користуватися функцієюis_user_logged_in(), але можемо визначити наявність автентифікації за cookie (як відомо, WordPress не використовує сесії).

Ускладнюємо завдання

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

wp_cache_postload()

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

Бувають ситуації, коли для формування ключа кеша потрібні дані, які неможливо отримати з cookie, IP та інших доступних на етапі ініціалізації ресурсів. Наприклад, потрібно генерувати індивідуальний кеш для кожного користувача (іноді це має сенс). Як видно у прикладі, вся логікапоміщена в тілоwp_cache_postloadі тут доступні всі функції платформи, включаючиget_current_user_id(). Даний варіант трохи повільніший за попередній, але ми отримуємо безмежні можливості для тонкого налаштування сторінкового кешу.

Про що не варто забувати

  1. Дані приклади дуже спрощені, якщо їх використовуватимете у своїх проектах — не полінуйтеся додати умови для кешування:
  2. тільки GET запити
  3. тільки якщо на сторінці немає помилок
  4. тільки якщо немає set-cookie
  5. тільки якщо статус 200 або 301
  6. Ефективність кеша залежить від його часу життя. Збільшуючи $timeout, намагайтеся продумати інвалідність кеша при зміні даних.
  7. WP Cron запускається пізніше advanced-cache.php, може просто не спрацьовувати за високого кешхіту.

Висновок

А у нас тут можна отримати грант на тестовий період Яндекс.Хмари. Варто лише у полі «секретний пароль» запровадити «Хабр»