Caché de página vs caché de objetos en WordPress: cuál necesitás

Cuando un sitio WordPress va lento, la primera recomendación suele ser «instalá un plugin de caché». El problema es que «caché» abarca capas muy distintas, y mezclarlas lleva a configurar lo que no hace falta y a dejar sin resolver lo que sí. Acá va una guía práctica para distinguir la caché de página de la caché de objetos.

Qué hace la caché de objetos

WordPress consulta la base de datos muchas veces por cada petición: opciones, metadatos, términos, usuarios. La caché de objetos (con backends como Redis o Memcached) guarda los resultados de esas consultas en memoria para no repetirlas.

• Reduce la carga sobre la base de datos.
• Ayuda tanto a visitantes anónimos como a usuarios con sesión.
• Pero PHP sigue ejecutándose: WordPress arranca, carga plugins y el tema, y construye la página en cada visita.

Es muy útil en áreas dinámicas: el panel de administración, una tienda con carrito, un sitio de membresías.

Qué hace la caché de página

La caché de página guarda el HTML ya terminado de cada URL. Cuando llega un visitante, se le entrega ese resultado sin volver a construirlo. Según cómo esté implementada, puede evitar por completo el paso por PHP y la base de datos.

HTML estático como archivo

La variante más directa es escribir el HTML como un archivo y dejar que el servidor web lo entregue. No hay arranque de WordPress ni consultas: es lo mismo que servir una imagen. En cómo funciona cache.lat explicamos el proceso de generación y regeneración de esos archivos, y en los datos técnicos encontrás los detalles de implementación.

¿Una u otra? Depende de quién visita

• Blog, sitio corporativo, landing pages, documentación: casi todo el tráfico es anónimo y el contenido cambia poco. La caché de página es la que más impacto tiene.
• Tienda online: las páginas de catálogo se pueden cachear, pero carrito, checkout y cuenta de cliente deben quedar fuera. Acá la caché de objetos aporta bastante.
• Sitios con login masivo (cursos, comunidades): la caché de página ayuda poco; pesa más la caché de objetos y un buen hosting.

Errores comunes

1. Apilar tres plugins de caché. Se pisan entre sí y generan comportamientos difíciles de depurar. Una capa de página y, si hace falta, una de objetos.
2. No excluir lo dinámico. Carrito, checkout, formularios con nonces y áreas privadas no deben servirse desde una copia compartida.
3. Olvidar la invalidación. Si publicás o editás una entrada y el visitante sigue viendo la versión vieja, la caché no está regenerándose como debería.
4. Medir solo con el sitio «caliente». Probá también la primera visita tras vaciar la caché para saber cuánto cuesta realmente construir cada página.

Cómo decidir en tres pasos

1. Revisá qué porcentaje de tu tráfico es anónimo. Si es la mayoría, empezá por la caché de página.
2. Identificá las URLs que nunca deben cachearse y excluilas explícitamente.
3. Si después de eso el panel o las zonas con sesión siguen lentos, sumá caché de objetos y revisá consultas pesadas y plugins.

Cómo medir el efecto

No hace falta inventar números: compará el tiempo hasta el primer byte (TTFB) de una URL antes y después, desde la misma ubicación y varias veces. Con una caché de página bien aplicada, la diferencia en visitantes anónimos suele ser evidente en esa métrica, y eso repercute en métricas como LCP.

Siguiente paso

Si querés ver cómo encaja cache.lat en tu sitio, la documentación recorre instalación y exclusiones, y podés consultar la página del producto. Y si tenés un caso particular, escribinos desde contacto.