Akceleracja WordPress CDN

Jeśli podzielisz optymalizację wydajności WordPress na trzy warstwy:

• warstwa stacji źródłowej: Hosting / PHP / Bazy danych / Wtyczki buforujące - wybór TTFB i ciśnienia backendu
• warstwa zasobówOptymalizacja obrazu - określanie rozmiaru i szybkości pobierania pierwszego dużego obrazu
• warstwa dostarczaniaCDN - decyduje o zasobach bliżej odwiedzającego, bardziej stabilne trafienia, strona źródłowa bardziej zrelaksowana

niniejszy dokument Akceleracja CDN.：

• Wiedza o tym, co CDN może, a czego nie może rozwiązać
• Wybierz odpowiednią dla siebie formę CDN i dostawcę (i poznaj granice bezpłatności/startera).
• Uruchomienie w kolejności niskiego ryzyka, bez awarii witryny lub incydentu z pamięcią podręczną e-commerce/członkostwa.
• Sprawdź, czy “działa” po uruchomieniu i rozwiąż problemy “dlaczego nie aktualizuje się / dlaczego zwalnia / dlaczego ciągnie zawartość”.”

1) Po pierwsze, wyjaśnijmy koncepcję: co CDN rozwiązuje, a czego nie.

1.1 CDN rozwiązuje 3 główne problemy

1.1.1 Szybsze dostarczanie zasobów statycznych
Zasoby statyczne, takie jak obrazy / CSS / JS / czcionki / ikony, są bliżej odwiedzającego, pobierają się szybciej i renderują strony bardziej spójnie.
W przypadku WordPressa, zwłaszcza motywów i zasobów wtyczek (wp-content/themes/、wp-content/plugins/), a także obrazy galerii multimediów (wp-content/uploads/) jest zwykle “większa”.

1.1.2 Zmniejszone ciśnienie na stacjach źródłowych
Po trafieniu do brzegowej pamięci podręcznej żądania nie są już tak często zwracane do źródła, a przepustowość, współbieżne połączenia, operacje wejścia-wyjścia na dysku i fluktuacje procesora u źródła są mniejsze.
Jest to szczególnie prawdziwe w przypadku scenariuszy falowych, takich jak “strony wydarzeń, artykuły i strony produktów, które są często odwiedzane”.

1.1.3 Zwiększona stabilność (większa odporność na wahania)
Gdy ruch jest gwałtowny, węzły brzegowe absorbują dużą liczbę zduplikowanych żądań, a stacja źródłowa jest znacznie mniej narażona na awarię.
Zobaczysz “płynniejszy dostęp”: brzegowa pamięć podręczna kontynuuje wysyłanie nawet wtedy, gdy witryna źródłowa jest chwilowo obciążona.

---

1.2 3 rodzaje problemów, których sieci CDN nie rozwiązują automatycznie

1.2.1 Sama stacja wolnego źródła
Wolne bazy danych, wolna logika wtyczek, wolne obliczenia PHP - to są problemy na poziomie witryny źródłowej.
CDN może sprawić, że zasoby statyczne będą szybsze, ale jeśli nawet strona główna HTML jest generowana bardzo wolno, użytkownik nadal będzie czuł się “otwarty na wolno”. Tym razem priorytet wraca do: hostingu / buforowania wtyczek / optymalizacji bazy danych.

1.2.2 Sam obraz jest zbyt duży
Sieci CDN nie mogą “zaczarować” obrazu o rozmiarze 3 MB do mniejszego rozmiaru.
W pierwszej kolejności należy wykonać optymalizację obrazu: strategia rozmiaru (nie pobieraj zbyt dużych obrazów), kompresja, WebP/AVIF, strategia leniwego ładowania itp.

1.2..3 Powolne skrypty innych firm
Reklamy, statystyki, obsługa klienta, komponenty mediów społecznościowych itp. pochodzą z domen stron trzecich.
CDN zazwyczaj nie może pomóc im być “szybszymi”, można sobie z tym poradzić jedynie poprzez zmniejszenie/opóźnienie obciążenia, zmianę dostawcy lub optymalizację polityki skryptów.

2. 30 sekund na wybór: Jakiego formatu CDN potrzebujesz?

W przypadku WordPressa istnieją dwie główne kategorie. Jeśli wybierzesz “Format”, a następnie “Usługodawca”, pomysł będzie bardzo jasny.

2.1 Zintegrowany wariant “odwrotnego proxy” (wygodniejszy, odpowiedni dla większości witryn)

*Cechy charakterystyczne:** Jest to nie tylko sieć dostarczania treści (CDN), ale także... DNS / SSL / podstawowa ochrona bezpieczeństwa (np. DDoS/WAF) Spakowane razem. Uzyskujesz do niego dostęp, a on stoi przed Twoją witryną jako proxy.

Co otrzymasz:

