Cache i CDN dla sklepu - jak skrócić czas odpowiedzi bez psucia koszyka

Cache i CDN skracają czas odpowiedzi sklepu, gdy pliki statyczne i strony katalogu są podawane z pamięci podręcznej - przeglądarki, serwerów CDN albo serwera sklepu - a koszyk, zamówienie, konto klienta i każda odpowiedź z danymi konkretnej osoby zawsze trafiają do aplikacji. Żeby nie zepsuć koszyka, potrzebne są trzy rzeczy: poprawne nagłówki Cache-Control, wyjątki dla ciasteczek sesji i koszyka oraz automatyczne czyszczenie cache po zmianie cen i stanów.

W tym wpisie patrzymy na cache i CDN od strony programisty: jak sklep komunikuje serwerom pośredniczącym, co wolno zapisać, jak ustawić wyjątki, jak czyścić pamięć podręczną z poziomu integracji i jak sprawdzić, czy wszystko działa. Przykłady konfiguracji CDN opieramy na dokumentacji Cloudflare, ale zasady dotyczą każdego dostawcy i każdej platformy na własnym serwerze.

[#wazne] W skrócie: CDN i cache w sklepie przyspieszają pierwszą odpowiedź serwera, jeśli zapisują tylko to, co jest wspólne dla wszystkich klientów. Strony katalogu mogą trafić do cache dla anonimowych odwiedzających, ale koszyk, checkout i konto - nigdy. Sklep steruje tym nagłówkami Cache-Control i Set-Cookie, a CDN regułami omijania cache dla ciasteczek sesji. Ceny i stany po aktualizacji z ERP lub integratora wymagają czyszczenia cache po adresie lub tagu. Programiści Vinson konfigurują cache i CDN w sklepach oraz łączą czyszczenie pamięci podręcznej z integracjami.

Cache i CDN w sklepie - co to jest i gdzie działa

Cache, czyli pamięć podręczna, to zapisana kopia odpowiedzi, którą można oddać kolejnemu odwiedzającemu bez ponownego liczenia jej przez aplikację. CDN to sieć serwerów rozmieszczonych bliżej klientów, które pośredniczą w ruchu do sklepu i przechowują kopie plików, a czasem całych stron. W sklepie internetowym pamięć podręczna działa zwykle na kilku poziomach naraz: w przeglądarce klienta, na serwerach CDN, na serwerze sklepu (np. reverse proxy) i wewnątrz aplikacji jako cache obiektów i zapytań do bazy.

Każda warstwa ma inne zasady i inaczej się ją czyści, dlatego problemy z koszykiem często wynikają z tego, że jedna z nich działa według innych reguł niż pozostałe. Szczegóły wtyczek i wykluczeń dla sklepu na WordPressie opisaliśmy we wpisie cache w WooCommerce - jak ustawić pamięć podręczną bez psucia koszyka. Tutaj skupiamy się na tym, co dzieje się na styku sklepu i CDN. Tak wygląda droga pojedynczego żądania:

[#chart:wpr87a]

Z punktu widzenia wydajności najważniejszy jest czas do pierwszego bajtu odpowiedzi (TTFB), bo od niego zaczyna się ładowanie każdej strony. Web.dev wśród sposobów na jego skrócenie wymienia korzystanie z CDN, ograniczanie przekierowań i unikanie unikalnych parametrów w adresach, np. dodawanych przez narzędzia analityczne, które uniemożliwiają podanie strony z pamięci CDN. To ostatnie ma w sklepie duże znaczenie, bo ruch z kampanii reklamowych niemal zawsze niesie takie parametry.

Nagłówki Cache-Control - jak sklep mówi CDN, co wolno zapisać

Podstawowym narzędziem programisty jest nagłówek Cache-Control w odpowiedzi serwera. To on informuje przeglądarkę i serwery pośredniczące, czy odpowiedź można zapisać, na jak długo i komu ją oddać. Najważniejsze dyrektywy według dokumentacji MDN:

Dyrektywa	Co oznacza	Gdzie w sklepie
max-age=N	odpowiedź jest świeża przez N sekund	pliki statyczne, krótko także strony katalogu
s-maxage=N	czas świeżości tylko dla pamięci współdzielonych, np. CDN	strony katalogu dla anonimowych klientów
private	zapis tylko w pamięci przeglądarki użytkownika	strony po zalogowaniu
no-store	żadna pamięć podręczna nie może zapisać odpowiedzi	koszyk, checkout, konto, odpowiedzi API z danymi klienta
no-cache	można zapisać, ale przed użyciem trzeba sprawdzić aktualność	zasoby, które muszą być zawsze aktualne
stale-while-revalidate=N	wolno podać starszą wersję, odświeżając ją w tle	kategorie i karty produktów
stale-if-error=N	wolno podać starszą wersję przy błędzie serwera	katalog w czasie awarii aplikacji
immutable	plik nie zmieni się, dopóki jest świeży	pliki CSS i JS z wersją lub skrótem w nazwie

Warto pamiętać o rozróżnieniu, które MDN podkreśla wprost: no-cache nie oznacza „nie zapisuj”. Jeśli odpowiedź nie może trafić do żadnej pamięci, właściwą dyrektywą jest no-store. Cloudflare z kolei według swojej dokumentacji domyślnie nie zapisuje HTML ani JSON, a pliki statyczne rozpoznaje po rozszerzeniu, np. CSS, JS, JPG, WEBP czy WOFF2. Nie zapisuje też odpowiedzi z nagłówkiem Cache-Control o wartości private, no-store, no-cache lub max-age=0 ani odpowiedzi z nagłówkiem Set-Cookie (stan na sierpień 2026 - sprawdź aktualną dokumentację Cloudflare).

[#uwaga] Jedna wtyczka lub moduł, który ustawia ciasteczko na każdej stronie, np. do śledzenia lub testów A/B, potrafi wyłączyć cache całego katalogu, bo odpowiedzi z Set-Cookie nie trafiają do pamięci CDN. Zanim zaczniesz konfigurować reguły, sprawdź nagłówki odpowiedzi kilku kart produktów w oknie prywatnym.

Cache i CDN skracają czas odpowiedzi sklepu, gdy pliki statyczne i strony katalogu są podawane z pamięci podręcznej - przeglądarki, serwerów CDN albo serwera sklepu - a koszyk, zamówienie, konto klienta i każda odpowiedź z danymi konkretnej osoby zawsze trafiają do aplikacji. Żeby nie zepsuć koszyka, potrzebne są trzy rzeczy: poprawne nagłówki Cache-Control, wyjątki dla ciasteczek sesji i koszyka oraz automatyczne czyszczenie cache po zmianie cen i stanów.

W tym wpisie patrzymy na cache i CDN od strony programisty: jak sklep komunikuje serwerom pośredniczącym, co wolno zapisać, jak ustawić wyjątki, jak czyścić pamięć podręczną z poziomu integracji i jak sprawdzić, czy wszystko działa. Przykłady konfiguracji CDN opieramy na dokumentacji Cloudflare, ale zasady dotyczą każdego dostawcy i każdej platformy na własnym serwerze.

[#wazne] W skrócie: CDN i cache w sklepie przyspieszają pierwszą odpowiedź serwera, jeśli zapisują tylko to, co jest wspólne dla wszystkich klientów. Strony katalogu mogą trafić do cache dla anonimowych odwiedzających, ale koszyk, checkout i konto - nigdy. Sklep steruje tym nagłówkami Cache-Control i Set-Cookie, a CDN regułami omijania cache dla ciasteczek sesji. Ceny i stany po aktualizacji z ERP lub integratora wymagają czyszczenia cache po adresie lub tagu. Programiści Vinson konfigurują cache i CDN w sklepach oraz łączą czyszczenie pamięci podręcznej z integracjami.

Cache i CDN w sklepie - co to jest i gdzie działa

Cache, czyli pamięć podręczna, to zapisana kopia odpowiedzi, którą można oddać kolejnemu odwiedzającemu bez ponownego liczenia jej przez aplikację. CDN to sieć serwerów rozmieszczonych bliżej klientów, które pośredniczą w ruchu do sklepu i przechowują kopie plików, a czasem całych stron. W sklepie internetowym pamięć podręczna działa zwykle na kilku poziomach naraz: w przeglądarce klienta, na serwerach CDN, na serwerze sklepu (np. reverse proxy) i wewnątrz aplikacji jako cache obiektów i zapytań do bazy.

Każda warstwa ma inne zasady i inaczej się ją czyści, dlatego problemy z koszykiem często wynikają z tego, że jedna z nich działa według innych reguł niż pozostałe. Szczegóły wtyczek i wykluczeń dla sklepu na WordPressie opisaliśmy we wpisie cache w WooCommerce - jak ustawić pamięć podręczną bez psucia koszyka. Tutaj skupiamy się na tym, co dzieje się na styku sklepu i CDN. Tak wygląda droga pojedynczego żądania:

[#chart:wpr87a]

Z punktu widzenia wydajności najważniejszy jest czas do pierwszego bajtu odpowiedzi (TTFB), bo od niego zaczyna się ładowanie każdej strony. Web.dev wśród sposobów na jego skrócenie wymienia korzystanie z CDN, ograniczanie przekierowań i unikanie unikalnych parametrów w adresach, np. dodawanych przez narzędzia analityczne, które uniemożliwiają podanie strony z pamięci CDN. To ostatnie ma w sklepie duże znaczenie, bo ruch z kampanii reklamowych niemal zawsze niesie takie parametry.

Nagłówki Cache-Control - jak sklep mówi CDN, co wolno zapisać

Podstawowym narzędziem programisty jest nagłówek Cache-Control w odpowiedzi serwera. To on informuje przeglądarkę i serwery pośredniczące, czy odpowiedź można zapisać, na jak długo i komu ją oddać. Najważniejsze dyrektywy według dokumentacji MDN:

Dyrektywa	Co oznacza	Gdzie w sklepie
max-age=N	odpowiedź jest świeża przez N sekund	pliki statyczne, krótko także strony katalogu
s-maxage=N	czas świeżości tylko dla pamięci współdzielonych, np. CDN	strony katalogu dla anonimowych klientów
private	zapis tylko w pamięci przeglądarki użytkownika	strony po zalogowaniu
no-store	żadna pamięć podręczna nie może zapisać odpowiedzi	koszyk, checkout, konto, odpowiedzi API z danymi klienta
no-cache	można zapisać, ale przed użyciem trzeba sprawdzić aktualność	zasoby, które muszą być zawsze aktualne
stale-while-revalidate=N	wolno podać starszą wersję, odświeżając ją w tle	kategorie i karty produktów
stale-if-error=N	wolno podać starszą wersję przy błędzie serwera	katalog w czasie awarii aplikacji
immutable	plik nie zmieni się, dopóki jest świeży	pliki CSS i JS z wersją lub skrótem w nazwie

Warto pamiętać o rozróżnieniu, które MDN podkreśla wprost: no-cache nie oznacza „nie zapisuj”. Jeśli odpowiedź nie może trafić do żadnej pamięci, właściwą dyrektywą jest no-store. Cloudflare z kolei według swojej dokumentacji domyślnie nie zapisuje HTML ani JSON, a pliki statyczne rozpoznaje po rozszerzeniu, np. CSS, JS, JPG, WEBP czy WOFF2. Nie zapisuje też odpowiedzi z nagłówkiem Cache-Control o wartości private, no-store, no-cache lub max-age=0 ani odpowiedzi z nagłówkiem Set-Cookie (stan na sierpień 2026 - sprawdź aktualną dokumentację Cloudflare).

[#uwaga] Jedna wtyczka lub moduł, który ustawia ciasteczko na każdej stronie, np. do śledzenia lub testów A/B, potrafi wyłączyć cache całego katalogu, bo odpowiedzi z Set-Cookie nie trafiają do pamięci CDN. Zanim zaczniesz konfigurować reguły, sprawdź nagłówki odpowiedzi kilku kart produktów w oknie prywatnym.

Cache stron katalogu na CDN - jak nie psuć koszyka

Zapis HTML na serwerach CDN daje największy zysk, bo klient dostaje gotową stronę bez czekania na aplikację. Jednocześnie to on najczęściej psuje sklep, jeśli brakuje wyjątków. Bezpieczna zasada brzmi: strony katalogu trafiają do cache tylko dla anonimowych odwiedzających, a każdy, kto ma ciasteczko sesji, koszyka lub logowania, dostaje stronę generowaną na bieżąco. W Cloudflare takie warunki buduje się w regułach cache, a pole ciasteczka (http.cookie) jest dostępne w kreatorze wyrażeń. Ciasteczka jako element własnego klucza cache dokumentacja wymienia natomiast jako opcję planu Enterprise (stan na sierpień 2026 - sprawdź aktualną dokumentację Cloudflare). Z cache zawsze wyłącz:

koszyk, zamówienie, konto klienta i ich przetłumaczone adresy używane w sklepie,
żądania z parametrem dodania do koszyka i inne adresy wywołujące akcję,
panel administracyjny i adresy logowania,
punkty API, webhooki, powiadomienia z bramek płatności i feedy dla integracji,
odwiedzających z ciasteczkiem sesji, koszyka lub zalogowanego klienta.

Elementy, które muszą być aktualne na każdej stronie, np. licznik koszyka w nagłówku albo ceny dla zalogowanej grupy klientów B2B, nie powinny być częścią zapisanego HTML. Lepiej doładować je osobnym żądaniem, które omija cache, a resztę strony podać z pamięci podręcznej. Ten sam problem dotyczy cen indywidualnych i walut: jeśli sklep pokazuje różne ceny zależnie od klienta lub kraju, zapisana strona pokaże wszystkim wariant pierwszego odwiedzającego. Zanim włączysz cache HTML, odpowiedz sobie na kilka pytań:

[#chart:wpr87b]

Czyszczenie cache po zmianie ceny i stanu z integracji

Największe ryzyko cache w sklepie to nie cudzy koszyk, tylko nieaktualna oferta: stara cena w promocji albo produkt pokazany jako dostępny, choć integracja z magazynem zdjęła go ze stanu. Wtyczki i moduły zwykle czyszczą cache po edycji produktu w panelu, ale nie zawsze widzą zmiany zapisane bezpośrednio w bazie przez ERP, integratora czy import z hurtowni. Rozwiązania są trzy: krótki czas życia stron katalogu z dyrektywą stale-while-revalidate, czyszczenie konkretnych adresów po aktualizacji oraz czyszczenie po tagach.

Cloudflare udostępnia czyszczenie pojedynczych adresów, całej strefy, po tagach, po nazwie hosta i po prefiksie adresu, według dokumentacji we wszystkich planach. Limity zależą od planu: w planie Free czyszczenie po tagach, hoście, prefiksie lub całości to 5 żądań na minutę, a czyszczenie pojedynczych adresów - do 800 adresów na sekundę, przy maksymalnie 100 elementach w jednym żądaniu (stan na sierpień 2026 - sprawdź aktualną dokumentację Cloudflare). Tagi serwer sklepu dodaje w nagłówku odpowiedzi Cache-Tag, np. identyfikator produktu i kategorii. Cloudflare usuwa ten nagłówek przed wysłaniem strony klientowi, a łączny rozmiar tagów w odpowiedzi nie może przekroczyć 16 KB.

W praktyce czyszczenie warto uruchamiać zdarzeniem z integracji, a nie ręcznie. Sklep lub integrator wysyła powiadomienie o zmianie produktu, a mała usługa wywołuje API CDN - zasady bezpiecznego odbierania takich powiadomień opisujemy we wpisie webhooki w e-commerce - do czego służą i jak je wdrożyć. Przykładowy przepływ:

Integracja zapisuje nową cenę lub stan produktu w sklepie.
Sklep wysyła webhook o aktualizacji produktu albo integracja sama zgłasza zmianę.
Usługa zbiera zmiany z kilku sekund w jedną paczkę, żeby nie przekroczyć limitu żądań.
Usługa czyści tag produktu i tagi jego kategorii w CDN oraz zapisuje wynik w logu.
Przy błędzie API próbuje ponownie z opóźnieniem, a po kilku nieudanych próbach wysyła alert.

Jak sprawdzić, czy cache i CDN działają

Najprostsze źródło wiedzy to nagłówki odpowiedzi. Cloudflare dodaje nagłówek cf-cache-status, którego wartości według dokumentacji oznaczają m.in.: HIT - odpowiedź z cache, MISS - zasobu nie było w cache, więc podał go serwer, EXPIRED - kopia wygasła i pobrano nową, BYPASS - odpowiedź nie mogła trafić do cache, np. przez no-store, private lub Set-Cookie, DYNAMIC - zasób z założenia nie podlega cache, oraz UPDATING - podano starszą kopię, odświeżając ją w tle. Sprawdzaj je w narzędziach deweloperskich przeglądarki dla każdego typu strony: jako anonimowy klient, z produktem w koszyku i po zalogowaniu.

Drugim narzędziem jest wskaźnik trafień, czyli odsetek żądań obsłużonych z pamięci podręcznej. Liczy się go dla zasobów, które mogą trafić do cache:

[#chart:wpr87c]

Niski wskaźnik przy stronach katalogu ma zwykle trzy przyczyny: parametry kampanii w adresach tworzące osobne kopie tej samej strony, ciasteczka ustawiane na każdej odpowiedzi oraz zbyt krótki czas życia. Każdą z nich rozwiązuje się inaczej, dlatego warto przejrzeć statystyki w panelu CDN osobno dla HTML, zdjęć i plików CSS oraz JS.

Pliki statyczne - długi cache i wersje w nazwach

Zdjęcia, arkusze stylów, skrypty i czcionki to większość danych pobieranych przy pierwszej wizycie. Im dłużej mogą leżeć w pamięci przeglądarki i CDN, tym szybciej ładują się kolejne podstrony. Problem pojawia się po aktualizacji motywu: jeśli plik ma tę samą nazwę, klient przez długi czas może dostawać starą wersję stylów do nowego HTML. Rozwiązaniem jest wersjonowanie, czyli dodawanie do nazwy pliku skrótu zawartości lub numeru wersji przy każdym wdrożeniu. Wtedy plik może mieć długi czas życia i dyrektywę immutable, bo każda zmiana tworzy nowy adres. Wiele platform i narzędzi do budowania frontu robi to automatycznie, ale w motywach pisanych ręcznie warto to sprawdzić.

Typowe błędy konfiguracji cache i CDN w sklepie

Większość awarii po wdrożeniu CDN wynika z kilku powtarzalnych błędów. Pierwszy to reguła zapisująca całe strony bez wyjątków dla ciasteczek, przez którą klienci widzą cudzy licznik koszyka albo komunikaty. Drugi to dwie warstwy cache stron, np. moduł w sklepie i reguła w CDN, z różnymi zasadami czyszczenia - wtedy wyczyszczenie jednej z nich nic nie zmienia. Trzeci to ochrona przed botami lub wyzwania stosowane także do adresów API, przez które bramka płatności nie może potwierdzić zamówienia, a integrator nie pobiera zamówień. Czwarty to zbyt długi czas życia stron katalogu bez mechanizmu czyszczenia, który kończy się nieaktualnymi cenami w czasie promocji. Każdy z tych błędów wychodzi w testach, jeśli po zmianie konfiguracji przejdziesz pełną ścieżkę zakupu i sprawdzisz integracje.

Cache i CDN na Shopify, Shoperze i własnym serwerze

Platformy abonamentowe, takie jak Shopify czy Shoper, mają własną infrastrukturę i CDN, więc programista wpływa głównie na zasoby motywu, zdjęcia i skrypty zewnętrzne. Dodawanie własnego CDN jako pośrednika przed taką platformą zwykle nie ma sensu i warto to sprawdzić w jej dokumentacji. Najwięcej pracy i najwięcej możliwości jest przy sklepach na własnym serwerze, np. WooCommerce i PrestaShop. Zanim jednak zaczniesz zmieniać konfigurację, zmierz, czy problemem rzeczywiście jest czas odpowiedzi serwera - jak to zrobić, opisujemy w tekście wydajność sklepu internetowego - jak zmierzyć i przyspieszyć ładowanie.

[#checklista] Po każdej zmianie konfiguracji cache i CDN sprawdź: nagłówki kart produktów jako anonimowy klient, nagłówki po dodaniu produktu do koszyka, koszyk i checkout z płatnością testową, logowanie i reset hasła, aktualizację ceny z integracji i jej widoczność w kategorii, powiadomienia z bramki płatności oraz dostęp integratora do API i feedów.

Jak Vinson pomaga z cache i CDN w sklepie

Zapewniamy wsparcie programistyczne dla sklepów i sprzedawców: integracje, automatyzacje, poprawki i rozwój sklepów oraz narzędzi. Przy cache i CDN ustawiamy nagłówki odpowiedzi w sklepie, reguły omijania pamięci podręcznej dla koszyka, konta i API, wydzielamy dynamiczne elementy stron i łączymy czyszczenie cache z integracjami, żeby nowe ceny i stany od razu były widoczne dla klientów. Szczegóły znajdziesz na stronie Wsparcie programistyczne dla e-commerce.

Najczęściej zadawane pytania

Czy CDN przyspieszy każdy sklep internetowy?

Nie każdy w tym samym stopniu. CDN skraca drogę plików statycznych do klienta i odciąża serwer, ale jeśli sklep jest wolny przez ciężki motyw, skrypty lub wolną bazę danych, sam CDN tego nie naprawi. Najpierw zmierz, która część ładowania trwa najdłużej.

Czy strony sklepu można trzymać w cache CDN?

Strony katalogu - tak, ale tylko dla anonimowych odwiedzających i z regułami omijania cache dla ciasteczek sesji, koszyka i logowania. Koszyk, checkout, konto klienta i odpowiedzi API z danymi klienta nie mogą trafiać do pamięci współdzielonej.

Jaka jest różnica między no-cache a no-store?

Według MDN no-cache pozwala zapisać odpowiedź, ale wymaga sprawdzenia jej aktualności przed każdym użyciem. No-store zabrania zapisu w jakiejkolwiek pamięci podręcznej. Dla koszyka i danych klienta właściwy jest no-store.

Dlaczego po zmianie ceny klient widzi starą cenę?

Najczęściej strona produktu lub kategorii jest w cache, a zmiana przyszła z integracji, której wtyczka cache nie zauważyła. Rozwiązaniem jest czyszczenie cache po adresie lub tagu uruchamiane po każdej aktualizacji z ERP lub integratora albo krótszy czas życia stron katalogu.

Jak sprawdzić, czy strona sklepu pochodzi z cache Cloudflare?

Otwórz narzędzia deweloperskie przeglądarki, zakładkę sieci, i sprawdź nagłówek cf-cache-status w odpowiedzi. Wartość HIT oznacza odpowiedź z cache, MISS i EXPIRED - pobranie z serwera, a BYPASS lub DYNAMIC - że odpowiedź nie trafia do pamięci podręcznej.

Dobrze ustawiony cache i CDN skracają czas odpowiedzi sklepu, a koszyk, płatności i aktualne ceny zostawiają nietknięte. Jeśli chcesz uporządkować nagłówki, reguły CDN i czyszczenie pamięci podręcznej po zmianach z integracji, sprawdź wsparcie programistyczne Vinson.

Cache stron katalogu na CDN - jak nie psuć koszyka

Zapis HTML na serwerach CDN daje największy zysk, bo klient dostaje gotową stronę bez czekania na aplikację. Jednocześnie to on najczęściej psuje sklep, jeśli brakuje wyjątków. Bezpieczna zasada brzmi: strony katalogu trafiają do cache tylko dla anonimowych odwiedzających, a każdy, kto ma ciasteczko sesji, koszyka lub logowania, dostaje stronę generowaną na bieżąco. W Cloudflare takie warunki buduje się w regułach cache, a pole ciasteczka (http.cookie) jest dostępne w kreatorze wyrażeń. Ciasteczka jako element własnego klucza cache dokumentacja wymienia natomiast jako opcję planu Enterprise (stan na sierpień 2026 - sprawdź aktualną dokumentację Cloudflare). Z cache zawsze wyłącz:

koszyk, zamówienie, konto klienta i ich przetłumaczone adresy używane w sklepie,
żądania z parametrem dodania do koszyka i inne adresy wywołujące akcję,
panel administracyjny i adresy logowania,
punkty API, webhooki, powiadomienia z bramek płatności i feedy dla integracji,
odwiedzających z ciasteczkiem sesji, koszyka lub zalogowanego klienta.

Elementy, które muszą być aktualne na każdej stronie, np. licznik koszyka w nagłówku albo ceny dla zalogowanej grupy klientów B2B, nie powinny być częścią zapisanego HTML. Lepiej doładować je osobnym żądaniem, które omija cache, a resztę strony podać z pamięci podręcznej. Ten sam problem dotyczy cen indywidualnych i walut: jeśli sklep pokazuje różne ceny zależnie od klienta lub kraju, zapisana strona pokaże wszystkim wariant pierwszego odwiedzającego. Zanim włączysz cache HTML, odpowiedz sobie na kilka pytań:

[#chart:wpr87b]

Czyszczenie cache po zmianie ceny i stanu z integracji

Największe ryzyko cache w sklepie to nie cudzy koszyk, tylko nieaktualna oferta: stara cena w promocji albo produkt pokazany jako dostępny, choć integracja z magazynem zdjęła go ze stanu. Wtyczki i moduły zwykle czyszczą cache po edycji produktu w panelu, ale nie zawsze widzą zmiany zapisane bezpośrednio w bazie przez ERP, integratora czy import z hurtowni. Rozwiązania są trzy: krótki czas życia stron katalogu z dyrektywą stale-while-revalidate, czyszczenie konkretnych adresów po aktualizacji oraz czyszczenie po tagach.

Cloudflare udostępnia czyszczenie pojedynczych adresów, całej strefy, po tagach, po nazwie hosta i po prefiksie adresu, według dokumentacji we wszystkich planach. Limity zależą od planu: w planie Free czyszczenie po tagach, hoście, prefiksie lub całości to 5 żądań na minutę, a czyszczenie pojedynczych adresów - do 800 adresów na sekundę, przy maksymalnie 100 elementach w jednym żądaniu (stan na sierpień 2026 - sprawdź aktualną dokumentację Cloudflare). Tagi serwer sklepu dodaje w nagłówku odpowiedzi Cache-Tag, np. identyfikator produktu i kategorii. Cloudflare usuwa ten nagłówek przed wysłaniem strony klientowi, a łączny rozmiar tagów w odpowiedzi nie może przekroczyć 16 KB.

W praktyce czyszczenie warto uruchamiać zdarzeniem z integracji, a nie ręcznie. Sklep lub integrator wysyła powiadomienie o zmianie produktu, a mała usługa wywołuje API CDN - zasady bezpiecznego odbierania takich powiadomień opisujemy we wpisie webhooki w e-commerce - do czego służą i jak je wdrożyć. Przykładowy przepływ:

Integracja zapisuje nową cenę lub stan produktu w sklepie.
Sklep wysyła webhook o aktualizacji produktu albo integracja sama zgłasza zmianę.
Usługa zbiera zmiany z kilku sekund w jedną paczkę, żeby nie przekroczyć limitu żądań.
Usługa czyści tag produktu i tagi jego kategorii w CDN oraz zapisuje wynik w logu.
Przy błędzie API próbuje ponownie z opóźnieniem, a po kilku nieudanych próbach wysyła alert.

Jak sprawdzić, czy cache i CDN działają

Najprostsze źródło wiedzy to nagłówki odpowiedzi. Cloudflare dodaje nagłówek cf-cache-status, którego wartości według dokumentacji oznaczają m.in.: HIT - odpowiedź z cache, MISS - zasobu nie było w cache, więc podał go serwer, EXPIRED - kopia wygasła i pobrano nową, BYPASS - odpowiedź nie mogła trafić do cache, np. przez no-store, private lub Set-Cookie, DYNAMIC - zasób z założenia nie podlega cache, oraz UPDATING - podano starszą kopię, odświeżając ją w tle. Sprawdzaj je w narzędziach deweloperskich przeglądarki dla każdego typu strony: jako anonimowy klient, z produktem w koszyku i po zalogowaniu.

Drugim narzędziem jest wskaźnik trafień, czyli odsetek żądań obsłużonych z pamięci podręcznej. Liczy się go dla zasobów, które mogą trafić do cache:

[#chart:wpr87c]

Niski wskaźnik przy stronach katalogu ma zwykle trzy przyczyny: parametry kampanii w adresach tworzące osobne kopie tej samej strony, ciasteczka ustawiane na każdej odpowiedzi oraz zbyt krótki czas życia. Każdą z nich rozwiązuje się inaczej, dlatego warto przejrzeć statystyki w panelu CDN osobno dla HTML, zdjęć i plików CSS oraz JS.

Pliki statyczne - długi cache i wersje w nazwach

Zdjęcia, arkusze stylów, skrypty i czcionki to większość danych pobieranych przy pierwszej wizycie. Im dłużej mogą leżeć w pamięci przeglądarki i CDN, tym szybciej ładują się kolejne podstrony. Problem pojawia się po aktualizacji motywu: jeśli plik ma tę samą nazwę, klient przez długi czas może dostawać starą wersję stylów do nowego HTML. Rozwiązaniem jest wersjonowanie, czyli dodawanie do nazwy pliku skrótu zawartości lub numeru wersji przy każdym wdrożeniu. Wtedy plik może mieć długi czas życia i dyrektywę immutable, bo każda zmiana tworzy nowy adres. Wiele platform i narzędzi do budowania frontu robi to automatycznie, ale w motywach pisanych ręcznie warto to sprawdzić.

Typowe błędy konfiguracji cache i CDN w sklepie

Większość awarii po wdrożeniu CDN wynika z kilku powtarzalnych błędów. Pierwszy to reguła zapisująca całe strony bez wyjątków dla ciasteczek, przez którą klienci widzą cudzy licznik koszyka albo komunikaty. Drugi to dwie warstwy cache stron, np. moduł w sklepie i reguła w CDN, z różnymi zasadami czyszczenia - wtedy wyczyszczenie jednej z nich nic nie zmienia. Trzeci to ochrona przed botami lub wyzwania stosowane także do adresów API, przez które bramka płatności nie może potwierdzić zamówienia, a integrator nie pobiera zamówień. Czwarty to zbyt długi czas życia stron katalogu bez mechanizmu czyszczenia, który kończy się nieaktualnymi cenami w czasie promocji. Każdy z tych błędów wychodzi w testach, jeśli po zmianie konfiguracji przejdziesz pełną ścieżkę zakupu i sprawdzisz integracje.

Cache i CDN na Shopify, Shoperze i własnym serwerze

Platformy abonamentowe, takie jak Shopify czy Shoper, mają własną infrastrukturę i CDN, więc programista wpływa głównie na zasoby motywu, zdjęcia i skrypty zewnętrzne. Dodawanie własnego CDN jako pośrednika przed taką platformą zwykle nie ma sensu i warto to sprawdzić w jej dokumentacji. Najwięcej pracy i najwięcej możliwości jest przy sklepach na własnym serwerze, np. WooCommerce i PrestaShop. Zanim jednak zaczniesz zmieniać konfigurację, zmierz, czy problemem rzeczywiście jest czas odpowiedzi serwera - jak to zrobić, opisujemy w tekście wydajność sklepu internetowego - jak zmierzyć i przyspieszyć ładowanie.

[#checklista] Po każdej zmianie konfiguracji cache i CDN sprawdź: nagłówki kart produktów jako anonimowy klient, nagłówki po dodaniu produktu do koszyka, koszyk i checkout z płatnością testową, logowanie i reset hasła, aktualizację ceny z integracji i jej widoczność w kategorii, powiadomienia z bramki płatności oraz dostęp integratora do API i feedów.

Jak Vinson pomaga z cache i CDN w sklepie

Zapewniamy wsparcie programistyczne dla sklepów i sprzedawców: integracje, automatyzacje, poprawki i rozwój sklepów oraz narzędzi. Przy cache i CDN ustawiamy nagłówki odpowiedzi w sklepie, reguły omijania pamięci podręcznej dla koszyka, konta i API, wydzielamy dynamiczne elementy stron i łączymy czyszczenie cache z integracjami, żeby nowe ceny i stany od razu były widoczne dla klientów. Szczegóły znajdziesz na stronie Wsparcie programistyczne dla e-commerce.

Najczęściej zadawane pytania

Czy CDN przyspieszy każdy sklep internetowy?

Nie każdy w tym samym stopniu. CDN skraca drogę plików statycznych do klienta i odciąża serwer, ale jeśli sklep jest wolny przez ciężki motyw, skrypty lub wolną bazę danych, sam CDN tego nie naprawi. Najpierw zmierz, która część ładowania trwa najdłużej.

Czy strony sklepu można trzymać w cache CDN?

Strony katalogu - tak, ale tylko dla anonimowych odwiedzających i z regułami omijania cache dla ciasteczek sesji, koszyka i logowania. Koszyk, checkout, konto klienta i odpowiedzi API z danymi klienta nie mogą trafiać do pamięci współdzielonej.

Jaka jest różnica między no-cache a no-store?

Według MDN no-cache pozwala zapisać odpowiedź, ale wymaga sprawdzenia jej aktualności przed każdym użyciem. No-store zabrania zapisu w jakiejkolwiek pamięci podręcznej. Dla koszyka i danych klienta właściwy jest no-store.

Dlaczego po zmianie ceny klient widzi starą cenę?

Najczęściej strona produktu lub kategorii jest w cache, a zmiana przyszła z integracji, której wtyczka cache nie zauważyła. Rozwiązaniem jest czyszczenie cache po adresie lub tagu uruchamiane po każdej aktualizacji z ERP lub integratora albo krótszy czas życia stron katalogu.

Jak sprawdzić, czy strona sklepu pochodzi z cache Cloudflare?

Otwórz narzędzia deweloperskie przeglądarki, zakładkę sieci, i sprawdź nagłówek cf-cache-status w odpowiedzi. Wartość HIT oznacza odpowiedź z cache, MISS i EXPIRED - pobranie z serwera, a BYPASS lub DYNAMIC - że odpowiedź nie trafia do pamięci podręcznej.

Dobrze ustawiony cache i CDN skracają czas odpowiedzi sklepu, a koszyk, płatności i aktualne ceny zostawiają nietknięte. Jeśli chcesz uporządkować nagłówki, reguły CDN i czyszczenie pamięci podręcznej po zmianach z integracji, sprawdź wsparcie programistyczne Vinson.

Cache i CDN dla sklepu - jak skrócić czas odpowiedzi bez psucia koszyka