Jak ustawić politykę cache w .htaccess dla WordPressa i statycznych zasobów

Przez
ShellSeeker
-
0
27
Rate this post

Nawigacja:

Dlaczego cache w .htaccess ma tak duże znaczenie dla WordPressa

Jak przeglądarka i serwer współpracują przy cache

Przeglądarka użytkownika nie pobiera każdego pliku przy każdym odświeżeniu strony. Jeśli dostanie od serwera odpowiednie nagłówki cache (między innymi Cache-Control i Expires), może przechować zasoby lokalnie i przy kolejnej wizycie skorzystać z kopii z dysku zamiast ponownie łączyć się z serwerem. To właśnie te nagłówki są zwykle ustawiane w .htaccess na serwerach Apache/LiteSpeed.

Dla WordPressa oznacza to jedno: jeśli statyczne pliki – obrazy, CSS, JS, fonty – są dobrze skeszowane, przeglądarka pobiera dynamicznie głównie HTML, a reszta leci z lokalnego cache. Mniej żądań HTTP, mniejsze zużycie transferu, krótszy czas ładowania widoczny dla użytkownika. Przy wolniejszym hostingu różnica bywa kolosalna – kilka linijek w .htaccess potrafi zdjąć z serwera setki niepotrzebnych zapytań na godzinę.

Klucz tkwi w tym, że serwer musi jasno powiedzieć przeglądarce, jak długo dane zasoby można uznawać za aktualne. Bez polityki cache w .htaccess wszystko sprowadza się do domyślnego zachowania serwera, które często jest zachowawcze lub w ogóle nie korzysta z browser cache w pełni.

Cache serwera vs cache przeglądarki – dwa różne światy

W świecie WordPressa bardzo łatwo pomylić dwie warstwy cache:

  • Cache po stronie serwera – tworzony przez wtyczki cache (np. WP Rocket, W3 Total Cache, LiteSpeed Cache), mechanizmy na poziomie PHP, Memcached, Redis. Redukuje liczbę zapytań do bazy danych i czasu generowania HTML.
  • Cache przeglądarki (browser cache) – kontrolowany głównie nagłówkami HTTP ustawianymi w .htaccess (lub w konfiguracji serwera). Sprawia, że przeglądarka nie pobiera ponownie plików statycznych za każdym razem.

Plik .htaccess odpowiada za to drugie. Nawet najlepsza wtyczka cache niewiele zdziała, jeśli każda ikona, każdy CSS i każdy skrypt WordPressa będzie pobierany na nowo przy każdym wejściu użytkownika. Z drugiej strony sama polityka cache w .htaccess nie zastąpi cache strony na poziomie HTML. Te warstwy nie konkurują – one się uzupełniają.

WordPress a statyczne zasoby – dlaczego jest ich tak dużo

Instalacja WordPressa generuje setki plików: motyw, motyw potomny, biblioteki JS, style, biblioteki edytora blokowego, do tego dziesiątki wtyczek – każda z własnymi skryptami i stylami. Do tego dochodzi rosnący katalog wp-content/uploads z obrazami, PDF-ami i innymi zasobami.

Każda strona WordPressa to zwykle:

  • kilkanaście–kilkadziesiąt żądań do plików CSS i JS,
  • kilka–kilkadziesiąt żądań do obrazów, ikon, fontów,
  • jedno główne żądanie do HTML.

Jeśli przeglądarka ponawia wszystkie te żądania przy każdej wizycie, serwer jest obciążony, a użytkownik widzi spowolnienia, zwłaszcza na wolniejszym łączu lub urządzeniach mobilnych. Odpowiednio ustawiona polityka cache w .htaccess zmienia tę sytuację: obrazy, CSS i JS są pobierane raz, a potem lecą z cache tygodniami lub miesiącami – o ile zmiany wersji są poprawnie zarządzane.

Wpływ polityki cache na Core Web Vitals i PageSpeed Insights

Google PageSpeed Insights i Lighthouse bardzo jasno to komunikują. Brak odpowiednich nagłówków cache skutkuje komunikatami w stylu:

  • „Włącz buforowanie w przeglądarce (Leverage browser caching)”
  • „Serve static assets with an efficient cache policy”

Dobrze ustawione nagłówki Cache-Control i Expires poprawiają przede wszystkim:

  • Largest Contentful Paint (LCP) – bo duże grafiki i główne style są szybciej dostępne,
  • First Contentful Paint (FCP) – pierwsze elementy pojawiają się szybciej,
  • Total Blocking Time (TBT) pośrednio – bo część JS dociera z cache bez przeciążania łącza.

Przy kolejnym wejściu użytkownika Core Web Vitals potrafią być dosłownie „zielone”, jeśli przeglądarka ma już w cache kluczowe zasoby. To bezpośrednio wpływa na wyniki SEO i komfort korzystania z serwisu.

Przykład odciążenia hostingu prostym cache

Wyobraź sobie mały sklep WooCommerce z kilkudziesięcioma produktami. Bez polityki cache w .htaccess każdy odwiedzający ściąga przy każdej wizycie wszystkie miniatury, CSS szablonu, skrypty slidera itp. Przy większym ruchu hosting współdzielony zaczyna się krztusić, czas odpowiedzi rośnie.

Po wprowadzeniu kilkunastu linijek z nagłówkami cache dla obrazów, CSS i JS ruch do serwera spada o dziesiątki procent, bo powracający użytkownicy pobierają jedynie HTML oraz ewentualne nowe dane. Ten sam serwer obsługuje więcej użytkowników bez zmiany planu, a w PageSpeed Insights znika komunikat o „braku wydajnej polityki cache”. Właśnie o taki efekt chodzi, kiedy konfigurujesz cache w .htaccess.

Jeżeli serwis ładuje się za wolno, a hosting „jęczy”, właściwie skonfigurowany browser cache jest jednym z najszybszych i najtańszych sposobów, by poczuć realną różnicę.

Podstawy: jak działa .htaccess i nagłówki cache

Czym jest .htaccess i gdzie działa

Plik .htaccess to plik konfiguracyjny serwera HTTP, używany przede wszystkim na Apache i jego zgodnych zamiennikach (np. LiteSpeed). Pozwala nadpisywać globalną konfigurację w obrębie konkretnego katalogu, bez dostępu do głównego pliku konfiguracyjnego serwera (httpd.conf lub analogicznego).

W WordPressie główny .htaccess znajduje się zazwyczaj w katalogu głównym instalacji, np.:

  • /public_html/.htaccess
  • /htdocs/.htaccess
  • /www/.htaccess

Jeśli serwer używa Nginx jako głównego frontu bez Apache, .htaccess może być w ogóle ignorowany, a politykę cache trzeba ustawiać w konfiguracji Nginx. Na hostingu współdzielonym w Polsce najczęściej spotkasz Apache lub LiteSpeed, gdzie .htaccess działa domyślnie.

