Czym jest CDN? Sieć dostarczania treści i dlaczego warto jej używać

Kiedy użytkownik z Polski otwiera Twoją stronę, a serwer stoi na innym kontynencie, każda prośba musi przebyć długą drogę. CDN skraca tę drogę, przechowując kopie plików bliżej użytkowników. Ten artykuł wyjaśnia, czym jest CDN, jak działa, kiedy warto go używać i jakich błędów unikać. Nie podaję cen ani rankingu dostawców, bo zależą od ruchu i szybko się zmieniają. Nie konfigurowałem CDN u żadnego dostawcy, ale sprawdziłem nagłówki prawdziwej strony i pokazuję je poniżej.

Czym jest CDN?

Według słownika MDN CDN (Content Delivery Network, sieć dostarczania treści) to grupa serwerów rozmieszczonych w wielu lokalizacjach. Przechowują duplikaty danych, dzięki czemu mogą obsługiwać prośby z serwera położonego najbliżej użytkownika. Taka usługa jest szybka i mniej podatna na duży ruch. Najprościej: zamiast jednego serwera, który odpowiada wszystkim, masz sieć kopii, a użytkownik dostaje odpowiedź z najbliższej z nich.

Jak działa CDN?

W opisie web.dev i AWS mechanizm wygląda tak:

1. Pierwsza prośba trafia do serwera źródłowego (origin), czyli Twojego serwera, z którego CDN pobiera treści.
2. CDN zapisuje kopię na serwerze w pobliżu użytkownika (AWS nazywa takie miejsca punktami obecności, POP).
3. Kolejne prośby obsługuje CDN, bez podróży do serwera źródłowego. Według web.dev buforowanie zasobów na serwerach CDN eliminuje potrzebę przesyłania prośby aż do serwera źródłowego.

Jeśli plik jest już w pamięci podręcznej CDN, mówimy o trafieniu (cache hit). Jeśli go brakuje i trzeba go pobrać z serwera źródłowego, o chybieniu (cache miss). Według MDN odległość geograficzna wpływa na opóźnienie proporcjonalnie, więc im bliżej użytkownika leży kopia, tym szybciej odpowiedź dotrze.

Dlaczego warto używać CDN? Główne korzyści

Według web.dev, MDN i AWS CDN daje:

Według web.dev idealnie jest serwować przez CDN całą stronę, a jeśli to niemożliwe, przynajmniej pliki statyczne. Nie podaję, o ile szybciej zadziała Twoja strona, bo żadne ze źródeł nie podaje takich liczb, a ja ich nie mierzyłem.

Co CDN cache'uje, a czego nie powinien?

AWS rozróżnia dwa rodzaje treści:

Dla treści dynamicznej CDN może przyspieszać samo połączenie z serwerem źródłowym (AWS nazywa to dynamic acceleration), ale to inna funkcja niż cache. Zasada bezpieczeństwa: treści spersonalizowanych nie wolno zapisywać w cache współdzielonym. MDN ostrzega, że byłoby problemem, gdyby odpowiedź ze spersonalizowaną treścią była niespodziewanie widoczna dla innych użytkowników cache'a. Do takich odpowiedzi służy nagłówek Cache-Control: private.

Uwaga mentora: zanim włączysz CDN, sprawdź nagłówki Cache-Control swojej aplikacji. CDN zrobi dokładnie to, co mu każą nagłówki, więc źle oznaczona strona po zalogowaniu może pokazać dane jednego użytkownika drugiemu.

Jak CDN wie, co i jak długo cache'ować? Nagłówki Cache-Control

CDN decyduje na podstawie nagłówków HTTP, które wysyła Twój serwer, albo reguł ustawionych w panelu dostawcy. Według MDN CDN należy do pamięci podręcznych współdzielonych (shared cache), czyli zarządzanych (managed cache), wdrażanych po to, żeby odciążyć serwer źródłowy. Najważniejsze nagłówki:

Według web.dev do cache'owania publicznych zasobów wymagany jest co najmniej max-age, s-maxage lub Expires, a odpowiedzi z no-store lub private nie są cache'owane. MDN dodaje, że niektórzy dostawcy CDN mają własne nagłówki (np. Surrogate-Control), a trwają prace nad ujednoliconym CDN-Cache-Control.

Jak wygląda cache CDN na prawdziwej stronie?

Sprawdziłem nagłówki naszej strony poleceniem curl:

curl -sI https://devmentor.pl/_next/static/chunks/NAZWA.css

Nagłówki pliku statycznego (CSS) z 10 listopada 2026:

HTTP/2 200
cache-control: public,max-age=31536000,immutable
age: 10073
x-vercel-cache: HIT
content-type: text/css; charset=utf-8

Co z tego wynika:

• cache-control: public,max-age=31536000,immutable: plik jest świeży przez rok i nie zmienia się. To dokładnie wzorzec z MDN dla plików z wersją w nazwie (nazwa pliku z losowym ciągiem znaków zmienia się, gdy zmieni się treść).
• age: 10073: odpowiedź leży w pamięci podręcznej od ponad dwóch godzin (10 073 sekund).
• x-vercel-cache: HIT: nagłówek dostawcy, z którego korzystamy, informujący o trafieniu w cache (nie sprawdzałem dokumentacji tego nagłówka, więc interpretuję go ostrożnie).

