Прискорена оптимізація веб-сайту CDN

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

• рівень вихідної станції: Хостинг / PHP / Плагіни для баз даних / Плагіни кешування - прийняття рішення про TTFB та навантаження на бекенд
• рівень ресурсів: Оптимізація зображень - визначення розміру та швидкості завантаження першого великого зображення
• рівень доставки:: CDN -- Ресурси, що приймають рішення, ближчі до відвідувачів, більш стабільні результати, простіші станції-джерела

цей документ CDN Прискорення：

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

1. давайте розберемося з поняттями: що вирішує CDN, а що ні.

1.1 CDN вирішує 3 основні проблеми

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

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

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

---

1.2 3 Типи проблем, які CDN не вирішує автоматично

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

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

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

2. 30-секундний вибір: Яка форма CDN вам потрібна?

У WordPress є дві основні категорії. Якщо ви виберете “Формат”, а потім “Постачальник послуг”, ідея буде дуже зрозумілою.

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

**Особливості:** Це не тільки CDN, але і ставить DNS / SSL / Базовий захист (наприклад, DDoS/WAF) Упаковані разом. Ви отримуєте доступ до нього, і він стоїть перед вашим сайтом як проксі-сервер.

Що ти отримаєш:

• HTTPS Простіше керування сертифікатами та TLS
• Єдиний портал безпеки (базовий DDoS, контроль доступу, WAF тощо)
• Граничне кешування з механізмом правил (можна робити більш гранульовані політики кешування, обхідні політики)
• “Більше простору для розширення”: якщо ви захочете пізніше додати безпеку, обмеження швидкості та захист від ботів, це все зазвичай знаходиться в одній системі.

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

Якщо хочеш:

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

---

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

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

Що ти отримаєш:

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

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

Якщо хочеш:

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

3. як це зробити

• Рівень 1: Інтегрований тип агента (перевага надається): Cloudflare / EdgeOne / ESA
• Рівень 2: Статичне витягування CDN (твердий старт)bunny.net / Cloudways CDN тощо.

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

4.1 Хмарний спалах: Інтеграція зворотного проксі (вільний старт, екологічно зріла)

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

для кого

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

точка ризику

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

інструкції：

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

---

4.2 Tencent Cloud International EdgeOne: Інтеграція зворотного проксі

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

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

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

Опис:

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

---

4.3 Aliyun International ESA: Інтеграція зворотного проксі

• має безкоштовну версію, як Cloudflare, але зазвичай є Квота/функціональна стеля(кількість правил, кількість завдань журналювання тощо), але жодних модифікацій DNS не потрібно, лише доступ до cname.Безкоштовна версія не рекомендується для комерційних сайтів！
• Зареєструйте обліковий запис на міжнародному сайті, щоб використовувати
• Перейдіть на консоль ESA, щоб додати сайт і виберіть безкоштовний Вхід доступ за передплатою
• Якщо ви хочете автоматично переключитися на лінію материкового Китаю в материковому Китаї, вам, як правило, спочатку потрібно завершити подачу ICP; ви можете перейти на міжнародну лінію тільки тоді, коли ви не подали заявку.
• Безкоштовні більше підходять для розробки/тестування/оцінки і зазвичай не еквівалентні комерційним пакетам SLA.
• Безкоштовні пакунки часто мають обмеження на швидкість/методи підтримки (наприклад, SLA тощо).

Про лінію материкового Китаю:

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

Опис:

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

---

