„U mnie działa” nie opisuje stanu strony u klienta
Po wdrożeniu nowego formularza zespół widzi poprawny ekran, a część klientów nadal zgłasza brak przycisku. Przyczyną może być połączenie elementów z różnych wydań: nowy HTML, stary arkusz stylów i jeszcze inna wersja skryptu. Cache nie jest jednym miejscem. Odpowiedzi mogą znajdować się w przeglądarce, warstwie pośredniej, na serwerze oraz w magazynie zarządzanym przez Service Workera. Czyszczenie jednego z nich nie dowodzi, że cała ścieżka została odświeżona.
Zanim zmienisz ustawienia, zapisz adres żądania, nagłówki odpowiedzi i identyfikator wersji zasobu. Porównaj zwykłe wejście powracającego użytkownika z nową sesją. Twarde odświeżenie własnego okna może zamaskować problem występujący u odbiorców. W przykładowym katalogu usług najważniejszym dowodem jest działające otwarcie oferty i wysłanie zapytania po przejściu ze starej wersji, a nie tylko poprawny zrzut nowej strony.
Nadaj plikom niezmienne adresy związane z zawartością
Dla statycznych zasobów wygodnym wzorcem są nazwy zależne od wydania lub skrótu treści. Jeżeli plik pod danym adresem nie będzie zmieniany, można bezpieczniej planować dłuższe przechowywanie. Nowy HTML odwołuje się wtedy do nowej nazwy. Problem powstaje, gdy skrypt zostaje podmieniony pod tym samym URL, a przeglądarka zgodnie z nagłówkiem uznaje starą kopię za aktualną. To nie jest błąd użytkownika, tylko niespójna umowa o ważności zasobu.
Nie usuwaj od razu wszystkich poprzednich plików po wdrożeniu. Otwarta karta może nadal korzystać ze starego dokumentu i dopiero później poprosić o jego dodatkowy moduł. Ustal okres zachowania zasobów potrzebnych poprzedniemu wydaniu. Ten sam mechanizm ułatwia cofnięcie kodu. Jeśli zachowasz tylko nowy JavaScript, przywrócenie starego szablonu może stworzyć kolejną mieszaną wersję zamiast działającego powrotu.
Rozróżnij ponowną walidację i zakaz przechowywania
Cache-Control: no-cache nie oznacza całkowitego zakazu zapisania odpowiedzi. Wymaga jej sprawdzenia przed ponownym użyciem. No-store dotyczy nieprzechowywania, a private ogranicza wykorzystanie do prywatnego cache. Dobór tych dyrektyw zależy od danych i sposobu działania strony. Publiczny artykuł, panel klienta oraz potwierdzenie formularza nie muszą mieć identycznych zasad. Samo istnienie ciasteczka nie stanowi pełnej konfiguracji ochrony prywatnej odpowiedzi.
Dla treści redakcyjnej można zaplanować walidację lub krótki czas świeżości. Dla wrażliwych widoków unikaj przypadkowego współdzielenia odpowiedzi między użytkownikami. Przy testowaniu sprawdzaj rzeczywiste nagłówki wychodzące z ostatniej warstwy serwera, ponieważ pośrednik może je zmienić. Zapis w konfiguracji aplikacji nie jest dowodem działania. W dokumentacji wydania umieść krótki wykaz klas zasobów i przyjętych dla nich zasad.
Service Worker potrzebuje osobnej strategii aktualizacji
Service Worker może obsługiwać żądania niezależnie od zwykłego cache HTTP. Dlatego zaktualizowanie CSS na serwerze nie gwarantuje pobrania go przez aplikację działającą offline. Rozdziel pliki niezbędne do uruchomienia od danych dynamicznych. Nie zapisuj automatycznie każdej odpowiedzi formularza ani panelu klienta. Nazwy magazynów, zasady czyszczenia i moment aktywacji nowej wersji powinny być częścią projektu, a nie kopiowanym bez analizy fragmentem kodu.
Przymusowe przejęcie wszystkich otwartych kart przez nowego workera może przerwać rozpoczętą pracę. W przykładowym konfiguratorze użytkownik nie powinien utracić wyborów dlatego, że w tle opublikowano zmianę stopki. Rozważ komunikat o dostępnej aktualizacji i przejście do niej w bezpiecznym momencie. Po powrocie do sieci sprawdź zarówno świeżość danych, jak i zgodność interfejsu. Obsługa offline nie może polegać na nieskończonym utrzymywaniu nieaktualnej oferty.
Wdrażaj komplet wydania w kontrolowanej kolejności
Przygotuj wszystkie nowe zasoby przed przełączeniem HTML, który się do nich odwołuje. Jeśli hosting pozwala na atomowe przełączenie katalogu wydania, wykorzystaj tę właściwość. Na prostszym hostingu opracuj kolejność publikacji i krótki test spójności. Unikaj sytuacji, w której połowa nowych plików jest dostępna, a reszta dopiero się przesyła. Przy zmianie kontraktu API utrzymuj zgodność ze starymi kartami przez uzgodniony okres.
Zanotuj, które warstwy cache trzeba unieważnić oraz kto ma do nich dostęp. Nie czyść całego magazynu obrazów tylko dlatego, że zmienił się jeden tekst. Szerokie czyszczenie może zwiększyć obciążenie bez rozwiązania źródła problemu. Dobrze przygotowane wydanie posiada identyfikator możliwy do odczytania w diagnostyce. Dzięki niemu zgłoszenie „widzę stary formularz” można powiązać z konkretnym zestawem plików zamiast zgadywać na podstawie godziny rozmowy.
Testuj powracającego użytkownika i cofnięcie wersji
Przed aktualizacją otwórz stronę, przejdź kilka kroków i pozostaw kartę. Wdróż zmianę, potem wróć do tej karty, przejdź na inną podstronę i wykonaj zadanie. Powtórz próbę przy słabej sieci, po rozłączeniu oraz po ponownym połączeniu. Osobno sprawdź świeże wejście. Jeśli działa tylko nowa sesja, problem nadal dotyczy części realnych odbiorców. Testy powinny też objąć odmowę aktualizacji przez użytkownika, gdy taki wybór jest dostępny.
Na kopii środowiska wykonaj cofnięcie wydania i sprawdź, czy stare pliki nadal istnieją. Zadbaj o dane wprowadzone po aktualizacji: rollback kodu nie musi oznaczać cofnięcia danych. Na końcu porównaj widoczny numer wydania z rzeczywistymi adresami zasobów. Spójny cache ma przyspieszać korzystanie ze strony, nie zmuszać klientów do ręcznego kasowania historii. Powtarzalny proces wydawania ogranicza takie zgłoszenia skuteczniej niż instrukcja „proszę nacisnąć Ctrl+F5”.