Першопричиною “повільності” сайту зазвичай є не конкретне зображення, аПосилання на запит + генерація сервера + статичний розподіл ресурсівспричинені накладанням:

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

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

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

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

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

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

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

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

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

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

Коротко про головне: 4 найпоширеніші сценарії для веб-сайтів

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

  1. Хочете заощаджувати гроші, бути стабільними та орієнтованими на глобальний доступ → WP Rocket(Платно)
  2. Хостинг явно LiteSpeed/OpenLiteSpeed → LiteSpeed Cache(безкоштовно, але сильно залежить від потужності сервера): Функція кешування вимагає Серверні компоненти 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 не тому, що він чарівний, а тому, що він перетворює три найпоширеніші типи продуктивності в “керовані пакети”:

  • Кешування сторінок (зменшує TTFB вихідного сайту)
  • Попереднє завантаження/підігрів кешу (для покращення досвіду першого відвідування з глобально розподіленим доступом)
  • Ключові оптимізації фронтенду (особливо затримки JS, обробка CSS тощо)
Оптимізація кешу WordPress - HOSTFO

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

1.1 Для кого WP Rocket

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

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

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

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

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

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

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

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

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

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

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

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

C. Сумісність з іншими плагінами/темами: “нульовий конфлікт” - це не те саме, що "душевний спокій".”

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

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

1.3 Спеціальне нагадування для WooCommerce/динамічних сайтів

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

Чому? Для чого:

  • Сильна залежність від cookie / сесії / nonce для сторінок кошика, оформлення замовлення, облікового запису
  • Якщо кеш сприйматиме ці сторінки як “статичні”, кнопки не працюватимуть, а інформація про ціну/інвентар/рахунок буде спотворена.
  • Ось найстрашніше: ви можете добре протестувати в одному регіоні і мати проблеми в іншому через розбіжності в CDN/кеш-пам'яті!

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