4.4 bunny.net: Статичне витягування CDN (запуск з низьким рівнем ризику, чітке виставлення рахунків за об'єм)

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

Підходить:

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

точка ризику

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

Чіткий принцип, що підлягає виконанню:

Номери версій мають пріоритет, очистіть кишені.

Чому це найстабільніший:

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

Наочні приклади:

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

Кролик як найкраща практика “Першого кроку CDN”

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

5. дорожня карта до верхньої лінії: просування у 3 етапи (від стабільного до сильного)

Найпростіший спосіб “зіпсувати” аплінки CDN - спробувати підняти всі можливості одночасно.

Етап 1: Тільки статичні ресурси CDN (настійно рекомендується спочатку)

цілі: Images/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
• Попередній перегляд/чернетка (попередній перегляд)
• Сторінка результатів пошуку (параметри часто змінюються, найекономніше не кешувати їх спочатку)
• POST запит на заповнення форми/надання коментаря

Кеш-ключі повинні принаймні розрізняти

• Незалежно від того, ввійшли ви в систему чи ні (вимір cookie)
• Мови (багатомовні станції)

---

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

відгуки

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

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

• Усі ключі активації кешу → Кеш подрібнений, поганий показник потрапляння
• Проігнорувати всі → Деякі сторінки, які залежать від параметрів рендерингу, можуть відображатися не так, як очікувалося

---

6.3 Членський сайт / сайт курсів / спільнота (висока частка зареєстрованих користувачів)

винести вирок: Кешування HTML слід виконувати з великою обережністю.
Безпечними практиками зазвичай є: статичне кешування CDN + кешування джерела/об'єкта; HTML кешує лише гостьовий стан.

Треба обійти

• Увійдіть/Реєструйтеся/Відновіть пароль
• Центр обслуговування, Замовлення/Підписка, Особисті дані
• Будь-які сторінки та інтерфейси, що “сильно релевантні стану користувача”

---

6.4 Станція електронної комерції (WooCommerce)

Перелік найважливіших обхідних шляхів

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

Чому електронна комерція більш схильна до нещасних випадків

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

---

6.5 Багатомовні / мультивалютні сайти

відгуки

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

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

• Мова (Шлях) /en/ /zh/ або субдомен en.）
• Входити в систему чи ні (cookie)
• Валюта/податкова ставка (якщо впливає на подання)

---

7. попередження про ризики

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

• Помилка кешування статичних ресурсів: переважно старі стилі/зображення
• Помилка кешування HTML: may string content, string shopping cart, string account - це серйозний інцидент!

Ризик 2: Оновлення не набувають чинності (найпоширеніший)

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

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

Ризик 3: Межа зобов'язань для безкоштовної/стартової версії

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

Ризик 4: Компетенції, пов'язані з материковим Китаєм, можуть бути легко витлумачені неправильно

• ЄКА: Для маршрутів у Китаї потрібен запис ICP для маршрутів у материковому Китаї
• EdgeOne: для маршрутів у Китаї потрібен запис ICP для маршрутів у материковому Китаї

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

8.1 Чи дійсно зникли статичні ресурси CDN?

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

8.2 Чи знизився тиск на станції-джерелі?

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

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

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

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

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

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

8.5 Чи збільшився відсоток помилок?

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

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

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

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

Сценарій A: Тільки ви бачите, що старий пристрій є новим, а невидимий/підмінний - новим
Пріоритетна підозра: кешування браузера

• Напрямок вирішення: випустити нові ресурси зі зміною номера версії/назви файлів

Сценарій B: Всі бачать старе (стелс/різні пристрої також старі)
Пріоритетний підозрюваний: CDN все ще працює зі старим кешем

• 99% Причина: URL-адресу ресурсу не змінено
• Пріоритетні рішення: стратегії версійності
• Кишеня: Очищення (тимчасовий засіб)

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

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

---

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

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

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

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

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

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

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

10. рекомендації

Хмарний спалах

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

Tencent Cloud International EdgeOne

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

Aliyun International ESA

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

bunny.net

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

11. рекомендації до дій

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

Поширені запитання про WordPress CDN

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 Переваги дійсно можуть бути більшими (TTFB буде нижчим), але ризики також є найбільшими: електронна комерція, членство, персоналізований контент, багатомовний/багатовалютний контент - все це може призвести до кешування неправильного контенту.

Стійкий маршрут:

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

---

4. чи може сайт електронної комерції бути на CDN і чи не зіпсує це кошик для покупок?

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

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

---

5. як багатомовний/багатовалютний сайт може зробити CDN без нанизування мов/цін?

центр Ключ кешу Чи правильно.

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

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

---

6. чи варто використовувати інтеграцію зворотного проксі (Cloudflare/EdgeOne/ESA) або статичний Pull CDN (зайчик)?

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

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

Якщо ви вагаєтесь, скористайтеся порадою за замовчуванням:Попередньо статичний CDN → Прочитайте політику версій і контрольний список перевірки → а потім вирішіть, чи потрібно переходити до кешу проксі/ХТМL.

---

7. чи можна використовувати безкоштовну версію безпосередньо на офіційному сайті?

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

• Чи влаштовує вас безкоштовна програмаОбмеження квот, відсутні функції, відмінності в підтримці та можлива відсутність зобов'язань SLA？
• Якщо ви не можете, вам слід розглядати безкоштовну версію як пробну і згодом оновити її до більш підходящого пакета

---

8. як я можу бути впевнений, що CDN дійсно працює, а не просто психологічний комфорт?

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

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

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

---

9. чому я часто застрягаю, коли вмикаю прискорення для материкового Китаю?

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

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

---

10. що спочатку встановити - плагін кешу чи CDN?

Загальний рекомендований порядок такий:

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

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