Калі мы разбіваем аптымізацыю прадукцыйнасці WordPress на тры ўзроўні:

  • Серверны слой OriginХост / 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 Змяншэнне нагрузкі на сервер-арыгінал
Пасля трапляння ў памяць краявога кэша запыты больш не будуць часта вяртацца да сервера-крыніцы, і нагрузка на прапускную здольнасць, адначасовыя злучэнні, дыскавы IO і ваганні CPU на серверы-крыніцы стане меншай.
Гэта асабліва відавочна падчас пікавых сцэнарыяў, такіх як “вялікі трафік на рэкламныя старонкі, вірусныя артыкулы і старонкі прадуктаў”.

1.1.3 Павышэнне стабільнасці (большая ўстойлівасць да валацільнасці)
Падчас перыядаў пікавых нагрузак краевыя вузлы паглынаюць значны аб'ём дублікаваных запытаў, тым самым зніжаючы верагоднасць перагрузкі сервера-арыгінала.
Вы заўважыце “больш плаўны доступ”: нават калі на арыгінальным серверы адбываецца раптоўны скачок нагрузкі, кэш на краі працягвае пастаўляць кантэнт без перапынкаў.

1.2 CDN Тры тыпы праблем, якія не вырашаюцца аўтаматычна

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

1.2.2 Сама выява занадта вялікая
CDN не можа “чароўна паменшыць” вялікую выяву 3MB.
Спачатку неабходна аптымізаваць вашыя выявы: укараніць стратэгію вызначэння памеру (пазбягайце спампоўвання занадта вялікіх выяў), выкарыстоўваць сціск, прымяняць фарматы 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Інтэграцыя рэверсіўнага праксі (бясплатны старт, сталая экасістэма)

Паскарэнне WordPress - HOSTFO

Што гэта?
Пасля падключэння дамена ён выступае як праксі перад сайтам, забяспечваючы CDN, сертыфікаты, базавую абарону і магчымасці правіл кэшавання.

Для каго гэта падыходзіць?

  • Хочаце менш клопатаў: HTTPS + CDN + базавая бяспека пад ключ
  • Для стварэння сталай экасістэмы: наступныя дапаўненні будуць уключаць WAF, абмежаванне хуткасці, правілы на краі сеткі і г.д., з вельмі плаўнай дарогай укаранення.

Пункты рызыкі

  • Абнаўленне не ўступіла ў сілу.: пасля запуску CDN ланцужок кэшавання становіцца даўжэйшым (кэш браўзера + кэш CDN + кэш зыходнага сервера), патрэбна “стратэгія версій”, каб абнаўленні былі кіраванымі (далей ёсць дрэва дыягностыкі)
  • Кэшыраванне HTML патрабуе асцярожнасціКалі HTML-код кэшуецца, старонкі электроннай камерцыі, членства або персаналізаваныя старонкі павінны строга абыходзіцца, інакш могуць узнікнуць сур'ёзныя інцыдэнты (спіс сцэнарыяў прыведзены ніжэй).

Тлумачэнне：

  • Пазіцыянаванне: комплекснае рашэнне з зваротным праксі (SSL + CDN + базавая абарона)
  • Падходзіць для: простага разгортвання з шырокімі магчымасцямі для будучага пашырэння
  • Асноўная каштоўнасць: Аб'яднаны ўваход у сэртыфікат/бяспеку/кэш
  • Рызыка: абнаўленні залежаць ад стратэгіі версіявання; кэшаванне HTML павінна быць строга абыходзіцца.

4.2 Міжнародны EdgeOne ад Tencent CloudІнтэграцыя зваротнага праксі

Паскарэнне WordPress - HOSTFO

