Prevent Browser Caching

Najczęściej zadawane pytania

Czy wpływa na szybkość witryny lub SEO?

Może tylko pomóc. W zalecanym trybie automatycznym pamięć podręczna przeglądarki działa w pełni — powracający odwiedzający wczytują CSS/JS ze swojej pamięci podręcznej, dopóki plik naprawdę się nie zmieni, więc kolejne wizyty są tak szybkie jak zawsze (szybsze niż przy domyślnym zachowaniu starych wersji 2.x, które pobierały zasoby ponownie przy każdej wizycie). A opcjonalna funkcja „Przyspiesz” idzie dalej: roczne nagłówki pamięci podręcznej dla twoich plików statycznych — czyli dokładnie to, czego wymaga audyt Lighthouse „efficient cache policy”. Koszt po stronie serwera to kilka odczytów czasu modyfikacji plików na stronę — pomijalny. Parametr „ver” w adresie URL to ten sam mechanizm, którego używa sam WordPress, wyszukiwarki są do niego doskonale przyzwyczajone, a wtyczka nie zmienia treści stron, kodu HTML ani adresów URL widzianych przez roboty.

Czy działa razem z wtyczkami pamięci podręcznej strony?

Tak — a od wersji 3.1.0 mogą aktywnie współpracować. Wersjonowane adresy zasobów trafiają do zapisanego kodu HTML jak wszystkie inne, więc udostępnianie nieaktualnego HTML oznaczało wcześniej udostępnianie razem z nim starych wersji zasobów. Gdy na stronie ustawień zaznaczone jest pole „Czyść także pamięć podręczną strony”, naciśnięcie „Zaktualizuj wersje” (na pasku narzędzi, na stronie ustawień, przez WP-CLI lub przez możliwość z Abilities API) czyści również pamięć podręczną wykrytej wtyczki, dzięki czemu ten kod HTML jest generowany na nowo z nowymi wersjami. Obsługiwane: WP Rocket, LiteSpeed Cache, W3 Total Cache, WP Super Cache, WP Fastest Cache, WP-Optimize, Breeze, Cache Enabler, Hummingbird, SiteGround Optimizer, Swift Performance, Comet Cache. To pole jest domyślnie wyłączone — pamięć podręczna innej wtyczki jest ruszana tylko wtedy, gdy to włączysz (jeśli na przykład twoja pamięć podręczna strony obsługuje wyłącznie niezalogowanych odwiedzających, możesz woleć nie odbudowywać jej przy każdej aktualizacji). Tak czy inaczej raport pokazywany po każdej aktualizacji mówi, czy pamięć podręczna strony została wyczyszczona, a aktualizacja wersji zawsze dochodzi do końca, nawet jeśli czyszczenie się nie powiedzie. Wtyczka nadal pozostawia nagłówki pamięci podręcznej HTML wtyczce pamięci podręcznej strony.

Czy działa z kreatorami stron (Elementor, Divi, Beaver Builder…)?

Tak. Kreatory stron generują swój CSS jako prawdziwe pliki (zwykle w katalogu uploads) i przy każdej regeneracji nadają im nową wersję opartą na czasie — Elementor na przykład udostępnia CSS poszczególnych stron jako post-123.css?ver=<generation time>, a ta wersja zmienia się za każdym razem, gdy plik jest zapisywany na nowo. Dodatkowo w trybie automatycznym ta wtyczka dokłada własny składnik wersji z czasu modyfikacji pliku, więc nawet plik kreatora nadpisany w miejscu natychmiast odświeża swoją pamięć podręczną. Razem sprawia to, że opcja długotrwałej pamięci podręcznej jest bezpieczna także dla plików kreatorów: ich adresy URL zawsze zmieniają się wtedy, gdy zmienia się ich treść.

Czy działa z wtyczkami do minifikacji (Autoptimize, WP-Optimize)?

