La caché web es el mecanismo por el que se almacenan copias de recursos (páginas HTML, imágenes, CSS, JavaScript) en distintos puntos de la cadena entre el servidor y el navegador del usuario, de modo que las solicitudes futuras se respondan más rápido sin volver a generar o descargar el recurso desde cero. En pocas palabras: la caché evita el trabajo repetido y reduce los tiempos de carga.
Existen cuatro capas principales de caché, cada una ubicada en un punto diferente de la cadena. Aquí te explicamos qué hace cada una, cómo configurarla y cuándo conviene usarla.
Caché del navegador (browser cache)
Es la caché que vive en el dispositivo del propio usuario. Cuando visitas un sitio por primera vez, el navegador descarga todos los recursos necesarios —imágenes, hojas de estilo, scripts, fuentes— y los guarda en el disco local. En la siguiente visita (o en otra página del mismo sitio), el navegador puede reutilizar esos archivos en lugar de volver a descargarlos.
Cómo se controla
El servidor indica al navegador cuánto tiempo guardar cada recurso mediante cabeceras HTTP:
Cache-Control: max-age=31536000— guarda el archivo durante un año (ideal para recursos con nombre versionado, comoapp.v3.js).Cache-Control: no-cache— el navegador guarda el archivo pero debe verificar con el servidor si sigue siendo válido antes de usarlo.Cache-Control: no-store— el navegador no guarda nada (para datos sensibles o en tiempo real).ETag/Last-Modified— permiten la revalidación condicional: el servidor solo envía el recurso completo si ha cambiado.
Cuándo usar
Siempre. La caché del navegador es la más barata de implementar y tiene impacto inmediato en las visitas recurrentes. Los recursos estáticos que cambian raramente (logos, CSS base, librerías JS) son candidatos perfectos para tiempos de caché largos. Los recursos que cambian con frecuencia deben usar cache busting —incluir un hash en el nombre del archivo— para que los cambios lleguen sin forzar al usuario a vaciar la caché manualmente.
Caché del servidor (server-side cache)
Vive en el propio servidor web o en la capa de aplicación. En lugar de ejecutar PHP, consultar la base de datos y construir el HTML en cada solicitud, el servidor almacena el resultado final y lo sirve directamente las siguientes veces.
Tipos de caché del servidor
- Caché de página completa (full-page cache): guarda el HTML completo de cada URL. Es la más efectiva para reducir el TTFB en sitios dinámicos. Herramientas: Varnish, Nginx FastCGI cache, WP Rocket (WordPress).
- Caché de objetos (object cache): guarda resultados de consultas a la base de datos o cálculos costosos en memoria. Redis y Memcached son las soluciones más populares. Útil cuando la página es dinámica pero ciertos datos no cambian a menudo.
- Caché de operaciones de código (opcode cache): PHP compila cada archivo
.phpa bytecode en cada ejecución. OPcache guarda ese bytecode en memoria para no recompilarlo en cada solicitud. Viene activado por defecto en PHP 5.5+ y es completamente transparente.
Cuándo usar
La caché de página completa es especialmente valiosa para sitios con mucho tráfico repetido en las mismas URLs —blogs, tiendas online, portales de noticias— donde el HTML no cambia entre visitas de usuarios anónimos. La caché de objetos complementa a la de página cuando el contenido sí varía (por usuario, por sesión o por parámetros) pero hay partes reutilizables.
Caché CDN (Content Delivery Network)
Una CDN es una red de servidores distribuidos geográficamente. Cuando un usuario solicita un recurso, la CDN lo sirve desde el nodo más cercano a su ubicación en lugar de desde el servidor de origen. Además de acortar la distancia física, la CDN almacena una copia del recurso en ese nodo para futuras solicitudes de la misma región.
Qué cachea una CDN
| Tipo de contenido | ¿Se suele cachear en CDN? | Tiempo típico de caché |
|---|---|---|
| Imágenes (JPG, WebP, PNG, SVG) | Sí | 7 días a 1 año |
| CSS y JavaScript | Sí | 1 día a 1 año (con versioning) |
| Fuentes web | Sí | 1 año |
| HTML dinámico | Opcional (edge caching) | Segundos a minutos |
| Respuestas de API personalizadas | No (por defecto) | — |
Cuándo usar
La CDN es imprescindible cuando tus usuarios están distribuidos en múltiples países o regiones. Sin CDN, todos los usuarios acceden al mismo servidor —con la latencia que su distancia implique—. Con CDN, cada usuario recibe el contenido desde el nodo más próximo. Cloudflare, Fastly, BunnyCDN y Amazon CloudFront son las opciones más populares.
Caché de proxy (proxy cache)
Un proxy cache es un servidor intermedio que se sitúa entre los usuarios y el servidor de origen. Puede estar bajo el control de la organización (proxy corporativo o proxy inverso) o del proveedor de internet. Cualquier recurso solicitado a través del proxy se almacena en él; si otra solicitud pide el mismo recurso, el proxy lo sirve directamente sin consultar al origen.
Proxy inverso vs. proxy de reenvío
- Proxy inverso (reverse proxy): se coloca delante del servidor de origen y protege e intermediará las solicitudes de los clientes. Nginx y Apache actuando como reverse proxy con caché son ejemplos comunes. Varnish es un reverse proxy diseñado específicamente para caching de alto rendimiento.
- Proxy de reenvío (forward proxy): se coloca del lado del cliente —en redes corporativas, por ejemplo— y cachea recursos para todos los usuarios de esa red. Menos relevante para el operador del sitio web, pero puede afectar cómo los usuarios reciben el contenido.
Cuándo usar
El proxy inverso es especialmente útil en infraestructuras propias cuando quieres controlar el caching a nivel de servidor sin depender de una CDN externa. Varnish delante de Apache o Nginx puede absorber miles de solicitudes por segundo sirviendo contenido cacheado, liberando al servidor de aplicación para las solicitudes que realmente requieren procesamiento dinámico.
Cómo se complementan las cuatro capas
Las cuatro capas no son excluyentes: la estrategia óptima es usarlas juntas. Un flujo típico para un sitio de alto tráfico sería:
- El navegador tiene el CSS y las imágenes en caché desde la visita anterior → responde en 0 ms.
- Si el recurso ya no está en la caché del navegador, la solicitud llega a la CDN → el nodo local sirve el recurso en decenas de milisegundos.
- Si la CDN tampoco tiene el recurso (cache miss), la solicitud llega al proxy inverso / Varnish → sirve el HTML desde caché de disco en ~5 ms.
- Si tampoco hay caché en el proxy, la solicitud llega a la aplicación PHP, que primero consulta la caché de objetos (Redis) antes de ir a la base de datos.
Este modelo en capas significa que muy pocas solicitudes llegan a la base de datos, que es el recurso más costoso en tiempo y en carga del servidor.
Para entender cómo la caché afecta métricas concretas como el TTFB o el LCP, visita nuestro archivo de artículos sobre rendimiento web con guías técnicas paso a paso.
Si necesitas ayuda para definir e implementar una estrategia de caché adecuada para tu sitio, el equipo de elenlace.com puede diseñar la solución correcta según tu arquitectura y volumen de tráfico.
Conclusiones clave
- Existen cuatro capas principales de caché web: navegador, servidor, CDN y proxy.
- La caché del navegador reduce descargas en visitas recurrentes; se controla con cabeceras HTTP como
Cache-Control. - La caché del servidor (full-page, object cache, OPcache) evita regenerar páginas y consultas repetidas a la base de datos.
- La CDN reduce la latencia de red distribuyendo el contenido en servidores cercanos al usuario.
- El proxy inverso absorbe picos de tráfico sirviendo contenido cacheado antes de que llegue a la aplicación.
- La estrategia óptima usa las cuatro capas en conjunto, cada una complementando a las demás.
¿Quieres implementar una estrategia de caché completa para tu sitio? Contacta al equipo de elenlace.com y recibe una propuesta adaptada a tu infraestructura y objetivos de rendimiento.
Preguntas frecuentes
¿Cuándo debo invalidar o vaciar la caché?
Debes invalidar la caché cada vez que publiques contenido nuevo o actualices un recurso que esté siendo cacheado. Los sistemas modernos de CMS y CDN permiten hacerlo automáticamente al publicar o mediante reglas basadas en URL. Para recursos estáticos, el cache busting con nombres de archivo versionados es la solución más fiable.
¿La caché puede causar que los usuarios vean contenido desactualizado?
Sí, si no se configura correctamente. Para contenido dinámico personalizado (carro de compra, dashboard de usuario), la caché debe excluir esas URLs o personalizarse por sesión. Para contenido público que cambia con frecuencia, usar tiempos de caché cortos o invalidación activa soluciona el problema.
¿Qué diferencia hay entre Varnish y Redis?
Varnish es un HTTP accelerator (proxy inverso de caché) que almacena respuestas HTTP completas —páginas enteras— y las sirve directamente sin llegar a PHP. Redis es una caché de objetos en memoria que almacena fragmentos de datos (resultados de consultas, sesiones, contadores) para que la aplicación PHP los recupere rápidamente. Son complementarios: Varnish trabaja a nivel de HTTP, Redis a nivel de datos de aplicación.
¿La caché del navegador afecta a todos los usuarios por igual?
No. La caché del navegador es local a cada dispositivo. El primer visitante siempre descarga todos los recursos; solo las visitas posteriores desde el mismo dispositivo se benefician. La caché del servidor y la CDN, en cambio, benefician a todos los visitantes desde el primer momento.
Compara proveedores
Otros proveedores y guías que vale la pena comparar:
