Czym jest CDN
Content Delivery Network to sieć serwerów rozstawionych w wielu miejscach świata, które przechowują kopie plików serwisu i wydają je z punktu położonego najbliżej pytającego. Zamiast jednej podróży przez pół Europy pliki pokonują kilkadziesiąt kilometrów. Brzmi to jak rozwiązanie problemu prędkości w całości. I tu zaczynają się nieporozumienia, bo z krawędzi sieci idzie zwykle mniej, niż się zakłada.
Lokalizacja serwera to sygnał, ale nierozstrzygający
Zanim przejdziemy do prędkości, zamknijmy wątek pozycji, bo krąży przekonanie, że serwer w kraju odbiorcy pomaga w wynikach lokalnych. Google wymienia lokalizację serwera wśród sygnałów geograficznych, ale sam ją relatywizuje: „Some websites use distributed content delivery networks (CDNs) or are hosted in a country with better webserver infrastructure, so it is not a definitive signal”.1
Zdanie to działa w obie strony. CDN faktycznie zaciera informację o tym, gdzie stoi serwer. Właśnie dlatego Google zastrzega, że nie traktuje jej rozstrzygająco. Wdrożenie takiej sieci nie zaszkodzi więc widoczności lokalnej, ale też jej nie zbuduje: robi to hosting o krótkim czasie odpowiedzi w połączeniu z treścią adresowaną do konkretnego rynku.
Co u nas naprawdę idzie z krawędzi sieci
Sprawdziliśmy 1 września 2026, co dokładnie obsługuje krawędź sieci na tym serwisie, a co wciąż wydaje serwer źródłowy.2 Wynik dzieli się na trzy wyraźne warstwy.
Dokument HTML nie jedzie z krawędzi ani razu. Każda odpowiedź wraca oznaczona jako treść dynamiczna. To, co realnie ratuje tu czas, siedzi na serwerze źródłowym: własna warstwa pamięci podręcznej, która przy pomiarze zwracała dokument z zapasu sprzed siedmiu minut.
Skrypty i style krawędź trzyma. Wszystkie sprawdzone pliki JavaScript i CSS wróciły z zapasu na krawędzi.
Obrazy — żaden. To znalezisko okazało się najciekawsze: każdy sprawdzony plik graficzny wracał z adnotacją o pominięciu pamięci podręcznej, i to zarówno przy pierwszym, jak i przy drugim pobraniu. Najcięższa część strony omija więc warstwę, którą wdraża się właśnie po to, żeby ciężkie pliki wędrowały krócej. Sam fakt posiadania takiej sieci niczego tu nie przesądza. Przesądza konfiguracja tego, co ma trafiać do zapasu.
Ile to warte w milisekundach
Różnicę da się zmierzyć wprost. Plik wydany z krawędzi wracał w 77–90 milisekund, dokument HTML wydany przez serwer źródłowy w 103–130.2 Zysk wynosi zatem około czterdziestu milisekund i dotyczy wyłącznie tych zasobów, które krawędź faktycznie trzyma.
Zestawmy to z progiem, jaki stawia się największemu elementowi strony: „sites should strive to have Largest Contentful Paint of 2.5 seconds or less”, mierzone na 75. percentylu wczytań.3 Czterdzieści milisekund to ułamek procenta tego budżetu. Sieć dostarczania treści przesuwa więc wskazówkę, ale nie przestawia zegara. A jeśli strona nie mieści się w progu, przyczyna prawie nigdy nie leży w odległości do serwera. Realny wpływ mają rozmiar plików, liczba żądań i to, co blokuje wyświetlenie; stąd sens ma zaczynanie od minifikacji, a nie od kolejnej warstwy sieciowej.
Drugi wniosek dotyczy geografii. Węzeł, który obsłużył nasze zapytania z Polski, znajdował się w Berlinie. Obecność takiej sieci nie gwarantuje więc, że ruch obsłuży punkt najbliższy, a to właśnie ta bliskość jest jedynym powodem, dla którego się ją wdraża.
Sprostowanie: to nie ma związku z przesuwaniem układu
Wcześniejsza wersja tego hasła twierdziła, że sieć dostarczania treści pomaga ustabilizować przesunięcia układu strony, „dzięki szybszemu ładowaniu elementów”. Sprawdziliśmy dokumentację tego wskaźnika: jako przyczyny wymienia obrazy i ramki bez podanych wymiarów oraz treść wstrzykiwaną dynamicznie.4 Prędkość sieci nie pada tam ani razu.
Mechanizm podany w naszym haśle był zmyślony, a nie tylko nieprecyzyjny. To dobry przykład na to, jak powstaje branżowa pewność: wystarczy połączyć dwie prawdziwe rzeczy zdaniem „dzięki temu”. Przesunięcia układu leczy się podawaniem wymiarów i rezerwowaniem miejsca, nie skracaniem drogi pakietów. Jak czytać sam pomiar, tłumaczy hasło o PageSpeed Insights, a szerzej — o szybkości strony.
Najczęstsze pytania
Czy CDN poprawia pozycje w wynikach?
Nie bezpośrednio. Zaciera sygnał lokalizacji serwera, który Google i tak opisuje jako nierozstrzygający.
Czy CDN przyspiesza wczytanie strony?
Tyle, ile wynosi różnica między krawędzią a serwerem: u nas około czterdziestu milisekund, i tylko dla plików faktycznie trzymanych na krawędzi.
Czy sama obecność CDN wystarczy?
Nie. Decyduje konfiguracja: u nas skrypty i style idą z krawędzi, a obrazy i dokument HTML nie.
Czy CDN zmniejsza przesunięcia układu strony?
Nie. Dokumentacja tego wskaźnika wymienia brak wymiarów obrazów i treść wstrzykiwaną dynamicznie, a prędkości sieci nie wspomina.
Źródła
1. Google Search Central, Managing multi-regional and multilingual sites — lokalizacja serwera jako sygnał geograficzny i zastrzeżenie wobec sieci dostarczania treści. developers.google.com/search/docs/specialty/international/managing-multi-regional-sites (odczyt 1.09.2026).
2. Pomiar własny z 1.09.2026: odczyt nagłówków odpowiedzi essaseo.pl dla dokumentu HTML, plików skryptów i stylów oraz plików graficznych, wraz z pomiarem czasu do pierwszego bajtu i odczytem węzła obsługującego zapytanie.
3. web.dev, Largest Contentful Paint (LCP) — próg 2,5 sekundy liczony na 75. percentylu wczytań. web.dev/articles/lcp (odczyt 1.09.2026).
4. web.dev, Optimize Cumulative Layout Shift — przyczyny przesunięć układu strony. web.dev/articles/optimize-cls (odczyt 1.09.2026).
Tadeusz Wolskizałożyciel ESSA SEO · 40+ zrealizowanych projektów · 5,0★ Google · 5,0★ Fiverr (30+ ocen)Zaktualizowano ⋅ 1 września 2026