• Proste zarządzanie certyfikatami HTTPS i TLS
• Ujednolicony portal bezpieczeństwa (podstawowy DDoS, kontrola dostępu, WAF itp.)
• Buforowanie brzegowe z silnikiem reguł (może tworzyć bardziej szczegółowe zasady buforowania, omijać zasady)
• “Więcej miejsca na rozbudowę”: jeśli chcesz później dodać zabezpieczenia, ograniczenia prędkości i ochronę przed botami, zwykle wszystko to znajduje się w tym samym systemie.

*Przedstawiciele:** Cloudflare / Tencent Cloud International EdgeOne / Alibaba Cloud International ESA

Jeśli chcesz:

• Chcesz HTTPS + CDN + podstawowe zabezpieczenia zrób wszystko za jednym razem
• Czy chciałbyś ujednolicić rozpoznawanie nazw domen/warstwę proxy w ramach jednej platformy?
• Jesteś bardziej zainteresowany “ogólnym doświadczeniem i późniejszą rozbudową” i nie chcesz dzielić DNS, certyfikatów, CDN, bezpieczeństwa na wiele zestawów.

---

2.2 Czysty “Static Pull CDN” (start niskiego ryzyka, głównie przyspieszanie obrazów/CSS/JS)

*Cechy charakterystyczne**: Zasoby statyczne są umieszczane wyłącznie w pamięci podręcznej na krawędzi sieci CDN; za strony HTML nadal odpowiada serwer źródłowy (wraz z wtyczką do pamięci podręcznej serwera źródłowego).

Co otrzymasz:

• Bardzo niskie ryzyko biznesowe: brak “ciągnięcia treści/kart”, jeśli nie dotykasz HTML.”
• Modelowanie kosztów jest bardziej intuicyjne: zwykle rozliczane według ruchu/odbioru/regionu.
• Czystsza struktura: bardziej przypomina “statyczną usługę dystrybucji zasobów”.”

*Przedstawiciel:** bunny.net (model rozliczeniowy według ilości danych jest jasny)

Jeśli chcesz:

• W pierwszej kolejności należy wykonać “najpewniejszy krok” - statyczną akcelerację zasobów.
• Chcesz szybko uzyskać przychody przed podjęciem decyzji o przejściu na buforowanie typu proxy/pełnej witryny
• Koszt powinien być zbliżony do “płać za to, czego używasz”.”

3. jak to zrobić

• Poziom 1: Typ agenta zintegrowanego (preferowany)Cloudflare / EdgeOne / ESA
• Warstwa 2: Static Pull CDN (solidny początek): bunny.net / Cloudways CDN itp.

4. rekomendowani dostawcy usług

4.1 CloudflareIntegracja reverse proxy (darmowy start, dojrzały ekologicznie)

Co to jest?
Podłączasz nazwę domeny, a ona staje przed witryną jako proxy, zapewniając CDN, certyfikaty, podstawową ochronę i możliwości reguł buforowania.

Dla kogo jest przeznaczony?

• Chcesz zaoszczędzić: HTTPS + CDN + podstawowe zabezpieczenia w jednym!
• Chcemy dojrzałego ekosystemu: kontynuacja, aby dodać WAF, ograniczenie prędkości, reguły brzegowe itp.

Punkty ryzyka

• Aktualizacje nie wchodzą w życieDłuższe buforowanie linków (pamięć podręczna przeglądarki + pamięć podręczna CDN + pamięć podręczna źródła) po uruchomieniu CDN, potrzeba “polityki wersjonowania”, aby kontrolować aktualizacje (drzewo rozwiązywania problemów później)
• Bądź ostrożny z buforowaniem HTML: w przypadku buforowania HTML, strony e-commerce/członkowskie/personalizacyjne muszą być ściśle omijane lub są podatne na poważne wypadki (lista scenariuszy poniżej).

Objaśnienie：

• Pozycjonowanie: Integracja Reverse Proxy (SSL + CDN + podstawowa ochrona)
• Nadaje się do: oszczędzania on-line, dużej przestrzeni do późniejszej rozbudowy
• Wartość podstawowa: ujednolicony portal certyfikatów/bezpieczeństwa/pamięci podręcznej
• Ryzyko: Aktualizacje opierają się na zasadach wersjonowania; buforowanie HTML musi być ściśle omijane.

---

4.2 Tencent Cloud International EdgeOneIntegracja z odwrotnym proxy

Co to jest?
Formularz jest również platformą typu “wszystko w jednym”, obejmującą "przyspieszenie + bezpieczeństwo + certyfikaty", która jest odpowiednia do umieszczania witryn w ujednoliconym zarządzaniu warstwą agenta.

• ma darmową wersję, taką jak Cloudflare, ale zazwyczaj jest Pułap kwotowy/funkcjonalny(liczba reguł, liczba zadań rejestrowania itp.), ale nie są wymagane żadne zmiany DNS, tylko dostęp cname doDarmowa wersja nie jest zalecana dla komercyjnych stron internetowych！
• Tymczasem darmowe plany często oznaczają Umowa SLA nie jest gwarantowana
  Działa, ale nie jako “komercyjny pakiet SLA”.

