Галоўная старонка/Кіраўніцтва/Аптымізацыя сайта/Падрабязнасці змесціва

Калі мы разбіваем аптымізацыю прадукцыйнасці 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） Згрупуйце іх разам. Пасля падключэння ён выступае ў якасці праксі-сервера перад вашым вэб-сайтам.

Што вы атрымаеце:

  • Кіраванне сертыфікатамі і TLS у HTTPS стала прасцей
  • Адзіны ўваход для абароны бяспекі (базавы 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, сертыфікаты, базавую абарону і магчымасці правілаў кэшавання.

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

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

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

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

Тлумачэнне：

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

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

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

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

Заўвага:

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

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

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

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

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

Заўвага:

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

4.4 bunny.net: статычны Pull CDN（нізкарызыкоўны старт, празрыстая аплата па факце выкарыстання）

Калі вы хочаце “спачатку забраць найбольш стабільны прыбытак”, такі 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 (або пакуль не чапаць).

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

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

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

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

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

Гэта водападзел паміж “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.）
  • Ці ўвайшлі ў сістэму（cookie）
  • Валюта/Падатковы стаўка (калі ўплывае на адлюстраванне)

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

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

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

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

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

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

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

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

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

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

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

8.1 Ці сапраўды статычныя рэсурсы прайшлі праз CDN?

  • Ці паходзяць выявы/CSS/JS з дамена 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: Анамалія ва ўліковым запісе/кошыку карыстальніка
Паведамленне аб высокай рызыцы: кэш можа ўтрымліваць няправільны кантэнт.

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

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. Як зрабіць шматмоўны/шматвалютны сайт, каб не блыталіся мова/цэны?

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

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

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

6. Што мне выбраць: інтэграваны зваротны праксі-сервер або статычны Pull CDN?

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

  • Хочаце адразу наладзіць 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）Стабільная даходнасць, мінімальны рызыка.