Czym jest CDN edge caching?

CDN edge caching to hasłowe określenie praktyki buforowania treści sieciowych w wielu geograficznie rozproszonych węzłach brzegowych, tak aby skrócić odległość między użytkownikiem a zasobem, zmniejszyć obciążenie serwera źródłowego i zapewnić stabilny czas odpowiedzi nawet w szczytach ruchu. Pojęcie łączy dwa poziomy: logiczny (reguły, nagłówki HTTP, polityki przechowywania i unieważniania) oraz fizyczny (rozproszone centra danych, Anycast, protokoły transportowe), tworząc spójną warstwę akceleracji dostępu do stron, API i mediów. Z punktu widzenia słownika tworzenia stron www jest to mechanizm kluczowy dla osiągania wysokiej wydajności, przewidywalności i skalowalności frontendu oraz warstwy treści, przy jednoczesnym zachowaniu integralności danych i zgodności z semantyką HTTP.

Definicja i zakres pojęcia

Podstawą terminu jest sieć dystrybucji treści, czyli CDN (Content Delivery Network). W warstwie operacyjnej CDN składa się z rozproszonego zestawu punktów obecności, które przyjmują żądania od użytkowników końcowych i zwracają zasoby sieciowe. Częścią tego modelu jest brzeg sieci – warstwa najbliższa użytkownikowi – określany jako edge. To tam stosuje się polityki przechowywania kopii zasobów, czyli caching, dzięki czemu zawartość może być serwowana bez konieczności każdorazowego sięgania do serwera źródłowego. Edge caching jest więc konkretną techniką w obrębie CDN polegającą na tym, że odpowiedzi HTTP (lub ich fragmenty) są zapamiętywane w węzłach brzegowych i udostępniane kolejnym klientom z lokalnego magazynu.

W praktyce definicja obejmuje trzy wymiary: po pierwsze mechanikę protokołu (nagłówki kontrolujące pamięć podręczną, walidatory, semantykę Fresh/Expired/Stale), po drugie strategię rozmieszczenia (geografia węzłów, routing Anycast, ewentualne warstwy pośrednie), i po trzecie politykę biznesową (czas życia, priorytety, wyjątki, zasady czyszczenia przy aktualizacjach). Dzięki temu edge caching nie jest wyłącznie „pamięcią” – to spójny model zarządzania treścią w skali globalnej, zgodny z regułami HTTP, który może dotyczyć plików statycznych, renderowanych stron, komponentów HTML, odpowiedzi API, a nawet strumieni wideo.

W słownikowym ujęciu: CDN edge caching to wielowarstwowy, geograficznie rozproszony mechanizm buforowania odpowiedzi HTTP w węzłach brzegowych CDN, sterowany nagłówkami i regułami, którego celem jest minimalizacja opóźnień, zmniejszenie obciążenia infrastruktury źródłowej oraz poprawa odporności i jakości doświadczenia użytkownika. Określenie to bywa używane zamiennie z terminami takimi jak „edge cache”, „cache at edge” czy „brzegowe buforowanie treści”, przy czym akcentuje zarówno bliskość do użytkownika, jak i świadomość protokołu HTTP.

Jak działa edge caching w przepływie żądań

Standardowy przebieg wygląda następująco: przeglądarka (lub inny klient) wysyła żądanie HTTP do hosta. DNS domeny kieruje to żądanie do węzła brzegowego CDN najbliższego użytkownika. Ten węzeł sprawdza, czy istnieje lokalna kopia odpowiedzi zgodna z kluczem pamięci podręcznej (cache key), dodatkowymi warunkami (np. Vary, cookies, parametrów zapytania) oraz czy kopia jest wciąż świeża. Jeśli tak – odpowiedź jest zwracana natychmiast z brzegu. Jeśli nie – węzeł brzegowy wysyła żądanie do warstwy pośredniej lub bezpośrednio do serwera źródłowego, otrzymuje odpowiedź, zapisuje ją (o ile polityka na to pozwala) i odsyła klientowi.

