Zdecyduj, co ma dostarczać CDN
Zacznij od inwentaryzacji. Oddziel wersjonowane zasoby, takie jak obrazy, arkusze stylów, skrypty, czcionki i pliki do pobrania, od HTML, API, stron kont użytkowników, koszyka i panelu administracyjnego. CDNy często wypełniają cache w trybie on‑demand: pierwsze żądanie może trafić do origin, podczas gdy kolejne pasujące żądania mogą być obsłużone na edge. Pobliska lokalizacja edge i trafienie w cache to różne korzyści.
Zanotuj hosta, aplikację, bucket storage lub load balancer dostarczający każdą ścieżkę; musi on odpowiadać w przypadku miss w cache.
Zacznij od zasobów identycznych dla każdego odwiedzającego, które bezpiecznie mogą być dostępne aż do zakończenia deklarowanego czasu życia.
Nie współdzielaj spersonalizowanych pulpitów, stron powiązanych z sesją ani danych klientów, chyba że wykwalifikowany inżynier zaprojektował i przetestował separację.
Ustal politykę cache w oparciu o zachowanie treści
Nagłówki odpowiedzi HTTP wyrażają zachowanie cache. Cache-Control mówi, czy odpowiedź może być przechowywana i jak długo pozostaje świeża; czas życia (TTL) to ten okres świeżości. Przeglądarka to cache prywatny, natomiast CDN zwykle jest cachem współdzielonym. Używaj jednoznacznych nagłówków. Standard HTTP pozwala ustawić s-maxage dla osobnego czasu życia cache współdzielonego względem max-age.
Publikuj nowy URL przy zmianie zawartości, np. nazwę pliku z hashem treści, a niezmiennej wersji nadaj długi, udokumentowany czas życia.
Wybierz krótki czas życia lub zachowanie walidacyjne w zależności od kosztu przestarzałej treści; nie używaj reguły zasobu dla cen, stanów magazynowych czy stanu konta.
Używaj dyrektywy private dla odpowiedzi przeznaczonych dla jednego użytkownika. Sam ciasteczko (cookie) nie czyni odpowiedzi bezpieczną dla cache współdzielonego.
Uczyń unieważnianie wyjątkiem, a nie planem wydania
Unieważnianie (invalidation) lub purge mówi zarządzanemu CDN, by usunął wybrane obiekty zanim wygasną. Używaj tego do korekt, nie przy każdym wdrożeniu. Potwierdź, że origin już zwraca zamiennik przed purge; w przeciwnym razie refill może zachować złą odpowiedź. Cache przeglądarki leży poza kontrolą purge CDN, więc wersjonowanie URL pozostaje niezawodnym sposobem przy zmieniających się plikach.
Wol preferuj konkretną ścieżkę, grupę wydań lub tag cache wspierany przez dostawcę zamiast purge całej witryny; szerokie missy mogą nagle obciążyć origin.
Rozproszony purge może nie dotrzeć do każdego edge jednocześnie. Sprawdź semantykę zakończenia po stronie dostawcy i przetestuj reprezentatywny URL.
Zapisz stary i nowy URL, regułę cache, zakres purge, oczekiwany rezultat i krok odwrócenia.
Trzymaj origin za warstwą dostarczania
Bezpośredni dostęp do origin może omijać cache CDN i kontrole edge. Ogranicz go tak, żeby CDN, i tylko zamierzone ścieżki, mogły się z nim łączyć. W zależności od stacku użyj kontroli dostępu cloud-origin, reguł firewall z udokumentowanymi zakresami egress CDN, sieci prywatnej, podpisanych żądań origin albo mutual TLS (mTLS), gdzie obie strony uwierzytelniają się certyfikatami.
Z uprawnionej lokalizacji testowej potwierdź, że origin odrzuca publiczne żądania, podczas gdy hostname CDN działa.
Ogranicz health checki, narzędzia wdrożeniowe i dostęp wewnętrzny poprzez tożsamość i sieć, a nie szeroką regułę publiczną.
Uwierzytelnianie origin różni się między CDN i origin. Stosuj aktualne wskazówki konfiguracyjne dostawcy i przegląd bezpieczeństwa.
Traktuj TLS jako dwa połączenia
HTTPS na edge chroni połączenie odwiedzający→CDN, ale połączenie CDN→origin także wymaga ochrony. Wymagaj szyfrowania na obu odcinkach, waliduj certyfikat origin dla trybu CDN i przypisz właściciela hostnamu i odnowień. OWASP zaleca TLS 1.3 domyślnie i dopuszcza TLS 1.2 dla kompatybilności; wskazuje, że TLS 1.0 i 1.1 powinny być wyłączone. Uzyskaj kwalifikowany przegląd dla danych regulowanych, przepływów płatności lub nietypowej kompatybilności klienta.
Wypisz właścicieli certyfikatów edge i origin, ścieżki odnowienia i procedurę na wypadek awarii.
Przetestuj HTTP→HTTPS, canonical‑host i przekierowania deep‑link pod kątem pętli lub utraty ścieżek.
Szyfrowanie nie czyni odpowiedzi bezpieczną do cachowania; ustaw reguły cache oddzielnie dla stron uwierzytelnionych, personalizowanych i związanych z płatnościami.
Przetestuj rzeczywistą ścieżkę dostarczania przed zmianą ruchu
Zacznij od hostname stagingowego lub wąskiej ścieżki produkcyjnej, następnie testuj hostname CDN, nie tylko origin. Chrome DevTools Network pokazuje status żądania, domenę, czasy, rozmiar i nagłówki. Przetestuj hard reload z pustym cache, by przybliżyć pierwszą wizytę, potem wizytę powtórną, aby sprawdzić ponowne użycie. Porównuj oczekiwane nagłówki i zawartość, nie tylko wizualnie szybszą stronę. Powtarzaj testy z reprezentatywnych regionów, gdy publiczność jest rozproszona.
Sprawdź Cache-Control i dostawcy nagłówki typu cache-status. Potwierdź, że zasoby publiczne są ponownie używane, a strony wrażliwe nie są niespodziewanie współdzielone.
Przećwicz miss, korektę nieświeżej treści, błąd origin i rollback jednego zasobu lub ścieżki przed szerokim uruchomieniem.
Zachowaj testowane URL, zrzuty nagłówków, wersję reguły trasowania oraz czasy przed i po z zapisem zmian.
Wybierz CDN według potrzeb operacyjnych, a potem to udowodnij
Nie wybieraj CDN wyłącznie po liczbie punktów obecności czy ogólnym twierdzeniu o szybkości. Wydajność różni się w zależności od geografii, czasu, rozkładu ruchu, routingu i współczynnika trafień cache. Porównaj kandydatów na reprezentatywnych trasach, zasobach i regionach. Zapytaj, czy każdy wspiera wymagane kontrolki cache, celowane unieważnianie, ograniczenie origin, workflow certyfikatów, logi, role dostępu, ceny, wsparcie i proces zmian.
Użyj identycznych nagłówków cache, zachowania origin i stron dla kandydatów; zapisz wyniki pierwszej wizyty i wizyty powtórnej oddzielnie.
Przejrzyj koszty żądań, transferu, unieważnień, logowania i wsparcia oraz skoków spowodowanych missami cache. Ceny i kontrolki różnią się w zależności od planu.
Wymagaj eksportowalnej konfiguracji, zasady najmniejszych uprawnień, przetestowanego rollbacku i jasnej własności przed pokryciem krytycznych tras.