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

  • Користувач знаходиться занадто далеко від вашого сервера, тому мережевий RTT є високим (особливо це помітно між континентами).
  • Кожен раз, коли WordPress отримує запит, він запускає PHP, запитує базу даних і відображає шаблон → Збільшення часу відгуку сервера (TTFB)
  • Сторінка також завантажує JS/CSS/шрифти/сторонні скрипти, що призводить до повільного рендерингу та взаємодії.

Плагін кешуванняСуть рішення полягає в тому, щоб зберегти результати сторінок, які “перераховуються”, щоб серверу не доводилося перераховувати їх кожен раз; а також застосувати відповідну стратегію, яка дозволить більшій кількості користувачів отримувати кешовані дані, що значно зменшить час відгуку сервера (TTFB).Офіційна документація WordPress.Також зазначається, що такі плагіни, як W3 Total Cache та WP Super Cache, можуть кешувати сторінки у вигляді статичних файлів, а потім надавати їх користувачам, зменшуючи навантаження на сервер.

Перед тим, як читати цю сторінку, запам'ятайте три непорушні правила.

1. Плагін кешування сторінок використовує лише один кеш одночасно.

Одночасне використання декількох плагінів кешування часто призводить не до прискорення, а навпаки:

  • Відображення правил кешування один одного, очищення кешу один одного, зниження показника точності кешування.
  • Динамічний вміст, такий як дані для входу, мова, кошик для покупок і ціни, кешувався, що призвело до появи “неправильного вмісту”.
    Багато документів/керівництв для плагінів рекомендують використовувати певний плагін для кешування.Заборонити інші плагіни кешування.Щоб уникнути конфліктів.

2. Електронна комерція/членство/багатомовний сайт: кешування — це не “вимикач”, а “система правил”.”

Офіційна документація з продуктивності WooCommerceЯвне нагадування: у плагіні кешування необхідно переконатися, що Кошик для покупок / Оформлення замовлення / Обліковий запис Не дозволяйте сторінкам кешуватися, а також рекомендується уникати стиснення файлів JavaScript (оскільки це може спричинити проблеми з сумісністю).

3. “Плагін кешування ≠ CDN”, але плагін кешування є основою CDN.

Плагін кешування вирішує проблему “недостатньої кількості обчислень на вихідному сервері”;CDN Вирішіть проблему “контент має бути ближче до користувачів”. Це два взаємопов'язаних кроки: спочатку зменшіть час відгуку сервера (TTFB), а потім передайте статичні ресурси на CDN для їх розповсюдження. Це найнадійніший спосіб забезпечити глобальним користувачам стабільний доступ до контенту.

Швидкий вибір: найпоширеніші 4 сценарії на вебсайтах.