Ważną rolę odgrywają nagłówki Cache-Control, Expires, ETag, Last-Modified oraz mechanizmy walidacji warunkowej (If-None-Match, If-Modified-Since). One określają, czy zasób można przechować, na jak długo, i kiedy wolno go ponownie zweryfikować. Często stosuje się też Surrogate-Control do odrębnego sterowania cache’em CDN, odróżniając go od przeglądarkowego. Uzupełnieniem są dyrektywy stale-while-revalidate i stale-if-error, które pozwalają serwować treść z pamięci jako „stale” podczas równoległej odświeżającej walidacji bądź w przypadku błędów po stronie źródła. To wzorzec znany z praktycznych akceleratorów – poprawia płynność dostaw bez wprowadzania niespójności dla użytkownika.

W edge cachingu definiujesz klucz pamięci: domena/ścieżka, opcjonalnie parametry zapytania, nagłówki urządzenia (User-Agent, Accept-Language), a także sposób normalizacji. Dobra definicja klucza redukuje duplikaty i zapobiega zjawisku „cache bloat”. Klucz łączysz z regułami czasu życia – TTL (Time To Live) – oraz politykami odświeżania. Dodatkowe techniki to tiered caching (warstwa „shield” trzyma gorący zestaw obiektów, odciążając origin), reużycie połączeń, kompresja i transformacje treści. Gdy treść wymaga natychmiastowej aktualizacji, stosuje się mechanizmy czyszczenia (purge/invalidate), zarówno precyzyjne (po URL, tagu), jak i szerokie (np. po prefiksie), oraz tryby miękkie (soft purge) i twarde (hard purge).

Z punktu widzenia doświadczenia użytkownika liczy się głównie redukcja opóźnień – niższa latencja i mniejsza zmienność, co przekłada się na szybsze renderowanie pierwszej treści i stabilny czas odpowiedzi API. Węzeł blisko użytkownika może też kończyć połączenia TLS, obsługiwać HTTP/2 i HTTP/3, a do źródła łączyć się po zoptymalizowanym, trwałym kanale, skracając overhead protokołów transportowych.

Architektura, składniki i terminologia

Fizyczną podstawą są punkty obecności – PoP (Points of Presence). Każdy PoP zawiera węzły brzegowe, które przechowują fragmenty treści i obsługują ruch lokalny. Globalny routing opiera się zwykle na Anycaście: wiele PoP-ów ogłasza ten sam prefiks IP, a ruch trafia do najbliższego topologicznie węzła. To zapewnia niskie opóźnienia i automatyczną redundancję. Między brzegiem a zapleczem może istnieć warstwa pośrednia (mid-tier, shield), która zwiększa skuteczność cache’u, zwłaszcza gdy wiele brzegów mogłoby dopytywać ten sam zasób. W głębi stoi serwer źródłowy – origin – jedyne autorytatywne źródło prawdy o zasobach.

W architekturze pojawiają się też funkcje towarzyszące: WAF (ochrona aplikacyjna), rate limiting (ochrona przed zalewem zapytań), bot management, TLS terminacja, HTTP/3 (QUIC), kompresja, optymalizacja obrazów, przepisywanie ścieżek, georouting, a nawet funkcje „edge compute” (np. krótkie skrypty uruchamiane na brzegu w celu modyfikacji odpowiedzi, personalizacji nagłówków, przekształceń HTML). Edge caching czerpie korzyści z tych komponentów: odpowiednio dobrane reguły przepuszczania/niewpuszczania, modyfikacji kluczy i kontroli nagłówków potrafią podnieść współczynnik trafień cache o kilkanaście punktów procentowych.

Istotna jest także topologia połączeń do zaplecza: łącza między PoP a originem bywają zoptymalizowane pod kątem mniejszej zmienności i większej przepustowości, z wielokrotnym reuse połączeń, co redukuje koszty zestawiania TLS i TCP oraz pozwala ograniczyć obciążenie źródła. Z kolei po stronie klienta brzeg może używać 0-RTT w QUIC (z odpowiednimi ostrożnościami bezpieczeństwa) i sesji TLS, skracając czas do pierwszego bajtu w nowych połączeniach.

Korzyści i mierzalny wpływ na wydajność

Najczęściej cytowane korzyści to niższe opóźnienia, mniejszy jitter i stabilność odpowiedzi. Przedmiotem bezpośredniego wpływu są wskaźniki Core Web Vitals z segmentu czasu odpowiedzi i renderowania. W szczególności skraca się TTFB (Time To First Byte) – zarówno w średniej, jak i w długim ogonie – a tym samym rośnie skuteczność pierwszego malowania i interaktywności przy zasobach krytycznych (HTML, CSS, JS). W API zyskiem jest spójny czas odpowiedzi pod obciążeniem, co umożliwia liniowe skalowanie warstw biznesowych.