Dla strony głównej ta sama próba pokazała cache-control: public, max-age=0, must-revalidate i age: 878: HTML ma krótki czas świeżości, więc jest sprawdzany na bieżąco, a pliki statyczne są trzymane długo. To typowy podział: długie cache dla niezmiennych plików, krótkie lub sprawdzane dla HTML. Strona z Cloudflare, którą sprawdziłem dla porównania, wysyłała dla strony głównej cache-control: no-store, więc nie służy jako przykład cache'owania. Nie mierzyłem szybkości ładowania z różnych krajów, więc nie twierdzę, że to „przyspieszyło” stronę.

Jak odświeżyć zawartość po zmianie? Cache busting i purge

Największy problem z CDN to nieaktualne pliki po wdrożeniu. Są na to dwa sposoby:

1. Zmiana adresu pliku (cache busting). Według MDN dla zasobów, które się zmieniają, dobrą praktyką jest zmiana URL przy każdej zmianie treści (np. bundle.v123.js), żeby adres mógł być cache'owany długo. Nagłówek immutable wskazuje, że nie trzeba rewalidacji.
2. Wyczyszczenie cache (purge). Dostawcy oferują czyszczenie wskazanych plików albo całej pamięci. Cloudflare opisuje to jako natychmiastowe czyszczenie zapisanych plików, po którym CDN pobiera świeże wersje z serwera źródłowego.

W praktyce wersjonowanie nazw plików robią za Ciebie narzędzia do budowania frontendu, a purge dodaje się do pipeline'u wdrożenia, o którym piszemy w artykule o CI/CD.

Jakich CDN używać?

Wiele dostawców oferuje własne sieci. Trzy chmury opisywane na blogu mają swoje usługi CDN, według zestawienia Google Cloud: CloudFront w AWS, Azure Front Door w Azure i Cloud CDN w Google Cloud (porównanie wszystkich usług znajdziesz w artykule AWS, Azure czy Google Cloud). AWS podaje, że CloudFront ma ponad 450 punktów obecności (liczba z ich strony, nie weryfikowana). Są też niezależni dostawcy CDN, np. Cloudflare, którego dokumentacja opisuje cache i czyszczenie plików. Wiele platform do hostowania stron ma CDN wbudowany. W przypadku naszej strony nagłówek x-vercel-cache pokazuje, że odpowiedzi trafiają do warstwy cache u dostawcy hostingu.

Przy wyborze sprawdź:

• czy obsługuje potrzebny Ci sposób czyszczenia cache (po plikach, po ścieżkach, wszystko),
• jak wygląda rozliczanie (nie podaję kwot, sprawdź cennik dostawcy),
• czy działa z Twoim hostingiem lub chmurą,
• czy daje HTTPS i nowoczesne protokoły (TLS 1.3, HTTP/2 według web.dev poprawiają wydajność).

Kiedy CDN ma sens, a kiedy nie?

Jeśli stawiasz własny serwer, o którym piszemy w artykule o serwerze VPS, CDN przed nim odciąży go od plików statycznych. MDN wspomina też o ryzykach CDN: zależność od zewnętrznego dostawcy, ryzyko ataku i w niektórych sytuacjach możliwy spadek wydajności, więc zawsze mierz efekt.

Jakie błędy zdarzają się przy CDN?

Od czego zacząć z CDN?

1. Sprawdź nagłówki swojej strony poleceniem curl -I i znajdź Cache-Control, Age i nagłówek dostawcy.
2. Wersjonuj nazwy plików statycznych i nadaj im długi max-age z immutable.
3. Ustaw private lub no-store dla treści spersonalizowanych.
4. Włącz CDN dla plików statycznych, a dopiero potem rozważ pozostałe treści.
5. Dodaj czyszczenie cache do wdrożenia i sprawdzaj wynik po każdej zmianie.

Wdrożenie aplikacji na prawdziwym serwerze, razem z kontenerami i automatycznym HTTPS, ćwiczysz w module wdrożenie produkcyjne w chmurze w kursie AI Engineer. Jeśli korzystasz z chmury AWS, podstawy opisuje artykuł czym jest AWS.

Podsumowanie

• CDN to rozproszona sieć serwerów, które przechowują kopie plików i serwują je z miejsca najbliżej użytkownika.
• Korzyści: mniejsze opóźnienia, odciążenie serwera źródłowego, odporność na skoki ruchu i, według web.dev, poprawa TTFB i LCP. Źródła nie podają liczb przyspieszenia, więc ich nie podaję.
• Pliki statyczne cache'uje się dobrze, treści spersonalizowane nie wolno cache'ować dla wszystkich (Cache-Control: private).
• Nagłówki max-age, private, no-store i immutable sterują tym, co i jak długo jest w cache'u, a Age pokazuje jego wiek.
• Nieaktualne pliki po wdrożeniu rozwiązujesz wersjonowaniem nazw plików (cache busting) lub czyszczeniem cache (purge).
• Nagłówki naszej strony sprawdziłem curl-em, ale CDN u żadnego dostawcy nie konfigurowałem, a szybkości z różnych krajów nie mierzyłem.