Hierarchia konfiguracji: httpd.conf vs .htaccess

Plik .htaccess działa tylko wtedy, gdy w konfiguracji serwera jest zezwolenie na jego użycie (AllowOverride). Administrator hostingu może ograniczyć listę dyrektyw dostępnych w .htaccess, więc część reguł może zostać zignorowana lub wywołać błąd serwera (500).

Główne zasady:

  • Jeśli reguły w httpd.conf wyłączają możliwość nadpisywania, .htaccess nie zadziała.
  • Konfliktujące reguły w kilku .htaccess (w podkatalogach) mogą prowadzić do trudnych w debugowaniu efektów.
  • Na mocno zarządzanych hostingach część dyrektyw cache może być już ustawiona globalnie – wtedy własne ustawienia należy testować szczególnie uważnie.

Kiedy „reguły nie wchodzą”, pierwszy krok to sprawdzenie, czy serwer rzeczywiście jest Apache/LiteSpeed oraz czy w logach błędów nie pojawiają się ostrzeżenia związane z dyrektywami mod_expires lub mod_headers.

Najważniejsze nagłówki cache po ludzku

Polityka cache w .htaccess opiera się głównie na kilku nagłówkach HTTP:

  • Cache-Control – podstawowy nagłówek, który określa m.in.:
    • public – zasób może być keszowany przez wszystkich (przeglądarki, CDN, proxy),
    • private – tylko dla pojedynczego użytkownika (bez wspólnego cache pośredniego),
    • max-age=sekundy – maksymalny czas przechowywania w cache od momentu pobrania,
    • no-cache – wymusza weryfikację u serwera przed użyciem kopii,
    • no-store – zabrania przechowywania w cache.
  • Expires – stary, ale nadal używany nagłówek z konkretną datą wygaśnięcia. Ustalany często dyrekcjami ExpiresByType lub ExpiresDefault z modułu mod_expires.
  • Last-Modified – data ostatniej modyfikacji zasobu. Przeglądarka może pytać serwer „czy od tej daty coś się zmieniło?”, wysyłając nagłówek If-Modified-Since.
  • ETag – unikalny identyfikator wersji pliku, często oparty na rozmiarze lub sumie kontrolnej. Ułatwia dokładniejszą weryfikację niż sama data.
  • Pragma – historyczny nagłówek (głównie Pragma: no-cache), używany dziś sporadycznie ze względu na wsteczną kompatybilność.

W większości przypadków wystarczy dobrze ustawione Cache-Control oraz Expires, a przy HTML w razie potrzeby Last-Modified i ewentualnie ETag. Za konfigurację nagłówków odpowiadają głównie moduły mod_expires i mod_headers.

Mocny cache vs cache „ostrożny”

Można wyróżnić dwa główne podejścia do cache:

  • Cache mocny (far-future, immutable) – bardzo długi czas ważności, np. rok lub więcej, z nagłówkiem Cache-Control: public, max-age=31536000, immutable. Idealny dla plików, które zmieniają się rzadko lub są wersjonowane (np. obrazy produktów, wersjonowane CSS/JS).
  • Cache słaby (krótki + revalidate) – krótszy czas, np. kilka minut/godzin, wraz z must-revalidate lub no-cache, co zmusza przeglądarkę do częstszej weryfikacji z serwerem. Stosowany częściej dla HTML i dynamicznie generowanej zawartości.

Kluczowa decyzja: HTML cachujemy ostrożnie, natomiast statyczne zasoby (obrazy, CSS, JS, fonty) mogą mieć dużo bardziej agresywną politykę cache, pod warunkiem, że wprowadzimy mechanizm wersjonowania plików, aby nie blokować użytkownikom aktualizacji.

Logiczny podział: HTML ostrożnie, statyki agresywnie

Bezpieczny schemat myślenia wygląda tak:

  • HTML (strony, wpisy, koszyk): krótki max-age (np. 0–300 sekund), ewentualnie no-cache, must-revalidate. Ułatwia szybkie odświeżanie treści, wpisów, stanów koszyka.
  • Obrazy, CSS, JS, fonty: długi max-age (miesiące, rok) i public. To one robią największy „hałas” w liczbie żądań i objętości transferu.

Takie podejście daje szybkie wczytywanie stałych elementów szablonu i grafik, a jednocześnie pozwala bez stresu aktualizować treści, wpisy, ceny i oferty bez ryzyka, że użytkownik utknie na starym widoku strony głównej czy koszyka.

Przygotowanie środowiska: kopie zapasowe, dostęp i testy

Gdzie leży .htaccess w WordPressie i ile ich może być

Standardowo główny plik .htaccess w WordPressie znajduje się w katalogu, w którym leżą pliki takie jak wp-config.php, wp-login.php i katalogi wp-admin, wp-includes, wp-content. Najczęściej jest to katalog główny domeny.

Istotne jest to, że :

  • W każdym podkatalogu może istnieć osobny plik .htaccess (np. w /wp-content/uploads/), który nadpisuje część reguł.
  • Niektóre wtyczki tworzą własne .htaccess, np. dla ochrony katalogów z plikami do pobrania.
  • Reguły zagnieżdżonych .htaccess działają kaskadowo, co czasem utrudnia analizę, skąd bierze się dany nagłówek.

Do podstawowej polityki cache dla statycznych zasobów zwykle wystarczy modyfikacja głównego .htaccess w katalogu WordPressa.

Kopia zapasowa .htaccess – obowiązkowy odruch

Jedna błędna linijka w .htaccess może spowodować błąd 500 i „białą stronę” w całym serwisie. Zanim pojawią się pierwsze reguły cache, trzeba:

  • pobrać plik .htaccess na lokalny komputer (FTP/SFTP lub menedżer plików w panelu hostingu),
  • zapisać kopię z datą, np. .htaccess-backup-2026-04-26,
  • w razie awarii szybko przywrócić starą wersję i sprawdzić, która z nowych linijek powoduje błąd.

W kryzysie (błąd 500) często wystarczy:

  1. zmienić nazwę aktualnego .htaccess (np. na .htaccess-bad),
  2. wgrać z powrotem poprzednią, działającą kopię,
  3. odświeżyć stronę i upewnić się, że błąd zniknął.

Dobrą praktyką jest wprowadzanie zmian małymi krokami: dodajesz kilka linijek, zapisujesz plik, testujesz stronę i dopiero potem idziesz dalej. Gdy coś się wysypie, od razu wiesz, który fragment konfiguracji odpowiada za problem i nie tracisz czasu na zgadywanie.