Drugi filar to odciążenie infrastruktury: wysoki współczynnik trafień w cache (cache hit ratio) zmniejsza liczbę zapytań do zaplecza, a więc koszty egress i licencyjne, a także ryzyko saturacji baz danych. Przy dobrze dobranym TTL, rozsądnej normalizacji klucza i purgu po zmianach treści możliwa jest redukcja ruchu do originu nawet o 70–95% dla statyk i kilkadziesiąt procent dla stron i API renderowanych dynamicznie, jeśli zastosuje się częściowe lub warunkowe buforowanie.

Trzeci filar to odporność. Gdy źródło przeżywa awarię lub chwilowe błędy, strategia stale-if-error pozwala dalej serwować kopie. Uzupełnia to izolacja geograficzna: awaria pojedynczego regionu nie musi oznaczać niedostępności globalnej. Wreszcie: poprawa wyników wydajnościowych ułatwia pozycjonowanie – szybszy serwis jest preferowany zarówno przez użytkowników, jak i roboty indeksujące, co przekłada się na częstotliwość i efektywność crawlowania oraz jakość indeksu.

Warto dodać korzyści biznesowe: krótsze czasy wczytywania zwiększają konwersję i obniżają współczynniki odrzuceń. W e‑commerce mniejsza zmienność czasu odpowiedzi sprzyja kończeniu zakupów, a w mediach – płynności odtwarzania. API B2B zyskują przewidywalność SLA, a zespoły inżynierskie – większą kontrolę nad ruchem dzięki telemetrii i regułom sterowania po stronie brzegu.

Konfiguracja, nagłówki i najlepsze praktyki

Skuteczny edge caching zaczyna się od poprawnych nagłówków. Cache-Control powinien rozdzielać politykę dla przeglądarki i CDN, często przez użycie Surrogate-Control (np. krótsze czasy w przeglądarce, dłuższe w CDN). Dla treści publicznych używa się zwykle public, s-maxage, stale-while-revalidate, stale-if-error. Dla treści wrażliwych – private, no-store lub krótkie okna z walidacją warunkową. Pamiętaj, że „no-cache” nie oznacza „nie przechowuj”, lecz „zawsze zweryfikuj przed użyciem”. W zastosowaniach, gdzie akceptujesz minimalne starzenie, stale-while-revalidate potrafi diametralnie poprawić płynność odświeżania.

Przykładowe wzorce nagłówków:

Cache-Control: public, s-maxage=86400, max-age=300, stale-while-revalidate=60, stale-if-error=600
Surrogate-Control: max-age=604800
ETag: „ab12cd”
Vary: Accept-Encoding, Accept-Language
Cache-Control: private, no-store (dla odpowiedzi z danymi użytkownika)

Projekt klucza cache to obszar decydujący o skuteczności. Ustal, które parametry zapytania należy ignorować, a które rozróżniać; rozważ normalizację protokołu i hosta; unikaj wrzucania całego nagłówka User-Agent do klucza – zamiast tego klasyfikuj urządzenie (mobile/desktop). Niekontrolowane cookies mogą uczynić treść niebuforowalną – rozważ ich separację lub akceptację tylko określonych. Ustaw dedykowane reguły dla zasobów krytycznych (np. HTML) i secondaries (obrazy, czcionki, skrypty), a także dla stron o wysokiej zmienności (newsy, wyniki giełdowe) z krótszym s-maxage i agresywnym purge.

Operacyjnie niezbędny jest proces unieważniania – inwalidacja. Zadbaj o możliwość czyszczenia po URL, po prefiksie oraz po tagach (np. „article:1234”). Tagi pozwalają grupować elementy i czyścić je po publikacji/aktualizacji. Miękkie purge (soft) oznacza oznaczenie kopii jako nieświeżej, ale nadal serwowanej do czasu odświeżenia; twarde (hard) – natychmiastowe usunięcie, kosztem krótkiego spadku trafień. W dużych witrynach stosuje się kolejki purge oraz harmonogramy, aby nie przeciążyć warstwy brzegowej lawiną czyszczeń.

