Cookies que rompen la caché de WordPress y cómo detectarlas

Instalaste un plugin de caché, hiciste la prueba y el sitio sigue lento. Muchas veces la causa no es la configuración del plugin sino algo más sencillo: una cookie que le dice al servidor "esta visita es especial, no la sirvas desde caché". Entender qué cookies rompen la caché te ahorra horas de diagnóstico.

Por qué las cookies afectan a la caché de página

Una caché de página guarda el HTML ya generado y lo entrega a todos los visitantes sin ejecutar PHP ni consultar la base de datos. Eso solo es seguro si la página es igual para todos. Cuando el navegador envía ciertas cookies, el sistema asume que el contenido puede ser personalizado (un carrito, un usuario conectado, un comentarista) y se salta la caché para no mostrarle a una persona los datos de otra.

El problema aparece cuando una cookie innecesaria dispara ese comportamiento para visitantes anónimos que en realidad verían la misma página.

Las cookies que más suelen causar problemas

• Sesiones de usuario de WordPress (wordpress_logged_in_*): correcto que salten la caché. Pero si navegás tu propio sitio conectado, tus pruebas de velocidad no representan lo que ve un visitante.
• Cookies de comentarios (comment_author_*): se guardan cuando alguien comenta y pueden hacer que esa persona deje de recibir páginas en caché.
• Cookies de WooCommerce (woocommerce_items_in_cart, woocommerce_cart_hash): necesarias para el carrito, pero solo deberían afectar a las páginas dinámicas (carrito, checkout, mi cuenta), no a todo el sitio.
• Cookies de plugins propios: popups, A/B testing, geolocalización o programas de afiliados que usan session_start() de PHP y envían una cookie PHPSESSID en todas las páginas.
• Cookies de campañas: algunas herramientas de marketing las generan del lado del servidor y las hacen llegar a cada visita.

Cómo detectar si una cookie te está costando la caché

1. Mirá las cabeceras de respuesta

Abrí las herramientas de desarrollo del navegador, pestaña Red, y revisá la primera petición del documento. Fijate si el servidor responde con una cabecera Set-Cookie en una página que debería ser pública. Si la respuesta de una portada pública intenta crear una cookie, algo en tu sitio está generando sesiones donde no debería.

2. Probá en una ventana privada

Una ventana de incógnito no trae cookies previas. Si en incógnito el sitio responde rápido y en tu navegador normal no, el culpable es una cookie almacenada. Si es lento en ambos, el problema es otro.

3. Desactivá plugins de a uno en staging

Si sospechás de un plugin que abre sesiones PHP, desactivalo en un entorno de pruebas y compará las cabeceras. Es la forma más directa de encontrar al responsable sin tocar producción.

Cómo corregirlo

• Limitá el alcance: las cookies de carrito o sesión solo deberían actuar en las URLs que realmente son dinámicas.
• Reemplazá lo que no necesitás: si un plugin abre una sesión PHP en todas las páginas solo para una función menor, buscá una alternativa o cargá esa función por JavaScript.
• Mové lo personalizado al navegador: el saludo "Hola, Ana" o un contador de carrito pueden pedirse por JavaScript después de cargar la página, y así el HTML base sigue siendo igual para todos.
• Revisá las reglas de exclusión de tu caché: una lista de cookies que "evitan caché" demasiado amplia es una causa frecuente de aciertos bajos.

Un enfoque distinto: HTML estático

Con un sistema que sirve la página como archivo estático, la decisión de qué se cachea y qué no queda mucho más clara, porque cada URL pública es un archivo. Si te interesa cómo funciona ese enfoque, podés leer la explicación en cómo funciona cache.lat y los detalles en la página de datos técnicos. Para dudas de configuración, la documentación es el mejor punto de partida.

Lista rápida de verificación

• Probá tu portada en una ventana privada y revisá si hay Set-Cookie.
• Identificá qué plugin crea cada cookie que veas.
• Excluí de caché solo lo que realmente es dinámico.
• Pasá la personalización a JavaScript siempre que sea posible.
• Repetí la prueba después de cada cambio, no al final.

Si tu sitio sigue sin aprovechar la caché y no encontrás por qué, escribinos y lo revisamos juntos.