Przy edycji .htaccess bardzo pomaga prosty edytor tekstu (np. VS Code, Sublime, Notepad++), a nie Word czy edytor z formatowaniem. Plik musi być zapisany w czystym tekście, bez „niewidocznych” znaków, które potrafią rozsypać konfigurację serwera. Po każdej modyfikacji odśwież stronę w trybie prywatnym lub z wyczyszczonym cache przeglądarki, żeby widzieć faktyczne efekty na serwerze.

Testowanie nagłówków cache w praktyce

Po wprowadzeniu nowych reguł cache nie ma sensu zgadywać, „czy działa” – lepiej od razu zajrzeć w nagłówki odpowiedzi. Najszybciej zrobisz to w narzędziach deweloperskich przeglądarki (zakładka Network): wybierz dowolny plik, przejdź do Headers i sprawdź, jakie Cache-Control, Expires czy Last-Modified zwraca serwer.

Przydatny jest też prosty schemat testów. Najpierw sprawdź stronę główną (HTML), potem jeden plik CSS, jeden JS i jakiś obrazek z katalogu /wp-content/uploads/. Jeśli widzisz tam nowe, oczekiwane nagłówki, możesz przejść do dokładniejszych pomiarów wydajności w PageSpeed Insights, GTmetrix lub WebPageTest i porównać liczbę żądań oraz czasy ładowania przed i po zmianach.

Dzięki takiemu podejściu modyfikacja .htaccess przestaje być ryzykowną „czarną magią”, a staje się prostym narzędziem: wprowadzasz konkretną regułę, weryfikujesz efekt i świadomie wyciskasz z WordPressa dodatkową porcję szybkości bez inwestowania w mocniejszy serwer.

Cache dla statycznych zasobów: obrazy, CSS, JS, fonty

Cel: agresywny cache dla „ciężkich” plików

Największy zysk z cache przynosi przeglądarka, która raz pobrany CSS, JS czy obrazek trzyma lokalnie przez miesiące. Serwer ma mniej roboty, użytkownik mniej czekania, a Ty mniej problemów z „wolnym WordPressem”. Klucz tkwi w osobnym potraktowaniu typów MIME i zdefiniowaniu sensownych czasów życia plików.

Dobry punkt wyjścia to mocny cache (np. rok) dla plików statycznych – pod warunkiem, że zadbasz o wersjonowanie. Poniżej konfiguracja, którą można bezpiecznie dostosować do własnych potrzeb.

Włączenie mod_expires i domyślnych reguł wygasania

Na początek potrzebne jest włączenie modułu mod_expires w kontekście katalogu. W .htaccess dodaj sekcję:

<IfModule mod_expires.c>
  ExpiresActive On

  # Domyślna polityka na wszelki wypadek (np. 1 miesiąc)
  ExpiresDefault "access plus 1 month"
</IfModule>

Ta sekcja aktywuje obsługę nagłówka Expires i ustawia miękką, domyślną politykę. Konkretne typy plików zaraz nadpiszą tę wartość, ale jeśli cokolwiek „przemknie bokiem”, nie zostanie bez cache.

Osobne czasy życia dla obrazów

Grafiki potrafią zajmować ponad połowę wagi strony. Tu naprawdę opłaca się długi cache. Przykład ustawień:

<IfModule mod_expires.c>
  # Obrazy rastrowe
  ExpiresByType image/jpeg "access plus 1 year"
  ExpiresByType image/jpg  "access plus 1 year"
  ExpiresByType image/png  "access plus 1 year"
  ExpiresByType image/gif  "access plus 1 year"
  ExpiresByType image/webp "access plus 1 year"
  ExpiresByType image/avif "access plus 1 year"

  # Ikony i favicony
  ExpiresByType image/x-icon  "access plus 1 year"
  ExpiresByType image/svg+xml "access plus 1 year"
</IfModule>

Przy tak agresywnym cache kluczowe jest, by nie nadpisywać obrazów „po cichu” pod tym samym adresem. Zamiast podmieniać banner.jpg na serwerze, lepiej wrzucić banner-v2.jpg i zmienić adres w motywie lub stronie. Wtedy przeglądarka pobierze nową wersję, mimo rocznego max-age.

CSS i JS – bez nich strona nie wystartuje szybko

Kaskadowe arkusze stylów i skrypty JS to pliki o mniejszej wadze niż zdjęcia, ale bardzo krytyczne dla szybkości pierwszego renderu. Dobrze ustawiony cache sprawia, że po pierwszym wejściu kolejne podstrony wczytują się „na klik”.

<IfModule mod_expires.c>
  # Arkusze stylów
  ExpiresByType text/css "access plus 1 year"

  # Skrypty JavaScript
  ExpiresByType application/javascript "access plus 1 year"
  ExpiresByType text/javascript        "access plus 1 year"
</IfModule>

Większość nowoczesnych motywów i wtyczek WordPressa dodaje do adresów CSS/JS parametr wersji (np. ?ver=6.5.2), więc długi cache nie blokuje aktualizacji. Gdy wtyczka lub motyw podbije wersję, adres się zmienia, a przeglądarka traktuje go jako nowy plik.

Fonty webowe – małe, ale problematyczne przy złym cache

Czcionki wczytywane z /wp-content/themes/ lub /wp-content/uploads/ to kolejne statyczne pliki, które spokojnie mogą wisieć w cache miesiącami. Dla nich także warto dodać osobne reguły:

<IfModule mod_expires.c>
  # Fonty
  ExpiresByType font/woff2 "access plus 1 year"
  ExpiresByType font/woff  "access plus 1 year"
  ExpiresByType font/ttf   "access plus 1 year"
  ExpiresByType font/otf   "access plus 1 year"
</IfModule>

Jeśli korzystasz z fontów hostowanych lokalnie zamiast z Google Fonts, taki cache robi ogromną różnicę przy nawigacji po stronie i przy powrocie użytkownika po kilku dniach.

Cache-Control dla statyk ustawiany przez mod_headers

Nagłówek Expires to jedno, ale PageSpeed i inne narzędzia często sugerują także konkretny Cache-Control. Można to połączyć z mod_headers, dodając:

<IfModule mod_headers.c>
  <FilesMatch ".(?:ico|gif|jpe?g|png|webp|avif|svg|css|js|woff2?|ttf|otf)$">
    Header set Cache-Control "public, max-age=31536000, immutable"
  </FilesMatch>
</IfModule>

Stały max-age=31536000 (rok) plus immutable mówi przeglądarce: „Ten plik się nie zmieni pod tym adresem, nie sprawdzaj go przy każdym odświeżeniu”. Przy wersjonowanych plikach daje to bardzo przyjemny efekt „rakiety” po pierwszym załadowaniu.

Zacznij od takiego szablonu, przetestuj efekty i dopiero potem skracaj lub wydłużaj czasy według realnych potrzeb serwisu.

