Jak ustawić cache przeglądarki i czasy browser caching?

Cache przeglądarki, czyli browser caching, konfiguruje się za pomocą reguł HTTP cache, które określają, jak długo statyczne pliki Twojej strony mają być przechowywane w przeglądarce odwiedzającego. W praktyce dla plików CSS, JavaScript, grafik, fontów i ikon definiuje się nagłówki Kontrola pamięci podręcznej, a w niektórych środowiskach także Expires; na przykład dla wersjonowanych plików CSS i JS często ustawia się 1 rok, dla obrazów od 30 dni do 1 roku, natomiast dla stron HTML krótszy czas lub ponowną walidację. Dobrze dobrane ustawienia zapobiegają wielokrotnemu pobieraniu tych samych zasobów, przyspieszają ładowanie strony i pomagają poprawić metryki Core Web Vitals.

W tym poradniku wyjaśniamy krok po kroku, jak działa cache przeglądarki, ile sekund warto przypisać do poszczególnych typów plików oraz jak wdrożyć te ustawienia w Apache, Nginx, LiteSpeed, WordPressie i po stronie CDN. Celem nie jest wyłącznie zdobycie zielonego wyniku w narzędziu do testowania szybkości. Chodzi o to, aby użytkownik otrzymywał aktualne pliki, a jednocześnie serwer działał wydajniej, TTFB i zużycie transferu były niższe, a ponowne wizyty odczuwalnie szybsze. Szczególnie w przypadku hostingu współdzielonego, hostingu WordPress i firmowych projektów WWW dobrze zaplanowana strategia cache jest jedną z najtańszych, a jednocześnie najbardziej efektywnych optymalizacji wydajności. Hostragons pakiety hostingu WWW

Czym jest cache przeglądarki?

Cache przeglądarki to tymczasowe przechowywanie na urządzeniu użytkownika statycznych zasobów pobieranych podczas otwierania strony internetowej. Gdy odwiedzający wchodzi na stronę główną, przeglądarka pobiera logo, plik CSS, pliki JavaScript, fonty i grafiki. Jeśli dla tych zasobów ustawiono prawidłowe nagłówki cache, przy przejściu na kolejną podstronę lub podczas późniejszej wizyty przeglądarka nie musi ponownie pobierać części tych samych plików z serwera. Dzięki temu strona ładuje się szybciej.

Wyobraźmy sobie stronę główną o rozmiarze 2 MB. Jeśli 1,4 MB stanowią obrazy, 300 KB pliki CSS i JS, a 100 KB fonty, podczas pierwszej wizyty te zasoby mogą zostać pobrane z sieci. Przy kolejnej wizycie, gdy przeglądarka wykorzysta statyczne pliki zapisane lokalnie, ilość danych przesyłanych przez internet znacząco spadnie. Różnica jest szczególnie widoczna na połączeniach mobilnych, w słabszych sieciach oraz na stronach o dużym ruchu.

Cache przeglądarki nie należy mylić z cache po stronie serwera. Cache serwerowy przechowuje na serwerze wynik działania PHP, zapytania do bazy danych lub gotowe wersje stron. Cache przeglądarki pozwala natomiast ponownie wykorzystać zasoby zapisane na urządzeniu odwiedzającego. Najlepszą wydajność uzyskuje się wtedy, gdy oba poziomy są zaplanowane wspólnie. W serwisach opartych na WordPressie page cache, object cache, cache CDN i browser cache są zazwyczaj elementami jednej strategii optymalizacyjnej. hosting WordPress i optymalizacja wydajności

Dlaczego browser caching jest ważny dla SEO?

Google lepiej ocenia strony, które zapewniają użytkownikom szybkie, stabilne i przewidywalne doświadczenie. Cache przeglądarki sam w sobie nie gwarantuje wyższych pozycji w wynikach wyszukiwania, ale wspiera SEO, ponieważ wpływa na szybkość ładowania, opóźnienia interakcji i efektywność pobierania zasobów. Największe znaczenie ma w scenariuszach takich jak ponowna wizyta, przechodzenie między kategoriami, oglądanie kolejnych produktów czy czytanie kilku wpisów na blogu.

