Wymuś buforowanie Varnish na LWS

Procédure

W tej dokumentacji wyjaśnimy krok po kroku, jak zmusić Varnish i przeglądarki do przechowywania zasobów w pamięci podręcznej, nawet jeśli wysyłają żądania Pragma: no-cache lub Cache-Control: no-cache.

1. Kontekst i architektura LWS

Hosting współdzielony LWS i zarządzane pakiety cPanel/VPS są oparte na architekturze :

Przeglądarka ⇄ NGINX (SSL + HTTP/2) ⇄ Varnish Cache ⇄ Apache/PHP-FPM

  • NGINX zarządza TLS i kompresuje zawartość.
  • Varnish (Fastest Cache ) jest używany jako odwrotne proxy do przechowywania odpowiedzi HTTP.
  • Apache lub PHP-FPM generują ostateczną odpowiedź, gdy Varnish nie ma HIT.

Gdy wszystko jest poprawnie skonfigurowane, Varnish może zapewnić do 1000 razy szybszy dostęp niż bezpośredni dostęp do PHP, jednocześnie odciążając procesor serwera.

2. Przypomnienie: w jaki sposób Varnish decyduje o cache'owaniu?

Element Wpływ na cache Jak na to wpłynąć
Metoda Kwalifikują się tylko GET i HEAD Unikaj POST dla stron publicznych
Nagłówki odpowiedzi Cache-Control, Expires, Pragma Określają czas trwania i zakres Ustawiane przez .htaccess (patrz §3)
Pliki cookie / Set-Cookie Jeden plik cookie = domyślnie brak buforowania Usuń lub wyłącz niepotrzebne pliki cookie
Status HTTP 200, 203, 301, 302, 404, 410 mogą być buforowane Brak działania, ale unikaj 500!

[Wskazówki]Varnish domyślnie ignoruje Cache-Control: no-cache wysyłane przez przeglądarkę dla plików statycznych, ale respektuje "logikę rewalidacji", jeśli obiekt jest już buforowany[/wskazówki].

3. Kontroluj czas życia poprzez .htaccess

Aktywuj moduł mod_headers (jest to domyślne w LWS), a następnie umieść poniższy fragment w dowolnym miejscu:


  Header set Cache-Control "public, max-age=3600, s-maxage=3600, stale-while-revalidate=60, stale-if-error=86400" Header set Expires "Thu, 31 Dec 2037 23:55:55 GMT"
  • max-age: czas trwania (w sekundach) w przeglądarce.
  • s-maxage: określony czas trwania dla współdzielonych pamięci podręcznych (Varnish/CDN).
  • stale-while-revalidate: pozwala Varnishowi na serwowanie nieaktualnych treści podczas odświeżania ich w tle.
  • stale-if-error: serwuje nieaktualną wersję, jeśli backend odpowie błędem (fail-safe).

3.1 Kierowanie według folderu

Umieszczenie tego samego pliku .htaccess w folderze "/images/" stosuje regułę tylko do folderu "images".

3.2 Ukierunkowanie według rozszerzenia


  
    Nagłówek ustawia Cache-Control "public, max-age=2592000, s-maxage=2592000, immutable".  

immutable: mówi przeglądarce, że nie jest wymagana ponowna walidacja, dopóki obiekt nie wygaśnie; idealny dla plików wersjonowanych (style.483bf.css).

3.3 Krótka pamięć podręczna dla HTML


  Ustawienie nagłówka Cache-Control "public, max-age=300, s-maxage=600, must-revalidate".

Wygasa po 5 minutach po stronie klienta i 10 minutach po stronie Varnish, następnie must-revalidate.

4. Rzeczywiste scenariusze użycia

Rzeczywisty przypadek Fragment .htaccess Dlaczego miałoby się tak dziać?
Strona docelowa aktualizowana co godzinę max-age=600, s-maxage=1200 Odwiedzający otrzymują dane "prawie na żywo" bez przeciążania PHP
Wersjonowane CSS/JS max-age=31536000, niezmienny Praktycznie brak ruchu na serwerze, natychmiastowe ładowanie
Obrazy produktów e-commerce max-age=604800 Zmniejsza TTFB, przyspiesza działanie katalogu
Back-office / wp-admin no-store, private Unika umieszczania wrażliwych danych we współdzielonej pamięci podręcznej

5. Wyczyść lub unieważnij pamięć podręczną

  1. Z panelu LWS: Optymalizacja i wydajność > LWS Cache > Opróżnij pamięć podręczną.
  2. HTTP
    PURGE
    (jeśli włączone):
    curl -X PURGE -H "Host: example.com" https://exemple.com/chemin/ressource.jpg
  3. Banowanie przez wyrażenie (zaawansowane VCL):
    ban req.http.host == "example.com" && req.url ~ "/images/"

6. Testowanie i debugowanie

curl -I https://exemple.com/style.css

Zobacz :

  • Wiek: 356 → Varnish zaserwował odpowiedź w wieku 356 s.
  • Cache-Control: public, max-age=2592000, s-maxage=2592000, immutable
  • X-Cache: HIT (lub MISS).

W Chrome/Edge: DevTools > Network > Disable cache może symulować pierwszego odwiedzającego.

7. Najczęstsze pułapki

  1. Niepotrzebne pliki cookie: wiele motywów WordPress ustawia pliki cookie nawet dla stron publicznych. Usuń je lub wyłącz za pomocą functions.php.
  2. Ciągi zapytań: domyślnie ?v=123 tworzy nowy wpis w pamięci podręcznej. Zamiast tego wersja w nazwie pliku.
  3. Wrażliwe treści: formularze, strony strefy klienta ➡ no-store, private, max-age=0.
  4. Kompresja Brotli/Gzip: aktywuj je przed warstwą Varnish, aby uniknąć podwójnego buforowania.

8. Podsumowanie najlepszych praktyk

  • Użyj s-maxage ⩾ max-age, aby zachować pamięć podręczną proxy, która jest dłuższa niż pamięć podręczna przeglądarki.
  • Umieść immutable na każdym pliku, którego nazwa zawiera hash.
  • Nie mieszaj Obsolete Expires z max-age, z wyjątkiem starszych przeglądarek.
  • Udokumentuj swoje TTL w pliku CACHE_POLICY.md dla zespołu.

9. Przydatne zasoby

Pamięć podręczna Varnish jest teraz pod kontrolą!

Oceń ten artykuł :

Ten artykuł był dla Ciebie przydatny ?

Article utileTak

Article non utileNie

MerciMerci ! N'hésitez pas à poser des questions sur nos documentations si vous souhaitez plus d'informations et nous aider à les améliorer.


Vous avez noté 0 étoile(s)

Podobne artykuły

1mn czytanie

Jak mogę uzyskać dostęp do statystyk odwiedzin witryny?

1mn czytanie

Jak aktywować Mod_PageSpeed na mojej stronie?

1mn czytanie

Jak korzystać z modułów pamięci podręcznej w LWSPanel?

3mn czytanie

Przyspiesz swoją witrynę dzięki LWS Cache


Zadaj pytanie zespołowi LWS i jego społeczności