Tak — sprawdzone z obiema. Narzędzia do minifikacji umieszczają w nazwach generowanych plików skrót zawartości i czas modyfikacji plików źródłowych, więc te pliki same odświeżają swoją pamięć podręczną przez nazwę — a tutejsza opcja długotrwałej pamięci podręcznej to dla nich dokładnie właściwa polityka: zminifikowane pliki CSS/JS z WP-Optimize dostają roczne nagłówki i zmieniają adres URL zawsze, gdy zmieni się plik źródłowy, natomiast Autoptimize udostępnia swój katalog pamięci podręcznej z własną, równoważną roczną polityką immutable, więc te dwa mechanizmy nigdy ze sobą nie walczą. Pliki, których minifikator nie rusza, zachowują parametr „ver” tej wtyczki — nawet gdy włączona jest w nim opcja usuwania parametrów zapytania (ta wtyczka celowo dodaje swoją wersję po nich).

Czy tryb automatyczny czyści moją pamięć podręczną strony, gdy plik się zmieni?

Nie — i to celowo, a nie przez przeoczenie. W trybie automatycznym wersja pochodzi z czasu modyfikacji pliku, odczytywanego w chwili renderowania strony; nic „nie dzieje się” na serwerze, gdy wysyłasz zmieniony plik, więc nie ma zdarzenia, przy którym można by wyczyścić pamięć podręczną strony. Zapisany kod HTML zachowuje stare wersje zasobów, dopóki pamięć podręczna strony nie wygaśnie albo nie zostanie wyczyszczona. Po większych zmianach naciśnij „Zaktualizuj wersje” — przy włączonej opcji „Czyść także pamięć podręczną strony” jedno kliknięcie zaktualizuje wersje i wyczyści wykrytą pamięć podręczną strony.

Jak naprawić wynik audytu Lighthouse „Serve static assets with an efficient cache policy”?

Włącz „Pozwól przeglądarkom przechowywać pliki statyczne przez rok” w sekcji „Przyspiesz” na stronie ustawień (opcja jest dostępna, gdy wersjonowanie CSS/JS jest włączone). Wtyczka udostępnia pliki statyczne z nagłówkiem Cache-Control: public, max-age=31536000, immutable, czyli dokładnie tak, jak wymaga tego audyt — i jest to tutaj bezpieczne, ponieważ wtyczka zmienia adres URL pliku za każdym razem, gdy plik się zmienia, więc odwiedzający nigdy nie utkną ze starą kopią. Po włączeniu strona ustawień informuje, czy nagłówki zostały zweryfikowane na twojej witrynie. Ta sama opcja rozwiązuje też starszą wersję tego zalecenia — „Leverage browser caching” — nadal pokazywaną przez GTmetrix i inne narzędzia testujące.

Czy wtyczka zmienia mój plik .htaccess?

Tylko jeśli włączysz opcję długotrwałej pamięci podręcznej i wyłącznie za pomocą API samego WordPressa (tego samego, którego WordPress używa do bezpośrednich odnośników): to wyraźnie oznaczony blok między # BEGIN Prevent Browser Caching a # END Prevent Browser Caching. Blok jest aktualizowany, gdy zmieniasz powiązane ustawienia, i usuwany w całości, gdy wyłączysz tę opcję, wyłączysz wtyczkę lub ją usuniesz. W sieci witryn, na nginx oraz gdy zdefiniujesz stałą PBC_DISABLE_HTACCESS_WRITE, wtyczka nigdy nie zapisuje tego pliku — zamiast tego pokazuje reguły do dodania ręcznie.

Moja wtyczka pamięci podręcznej już dodaje nagłówki pamięci podręcznej przeglądarki (expires). Czy potrzebuję obu?

Nie — zarządzaj nimi w jednym miejscu. Jeśli twoja wtyczka pamięci podręcznej już udostępnia długotrwałe nagłówki dla plików statycznych, możesz pozostawić tutejszą opcję „Przyspiesz” wyłączoną: wersjonowanie i tak dba o aktualność. Nic się nie zepsuje, jeśli obie zostaną włączone — reguły nie kolidują ze sobą, po prostu wygrywa późniejszy blok — ale jedno źródło jest czystsze. Zaletą zarządzania nimi tutaj jest to, że nagłówki są powiązane z wersjonowaniem (adresy URL zmieniają się zawsze, gdy zmieniają się pliki, więc roczna pamięć podręczna nigdy nie pokaże nikomu przestarzałego pliku), a strona ustawień sprawdza, czy nagłówki faktycznie działają na twoim serwerze.

Strona ustawień informuje, że nagłówki pamięci podręcznej się nie pojawiają. Co teraz?

Reguły są na miejscu, ale twój serwer ich nie zastosował — najczęściej Apache u hostingodawcy nie ma modułów mod_headers/mod_expires albo nadpisywanie przez .htaccess jest wyłączone. Poproś hostingodawcę o ich włączenie albo skopiuj reguły pokazane na stronie ustawień do konfiguracji serwera. Zapisanie ustawień uruchamia sprawdzenie ponownie. Dopóki nagłówki nie działają, nic się nie psuje — przeglądarki po prostu korzystają z pamięci podręcznej tak jak wcześniej.

Plik wykluczony z wersjonowania — czy nadal będzie przechowywany przez rok?

Jeśli to lokalny plik CSS/JS udostępniany z twojej witryny: tak — reguły długotrwałej pamięci podręcznej działają na podstawie rozszerzenia pliku i nie widzą twojej listy wykluczeń. Wykluczenia to prawie zawsze zewnętrzne adresy URL (skrypty płatności, CDN), których te reguły nigdy nie dotyczą — ale jeśli wykluczasz lokalny plik dlatego, że nie może być długo przechowywany w pamięci podręcznej, albo pozostaw opcję długotrwałej pamięci podręcznej wyłączoną, albo dodaj węższą regułę dla tego pliku w konfiguracji serwera.

Dlaczego pliki zewnętrzne domyślnie nie dostają wersji?

Kilka usług zewnętrznych — zwłaszcza skrypty płatności (PayPal, Braintree, Authorize.net) — odrzuca żądania z nieoczekiwanym parametrem zapytania „ver”, co potrafiło psuć formularze zamówienia. Od wersji 3.0.0 domyślnie wersjonowane są tylko pliki lokalne; jest pole wyboru, które ponownie obejmuje zewnętrzne adresy URL, jeśli ktoś na tym polegał.

Czy przez tę wtyczkę tracę pamięć podręczną przeglądarki?

Nie w zalecanym trybie automatycznym. Pliki są normalnie przechowywane w pamięci podręcznej; wersja zmienia się tylko wtedy, gdy zmieni się sam plik. Tryb „przy każdym wczytaniu strony” faktycznie wyłącza przechowywanie CSS/JS w pamięci podręcznej — używaj go tylko podczas aktywnej pracy nad witryną.

Wersja nie aktualizuje się co X minut, mimo takiego ustawienia. Dlaczego?

Przestarzały tryb „co N minut” działa osobno dla każdego odwiedzającego, przy użyciu pliku ciasteczka — nie przebudowuje niczego na serwerze przez cron. Każdy odwiedzający dostaje nową wersję zasobów nie częściej niż co wybrany odstęp czasu. Od wersji 3.0.0 tryb automatyczny jest lepszym wyborem w niemal każdym przypadku.

Czy wersjonuje obrazki w treści wpisów?

Tak, gdy włączona jest opcja „Obrazki”: adresy URL załączników renderowane przez WordPressa dostają wersje natychmiast, a adresy obrazków wpisane na stałe w treści wpisów dostają ogólnowitrynową wersję multimediów po pierwszej aktualizacji (przycisk „Zaktualizuj wersje” albo zastąpienie pliku multimedialnego).

Mój CDN ignoruje parametry zapytania.

Wtedy wersjonowanie przez parametr zapytania nie odświeży pamięci podręcznej tego CDN dla tych plików. Skonfiguruj CDN tak, aby uwzględniał parametry zapytania w kluczu pamięci podręcznej, albo użyj wersjonowania przez nazwę pliku (na przykład zastąp plik nową nazwą).

Po wyłączeniu wtyczki moja witryna pokazuje błąd.

Jeśli w pliku functions.php swojego motywu dodano prevent_browser_caching( ... ), to ten wiersz wywołuje funkcję dostarczaną przez tę wtyczkę. Po wyłączeniu wtyczki funkcja przestaje istnieć, więc PHP zatrzymuje się z błędem krytycznym. Są dwa sposoby, aby to naprawić: przejść na filtr pbc_assets_version (zalecane — on nigdy tego nie powoduje) albo owinąć wywołanie w if ( function_exists( 'prevent_browser_caching' ) ) { ... }. Zobacz „Dla programistów” powyżej.