• Jeśli chcesz automatycznie przełączać się między liniami Chin kontynentalnych w Chinach kontynentalnych, zwykle będziesz musiał najpierw ukończyćRekord ICP w ChinachTylko trasy międzynarodowe mogą być używane, gdy nie są zgłoszone.

Opis:

• Pozycjonowanie: Integracja odwrotnego proxy (przyspieszenie + bezpieczeństwo + certyfikaty)
• Idealny dla: tych, którzy chcą zintegrowanego dostępu i rozważają pojemność węzła w Chinach kontynentalnych
• Bezpłatne: istnieją bezpłatne plany / bezpłatne wersje, ale kwoty są ograniczone, a umowy SLA zwykle nie są gwarantowane.
• Ryzyko: reguły/logi/przydziały subdomen powinny być zaplanowane z wyprzedzeniem; buforowanie HTML powinno być równie ostrożne.

---

4.3 Aliyun International ESAIntegracja z odwrotnym proxy

• ma darmową wersję, taką jak Cloudflare, ale zazwyczaj jest Pułap kwotowy/funkcjonalny(liczba reguł, liczba zadań rejestrowania itp.), ale nie są wymagane żadne zmiany DNS, tylko dostęp cname doDarmowa wersja nie jest zalecana dla komercyjnych stron internetowych！
• Zarejestruj konto w witrynie międzynarodowej, aby z niego korzystać
• Przejdź do konsoli ESA, aby dodać witrynę i wybierz opcję bezpłatną Entrance dostęp do subskrypcji
• Jeśli chcesz automatycznie przełączyć się na linię Chin kontynentalnych w Chinach kontynentalnych, zwykle musisz najpierw wypełnić wniosek ICP; możesz przejść na linię międzynarodową tylko wtedy, gdy nie złożyłeś wniosku.
• Darmowy jest bardziej odpowiedni do rozwoju/testowania/oceny i zwykle nie jest odpowiednikiem komercyjnych pakietów SLA.
• Bezpłatne pakiety często mają ograniczenia prędkości/ograniczenia metod wsparcia (np. umowy SLA itp.).

Informacje o linii do Chin kontynentalnych:

• Aby włączyć węzły w Chinach kontynentalnych, zwykle trzeba spełnić warunki zgłoszenia i warunki regionalne
• Bezpłatne wejście Domyślna trasa międzynarodowa, chęć skorzystania z trasy Chiny kontynentalne musi zostać zakończona.Wymagania dotyczące dokumentacji ICP w Chinach

Opis:

• Pozycjonowanie: integracja reverse proxy (przyspieszenie witryny + bezpieczeństwo)
• Bezpłatnie: dostępne międzynarodowe konto stacji Wejście bezpłatny dostęp; domyślnie nie obejmuje przyspieszenia w Chinach kontynentalnych.
• Idealny do: ewaluacji/testowania z lekkim użyciem; lub kolejnego pakietu aktualizacji
• Ryzyko: wolne granice, którym należy się przyjrzeć (umowy SLA/limity prędkości/metody wsparcia); strefy i zgłoszenia, które należy zaplanować z wyprzedzeniem.

---

4.4 \nbunny.netStatic Pull CDN (start o niskim ryzyku, przejrzyste rozliczenia za wolumen)

Jeśli chcesz “najpierw uzyskać najbardziej stabilne przychody”, Pull CDN, taki jak bunny, jest dobrym rozwiązaniem:
To bardziej jak “usługa dostarczania zasobów”: dajesz jej statyczne zasoby do dostarczenia, koszt jest zwykle związany z ruchem / żądaniami / regionem, a model jest jasny i kontrolowany.

Odpowiednie dla:

• zrobić coś jako pierwszy Obrazy / CSS / JS / Czcionki Statyczne przyspieszenie
• Chcesz najpierw uzyskać “stabilny dochód o niskim ryzyku” i nie spieszysz się z przekazaniem całej witryny platformie typu proxy (DNS/SSL/WAF all-in-one).
• Chcesz, aby model kosztów był bliższy “płać za to, czego używasz”, zamiast od razu wchodzić w bardziej złożony pakiet.

Punkty ryzyka

Statyczny zasób “aktualizacja nie działa” prawie zawsze nie jest błędem CDNJest to raczej normalne zachowanie systemu buforowania:
Podczas aktualizacji CSS/JS/obrazów w backendzie, ale plikAdres URL zasobu pozostaje niezmieniony.(ten sam adres / nazwa pliku / ścieżka), zarówno CDN, jak i przeglądarka będą prawdopodobnie nadal trafiać do starej pamięci podręcznej, a Ty zobaczysz “dlaczego nie jest aktualizowany”.

Jasna, możliwa do wyegzekwowania zasada:

Numery wersji mają pierwszeństwo, kieszenie Purge.

Dlaczego jest to najbardziej stabilne rozwiązanie:

• Zmiany numeru wersji/nazwy pliku → zmiana adresu URL → CDN buforuje jako nowy zasób → nowa wersja wchodzi w życie niemal natychmiast
• Funkcja **Purge (czyszczenie pamięci podręcznej)** wymaga ręcznego uruchomienia i może powodować problemy z dokładnością oraz opóźnienia w rozpowszechnianiu danych w węzłach. Częste uruchamianie tej funkcji skutkuje spadkiem współczynnika trafień, większą liczbą żądań do źródła danych oraz większymi wahaniami.

Łatwe do zobaczenia przykłady:

• style.css Zawartość uległa zmianie, ale adres URL nadal jest następujący style.css → CDN nadal udostępnia stare pamięci podręczne (rozsądnie)
• Adres URL staje się style.css?ver=20260103 或 style.abc123.css → CDN uważa, że jest to nowy zasób → nowa wersja wchodzi w życie natychmiast

Najlepsze praktyki dla Bunny jako pierwszego kroku CDN

1. W pierwszej kolejności uwzględnij tylko zasoby statyczne(obrazy/CSS/JS/czcionki), nie buforuj HTML od razu!
   • Korzyść: Nie ma prawie żadnych poważnych incydentów, takich jak “użytkownik widzi czyjąś zawartość/numer seryjny koszyka”.
   • Bardziej prawdopodobne jest również sprawdzenie korzyści: szybsze zasoby statyczne, lżejsze witryny źródłowe
2. Właściwa strategia aktualizacji
   • CSS/JS: spróbuj użyć zmiany numeru wersji/nazwy pliku
   • Obrazy: staraj się unikać długotrwałego “pokrycia tej samej nazwy”, bardziej zalecane nowe nazwy plików / zmiany ścieżek (zwłaszcza baner strony głównej, mapa wydarzeń).
3. Po uruchomieniu potwierdź trafienie za pomocą listy kontrolnej walidacji.
   • Czy zasób statyczny pochodzi z sieci CDN
   • Czy współczynnik trafień stopniowo wzrasta, a przepustowość/żądania źródła są płynniejsze (lista weryfikacji poniżej)?

5. mapa drogowa do górnej linii: postęp w 3 fazach (od stabilnej do silnej)

Najłatwiejszym sposobem na “zepsucie” uruchomienia CDN jest próba wykorzystania całej pojemności na raz.

Etap 1: Tylko zasoby statyczne CDN (wysoce zalecane w pierwszej kolejności)

CelObrazy/CSS/JS/czcionki trafiają najpierw do CDN; HTML nie znajduje się w pamięci podręcznej CDN (lub na razie tam pozostaje).

Dlaczego jest to najbezpieczniejsza rzecz do zrobienia w pierwszej kolejności?

• Minimalne ryzyko: błędne buforowanie zasobów statycznych, aż do “styl/obraz nie został zaktualizowany”, możliwe do opanowania.
• Nie wpłynie na stan logowania, procesy e-commerce, poprawność informacji o koncie
• Wyraźnie widać korzyści: szybsze pobieranie zasobów statycznych i płynniejsze działanie witryn źródłowych!

Najczęstsze problemy na tym etapie (drzewo rozwiązywania problemów zostanie podane później)

• Zawartość mieszana (strona HTTPS załadowana zasobami HTTP)
• Aktualizacje zasobów statycznych nie wchodzą w życie (adresy URL nie ulegają zmianie).

---

Etap 2: Strategia odświeżania (najpierw numer wersji, kieszenie oczyszczania/awarii)

To jest przełom “CDN zrobiony profesjonalnie lub nie”.

Twarda zasada:

Nie polegaj na Purge w przypadku aktualizacji, które można rozwiązać za pomocą zmian numeru wersji / nazwy pliku.

Dlaczego linki do pamięci podręcznej stają się metafizyczne, gdy stają się dłuższe:

• Buforowanie przeglądarki: stare CSS/JS mogą być buforowane lokalnie.
• Buforowanie CDN: Węzły brzegowe mogą buforować stare zasoby.
• Buforowanie witryny źródłowej: Wtyczki pamięci podręcznej / pamięci podręczne serwera mogą nadal wyświetlać starą zawartość.

Jeśli nie masz strategii wersjonowania, wydanie staje się:
“Zmieniono coś → Odśwież → Nie działa → Wyczyść pamięć podręczną ponownie → Nie działa ponownie → Wyczyść inny poziom pamięci podręcznej”
Jest to największa bolączka wielu osób korzystających z sieci CDN.

---

Etap 3 (zaawansowany): buforować lub nie buforować HTML (wysoka wydajność, ale najwyższe ryzyko)

Buforowanie HTML (full-site caching/edge caching) znacznie zmniejsza TTFB, ale jest również obszarem wysokiego ryzyka w scenariuszach WordPress.

Nie buforuj HTML, jeśli nie masz pewności. Najpierw statyczny CDN + wtyczka buforowania źródła.

Jeśli chcesz buforować HTML, obowiązują dwie zasady:

1. Zaczyna się tylko od “stanu odwiedzającego”.Cache'owanie tylko niezalogowanych stron odwiedzających
2. Najpierw napisz listę obejśćNa pierwszym miejscu jest poprawność, potem hity

6. lista zasad scenariusza: co należy zrobić w przypadku różnych typów miejsc bez incydentów

6.1 Witryny z treścią / blogi (oparte na artykułach, wielu odwiedzających)

Polecam.

• Zasoby statyczne: w pełni buforowane
• HTML: rozważ buforowanie “strony niezalogowanego użytkownika”

Często konieczne jest ominięcie

• Backend i logowanie:/wp-admin/*、/wp-login.php
• Podgląd/draft (zapowiedź)
• Strona wyników wyszukiwania (parametry często się zmieniają, najbardziej opłaca się ich nie buforować)
• Żądanie POST przesłania formularza/komentarza

Klucze pamięci podręcznej powinny przynajmniej rozróżniać

• Czy użytkownik jest zalogowany (wymiar pliku cookie)
• Języki (stacje wielojęzyczne)

---

6.2 Strona korporacyjna / marketingowa strona docelowa (formularze, mnóstwo działań)

Polecam.

• Zasoby statyczne: w pełni buforowane
• HTML: publiczne strony docelowe mogą być buforowane (stan gościa), ale należy zachować ostrożność w przypadku stron wyników formularzy.

Najłatwiejsza pułapka: śledzenie parametrów prowadzące do fragmentacji pamięci podręcznej
Strony docelowe są powszechne utm_* Parametry:

• Wszystkie klucze pamięci podręcznej Engage → Pamięć podręczna zniszczona, niski współczynnik trafień
• Ignoruj wszystkie → Kilka stron zależnych od renderowania parametrów może nie działać zgodnie z oczekiwaniami.

---

6.3 Strona członkowska / strona kursu / społeczność (wysoki udział stanów zalogowania)

KonkluzjaBuforowanie HTML powinno być wykonywane z dużą ostrożnością.
Bezpiecznym rozwiązaniem jest zazwyczaj: statyczny CDN + buforowanie źródła/obiektu; HTML buforuje tylko stan gościa.

Musi ominąć

• Logowanie/Rejestracja/Odzyskanie hasła
• Centrum kont, zamówienia/subskrypcje, dane osobowe
• Wszelkie strony i interfejsy “silnie związane ze stanem użytkownika”

---

6.4 Stacja e-commerce (WooCommerce)

Lista najważniejszych obwodnic

• Koszyk, kasa, strona konta
• Strony związane z potwierdzeniem zamówienia i wywołaniami zwrotnymi płatności
• Logowanie/rejestracja, kupony/punkty i inne wejścia związane ze stanem użytkownika

Dlaczego handel elektroniczny jest bardziej podatny na wypadki

• Gdy użytkownik ma już koszyk, sesję i stan logowania, strona jest wysoce spersonalizowana
• Typowymi konsekwencjami buforowania HTML, które nie jest omijane/rozróżniane, są: niedopasowanie koszyka zakupów, ciągi kont i anomalie w wyświetlaniu cen.
  Poprawność ma pierwszeństwo, nie poświęcaj poprawności dla hitów.

---

6.5 Witryny wielojęzyczne / wielowalutowe

Polecam.

• Zasoby statyczne: w pełni buforowane
• HTML: stany gościa mogą być buforowane, ale klucze pamięci podręcznej muszą wyraźnie rozróżniać warianty językowe/walutowe.

Należy uwzględnić klucz pamięci podręcznej

• Język (ścieżka) /en/ /zh/ lub subdomena en.）
• Czy użytkownik jest zalogowany (plik cookie)
• Waluta/stawka podatku (jeśli wpływa na prezentację)

---

7. ostrzeżenia o ryzyku

Ryzyko 1: Buforowanie niewłaściwej zawartości (najpoważniejsze)

• Błąd buforowania zasobów statycznych: głównie stare style/obrazy
• Błąd buforowania HTML: may string content, string shopping cart, string account - to poważny incydent!

Ryzyko 2: Aktualizacje nie wchodzą w życie (najczęstsze)

W miarę wydłużania się łącza pamięci podręcznej, “zmiany nie wchodzą w życie” będą coraz częstsze:

• Zmiany numeru wersji/nazwy pliku mają pierwszeństwo
• Oczyszczanie / nieudane pedałowanie
• Proces publikacji powinien być powtarzalny (wiedzieć, jakie adresy URL zostały zmienione dla każdej publikacji).

Ryzyko 3: Granica zaangażowania dla wersji darmowej / startowej

• Wspólne cechy bezpłatnych programów: ograniczone limity, wyłączenie niektórych możliwości, podejście oparte na umowach SLA/wsparcia nie odpowiadające pełnemu wykorzystaniu komercyjnemu.

Ryzyko 4: Kompetencje związane z Chinami kontynentalnymi są łatwo błędnie interpretowane

• ESA: chiński rekord ICP wymagany dla tras w Chinach kontynentalnych
• EdgeOne: Zgłoszenie ICP w Chinach wymagane dla tras w Chinach kontynentalnych

8 Lista kontrolna walidacji: jak potwierdzić, że “naprawdę działa” po uruchomieniu?”

8.1 Czy zasoby statyczne faktycznie przeszły na CDN?

• Obraz/CSS/JS z domeny CDN/węzła brzegowego
• Czy widać wyraźne oznaki trafień z pamięci podręcznej (oznaki różnią się w zależności od platformy).

8.2 Czy ciśnienie w stacji źródłowej spadło?

• Czy przepustowość stacji źródłowej jest płynniejsza?
• Czy spadła liczba żądań/połączeń z witryny źródłowej (zwłaszcza żądań zduplikowanych zasobów)?

8.3 Czy aktualizacjami można zarządzać?

• Zmień CSS/JS raz lub zastąp obraz.
• Czy nowa wersja może być przyspieszona przez “zmianę numeru wersji/zmianę nazwy pliku”.
• Jeśli możesz aktualizować tylko przez Purge, nie masz dobrej strategii wersjonowania (nadaj priorytet łataniu strategii, nie rób z Purge codziennej rutyny).

8.4 Czy strony z kluczami dynamicznymi są poprawne?

(E-commerce / strona członkowska jest koniecznością)

• Zawartość strony po zalogowaniu/wylogowaniu jest poprawna
• Strony związane z koszykiem/kasą/kontem są zawsze poprawne.
• Każdy wyjątek “różni użytkownicy widzą tę samą zawartość stanu użytkownika” (wysokie ryzyko).

8.5 Czy poziom błędów wzrósł?

• Limit czasu powrotu do źródła, 5xx, przerywany brak otwarcia
• Zazwyczaj oznaczają one: niewystarczający nośnik w źródle, nieprawidłowe reguły, wyzwalacze ograniczeń prędkości lub problemy z łączem z powrotem do źródła

9. aktualizacja drzewa niefunkcjonalności (przekształcenie “metafizyki” w kroki)

Zacznij od określenia rodzaju problemu:

9.1 Niezaktualizowane zasoby statyczne (CSS/JS/obrazy wciąż stare)

Scenariusz A: Tylko ty widzisz stare, ukryte/zamienione urządzenie jest nowe.
Podejrzenie priorytetu: buforowanie przeglądarki

• Kierunek rozwiązania: wydanie nowych zasobów ze zmianami numeru wersji/nazwy pliku

Scenariusz B: Wszyscy widzą stare (ukryte/różne urządzenia również stare)
Wątpliwości co do priorytetu: sieci CDN wciąż trafiają do starych pamięci podręcznych

• 99% Przyczyna: Adres URL zasobu nie został zmieniony.
• Rozwiązania priorytetowe: strategie wersjonowania
• Kieszeń: Oczyszczenie (środki tymczasowe)

Scenariusz C: Stary obraz jest nadal wyświetlany po nadpisaniu obrazu o tej samej nazwie.
Jest to klasyczny problem pamięci podręcznej przeglądarki + nakładki pamięci podręcznej CDN

• Praktyczna rada: staraj się unikać długotrwałego “nadpisywania tej samej nazwy”, używaj nowych nazw plików/ścieżek lub numerów wersji.

---

9.2 HTML nie jest aktualizowany (zawartość strony/moduły są nadal stare)

Scenariusz A: backend/login jest nowy, odwiedzający widzą stary
Podejrzenie priorytetu: HTML gościa jest buforowany

• Po pierwsze: czy te strony powinny buforować HTML?
• Jeśli powinien być buforowany: wymaga kontrolowanej strategii odświeżania, w przeciwnym razie zwolnienie jest niekontrolowane.

Scenariusz B: Tylko niektóre regiony/niektóre sieci przekazują stare treści.
Wątpliwość co do priorytetu: różne węzły krawędzi mają różne stany pamięci podręcznej

• Kierunek rozwiązania: zbieżne różnice ze strategią wersjonowania/odświeżania; w razie potrzeby wyraźniejsze unieważnianie

Scenariusz C: Nieprawidłowości w zalogowanych użytkownikach/wózkach sklepowych
Znak wysokiego ryzyka: może buforować niewłaściwą zawartość

• Natychmiastowe sprawdzenie, czy strony stanu użytkownika (koszyk/kasa/konto itp.) są buforowane.
• Sprawdź, czy Cache Key ignoruje warianty kluczy, takie jak “userland cookie/language/currency”.

10. Zalecenia

Cloudflare

• Integracja z odwrotnym proxy
• Nadaje się do: oszczędzania na starcie
• Koncentracja: polityka wersjonowania w celu uwzględnienia aktualizacji; buforowanie HTML ze stanu gościa
• Ryzyko: Dynamiczne strony muszą być omijane

Tencent Cloud International EdgeOne

• Integracja z odwrotnym proxy
• Odpowiednie: uwzględnienie pojemności węzłów w Chinach kontynentalnych i zintegrowanego dostępu
• Bezpłatne: istnieją bezpłatne plany / bezpłatne wersje, ale granice kwot i zobowiązań muszą być wyraźnie widoczne.
• Ryzyko: należy zaplanować limity reguł/logów/subdomen; buforowanie HTML z zachowaniem ostrożności.

Aliyun International ESA

• Integracja z odwrotnym proxy
• Bezpłatnie: dostępne konta międzynarodowe Wejście Free Access
• Ryzyko: Wolne granice (SLA/obsługa/limit prędkości) i strefy/warunki rejestracji zostaną potwierdzone z wyprzedzeniem.
• Nadaje się do: oceny / testowania i lekkiego dostępu; lub późniejszej aktualizacji pakietu lub rozważenia pojemności węzła w Chinach kontynentalnych i zintegrowanego dostępu

\nbunny.net

• Static Pull CDN
• Odpowiednie: najpierw przyspieszenie statyczne niskiego ryzyka
• Skup się: najpierw numer wersji, Purge undercover; unikaj nadpisywania tej samej nazwy
• Ryzyko: Częste spotkania ze “starymi zasobami”, jeśli strategia aktualizacji nie zostanie wykonana prawidłowo.”

11 Zalecenia dotyczące działań

1. Najpierw wybierz format: Integracja z odwrotnym proxy (Cloudflare/EdgeOne/ESA) lub Static Pull CDN (bunny).
2. Przejdź na żywo przez scenę:Najpierw statyczne → następnie polityka wersjonowania → na koniec rozważ buforowanie HTML
3. Sprawdzenie za pomocą listy kontrolnej walidacji po uruchomieniu: trafienie/powrót do źródła/aktualizacja/dynamiczne obejście/częstotliwość błędów.
4. Chcesz być szybszy: wróć do “Cache Plugin”, “Image Optimisation” i ponownie skompresuj źródło i warstwy zasobów!

Często zadawane pytania dotyczące WordPress CDN

1) Dlaczego po użyciu CDN nadal działa wolno?

Najczęstszym powodem nie jest to, że sieci CDN nie działają, ale to, że wąskie gardło nie znajduje się w “warstwie dostarczania”.

Można je oceniać w tej kolejności:

• TTFB jest wciąż na wysokim poziomie.Wyjaśnienie powolnego generowania HTML ze źródła (baza danych/wtyczka/konfiguracja wtyczki pamięci podręcznej/wydajność hostingu) → powrót do optymalizacji na poziomie źródła
• Pierwszy duży obraz jest bardzo powolny: wskazuje nieprawidłową objętość, rozmiar lub format obrazu → najpierw wykonaj optymalizację obrazu (kompresja, WebP/AVIF, strategia rozmiaru)
• Skrypty innych firm spowalniają działanie: reklamy/statystyki/skrypty obsługi klienta są powszechne → CDN zazwyczaj nie mogą pomóc, muszą zmniejszyć lub opóźnić ładowanie
• Tylko niektóre obszary są wolneMoże to być nadpisanie węzła, linia powrotu lub brak pamięci podręcznej (niski współczynnik trafień) → sprawdź współczynnik trafień i zwroty

CDN jest odpowiedzialny za szybsze przesyłanie “zoptymalizowanych zasobów”; powolne strony źródłowe, duże obrazy i powolne skrypty powinny być obsługiwane osobno.

---

2) Dlaczego użytkownicy wciąż widzą starą wersję, mimo że zaktualizowałem CSS/JS/obrazy?

Jest to najczęstszy problem w scenariuszach CDN, a głównym powodem jest zazwyczaj:Adres URL zasobu pozostaje niezmieniony., system buforowania będzie w rozsądny sposób nadal trafiał do starej pamięci podręcznej.

Zasada najbardziej stabilnego leczenia:

• numer wersji priorytetNiech zmieni się adres URL zasobu (np. style.css?ver=xxxx lub hash nazwy pliku)
• Ubezpieczenie na wypadek niewypłacalnościCzyszczenie pamięci podręcznej jako rozwiązanie tymczasowe, gdy nie masz wdrożonych zasad wersjonowania.

Jeśli często zastępujesz baner strony głównej / obraz kampanii, zaleca się unikanie “nadpisywania tej samej nazwy”, preferując użycie nowej nazwy pliku / nowej ścieżki (bardziej kontrolowanej).

---

3) Czy muszę buforować HTML? Czy nie ma sensu go nie buforować?

Niekoniecznie potrzebne.

Dla wielu witryn największa wartość CDN wynika z:

• Szybciej dla zasobów statycznych (obrazy/CSS/JS/czcionki)
• Redukcja ciśnienia w stacji źródłowej i poprawa stabilności

Buforowanie kodu HTML Korzyści mogą być rzeczywiście większe (TTFB byłoby niższe), ale ryzyko jest również największe: e-commerce, członkostwo, spersonalizowana zawartość, wielojęzyczność/wielowalutowość - wszystkie są podatne na buforowanie niewłaściwej zawartości.

Stała trasa:

1. Statyczna sieć CDN jako pierwsza (niskie ryzyko, wysoki zysk)
2. Przeanalizuj zasady tworzenia wersji i listę kontrolną walidacji
3. Ponowna ocena, czy buforować HTML (zaczynając od “stanu gościa”)

---

4) Czy witryna e-commerce może znajdować się w sieci CDN i czy nie zakłóci to działania koszyka?

Może być włączony i powinien być (przynajmniej dla zasobów statycznych), ale unikaj buforowania stron userland.

• Zasoby statyczne mogą być buforowaneobrazy, CSS, JS
• Strona userland musi omijaćNie buforuj stron HTML związanych z koszykiem, kasą i kontem.
• Tak długo, jak nie buforujesz HTML tych stron, ryzyko “przesłuchu” jest znacznie zmniejszone!

---

5) Jak zrobić CDN dla witryn wielojęzycznych / wielowalutowych, aby język / cena nie były wypaczone?

centrum Klucz pamięci podręcznej Czy to prawda?

• Język (ścieżka lub subdomena)
• Waluta (jeśli ma wpływ na wyświetlaną cenę)
• Czy użytkownik jest zalogowany (plik cookie)
• Region/stawka podatku (jeśli strona podlega zmianom w zależności od regionu)

Jeśli te wymiary nie zostaną uwzględnione w logice buforowania, łatwo jest uzyskać: użytkownicy języka A widzą treści w języku B lub niespójne ceny.

---

6) Czy powinienem wybrać integrację reverse proxy (Cloudflare/EdgeOne/ESA) czy statyczny Pull CDN (bunny)?

Możesz wybrać według “Celu” i “Preferencji ryzyka”:

• Chcę zadbać o HTTPS + CDN + podstawowe zabezpieczenia, a następnie rozszerzyć reguły/WAF:Integracja z odwrotnym proxy
• Chcesz wykonać pierwszy krok najbardziej stabilnego pierwszego kroku (zasoby statyczne są szybsze) i nie chcesz przenosić całego agenta:Static Pull CDN(np. króliczek)

Jeśli się wahasz, domyślna rada:Najpierw statyczny CDN → Przejdź przez politykę wersjonowania i listę kontrolną walidacji → następnie zdecyduj, czy przejść do serwera proxy / pamięci podręcznej HTML.

---

7) Czy darmowa wersja może być używana bezpośrednio na oficjalnej stronie?

Można z niego korzystać, ale należy myśleć o “darmowym” jako o “starterze/ewaluacji/lekkim użyciu”, a nie jako o “formalnym programie z komercyjnymi umowami SLA”.

• Czy odpowiada Ci darmowy programLimity kwotowe, brakujące funkcje, różnice w zakresie wsparcia i możliwy brak zobowiązań SLA？
• Jeśli nie możesz, powinieneś potraktować darmowy pakiet jako wersję próbną, a następnie uaktualnić go do bardziej odpowiedniego pakietu

---

8) Skąd mogę mieć pewność, że CDN faktycznie działa, a nie jest tylko wygodą?

Potwierdź za pomocą tych trzech kroków (bez żadnych skomplikowanych narzędzi):

1. Sprawdzenie, czy zasób statyczny został zwrócony z CDN(czy zmieniło się źródło obrazu/CSS/JS)
2. Sprawdź, czy współczynnik trafień i źródło zwrotu ulegną poprawie(Uderz w górę, źródło z powrotem w dół, aby uzyskać prawdziwe zyski)
3. Jednorazowa zmiana strategii aktualizacji walidacji CSS/obrazów(obowiązujący numer wersji, wskazujący, że łącze można kontrolować)

Jeśli nie możesz zrobić #3, im bardziej optymalizujesz, tym bardziej prawdopodobne jest, że będziesz dręczony przez “aktualizacje nie wchodzą w życie”, dlatego zaleca się nadanie priorytetu polityce wersjonowania.

---

9) Dlaczego często zacinam się po włączeniu przyspieszenia dla Chin kontynentalnych?

Najczęstszą przyczyną jest:Niedopasowanie wyborów regionalnych do warunków zgłoszenia。

• Jeśli chcesz wybrać region przyspieszenia, który obejmuje Chiny kontynentalne, zazwyczaj będziesz musiał wypełnić formularz Rejestracja w ICPUndocumented może wybrać tylko regiony, które nie obejmują Chin kontynentalnych.

---

10) Czy powinienem najpierw zainstalować wtyczkę buforującą czy CDN?

Ogólna zalecana kolejność to:

1. Warstwa witryny źródłowej: wtyczka pamięci podręcznej / baza hostingowa ustabilizowana jako pierwsza (TTFB w dół, ciśnienie backendu w dół)
2. Warstwa zasobów: optymalizacja obrazu w celu zmniejszenia jego rozmiaru
3. Warstwa dostarczania: CDN dostarcza zasoby szybciej i bardziej spójnie

Jeśli chcesz teraz zrobić tylko jedną rzecz i boisz się flipowania:Najpierw statyczny CDN (faza 1)ze stabilnymi zwrotami i minimalnym ryzykiem.