W standardach SEO na rok 2026 wydajność techniczna nie sprowadza się wyłącznie do wyniku Lighthouse. Doświadczenie użytkownika analizowane przez Google jest powiązane z LCP, INP, CLS, TTFB oraz danymi rzeczywistych użytkowników. Niepotrzebne ponowne pobieranie plików CSS i JS może wydłużyć LCP. Ciągłe pobieranie fontów na każdej podstronie może negatywnie wpływać na stabilność wizualną. Brak cache dla dużych grafik sprawia, że użytkownik mobilny odczuwa stronę jako wolniejszą.

• Szybsze ponowne wizyty: Użytkownik nie pobiera drugi raz tych samych plików.
• Niższe zużycie transferu: Ruch na serwerze maleje, a zasoby hostingu są wykorzystywane efektywniej.
• Lepsza efektywność crawlowania: Dostarczanie statycznych zasobów staje się bardziej uporządkowane zarówno dla botów, jak i użytkowników.
• Mniejsze ryzyko szybkiego opuszczenia strony: Szybko otwierające się podstrony sprzyjają większemu zaangażowaniu.
• Stabilniejsza wydajność: Obciążenia po stronie CDN i hostingu są lepiej amortyzowane.

Podstawowe nagłówki HTTP cache

Czasy cache przeglądarki są kontrolowane przez nagłówki odpowiedzi HTTP. Najczęściej używane nagłówki to Cache-Control, Expires, ETag oraz Last-Modified. W nowoczesnych projektach głównym mechanizmem kontroli jest Cache-Control; Expires stosuje się przede wszystkim dla zgodności wstecznej ze starszymi środowiskami.

Kontrola pamięci podręcznej

Cache-Control informuje przeglądarkę i pośrednie systemy cache, w jaki sposób dany plik ma być przechowywany. Najczęściej stosowane dyrektywy to:

• max-age: Określa przez ile sekund zasób jest uznawany za świeży. Na przykład max-age=31536000 oznacza około 1 rok.
• public: Informuje, że zasób może być przechowywany w przeglądarce oraz we współdzielonych systemach cache, takich jak CDN.
• private: Oznacza, że zasób powinien być przechowywany wyłącznie w przeglądarce konkretnego użytkownika.
• no-cache: Wymaga sprawdzenia zasobu na serwerze przed użyciem; nie oznacza całkowitego wyłączenia cache.
• no-store: Oznacza, że zasób nie powinien być nigdzie przechowywany; to dobry wybór dla płatności, paneli i stron z danymi osobowymi.
• immutable: Informuje, że zasób nie zmieni się do końca okresu ważności; idealne dla plików z wersjonowaną nazwą.

Przykładowy nagłówek dla pliku statycznego może wyglądać tak: Cache-Control: public, max-age=31536000, immutable. Oznacza to, że przeglądarka może przechowywać plik przez 1 rok i nie musi go ponownie sprawdzać, dopóki nazwa pliku się nie zmieni.

Expires

Nagłówek Expires wskazuje konkretną datę i godzinę, do której zasób jest uznawany za ważny. Dla obrazu można na przykład ustawić wartość Expires przypadającą 30 dni w przyszłość. Ponieważ Expires wykorzystuje bezwzględną datę, jest mniej elastyczny niż Cache-Control. W nowoczesnych konfiguracjach priorytet ma Cache-Control, a Expires można dodać jako warstwę zgodności dla starszych przeglądarek.

ETag i Last-Modified

