Caché del navegador: ¿tu página HTML fuerza una recarga cada vez?

Sin encabezados de caché, el navegador vuelve a descargar toda la página en cada visita. El test #02 verifica tu política de caché en segundos.

Tu visitante carga una página. Hace clic en un enlace, luego vuelve. Sin encabezados de caché, el navegador descarga todo el HTML de nuevo — mismo contenido, mismo peso, misma espera. Cada vez.

El caché del navegador para páginas HTML es uno de los ajustes de rendimiento más olvidados. Todos ponen en caché las imágenes y el CSS, pero ¿el documento HTML en sí? La mayoría de los sitios WordPress no tienen una política de caché adecuada.

El test #02 de Orilyt inspecciona los encabezados de caché de la respuesta HTML. No los assets, no las imágenes — el documento principal. Verifica Cache-Control, Expires, ETags y Last-Modified en un solo paso. El resultado indica si los visitantes recurrentes obtienen una experiencia rápida o una descarga redundante.

Cómo funciona el caché del navegador para HTML

Cuando un servidor envía una página HTML, puede incluir encabezados que le indican al navegador cómo almacenarla en caché. Los actores principales:

1. Cache-Control: max-age=N — indica al navegador que conserve esta página N segundos sin volver a pedir al servidor. Un max-age de 600 significa 10 minutos de caché local
2. Cache-Control: s-maxage=N — igual que max-age, pero para cachés compartidos (CDN, proxies). Tiene prioridad sobre max-age cuando está presente
3. Expires — un encabezado más antiguo que fija una fecha/hora absoluta de expiración. Funciona como respaldo cuando Cache-Control está ausente
4. ETag y Last-Modified — validadores que permiten solicitudes condicionales. En lugar de volver a descargar, el navegador pregunta «¿ha cambiado desde X?» — si no, el servidor devuelve un 304 Not Modified (cuerpo vacío)

Cache-Control: no-store significa que el navegador nunca debe almacenar en caché. Cache-Control: no-cache significa que puede almacenarla pero debe revalidar cada vez. Ambos generan una solicitud al servidor en cada visita.

Para páginas HTML que cambian con poca frecuencia (la mayoría del contenido WordPress), un max-age de 300 a 3600 segundos combinado con ETags es el punto ideal. La página se carga al instante desde el caché, y la siguiente revalidación es ligera.

Cómo Orilyt puntúa tu política de caché

El test #02 lee los encabezados de respuesta y evalúa la política de caché:

1. Puntuación 90 — Cacheable con un TTL superior a 300 segundos. El navegador puede servir la página desde su caché local durante al menos 5 minutos. Mejor resultado
2. Puntuación 70 — Cacheable pero el TTL es corto o inexistente. La página tiene encabezados de caché pero la ventana de frescura es demasiado breve para ser útil
3. Puntuación 30 — No cacheable o ningún encabezado de caché detectado. El navegador descarga la página completa en cada visita. Este es el valor por defecto para la mayoría de los sitios sin configurar

El test también detecta la presencia de validadores (ETag, Last-Modified), si la página está marcada como private, y si los encabezados Set-Cookie interfieren con el caché.

Por qué el caché HTML a menudo falta

El caché HTML es menos común que el caché de assets por una tensión fundamental: las páginas pueden cambiar. Pero hay soluciones más inteligentes que no tener caché:

1. WordPress por defecto — WordPress no establece encabezados Cache-Control por defecto. El servidor (Apache, Nginx) debe configurarse por separado, y la mayoría de los paneles de hosting no lo hacen
2. Páginas dinámicas con Set-Cookie — si la respuesta incluye Set-Cookie, muchos CDN y proxies omiten el caché. Páginas de login, carritos de WooCommerce y contenido personalizado desencadenan esto
3. no-store en todas partes — algunos plugins de seguridad o plugins de caché mal configurados establecen no-store en todas las páginas, incluyendo contenido estático que debería estar en caché
4. ETag/Last-Modified ausentes — sin validadores, el navegador no puede hacer solicitudes condicionales. O usa la versión en caché a ciegas o descarga la página completa. La mayoría no lo nota

La clave: para el 90 % de las páginas WordPress (artículos, páginas de servicios, landing pages), un max-age moderado (300–600 s) con revalidación ETag es seguro y efectivo. El navegador obtiene un caché hit rápido, y los cambios se propagan en minutos.

La política de caché como argumento de venta

Para freelances y agencias, una política de caché ausente es un hallazgo de audit fuerte. Afecta a cada visitante recurrente — y los visitantes recurrentes son tu tráfico más valioso.

En el informe Orilyt, el test #02 genera una recomendación FIA estructurada:

1. Hecho: «Ningún encabezado Cache-Control o Expires en el documento HTML. Ninguna política de caché detectada»
2. Impacto: «Cada visita desencadena una descarga completa de la página, incluso para visitantes recurrentes. Desperdicio de ancho de banda y tiempo de carga innecesario»
3. Acción: «Añadir Cache-Control: public, max-age=600 a las respuestas HTML. Añadir validación ETag para revalidación inteligente»

Una puntuación de 30/100 en política de caché señala un sitio que no ha sido optimizado más allá de lo básico. Es el tipo de detalle que distingue un audit profesional de un informe genérico «tu sitio es lento».

Haz que las visitas recurrentes sean instantáneas

El caché del navegador para HTML no es una cuestión de caché agresivo o riesgo de contenido obsoleto. Es decirle al navegador: «puedes guardar esto unos minutos, y aquí te digo cómo verificar si cambió.»

El test #02 lo verifica en un solo paso. Sin inspección manual de encabezados, sin comandos de terminal — solo una puntuación (90, 70 o 30) con una explicación clara y una corrección accionable.

Si auditas sitios de clientes, la política de caché es uno de esos hallazgos invisibles a simple vista pero medibles en datos. Es el tipo de mejora que marca una diferencia real — y que no cuesta casi nada implementar.