Wdrożyłeś poprawkę. CI zielone. Deployment się powiódł. Odświeżasz stronę i widzisz stary build — ten sprzed godziny, z błędem, który właśnie naprawiłeś.
CDN serwuje cache. I nie pyta o zdanie.
Standardowe podejście: wyczyścić cache z panelu CDN, dodać query string do buildu, poczekać na inwalidację. Każde z nich działa — i każde wymaga albo dostępu do dashboardu CDN, albo zmiany w pipeline, albo czekania.
Header Modifier daje prostszą opcję: powiedz CDN żeby nie serwował cache dla tego konkretnego żądania z tej konkretnej przeglądarki. Bez dotykania konfiguracji serwera.
Dlaczego CDN ignoruje twój deployment
CDN cache działa na podstawie nagłówków odpowiedzi — serwer mówi CDN "to możesz cachować na N sekund" i CDN to szanuje. Kiedy wdrażasz nową wersję, CDN może nadal serwować stary plik przez całą tę żywotność cache'u.
Inwalidacja cache z panelu rozwiązuje problem globalnie. Ale podczas aktywnego testowania — kiedy wdrażasz cztery razy w ciągu godziny i sprawdzasz każdą zmianę — globalne czyścenie cache jest wolne i destrukcyjne dla innych.
Nagłówek Cache-Control: no-cache w żądaniu HTTP mówi serwerowi: "masz token na odpowiedź z cache'u, ale muszę ją zwalidować zanim użyję." W praktyce większość CDN to respektuje i pobiera świeżą odpowiedź ze źródła.
To jest nagłówek żądania — modyfikuje to, co Twoja przeglądarka wysyła do serwera, nie to, co serwer wysyła z powrotem. Header Modifier działa dokładnie w tej warstwie.
Konfiguracja reguł
Zainstaluj Header Modifier z Chrome Web Store — bezpłatne, bez konta, bez trackingu.
Otwórz panel reguł. Dodaj dwie reguły:
Reguła 1:
- Header name:
Cache-Control - Value:
no-cache, no-store - URL pattern:
https://cdn.twojadomena.com/*(lub jakkolwiek wygląda Twój staging CDN)
Reguła 2:
- Header name:
Pragma - Value:
no-cache - URL pattern: ten sam co powyżej
Pragma to relikt HTTP/1.0 — ale wciąż jest respektowany przez wiele warstw proxy i reverse proxy. Dodanie go razem z Cache-Control kosztuje nic.
Zakres URL — kluczowy szczegół
URL pattern decyduje o tym, do których żądań reguła się stosuje. Nie używaj * jako wzorca — to włącza regułę dla każdej strony w Chrome.
Wpisz dokładną domenę środowiska testowego: https://staging.twojadomena.com/* albo domenę CDN. Jeśli testujesz lokalnie z frontendem podpiętym pod zewnętrzny CDN, zawęź do tego konkretnego originu.
Cel jest prosty: reguła ma działać tylko tam, gdzie testujesz. Nie na produkcji, nie na stronach zewnętrznych.
Weryfikacja
Odśwież stronę z otwartymi DevTools (F12) → zakładka Network. Kliknij na żądanie do pliku JS lub CSS z CDN. W sekcji Request Headers powinno być widoczne cache-control: no-cache, no-store i pragma: no-cache.
Jeśli CDN respektuje te nagłówki, odpowiedź powinna mieć status 200 zamiast 304 i nagłówek Age: 0 lub całkowity brak Age. To znaczy, że pobierasz świeżą wersję ze źródła.
Jeśli nadal widzisz stary build — CDN prawdopodobnie ignoruje cache-control z klienta po swojej stronie. W takim przypadku konieczna jest ręczna inwalidacja z panelu CDN lub dodanie wersjonowania do nazw plików buildu.
Master Switch — szybkie wyłączenie
Header Modifier ma główny wyłącznik, który dezaktywuje wszystkie reguły jednocześnie bez ich usuwania. Przydatne, kiedy skończyłeś testować i chcesz wrócić do normalnego zachowania przeglądarki.
Reguły zostają zapisane w Chrome sync storage — przetrwają restart przeglądarki i będą dostępne na innych urządzeniach z tym samym profilem Chrome. Nie trzeba konfigurować od nowa przy każdej sesji.
Przy następnych testach: kliknij toggle przy regule albo włącz master switch. Pięć sekund i reguły znowu aktywne.
Co Header Modifier nie robi
Żeby nie było nieporozumień: Header Modifier nie modyfikuje nagłówków odpowiedzi serwera. Jeśli CDN uparcie serwuje stary plik niezależnie od tego co wyślesz w żądaniu, Header Modifier tego nie przeskoczy. Potrzebujesz wtedy inwalidacji po stronie CDN.
Nie siedzi w żadnym proxy, nie przechwytuje ruchu, nie loguje treści żądań. Reguły działają wyłącznie w Chrome — curl, Postman, CI runner i backend Twojej aplikacji działają tak, jakby rozszerzenia nie było.
Więcej o tym, co Header Modifier może, a czego nie może, znajdziesz na stronie rozszerzenia albo na stronie dla developerów.