Tvinga fram Varnish-cachelagring på LWS

Procédure

I den här dokumentationen förklarar vi steg för steg hur du tvingar Varnish och webbläsare att hålla dina resurser cachade, även när de skickar Pragma: no-cache- eller Cache-Control: no-cache-förfrågningar.

1. Sammanhang och AWS-arkitektur

LWS delad hosting och hanterade cPanel/VPS-paket baseras på :

Webbläsare ⇄ NGINX (SSL + HTTP/2) ⇄ Varnish Cache ⇄ Apache/PHP-FPM

• NGINX hanterar TLS och komprimerar innehåll.
• Varnish (Fastest Cache ) används som en omvänd proxy för att lagra HTTP-svar.
• Apache eller PHP-FPM genererar det slutliga svaret när Varnish inte har någon HIT.

När allt är korrekt konfigurerat kan Varnish leverera upp till 1000 gånger snabbare än direktåtkomst till PHP, samtidigt som serverns CPU avlastas.

2. Påminnelse: hur bestämmer Varnish att cachelagra?

[tips]Varnish ignorerar som standard Cache-Control: no-cache som skickas av webbläsaren för statiska filer, men respekterar "revalideringslogiken" om objektet redan är cachat[/tips].

3. Kontrollera livstiden via .htaccess

Aktivera mod_headers-modulen (detta är standard på LWS) och placera sedan följande snutt där du vill:

  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: varaktighet (i sekunder) i webbläsaren.
• s-maxage: specifik varaktighet för delade cacheminnen (Varnish/CDN).
• stale-while-revalidate: tillåter Varnish att servera inaktuellt innehåll medan det uppdateras i bakgrunden.
• stale-if-error: serverar den föråldrade versionen om backend svarar med fel (felsäkert).

3.1 Inriktning per mapp

Om du placerar samma .htaccess-fil i mappen "/images/" tillämpas regeln endast på mappen "images".

3.2 Inriktning efter tillägg

  
    Header set Cache-Control "public, max-age=2592000, s-maxage=2592000, immutable".  

immutable: talar om för webbläsaren att ingen omvalidering krävs förrän objektet har löpt ut; perfekt för versionshanterade filer (style.483bf.css).

3.3 Kort cache för HTML

  Header set Cache-Control "public, max-age=300, s-maxage=600, must-revalidate".

Upphör att gälla efter 5 min på klientsidan och 10 min på Varnish-sidan, sedan måste den ogiltigförklaras.

4. Scenarier för användning i verkliga livet

5. Rensa eller inaktivera cacheminnet

1. Från LWS-panelen: Optimering & prestanda > LWS-cache > Töm cache.
2. HTTP PURGE (om aktiverat):

   curl -X PURGE -H "Host: example.com" https://exemple.com/chemin/ressource.jpg

3. Förbjud genom uttryck (avancerad VCL):

   ban req.http.host == "example.com" && req.url ~ "/images/"

6. Testning och felsökning

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

Titta på :

• Ålder: 356 → Varnish serverade ett svar som var 356 s gammalt.
• Cache-Control: public, max-age=2592000, s-maxage=2592000, immutable
• X-Cache: HIT (eller MISS).

Med Chrome/Edge: DevTools > Network > Disable cache kan man simulera en första besökare.

7. Vanliga fallgropar

1. Onödiga cookies: många WordPress Teman sätter en cookie även för offentliga sidor. Ta bort dem eller inaktivera dem via functions.php.
2. Frågesträngar: Som standard skapar ?v=123 en ny post i cacheminnet. Ange istället version i filnamnet.
3. Känsligt innehåll: formulär, kundområdessidor ➡ no-store, private, max-age=0.
4. Brotli/Gzip-komprimering: aktivera dem före Varnish-lagret för att undvika dubbel cachelagring.

8. Sammanfattning av bästa praxis

• Använd s-maxage ⩾ max-age för att hålla en proxy-cache som är längre än webbläsarens cache.
• Lägg till immutable på alla filer vars namn innehåller en hash.
• Blanda inte Obsolete Expires med max-age utom för äldre webbläsare.
• Dokumentera dina TTL:er i en CACHE_POLICY.md-fil för teamet.

9. Användbara resurser

• LWS: Snabba upp din webbplats med Fastest Cache
• AWS-blogg: Hur du får en bättre presterande webbplats med Varnish Cache

✅ Din Varnish-cache är nu under kontroll!