Zaawansowane techniki: mikrobrowsery i prerendering HTML w cache, ESI (Edge Side Includes) do składania strony z fragmentów o różnych politykach, warianty językowe i regionalne przez Vary: Accept-Language/Geo, uwzględnienie stale-while-revalidate przy SSR, „key normalization” z wycinaniem śledzących parametrów UTM, a nawet adaptacyjne TTL w zależności od pory dnia i aktywności edytorskiej. Pamiętaj również o spójności z polityką bezpieczeństwa: podpisywane URL-e dla zasobów prywatnych, ochrona przed cache poisoning (walidacja wartości nagłówków wpływających na klucz), twarde limity wielkości obiektu i kontrola zakresowych zapytań (Range) dla mediów.

Po stronie narzędzi monitoruj wskaźniki per ścieżka i region: współczynnik trafień, TTFB, czas dopełnienia transferu, odsetek błędów i uderzeń w źródło. Utrzymuj dashboard z korelacją wydawniczych zdarzeń (publikacje, deploye) z telemetrią – ułatwia to kalibrację TTL i szybkość purge. Wreszcie – postaraj się odróżnić politykę cache dla użytkowników zalogowanych i niezalogowanych; dla tych pierwszych rozważ „keyed by session” jedynie dla wąskich fragmentów danych, a nie dla całego dokumentu HTML, aby nie zdegradować pamięci podręcznej.

Wyzwania, ryzyka i aspekty bezpieczeństwa

Edge caching to kompromisy. Zbyt długi TTL prowadzi do starzenia treści, zbyt krótki – do niskiego współczynnika trafień i wysokiego obciążenia originu. Drobne błędy w kluczu (np. nieuwzględnienie istotnego nagłówka) mogą spowodować mieszanie treści między wariantami lub pominąć ważne rozróżnienia (np. język, waluta). Z drugiej strony nadmierne różnicowanie klucza prowadzi do eksplozji wariantów i spadku efektywności.

Ryzyko „cache stampede” pojawia się, gdy popularny obiekt jednocześnie traci świeżość i wiele brzegu żąda odświeżenia. Rozwiązaniem są mechanizmy single-flight/coalescing (jeden odświeża, reszta czeka), tiered caching z „shieldem”, oraz polityki stale-while-revalidate. Zjawisko „thundering herd” może też dotyczyć invalidacji masowych – sekwencjonuj czyszczenia i stosuj soft purge, a w komponentach backendowych wprowadź niewielką losowość (jitter) do TTL, aby uniknąć skorelowanych wygaszeń.

Bezpieczeństwo obejmuje dwa główne obszary: integralność i prywatność. Edge nie powinien buforować odpowiedzi zawierających dane prywatne identyfikowane przez nagłówki Set-Cookie lub inne znaczniki sesji, chyba że klucz uwzględnia identyfikator i istnieją dodatkowe zabezpieczenia. Ataki na cache (poisoning) wykorzystują fakt, że parametry zapytania lub nagłówki wpływają na klucz – waliduj je i normalizuj. Dla zasobów wrażliwych stosuj podpisywane adresy (np. signed URL z wygasaniem) i weryfikację po stronie brzegu, a także mechanizmy autoryzacji skracające okno dostępu. Nie zapominaj o konsekwencjach CORS: nagłówki odpowiedzi muszą być spójne z polityką cache, aby nie udostępniać przypadkiem zasobów w szerszym kontekście niż zamierzony.

Wreszcie, w dynamicznych serwisach personalizacja bywa napięta wobec buforowania. Rozwiązaniem jest fragmentacja: buforuj trzon HTML i statyki, a elementy personalizowane dosyłaj jako niezależne żądania API (ESI, klientowe fetch, lub serwerowe wtrącenie o krótkim TTL). Alternatywnie używaj edge compute do wstrzykiwania drobnych różnic bez rozbijania cache na miliardy wariantów. Rozważ też model prywatnej pamięci podręcznej przeglądarki (private, max-age) dla komponentów ściśle użytkownika, pozostawiając CDN-owi to, co wspólne.

Przykłady zastosowań i wzorce projektowe

W e‑commerce buforuje się katalog, strony produktowe i media, a koszyk, ceny w czasie rzeczywistym i dane konta pozostają dynamiczne. Klasyczny wzorzec to: dokument HTML z krótkim s-maxage i agresywnym stale-while-revalidate, zasoby statyczne z długim s-maxage i fingerprintingiem (immutable), obrazy transkodowane na brzegu do WebP/AVIF z vary na Accept. Aktualizacja opisów produktów wyzwala purge po tagu „product:{id}”.

W mediach i portalach informacyjnych – artykuły i listingi z krótkim TTL i częstym purge, elementy wspólne (logo, czcionki, CSS, runtime JS) z bardzo długim TTL. Dodatkowo streaming wideo korzysta z segmentacji HLS/DASH, gdzie edge cache przechowuje fragmenty strumienia, a walidacja odbywa się po manifeście. Wydarzenia na żywo wymagają niskiej latencji i dużej przepustowości – PoP-y blisko operatorów ostatniej mili odgrywają kluczową rolę.

Dla API wzorzec różni się subtelnościami. Tu ważny jest deterministyczny klucz (np. metoda, ścieżka, istotne parametry) oraz twardsze limity świeżości. Odpowiedzi można oznaczyć krótkim s-maxage (sekundy), z mechanizmami walidacji warunkowej i stale-if-error, co poprawia SLA w porywach ruchu. W finansach polityka może zakładać TTL rzędu setek milisekund–sekund dla notowań, ale wymaga bardzo sprawnego purge lub streamingu aktualizacji.

W aplikacjach SSR/SSG (Next.js, Nuxt, Remix) popularne są tryby „Incremental Static Regeneration” i „stale-while-revalidate”. HTML powstaje na żądanie i jest buforowany na brzegu – kolejne żądania trafiają w kopię, a odświeżenie odbywa się asynchronicznie. W połączeniu z tagami purge i webhookami z CMS otrzymujemy zwinny model publikacji bez nadmiernego obciążania źródeł. W SaaS wielodomenowych sens ma separacja klucza po hostach, a w personalizacji – mieszany model: elementy wspólne w cache, prywatne na kliencie lub przez krótkie, niebuforowane wywołania.

Nie można pominąć obrazów i czcionek: transformacje na brzegu i warianty zależne od rozdzielczości/formatu to dziś standard. Stosuj fingerprinting (np. nazwy plików z hashami) i „immutable”, aby wydłużyć czas życia i uprościć politykę aktualizacji. Dla PWA pamiętaj, że Service Worker to dodatkowy poziom cache – zgrywalność polityk (SW vs CDN vs przeglądarka) ma krytyczne znaczenie dla przewidywalności.

FAQ