Што гэта?
Платформа аналагічным чынам выкарыстоўвае інтэграваны падыход “паскарэнне + бяспека + сертыфікаты”, што робіць яе прыдатнай для размяшчэння вэб-сайтаў пад адзіным кіраваннем праксі-слоем.

  • Як і ў Cloudflare, ёсць бясплатная версія, але звычайна будзе Квота/функцыянальны ліміт(колькасць правілаў, колькасць задач журнала і г.д.), але не трэба змяняць DNS, дастаткова толькі падключыць cnameБясплатныя версіі не рэкамендуюцца для камерцыйных вэб-сайтаў.！
  • У той жа час, бясплатныя планы часта азначаюць SLA не гарантуе
    Яго можна выкарыстоўваць, але не варта разглядаць як “камерцыйны пакет SLA”.
  • Калі вы хочаце аўтаматычна пераключыцца на лініі сухапутнага Кітая, знаходзячыся ў Кітаі, вам, як правіла, спачатку трэба будзе выканаць наступнае:Рэгістрацыя ICP у КітаіКалі не зарэгістраваны, можна выкарыстоўваць толькі міжнародныя маршруты.

Заўвага:

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

4.3 Міжнародная карпаратыўная архітэктура бяспекі Alibaba Cloud (ESA)Інтэграцыя зваротнага праксі

Паскарэнне WordPress - HOSTFO
  • Як і ў Cloudflare, ёсць бясплатная версія, але звычайна будзе Квота/функцыянальны ліміт(колькасць правілаў, колькасць задач журнала і г.д.), але не трэба змяняць DNS, дастаткова толькі падключыць cnameБясплатныя версіі не рэкамендуюцца для камерцыйных вэб-сайтаў.！
  • Зарэгіструйце ўліковы запіс на міжнародным сайце, каб пачаць яго выкарыстоўваць.
  • Перайдзіце ў кансоль ESA, каб дадаць сайт, і выберыце бясплатную опцыю. Уваход Доступ да пакета
  • Калі вы хочаце аўтаматычна пераключацца на маршруты ў мацерыковай Кітаі ў межах самой мацерыковай Кітая, вам звычайна спачатку трэба будзе падаць заяўку ў ICP; без падачы заяўкі вы можаце выкарыстоўваць толькі міжнародныя маршруты.
  • Бясплатныя планы больш падыходзяць для распрацоўкі, тэсціравання і ацэнкі і звычайна не эквівалентныя камерцыйным пакетам SLA.
  • Бясплатныя пакеты часта маюць абмежаванні хуткасці або абмежаванні па падтрымцы (напрыклад, пагадненні аб узроўні сэрвісу і г.д.).

Адносна маршрутаў у Кітайскай Народнай Рэспубліцы:

  • Для актывацыі вузла на мацерыковай частцы Кітая звычайна неабходна задаволіць адначасова патрабаванні да падачы запісу і рэгіянальныя патрабаванні.
  • Бясплатны ўваход па змаўчанні выкарыстоўвае міжнародны маршрут. Каб выкарыстоўваць маршрут для материковай Кітая, вы павінны выканаць наступнае:Патрабаванні да падачы заявы ICP у Кітаі

Заўвага:

  • Пазіцыянаванне: інтэграцыя зваротнага праксі (паскарэнне сайта + бяспека)
  • Бясплатна: уліковыя запісы міжнароднага сайта могуць бясплатна атрымаць доступ; паскарэнне ў мацерыковай Кітаі па змаўчанні не ўключана.
  • Падходзіць для: ацэнкі/тэсціравання і лёгкага выкарыстання; або для наступных абнаўленняў пакета.
  • Рызыкі: Звярніце ўвагу на абмежаванні бясплатнай версіі (SLA/абмежаванні па нагрузцы/варыянты падтрымкі); загадзя сплануйце рэгіянальныя і рэгістрацыйныя патрабаванні.

4.4 bunny.net: Статычны Pull CDN (нізкарызыкоўны старт, празрыстая аплата па аб’ёме)

Паскарэнне WordPress - HOSTFO

Калі вы хочаце “спачатку ўзяць самы надзейны прыбытак”, такі Pull 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 лічыць новым рэсурсам → новая версія ўступае ў сілу неадкладна

