Forzar el almacenamiento en caché de Varnish en LWS

Procédure

En esta documentación, explicaremos paso a paso cómo forzar a Varnish y a los navegadores a mantener tus recursos en caché, incluso cuando envíen peticiones Pragma: no-cache o Cache-Control: no-cache.

1. Contexto y arquitectura de LWS

Los paquetes de alojamiento compartido y cPanel/VPS gestionados de LWS se basan en la arquitectura :

Navegador ⇄ NGINX (SSL + HTTP/2) ⇄ Caché Varnish ⇄ Apache/PHP-FPM.

  • NGINX gestiona TLS y comprime el contenido.
  • Varnish (Fastest Cache) se utiliza como proxy inverso para almacenar las respuestas HTTP.
  • Apache o PHP-FPM generan la respuesta final cuando Varnish no tiene HIT.

Cuando todo está correctamente configurado, Varnish puede proporcionar hasta 1000 veces más rápido que el acceso directo a PHP, a la vez que alivia la CPU del servidor.

2. Recordatorio: ¿cómo decide Varnish almacenar en caché?

Elemento Impacto en la caché Cómo influir
Método Sólo GET y HEAD son elegibles Evite POSTs para páginas públicas
Cabeceras de respuesta Cache-Control, Expires, Pragma Determinar la duración y el alcance Fijar mediante .htaccess (véase §3)
Cookies / Set-Cookie Una cookie presente = sin caché por defecto Eliminar o desactivar las cookies innecesarias
Estado HTTP 200, 203, 301, 302, 404, 410 son cacheables Ninguna acción, ¡pero evite 500!

[tips]Varnish ignora por defecto el Cache-Control: no-cache enviado por el navegador para los archivos estáticos, pero respeta la "lógica de revalidación" si el objeto ya está cacheado[/tips].

3. Controlar el tiempo de vida mediante .htaccess

Activa el módulo mod_headers (es el predeterminado en LWS) y coloca el siguiente fragmento donde quieras:


  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: duración (en segundos) en el navegador.
  • s-maxage: duración específica para cachés compartidas (Varnish/CDN).
  • stale-while-revalidate: permite a Varnish servir contenido obsoleto mientras lo refresca en segundo plano.
  • stale-if-error: sirve la versión desactualizada si el backend responde con un error (a prueba de fallos).

3.1 Orientación por carpeta

Colocando el mismo archivo .htaccess en la carpeta "/images/" se aplica la regla sólo a la carpeta "images".

3.2 Selección por extensión


  
    El encabezado establece Cache-Control "public, max-age=2592000, s-maxage=2592000, immutable".  

immutable: indica al navegador que no es necesaria la revalidación hasta que el objeto haya caducado; ideal para archivos versionados (style.483bf.css).

3.3 Caché corta para HTML


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

Expira después de 5 min del lado del cliente y 10 min del lado de Varnish, luego must-revalidate.

4. Escenarios de uso reales

Caso real Fragmento de .htaccess ¿Por qué hacer esto?
Página de aterrizaje actualizada cada hora max-age=600, s-maxage=1200 Los visitantes obtienen datos "casi en directo" sin sobrecargar PHP
CSS/JS versionados max-age=31536000, inmutable Prácticamente sin tráfico de servidor, carga instantánea
Imágenes de productos de comercio electrónico max-age=604800 Reduce el TTFB, acelera el catálogo
Back-office / wp-admin no-store, privado Evita poner datos sensibles en la caché compartida

5. Purgar o invalidar la caché

  1. Desde el Panel LWS: Optimización y Rendimiento > Caché LWS > Vaciar caché.
  2. PURGA HTTP (si está activada):
    curl -X PURGE -H "Host: example.com" https://exemple.com/chemin/ressource.jpg
  3. Ban por expresión (VCL avanzada):
    ban req.http.host == "ejemplo.com" && req.url ~ "/images/"

6. Pruebas y depuración

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

Mira :

  • Edad: 356 → Varnish sirvió una respuesta con una edad de 356 s.
  • Cache-Control: public, max-age=2592000, s-maxage=2592000, immutable.
  • X-Cache: HIT (o MISS).

Con Chrome/Edge: DevTools > Network > Disable cache puede simular un primer visitante.

7. Errores comunes

  1. Cookies innecesarias: muchos temas de WordPress establecen una cookie incluso para las páginas públicas. Elimínelas o desactívelas a través de functions.php.
  2. Cadenas de consulta: por defecto, ?v=123 crea una nueva entrada en la caché. Versión en el nombre de archivo en su lugar.
  3. Contenido sensible: formularios, páginas del área de clientes ➡ no-store, private, max-age=0.
  4. Compresión Brotli/Gzip: actívalas antes que la capa Varnish para evitar la doble caché.

8. Resumen de las mejores prácticas

  • Utiliza s-maxage ⩾ max-age para mantener una caché proxy más larga que la caché del navegador.
  • Pon immutable en cualquier archivo cuyo nombre contenga un hash.
  • No mezcle Obsolete Expires con max-age excepto para navegadores antiguos.
  • Documenta tus TTLs en un archivo CACHE_POLICY.md para el equipo.

9. Recursos útiles

✅ ¡Tu caché de Varnish ya está bajo control!

Valora este artículo :

5/5 | 1 opinión

Este artículo le ha sido útil ?

Article utile

Article non utileNo

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)

Artículos similares

1mn lectura

¿Cómo puedo acceder a las estadísticas de visitas?

1mn lectura

¿Cómo activo Mod_PageSpeed en mi sitio?

1mn lectura

¿Cómo se utilizan los módulos de caché en LWSPanel?

3mn lectura

Acelere su sitio con LWS Cache


Questions sur cet article

Formule una pregunta al equipo de LWS y a su comunidad

RGPD : Responsable LWS-Ligne Web Services. Finalité : modération et publication publique de votre question, notification éventuelle d'une réponse. Base légale : consentement (art. 6.1.a RGPD). Conservation des emails : 90 jours après notification, 12 mois maximum sans réponse. Vous pouvez exercer vos droits via notre nos CGV - section RGPD.