Якщо розділити оптимізацію продуктивності WordPress на три рівні:

  • Шар вихідних станційХостинг / PHP / база даних / плагін кешування — визначають TTFB і навантаження на бекенд.
  • Шар ресурсівОптимізація зображень — визначає розмір файлу для завантаження та швидкість завантаження великих зображень на першому екрані.
  • Рівень доставки.CDN —— забезпечує більш швидкий доступ до ресурсів для відвідувачів, стабільнішу роботу та менше навантаження на сервер.

Ця стаття розповідає про... Акселерація CDN：

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

1. Найперше, давайте уточнимо концепцію: що CDN робить, а чого не робить?

1.1 CDN в основному вирішує три завдання.

1.1.1 Швидша доставка статичних ресурсів.
Статичні ресурси, такі як зображення, CSS, JS, шрифти та іконки, знаходяться ближче до відвідувачів, завантажуються швидше і забезпечують більш стабільне відображення сторінок.
Для WordPress, особливо для ресурсів тем і плагінів (wp-content/themes/、wp-content/plugins/а також зображення з медіатеки (wp-content/uploads/Вони зазвичай є “великогабаритними”.

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

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

1.2 Проблеми третього типу, які не вирішуються автоматично CDN.

1.2.1 Сам веб-сервер працює повільно.
Повільна робота бази даних, повільна логіка плагінів, повільні обчислення в PHP — це проблеми на рівні сервера.
CDN може прискорити завантаження статичних ресурсів, але якщо навіть HTML-код головної сторінки генерується дуже повільно, користувачі все одно відчуватимуть, що сайт “повільно завантажується”. У цьому випадку слід у першу чергу зосередитися на: хостингу/кешуванні плагінів/оптимізації бази даних.

1.2.2 Саме зображення занадто велике.
CDN не може “чарівним чином” зменшити розмір великого зображення об'ємом 3 МБ.
Спочатку вам потрібно оптимізувати зображення: стратегія розмірів (не завантажуйте надто великі зображення), стиснення, WebP/AVIF, стратегія лінивого завантаження тощо.

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

Рекомендація

Спочатку налаштуйте рівень вихідного сервера та рівень ресурсів, а потім встановіть CDN. Це дасть більш відчутний результат і дозволить уникнути багатьох проблем.

2. Вибір за 30 секунд: який тип CDN вам потрібен?

Для WordPress існують дві основні категорії. Спочатку ви вибираєте “формат”, а потім — “провайдера послуг”, і таким чином все стає набагато зрозумілішим.

2.1 Інтегрований “реверсний проксі” (більш зручний і підходить для більшості сайтів)

**Особливості:** Це не просто CDN, а й також... DNS / SSL / базова безпека (наприклад, DDoS/WAF) Давайте упакуємо це. Після того, як ви підключитеся, він буде виступати в ролі проксі-сервера для вашого вебсайту.

Що ви отримаєте:

  • HTTPS-сертифікати та управління TLS стали простішими.
  • Об'єднаний вхід для захисту безпеки (базовий DDoS, контроль доступу, WAF тощо)
  • Кешування на краях та движок правил (що дозволяє реалізовувати більш детальні стратегії кешування та обхідні стратегії).
  • “Великий потенціал для розширення”: якщо в майбутньому ви захочете додати функції безпеки, обмеження швидкості або захист від ботів, вони зазвичай будуть інтегровані в ту саму систему.

**Представники:** Cloudflare / Tencent Cloud International EdgeOne / Alibaba Cloud International ESA

Якщо ви хочете:

  • Ви хочете HTTPS + CDN + базова безпека Зробити це один раз
  • Ви готові передати управління доменом/проксі-сервером одній платформі?
  • Ви надаєте перевагу “комплексному досвіду та подальшому розширенню”, не бажаючи розділяти DNS, сертифікати, CDN та безпеку на кілька наборів.

2.2 Чистий “статичний Pull CDN” (початок з низьким ризиком, в основному для прискорення завантаження зображень/CSS/JS).

**Особливості:** ви розміщуєте лише статичні ресурси у кеші на краях CDN; відповідальність за HTML-сторінки все ще несе вихідний сайт (а також плагіни кешування на вихідному сайті).

Що ви отримаєте:

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

**Представник:** bunny.net (модель розрахунку за обсяг роботи чітка)

Якщо ви хочете:

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

3. Як це зробити?

  • Перший рівень: інтегрований агентський тип (рекомендується)Cloudflare / EdgeOne / ESA
  • Другий рівень: статичний Pull CDN (надійний початок):bunny.net / Cloudways CDN тощо.

4. Рекомендовані постачальники послуг.

4.1 CloudflareІнтеграція зворотного проксі-сервера (безкоштовний старт, зріла екосистема)

Акселерація CDN у WordPress — LikaCloud.

Що це?
Після підключення доменного імені, воно виступатиме в ролі проксі-сервера для веб-сайту, забезпечуючи CDN, сертифікати, базовий захист і можливості кешування.

Для кого це підходить?

  • Хочете заощадити зусилля: HTTPS + CDN + базова безпека в одному пакеті.
  • Хочете розвинути екосистему: надалі потрібно додати WAF, обмеження швидкості, правила для крайових мереж тощо. Цей шлях є доволі прямим.

Пункти ризику

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

Опис：

  • Позиціонування: інтегрований зворотний проксі (SSL + CDN + базова захист)
  • Підходить для: безтурботного запуску, з великим потенціалом для подальшого розширення.
  • Основні цінності: єдиний сертифікат/безпека/кеш-вхід.
  • Ризик: оновлення залежить від стратегії версій; кешування HTML має бути суворо обхідне.

4.2 Тенцент Клауд Інтернешнл ЕджОнІнтеграція зворотного проксі-сервера.

Акселерація CDN у WordPress — LikaCloud.

Що це?
Ця платформа також є інтегрованою, що включає в себе “прискорення + безпеку + сертифікацію”, і підходить для розміщення сайтів на єдиному рівні проксі-сервера для управління.

  • Як і у Cloudflare, є безкоштовна версія, але зазвичай вона має обмежені можливості. Квоти/обмеження функціональних можливостей.(Кількість правил, кількість завдань журналювання тощо), але немає необхідності змінювати DNS, достатньо лише налаштувати доступ за допомогою CNAME.Не рекомендується використовувати безкоштовну версію для комерційних веб-сайтів.！
  • У той же час, безкоштовні плани часто означають, що SLA не гарантує
    Це працює, але не слід розглядати його як “комерційний пакет SLA”.
  • Якщо ви хочете автоматично перемикатися на китайські сервери в материковому Китаї, зазвичай для цього потрібно спочатку виконати наступні дії:Реєстрація ICP у КитаїКоли немає реєстрації, можна користуватися лише міжнародними маршрутами.

Пояснення:

  • Позиціонування: інтегрований зворотний проксі (прискорення + безпека + сертифікати)
  • Підходить для: тих, хто хоче інтегрований доступ і бере до уваги можливості вузлів у материковому Китаї.
  • Безкоштовно: існують безкоштовні плани/безкоштовні версії, але обмежено квоти, і угода про рівень послуг (SLA) зазвичай не гарантується.
  • Ризик: правила/журнали/квоти для піддоменів повинні бути заплановані заздалегідь; до кешування HTML також потрібно підходити з обережністю.

4.3 Альibaba Cloud International ESAІнтеграція зворотного проксі-сервера.

Акселерація CDN у WordPress — LikaCloud.
  • Як і у Cloudflare, є безкоштовна версія, але зазвичай вона має обмежені можливості. Квоти/обмеження функціональних можливостей.(Кількість правил, кількість завдань журналювання тощо), але немає необхідності змінювати DNS, достатньо лише налаштувати доступ за допомогою CNAME.Не рекомендується використовувати безкоштовну версію для комерційних веб-сайтів.！
  • Щоб користуватися послугою, достатньо зареєструвати обліковий запис на міжнародному сайті.
  • Ввійдіть до консолі ESA, додайте сайт і виберіть безкоштовний план. Вхід Доступ до пакета послуг
  • Якщо ви хочете автоматично перемикатися на китайські сервери на материковій частині Китаю, вам зазвичай необхідно спочатку пройти реєстрацію в ICP; без реєстрації ви зможете користуватися лише міжнародними серверами.
  • Безкоштовні пакети більше підходять для розробки/тестування/оцінки і зазвичай не відповідають комерційним пакетам SLA.
  • Безкоштовні пакети часто мають обмеження швидкості/обмеження підтримки (наприклад, угода про рівень послуг тощо).

Що стосується маршрутів у материковому Китаї:

  • Щоб активувати вузол у материковому Китаї, зазвичай необхідно виконати вимоги щодо реєстрації та географічного розташування.
  • Вхід безкоштовний, але за умовчанням відвідувачі повинні пройти через міжнародний термінал. Якщо вони хочуть пройти через термінал на материковій частині Китаю, їм необхідно виконати відповідні формальності.Вимоги до реєстрації ICP у Китаї

Пояснення:

  • Позиціонування: інтегрований зворотний проксі (прискорення сайту + безпека)
  • Безкоштовно: доступ до міжнародного сайту через Entrance; за замовчуванням не включає прискорення для материкового Китаю.
  • Підходить для: оцінки/тестування та нерегулярного використання; або для подальшого оновлення пакета.
  • Ризик: уважно ознайомтеся з умовами безкоштовного трафіку (рівень обслуговування/обмеження швидкості/методи підтримки); заздалегідь сплануйте розподіл регіонів і процес реєстрації.

4.4 \nbunny.netСтатичний Pull CDN (низький ризик для початку, чіткий розрахунок оплати за обсяг використання)

Акселерація CDN у WordPress — LikaCloud.

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

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

  • Зроби це спочатку. Зображення / CSS / JS / Шрифти Статичне прискорення
  • Ви хочете спочатку отримати “низький ризик і стабільний прибуток”, не поспішаючи передавати весь сайт на агентську платформу (інтегровані DNS/SSL/WAF).
  • Ви хочете, щоб модель витрат була ближча до формату “скільки витрачаєш, стільки й платиш”, а не переходила відразу до більш складної системи тарифних планів.

Пункти ризику

Майже завжди, коли статичні ресурси “не оновлюються”, це не через помилку CDN.Але це нормальна робота системи кешування:
Коли ви оновлюєте CSS/JS/зображення у фоновому режимі, алеURL ресурсу не змінився.У цьому випадку (з тією самою адресою/назвою файлу/шляхом) CDN і браузер продовжать користуватися старим кешем, тому ви бачитимете повідомлення “Чому не оновилося?”.

Чіткий, виконуваний принцип:

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

Чому це найнадійніший варіант:

  • Зміна номера версії/назви файлу. → Зміна URL → Кешування нових ресурсів у CDN → Нова версія запускається майже негайно.
  • **Очищення кешу** вимагає вашого активного втручання, і може призвести до неточного визначення діапазону та затримки поширення даних між вузлами; часте очищення кешу також може призвести до зниження показника ефективності, збільшення кількості звернень до сервера та посилення коливань.

Зрозумілий приклад:

  • style.css Змінився контент, але URL залишився той самий. style.css → CDN продовжує використовувати старий кеш (розумно)
  • URL перетворюється на style.css?ver=20260103 或 style.abc123.css → CDN вважає це новим ресурсом → нова версія негайно вступає в дію.

Ну, а Банні — це кращий приклад “першого кроку до CDN”.

  1. Найперше покрийте лише статичні ресурси.(Зображення/CSS/JS/шрифти), не кешуйте HTML відразу.
    • Переваги: практично немає серйозних інцидентів, коли користувачі бачать чужий вміст або номери кошиків для покупок.
    • Вам також легше перевірити прибуток: статичні ресурси завантажуються швидше, а сервер працює швидше й ефективніше.
  2. Сплануйте стратегію оновлення.
    • CSS/JS: наскільки можливо, використовуйте номери версій/зміни назв файлів.
    • Зображення: наскільки це можливо, уникайте довготривалого “перекриття імен”, краще змініть назву файлу або шлях (особливо для банерів на головній сторінці та зображень подій).
  3. Після запуску перевірте результати за допомогою контрольного списку.
    • Чи статичні ресурси надходять з CDN?
    • Чи поступово зростає відсоток успішних запитів, чи стабільніша пропускна здатність сервера/запитів (нижче наведено список перевірок)?

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

Якщо ваш бізнес пов'язаний з материковим Китаєм або ви хочете, щоб ваш вебсайт був доступний у материковому Китаї швидше.

Алівукл-Китай та Тенцент-Клауд-Китай заслуговують вашого вибору. Якщо ваше доменне ім'я вже зареєстровано в материковому Китаї, при використанні EdgeOne або ESA під час доступу з материкового Китаю, він автоматично перемикається на китайський сервер.

“Використовуйте вузли в материковому Китаї.”Це зазвичай включає реєстрацію в ICP.

\nДжерело

“Оптимізація досвіду транскордонного доступу до веб-сайтів.”Це може бути інша окрема функція, яка зазвичай не означає “безкоштовний доступ до серверів у материковому Китаї”.”

5. План запуску: реалізація у три етапи (від стабільного до сильного).

Найчастіша причина, через яку CDN-мережа може не працювати належним чином, — це спроба відразу активувати всі її можливості.

Етап 1: використовуйте тільки CDN для статичних ресурсів (наполегливо рекомендується зробити це в першу чергу).

ЦільЗображення/CSS/JS/шрифти спочатку передаються через CDN; HTML не кешується в CDN (або не змінюється тимчасово).

Чому краще спочатку зробити це?

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

Часті проблеми на цьому етапі (детальна інформація про їх усунення буде надана пізніше)

  • Змішаний вміст (сторінка HTTPS із завантаженими ресурсами HTTP)
  • Оновлення статичних ресурсів не впливає (адреса URL не змінилася).

Етап 2: Оновлення стратегії (пріоритет номеру версії, очищення/вилучення застарілих даних в якості запасного варіанту).

Це переломний момент для того, чи є CDN професійним чи ні.

Жорстке правило:

Оновлення, які можна вирішити за допомогою зміни номера версії/назви файлу, не повинні залежати від Purge.

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

  • Кеш браузера: у вас на локальному рівні може бути кешований старий CSS/JS.
  • Кешування CDN: крайові вузли можуть кешувати старі ресурси.
  • Кешування на стороні сервера: кешувальний плагін/кеш сервера, можливо, все ще видає старий вміст.

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

Етап 3 (розширений): чи кешувати HTML (високий прибуток, але найвищий ризик)

Кешування HTML (кешування всього сайту/кешування на краях) може значно зменшити TTFB, але у випадку з WordPress це також область, де часто трапляються збої.

Якщо ви не впевнені, не кешуйте HTML. Спочатку використовуйте статичний CDN та плагін кешування на сервері.

Якщо ви хочете кешувати HTML, дотримуйтеся двох принципів:

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

6. Перелік правил для сценаріїв: як уникнути нещасних випадків на різних типах станцій.

6.1 Інформаційний сайт/блог (в основному статті, багато відвідувачів)

Рекомендація

  • Статичні ресурси: повне кешування.
  • HTML: можна розглянути можливість кешування “сторінки для неавторизованих відвідувачів”.”

Зазвичай необхідно обійти це.

  • Задній план і вхід у систему:/wp-admin/*、/wp-login.php
  • Перегляд/чернетка (preview)
  • Сторінка результатів пошуку (параметри часто змінюються, тому краще не кешувати її на початку).
  • POST-запит на відправку форми/коментаря.

Ключ кешування має бути, як мінімум, унікальним.

  • Чи є ви зареєстрованим користувачем (параметр cookie)?
  • Мова (багатомовний сайт)

6.2 Корпоративний сайт / сторінка для маркетингових кампаній (багато форм та заходів)

Рекомендація

  • Статичні ресурси: повне кешування.
  • HTML: відкриті цільові сторінки можуть кешуватися (у режимі відвідувача), але слід обережно ставитися до сторінок із результатами форм.

Найчастіша помилка: відстеження параметрів призводить до фрагментації кешу.
Цільові сторінки є звичним явищем. utm_* Параметри:

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

6.3 Сторінки для членів / сторінки курсів / спільноти (високий відсоток користувачів, які входять у систему)

ВисновокНеобхідно дуже обережно ставитися до кешування HTML.
Зазвичай краще використовувати статичний CDN у поєднанні з кешуванням на стороні сервера/кешуванням об'єктів; HTML-сторінки кешуються тільки для відвідувачів сайту.

Необхідно обійти це.

  • Вхід/реєстрація/відновлення паролю
  • Центр облікових записів, замовлення/підписки, профіль.
  • Будь-які сторінки та інтерфейси, які мають “сильну кореляцію з користувацьким режимом”.

6.4 Інтернет-магазин (WooCommerce)

Найважливіший список для обходу

  • Кошик для покупок, оформлення замовлення, сторінка облікового запису.
  • Сторінки, пов'язані з підтвердженням замовлення та зворотним платежем.
  • Вхід/реєстрація, купони/бонусні бали тощо – всі вхідні сторінки, пов'язані з обліковим записом користувача.

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

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

6.5 багатомовний/багатовалютний сайт

Рекомендація

  • Статичні ресурси: повне кешування.
  • HTML: можна кешувати інформацію про відвідувачів, але ключі кешування повинні чітко розрізняти мовні/валютні варіанти.

Необхідно врахувати ключ кешування.

  • Мова (шлях) /en/ /zh/ або піддомен en.）
  • Чи ввійшли ви (кукі)?
  • Валюта/ставка податку (якщо це впливає на відображення)

7 Інформація про ризики

Ризик 1: кешування неправильного вмісту (найсерйозніший)

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

Ризик 2: оновлення не вступає в силу (найчастіше).

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

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

Ризик 3: обмеження, передбачені для безкоштовної/базової версії.

  • Часті особливості безкоштовних планів: обмежені квоти, відсутність деяких функціональних можливостей, а також різні умови SLA/підтримки у порівнянні з комерційними продуктами.

Ризик 4: відповідні можливості материкового Китаю можуть бути неправильно зрозумілі.

  • ЕСА: для того, щоб користуватися послугами на материковій частині Китаю, необхідно пройти реєстрацію в китайському реєстрі інтернет-контенту (ICP).
  • EdgeOne: для того, щоб користуватися послугами на території материкового Китаю, необхідно пройти реєстрацію в китайському реєстрі інтернет-контенту (ICP).

8 перевірочних списків: як підтвердити, що вони “дійсно працюють” після запуску.”

8.1 Чи справді статичні ресурси передаються через CDN?

  • Чи зображення/CSS/JS походять з домену CDN/крайових вузлів?
  • Чи можна побачити очевидні ознаки кешування (позначки на різних платформах відрізняються)?

8.2 Чи тиск на вихідній станції знижується?

  • Чи є пропускна здатність вихідного сервера більш стабільною?
  • Чи зменшилася кількість запитів до вихідного сервера/кількість підключень (особливо запитів до повторних ресурсів)?

Чи можна контролювати оновлення 8.3?

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

8.4 Чи правильно налаштована динамічна ключова сторінка?

(Обов'язково для електронної комерції/сайтів для членів)

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

8. Чи зросла кількість помилок?

  • Термін відновлення після збою, помилка 5xx, періодична недоступність.
  • Це зазвичай означає: недостатня пропускна здатність вихідної станції, неправильні правила, спрацював ліміт швидкості або проблеми з каналом зв'язку з вихідною станцією.

9 Усунення неполадок із недійсними оновленнями (перетворення “метафізики” на конкретні кроки)

Спочатку визначте, з якою проблемою ви зіткнулися:

9.1 Статичні ресурси не оновлені (CSS/JS/зображення все ще старі).

Ситуація А: тільки ви бачите старе, а невидимість/зміна пристрою — це нове.
Пріоритетна гіпотеза: кеш браузера.

  • Рішення: випуск нових ресурсів з зміненими номерами версій/ назвами файлів.

Ситуація B: всі бачать старе (невидиме/старе на різних пристроях)
Пріоритетна гіпотеза: CDN все ще використовує старий кеш.

  • 991TP4Т. Причина: URL ресурсу не змінився.
  • Пріоритетне рішення: стратегія версій.
  • Закрити питання: Purge (тимчасовий захід)

Ситуація C: після перезапису зображення з тією самою назвою стара картинка все ще відображається.
Це класична проблема, коли кеш браузера та кеш CDN працюють разом.

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

9.2 HTML не оновлено (зміст сторінки/модулі все ще старі).

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

  • Спочатку перевірте, чи слід кешувати HTML на таких сторінках.
  • Якщо необхідно кешувати: потрібна стратегія контрольованого оновлення, в іншому випадку публікація буде неконтрольована.

Ситуація B: лише деякі регіони/частини мережі надають зворотний зв'язок щодо старого вмісту.
Пріоритетна гіпотеза: різні крайові вузли зберігають різні стани кеша.

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

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

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

10. Рекомендація

Cloudflare

  • Інтеграція зворотного проксі-сервера.
  • Підходить для: безтурботного старту.
  • Головне: стратегія версій вирішує проблему оновлення; кешування HTML відбувається в режимі гостя.
  • Ризик: динамічні сторінки повинні бути обхідні.

Тенцент Клауд Інтернешнл ЕджОн

  • Інтеграція зворотного проксі-сервера.
  • Придатно: врахуйте пропускну здатність вузлів у материковому Китаї та можливість інтегрованого доступу.
  • Безкоштовно: існують безкоштовні плани/безкоштовні версії, але необхідно уважно ознайомитися з обмеженнями та умовами використання.
  • Ризик: необхідно планувати квоти для правил/журналів/субдоменів; обережно ставитися до кешування HTML.

Альibaba Cloud International ESA

  • Інтеграція зворотного проксі-сервера.
  • Безкоштовно: міжнародний обліковий запис Entrance забезпечує безкоштовний доступ.
  • Ризик: необхідно заздалегідь перевірити безкоштовні обмеження (SLA/підтримка/обмеження швидкості) та умови щодо регіону/реєстрації.
  • Придатно для: оцінки/тестування та легкого доступу; або для подальшого оновлення пакета, або для розгляду можливостей вузлів у материковому Китаї та інтегрованого доступу.

\nbunny.net

  • Статичне витягування CDN
  • Показано: спочатку виконайте статичне прискорення з низьким рівнем ризику.
  • Головне: пріоритет надається номеру версії, а Purge забезпечує підтримку; уникайте перекриття з однаковими назвами.
  • Ризик: якщо стратегія оновлення не буде належним чином реалізована, ви часто будете стикатися зі “старими ресурсами”.”

11. Пропозиції щодо дій

  1. Спочатку виберіть формат: інтегрований зворотний проксі (Cloudflare/EdgeOne/ESA) або статичний Pull CDN (Bunny).
  2. Запуск у різні етапи:Спочатку статична версія → потім стратегія версій → і нарешті, розглянемо кешування HTML.
  3. Після запуску перевірте за списком перевірки: попадання/повернення на вихідну сторінку/оновлення/динамічне обхідняння/показник помилок.
  4. Потрібно швидше: поверніться до “Плагінів кешування” та “Оптимізації зображень”, і знову стисніть рівень вихідної станції та рівень ресурсів.

Часті запитання про CDN у WordPress

1. Чому все ще повільно, навіть якщо я використовую CDN?

Найчастіша причина не в тому, що CDN не працює, а в тому, що вузьким місцем є не “шар доставки”.

Ви можете оцінити це в такому порядку:

  • Час завантаження сторінки (TTFB) все ще дуже високий.Поясніть, що джерело генерує HTML повільно (ฐта база даних/плагіни/налаштування кешування/продуктивність хосту) → поверніться до оптимізації на рівні джерела.
  • Зображення на головному екрані завантажується дуже повільно.Поясніть, що розмір, формат або параметри зображення неправильні → спочатку оптимізуйте зображення (стиснення, WebP/AVIF, стратегія розміру).
  • Скрипти сторонніх розробників сповільнюють роботу.Рекламні/статистичні/службові скрипти є поширеними → CDN зазвичай не допомагає, необхідно зменшити або відкласти завантаження.
  • Тільки в деяких регіонах це повільно.Може бути, це покриття вузлів, маршрути зворотного трафіку або відсутність кешування (низький коефіцієнт попадання) → перевірте коефіцієнт попадання та стан зворотного трафіку.

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

2. Чому, незважаючи на те, що я оновив CSS/JS/зображення, користувачі все ще бачать стару версію?

Це найпоширеніша проблема в сценаріях CDN, і основною причиною зазвичай є:URL ресурсу не змінився.Система кешування продовжуватиме коректно використовувати старий кеш.

Найнадійніший принцип дій:

  • Номер версії має перевагу.Змінити URL ресурсу (наприклад, style.css?ver=xxxx або хеш назви файлу)
  • Очищення.Використовуйте очищення кешу лише як тимчасовий захід, поки ви не налаштуєте стратегію версій.

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

3. Мені потрібно кешувати HTML? Якщо не кешувати, чи не буде це безглуздо?

Це не обов'язково.

Для багатьох сайтів найбільша цінність CDN полягає в наступному:

  • Статичні ресурси (зображення/CSS/JS/шрифти) завантажуються швидше.
  • Зниження тиску на вихідній станції та підвищення її стабільності.

Зберегти HTML у кеші Дійсно, вигоди можуть бути більшими (нижчий час відгуку сервера), але ризик теж вищий: електронна комерція, членство, персоналізований вміст, а також вміст різними мовами та валютами — все це може призвести до кешування неправильного вмісту.

Надійний варіант:

  1. Спочатку зробіть статичний CDN (низький ризик, високий прибуток).
  2. Реалізуйте стратегію версій та перевірний список.
  3. Знову оцініть, чи варто кешувати HTML (починаючи з “режиму відвідувача”).

4. Чи можна підключити CDN до електронної комерційної платформи? Чи це не призведе до плутанини з кошиком покупок?

Це можна зробити, і це слід зробити (принаймні для статичних ресурсів), але необхідно уникнути кешування сторінок користувача.

  • Статичні ресурси можна кешувати.Зображення, CSS, JS
  • Сторінки користувацького режиму повинні бути обхідними.Не кешуйте HTML-сторінки, пов'язані з кошиком, оформленням замовлення та обліковим записом.
  • Якщо ви не кешуєте сторінки у форматі HTML, ризик виникнення проблем із “кошиком покупок/акаунтом” значно знизиться.

5. Як налаштувати CDN для багатомовних/багатовалютних сайтів, щоб уникнути неправильного відображення мов або цін?

Суть полягає в тому, що... Ключ кешування Це правильно?

  • Мова (шлях або піддомен)
  • Валюта (якщо це впливає на відображення ціни)
  • Чи ввійшли ви (кукі)?
  • Регіон/ставка податку (якщо сторінка змінюється в залежності від регіону)

Якщо ці параметри не потрапляють у кеш-логіку, дуже легко може статися так, що користувач мови А побачить контент мови Б або некоректні ціни.

6 Найкраще обрати інтегрований зворотний проксі (Cloudflare/EdgeOne/ESA) чи статичний Pull CDN (Bunny)?

Ви можете вибрати за критеріями “мета” та “ступінь ризику”:

  • Хочете налаштувати HTTPS + CDN + базову безпеку за один раз, а потім розширити правила/WAF?Інтеграція зворотного проксі-сервера.
  • Я хочу спочатку зробити найнадійніший перший крок (швидше завантаження статичних ресурсів), а не займатися агентом для всього сайту.Статичне витягування CDN(Наприклад, кролик)

Якщо ви сумніваєтеся, скористайтеся рекомендацією за замовчуванням:Спочатку статичний CDN. → Випробуйте стратегію версії та список перевірки → Потім вирішіть, чи використовувати проксі-сервер або кешування HTML.

7 Чи можна безкоштовну версію використовувати на офіційному вебсайті?

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

  • Чи можете ви прийняти безкоштовну пропозицію?Максимальні обмеження квот, відсутність функціональних можливостей, різні способи підтримки та можливий брак зобов'язань щодо рівня обслуговування (SLA).？
  • Якщо це неможливо, слід розглядати безкоштовну версію як пробну і згодом перейти на більш підходящий тарифний план.

8 Як мені переконатися, що CDN дійсно працює, а не просто заспокоює мене?

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

  1. Перевірте, чи статичні ресурси повертаються з CDN.(Чи змінилося джерело зображень/CSS/JS?)
  2. Подивіться, чи покращився відсоток попадань і чи зменшилася кількість відскоків.(Справжній прибуток — це коли кількість переглядів зростає, а кількість відмов зменшується).
  3. Змініть стратегію оновлення перевірки CSS/зображень один раз.(Номер версії вступає в силу, що означає, що посилання контролюється)

Якщо ви не можете виконати пункт 3, то чим більше ви оптимізуєте далі, тим більше ви будете страждати від проблеми “оновлення не працює”. Рекомендується спочатку доопрацювати стратегію версій.

9 Чому при включенні прискорення для материкової частини Китаю часто виникають затримки?

Найчастіша причина — це:Вибір регіону не відповідає умовам реєстрації.。

  • Якщо ви хочете вибрати регіон прискореної обробки, що включає материкову частину Китаю, зазвичай потрібно спочатку завершити Реєстрація в ICP; Якщо ви не зареєстровані, ви можете вибрати лише регіони, які не включають материкову частину Китаю.

10 Чому спочатку я маю встановити плагін кешування, а не підключитися до CDN?

Зазвичай рекомендований порядок такий:

  1. Рівень вихідного сервера: кеш-плагіни/базова інфраструктура хосту повинні бути стабільними (зменшення часу відгуку сервера, зниження навантаження на сервер).
  2. Рівень ресурсів: оптимізація зображень для зменшення їх розміру.
  3. Рівень доставки: CDN доставляє ресурси швидше і стабільніше.

Якщо зараз ви хочете зробити лише одну річ, але боїтеся невдачі:Спочатку завантажте статичний CDN (етап 1).Прибуток стабільний, а ризик мінімальний.