bunny як найлепшая практыка для “Першага кроку CDN”

  1. Першапачаткова ахопліваць толькі статычныя рэсурсы.(Выявы/CSS/JS/шрыфты), не кэшуйце HTML адразу пасля загрузкі.
    • Перавага: сур'ёзныя інцыдэнты, такія як прагляд карыстальнікамі чужога кантэнту або звестак аб кошыку, практычна адсутнічаюць.
    • Вам таксама будзе лягчэй праверыць перавагі: статычныя рэсурсы загружаюцца хутчэй, а сервер арыгінала менш нагружаны.
  2. Эфектыўна распрацаваць стратэгію абнаўленняў
    • CSS/JS: Па магчымасці выкарыстоўвайце нумары версій або змяняйце назвы файлаў.
    • Выявы: па магчымасці пазбягайце працяглага выкарыстання аднолькавых назваў файлаў; лепш за ўсё прымаць новыя назвы файлаў або змененыя шляхі (асабліва для банэраў галоўнай старонкі і рэкламнай графікі).
  3. Пасля запуску выкарыстайце кантрольны спіс праверкі, каб пацвердзіць паспяховае ўкараненне.
    • Ці паходзяць статычныя рэсурсы з CDN
    • Ці паступова расце паказчык паспяховых адказаў? Ці становіцца прапускная здольнасць/аб'ём запытаў сервера-арыгінала больш стабільным? (Пералік для праверкі прыведзены ніжэй)

Звярніце ўвагу

Калі ваш бізнес звязаны з материковай Кітаем, або вы жадаеце забяспечыць больш хуткі доступ да вашага вэб-сайта з материковай Кітая.

І Alibaba Cloud China, і Tencent Cloud China вартыя вашай ўвагі. Калі ваш дамен ужо мае статус зарэгістраванай у ICP на тэрыторыі Кітая, пры выкарыстанні EdgeOne або ESA трафік, які паступае з Кітая, будзе аўтаматычна пераключацца на кітайскія маршруты.

“Выкарыстоўваць вузлы материковага Кітая”Звычайна ўключае падачу ICP

Для даведкі

“Аптымізацыя трансгранічнага досведу доступу да вэб-сайта”Гэта можа быць асобная магчымасць, звычайна не эквівалентная “свабоднаму доступу да вузлоў у материковай Кітаі”.”

5. План рэалізацыі маршруту: прасоўванне ў трох фазах (ад стабільнага да надзейнага)

Прычына, чаму CDN пры запуску лягчэй за ўсё “зблытаць”, у тым, што з самага пачатку хочацца ўключыць усе магчымасці на максімум.

Этап 1: толькі статычныя рэсурсы CDN (настойліва рэкамендуецца зрабіць спачатку)

МэтаВыявы/CSS/JS/шрыфты спачатку праз CDN; HTML не кэшуецца ў CDN (або пакуль без змен)

Чаму б не пачаць з гэтага, бо гэта самы стабільны падыход?

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

Распаўсюджаныя праблемы на гэтай стадыі (выпраўленне памылак будзе далей)

  • Змешаны кантэнт (старонка загружае HTTP рэсурсаў)
  • Абнаўленні статычных рэсурсаў не ўступаюць у сілу (URL не змяніўся)

Этап 2: Аднаўленне стратэгіі (Прыярытэт нумара версіі, рэзервовы варыянт выдалення/спынення дзеяння)

Гэта мяжавы рубеж паміж “CDN працуе прафесійна” і «CDN не працуе прафесійна».

Адно нязменнае правіла:

Абнаўленні, якія можна вырашыць змяненнем нумароў версій або імёнаў файлаў, не павінны залежаць ад Purge.

Чаму ланцужок кэшаў становіцца непаймельным, калі ён падаўжаецца?

  • Кэш браўзера: магчыма, у вас у кэшы захоўваюцца састарэлыя CSS/JS.
  • Кэш CDN: на краявых вузлах можа захоўвацца стары рэсурс
  • Кэшаванне сервера Origin: Плагіны кэшавання/кэшаванне сервера могуць па-ранейшаму падаваць састарэлую інфармацыю.

Калі ў вас няма стратэгіі вэрсіявання, разгортванне ператвараецца ў:
“Зрабіў змены → Абновіў → Не працавала → Вычысціў кэш → Усё роўна не працавала → Вычысціў яшчэ адзін слой кэшу”
Гэта і ёсць найбольш балючая праблема 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.）
  • Ці ўваходзіў (кукі)
  • Валюта/Падатковы стаўка (калі ўплывае на адлюстраванне)

7. Раскрыццё інфармацыі аб рызыках