Якщо ви не хочете читати весь текст, виберіть 4 пункти нижче, і ви навряд чи зробите помилку:

  1. Хочете, щоб було просто, стабільно та з доступом до всього світу? → WP Rocket(Платне)
  2. Хост явно є LiteSpeed/OpenLiteSpeed. → ЛітСпід Кеш(Безкоштовно, але сильно залежить від продуктивності сервера)Необхідна функція кешування. Серверний компонент LiteSpeed.Щоб працювати.
  3. Вебсайт із контентом/блог/сайт із документами, який потребує безкоштовного та надійного хостингу. → WP Super Cache(Кешування статичного HTML)генерація статичних HTML-файлів, які надаються більшості неавторизованих користувачів;
  4. У вас є технічна команда, яка має ретельно контролювати (CDN/кешування об'єктів/багатомодульність). → W3 Загальний кеш(Сильний, але складний): Основна увага приділяється комплексній системі аналітики та інтеграції з CDN.

Що насправді зберігається у кеші?

“Чому деякі сайти працюють повільно, навіть якщо на них встановлений кеш?”. Ми розділимо продуктивність WordPress на 5 рівнів:

  1. Кеш браузера.Зробити другий візит користувача швидшим (кешування статичних ресурсів, заголовки, номери версій).
  2. Кешування сторінокЗберегти результат виводу сторінки у форматі HTML (головний елемент цієї сторінки)
  3. Кешування об'єктівЗберігати об'єкти результатів запитів до бази даних (більш корисно для динамічних веб-сайтів).
  4. PHP OPcacheЗберігати кеш байт-коду PHP (зазвичай це налаштовується на сервері, а не є основним завданням плагіна).
  5. CDN/кешування на країнахПомістіть ресурси на вузли, які знаходяться ближче до користувачів.

Ця стаття присвячена: плагінам кешування сторінок;
Але вам постійно нагадуватимуть, що веб-сайтам часто потрібна комбінація 2+5, щоб бути “дійсно швидкими”.

Плагін 1:WP Rocket(Платний) — інтегроване рішення, яке “позбавляє від клопоту”.

WP Rocket користується популярністю в середовищі WordPress не тому, що він чудовий, а тому, що він перетворює три найпоширеніші види роботи з продуктивністю на “контрольовані пакети”:

  • Кешування сторінок (зменшення часу відгуку сервера)
  • Передзавантаження/передгрівання кешу (покращення досвіду при першому відвідуванні з урахуванням глобального розподілу доступу)
  • Ключова оптимізація фронтенду (особливо затримка JavaScript, обробка CSS тощо)
Оптимізація кешування в WordPress — LikaCloud

ЇїОфіційна документація.Там також чітко зазначено: навіть якщо ви вимкнете кешування сторінок, увімкнення попереднього завантаження все одно може запустити/активувати певні процеси оптимізації (наприклад, пов'язані з CSS/JS).

1.1 WP Rocket підходить для кого?

WP Rocket особливо підходить для таких сайтів:

  • Веб-сайт компанії, брендовий сайт, сайт контент-маркетингу, посадкова сторінка (трафік з різних країн і регіонів)
  • Я хочу, щоб сайт завантажувався швидко і був стабільним, тому не хочу використовувати багато безкоштовних плагінів.
  • Немає штатних інженерів з експлуатації та технічного обслуговування/оптимізації продуктивності, але є вимоги до якості роботи та SEO.
  • WooCommerce Це теж можна зробити, але потрібно бути обережнішим (про це буде сказано далі в цьому розділі).Правила та ризики）

1.2 Його ключове значення для доступу до веб-сайтів (не лише “перемикач кешування”)

А. Предваричне завантаження кеша: вирішення проблеми нестабільної роботи при першому відвідуванні веб-сайту через розподілену архітектуру.“

Коли користувачі вебсайту розкидані по всьому світу, ви стикаєтеся з типовою проблемою повільної роботи:
Коли користувач з певного регіону вперше відкриває певну сторінку, а кеш сторінки застарілий або ніколи не був підготовлений → користувач несе повні витрати на рендерингу PHP/бази даних.
Механізм попереднього завантаження.Значення цього полягає в тому, що:Сплатіть витрати на “первинне виробництво” заздалегідь.Зменшити ймовірність того, що люди, які відвідують ваш сайт вперше, будуть відчувати себе загубленими.

  • Без попереднього завантаження: той, хто заходить першим, той і страждає.
  • Є попереднє завантаження: система автоматично створює кеш у фоновому режимі, завдяки чому перше відвідування сайту проходить стабільніше.

Б. Відкладання виконання JavaScript: найбільш очевидна функція при відвідуванні веб-сайту, але вона також і найбільш ризикована.

Офіційна сторінка WP Rocket у Facebook“Відкладене виконання JS”Описання як найпотужніша оптимізація JavaScript: вона відкладає виконання скриптів до тих пір, поки користувач не взаємодіє з ними (рух миші, натискання на екран, прокрутка, натискання клавіш тощо), щоб пріоритетно відобразити сторінку.

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

  • Завантаження ресурсів відбувається повільніше → головний потік легше застряє на скриптах.
  • Зовнішні скрипти (для статистики, реклами, чат-плагінів) частіше призводять до погіршення показників INP/затримки взаємодії.

але це також може спричинити певні проблеми:

  • Зі зволіканням у роботі JavaScript можуть виникнути проблеми з такими елементами, як меню, слайдери, спливаючі вікна, перевірка форм, платежі та відстеження подій.
  • Тому він підходить для стратегії “поступового просування + виключення з чорного списку”.

C. Сумісність з іншими плагінами/темами: зручність не означає “нуль конфліктів”.”

Офіційний сайт WP Rocket спеціально перерахував:“Несумісні плагіни/теми.”Список причин включає те, що це може вплинути на такі механізми, як кешування/оптимізація вихідної буферизації в WP Rocket.

  • Якщо у вашому вебсайті багато плагінів і теми дуже важкі, розглядайте “оптимізацію продуктивності” як невеликий проект із запуском у продакшн: після кожної зміни необхідно проводити регресійне тестування (форм, входу, платежів, перемикання між мовами тощо).

1.3 Особливі попередження щодо WooCommerce/динамічних сайтів

Офіційна документація WooCommerce містить основну пораду щодо налаштування плагіна кешування:

Чому? :

  • Корзина для покупок, оформлення замовлення та сторінка облікового запису сильно залежать від файлів cookie/сеансу/номеру замовлення.
  • Як тільки кеш розглядає такі сторінки як “статичні”, це може призвести до неправильної роботи кнопок або навіть до некоректної інформації про ціни/товарні запаси/рахунки.
  • Найстрашніше те, що у вас можуть не виникнути проблем із тестуванням в одному регіоні, але ви зіткнетеся з проблемами в іншому через відмінності в CDN/кешуванні.

1.4 Рекомендації щодо стратегій плагінів кешування

1-й рівень: базові заходи безпеки (повинні виконуватися майже на всіх станціях).

  • Включити кешування сторінок.
  • ВключитиПередзавантаження кеша.(Підвищення стабільності при першому відвідуванні)
  • Розумна стратегія кешування браузера (можлива на будь-якому рівні: WP Rocket, сервер, CDN).

2-й рівень: середній прибуток, середній ризик (підходить для більшості контент-сайтів)

  • Откладання завантаження зображень/iframів (більш детально про оптимізацію зображень на сторінці)
  • Контроль об'єму CSS (наприклад, видалення невикористаного CSS)

3-й рівень: високий прибуток, але високий ризик (потрібен список регресійних тестів)

1.5 ціна та ліцензія

  • WP Rocket є платним програмним забезпеченням, що пропонує різні ліцензії в залежності від кількості сайтів.

Плагін 2:LiteSpeed Cache (LSCWP)— Передбачення “безкоштовний топ-конфігурація” передбачає, що сервер насправді є LiteSpeed.

Оптимізація кешування в WordPress — LikaCloud

Багато людей неправильно розуміють LiteSpeed Cache, думаючи, що це просто плагін для WordPress, який можна встановити, і він буде працювати так само добре, як WP Rocket, на будь-якому хостингу. Насправді це не так.

Офіційна документація LiteSpeed.Детальне пояснення: для того, щоб функція кешування LSCWP працювала, необхідний сервер LiteSpeed, оскільки він взаємодіє з вбудованим кешем сторінок LiteSpeed Web Server (LSCache); плагін відповідає за те, які сторінки можна кешувати, як довго їх кешувати, а також за запуск очищення за допомогою тегів.

Основна перевага LiteSpeed Cache полягає в тому, що він“Кешування сторінок на рівні сервера (LSCache)”Немає цього основного переваги без сервера LiteSpeed/OpenLiteSpeed.

2.1 ЛітСпід КешДля кого це підходить?

Підходить для:

  • Ваша панель хостингу чітко позначена. LiteSpeed / OpenLiteSpeed(Наприклад, багато хостинг-провайдерів cPanel пишуть про це)
  • Ви хочете, щоб “безкоштовні рішення також забезпечували високу продуктивність TTFB і здатність обробляти великі обсяги одночасних запитів”.”
  • Ви готові прийняти те, що він дуже функціональний, але має більше концепцій (TTL, Tag, Purge, ESI, Crawler тощо)?

Не дуже підходить:

  • Ви не впевнені, який веб-сервер використовується, або підтверджуєте, що це Nginx/Apache (якщо тільки ви не хочете використовувати лише його функції оптимізації інтерфейсу, але в такому випадку співвідношення ціни та складності може бути не вигідним).
  • Ви маєте складний інтернет-магазин/сайт для членів/багатомовний сайт, але у вас немає процесу тестування (LSCWP хороший, але в ньому легко “кешувати неправильний вміст”).

2.2 Його механізм кешування: чому він більше схожий на “частину можливостей сервера”.”

Ви можете описати механізм LiteSpeed Cache одним реченням: “інженерне пояснення”:

  • WP Rocket / WP Super Cache Такі речі часто робляться для кешування та оптимізації на стороні WordPress/PHP;
  • LSCWP Це комбінація “Панель управління WordPress + сервер LiteSpeed із вбудованим LSCache”: плагін відповідає за налаштування правил і очищення кеша, а справжнє високошвидкісне кешування сторінок відбувається в самому сервері.Серверний рівень.。

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

2.3 “Правильний спосіб використання” LSCWP в контексті веб-сайтів.”

Ми розділили “правильний спосіб використання” на 4 рівні:

1-й рівень: стратегія кешування сторінок (визначає, чи справді можна зменшити час відгуку сервера до клієнта).

  • Визначте, які сторінки можна кешувати (більшість сторінок із відкритим вмістом).
  • Зрозумійте, які сторінки ні в якому разі не можна кешувати (сторінки входу, облікового запису, кошика, оформлення замовлення, зміни мови/валюти, які залежать від строго необхідних файлів cookie).
  • Встановіть розумний TTL для кеша (чим частіше оновлюється вміст, тим коротший TTL; і навпаки, чим довший, тим краще).
  • Створіть стратегію очищення: очищуйте відповідні теги після оновлення контенту (а не проводите грубе очищення всієї веб-сайти).

Якщо цей рівень зроблено правильно, то веб-сайт одразу побачить наступне: Зниження часу завантаження сторінки та стабільніший перший екран.。

2-й рівень: прогрівання/сканування (визначає, чи швидко відбувається перший візит на “малопопулярні сторінки”).

Часто проблеми з непослідовним досвідом при відвідуванні веб-сайтів виникають через різницю у швидкості кешування:

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

Представлення не є додатковим елементом, а є ключем до забезпечення послідовного досвіду відвідування веб-сайту.

3-й рівень: рішення для безпеки динамічного контенту (електронна комерція/членство/багатомовність)

Сильна сторона LSCWP полягає в тому, що він надає вам багато “розширених інструментів”, таких як:

  • Стратегія диференційованого кешування для зареєстрованих користувачів, користувачів, які залишають коментарі тощо.
  • Основна ідея ESI полягає в тому, щоб розділити сторінку на "кешовані загальні елементи" та "некешовані динамічні фрагменти", обробити їх окремо, а потім з'єднати на крайовому вузлі.

4-й рівень: онлайн-послуги та додаткові можливості (за бажанням)

Багато веб-майстрів стикаються з онлайн-сервісами QUIC.cloud у LSCWP (наприклад, послуги з оптимізації сторінок).Документація QUIC.cloudЯсно зазначено, що він надає послуги з оптимізації сторінок для LSCWP, які включають критичний CSS (CCSS), унікальний CSS (UCSS), зображення для вікон перегляду (VPI) тощо.

  • Подібні послуги є необов'язковими.Ви можете використовувати лише кеш сервера, не включаючи онлайн-оптимізацію.
  • Після того, як ви активуєте онлайн-послугу, посилання на ресурси/сторінки вашого сайту зміняться (це важлива інформація для клієнтів, які зацікавлені в безпеці та конфіденційності).

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

  1. Сервер не є LiteSpeed, але він використовує LSCWP як повнофункціональний плагін кешування.
    Результат: ефект кешування не такий, як очікувалось, а також збільшилася складність конфігурації. Рішення: спочатку перевірте стек хосту; якщо це не так, \nLiteSpeedРозгляньте WP Rocket або WP Super Cache.
  2. Активування надмірної кількості оптимізацій на стороні клієнта призвело до неправильної роботи функції.
    Оптимізація сторінок (CSS/JS) часто призводить до проблем сумісності набагато частіше, ніж сам кеш. Рекомендація: спочатку налаштуйте кешування сторінок, а потім поступово вмикайте оптимізацію та створюйте список регресійних тестів (форми, меню, платежі, відстеження, зміна мови тощо).
  3. Відсутність стратегії виключення/розділення для динамічних сторінок.
    Типові помилки: кешування кошика, сторінки оформлення замовлення або сторінки облікового запису; або неправильне перемикання між різними мовами/валютами. Інтернет-магазини повинні перевіряти ці пункти перед запуском (це також підкреслюється представниками WooCommerce).Не кешуйте ключові сторінки.）。

Плагін 3:WP Super Cache(Безкоштовно) — класична схема “низький ризик, високий прибуток” для контент-сайтів.

Оптимізація кешування в WordPress — LikaCloud

WP Super Cache Чому він настільки популярний протягом тривалого часу? Тому що він вирішує проблеми дуже простим і “дружнім для серверів” способом:
Перетворити динамічну сторінку WordPress на статичний HTML-файл.Після цього веб-сервер напряму надає доступ до цих HTML-файлів, обходячи дорогу обробку PHP.

На сторінці плагіна також зазначено, що статичний HTML буде наданий більшості користувачів, які не увійшли в систему, з наступним поясненням: “Відвідувачам 99% буде надано статичний файл HTML”. Один файл кешування може обслуговувати тисячі запитів.

3.1 WP Super Cache підходить для кого?

Наполегливо рекомендую:

  • Блоги, медіаконтент-сайти, документальні сайти, корпоративні презентаційні сайти, посадочні сторінки.
  • Відвідувачі — це в основному неавторизовані користувачі.
  • Ви хочете: безкоштовно, стабільно, з низькими витратами на обслуговування.

Обережно використовуйте/потрібна більш сильна стратегія:

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

3.2 Його три способи кешування:

У описі плагіна WP Super Cache описано три способи кешування за швидкістю та пояснено їх відмінності:

  • Модуль mod_rewrite (для експертів)Найшвидший спосіб — повністю обійти PHP, але для цього потрібно змінити файл .htaccess. Неправильна конфігурація може призвести до недоступності сайту, і ризик цього є доволі високим.
  • Просто (рекомендований спосіб): Статичні файли із “суперкешуванням” від PHP, швидкість яких близька до швидкості mod_rewrite, але їх легше налаштувати.
  • Вікіпедія-кешбільш гнучкий, для відомих користувачів, URL із параметрами, підписок тощо, але працює повільніше.

Рекомендований вибір:

  • Для новачків/тих, хто прагне стабільності: користуйтеся рекомендованими методами (прості).
  • Ви добре знайомі з правилами сервера і готові ризикнути, переписавши їх: розглянемо режим експерта.
  • Вам потрібна більш гнучка обробка “відомих користувачів/параметрів”: зрозумійте, як працює WP-Cache.

3.3 Переваги та недоліки WP Super Cache

Переваги:

  1. Дуже добре підходить для роботи з CDN.
    Оскільки це, по суті, “генерація статичного HTML”, це природним чином відповідає концепції CDN/кешування на краях мережі.
  2. Покращення навантаження на процесор/базу даних вихідної станції є дуже прямим.
    Коли трафік веб-сайту розподілений, пошукові системи та спамери в соціальних мережах також можуть надходити з різних частин світу. Статичне відображення добре справляється з проблемою “повторного рендерингу”.

Недолік:

  1. Це не “комплект для оптимізації продуктивності”.”
    Він переважно спеціалізується на кешуванні сторінок і не пропонує такого глибокого оптимізації CSS/JS, як WP Rocket. Вам може знадобитися додати більше контенту на сторінках “Оптимізація зображень” і “Оптимізація переднього плану” (або скористатися іншими плагінами/темами для оптимізації).
  2. Слід бути обережнішим із “динамічною персоналізацією”.
    Наприклад, відображення різного вмісту залежно від регіону, різних цін/мов/рекомендацій залежно від статусу користувача тощо. У такому випадку необхідно розробити стратегію виключення або запровадити більш підходящий механізм кешування фрагментів.

3.4 Сумісність з WooCommerce: чому вона більш “безпечна”

Офіційна документація з допомоги WooCommerceЗгадується, що WooCommerce сумісний із WP Super Cache, і WooCommerce надсилає інформацію до WP Super Cache, щоб за замовчуванням не кешувати сторінки "Кошик", "Оформлення замовлення" та "Мій акаунт".

  • Навіть якщо ви новачок, з комбінацією WP Super Cache та WooCommerce ви набагато рідше зіткнетеся з проблемою кешування критично важливих сторінок.
  • Але все ж рекомендується провести регресійне тестування перед запуском (оплата, купони, доставка, податки, мультивалютність тощо).

Плагін 4:W3 Total Cache (W3TC)— Найбільш функціональна “рамка продуктивності”, яка підійде для інженерних команд.

Оптимізація кешування в WordPress — LikaCloud

W3 Загальний кеш Ціль WordPress.org — не “окремий плагін для кешування”, а швидше “фреймворк для оптимізації продуктивності сайту”: він фокусується на покращенні SEO, основних веб-параметрів та загального досвіду користування завдяки інтеграції з CDN і кращим практикам.

Опис плагіна перераховує безліч можливостей: кешування сторінок/публікацій, кешування CSS/JS, кешування фідів, кешування результатів пошуку, кешування об'єктів бази даних, кешування об'єктів, кешування фрагментів, а також підтримка різних способів кешування, таких як Redis/Memcached/APC, а також кешування за UA/Referrer для мобільних пристроїв, підтримка AMP, інтеграція з зворотними проксі-серверами (Nginx/Varnish) тощо.

4.1 W3 Total Cache підходить для кого?

Дуже підходить для:

  • Ви маєте навички розробки/експлуатації та готові виконати “поетапне впровадження + тестування під навантаженням + регресивне тестування”.”
  • Ваш сайт складний: багатомовність, зміна тематики, різні версії для мобільних пристроїв, складна структура контенту.
  • Вам потрібно не тільки кешувати сторінки, але й включити кешування об'єктів/фрагментів у систему (особливо для динамічних сайтів).

Не підходить для:

  • Ви хочете, щоб “воно працювало одразу після установки”, і не хочете розбиратися з ієрархією кешування.
  • У вас немає процесу тестування, але ви хочете відразу запустити такі високоризикові елементи, як стиснення та затримка скриптів.

4.2 Чому це “сильне, але складне”: веб-сайти цінують “контрольованість”.”

Цінність W3TC не в тому, що він “обов'язково швидший за інших”, а в тому, що він надає вам достатньо інструментів контролю, щоб ви могли перетворити стратегію підвищення продуктивності на інженерну систему:

  • Кешування сторінок: може здійснюватися в пам'яті, на диску або в CDN.
  • Кешування об'єктів бази даних, кешування об'єктів: можна використати Redis/Memcached тощо.
  • Кешування фрагментів: дуже важливо для “напівдинамічних сторінок”.
  • Мобільна підтримка: кешування сторінок для рефералів або груп користувацьких агентів.
  • Керування CDN: прозоре керування медіатекою, тематичними файлами тощо.

Ці можливості особливо цінні для веб-сайтів, оскільки доступ до них часто є глобальним:

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

4.3 “Рекомендований порядок активації” від W3TC.”

Порядок рекомендацій:

  1. Спочатку увімкніть лише кешування сторінок.
    Перевірка: чи зменшився час відгуку сервера, чи є контент послідовним, чи нормально працюють ключові процеси входу/багатомовність/електронна комерція.
  2. Знову увімкніть кешування браузера.
    Ціль: зробити так, щоб повторні відвідування та завантаження статичних ресурсів відбувалися швидше, а також зменшити кількість повторних завантажень через різні континенти.
  3. Знову оцінити кеш об'єктів / кеш об'єктів бази даних.
    Застосування: динамічні сайти (WooCommerce, система членства, складні запити).
    Не застосовується: веб-сайти, що містять лише контент, можуть мати обмежені доходи та навіть призводити до більшого витрачання ресурсів.
  4. Нарешті, обробіть скрипт стиснення/затримки/оптимізації фронтенду.
    Оскільки цей рівень найбільш схильний до порушень у роботі, необхідно скласти список регресійних тестів (оплата, форми, відстеження, спливаючі вікна, меню, зміна мови тощо).

Нагадування від WooCommerce про “налаштування плагіна кешування”.Ключові сторінки не кешуються, і рекомендується уникати стискання файлів JavaScript.

Матриця порівняння чотирьох плагінів.

Зверніть увагу: це не “хто сильніший”, а “хто краще підходить для вашої ситуації”.

ВімірWP RocketЛітСпід КешWP Super CacheW3 Загальний кеш
Основне позиціонування.Зручна інтегрована система (кешування + оптимізація)Кешування на рівні сервера (залежить від LSCache)Кешування статичного HTMLПлатформа продуктивності (декілька рівнів кешування + CDN)
Залежність від хостингу.Низький (універсальний)Високий (потребує LiteSpeed/OpenLiteSpeed для повноцінної роботи кешування).Низький (універсальний)Китайський (універсальний, але більше залежить від навколишнього середовища/можливостей конфігурації)
Вартість навчаннянизький — середній中低高
Рекомендованість контент-сайту.Дуже високий.Дуже високий (за умови, що вимоги будуть виконані)Дуже високий.Середній-високий (залежить від команди)
Електронна комерція/сайт для членівДоступно, але слід обережно виключити (критичні сторінки WooCommerce не кешуються)Доступно, але потребує додаткових правил/стратегії фрагментації.Він доступний, і WooCommerce згадує про його вбудовану сумісність і те, що він за замовчуванням не кешує ключові сторінки.Доступний, підходить для інженерного контролю.
Бюджет\nПлатнийБезкоштовноБезкоштовноБезкоштовна + платна версії

“Інциденти з кешем” та список запобіжних заходів

1. Три основні причини, через які у кеші може бути “неправильний вміст”

А. Сприймати сторінки з “станом” як “статичні сторінки без стану”.”

Типове: сторінка облікового запису, кошик для покупок, сторінка оформлення замовлення зберігаються у кеші. WooCommerce Представники влади неодноразово наголошували, що Кошик для покупок / Оформлення замовлення / Обліковий запис не повинні кешуватися.

Б. Багатомовні/багатовалютні/регіональні варіанти не розрізняють кеш належним чином.

Якщо ваш сайт відображає різний вміст залежно від файлів cookie, параметрів запиту або географічного розташування, кешування має враховувати “вимір варіантів”. В іншому випадку кеш, створений користувачами з регіону А, може бути повторно використаний користувачами з регіону Б.

C. Переробка фронт-енду (JS/CSS) призвела до некоректної роботи функцій.

Зокрема, стиснення, об'єднання та відкладене виконання JS. WooCommerce навіть рекомендує це.Уникайте стискання файлів JavaScript.。

2. Перелік тестувань перед запуском.

  • Чи нормально проходить процес входу/виходу?
  • Чи правильно працює подання форми (контактна форма, підписка, реєстрація для входу)?
  • Процес електронної комерції: додати до кошика → купон → доставка/податки → оплата → сторінка замовлення.
  • Чи стабільна зміна мови (зміна контенту, URL, hreflang, валюти після переходу)?
  • Чи нормально працюють меню, спливаючі вікна, прокрутка та ліниве завантаження на мобільних пристроях?
  • Перевірте, чи скрипт відстеження все ще активний (Google Analytics, Meta Pixel, події конверсії).

загальні проблеми

Запитання 1: Чому, навіть після встановлення плагіна кешування, доступ до закордонних сайтів все ще повільний?

Найчастіша причина: ви вирішили лише проблему “повторної візуалізації на сервері”, але не вирішили проблему “міжконтинентальної затримки мережі”.
Плагіни кешування допомагають серверу швидше видавати контент (скорочення часу відгуку), але статичні ресурси (зображення, CSS, JS, шрифти) та час передачі даних по глобальній мережі все ще мають значення. CDN Щоб скоротити відстань.
👉 Тому правильний шлях:Спочатку необхідно налаштувати кешування на вихідному сервері.Потім розповсюджуємо його по всьому світу за допомогою CDN.。

Запитання 2: Чому, навіть після кешування, зміни, які я вношу, не оновлюються?

Це тому, що ви бачите “старий кеш”. Рішення:

  • Створіть стратегію очищення: очищуйте відповідний кеш після оновлення статті/сторінки (а не очищуйте весь сайт).
  • Для сценаріїв з попереднім нагріванням/скануванням: після очищення необхідно знову провести попереднє нагрівання, інакше перший візит буде повільним.
  • Для CDN: необхідно врахувати, що на краях CDN також можуть кешуватися старі ресурси.

Питання 3: Чи можна одночасно встановити WP Rocket та WP Super Cache?

Не рекомендується. Плагін кешування сторінок має працювати лише один одночасно. Ви можете розглядати ідею “один для кешування, інший для оптимізації” як “розподіл обов'язків”, але на практиці вони часто взаємодіють із кешуванням сторінок/перезаписом ресурсів, тому ймовірність конфліктів висока. Краще вибрати один “основний плагін кешування”, а інші потреби задовольняти за допомогою більш спеціалізованих інструментів.

Запитання 4: чи є використання кешування на електронній комерційній платформі дуже небезпечним?

Це не небезпечно. Небезпечно те, що “немає правил”.Рекомендації щодо WooCommerceДуже чітко: кошик для покупок/оплата/акаунт не зберігаються у кеші, і уникнуто стиснення JS-файлів.
Крім того, WooCommerce також згадує, що він працює з WP Super Cache має вбудовану сумісність.І за замовчуванням уникайте кешування ключових сторінок.
Отже, електронний магазин можна повністю кешувати, але, якщо вносити зміни в режимі онлайн, необхідно протестувати їх.

Запитання 5: Який плагін краще вибрати: LiteSpeed Cache чи WP Rocket?

  • Ви підтверджуєте, що хост є LiteSpeed/OpenLiteSpeed.Пріоритет: LiteSpeed Cache (безкоштовний і потужний, основні переваги надаються серверним LSCache).
  • Ви не впевнені у хостинг-сервері / не хочете займатися цим / хочете, щоб все було інтегровано та просте у використанні.WP Rocket надійніший.
  • Ви — власник контент-сайту, і ваш бюджет обмежений.WP Super Cache є більш стабільним і легким.

Плагін кешування в поєднанні з CDN.

Плагіни кешування вирішують проблему “недостатньої кількості серверів на вихідному рівні та низького показника TTFB”; CDN вирішує проблему “розміщення статичних ресурсів ближче до глобальних користувачів”. Комбінація цих двох факторів є найбільш оптимальним рішенням для забезпечення глобального доступу.

  • Типові комбінації на контент-сайтах:Кешування сторінок + статична дистрибуція через CDN.
  • Типові комбінації для динамічних веб-сайтів:Кешування сторінок (суворо виключено) + кешування об'єктів (за потреби) + статична дистрибуція через CDN.

👉 Читання:Акселерація CDN (глобальні вузли та стратегія кешування)

Рекомендована комбінація для кешування веб-сайтів.

1. Інформаційний сайт / блог / сайт документів

Ціль: Зменшити TTFB, забезпечити стабільне відображення першого екрана, знизити навантаження на сервер і налаштувати CDN для глобальної дистрибуції.

1.1 Найбільш зручний бізнес-комбінат

  • WP Rocket (кешування сторінок + попереднє завантаження + оптимізація фронтенду)
    • CDN (детальніше на сторінці CDN)

Застосування:

  • Ви хочете “менше налаштувань, швидкі результати та низький ризик”.”
  • Існує багато тем/плагінів, і я хочу зменшити кількість проблем із сумісністю.

Зверніть увагу:

  • Оптимізація фронтенду (особливо відкладання роботи JavaScript) включається поетапно, щоб уникнути некоректної роботи функцій (меню, форми, відстеження тощо).
  • Для сайтів, які часто оновлюють або публікують контент, необхідно використовувати стратегію “очищення + розігріву”, інакше перший візит на малопопулярну сторінку буде повільним.

1.2 безкоштовна та надійна класична комбінація.

  • WP Super Cache (кешування статичного HTML)Перетворюємо динамічні сторінки на статичні HTML-сторінки, в основному для неавторизованих користувачів.

Застосування:

  • Бюджет має бути чутливим до витрат, але при цьому стабільним.
  • Відвідувачі зазвичай не реєструються.
  • Ритм оновлення контенту можна контролювати.

Зверніть увагу:

  • Це комбінація “кешування сторінок на першому місці”, не очікуйте, що вона вирішить усі складні проблеми з CSS/JS.

2. Корпоративний сайт / Брендовий сайт / Цільова сторінка.

Ціль: Потрібно діяти швидко, але ще важливіше – “не переривати ланцюжок конвертації через оптимізацію”.

2.1 Надійний і контрольований (рекомендується для глобального розміщення/конверсійних сторінок)

  • WP Rocket
  • + (необов'язково) Легка оптимізація зображень (у вас є сторінка “Оптимізація зображень”)
    • CDN

Чому підходить для станції перетворення:

  • Станція конвертації найбільше боїться того, що “форма/спливаюче вікно/скрипт відстеження будуть зламані внаслідок оптимізації”.”
  • Ідея WP Rocket є більш “інтегрованою”. Ви можете активувати всі функції в одній системі і потім протестувати їх по одній.

Принципи запуску корпоративного вебсайту:

  • Оптимізація продуктивності — це “зміна після запуску”, для якої необхідно мати список регресійних тестів.
  • Будь-які налаштування, пов'язані із затримкою/об'єднанням/стисненням JS, мають бути спочатку перевірені в середовищі перед публікацією, а потім вже запущені в продакшн.

3. Інтернет-магазин WooCommerce (безпека замовлень і динамічних сторінок)

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

Офіційна позиція WooCommerce щодо плагінів кешування дуже чітка:Сторінки "Кошик", "Оплата" та "Обліковий запис" не повинні кешуватися.Крім того, рекомендується уникати стиснення файлів JavaScript, щоб зменшити проблеми із сумісністю.

3.1 Більш “дружні для новачків” безкоштовні безпечні маршрути.

  • WP Super Cache + WooCommerce
    • CDN

Чому це називають “безпечнішим варіантом для початківців”:

  • Офіційна сторінка WooCommerce згадує, що він сумісний з WP Super Cache, і повідомляє, що WP Super Cache за замовчуванням не кешує такі важливі сторінки, як кошик, оформлення замовлення та обліковий запис.
  • Для сайтів, які тільки починають працювати в сфері електронної комерції, важливіше “не допустити невдачі”, ніж “досягти максимальної продуктивності”.

3.2 Якщо ви користуєтеся хостингом LiteSpeed (безкоштовним, але дуже потужним)

  • LiteSpeed Cache (необхідно, щоб хостинг був на LiteSpeed/OpenLiteSpeed, аби використати переваги кешування на рівні сервера).
  • + (необов'язково) кешування об'єктів (Redis/Memcached, залежно від можливостей хосту та масштабу сайту)
    • CDN

Застосування:

  • Стек хосту чіткий, і ви готові встановити правила кешування та стратегії виключення.
  • Об'єм замовлень і кількість товарів великі, тому потрібно, щоб основний сервер краще справлявся з навантаженням.

3.3 Інженерна команда/складний електронний магазин (з керованими багатомодульними системами)

  • W3 Total Cache (фреймворк для підвищення продуктивності, що включає декілька рівнів кешування та інтеграцію з CDN).
    • Кешування об'єктів (за потреби)
    • CDN

Застосування:

  • Якщо є розробники/адміністратори, можна запустити в продакшн, використовуючи процес “поступове впровадження модулів + тестування під навантаженням + регресійне тестування”.
  • Потрібна кешування фрагментів/більш складна стратегія кешування (наприклад, детальне кешування за пристроєм/регіоном/мовою).

4. Сайти для членів / Спільноти / Онлайн-курси (часте входження, високий рівень персоналізації)

Ціль: Зробіть публічний контент швидким, забезпечивши при цьому, щоб “контент, призначений для зареєстрованих користувачів, не витікав”.

4.1 Це зручно, але вимагає ретельного виключення певних стратегій.

  • WP Rocket
  • + (необов'язково) кешування об'єктів (якщо багато динамічних запитів)
    • CDN

Ключові моменти:

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

4.2 Хостинг LiteSpeed + розширена стратегія

  • LiteSpeed Cache (серверний кеш + більш складні інструменти стратегії)
  • + (За потреби) кешування об'єктів
    • CDN

Ключові моменти:

  • Часто веб-сайтам для членів потрібен підхід “кешовані елементи + некешовані фрагменти”.
  • Стратегії попереднього нагрівання та очищення мають бути більш ретельними, інакше користувачі будуть надто часто бачити старий вміст після оновлення.

Кеш вебсайту “Бібліотека прикладів розмінування”.”

Приклад 1: після встановлення плагіна кешування швидкість практично не змінилася.

Явище:

  • Місцева/регіональна швидкість інтернету прийнятна, але за кордоном (між континентами) вона все ще повільна.
  • Час завантаження сторінки покращився, але загальний час завантаження не значно скоротився.

Часті причини:

  • Ви налаштували кешування тільки на сервері (TTFB), але статичні ресурси (зображення/JavaScript/CSS/шрифти) все ще завантажуються з сервера на іншому континенті.
  • Скрипти третіх сторін (реклама, чат, статистика) уповільнюють відображення та взаємодію.
  • Зображення занадто великі, тому вони повільно завантажуються (кешування не вирішує проблему з розміром при першому завантаженні).

Спосіб вирішення:

  • Плагін кешування спочатку відповідає за “недостатню кількість запитів до сервера + високий рівень попадання в кеш”.”
  • Статичні ресурси передаються через CDN.
  • Зображення підлягають оптимізації зображень.
  • Скрипти третіх сторін використовують стратегії затримки/розділення.

Чітання:

Приклад 2: після включення кешування, сторінка була змінена, але інтерфейс не оновився.

Явище:

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

Часті причини:

  • Кеш сторінки не очищено або діапазон очищення неправильний.
  • Нагрів/сканування не запущені, очищення кешу призвело до повільного завантаження при першому відвідуванні, а ви помилково думали, що оновлення не відбулося.
  • Якщо ви активували кешування на краях CDN, краї також можуть зберігати старі ресурси.

Спосіб вирішення:

  • Створіть “стратегію очищення після публікації/оновлення”: очищуйте відповідні сторінки, а не весь сайт в цілому.
  • Створіть стратегію попереднього нагрівання для важливих сторінок (головна сторінка, основна цільова сторінка), щоб уникнути ситуації, коли “очищення = уповільнення”.”
  • Шар CDN виконує очищення на краях у разі необхідності.

Випадок 3: після перемикання на іншу мову/валюту, контент став некоректним.

Явище:

  • Після зміни мови сторінка все ще відображає попередню мову.
  • Або користувачі в певних регіонах бачать неправильну валюту/неправильний вміст.

Часті причини:

  • Кеш не розрізняє “виміри варіантів” (кукі/параметри/мовні префікси/субдомени).
  • У результаті кеш-хіта користувачеві, який розмовляє мовою B, було надано сторінку результатів мовою A.

Спосіб вирішення:

  • Відокремте ваш багатомовний проект: каталог/піддомен/параметри/кукі.
  • Додайте до правил кешування “стратегію варіантів” або виключіть ключові сторінки.
  • Деякі сайти вимагають більш просунутої концепції кешування фрагментів (W3TC краще підходить для інженерного контролю).

Випадок 4: після включення кешування на сайті електронної комерції виникли проблеми з кошиком для покупок/оплатою.

Явище:

  • Кількість товарів у кошику неправильна,ціна неправильна, кнопка оформлення замовлення не працює.
  • Після входу ви бачите контент, який не належить вам (серйозно)

Часті причини:

  • Такі ключові сторінки, як "Кошик", "Оформлення замовлення" та "Мій акаунт", зберігаються у кеші.
  • Зменшення/об'єднання JS-файлів призводить до несумісності платіжних/динамічних компонентів.

Спосіб вирішення:

  • Представники WooCommerce чітко заявляють, що не слід кешувати кошик/сторінку оформлення замовлення/акаунт, а також рекомендують уникати стиснення файлів JavaScript.
  • Спочатку налаштуйте “кешування сторінок + виключення”, а потім вже думайте про оптимізацію фронтенду.
  • Якщо ви використовуєте WP Super Cache, WooCommerce заявляє про його вбудовану сумісність і те, що він за замовчуванням не кешує ключові сторінки.

Випадок 5: після включення функції “Відкладення JS/Об'єднання скриптів”, меню/форми/спливаючі вікна перестали працювати.

Явище:

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

Часті причини:

  • Відкладення JS змінює час виконання скриптів: скрипти не виконуються до взаємодії користувача, а деякі компоненти залежать від того, що сторінка ініціалізується під час завантаження.“
  • Об'єднання/стиснення може змінити порядок скриптів або порушити залежності.

Офіційні представники WP Rocket описують “відкладену виконання JS-коду” як одну з найпотужніших функцій оптимізації JS: скрипти відкладаються до моменту взаємодії користувача, що дозволяє пріоритетно відображати сторінку. Ця функція є дуже корисною, але вона також спричиняє підвищений ризик несумісності.

Спосіб вирішення:

  • Поетапне запущення: спочатку кешування, потім зображення, потім CSS, і нарешті JS.
  • Додати виключення для ключових скриптів (оплата, форми, меню, відстеження)
  • Після кожної зміни необхідно проводити регресійне тестування.

Приклад 6: Я встановив LiteSpeed Cache, але не помітив особливої користі від його використання.

Явище:

  • Я включив LiteSpeed Cache, але час відгуку сервера (TTFB) не сильно зменшився.
  • Відсоток попадань теж не дуже високий.

Часті причини:

  • Ваш сервер не є LiteSpeed/OpenLiteSpeed, тому ви не можете користуватися основними можливостями LSCache.
  • Або ви активували купу оптимізацій, але не налаштували “стратегію кешування сторінок/передобування/виключення”.

Спосіб вирішення:

  • Спочатку перевірте стек хосту: чи є він LiteSpeed/OpenLiteSpeed (це обов'язкова умова).
  • Зосередьтеся на наступних аспектах роботи: “стратегія кешування сторінок + попереднє нагрівання + виключення + очищення”.”
  • Якщо це не хостинг LiteSpeed: розгляньте WP Rocket або WP Super Cache.