Рівень 1: Базові переваги безпеки (майже всі станції повинні це робити)

  • Увімкнути кешування сторінок
  • відкриваєтьсяПопереднє завантаження кешу(Підвищення стабільності першого візиту)
  • Розумна політика кешування браузера (WP Rocket/Server/CDN Можна реалізувати будь-який рівень)

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

  • Затримка завантаження зображень/iframe (сторінка оптимізації зображень йде далі)
  • Керування обсягом CSS (наприклад, видалення невикористаного CSS)

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

  • Відкладене виконання JavaScript (надає пріоритет рендерингу, але може впливати на взаємодію)
  • Стиснення/злиття JS/CSS: будьте особливо обережні з електронною комерцією/користувачами/багатомовними (WooCommerce також попереджає про ризик стиснення JS）

1.5 Ціни та дозволи

  • WP Rocket - платна ліцензія, з різними ліцензіями залежно від кількості сайтів.

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

Оптимізація кешу WordPress - HOSTFO

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

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

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

2.1 LiteSpeed Cacheдля кого

Підходить:

  • Ваша панель хостингу чітко позначена 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 + вбудованого LSCache LiteSpeed Server: плагін відповідає за видачу правил і сигналів очищення, а справжнє високошвидкісне кешування сторінок відбувається всерверний рівень。

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

2.3 “Правильний спосіб” відкриття LSCWP для сценаріїв користувачів веб-сайту”

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

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

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

Цей шар, якщо все зроблено правильно, є найбільш видимим для веб-сайту як TTFB знизився, перший екран стабільніший。

Рівень 2: Прогрівання/Блукач (визначає “повільне перше відвідування холодної сторінки”)

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

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

Підігрів - це не вишенька на торті, а ключ до стабільного досвіду відвідувачів сайту

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

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

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

Рівень 4: Онлайн-сервіси та додаткові можливості

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

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

2.4 Загальний котлован ЛУЖКГ

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

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

Оптимізація кешу WordPress - HOSTFO

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

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

3.1 Для кого призначений WP Super Cache?

Дуже рекомендую:

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

Будьте обережні/потрібні сильніші стратегії:

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

3.2 Три методи кешування:

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

  • mod_rewrite (expert): найшвидший, повністю обходить PHP, але потрібно змінити .htaccess, неправильна конфігурація може призвести до недоступності сайту, ризик вищий!
  • Простий (рекомендований підхід): “Супер кешовані” статичні файли, що надаються PHP, близькі за швидкістю до mod_rewrite, але простіші у налаштуванні.
  • WP-Cache Кеш-пам'ять: більш гнучкий для відомих користувачів, URL-адреси з параметрами, стрічки підписок тощо, але повільніший

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

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

3.3 Сильні та слабкі сторони WP Super Cache

Перевага:

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

Коротка дошка:

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

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

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

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

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

Оптимізація кешу WordPress - HOSTFO

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

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

4.1 Для кого призначений W3 Total Cache?

Ідеально підходить:

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

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

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

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

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

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

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

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

4.3 “Рекомендований порядок увімкнення” W3TC”

Рекомендоване замовлення:

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

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

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

Примітка: Це не “хто кращий”, а “хто краще підходить для вашого сценарію”.

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

“Інциденти з кешем” та контрольний список для запобігання

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

A. Розгляд “державних” сторінок як “статичних сторінок без громадянства”

Зазвичай: сторінка облікового запису, кошик, сторінка оформлення замовлення кешуються.WooCommerce Урядовці неодноразово наголошували Кошик/Каса/Акаунт не повинні бути закешовані.

B. Багатомовні / мультивалютні / регіональні варіанти кешуються некоректно

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

C. Переписування оптимізації фронтенду (JS/CSS), що призводить до функціональних аномалій

Зокрема, стиснення JS, злиття та відкладене виконання.Уникнення стиснення JS-файлів。

2. контрольний список регресійного тестування перед запуском

  • Вхід/вихід є нормальним
  • Форми (контактна форма, підписка, реєстрація входу) працюють належним чином
  • Процес електронної комерції: додати покупку → купон → доставка/податки → оплата → сторінка замовлення
  • Стабільність багатомовного перемикання (контент, URL-адреси, грефланги, валюта після перемикання)
  • Мобільні меню, спливаючі вікна, прокрутка, ліниве завантаження працюють належним чином
  • Відстежуйте, чи все ще спрацьовують скрипти (GA, Meta Pixel, події трансформації)

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

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

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

Q2: Чому контент не оновлюється після того, як я змінив його після кешування?

Тому що ви бачите “старий кеш”. Ідея рішення:

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

Q3: Чи можу я встановити WP Rocket + WP Super Cache одночасно?

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

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

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

Q5: Що обрати: LiteSpeed Cache чи WP Rocket?

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

Плагін кешу з CDN

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

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

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

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

1. контент сайту / блогу / документального сайту

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

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

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

Прийнятно:

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

На що слід звернути увагу:

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

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

Прийнятно:

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

4. членський сайт / спільнота / онлайн-курси (багато логінів, сильна персоналізація)

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

4.1 Зберегти, але потребують суворих стратегій виключення

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

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

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

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

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

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

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

Веб-кеш “Практичний посібник з розмінування”

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

Феномен:

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

Загальні причини:

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

Ідея рішення:

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

Читаю:

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

Феномен:

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

Загальні причини:

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

Ідея рішення:

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

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

Феномен:

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

Загальні причини:

  • Кеш не розрізняє “виміри варіантів” (файл cookie / параметр / мовний префікс / субдомен)
  • Потрапляння в кеш надає користувачам мови А результати сторінки мовою Б

Ідея рішення:

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

Кейс 4: Проблеми з кошиком/оформленням замовлення на сайті електронної комерції з увімкненим кешуванням

Феномен:

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

Загальні причини:

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

Ідея рішення:

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

Випадок 5: Меню/форма/спливаюче вікно не працює після увімкнення “Delay JS/Merge Scripts”.

Феномен:

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

Загальні причини:

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

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

Ідея рішення:

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

Випадок 6: Встановлено лише LiteSpeed Cache, але здається, що він не працює.

Феномен:

  • LiteSpeed Cache увімкнено, але TTFB не сильно падає.
  • Збіги також не є очевидними

Загальні причини:

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

Ідея рішення:

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