Włączenie CDN zajmuje kilka minut, ale jego poprawna konfiguracja decyduje o tym, czy strona faktycznie przyspieszy, czy zacznie pokazywać nieaktualne ceny, cudze koszyki albo stare wersje plików po wdrożeniu. W tym wpisie pokazuję, jak konfiguruję CDN dla stron firmowych i sklepów: co trafia do pamięci podręcznej, a co nigdy nie powinno, jak czyszczę cache po zmianach, jakie reguły ustawiam na brzegu sieci i jak sprawdzam, że wszystko działa.
Jaki model wdrożenia wybieram
Są dwa podstawowe sposoby podłączenia CDN i od wyboru zależy reszta konfiguracji:
- CDN przed całą domeną. Ruch do całej strony przechodzi przez CDN, zwykle po zmianie serwerów nazw lub rekordów w konfiguracji DNS. Daje to najwięcej możliwości: cache stron HTML, zaporę, reguły przekierowań i ochronę serwera, ale wymaga przemyślenia, czego nie wolno zapisywać w pamięci.
- CDN tylko dla plików statycznych. Obrazy, style i skrypty są serwowane z osobnej subdomeny, np.
cdn.twojadomena.pl, a strony HTML nadal z serwera. Prostsze i bezpieczniejsze, ale bez ochrony samego serwera i bez przyspieszenia stron dynamicznych.
Przy sklepach i serwisach z dużym ruchem zwykle wybieram pierwszy wariant. Przy małych stronach z polskimi użytkownikami i szybkim hostingiem w Polsce różnica w szybkości bywa niewielka i CDN wdrażam głównie dla bezpieczeństwa i odciążenia serwera.
Co trafia do pamięci CDN, a co nie
To najważniejsza część konfiguracji. Każdy typ treści ustawiam osobno:
| Typ treści | Ustawienie w CDN | Uwagi |
|---|---|---|
| CSS, JS i czcionki z wersją w nazwie | Cache na długo, nawet rok | Nowa wersja ma nową nazwę, więc nie trzeba czyścić pamięci |
| Obrazy | Cache na tygodnie lub miesiące | Przy podmianie pliku pod tym samym adresem potrzebne czyszczenie |
| Strony HTML dla niezalogowanych | Krótki cache lub cache z czyszczeniem po publikacji | Największy zysk dla stron firmowych i blogów |
| Koszyk, zamówienie, konto, panel administracyjny | Zawsze pomijane | Dane jednego użytkownika nie mogą trafić do pamięci współdzielonej |
| Odpowiedzi API i formularze | Zwykle pomijane | Wyjątkiem są publiczne dane, np. lista produktów, z krótkim czasem |
Kluczowe jest pomijanie cache dla zalogowanych użytkowników i osób z produktami w koszyku. W WordPressie i WooCommerce robię to na
podstawie ciasteczek ustawianych po zalogowaniu i dodaniu produktu do koszyka. Odpowiedzi, które ustawiają ciasteczka nagłówkiem
Set-Cookie, w ogóle nie powinny trafiać do pamięci współdzielonej.
Ustawiam też klucz cache, czyli to, które elementy adresu tworzą osobną kopię. Parametry kampanii, np. utm_source, wyłączam
z klucza, bo inaczej każdy link z newslettera tworzy osobną kopię strony i większość wejść trafia do serwera zamiast do pamięci CDN.
Nagłówki, które sterują CDN
Najlepiej, gdy o czasie przechowywania decyduje serwer, a CDN tylko respektuje jego nagłówki. Wtedy reguły są w jednym miejscu, w kodzie
lub konfiguracji serwera, a nie rozproszone po panelu CDN. Do rozdzielenia czasu w przeglądarce i w CDN używam dyrektywy s-maxage:
Cache-Control: public, max-age=60, s-maxage=3600, stale-while-revalidate=600Przeglądarka trzyma stronę minutę, CDN godzinę, a po tym czasie przez kolejne 10 minut może jeszcze pokazać starą wersję, pobierając w tle nową. Dla plików statycznych stosuję te same zasady, które obowiązują przy cache przeglądarki: długi czas tylko dla plików z wersją w nazwie.
Czyszczenie cache po zmianach
Każdy cache wymaga planu na to, jak usuwać z niego nieaktualne dane. Stosuję kilka poziomów:
- Wersjonowane nazwy plików – dla CSS i JS najlepszy sposób to brak potrzeby czyszczenia. Nowa wersja ma nowy adres.
- Czyszczenie konkretnych adresów – po edycji wpisu czy produktu usuwam z pamięci tylko jego stronę i strony, na których się pojawia, np. kategorię i stronę główną.
- Czyszczenie po tagach lub prefiksach – jeśli CDN to obsługuje, oznaczam strony tagami, np. wszystkie strony kategorii „buty”, i czyszczę je jednym poleceniem.
- Pełne czyszczenie – tylko po zmianach w szablonie lub przy migracji. Przy dużym ruchu oznacza nagłe obciążenie serwera, bo przez chwilę wszystkie żądania trafiają bezpośrednio do niego.
Czyszczenie automatyzuję. CMS lub aplikacja po publikacji zmiany wywołuje API CDN, a wdrożenie nowej wersji kodu kończy się wyczyszczeniem stron HTML. Ręczne klikanie w panelu CDN po każdej zmianie prędzej czy później kończy się nieaktualną ceną na stronie.
Reguły na brzegu sieci
CDN to nie tylko pamięć podręczna. Część logiki przenoszę na brzeg sieci, bo działa tam szybciej i odciąża serwer:
- Przekierowania – wymuszenie HTTPS i jednej wersji domeny oraz przekierowania po migracji.
- Bezpieczeństwo – zapora aplikacyjna, ograniczanie liczby żądań do logowania i formularzy, blokowanie złośliwych botów.
- Kompresja i obrazy – Brotli dla plików tekstowych oraz konwersja obrazów do nowoczesnych formatów, jeśli serwer sam tego nie robi.
- Modyfikacja odpowiedzi – dodanie nagłówków czy poprawki w kodzie strony bez zmian w aplikacji. To podstawa podejścia Edge SEO, które stosuję, gdy wdrożenie zmian w samym CMS-ie trwa miesiącami.
SSL i ochrona serwera źródłowego
Połączenie między CDN a serwerem też musi być szyfrowane z weryfikacją certyfikatu. Tryb, w którym CDN łączy się z serwerem przez HTTP, daje kłódkę w przeglądarce, ale ruch do serwera pozostaje nieszyfrowany i często kończy się pętlą przekierowań, jednym z typowych błędów certyfikatu SSL po wdrożeniu CDN.
Po wdrożeniu ograniczam też bezpośredni dostęp do serwera, tak aby przyjmował ruch tylko z adresów CDN. Inaczej atakujący, który zna adres IP serwera, omija całą ochronę. Pamiętam również o konfiguracji serwera tak, by odczytywał prawdziwy adres IP użytkownika z nagłówka przekazywanego przez CDN. Bez tego wszystkie wejścia w logach wyglądają jak ruch z kilku adresów CDN, a analiza logów serwera czy blokowanie konkretnych adresów traci sens.
Jak sprawdzam, czy CDN działa poprawnie
Najprostszy test to sprawdzenie nagłówków odpowiedzi kilka razy z rzędu:
curl -sI https://twojadomena.pl/ | grep -i -E "cache-status|x-cache|age|cache-control"CDN-y dodają nagłówek ze statusem, np. HIT, gdy odpowiedź pochodzi z pamięci, i MISS, gdy z serwera. Sprawdzam stronę
główną, wpis, produkt, plik CSS oraz koszyk i stronę po zalogowaniu, które zawsze muszą mieć status pominięcia cache. W panelu CDN
obserwuję współczynnik trafień w pamięć: jeśli jest niski, zwykle winny jest klucz cache z parametrami albo ciasteczka ustawiane na każdej stronie.
Najczęstsze błędy, które poprawiam po cudzych wdrożeniach, to cache stron dla zalogowanych użytkowników, brak czyszczenia po zmianach, sprzeczne reguły w CDN i na serwerze oraz brak prawdziwego adresu IP w logach. Każdy z nich da się wychwycić powyższym testem w kilka minut, zanim zauważą go klienci.