Co dokładnie oznacza „CDN edge caching” w kontekście HTTP?
To buforowanie odpowiedzi HTTP w węzłach brzegowych CDN wedle polityk opisanych nagłówkami (Cache-Control, Surrogate-Control, ETag, Last-Modified), z rozróżnieniem świeżości, walidacji warunkowej i strategii odświeżania. Klucz pamięci decyduje, jakie warianty są utrzymywane, a mechanizmy purge – kiedy i jak są usuwane.
Czym różni się cache przeglądarki od edge cache CDN?
Cache przeglądarki jest prywatny i działa na urządzeniu użytkownika, CDN jest współdzielony i działa blisko użytkownika, ale w infrastrukturze dostawcy. CDN może stosować dłuższe okresy przechowywania (s-maxage), inne reguły (Surrogate-Control) i zaawansowane odświeżanie, co pozwala serwować treści wielu użytkownikom z jednej kopii.
Jakie nagłówki są kluczowe do sterowania edge cache?
Cache-Control (public/private, s-maxage, max-age, no-store, no-cache, stale-while-revalidate, stale-if-error), Surrogate-Control, ETag/Last-Modified wraz z If-None-Match/If-Modified-Since, a także Vary decydujący o wariantach. Dodatkowo polityki dostawcy (np. ignorowanie niektórych parametrów) oraz reguły na brzegu.
Co to jest klucz pamięci (cache key) i jak go projektować?
To zestaw atrybutów identyfikujących wariant odpowiedzi: host, ścieżka, istotne parametry, wybrane nagłówki (np. język), czasem metoda. Projektuj oszczędnie: tylko to, co wpływa na treść; normalizuj parametry; unikaj pełnego User-Agent; rozważ ignorowanie śledzących UTM; dla personalizacji używaj fragmentacji zamiast wprowadzania identyfikatora sesji do klucza całego dokumentu.
Czym jest TTL i jak dobrać jego wartość?
TTL to czas życia obiektu w cache. Dobieraj go według dynamiki treści i tolerancji starzenia: statyki z fingerprintingiem – bardzo długi; artykuły – minuty–godziny z purge po publikacji; API – sekundy z walidacją. Dodaj stale-while-revalidate, by zmniejszyć skoki opóźnień przy odświeżeniach.
Jak szybko odświeżyć treść po publikacji?
Użyj webhooków z CMS do wyzwolenia purge po tagach/URL, preferuj soft purge, aby utrzymać trafienia podczas odświeżania, i stosuj krótkie TTL w godzinach wzmożonych aktualizacji. Tiered caching z „shieldem” ograniczy liczbę żądań do źródła.
Czy dynamiczne strony i API można buforować?
Tak, selektywnie. Buforuj odpowiedzi deterministyczne przez krótki czas, stosuj warunkową walidację (ETag/Last-Modified), a elementy personalizowane dostarczaj osobno. W SSR korzystaj z trybów SWR/ISR i fragmentacji (ESI). W API dodaj twarde reguły dla metod i ścieżek.
Jak edge caching wpływa na SEO i Core Web Vitals?
Obniża TTFB i stabilizuje czas odpowiedzi, co poprawia LCP i ogólne wrażenia użytkownika. Roboty indeksujące szybciej pozyskują treść, a serwis może obsłużyć większą liczbę jednoczesnych crawlów bez degradacji.
Jakie są najczęstsze błędy konfiguracyjne?
Zbyt krótki lub zbyt długi TTL, brak rozróżnienia wariantów (Vary), niekontrolowane cookies, błędny klucz, mylne rozumienie no-cache/no-store, brak mechanizmu purge i telemetrii, a także brak koordynacji między CDN a Service Workerem.
Czy edge cache może zaszkodzić bezpieczeństwu?
Tak, jeśli nieopatrznie zbuforuje dane prywatne lub jeśli dojdzie do cache poisoning. Ogranicz buforowanie odpowiedzi z wrażliwymi nagłówkami, waliduj wejście do klucza, używaj podpisywanych URL-i i zabezpiecz polityki CORS. W razie wątpliwości stosuj private/no-store.
Czym jest stale-while-revalidate i kiedy go używać?
To strategia serwowania lekko przeterminowanej kopii przy równoczesnym odświeżeniu w tle. Stosuj, gdy akceptujesz minimalną nieświeżość w zamian za płynność i mniejsze skoki opóźnień, np. w artykułach, listach, niekrytycznych API.
Jak mierzyć skuteczność edge cache?
Monitoruj cache hit ratio per ścieżka/region, TTFB, odsetek stale served, origin offload (ile żądań nie trafia do źródła), błędy i czas walidacji. Koreluj to ze zmianami publikacyjnymi i kampaniami ruchu, by kalibrować reguły.
Jak podejść do wersjonowania zasobów statycznych?
Stosuj fingerprinting (hash w nazwie), ustaw bardzo długie s-maxage i immutable. Zmiana treści zmienia hash, więc nie wymaga purge – stare wersje wygasają naturalnie, a przeglądarki i CDN natychmiast pobierają nową wersję po aktualizacji odnośników.
Czy HTTP/3 ma znaczenie dla edge caching?
Tak, skraca czas zestawiania połączeń i poprawia odporność na utraty pakietów, co w połączeniu z lokalnością brzegu obniża czas odpowiedzi zwłaszcza w sieciach mobilnych. Edge kończy QUIC blisko użytkownika, a dalej komunikuje się z originem po zoptymalizowanej ścieżce.
Jak łączyć Service Workera z CDN?
Zachowaj spójność polityk: to, co wspólne, zostaw CDN-owi; to, co ściśle prywatne lub offline-first – w SW. Unikaj sytuacji, gdzie SW nadpisuje politykę i wymusza odświeżanie każdorazowo, niwecząc korzyści z CDN. Dokumentuj priorytety i porządek źródeł.
Co to jest tiered caching i kiedy go używać?
To dodatkowa warstwa pośrednia (shield) gromadząca gorący zestaw obiektów, do którego odwołują się węzły brzegowe zamiast originu. Zwiększa to trafienia i zmniejsza liczbę żądań do źródła w skali globalnej. Stosuj przy dużym zasięgu geograficznym i wysokiej popularności wspólnych zasobów.