ETag i Last-Modified to mechanizmy walidacji. Przeglądarka może zapytać serwer, czy posiadana przez nią wersja pliku nadal jest aktualna. Jeśli plik się nie zmienił, serwer zwraca odpowiedź 304 Not Modified i nie przesyła ponownie treści pliku. To podejście jest szczególnie przydatne dla HTML oraz innych zasobów, które mogą zmieniać się często albo dla których nie chcesz ustawiać bardzo długiego czasu cache.

Jaki czas cache ustawić dla poszczególnych typów plików?

Jednym z najczęstszych błędów jest ustawianie takiego samego czasu dla wszystkich typów plików. Tymczasem HTML, CSS, JS, obrazy, fonty i odpowiedzi API mają zupełnie różną dynamikę zmian. Główna zasada jest prosta: jeśli możesz zmienić nazwę pliku przy aktualizacji, możesz ustawić długi cache; jeśli zawartość często się zmienia, a nazwa pliku pozostaje taka sama, lepszy będzie krótki czas lub walidacja.

Ta tabela jest dobrym punktem startowym, ale nie powinna być traktowana jak sztywny szablon dla każdego projektu. W sklepie internetowym strony HTML zawierające stany magazynowe i ceny nie powinny być agresywnie cache’owane. Jednocześnie zdjęcia produktów mogą być przechowywane przez 1 rok, o ile przy zmianach stosujesz nowe nazwy plików. W witrynie firmowej logo, fonty i pliki motywu można zwykle trzymać w cache długo, natomiast banery promocyjne, jeśli zmieniają się często, bezpieczniej ustawić na 7-30 dni.

Jak zaplanować czasy cache przeglądarki?

Aby strategia cache działała dobrze, najpierw podziel pliki na kategorie. Technicznie chodzi o napisanie reguł według rozszerzeń plików; strategicznie zaś o dobranie czasu przechowywania na podstawie częstotliwości aktualizacji.

1. Oddziel zasoby statyczne od dynamicznych

Pliki CSS, JS, JPG, PNG, WebP, SVG czy WOFF2 są zasobami statycznymi. HTML, koszyk, panel użytkownika, wyniki wyszukiwania i odpowiedzi API należy traktować jako treści dynamiczne. Zasoby statyczne można cache’ować długo, natomiast dynamiczne wymagają większej ostrożności. Szczególnie w przypadku treści personalizowanych dla użytkownika nie wolno stosować public cache.

2. Stosuj wersjonowanie plików

Najbezpieczniejszą drogą do długich czasów cache jest wersjonowanie plików. Jeśli ustawisz 1 rok cache dla pliku style.css, a potem zmienisz jego zawartość, część użytkowników może nadal widzieć stary wygląd strony. Zamiast tego używaj nazw takich jak style.2026.01.css, app.v12.js albo app.8f3a2.js z hashem pliku. W momencie aktualizacji publikowana jest nowa nazwa, a przeglądarka pobiera nowy zasób.

Motywy WordPress oraz nowoczesne narzędzia build potrafią automatyzować ten proces. Jeśli tworzysz motyw, użycie parametru version w funkcjach wp_enqueue_style i wp_enqueue_script ułatwia zarządzanie wersjami przez query string lub nazwę pliku. Warto jednak pamiętać, że niektóre konfiguracje CDN inaczej traktują query stringi w cache, dlatego dodanie hasha bezpośrednio do nazwy pliku bywa bardziej odporne i przewidywalne.

3. Nie bądź zbyt agresywny dla HTML

Strony HTML zawierają właściwą treść widoczną dla użytkownika, dlatego zwykle zarządza się nimi przez krótki cache lub revalidation. Dla wpisów blogowych 5-10 minut może w zupełności wystarczyć; dla aktualności, promocji albo stron z cenami potrzebny jest jeszcze krótszy czas. Jeśli w WordPressie używasz page cache, nagłówki cache przeglądarki musisz analizować razem z cache serwerowym oraz mechanizmem purge w CDN.

4. Wyłącz cache tam, gdzie liczy się bezpieczeństwo