Przykładowa, kompletna konfiguracja .htaccess pod cache WordPressa

Układ: najpierw WordPress, potem cache

W typowej instalacji WordPressa w głównym .htaccess widać blok:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Reguły cache najlepiej umieścić nad tym blokiem albo pod nim, ale zawsze poza komentarzami # BEGIN WordPress i # END WordPress. Ten fragment bywa nadpisywany przez sam WordPress, więc własne ustawienia trzymaj osobno.

Przykładowy blok cache do wklejenia

Poniżej przykład sensownej konfiguracji startowej, którą możesz wkleić do .htaccess (np. nad sekcją WordPress) i dopasować do swojego serwisu:

# --- Cache statycznych zasobów ---

<IfModule mod_expires.c>
  ExpiresActive On

  # Domyślna polityka bezpieczeństwa
  ExpiresDefault "access plus 1 month"

  # Obrazy
  ExpiresByType image/jpeg "access plus 1 year"
  ExpiresByType image/jpg  "access plus 1 year"
  ExpiresByType image/png  "access plus 1 year"
  ExpiresByType image/gif  "access plus 1 year"
  ExpiresByType image/webp "access plus 1 year"
  ExpiresByType image/avif "access plus 1 year"
  ExpiresByType image/svg+xml "access plus 1 year"
  ExpiresByType image/x-icon  "access plus 1 year"

  # CSS i JS
  ExpiresByType text/css "access plus 1 year"
  ExpiresByType application/javascript "access plus 1 year"
  ExpiresByType text/javascript        "access plus 1 year"

  # Fonty
  ExpiresByType font/woff2 "access plus 1 year"
  ExpiresByType font/woff  "access plus 1 year"
  ExpiresByType font/ttf   "access plus 1 year"
  ExpiresByType font/otf   "access plus 1 year"

  # Multimedia (np. video wgrane na serwer)
  ExpiresByType video/mp4  "access plus 1 year"
  ExpiresByType audio/mpeg "access plus 1 year"
</IfModule>

<IfModule mod_headers.c>
  # Cache-Control dla statycznych zasobów
  <FilesMatch ".(?:ico|gif|jpe?g|png|webp|avif|svg|css|js|woff2?|ttf|otf|mp4|mp3)$">
    Header set Cache-Control "public, max-age=31536000, immutable"
  </FilesMatch>

  # Bardziej ostrożna polityka dla HTML (nadpisywana ewentualnie przez wtyczki cache)
  <FilesMatch ".(?:html|htm|php)$">
    Header set Cache-Control "no-cache, no-store, must-revalidate"
    Header set Pragma "no-cache"
    Header set Expires "0"
  </FilesMatch>
</IfModule>

Taki zestaw spełnia wymagania większości audytów wydajności, a jednocześnie nie ryzykuje „przyklejenia” starego HTML użytkownikom. Następny krok to przetestowanie kilku podstron i sprawdzenie, czy hosting nie dorzuca dodatkowych, sprzecznych nagłówków.

Radzenie sobie z nagłówkami hostingu i wtyczek

W praktyce może się okazać, że po wprowadzeniu własnych reguł hosting lub wtyczka cache nadal dołącza własne Cache-Control. Wtedy pojawiają się duplikaty, a przeglądarka wybiera ostatni nagłówek. Dobrze jest to uporządkować.

Przykład wymuszenia własnej polityki dla statyk:

<IfModule mod_headers.c>
  <FilesMatch ".(?:ico|gif|jpe?g|png|webp|avif|svg|css|js|woff2?|ttf|otf)$">
    Header unset Cache-Control
    Header set   Cache-Control "public, max-age=31536000, immutable"
  </FilesMatch>
</IfModule>

Jeśli hosting ustawiał inne wartości, po użyciu Header unset priorytet przejmują Twoje reguły. Po takiej zmianie jeszcze raz przejrzyj nagłówki w narzędziach deweloperskich i potwierdź, że widzisz tylko jedną, spójną politykę cache.

Warunkowe stosowanie cache po domenie lub środowisku

Gdy masz kilka środowisk (produkcja, staging, dev) na jednym serwerze, przydaje się różnicowanie polityki cache po nazwie hosta. W dev/test zwykle chcesz krótszy cache, żeby szybciej widzieć zmiany.

<IfModule mod_headers.c>
  # Na środowisku testowym skróć cache statyk do 5 minut
  <If "%{HTTP_HOST} == 'test.twojadomena.pl'">
    <FilesMatch ".(?:ico|gif|jpe?g|png|webp|avif|svg|css|js|woff2?|ttf|otf)$">
      Header set Cache-Control "public, max-age=300"
    </FilesMatch>
  </If>
</IfModule>

Taki trik upraszcza życie przy pracy nad nową skórką albo większą przebudową – nie musisz za każdym razem czyścić agresywnego cache z produkcji w przeglądarce.

Podłączanie kabla sieciowego do serwera w centrum danych
Źródło: Pexels | Autor: panumas nikhomkhai

Wersjonowanie plików: jak pogodzić agresywny cache z aktualizacjami

Dlaczego „1 rok cache” nie blokuje zmian, jeśli zrobisz to mądrze

Na papierze max-age=31536000 wygląda groźnie: „użytkownik zobaczy nowy CSS dopiero za rok”. W praktyce tak się nie dzieje, jeśli adres pliku zmienia się przy każdej istotnej aktualizacji. Wtedy przeglądarka traktuje go jak zupełnie nowy zasób i pobiera świeżą kopię od razu.

Ten mechanizm nazywa się wersjonowaniem zasobów i jest absolutnym fundamentem mocnego cache. Działa zarówno dla CSS/JS, jak i obrazów czy fontów.

Query string w WordPressie: ?ver=1.2.3

WordPress ma wbudowany mechanizm wersjonowania zasobów przez parametr ver. Motywy i wtyczki, które prawidłowo korzystają z funkcji wp_enqueue_style() i wp_enqueue_script(), zwykle generują adresy w stylu:

  • /wp-content/themes/twoj-motyw/style.css?ver=1.4.0
  • /wp-content/plugins/nazwa-wtyczki/assets/script.js?ver=3.2.1

Gdy motyw lub wtyczka podniesie wersję, zmienia się wartość ver. Dla przeglądarki to już inny adres, więc od razu pobiera aktualny plik, ignorując starą wersję w cache.

Dzięki temu możesz ustawić śmiało rok cache w .htaccess, a i tak każda aktualizacja plików frontendu będzie wymuszała pobranie nowych zasobów.

Wersjonowanie w nazwie pliku: style.v123.css

Jeśli twój motyw lub customowy kod nie używa parametru ver, alternatywą jest wersjonowanie w samej nazwie pliku. Przykład:

  • pierwsza wersja: /assets/css/style.v1.css
  • druga wersja: /assets/css/style.v2.css