Рызыка 1: Кешаванне няправільнага кантэнту (самая сур'ёзная)

  • Памылка кэшавання статычных рэсурсаў: звычайна звязаная са састарэлымі стылявымі лістамі або выявамі.
  • Памылка кэша HTML: патэнцыйныя праблемы перакрыжаванага кантэнту, перакрыжаваных кошыкаў, перакрыжаваных уліковых запісаў — Гэта з'яўляецца крытычным інцыдэнтам.

Рызыка 2: няўлічванне абнаўленняў (найбольш распаўсюджана)

Па меры падаўжэння кэш-ланцужка выпадкі, калі “змены не ўступаюць у сілу”, становяцца больш частымі:

  • Прыярытэт надаецца зменам нумароў версій/іменаў файлаў
  • Выпраўленне/Адкат пры няўдачы
  • Працэс рэлізу павінен быць рэпрадукцыйным (каб ведаць, якія URL-адрасы былі зменены падчас кожнага рэлізу).

Рызыка 3: Аб'ём абавязацельстваў для бясплатных/пачатковых версій

  • Агульныя характарыстыкі бясплатных планаў: абмежаваныя квоты, выключэнне пэўных магчымасцей, пагадненні аб узроўні абслугоўвання (SLA) і варыянты падтрымкі, якія не эквівалентныя поўным камерцыйным прапановам.

Рызыка 4: адпаведныя магчымасці материковага Кітая схільныя да непаразуменняў.

  • ESA: Для працы ў сетцы материковай Кітая рэгістрацыя ICP у Кітаі з'яўляецца абавязковай.
  • EdgeOne: Каб выкарыстоўваць маршруты ў материковай частцы Кітая, рэгістрацыя ICP у Кітаі з'яўляецца абавязковай.

8. Кантрольны спіс праверкі: Як пацвердзіць, што “ўсё сапраўды працуе” пасля запуску”

8.1 Ці сапраўды статычныя рэсурсы ідуць праз CDN?

  • Ці паходзяць выявы/CSS/JS з дамена або edge-вузла CDN
  • Ці назіраюцца якія-небудзь бачныя паказчыкі траплення ў кэш (маркеры адрозніваюцца ў залежнасці ад платформы)?

8.2 Ці зменшылася нагрузка на сервер-арыгінал?

  • Ці больш стабільны прапускная здольнасць сервера-арыгінала?
  • Ці зменшылася колькасць запытаў/злучэнняў да арыгінальнага сервера (асабліва запытаў на дублікаты рэсурсаў)?

8.3 Ці можна кантраляваць абнаўленні?

  • Змяніць CSS/JS адзін раз або замяніць выяву
  • Ці можна новую версію хутка ўкараніць шляхам “змены нумароў версій/змены назваў файлаў”?
  • Калі абнаўленні можна выконваць толькі праз Purge, гэта сведчыць пра тое, што стратэгія версіявання застаецца неадэкватнай (прыярытэт — выпраўленне стратэгіі; не разглядайце Purge як звычайную аперацыю).

8.4 Ці правільныя дынамічныя старонкі ключоў?

(Неабходна для сайтаў электроннай камерцыі/па членстве)

  • Ці правільны змест старонкі пасля ўваходу/выхаду?
  • Ці старонкі кошыка, афармлення заказу і ўліковага запісу заўсёды дакладныя?
  • Ці адбылася анамалія “розныя карыстальнікі праглядаюць аднолькавы кантэнт стану карыстальніка” (высокая рызыка)?

8.5 Ці павялічваецца паказчык памылак?

  • Час вычарпаны, памылкі 5xx, перыядычная недаступнасць
  • Гэта звычайна паказвае на: недастатковую магутнасць сервера-арыгінала, памылковыя правілы, актывацыю абмежавання прапускнасці або праблемы з зваротнай сувяззю.

9. Дыягностыка і ліквідацыя няспраўнасцей, калі абнаўленні не ўступаюць у сілу (Ператварэнне “таямніцы” ў крокі)

Спачатку вызначце, з якой катэгорыяй праблемы вы сутыкнуліся:

9.1 Статычныя рэсурсы не абнаўляліся (CSS/JS/выявы застаюцца састарэлымі)

Сцэнар А: Толькі вы бачыце старую версію; калі вы пераходзіце ў рэжым інкогніта або змяняеце прыладу, яна адлюстроўваецца як новая.
Галоўны падазраваны: кэш браўзера

  • Падыход да вырашэння: выпуск новых рэсурсаў з абноўленымі нумарамі версій/іменамі файлаў.

Сцэнар B: усе бачаць старую версію (нябачная/таксама старая на розных прыладах)
Перш за ўсё падазравайце: CDN усё яшчэ трапляе ў стары кэш

  • 99% Прычына: URL рэсурсу не змяніўся
  • Рэкамендаванае рашэнне: Стратэгія версіянавання
  • Чыстка (як часовая мера)

Сцэнар C: пасля запісу паверх выявы з такім жа імем файла старая выява працягвае адлюстроўвацца.
Гэта класічная праблема накладання кэшу браўзера і кэшу CDN

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

9.2 HTML не абнаўлены (змесціва/модулі старонкі ўсё яшчэ састарэлыя)

Сцэнар А: Бэкенд/інтэрфейс пасля ўваходу ў сістэму новы, а наведвальнікі бачаць старую версію.
Папярэдняе падазрэнне: HTML-старонка ў стане «Візітар» была кэшавана.

  • Спачатку пацвердзіце: ці павінна захоўвацца ў кэшы HTML для такой старонкі?
  • Калі патрабуецца кэшаванне: неабходна кантраляваная стратэгія абнаўлення, інакш публікацыя становіцца некіраванай.

Сцэнар B: Толькі пэўныя рэгіёны/сеткі адлюстроўваюць састарэлую кантэнт.
Асноўнае падазрэнне: станы кэша адрозніваюцца паміж краевымі вузламі

  • Падыход да вырашэння: выкарыстоўвайце стратэгіі версіравання/абнаўлення, каб мінімізаваць разыходжанні; укараняйце яўную апрацоўку памылак пры неабходнасці.

Сцэнар C: Анамалія ва ўліковым запісе/кошыку карыстальніка
Паведамленне аб высокай рызыцы: кэш можа ўтрымліваць няправільны кантэнт.

  • Неадкладна праверце, ці кэшуюцца старонкі ў карыстальніцкім рэжыме (напрыклад, кошык, афармленне заказу, старонкі ўліковага запісу і г.д.).
  • Праверце, ці не прапускае ключ кэша крытычныя варыянты, такія як “карыстальніцкія кукі-файлы/мова/валюта”.

10. Рэкамендавана

Cloudflare

  • Інтэграцыя зваротнага праксі
  • Падыходзіць для пачаткоўцаў, якія не хочуць нічога ўладкоўваць.
  • Асноўныя моманты: стратэгія версіявання вырашае пытанне абнаўленняў; кэшыраванне HTML з пункту гледжання наведвальніка.
  • Рызыка: дынамічныя старонкі павінны быць абыходжаны.

Міжнародны EdgeOne ад Tencent Cloud

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

Міжнародная карпаратыўная архітэктура бяспекі Alibaba Cloud (ESA)

  • Інтэграцыя зваротнага праксі
  • Бясплатна: Уладальнікі міжнародных уліковых запісаў сайта могуць атрымаць доступ да ўваходу бясплатна.
  • Рызыкі: бясплатны тарыф (SLA/падтрымка/абмежаванні прапускной здольнасці) і рэгіянальныя/рэгістрацыйныя патрабаванні павінны быць пацверджаны загадзя.
  • Падходзіць для: ацэнкі/тэсціравання з лёгкім доступам; або для наступных абнаўленняў пакета; або для разгляду магчымасцей вузлоў материковай Кітая і інтэграванага доступу.

bunny.net

  • Статычны Pull CDN
  • Падходзіць для: пачатку са статычнага паскарэння нізкай рызыкі
  • Ключавыя моманты: нумар версіі мае перавагу, а Purge — рэзервовы варыянт; пазбягайце перазапісу файлаў з аднолькавымі назвамі.
  • Рызыка: няправільнае ўкараненне стратэгій абнаўлення можа прывесці да частых сутыкненняў з “састарэлымі рэсурсамі”.”

11. Рэкамендацыі да дзеянняў

  1. Спачатку выберыце тып: інтэграваны зваротны праксі (Cloudflare/EdgeOne/ESA) або статычны Pull CDN (bunny)
  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, каб не блыталіся мовы/цэны?

Ключ у тым, што Ключ кэша Ці правільна гэта?

  • Мова (шлях або паддамен)
  • Валюта (калі ўплывае на адлюстраванне цаны)
  • Ці ўваходзіў (кукі)
  • Рэгіён/Падатковая стаўка (калі старонка адрозніваецца ў залежнасці ад рэгіёна)

Калі гэтыя аспекты не будуць улічаны ў логіку кэшавання, вельмі верагодна, што карыстальнік мовы А ўбачыць кантэнт мовы Б або сутыкнецца з несумяшчальнасцю цэн.

6. Што мне выбраць: інтэграваны зваротны праксі (Cloudflare/EdgeOne/ESA) ці статычны Pull CDN (bunny)?

Вы можаце выбраць на аснове вашых “мэтаў” і “талерантнасці да рызыкі”:

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

Калі вы не вызначыліся, рэкамендацыя па змаўчанні:Спачатку статычна CDN → Разгледзьце стратэгію версіравання і кантрольны спіс праверкі → Затым вырашыце, ці ўкараняць кэшаванне з дапамогай праксі-сервера/HTML-кэшаванне.

7. Ці можна выкарыстоўваць бясплатную версію непасрэдна на жывым сайце?

Яго можна выкарыстоўваць, але трэба разглядаць “бясплатна” як “пачатковае/ацэначнае/лёгкае выкарыстанне”, а не як “афіцыйнае рашэнне з камерцыйным SLA”.

  • Ці згодныя вы прыняць бясплатны план?Абмежаванні магутнасці, функцыянальныя прапускі, разнастайнасць метадаў падтрымкі і магчымая адсутнасць абавязацельстваў па SLA？
  • Калі гэта немагчыма, бясплатны сэрвіс павінен разглядацца як пробны, з наступным пераходам на больш падыходзячы пакет.

8. Як мне пацвердзіць, што CDN сапраўды працуе, а не проста дае псіхалагічнае суцяшэнне?

Пацвердзіце, выкарыстоўваючы гэтыя тры крокі (не патрабуюцца складаныя інструменты):

  1. Праверыць, ці статычныя рэсурсы вяртаюцца з CDN(Ці змянілася крыніца выяў/CSS/JS?)
  2. Праверце, ці палепшыліся паказчыкі клікабельнасці і зваротнай дастаўляльнасці.(Толькі калі паказчык трапленняў павялічваецца, а рэгенерацыя рэсурсаў змяншаецца, гэта можа лічыцца сапраўднай перавагай)
  3. Абнаўленне палітыкі праверкі CSS/выяў пры мадыфікацыі(Нумар версіі, які ўступае ў сілу, што паказвае кантраляванасць сувязі)

Калі вы не можаце рэалізаваць трэці пункт, далейшыя аптымізацыі будуць усё часцей сутыкацца з тым, што змены не ўступаюць у сілу. Рэкамендуецца надаць прыярытэт завяршэнню стратэгіі версіявання.

9. Чаму часта захрасае ўключэнне функцыі паскарэння для материковай Кітая?

Найбольш распаўсюджаныя прычыны:Абраны рэгіён не адпавядае патрабаванням для падачы.。

  • Калі вы хочаце выбраць рэгіён паскарэння, які ўключае мацерыковую Кітай, вам звычайна трэба будзе выканаць Падача заяўкі ICPНарэгістраваныя карыстальнікі могуць выбіраць толькі рэгіёны, за выключэннем мацерыковай Кітая.

10. Мне спачатку ўсталяваць убудову кэшавання ці спачатку перайсці на CDN?

Звычайна рэкамендаваны парадак такі:

  1. Узровень сервера Origin: спачатку стабілізаваліся плагіны кэшавання/інфраструктура хостынгу (зменшыўся TTFB, знізілася нагрузка на бэкэнд)
  2. Рэсурсны слой: Аптымізуйце выявы для змяншэння памеру файлаў
  3. Узровень дастаўкі: CDN дастаўляе рэсурсы хутчэй і больш стабільна

Калі вы зараз хочаце толькі адно і жадаеце пазбегнуць непрыемнасцей:Спачатку статычны CDN（этап 1）Стабільная даходнасць, мінімальны рызыка.