Na stronie logowania, w panelu klienta, w kroku płatności, w podsumowaniu zamówienia, na fakturach i wszędzie tam, gdzie pojawiają się dane osobowe, zalecane są nagłówki takie jak Cache-Control: no-store, private. Cache przeglądarki służy wydajności, ale nie może zagrażać prywatności ani bezpieczeństwu danych. Używanie SSL jest w tym kontekście podstawowym wymaganiem. Hostragons certyfikaty SSL

Ustawienia cache przeglądarki w Apache przez .htaccess

Na serwerach Apache cache przeglądarki najczęściej konfiguruje się w pliku .htaccess. Dla wielu właścicieli stron korzystających z hostingu współdzielonego jest to najprostsza i najszybsza metoda. Najpierw trzeba upewnić się, że aktywne są moduły mod_expires i mod_headers. W większości dobrych środowisk hostingowych są one dostępne domyślnie.

Możesz przyjąć następującą logikę: długi czas dla obrazów i fontów, długi czas dla CSS i JS oraz krótka walidacja dla HTML. W regułach dodawanych do pliku .htaccess definiuje się ExpiresByType oraz Header set Cache-Control dla konkretnych typów plików. Przykładowo dla image/webp, image/jpeg, image/png i image/svg+xml można ustawić 1 rok; dla text/css i application/javascript również 1 rok; natomiast dla text/html zastosować no-cache.

Przed zmianą ustawień zrób kopię zapasową pliku .htaccess. Błędnie zapisana reguła może spowodować błąd 500 Internal Server Error i chwilowo wyłączyć stronę. Po wdrożeniu otwórz witrynę w trybie incognito, a następnie w DevTools przejdź do zakładki Network i sprawdź response headers dla wybranego pliku. Jeśli Cache-Control się nie pojawia, moduł serwera może być wyłączony, CDN może nadpisywać nagłówek albo inna wtyczka może przejmować kontrolę nad nagłówkami.

Przykładowe wartości dla Apache: max-age=31536000 dla CSS i JS, max-age=31536000 dla obrazów, max-age=2592000 dla PDF, max-age=0 oraz no-cache dla HTML. To dobre wartości startowe, które należy dopasować do sposobu publikowania treści na stronie. Korzystając z ustawień wydajnościowych przez .htaccess w infrastrukturze Hostragons, warto sprawdzić, czy nie kolidują one z ustawieniami cache motywu i wtyczek. ustawienia wydajności Apache .htaccess

Ustawienia browser caching w Nginx

Na serwerach Nginx nagłówki cache definiuje się w blokach server lub location. Nginx jest często wybierany w projektach o większym ruchu, ponieważ bardzo wydajnie obsługuje pliki statyczne. Podstawowa logika polega na przygotowaniu reguł location według rozszerzeń plików i ustawieniu wartości expires oraz add_header Cache-Control.

Przykładowe podejście wygląda tak: dla zasobów statycznych takich jak CSS, JS, WebP, JPG, PNG, SVG i WOFF2 ustawiasz expires 1y oraz Cache-Control public, immutable. Dla wyjścia HTML stosujesz expires off lub no-cache. Jeśli używasz CDN, koniecznie przetestuj też, jak CDN interpretuje nagłówki Cache-Control otrzymywane z serwera origin.

W konfiguracji Nginx trzeba uważać na dyrektywę add_header, ponieważ w pewnych sytuacjach jest stosowana tylko do wybranych kodów odpowiedzi. W nowoczesnych konfiguracjach można użyć parametru always. Jeśli ten sam nagłówek dodaje aplikacja, Nginx i CDN, mogą powstać sprzeczne lub zdublowane wartości Cache-Control. Wtedy należy jasno ustalić kolejność priorytetów i zdecydować, która warstwa jest głównym źródłem prawdy.

Cache w LiteSpeed i na stronach WordPress

Serwery LiteSpeed, zwłaszcza w połączeniu z wtyczką LiteSpeed Cache, dają bardzo mocną przewagę wydajnościową w projektach WordPress. Trzeba jednak rozróżnić cache przeglądarki od page cache. Po włączeniu opcji Browser Cache w LiteSpeed Cache nagłówki cache dla plików statycznych mogą być dodawane automatycznie. Mimo to warto sprawdzić, jakie czasy faktycznie są ustawione.

Rekomendowana praktyka w WordPressie to długie cache’owanie statycznych zasobów przy jednoczesnym aktywnym wersjonowaniu plików. Po aktualizacji motywu, zmianie CSS lub modyfikacji JS wtyczka powinna wyczyścić cache, a jeśli używasz CDN, należy wykonać również CDN purge. W przeciwnym razie część użytkowników może zobaczyć starą wersję projektu albo napotkać błędne działanie JavaScriptu.

Popularne wtyczki cache oferują opcje takie jak Browser Cache, Minify, Combine, Critical CSS, integracja z CDN oraz Object Cache. Włączanie wszystkich funkcji naraz i w najbardziej agresywnym wariancie nie zawsze jest dobrym pomysłem. Najpierw uporządkuj nagłówki cache przeglądarki, a dopiero potem testuj minifikację i łączenie plików. W 2026 roku HTTP/2 i HTTP/3 są powszechne, więc łączenie każdego pliku w jeden pakiet nie jest już tak krytyczne jak dawniej; w niektórych sytuacjach może nawet pogorszyć efektywność cache.

Jeśli Twoja strona WordPress działa wolno, przyczyną nie musi być wyłącznie browser cache. Wydajność obniżają również rozrośnięta baza danych, ciężki motyw, zbyt wiele wtyczek, niezoptymalizowane obrazy oraz hosting z małą ilością zasobów. Dlatego ustawienia cache warto analizować razem z jakością hostingu, aktualną wersją PHP i poprawną konfiguracją SSL. Hostragons hosting WordPress

Jak ustawić czasy cache przy korzystaniu z CDN?

CDN dostarcza statyczne pliki z serwerów edge znajdujących się geograficznie bliżej użytkownika. Cache przeglądarki przechowuje natomiast plik na urządzeniu odwiedzającego. Gdy te dwie warstwy działają razem, wzrost wydajności jest znacznie bardziej odczuwalny. Trzeba jednak zadbać, aby czas edge cache ustawiony w panelu CDN był spójny z nagłówkami Cache-Control na serwerze origin.

Ogólna strategia może być następująca: na serwerze origin ustaw dla statycznych plików Cache-Control na 1 rok, a w CDN zdefiniuj taki sam lub kontrolowany TTL. Przy zmianach plików stosuj wersjonowane nazwy albo wykonuj CDN purge. Jeśli cache’ujesz strony HTML przez CDN, przygotuj reguły specjalne; koszyk, konto, płatności i panel administracyjny muszą być bezwzględnie wyłączone z cache.

Częstym problemem w witrynach korzystających z CDN jest wyświetlanie starych plików po aktualizacji. Najczęściej wynika to ze zmiany zawartości bez zmiany nazwy pliku albo z pominięcia CDN purge. Najsolidniejszym rozwiązaniem jest generowanie w procesie build plików z hashem w nazwie i odwoływanie się do nowej nazwy w HTML. Dzięki temu nawet jeśli przeglądarka i CDN nadal przechowują stary plik, nowa strona zażąda nowego zasobu.

Praktyczna lista kontrolna wdrożenia

Poniższa lista kontrolna to praktyczny plan ustawiania czasów cache przeglądarki. W małej stronie firmowej można go zwykle wdrożyć w 30-60 minut; w sklepie internetowym lub projekcie z autorskim oprogramowaniem warto przeznaczyć więcej czasu na testy.