Przy podmianie stylów zmieniasz zarówno nazwę pliku, jak i odwołanie w motywie (np. w functions.php lub w builderze). Wówczas nawet bardzo agresywny cache nie zatrzyma użytkowników na starej wersji.

Takie podejście bardzo dobrze sprawdza się też przy grafikach hero, dużych bannerach czy ikonach. Zamiast nadpisywać hero.jpg, wgrywasz hero-v3.jpg, aktualizujesz link i masz święty spokój z „przyklejonymi” starymi obrazkami.

Usuwanie query string z adresów a cache

Niektóre wtyczki „optymalizacyjne” usuwają query string z zasobów statycznych (np. zamieniają style.css?ver=1.2.3 na style.css), bo niektóre proxy i CDN-y źle cache’ują adresy z parametrami. To może popsuć wersjonowanie, jeśli mechanizm nie zadba o inną formę odróżniania wersji.

Bezpieczne opcje wyglądają tak:

Gdy plugin usuwa ?ver=, powinien równocześnie przenosić informację o wersji do nazwy pliku (np. style-1.2.3.css) lub do osobnej ścieżki (np. /v123/style.css). Wtedy URL nadal się zmienia przy aktualizacji i cache nie blokuje nowych plików. Jeśli używasz takiej wtyczki, sprawdź w kodzie frontu, czy adresy CSS/JS faktycznie zawierają wersję, a nie kończą się na samym style.css lub script.js bez żadnego odróżnienia.

Dobrym testem jest wymuszenie zmiany w CSS (np. zmiana koloru tła przycisku), podbicie wersji motywu lub zapisanie ustawień wtyczki cache, a potem odświeżenie strony w trybie prywatnym. Jeśli mimo agresywnego cache od razu widzisz nowy styl, mechanizm wersjonowania działa poprawnie. Jeżeli zmiany pojawiają się dopiero po ręcznym odświeżeniu z pominięciem cache (Ctrl+F5), to sygnał, że wersjonowanie gdzieś „uciekło”.

Gdy masz wpływ na kod motywu, trzymaj wersjonowanie jak najbliżej źródła: w parametrach ver przy wp_enqueue_* lub w nazwach plików generowanych przez bundler (Webpack, Vite itp.). Wtyczki od „usuwania query stringów” traktuj jako dodatek, nie główne narzędzie do zarządzania wersjami. Dzięki temu nawet przy zmianie hostingu, CDN czy konfiguracji serwera front będzie przewidywalnie się odświeżał.

Konsekwentne wersjonowanie + mocne nagłówki cache w .htaccess daje fajny efekt: strona ładuje się odczuwalnie szybciej, serwer ma mniej pracy, a Ty nie walczysz z duchami typu „u mnie działa, u klienta nie widać zmian”. Wprowadź te zasady raz porządnie, a każda kolejna aktualizacja WordPressa i motywu będzie dużo spokojniejsza.

Cache HTML i stron dynamicznych WordPressa – gdzie kończy się rola .htaccess

Dlaczego nie cache’ujemy agresywnie HTML w .htaccess

HTML generowany przez WordPressa jest dynamiczny: logowanie, koszyk, formularze, personalizacja, treści chronione hasłem – to wszystko zmienia się w czasie i pomiędzy użytkownikami. Gdyby na poziomie .htaccess ustawić na sztywno rok cache dla .html czy .php, efekty byłyby bolesne:

  • użytkownik widzi stary stan koszyka mimo dodanych produktów,
  • zalogowani dostają treści z widokiem „gościa”,
  • nowe wpisy blogowe pojawiają się z solidnym opóźnieniem,
  • zmiany w treści i SEO (meta, tytuły) nie są widoczne przez długi czas.

Stąd bezpieczna zasada: .htaccess niech cache’uje statykę do oporu, a HTML zostaw w rękach wyspecjalizowanych narzędzi – wtyczek cache, reverse proxy, CDN. To one wiedzą, kiedy można podać kopię strony, a kiedy trzeba wygenerować ją na nowo.

Rola wtyczek cache vs reguły w .htaccess

Typowa wtyczka cache (WP Rocket, LiteSpeed Cache, W3TC, WP Super Cache itd.) robi kilka rzeczy naraz:

  • tworzy statyczne pliki HTML na podstawie dynamicznych stron,
  • ustawia własne nagłówki cache dla HTML i czasem dla CSS/JS,
  • dodaje reguły do .htaccess, by serwer podał HTML z pliku, bez odpalenia PHP,
  • czyści cache po zmianie treści czy aktualizacji motywu/wtyczek.

Twoje reguły cache w .htaccess powinny się z tym uzupełniać, a nie walczyć. Prostym podejściem jest:

  • .htaccess – agresywny cache dla statycznych zasobów (obrazki, CSS, JS, fonty, media),
  • wtyczka cache – logika cache dla HTML (czas życia, wyjątki, czyszczenie po zmianach).

To rozdzielenie upraszcza debugowanie. Gdy jest problem z obrazkami – patrzysz w .htaccess. Gdy coś dzieje się z treścią strony – zaglądasz do ustawień wtyczki cache.

Strategia no-cache dla HTML w .htaccess

Fragment z no-cache dla HTML/PHP z poprzedniej części nie jest przypadkowy. Dla serwowania treści przez wtyczki cache lepszy jest brak agresywnych nagłówków HTML na poziomie serwera, bo:

  • wtyczka sama ustala, jak długo strona może być trzymana w cache przeglądarki lub CDN,
  • łatwiej jest wprowadzić wyjątki (np. dla stron koszyka) bez hakowania .htaccess,
  • unikasz konfliktów, gdy hosting dodaje własne nagłówki.

Jeśli widzisz, że wtyczka cache sama dodaje nagłówki Cache-Control dla HTML (np. max-age=600), możesz całkowicie usunąć sekcję <FilesMatch "…html…php"…> z .htaccess albo ograniczyć ją tylko do przypadków awaryjnych, np. stron logowania.

Cache na poziomie plików HTML generowanych przez wtyczkę

Większość wtyczek cache tworzy statyczne pliki, np.:

  • /wp-content/cache/page_enhanced/twojadomena.pl/index.html
  • /wp-content/cache/wp-rocket/twojadomena.pl/category/aktualnosci/index-https.html

Do tych plików zwykle nie stosujesz osobnych reguł cache w .htaccess, bo wtyczka sama generuje odpowiednie nagłówki przy podawaniu zawartości. Natomiast .htaccess może decydować, czy w ogóle WordPress ma być wołany. Przykładowy schemat:

<IfModule mod_rewrite.c>
  RewriteEngine On

  # Jeśli istnieje statyczna kopia HTML wygenerowana przez wtyczkę – podaj ją bez WordPressa
  RewriteCond %{REQUEST_METHOD} GET
  RewriteCond %{QUERY_STRING}  =""
  RewriteCond %{REQUEST_URI}   !^/wp-admin
  RewriteCond %{REQUEST_URI}   !^/wp-login.php
  RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/page_enhanced%{REQUEST_URI}index.html -f
  RewriteRule ^ /wp-content/cache/page_enhanced%{REQUEST_URI}index.html [L]
</IfModule>

Reguły różnią się między wtyczkami, ale idea jest ta sama: jeśli jest gotowy plik HTML, Apache podaje go od ręki. To daje efekt turbo-HTML bez mieszania w samych nagłówkach cache dla całego serwisu.

Wyjątki: strony, których nie wolno cache’ować

Są miejsca, gdzie nawet wtyczka cache powinna powiedzieć „stop”. Typowe przykłady:

  • /wp-login.php i panel admina,
  • strony koszyka, płatności, konto klienta (WooCommerce i podobne),
  • strony z dynamicznymi formularzami krok-po-kroku,
  • panele partnerów, intranet, treści tylko dla wybranych ról.

Większość dobrych wtyczek cache ma wbudowane wyjątki dla WooCommerce, Easy Digital Downloads itd. Możesz też dodać własne reguły, np. dla ścieżki /panel-klienta/. W .htaccess jedynie uzupełniasz ochronę, np. wyłączając jakiekolwiek kombinacje cache’u po ścieżkach:

<IfModule mod_headers.c>
  <LocationMatch "^/wp-login.php|^/wp-admin|^/panel-klienta">
    Header set Cache-Control "no-store, no-cache, must-revalidate, max-age=0"
    Header set Pragma "no-cache"
    Header set Expires "0"
  </LocationMatch>
</IfModule>

Jeżeli masz wątpliwość, czy daną podstronę wolno „przykleić” do cache, załóż ochronę – lepiej minimalnie wolniej, niż pokazać cudze dane nie tej osobie, co trzeba.

Interakcja z CDN: kto naprawdę kontroluje cache HTML

Gdy do gry wchodzi CDN (Cloudflare, Bunny, KeyCDN i podobne), robi się ciekawiej. Pojawiają się trzy warstwy:

  1. przeglądarka użytkownika,
  2. CDN (proxy na brzegu),
  3. Twój serwer Apache + .htaccess + WordPress + wtyczka cache.

CDN często stosuje własną logikę cache:

  • ignoruje niektóre nagłówki z serwera,
  • używa „page rules” lub „caching rules” do decydowania, który HTML cache’ować,
  • cache’uje tylko dla niezalogowanych użytkowników.

Dlatego przy CDN warto:

  • ustalić, czy HTML ma być cache’owany po stronie CDN, czy tylko na serwerze (wtyczką),
  • sprawdzić, czy CDN nie nadpisuje nagłówka Cache-Control dla HTML, który ustawiasz lokalnie,
  • upewnić się, że logowanie, koszyk i konta klientów są wyłączone z cache CDN.

Prosty test: w narzędziach deweloperskich sprawdź nagłówki odpowiedzi. Jeśli widzisz coś w stylu cf-cache-status: HIT albo cdn-cache: HIT przy HTML, to znak, że CDN serwuje stronę z własnego cache. Wtedy wszelkie zmiany w .htaccess wpływają głównie na komunikację serwer ↔ CDN, a nie bezpośrednio na użytkownika.

Świadomie ustawiona relacja „CDN + wtyczka + .htaccess” ściąga ogromny ruch z serwera, więc poświęcenie kilkunastu minut na testy zwróci się bardzo szybko.

Diagnostyka: jak sprawdzić, co naprawdę jest cache’owane

Bez rzetelnych testów cache łatwo o złudne wnioski w stylu „na pewno nie działa”. Kilka konkretnych kroków, które porządkują obraz:

  1. Tryb prywatny / inna przeglądarka
    Zmiany najpierw sprawdzaj w oknie incognito albo w przeglądarce, której „nie używa” klient. Dzięki temu unikasz lokalnego cache z poprzednich wizyt.
  2. Narzędzia deweloperskie → zakładka Network
    Otwórz zakładkę Network, zaznacz „Disable cache” i odśwież. Spójrz na kolumnę „Size” i „Status”: (from disk cache), (from memory cache) oznacza, że przeglądarka korzysta z cache. W szczegółach odpowiedzi zobacz nagłówki Cache-Control, Expires, Age.
  3. curl z linii komend
    Jeśli masz SSH, możesz wykonać:

    curl -I https://twojadomena.pl/

    i sprawdzić, co serwer naprawdę wysyła bez pośredników. To szczególnie przydatne przy CDN – czasem warto dodać nagłówek Cache-Control: no-cache w zapytaniu, by wymusić odświeżenie.

  4. LOGI wtyczki cache
    Sporo wtyczek pokazuje, czy dana strona została zaserwowana z cache. Jeśli w logu widać „cache HIT”, a zmiana treści się nie pokazuje, to sygnał, że TTL jest zbyt długi albo czyszczenie cache nie obejmuje tej podstrony.

Zrób sobie mały rytuał: po każdej większej zmianie w polityce cache przeleć ten check-list. Zaoszczędzisz godziny domysłów i „czyściłem wszystko, a i tak nie działało”.

Bezpieczne czyszczenie cache przy większych aktualizacjach

