CDN może przyspieszyć część ruchu, ale nie naprawi wolnego WordPressa, jeśli problem leży w PHP, bazie danych albo limitach hostingu. Największy efekt daje wtedy, gdy użytkownicy pobierają dużo statycznych zasobów z lokalizacji odległej od serwera albo gdy CDN potrafi obsłużyć z cache całe odpowiedzi HTML.
Przy wyborze hostingu warto więc rozdzielić trzy rzeczy: serwowanie statycznych plików przez CDN, cache całych stron na brzegu sieci oraz rzeczywistą wydajność serwera origin. Sam napis „CDN w cenie” nie mówi jeszcze, który z tych mechanizmów jest dostępny.
Co właściwie robi CDN?
Dokumentacja cache CDN Cloudflare opisuje przechowywanie treści w rozproszonych centrach danych oraz domyślne cache’owanie zasobów statycznych, takich jak obrazy, CSS i JavaScript. Konkretna usługa może mieć inne reguły, dlatego trzeba sprawdzić jej dokumentację.
Jeżeli użytkownik pobiera zasób z cache CDN, żądanie nie musi za każdym razem docierać do hostingu źródłowego. Może to zmniejszyć opóźnienie sieciowe i część transferu po stronie origin.
Nie oznacza to jednak, że WordPress, PHP i baza danych przestają mieć znaczenie. Gdy CDN nie ma gotowej odpowiedzi w cache, ruch nadal trafia do serwera źródłowego.
CDN statycznych plików a full-page cache
| Mechanizm | Co może obsłużyć | Czego nie rozwiązuje samodzielnie |
|---|---|---|
| CDN statycznych zasobów | Obrazy, CSS, JS, fonty i inne pliki | Generowania dynamicznego HTML przez PHP |
| Full-page edge cache | Gotową odpowiedź HTML dla pasujących żądań | Operacji, których nie wolno lub nie da się cache’ować |
| Origin hosting | PHP, baza danych, logika aplikacji i dynamiczne żądania | Opóźnienia sieciowe użytkowników daleko od serwera |
To rozróżnienie jest ważne. CDN może świetnie dostarczać obrazy, a jednocześnie każda odsłona nadal może czekać na wolne wygenerowanie HTML przez WordPressa.
Kiedy CDN może realnie pomóc?
Największy sens ma wtedy, gdy:
- użytkownicy są rozproszeni geograficznie,
- strona ma dużo ciężkich zasobów statycznych,
- część ruchu można skutecznie obsłużyć z cache,
- origin ma ograniczony transfer albo chcesz zmniejszyć liczbę żądań dochodzących do hostingu,
- serwis korzysta z full-page cache na brzegu sieci dla anonimowych użytkowników.
Efekt zależy od cache hit ratio, rodzaju treści, lokalizacji użytkowników i tego, które odpowiedzi rzeczywiście mogą być cache’owane.
Kiedy CDN może niewiele zmienić?
Jeżeli największa część opóźnienia powstaje zanim serwer zacznie wysyłać HTML, samo przeniesienie obrazów i CSS do CDN może niewiele zmienić w odczuwalnym czasie startu strony.
Typowe przykłady:
- wolne zapytania do bazy,
- ciężkie operacje PHP,
- brak PHP workers przy wielu równoległych żądaniach,
- zewnętrzne API blokujące wygenerowanie odpowiedzi,
- dobijanie do CPU, PMEM, I/O lub IOPS.
W takich przypadkach najpierw zdiagnozuj origin. Pomaga w tym poradnik o wolnym WordPressie.
TTFB originu a CDN
CDN może skrócić drogę sieciową do użytkownika, ale nie usuwa czasu potrzebnego originowi na przygotowanie odpowiedzi, jeśli dana strona nie jest dostępna z edge cache.
Dlatego przy diagnostyce warto rozdzielić:
- czas potrzebny na wygenerowanie odpowiedzi przez origin,
- czas transmisji odpowiedzi przez sieć,
- czas pobierania zasobów statycznych,
- cache hit i cache miss.
Jeżeli TTFB originu jest wysoki dla dynamicznych żądań, trzeba sprawdzić PHP, bazę i zasoby hostingu. Nie utożsamiaj jednak TTFB mierzonego przez CDN z samym czasem generowania PHP. Jeśli chcesz ocenić origin, potrzebujesz pomiaru pozwalającego oddzielić warstwę CDN od czasu odpowiedzi serwera źródłowego. CDN może maskować problem tylko dla części ruchu obsługiwanej z cache.
Cache hit i cache miss — dlaczego mają znaczenie?
Cache hit oznacza, że CDN miał już gotową odpowiedź lub zasób i mógł dostarczyć go bez pobierania z originu. Cache miss oznacza, że dany punkt CDN nie ma gotowej odpowiedzi. Musi ją uzyskać z kolejnej warstwy cache albo z originu, zależnie od architektury CDN. Przykładowe znaczenie stanów HIT, MISS i BYPASS pokazuje dokumentacja diagnostyki cache Cloudflare.
Wysoki udział hitów może znacząco ograniczyć ruch do originu. Niski udział hitów oznacza, że większość żądań nadal przechodzi przez hosting źródłowy.
Nie oceniaj więc CDN wyłącznie po tym, że jest aktywny. Sprawdź, czy faktycznie cache’uje typ ruchu, który generuje większość obciążenia.
CDN a WordPress page cache
Page cache na hostingu i CDN mogą współpracować, ale rozwiązują problem na różnych warstwach. Lokalny page cache może ograniczyć liczbę pełnych uruchomień WordPressa, a CDN może przechowywać gotową odpowiedź jeszcze bliżej użytkownika.
Jeżeli edge cache potrafi obsłużyć całą stronę bez kontaktu z originem, zmniejsza liczbę żądań docierających do PHP. Jeżeli CDN przechowuje tylko pliki statyczne, dynamiczny HTML nadal musi być wygenerowany przez hosting.
Różnicę między page cache i object cache opisuje poradnik o Redis i cache WordPressa.
WooCommerce i dynamiczne strony
Sklep ma wiele odpowiedzi, których nie można bezpiecznie traktować jak identycznej strony dla wszystkich użytkowników. Oficjalna dokumentacja WooCommerce zaleca wykluczenie z cache stron Cart, Checkout i My Account, ponieważ pokazują dane właściwe dla klienta i jego koszyka; konfiguracja musi też uwzględniać sesję użytkownika.
Dlatego full-page cache w WooCommerce wymaga poprawnych reguł wykluczeń i rozpoznawania zalogowanych lub aktywnych sesji. Błąd w konfiguracji cache może prowadzić do serwowania nieaktualnych albo niewłaściwych danych.
Nie oznacza to, że CDN nie ma sensu dla WooCommerce. Statyczne zasoby i bezpiecznie cache’owane strony publiczne nadal mogą korzystać z CDN, a dynamiczne żądania pozostają po stronie originu.
CDN a obrazy
Obrazy są naturalnym kandydatem do CDN, szczególnie gdy mają duży udział w całkowitym rozmiarze strony.
CDN nie zastępuje jednak optymalizacji samych plików. Zbyt duży obraz nadal będzie duży, tylko zostanie dostarczony z innego miejsca. Kompresja, właściwe wymiary i nowoczesne formaty mogą być równie ważne jak sama dystrybucja.
CDN a DNS, WAF i bezpieczeństwo
Niektóre usługi łączą CDN z DNS, reverse proxy, WAF i ochroną przed częścią ataków. Architektura referencyjna Cloudflare pokazuje CDN, DNS i WAF jako osobne usługi, które mogą działać razem. Nie należy przenosić tego zakresu automatycznie na ofertę innego dostawcy.
Przy porównaniu ofert sprawdź, czy „CDN” oznacza:
- tylko dystrybucję plików statycznych,
- reverse proxy dla całej domeny,
- edge cache HTML,
- WAF,
- ochronę DDoS,
- zarządzanie DNS.
Nie zakładaj, że obecność jednej funkcji automatycznie oznacza dostępność pozostałych.
CDN a limity transferu hostingu
Jeżeli CDN obsługuje część ruchu z własnego cache, może zmniejszyć transfer po stronie originu. Skala zależy od udziału cache hitów i rodzaju zasobów.
Nie należy jednak zakładać, że transfer hostingu spadnie o dokładnie taki sam procent jak udział ruchu przez CDN. Cache miss, odświeżanie zasobów, dynamiczne żądania i komunikacja między CDN a originem nadal generują ruch.
Co sprawdzić w ofercie hostingu?
- czy CDN jest dostępny w konkretnym pakiecie,
- czy cache’uje tylko pliki statyczne czy również HTML,
- czy wymaga zmiany DNS lub delegacji domeny,
- czy można kontrolować reguły cache i wykluczenia,
- czy panel pokazuje cache hit/miss lub inne statystyki,
- czy WooCommerce i zalogowani użytkownicy są odpowiednio wykluczani z full-page cache,
- czy CDN ma limity transferu, liczby żądań albo osobny cennik,
- czy usługa zawiera WAF/DDoS/DNS czy są to osobne funkcje.
Gotowe pytanie do operatora
Czy CDN w tym pakiecie obsługuje tylko pliki statyczne, czy również full-page cache HTML? Czy wymaga zmiany DNS albo delegacji domeny? Czy mogę kontrolować reguły cache i wykluczenia dla WooCommerce oraz zalogowanych użytkowników? Proszę również wskazać, czy panel pokazuje cache hit/miss i czy CDN ma osobne limity transferu lub liczby żądań.
CDN czy szybszy hosting?
To nie są zamienne rozwiązania. CDN pomaga przede wszystkim w dystrybucji i cache’owaniu ruchu, a hosting odpowiada za wykonanie PHP, bazę danych i dynamiczną część aplikacji.
Jeżeli origin jest wolny przy każdym cache miss, lepszy CDN nie usunie źródła problemu. Z kolei szybki hosting nie skróci fizycznej drogi sieciowej użytkownika znajdującego się bardzo daleko od serwera.
Najpierw ustal, gdzie powstaje opóźnienie. Dopiero potem zdecyduj, czy potrzebujesz CDN, lepszego cache, większych zasobów hostingu czy optymalizacji samej aplikacji.