• 1. Zrób inwentaryzację plików: Oddziel CSS, JS, obrazy, fonty, PDF, HTML oraz odpowiedzi API.
• 2. Określ częstotliwość aktualizacji: Zapisz, które pliki zmieniają się codziennie, a które raz w miesiącu lub rzadziej.
• 3. Wybierz strategię wersjonowania: Użyj hasha w nazwie pliku, parametru wersji albo numeru builda.
• 4. Dodaj reguły serwerowe: Zdefiniuj nagłówki Cache-Control w Apache, Nginx, LiteSpeed lub panelu CDN.
• 5. Wyklucz strony wrażliwe: Dla panelu admina, płatności, koszyka, panelu użytkownika i stron z danymi osobowymi używaj no-store.
• 6. Przetestuj konfigurację: Sprawdź ją przez Chrome DevTools, curl -I, WebPageTest, Lighthouse i testy na realnych urządzeniach.
• 7. Monitoruj po publikacji: Upewnij się, że nie pojawiają się stare pliki, zepsuty wygląd strony ani błędy JS.

Jak testować cache przeglądarki?

Najszybszym sposobem sprawdzenia, czy ustawienia działają, są narzędzia deweloperskie w przeglądarce. W Chrome otwórz stronę, przejdź do DevTools i zakładki Network, kliknij plik CSS albo obraz, a następnie sprawdź wartość Cache-Control w sekcji Response Headers. Przy drugim załadowaniu strony w kolumnie Status możesz zobaczyć informacje takie jak memory cache lub disk cache.

Jeśli korzystasz z wiersza poleceń, komenda curl -I twojadomena.pl/plik.css pokaże nagłówki odpowiedzi. Warto sprawdzić tam Cache-Control, Expires, ETag oraz Last-Modified. Jeśli oczekiwanego nagłówka nie ma, jedna z warstw — aplikacja, serwer WWW albo CDN — mogła nadpisać konfigurację.

Do testów wydajności można używać Lighthouse, PageSpeed Insights i WebPageTest. Nie warto jednak stosować ich zaleceń bezrefleksyjnie. Oceniaj je w kontekście rzeczywistego scenariusza użytkownika. Na przykład Lighthouse może zalecać długi cache dla plików statycznych, ale nie oczekuje takiej samej agresywności wobec stron HTML. Narzędzia testowe często zgłaszają też ostrzeżenia dotyczące skryptów zewnętrznych; w przypadku Google Fonts, sieci reklamowych lub skryptów społecznościowych zwykle nie masz kontroli nad ich nagłówkami cache.

Najczęstsze błędy

Cache przeglądarki wydaje się prosty, ale błędna konfiguracja może prowadzić do problemów z aktualizacjami, ryzyk bezpieczeństwa i gorszego doświadczenia użytkownika. Poniższe błędy szczególnie często pojawiają się u osób zaczynających optymalizację.

• Ustawienie 1 roku cache dla wszystkich zasobów: HTML, odpowiedzi API i treści personalizowane nie powinny trafiać do tej samej kategorii.
• Długi cache bez wersjonowania plików: Użytkownicy mogą nadal widzieć stare pliki CSS lub JS.
• Zapomnienie o CDN purge: Nawet po aktualizacji origin CDN może nadal serwować stare pliki.
• Używanie wielu wtyczek cache naraz: Kilka wtyczek może zapisywać te same nagłówki i tworzyć konflikty.
• Błędna interpretacja ostrzeżeń dla zasobów zewnętrznych: Nagłówki cache skryptów z innych domen nie zawsze są pod Twoją kontrolą.
• Cache’owanie stron wrażliwych: Dla płatności i kont użytkowników należy stosować no-store.

Zalecane wartości początkowe

Dla nowej strony bezpieczne wartości startowe można podsumować tak: pliki CSS i JS, jeśli są wersjonowane, 1 rok; obrazy 1 rok, ale często zmieniane grafiki kampanijne 30 dni; fonty 1 rok; pliki PDF od 7 do 180 dni zależnie od częstotliwości aktualizacji; strony HTML no-cache albo krótki czas liczony w minutach. Takie podejście pozwala zachować równowagę między szybkością a aktualnością.