Aktualizacja WordPressa, motywu, kluczowych wtyczek – to momenty, kiedy cache potrafi namieszać. Zamiast czyścić wszystko „w ciemno”, podejdź do tego świadomie:

  • wtyczka cache – wyczyść cache stron (HTML) i, jeśli to możliwe, cache minifikowanych CSS/JS,
  • CDN – zrób „Purge Cache” tylko dla HTML lub dla wybranych ścieżek (np. /* przy dużych zmianach),
  • przeglądarka – wymuś twarde odświeżenie (Ctrl+F5), ale docelowo polegaj na wersjonowaniu zasobów, a nie na ręcznych sztuczkach.

Samego .htaccess zwykle nie modyfikujesz przy każdej aktualizacji. Raz dobrze ustawiona polityka cache dla statycznych zasobów powinna działać latami – resztę kontrolują wersje plików i narzędzia nad cache HTML.

Przy większym rebrandingu czy nowej skórce zrób jedną porządną rundę: czyść cache wtyczki, CDN, otwórz szablon w trybie prywatnym, sprawdź nagłówki. Gdy widzisz wszędzie spójną politykę Cache-Control, możesz spokojnie oddać stronę użytkownikom.

Typowe pułapki przy ustawianiu cache w .htaccess

Dobrze ustawiony cache przyspiesza stronę, ale kilka klasycznych błędów potrafi zepsuć efekt i wygenerować „niewyjaśnione” problemy. Złapanie ich od razu oszczędza sporo nerwów.

Zbyt krótki TTL – serwer dalej dusi się pod obciążeniem

Częsta sytuacja: cache jest, ale praktycznie nie działa, bo pliki wygasają po kilkunastu minutach. Każde wejście po przerwie znowu uderza w serwer. Przykład zbyt ostrożnej konfiguracji:

<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType image/jpeg "access plus 1 hour"
  ExpiresByType text/css   "access plus 1 hour"
  ExpiresByType application/javascript "access plus 1 hour"
</IfModule>

Na pierwszy rzut oka wygląda dobrze, ale w praktyce przeglądarka regularnie odświeża pliki. Przy wersjonowaniu zasobów śmiało podbij czasy do tygodni czy miesięcy:

<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType image/jpeg  "access plus 6 months"
  ExpiresByType image/png   "access plus 6 months"
  ExpiresByType image/gif   "access plus 6 months"
  ExpiresByType image/webp  "access plus 6 months"
  ExpiresByType text/css    "access plus 1 year"
  ExpiresByType application/javascript "access plus 1 year"
</IfModule>

Podbij TTL, jeśli masz już sensowne wersjonowanie plików – od razu poczujesz różnicę w stabilności strony przy większym ruchu.

Konfliktujące nagłówki z hostingu lub innymi modułami

Wielu hostingodawców dorzuca własne reguły cache na poziomie Apache lub panelu (np. „Przyspiesz stronę”). Efekt: w kodzie masz jedno, w odpowiedzi inne nagłówki. Typowe zderzenie:

  • Twoje Cache-Control: public, max-age=31536000 dla CSS,
  • globalne Cache-Control: no-cache z panelu hostingu.

Przeglądarka widzi dwa nagłówki i zachowuje się różnie, zależnie od implementacji. Żeby uniknąć chaosu:

  • sprawdź w panelu hostingu, czy nie ma równoległych „opcji cache” (i wyłącz je, jeśli sterujesz wszystkim z .htaccess),
  • używaj Header unset, gdy chcesz „wyczyścić” poprzednie wartości:
<IfModule mod_headers.c>
  <FilesMatch ".(css|js)$">
    Header unset Cache-Control
    Header set Cache-Control "public, max-age=31536000, immutable"
  </FilesMatch>
</IfModule>

Po każdej większej zmianie zawsze zerkaj w nagłówki odpowiedzi – wtedy konflikty wychodzą na wierzch błyskawicznie.

Reguły, które łapią „za dużo” i psują panel admina

Mocne reguły typu „cache’uj wszystko na maksa” bywają kuszące, ale bez wyjątków uderzają w obszary, gdzie cache jest wręcz szkodliwy – jak admin czy formularze. Przykład problematycznej konstrukcji:

<IfModule mod_headers.c>
  Header set Cache-Control "public, max-age=31536000"
</IfModule>

Taki blok zastosowany globalnie dotknie HTML, /wp-admin/, a nawet strony logowania. Lepiej zawężać reguły:

<IfModule mod_headers.c>
  <FilesMatch ".(ico|jpe?g|png|gif|webp|css|js|woff2?)$">
    Header set Cache-Control "public, max-age=31536000, immutable"
  </FilesMatch>
</IfModule>

Im precyzyjniejsze dopasowanie, tym mniejsze ryzyko dziwnych efektów w panelu admina. Zadbaj o to raz porządnie i zapomnij o niespodziankach typu „nie mogę się wylogować”.

Brak spójności między Expires a Cache-Control

Niektóre konfiguracje zawierają jednocześnie nagłówki Expires i Cache-Control. To w porządku, o ile mówią to samo. Błąd pojawia się, gdy czasy są sprzeczne:

# Przykład niekonsekwentny:
Header set Cache-Control "public, max-age=3600"
ExpiresActive On
ExpiresDefault "access plus 7 days"

Przeglądarka dostaje dwa różne sygnały co do czasu życia zasobu. Staraj się, by oba mechanizmy były zgrane:

<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType text/css "access plus 1 year"
</IfModule>

<IfModule mod_headers.c>
  <FilesMatch ".css$">
    Header set Cache-Control "public, max-age=31536000, immutable"
  </FilesMatch>
</IfModule>

Przyjmij jedną, jasną logikę – wtedy zachowanie po stronie przeglądarki staje się przewidywalne.

Zaawansowane techniki cache w .htaccess dla WordPressa

Gdy podstawy są ogarnięte, można dołożyć kilka sprytniejszych trików. Nie są obowiązkowe, ale często dorzucają te brakujące kilka procent szybkości i stabilności.

Użycie dyrektywy immutable dla statycznych zasobów

Nowoczesne przeglądarki obsługują parametr immutable w nagłówku Cache-Control. Informuje on, że plik nie zmieni się w trakcie trwania TTL, więc przeglądarka nie musi nawet sprawdzać, czy jest nowsza wersja na serwerze. Ma to sens przy mocnym wersjonowaniu:

<IfModule mod_headers.c>
  <FilesMatch ".(css|js|png|jpe?g|gif|webp|svg|woff2?)$">
    Header set Cache-Control "public, max-age=31536000, immutable"
  </FilesMatch>
</IfModule>

Warunek: zmieniasz nazwę pliku przy każdej jego istotnej edycji. Jeśli wiesz, że czasem podmieniasz plik „po cichu”, lepiej odpuścić immutable lub obniżyć TTL.

Segmentowanie cache po ścieżkach (np. /wp-content/uploads/)

Nie wszystkie zasoby muszą mieć taki sam czas życia. Czasem zdjęcia produktów chcesz trzymać bardzo długo, a pliki z katalogu aktualności trochę krócej. .htaccess pozwala rozbić logikę cache po folderach:

<IfModule mod_expires.c>
  ExpiresActive On

  # Uploady – zwykle stabilne
  <Location "/wp-content/uploads/">
    ExpiresDefault "access plus 1 year"
  </Location>

  # Pliki tymczasowe / eksperymentalne
  <Location "/media-test/">
    ExpiresDefault "access plus 1 day"
  </Location>
</IfModule>

Jeśli nie chcesz bawić się w wiele katalogów, możesz przynajmniej różnicować typy MIME – np. fonty i grafiki z długim TTL, a pliki JSON lub feedy z krótkim.

Cache warunkowy w zależności od typu klienta (przeglądarka vs bot)

Niektóre boty (np. do monitoringu) mogą generować ruch pomijający cache, ale są też takie, które korzystają z niego bardzo dobrze. Zaawansowane konfiguracje wykorzystują RewriteCond %{HTTP_USER_AGENT}, aby stosować inne nagłówki dla konkretnych agentów. Prosty przykład ukierunkowany na debugowanie:

<IfModule mod_headers.c>
  # Dla Google PageSpeed Insights – skróć TTL, żeby szybko widzieć zmiany
  SetEnvIfNoCase User-Agent "Chrome-Lighthouse" lighthouse_user=1

  <FilesMatch ".(css|js|png|jpe?g|gif|webp|svg|woff2?)$">
    Header set Cache-Control "public, max-age=31536000, immutable" env=!lighthouse_user
    Header set Cache-Control "public, max-age=60" env=lighthouse_user
  </FilesMatch>
</IfModule>

To już „geek level”, ale bywa pomocne przy intensywnych testach narzędziami typu Lighthouse, gdzie chcesz szybko weryfikować zmiany bez wyłączania produkcyjnego cache.

Integracja cache z kompresją (mod_deflate / mod_brotli)

Cache sam w sobie jest świetny, ale w parze z kompresją dostarcza dodatkowe przyspieszenie – zwłaszcza przy wolniejszych łączach mobilnych. W .htaccess możesz aktywować kompresję i jednocześnie dopieścić nagłówki:

<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/plain text/html text/xml text/css application/javascript application/json
</IfModule>

<IfModule mod_headers.c>
  <FilesMatch ".(css|js|html)$">
    Header append Vary "Accept-Encoding"
  </FilesMatch>
</IfModule>

Nagłówek Vary: Accept-Encoding informuje cache pośrednie (CDN, proxy), że muszą rozróżniać wersje skompresowane i nieskompresowane. Raz ustawiony działa w tle i nie wymaga już ręcznej obsługi.

Organizacja i utrzymanie konfiguracji .htaccess w dłuższej perspektywie

Najlepszy .htaccess to taki, którego nie trzeba dotykać przy każdej drobnej zmianie w serwisie. Odrobina porządku na starcie robi tu ogromną robotę.

Komentowanie i sekcjonowanie reguł

Za kilka miesięcy nawet własne reguły potrafią wyglądać obco. Proste komentarze i logiczne bloki bardzo ułatwiają życie:

# =========================
# CACHE: statyczne zasoby
# =========================
<IfModule mod_expires.c>
  ...
</IfModule>

# =========================
# CACHE: HTML / no-cache
# =========================
<IfModule mod_headers.c>
  ...
</IfModule>

# =========================
# REWRITE: WordPress
# =========================
<IfModule mod_rewrite.c>
  ...
</IfModule>

Kilka linii komentarza oszczędza godzin szukania „kto to kiedy w ogóle dodał”. Zrób to raz porządnie i przyszłe zmiany będą spokojniejsze.

Środowiska staging / dev z inną polityką cache

Na serwerach stagingowych czy developerskich agresywny cache przeszkadza, bo wymusza ciągłe czyszczenie przeglądarki. Jeśli masz osobną subdomenę (np. dev.twojadomena.pl), możesz stworzyć osobny .htaccess z „luźniejszym” podejściem:

<IfModule mod_headers.c>
  # Na dev – krótkie TTL, szybkie odświeżanie
  <FilesMatch ".(css|js|png|jpe?g|gif|webp|svg|woff2?)$">
    Header set Cache-Control "public, max-age=60"
  </FilesMatch>
</IfModule>

Dzięki temu na produkcji użytkownicy dostają turbo wersję strony, a na devie Ty pracujesz bez frustracji związanej z „zaciętym” cache.

Kontrola wersji konfiguracji (Git / kopie zapasowe)

.htaccess to zwykły plik tekstowy, więc świetnie nadaje się do trzymania w Gicie razem z motywem lub child theme. Minimalny workflow:

  1. każdą większą zmianę configu opisujesz w commicie,
  2. testujesz na stagingu,
  3. po akceptacji wrzucasz na produkcję.

Jeśli nie korzystasz z Gita, zrób chociaż ręczne snapshoty: .htaccess-2024-04-26-backup. Przy problemach z cache wrócisz w kilka sekund do poprzedniej, działającej wersji, zamiast kleić konfigurację z pamięci.

Minimalizm: mniej kombinacji, więcej efektu

Jak w wielu technicznych tematach, łatwo przesadzić. Rozbudowane, wielopiętrowe reguły wcale nie gwarantują lepszej wydajności, za to zwiększają szansę na błąd. Dobra zasada:

  • max-age długi dla statycznych zasobów + wersjonowanie plików,
  • no-cache / kontrola HTML pozostawiona wtyczce + ewentualny CDN,
  • w .htaccess tylko to, co naprawdę musi być na poziomie serwera.

Zacznij od prostej, czytelnej konfiguracji i dopiero przy konkretnych potrzebach dokładnie analizuj, czy warto dorzucać kolejne warstwy logiki. Dzięki temu cache stanie się Twoim sprzymierzeńcem, a nie kolejnym źródłem zagadek.

Najważniejsze wnioski

  • Polityka cache w .htaccess decyduje, jak długo przeglądarka trzyma statyczne pliki (obrazy, CSS, JS, fonty) lokalnie, dzięki czemu przy kolejnych wizytach ładuje głównie HTML zamiast wszystkiego od zera.
  • Cache przeglądarki (browser cache) to inna warstwa niż cache po stronie serwera (wtyczki, Redis, Memcached) – oba mechanizmy muszą działać razem, bo żaden samodzielnie nie zapewni pełnej poprawy wydajności.
  • WordPress generuje bardzo dużo statycznych zasobów (motywy, wtyczki, biblioteki, media), więc brak sensownej polityki cache prowadzi do dziesiątek niepotrzebnych żądań przy każdym wejściu i realnego „zamulenia” strony.
  • Odpowiednie nagłówki Cache-Control i Expires ustawione w .htaccess bezpośrednio poprawiają LCP, FCP i pośrednio TBT, co przekłada się na lepsze wyniki w PageSpeed Insights, lepsze Core Web Vitals i mocniejszą pozycję SEO.
  • Nawet kilka linijek w .htaccess potrafi znacząco odciążyć hosting – powracający użytkownicy pobierają głównie z cache, a serwer obsługuje większy ruch bez zmiany planu i bez „jęczenia” przy każdym piku odwiedzin.
  • Brak lub zła konfiguracja cache w .htaccess powoduje typowe ostrzeżenia typu „Leverage browser caching” – usunięcie ich to szybki, tani i bardzo skuteczny krok, który czuć w codziennym działaniu strony.
  • .htaccess działa na serwerach Apache/LiteSpeed i pozwala lokalnie nadpisać konfigurację – jeśli masz z nim dostęp, masz w ręku prosty, ale mocny przełącznik wydajności, który po prostu opłaca się włączyć.

Następne kroki w tym temacie: