...
logo hostingu

WordPress i buforowanie przeglądarki - często skonfigurowane nieprawidłowo

Buforowanie przeglądarki WordPress często powoduje powolne odpowiedzi, ponieważ operatorzy muszą Nagłówek pamięci podręcznej ustawione nieprawidłowo lub w ogóle niekontrolowane. Pokażę ci, jak typowe błędne konfiguracje zwracają 200 zamiast 304, dlaczego brakuje TTL i jak mogę poprawnie skonfigurować buforowanie w WordPress. Wydajność wykończenie.

Punkty centralne

  • Długi TTL dla zasobów statycznych zapobiega niepotrzebnym żądaniom.
  • Wyraźna separacja statycznych i dynamicznych ścieżek chroni administratora i logowanie.
  • Jeden system nie mieszaj konkurujących ze sobą wtyczek buforujących.
  • Sprawdź nagłówki z DevTools i statusem 304.
  • Buforowanie serwera i pamięci podręcznej przeglądarki.

Jak naprawdę działa buforowanie przeglądarki w WordPress

Przeglądarka przechowuje pliki statyczne lokalnie, dzięki czemu nie trzeba ich ponownie ładować. Żądania HTTP. Podczas drugiej wizyty odczytuje obrazy, CSS i JS z pamięci lokalnej i prosi serwer tylko o zmiany. Zmniejsza to ilość danych, skraca czas odpowiedzi, a przewijanie jest bardziej responsywne. płyn na. Jeśli nie ma jasnych instrukcji, przeglądarka przeładowuje się całkowicie za każdym razem i cierpi na tym czas interakcji. Prawidłowo ustawione nagłówki kontroli pamięci podręcznej umożliwiają walidację 304, zmniejszają przepustowość i zmniejszają obciążenie PHP i bazy danych. Używam tego konsekwentnie, ponieważ powtarzający się użytkownicy w szczególności odnoszą największe korzyści z trwałego buforowania.

Dlaczego konfiguracja często zawodzi

Wiele witryn dostarcza statyczne pliki z absurdalnie krótkimi plikami maksymalny wiek-values. Niektóre wtyczki nadpisują wzajemnie swoje .htaccess i ustawiają sprzeczne dyrektywy. Witryna często nieprawidłowo oznacza ścieżki administratora, powodując, że zawartość z /wp-admin lub /wp-login.php trafia do pamięci podręcznej w sposób niezamierzony, a sesje kolidują ze sobą. Sprawdzam również różnicę między pierwszym a powtarzającym się wywołaniem, ponieważ jasno wyjaśnia to rzeczywiste doświadczenia użytkowników; porównanie pasuje do tego Pierwsze połączenie a powracający rozmówca. Jeśli nadal używasz ciągów zapytań bez wersjonowania, będziesz tworzyć stare pliki w pamięci i zastanawiać się nad przestarzały Style.

Poprawne ustawienie nagłówków pamięci podręcznej WP

Kontroluję czas trwania za pomocą Kontrola pamięci podręcznej i Expires, a także unikam niejednoznacznych ETagów w środowiskach wieloserwerowych. W przypadku Apache ustawiam Expires na znaczące wartości i definiuję „public, max-age“ dla zasobów. W przypadku Nginx dodaję dyrektywy add_header i upewniam się, że HTML ma krótki czas lub „no-store“, jeśli zawartość jest spersonalizowana. Dezaktywuję również nagłówki ETag, jeśli load balancery lub proxy nie generują tych wartości konsekwentnie. W ten sposób wymuszam jasne zachowanie w przeglądarce i unikam Unieważnienia przy każdym kliknięciu.

ExpiresActive On
  ExpiresByType image/jpeg "dostęp plus 1 rok"
  ExpiresByType image/png "dostęp plus 1 rok"
  ExpiresByType text/css "dostęp plus 1 miesiąc"
  ExpiresByType application/javascript "dostęp plus 1 miesiąc"



  Header set Cache-Control "public, max-age=31536000" "expr=%{CONTENT_TYPE} =~ m#^(image/|font/|application/javascript)#"
  Header set Cache-Control "no-cache, no-store, must-revalidate" "expr=%{REQUEST_URI} =~ m#(wp-admin|wp-login.php)#"
  Nieustawiony ETag nagłówka
# Nginx
location ~* .(jpg|jpeg|png|gif|ico|webp|avif|css|js|woff2?)$ {
    add_header Cache-Control "public, max-age=31536000";
}
location ~* /(wp-admin|wp-login.php)$ {
    add_header Cache-Control "no-store";
}

Rozszerzone dyrektywy kontroli pamięci podręcznej w codziennym życiu

Oprócz „max-age“ i „no-store“, nowoczesne dyrektywy zapewniają zauważalną stabilność. „immutable“ sygnalizuje przeglądarce, że plik nie ulegnie zmianie, dopóki jego nazwa pozostanie taka sama - idealne rozwiązanie dla zasobów wersjonowanych. „stale-while-revalidate“ pozwala na dostarczenie wygasłej kopii, podczas gdy jest ona aktualizowana w tle. „stale-if-error“ utrzymuje kopię w gotowości, jeśli Origin krótko zwraca błędy. „s-maxage“ jest przeznaczony dla serwerów proxy/CDN i może mieć wartości inne niż „max-age“. Ważne: „public“ pozwala na buforowanie we współdzielonych serwerach proxy; „private“ jest ograniczone do przeglądarki. „no-cache“ nie oznacza „nie buforuj“, ale „buforowanie dozwolone, ale sprawdź ponownie przed użyciem“ - kluczowa różnica w stosunku do „no-store“.

Przykład # Apache 2.4 (jeszcze solidniejsze buforowanie zasobów)

  Header set Cache-Control "public, max-age=31536000, immutable, stale-while-revalidate=86400, stale-if-error=259200" "expr=%{REQUEST_URI} =~ m#.(css|js|woff2?|png|jpe?g|webp|avif)$#"
  Header set Cache-Control "no-cache, must-revalidate" "expr=%{CONTENT_TYPE} =~ m#^text/html#"
Przykład # Nginx (przekierowania 304/Include)
location ~* .(css|js|woff2?|png|jpe?g|webp|avif)$ {
    add_header Cache-Control "public, max-age=31536000, immutable, stale-while-revalidate=86400, stale-if-error=259200" always;
}
location ~* .html$ {
    add_header Cache-Control "no-cache, must-revalidate" always;
}

Zalecany czas buforowania według typu pliku

Wybieram godziny zgodnie z częstotliwością zmian, a nie przyzwyczajeniem, ponieważ Aktywa starzeją się w bardzo różny sposób. Obrazy, logo i ikony zazwyczaj pozostają aktualne przez długi czas, podczas gdy CSS/JS otrzymują częstsze iteracje. Czcionki internetowe rzadko się zmieniają, ale wymagają spójnych nagłówków CORS. HTML często służy jako kontener dla dynamicznej zawartości i dlatego może być krótki lub tylko ponownie walidowany. Interfejsy API powinny mieć jasno określone zasady, aby klienci mogli poprawnie pracować z JSON unikać.

Typ pliku Zalecenie Cache-Control Wskazówka
Obrazy (jpg/png/webp/avif/svg) publiczny, max-age=31536000 Korzystanie z rocznej pamięci podręcznej z wersjonowaniem plików
CSS/JS publiczny, max-age=2592000 Dodanie wersji do nazwy pliku w celu aktualizacji
Czcionki (woff/woff2) publiczny, max-age=31536000 Prawidłowe ustawienie Access-Control-Allow-Origin
HTML (strony) no-cache, must-revalidate lub krótki max-age Bardzo ostrożnie z dynamiczną zawartością
REST API (json) private, max-age=0, must-revalidate Różnicowanie w zależności od punktu końcowego

Unikanie konfliktów z wtyczkami

Używam co najwyżej Wtyczka buforowania i sprawdzić, czy hosting określa już reguły na poziomie serwera. Kombinacje takie jak W3 Total Cache plus WP Super Cache często tworzą zduplikowane dyrektywy, które wzajemnie się wykluczają. WP Rocket oferuje szybką konfigurację, ale wymaga jasnych wykluczeń dla dynamicznych ścieżek i e-commerce. W każdym razie sprawdzam wygenerowany .htaccess po zapisaniu, aby rozpoznać nielogiczne nagłówki. Następnie testuję krytyczne strony, takie jak kasa, logowanie i spersonalizowane pulpity nawigacyjne pod kątem poprawności. Obejście.

Buforowanie i pliki cookie: zalogowani użytkownicy, WooCommerce, sesje

HTML dla zalogowanych użytkowników nie może być przechowywany w publicznej pamięci podręcznej. WordPress ustawia pliki cookie, takie jak wordpress_logged_in_, uzupełniony o WooCommerce woocommerce_items_in_cart, wp_woocommerce_session_ i inne. Zamiast nadmiernego Vary: Cookie W przypadku takich żądań całkowicie pomijam pamięć podręczną. Zapewnia to stabilność procesów kasowych i poprawność spersonalizowanych obszarów. Używam również reguł po stronie serwera, które ustawiają bardziej restrykcyjne nagłówki, gdy pliki cookie są rozpoznawane.

# Apache: Rozpoznawanie plików cookie i ustawianie nagłówków obejścia

  SetEnvIfNoCase Cookie "wordpress_logged_in_|woocommerce_items_in_cart|wp_woocommerce_session" has_session
  Header set Cache-Control "private, no-store" env=has_session
# Nginx: Obejście oparte na plikach cookie
if ($http_cookie ~* "(wordpress_logged_in|woocommerce_items_in_cart|wp_woocommerce_session)") {
    add_header Cache-Control "private, no-store" always;
}

Wiele wtyczek do buforowania oferuje w tym celu pola wyboru (WooCommerce/Cart/Exclude checkout). Ważne: Nonces (_wpnonce) w formularzach i Heartbeat API generują częste zmiany. Upewniam się, że frontendowy HTML z nonces nie jest trwale buforowany lub działa poprzez „no-cache, must-revalidate“.

Ukierunkowane leczenie HTML: spersonalizowane vs. ogólne

Nie wszystkie strony są takie same. Artykuły, strony docelowe i strony prawne często mogą być buforowane z krótkim TTL lub ponowną walidacją. Archiwa, strony wyszukiwania, pulpity nawigacyjne, obszary kont i kasy pozostają dynamiczne. Jeśli chodzi o buforowanie stron, stosuję następującą praktykę: buforuj tylko publiczny HTML bez plików cookie, w przeciwnym razie „prywatny“ lub „bez przechowywania“. Jeśli testujesz mikro-buforowanie (np. 30-60 sekund dla często odwiedzanych, niespersonalizowanych stron), powinieneś zdefiniować ścisłe wykluczenia dla parametrów zapytania i sesji. WordPress posiada DONOTCACHEPAGE stała, którą szablony mogą ustawiać na trudnych stronach - używam jej konsekwentnie, aby uniknąć błędów.

Rozsądne połączenie buforowania po stronie serwera

Buforowanie przeglądarki kończy się na kliencie, ale odciążam również serwer za pomocą pamięci podręcznej stron, obiektów i kodów operacyjnych. Szczyty obciążenia. Buforowanie stron dostarcza statyczny HTML jeszcze przed uruchomieniem PHP. Redis lub Memcached redukują zapytania do bazy danych dla powtarzających się żądań i zauważalnie zmniejszają TTFB. OPcache zapewnia prekompilowane fragmenty kodu bajtowego PHP, a tym samym skraca czas wykonania. Ostatecznie liczy się czyste połączenie między pamięcią podręczną serwera a pamięcią podręczną przeglądarki, dzięki czemu druga wizyta jest mniej lub bardziej udana. natychmiastowy działa.

Integracja CDN bez niespodzianek

Sieci CDN używają własnej logiki TTL i reagują na „s-maxage“. Dlatego dokonuję wyraźnego rozróżnienia: „max-age“ dla przeglądarek, „s-maxage“ dla Edge. Jeśli wdrożenia są w toku, uruchamiam ukierunkowane czyszczenie zamiast globalnego niszczenia „Cache Everything“. Ważne: buforuj HTML na Edge tylko wtedy, gdy nie są zaangażowane żadne pliki cookie. W przeciwnym razie tworzone są nieprawidłowe stany, ponieważ pamięć podręczna krawędzi udostępnia spersonalizowane odpowiedzi. W przypadku zasobów ustawiam długie czasy wygaśnięcia i polegam na wersjonowaniu nazw plików. Sieci CDN mogą ignorować ciągi zapytań - kolejny powód, aby zachować wersje w nazwie pliku. Normalizacja nagłówków (brak zbędnych wartości „Vary“, spójny „Content-Type“) zapobiega rozdętym kluczom pamięci podręcznej.

Krok po kroku: czysta instalacja

Zaczynam od wtyczki i aktywuję buforowanie przeglądarki dla CSS, JS, obrazów i czcionek przed aktywacją htaccess zakończyć. Następnie ustawiam wysoki max-age dla zasobów statycznych i dostarczam HTML z krótkimi czasami lub regułami no-cache. Dezaktywuję ETags, jeśli zaangażowanych jest kilka serwerów i polegam na Last-Modified plus 304. Następnie uruchamiam wstępne ładowanie, aby ważne strony były natychmiast dostępne jako kopie statyczne. Na koniec sprawdzam ścieżki sklepu, logowania i administratora, aby żadna prywatna zawartość nie była przechowywana w folderze pamięć podręczna ziemia.

Praktyczna diagnostyka za pomocą CLI i sprawdzanie nagłówków

DevTools są obowiązkowe, ale wchodzę głębiej z testami CLI. A curl -I pokazuje nagłówek bez pobierania; z -H Symuluję warunki. Na przykład sprawdzam, czy ponowne walidacje rzeczywiście zwracają 304, czy „Wiek“ wzrasta z proxy/CDN i czy pliki cookie wyłączają buforowanie.

Nagłówek wyświetlacza #
curl -I https://example.com/style.css

Symulacja ponownej walidacji # (If-Modified-Since)
curl -I -H "If-Modified-Since: Tue, 10 Jan 2023 10:00:00 GMT" https://example.com/style.css

Test # z plikiem cookie (powinien wymusić obejście)
curl -I -H "Cookie: wordpress_logged_in_=1" https://example.com/

Upewniam się, że zasoby mają długą wartość „cache control“, najlepiej „immutable“. HTML powinien mieć „no-cache“ lub krótki TTL. Jeśli nadal otrzymuję 200 zamiast 304, często występują przekierowania, które unieważniają ETags/Last-Modified. Ponadto „add_header“ w Nginx domyślnie dotyczy tylko odpowiedzi 200 - z „zawsze“ ustawiam również nagłówki dla 304 i 301/302.

Testowanie i walidacja nagłówków

Otwieram DevTools, przeładowuję stronę raz, czyszczę pamięć podręczną i ładuję ponownie, aby uzyskać 304 vs. 200 obserwować. W panelu sieciowym sprawdzam kontrolę pamięci podręcznej, wiek, ETag/ostatnią modyfikację i rozmiary odpowiedzi. Jeśli nadal występują bezpośrednie trafienia zamiast rewalidacji, sprawdzam konflikty z przekierowaniami, plikami cookie lub ciągami zapytań. W trudnych przypadkach pomaga mi ten artykuł o pułapkach z nagłówkami: Sabotowanie nagłówka pamięci podręcznej. Powtarzam sprawdzanie po każdej aktualizacji wtyczki, ponieważ zmiany w regułach są często wprowadzane po cichu. przepustka.

Wersjonowanie, CDN i cache busting

Zawieszam Wersja do nazw plików (style.23.css zamiast style.css?ver=23), dzięki czemu przeglądarki zachowują długie pamięci podręczne i nadal natychmiast ładują nową zawartość. CDN dystrybuuje pliki statyczne globalnie, ustawia własne TTL w brzegowych PoP i drastycznie skraca RTT. Ważne: buforuj HTML w CDN tylko wtedy, gdy nie jest wymagana personalizacja, w przeciwnym razie zostaną utworzone nieprawidłowe stany. Podczas wdrażania automatycznie zmieniam numer wersji, aby użytkownicy nigdy nie utknęli ze starymi skryptami. W ten sposób łączę twarde TTL przeglądarki z bezpiecznym Niszczenie pamięci podręcznej.

Czyste wersjonowanie w kompilacjach WordPress

Najbardziej niezawodny jest potok kompilacji, który zapisuje skróty w nazwach plików (np. app.9f3c.css). Następnie WordPress ładuje dokładnie ten plik - przeglądarki mogą go przechowywać przez rok dzięki „niezmienności“. Jako rozwiązanie awaryjne, jeśli nazwy plików nie mogą zostać zmienione, ustawiam numer wersji dynamicznie na podstawie daty pliku. Dzięki temu ciągi zapytań są poprawne i niezawodne.

// functions.php (wersjonowanie awaryjne przez filemtime)
add_action('wp_enqueue_scripts', function () {
    $css = get_stylesheet_directory() . '/dist/style.css';
    $ver = file_exists($css) ? filemtime($css) : null;
    wp_enqueue_style('theme', get_stylesheet_directory_uri() . '/dist/style.css', [], $ver);
});

Ważne: Jeśli nazwa pliku zawiera wersje, można ustawić opcję „immutable“. Jeśli używasz tylko ciągów zapytań, przeglądarki powinny mieć możliwość ponownej walidacji, aby aktualizacje docierały niezawodnie. Upewniam się również, że narzędzia do kompilacji czyszczą stare pliki, aby sieci CDN nie przechowywały niepotrzebnie dużej liczby wariantów.

Poprawne buforowanie i ładowanie czcionek internetowych

Czcionki internetowe wymagają długiego TTL, poprawnych nagłówków CORS i opcjonalnego ładowania wstępnego, aby Skoki układu nie pojawiają się. Umieszczam pliki woff2 w tej samej domenie lub czysto ustawiam Access-Control-Allow-Origin. Ponadto należy zdefiniować font-display: swap, aby tekst był widoczny natychmiast podczas ładowania czcionki. Jeśli chcesz zoptymalizować czas ładowania czcionek, przydatne wskazówki znajdziesz tutaj: Szybsze ładowanie czcionek internetowych. Dzięki czystym nagłówkom pamięci podręcznej i wstępnemu połączeniu z CDN, zauważalnie skracam FOUT/FOIT i zapewniam spójność. Renderowanie-Wyniki.

Poprawne dostrojenie czcionek, CORS i Vary

Czcionki z innego pochodzenia wymagają CORS. Ustawiam Access-Control-Allow-Origin (np. do własnej domeny lub „*“ dla prawdziwie publicznych) i uniknąć niepotrzebnego Różne: Pochodzenie, która zawyża klucze pamięci podręcznej. Zalecane dla czcionek: publiczne, max-age=31536000, niezmienne. Preload poprawia First Paint, ale nie zmienia TTL - preload i hard caching wzajemnie się uzupełniają. Nie zapominam również, że skompresowane dostarczanie (br/gzip) a Vary: Accept-Encoding jest wymagana do prawidłowego rozdzielenia proxy.

Typowe wzorce błędów i szybkie rozwiązania

Jeśli po aktualizacji pojawi się stary kod Wersjonowanie na nazwie pliku. Jeśli przeglądarka przeładowuje się całkowicie za każdym razem, nagłówki ustawiają sprzeczne instrukcje lub serwery proxy usuwają je po drodze. Jeśli płatność zostanie anulowana, witryna prawdopodobnie buforuje strony po stronie sesji lub odpowiedzi API. Jeśli ścieżki administratora wślizgują się do pamięci podręcznej, brakuje wykluczeń dla wp-admin i logowania lub wtyczka buforuje globalnie. Rozwiązuję to poprzez dezaktywację krok po kroku, konsolidację nagłówków, wykluczenie krytycznych ścieżek i wreszcie efekt ze statusem 304 potwierdzać.

Często pomijane szczegóły, które robią dużą różnicę

  • Nginx add_header nie ma zastosowania do 304/redirects bez „zawsze“ - nagłówki pamięci podręcznej są wtedy pomijane przy walidacji. Konsekwentnie ustawiam „zawsze“.
  • Wygasanie a kontrola pamięci podręcznej: „Cache-Control“ ma priorytet, „Expires“ służy jako rozwiązanie awaryjne dla starych klientów. Unikaj powielania, sprzecznych informacji.
  • ETag w konfiguracjach wieloserwerowych: Niespójne ETagi niszczą 304. Wyłączam ETagi lub używam słabych walidatorów i polegam na „Last-Modified“.
  • Zróżnicowane do minimum: „Vary: Accept-Encoding“ jest obowiązkowe dla kompresji, „Vary: Cookie“ blokuje pamięci podręczne krawędzi - lepiej ominąć oparte na plikach cookie.
  • SVG i typ MIME: Prawidłowo image/svg+xml ustawić, dać długi TTL i rozważyć inline SVG dla krytycznych ikon.
  • Unikaj łańcuchów przekierowań: Każde 301/302 może utracić walidatory i wymusić 200 - czyste adresy URL bez kaskad.
  • Używaj priorytetu/przeładowania w ukierunkowany sposób: fetchpriority="high" lub wstępne ładowanie krytycznych zasobów przyspiesza pierwsze wywołanie; buforowanie jest skuteczne dla powracających użytkowników.
  • Rozróżnianie REST-API: Publiczne, rzadko zmieniające się JSON-y mogą być krótko buforowane; punkty końcowe z tokenami/plikami cookie są ściśle „prywatne“.

Krótkie podsumowanie

Polegam na jasnych Zasadydługie TTL dla zasobów, krótkie lub ponownie zweryfikowane odpowiedzi HTML, wersjonowanie i pojedyncza wtyczka buforująca. Następnie łączę pamięć podręczną przeglądarki z pamięcią podręczną strony, obiektu i kodu operacyjnego, aby zmniejszyć obciążenie serwera. Sprawdzam DevTools, szukam 304, sprawdzam nagłówki i eliminuję konflikty z przekierowaniami lub plikami cookie. W teście praktycznym porównuję pomiary przy pierwszym i wielokrotnym wywołaniu i skupiam się na zauważalnej poprawie. Jeśli wykonasz te kroki, możesz doprowadzić WordPress do niezawodnego poziomu buforowania przeglądarki. Prędkość i sprawia, że użytkownicy i wyszukiwarki są zadowoleni.

Artykuły bieżące