Jeśli prowadzisz firmową stronę wizytówkową, długie czasy cache zwykle nie sprawiają problemów. Jeśli masz sklep internetowy, możesz ustawić długi cache dla statycznych plików na stronach produktów, ale ceny, stany magazynowe, koszyk i dane użytkowników muszą pozostać poza cache. Jeśli prowadzisz serwis newsowy lub blog, obrazy i pliki motywu mogą być przechowywane długo, natomiast HTML warto cache’ować krótko, zgodnie z rytmem publikacji. Domena, SSL i infrastruktura hostingowa również są częścią łańcucha wydajności. Hostragons sprawdzanie domeny Hostragons rozwiązania hostingu dla firm

Podsumowanie

Dobrze zaplanowane czasy cache przeglądarki potrafią znacząco poprawić wydajność strony podczas ponownych wizyt. Podstawowa zasada brzmi: dla wersjonowanych plików statycznych ustawiaj długi cache, a dla HTML oraz stron z danymi osobowymi stosuj krótki czas, walidację albo no-store. W Apache, Nginx, LiteSpeed, WordPressie i środowiskach CDN obowiązuje ta sama logika: rozpoznaj typ zasobu, określ częstotliwość aktualizacji, przetestuj nagłówki Cache-Control i monitoruj działanie po publikacji.

Krótko mówiąc, browser caching to niedroga, ale bardzo skuteczna optymalizacja szybkości. Jeśli hostujesz stronę w infrastrukturze Hostragons, wybór ustawień cache dopasowanych do typu hostingu może wzmocnić zarówno doświadczenie użytkownika, jak i techniczne SEO. Aby dobrać najlepsze rozwiązanie hostingowe do swoich potrzeb, możesz sprawdzić opcje hostingu Hostragons albo krok po kroku przeanalizować aktualną konfigurację cache w swojej witrynie. Hostragons Pakiety Hostingu

Najczęściej zadawane pytania

Jaki powinien być czas cache przeglądarki?

Dla wersjonowanych plików statycznych, takich jak CSS, JS, obrazy i fonty, zwykle najlepszy jest zakres od 30 dni do 1 roku. Dla stron HTML ważniejsza jest aktualność treści, dlatego zaleca się no-cache, max-age=0 albo krótki czas liczony w kilku minutach.

Jaka jest różnica między Cache-Control a Expires?

Cache-Control to nowoczesny i bardziej elastyczny nagłówek HTTP, który używa reguł opartych na sekundach, takich jak max-age. Expires wskazuje konkretną datę i godzinę. W aktualnych projektach priorytetowo należy stosować Cache-Control, a Expires dodawać głównie dla zgodności wstecznej.

Jak włączyć browser caching w WordPressie?

We wtyczkach takich jak LiteSpeed Cache, WP Rocket czy W3 Total Cache można aktywować opcję Browser Cache lub cache przeglądarki. Dodatkowo nagłówki Cache-Control dla typów plików można dodać przez .htaccess albo konfigurację serwera.

Czy przy długim czasie cache aktualizacje strony nie będą widoczne?

Jeśli zmienisz zawartość tego samego pliku CSS lub JS bez zmiany jego nazwy, część użytkowników może nadal widzieć starą wersję. Aby temu zapobiec, stosuj wersjonowanie plików, nazwy z hashem oraz CDN purge.

Czy strony płatności i panel użytkownika powinny być cache’owane?

Nie. Na stronach zawierających dane osobowe, takich jak płatność, koszyk, konto, faktury i panel administracyjny, należy stosować bezpieczne nagłówki typu Cache-Control: no-store, private. Nie warto poświęcać bezpieczeństwa dla wydajności.