Co przeglądarka zachowuje po pierwszej wizycie
Gdy użytkownik otwiera stronę, przeglądarka pobiera dokument HTML oraz potrzebne mu zasoby, na przykład arkusze CSS, skrypty, czcionki i obrazy. Część tych plików może zapisać w pamięci podręcznej. Przy kolejnej wizycie sprawdza, czy zapisanej kopii wolno nadal użyć. Jeśli tak, nie musi ponownie pobierać całego pliku. Korzyść bywa szczególnie widoczna w serwisach, których podstrony korzystają z tych samych zasobów, na przykład wspólnego arkusza stylów.
Cache przeglądarki nie oznacza, że każda kolejna odsłona będzie natychmiastowa. Przeglądarka może usuwać zapisane pliki, a użytkownik może korzystać z innego urządzenia lub przeglądarki. Szybkość zależy też od samej strony, połączenia i pracy urządzenia. Pamięć podręczna zmniejsza przede wszystkim potrzebę ponownego pobierania zasobów, które nie uległy zmianie.
Jak strona informuje, czy plik jest nadal aktualny
Serwer przekazuje przeglądarce wskazówki w nagłówkach odpowiedzi HTTP. Nagłówek Cache-Control może określać, jak długo odpowiedź jest uznawana za świeżą. Dopóki ten czas nie minie, przeglądarka może użyć lokalnej kopii bez pytania serwera. Po jego upływie nie zawsze musi pobierać plik od początku: może sprawdzić, czy wersja na serwerze się zmieniła. Pomagają w tym między innymi identyfikator ETag lub data ostatniej modyfikacji. Jeśli plik jest nadal taki sam, serwer może potwierdzić to odpowiedzią 304, bez przesyłania całej zawartości.
Warto rozróżniać dwa często mylone ustawienia. Cache-Control: no-cache dopuszcza przechowywanie odpowiedzi, ale wymaga sprawdzenia jej aktualności przed ponownym użyciem. Cache-Control: no-store oznacza, że odpowiedź nie powinna być przechowywana w pamięci podręcznej. Dobór zasad zależy od rodzaju treści: inne potrzeby ma niezmienny plik z wyglądem strony, a inne dokument z informacjami zmieniającymi się często.
Dlaczego po aktualizacji widać czasem starą wersję
Wyobraź sobie sklep, w którym plik style.css jest zapisywany pod tym samym adresem przez wiele miesięcy. Jeśli przeglądarka dostała informację, że może długo korzystać z zapisanej kopii, po zmianie pliku na serwerze część odwiedzających nadal zobaczy starszy wygląd. Podobny problem dotyczy skryptów: nowy HTML może współpracować z nową wersją JavaScriptu, podczas gdy przeglądarka użyje starej. Efektem mogą być błędy interfejsu trudne do odtworzenia u osoby, która odwiedza stronę po raz pierwszy.
Praktycznym rozwiązaniem jest zmiana adresu zasobu przy zmianie jego zawartości, na przykład przez dodanie identyfikatora wersji do nazwy pliku: style.a1b2.css. Dokument HTML wskazuje wtedy nowy adres, więc przeglądarka pobiera nowy plik, a poprzednia kopia nie przeszkadza. Tak przygotowane, wersjonowane zasoby mogą mieć dłuższy okres przechowywania. Sam HTML zwykle wymaga ostrożniejszego podejścia do cache, bo to on informuje przeglądarkę o nowych adresach plików.
Jak dobrać zasady do typowego serwisu
Zacznij od podziału zasobów według tego, jak są aktualizowane. Wersjonowane pliki CSS, JavaScript i niezmienne obrazy mogą korzystać z dłuższego czasu świeżości, pod warunkiem że wdrożenie nowej wersji zmienia ich adresy. Dokumenty HTML oraz pliki dostępne stale pod tym samym adresem warto traktować ostrożniej. Jeśli zawartość zależy od zalogowanego użytkownika, sprawdź osobno zasady jej przechowywania; nie stosuj ustawień dla publicznych zasobów bez namysłu do odpowiedzi zawierających prywatne informacje.
Pamiętaj też, że pamięć podręczna przeglądarki i cache sieci CDN to różne miejsca przechowywania. Usunięcie pliku z CDN nie musi sprawić, że przeglądarka natychmiast porzuci swoją świeżą kopię. Dlatego procedura publikacji powinna uwzględniać zarówno nagłówki odpowiedzi, jak i sposób nazywania plików. Ręczne polecenie użytkownikom, by wyczyścili cache, może pomóc w pojedynczym przypadku, ale nie zastępuje poprawnego procesu aktualizacji.
Krótka kontrola po wdrożeniu zmian
Otwórz narzędzia deweloperskie przeglądarki i sprawdź w panelu sieciowym nagłówki odpowiedzi dla HTML, CSS, JavaScriptu oraz kilku obrazów. Czy każdy typ zasobu ma zasady odpowiadające temu, jak często zmienia się jego zawartość? Czy przy kolejnej wizycie niezmienione pliki są używane z pamięci podręcznej albo skutecznie sprawdzane pod kątem zmian? Jednocześnie upewnij się, że wyłączona w narzędziach opcja korzystania z cache nie zniekształca testu.
Następnie wykonaj próbne wdrożenie zmiany w CSS lub skrypcie. Sprawdź, czy adres zmienionego pliku jest nowy i czy HTML odwołuje się właśnie do niego. Przetestuj stronę zarówno w przeglądarce, która już ją odwiedzała, jak i w świeżej sesji. Jeśli wyniki się różnią, porównaj adresy plików i ich nagłówki, zanim uznasz problem za błąd samej przeglądarki. Taka kontrola pomaga zachować korzyści z cache bez ryzyka, że odwiedzający utkną przy nieaktualnym wyglądzie lub działaniu strony.
