Las distintas cachés en WordPress – Lo que siempre quisiste saber y nadie te había contado

El almacenamiento en caché en WordPress se suele malinterpretar, y las webs cargan más lento de lo que deberían como resultado de ello.

En esta guía espero desmitificar algunos de esos conceptos erróneos y proporcionar un poco de claridad en el asunto técnico, que lo es, del almacenamiento en caché de WordPress.

Espero que, al final de esta guía, tengas una mejor comprensión de cómo las diferentes capas de caché juegan un papel en la optimización de WordPress.

Qué es la caché y por qué es importante

Una caché es una capa de almacenamiento que almacena copias temporales de datos o archivos de una solicitud, para que las futuras solicitudes puedan acceder a ese contenido más rápidamente.

En WordPress, esto puede significar cualquier cosa, desde el almacenamiento en caché de una página completa, hasta el almacenamiento en caché de los resultados de una consulta a la base de datos.

Antes de que nos sumerjamos en los diferentes mecanismos de almacenamiento en caché, es esencial entender los beneficios del almacenamiento en caché. El almacenamiento en caché desempeña dos funciones principales:

1. Mejora el rendimiento de la aplicación. En el caso de los sitios WordPress, esto significa que tu sitio se carga más rápido y proporciona una mejor experiencia de usuario.
2. Aumenta el rendimiento de la aplicación. Esto significa que tu sitio puede manejar más tráfico.

Es más, el almacenamiento en caché puede aumentar el rendimiento de la aplicación sin aumentar los costes de alojamiento. Esto se debe a que se necesitan muchos menos recursos del sistema (CPU y memoria) para alojar un sitio que ha sido correctamente almacenado en caché.

Además, un mejor rendimiento puede ser beneficioso para el SEO, ya que la velocidad de la página es uno de los factores de posicionamiento que utilizan los motores de búsqueda. Se trata de una estrategia en la que todos ganan (cuando se hace correctamente).

Capas de caché

WordPress es un CMS basado en bases de datos, lo que significa que hay muchas partes en movimiento para gestionar cada solicitud entrante.

Por ejemplo, WordPress tiene que consultar la base de datos y procesar la página antes de enviarla al usuario. Esto sucede en cada solicitud entrante, lo que es enormemente ineficaz si el contenido de la página no ha cambiado.

Una petición típica será algo así:

Por lo general, cuantas más partes móviles intervienen en la gestión de una solicitud, más tiempo tiene que esperar el usuario para obtener una respuesta y más recursos del sistema se utilizan.

Para combatir esto, el almacenamiento en caché se realiza a menudo en capas, y cada capa se sitúa delante de una parte móvil. Las tres capas principales en WordPress se suelen desglosar en:

1. Caché del navegador
2. Caché de página
3. Caché de objetos

Vamos a sumergirnos en cada una de esas capas. Trabajaremos desde fuera hacia dentro, lo que nos lleva a la primera, a la caché del navegador.

Caché del navegador

Aunque el almacenamiento en caché del navegador no ayuda necesariamente al tiempo de respuesta de la aplicación o al rendimiento (al menos en lo que afecta a WordPress), es la capa más importante cuando se trata de reducir la cantidad de datos que deben enviarse desde el servidor al navegador.

Esto puede hacer que tu sitio se perciba mucho más adaptable (responsive) porque los activos estáticos como CSS, JS e imágenes aparecen mucho más rápido si los cachea el navegador.

Cuando se trata de entender el caché del navegador, la pestaña de red en las herramientas de desarrollo de tu navegador es tu mejor amigo. Echemos un vistazo a la caché del navegador en acción, cargando este sitio, AyudaWP.com, como ejemplo.

La primera carga de la página no tendrá ningún activo cacheado por el navegador. (He activado la opción «Disable cache» para simular una carga de página inicial).

Las métricas que nos interesan son la cantidad de datos transferidos y los recursos totales.

En primer lugar, ten en cuenta que cada métrica tiene dos valores porque puedes filtrar los resultados por tipo de recurso. Esto te permite ver fácilmente qué tipo de recursos está ocupando la mayor parte del ancho de banda.

En segundo lugar, el valor transferido debe ser siempre inferior al total de recursos, aunque sea la primera vez que el navegador carga la página (o esté activada la opción «Disable cache»), por dos razones:

1. Los activos que se almacenan en la caché del navegador no se transfieren.
2. Los activos como HTML, CSS y JS deben comprimirse (usando Gzip o Brotli) por el servidor antes de transferirse al navegador. Luego los descomprime el navegador antes mostrarlos al usuario.

Por lo tanto, si la caché del navegador está correctamente configurada, las siguientes cargas de la página deberían transferir menos datos. Puedes comprobarlo por ti mismo cuando recargamos la página.

Los datos transferidos han bajado de 808 Kb a 108 Kb, lo que supone un gran ahorro. También notarás que la métrica de carga ha bajado de 1.32 a 1.02ms.

Puedes configurar el comportamiento de la caché del navegador mediante las cabeceras cache-control y expires que tu servidor añade a la respuesta de los activos estáticos.

La cabecera cache-control tendrá prioridad sobre la cabecera expires más antigua. Sin embargo, ambas suelen aplicarse para garantizar la compatibilidad con algunos servicios proxy heredados.

Puedes comprobar estas cabeceras con distintas herramientas…

Normalmente, la cabecera cache-control tendrá un valor de max-age=segundos que indicará al navegador que guarde el archivo en la caché durante un máximo de segundos y evitará que se vuelva a descargar en posteriores peticiones.

En el caso anterior, el archivo será almacenado en caché por el navegador durante un máximo de 1 año.

Problemas habituales con la caché del navegador

1. 1. La invalidación de la caché es difícil. Una vez que un navegador ha almacenado en caché un activo utilizando cache-control: max-age=segundos no puedes decirle al navegador que lo desactive, al menos no sin cambiar la URL. Por ello, WordPress añade una cadena de consulta de versión a los activos encolados. Por ejemplo:

      https://ayudawp.com/wp-includes/css/dashicons.min.css?ver=5.2.2

   2. Las herramientas de análisis de velocidad de sitios web, como PageSpeed o GTMetrix, mostrarán advertencias sobre caducidad de cabeceras de corta duración. A menudo, estas advertencias se activan debido a activos externos como Google Analytics. Esto se debe a que los servicios externos tienen que utilizar tiempos de caducidad cortos para asegurar que sus activos se actualizan, debido a las dificultades con la invalidación de la caché. Con un tiempo de caducidad largo tendrías que actualizar tus scripts incrustados cada vez que Google Analytics cambiara su código. No hay que olvidar que el tiempo de caducidad es muy corto.
   3. Las cabeceras cache-control y expires no son las únicas que utiliza el navegador para determinar si un recurso debe obtenerse del servidor. Por ejemplo, una vez transcurrida la duración especificada por cache-control: max-age=segundos, se utilizará la cabecera etag. Esta contiene un identificador de validación (similar a un algoritmo MD5 del recurso solicitado), que se compara con el identificador del recurso almacenado en el servidor. Si el valor del etag es el mismo, el recurso devuelve una respuesta «304 Not Modified». Esto indica al navegador que el recurso almacenado en caché no ha cambiado y que debe renovar el tiempo de expiración especificado en cache-control: max-age=segundos. La caché de HTTP da para todo una guía aparte, así que de momento no me extenderé.

Cómo optimizar la caché del navegador

Podemos optimizar para nuestro beneficio la caché del navegador aplazando la actualización de descarga de los contenidos, como veíamos en esta guía:

Cómo solucionar los errores Leverage Browser Caching en WordPress

Por otro lado, si tu hosting utiliza NGINX Direct Delivery, ya optimiza esta parte por tí.

Caché de página

La caché de página va a proporcionarte el mayor beneficio en lo que se refiere a mejorar tanto el tiempo de respuesta de la aplicación como el rendimiento.

La caché de página esencialmente convierte a WordPress (un CMS basado en una base de datos) en un sitio HTML estático al sacar a PHP y MySQL de la ecuación cuando se trata de gestionar una solicitud.

El tiempo medio de respuesta es cinco veces más rápido cuando se activa la caché de página. Esto es bastante llamativo si tienes en cuenta que se gestiona una cantidad 10 veces mayor de solicitudes por segundo.

Problemas habituales con la caché de página

1. La caché de página es extremadamente problemática cuando los sitios muestran contenido personalizado como las webs de comercio electrónico o son muy dinámicos como los foros. A menudo, la caché de página tendrá que desactivarse por completo o páginas específicas como /finalizar-compra tendrán que evitar la caché. Esto no pasa con WooCommerce como ya vimos, pero debes tenerlo en cuenta.
2. La invalidación de la caché puede ser complicada dependiendo de cómo se implemente. Debido a la naturaleza dinámica de WordPress, es difícil determinar en qué páginas se debe vaciar la caché cuando se actualiza el contenido (especialmente cuando hay archivos, paginación y widgets involucrados). Por ello, el método que se suele emplear es vaciar toda la caché de página cuando hay cambios en el contenido.
3. El uso de varias soluciones de caché de páginas no mejorará el rendimiento. De hecho, no te aconsejo que utilices varias soluciones de caché de página, ya que puede causar incoherencias en la caché (diferentes versiones de tu sitio almacenadas en cada caché) y dificultar la invalidación de la caché.
4. La caché de página suele estar desactivada para los usuarios que han iniciado sesión, por lo que sigue siendo aconsejable la caché de objetos (más abajo).

Cómo optimizar la caché de página

Para optimizar las consultas dinámicas puedes utilizar cualquiera de los plugins de caché que existen, como WP-Rocket, WP SuperCache y otros o, más eficientemente, APO de CloudFlare.

Caché de objetos

Como he mencionado anteriormente, no todas las páginas pueden almacenarse en la caché. Esto es especialmente importante para las webs de comercio electrónico y de afiliación, que a menudo muestran contenidos personalizados.

También pasa con el área de administración de WordPress. Si estas páginas dinámicas se almacenaran en la caché, los usuarios verían contenidos personalizados que no serían relevantes para ellos.

WordPress tiene incorporada la caché de objetos, lo que permite que datos como las consultas a la base de datos se almacenen en memoria. De este modo, las múltiples llamadas a funciones como get_posts sólo generan una única consulta a la base de datos.

Sin embargo, la caché de objetos no es persistente por defecto (lo que significa que no vive más allá de una petición).

Por suerte, WordPress puede integrarse con sistemas de almacenamiento de datos persistente como Memcached o Redis, fundamental para escalar páginas dinámicas.

La caché de objetos se sitúa entre PHP y la base de datos, lo que acelera el tiempo de ejecución de PHP y reduce la carga de la base de datos al almacenar las consultas en la memoria.

Puedes ver el impacto que tiene una caché de objetos instalando el plugin Query Monitor.

Cargar la página del carrito de WooCommerce sin la caché de objetos activada da como resultado 109 consultas a la base de datos:

Con la caché de objetos activa, Memcached en este ejemplo, baja hasta 32 consultas a la base de datos y reduce el tiempo de generación de la página de 0.5305 segundos a 0.3434 segundos:

Estas pruebas están hechas en un servidor de SiteGround con las últimas versiones de WooCommerce y WordPress, PHP 8.0.3, el tema Proteo y contenido demo.

Problemas habituales con la caché de objetos

1. Se requiere software de servidor adicional como Redis o Memcached para que la caché de objetos sea persistente. Esto debería estar resuelto si utilizas un buen proveedor de hosting WordPress, o puedes instalarlo tú mismo si gestionas tu propio servidor.
2. La caché de objetos no elimina por completo la dependencia de la base de datos, que suele ser el mayor cuello de botella en WordPress. Esto se debe a que las consultas SQL para construir el índice de entradas se ejecutarán siempre, ya que los resultados no se almacenan en la caché.

Cómo optimizar la caché de objetos

Como te comentaba arriba, necesitas que tu hosting tenga instalado y activo un sistema de gestión de caché de objetos, como Redis o Memcached, salvo que dispongas de un servidor dedicado y sepas instalarlos y configurarlos por tu cuenta.

Estos sistemas de caché suelen activar la caché de objetos interna de WordPress para aprovechar el motor existente y optimizarla. Para ello suelen realizar dos acciones:

1. Activar la caché de objetos en el archivo wp-config.php con define('WP_CACHE', true);.
2. Crear archivos de caché de objetos avanzados como object-cache.php o advanced-cache.php en la carpeta wp-content. Estos archivos suelen aparecer en tu pantalla de plugins como plugins dependientes o drop-in.

Plugins de caché para WordPress

Los plugins de caché más populares, como WP Rocket, W3 Total Cache o WP Super Cache, son una forma habitual de añadir prestaciones de caché a tu sitio.

Sin embargo, es posible que no necesites usar ningún plugin. Debes tener en cuenta que los plugins de almacenamiento en caché no siempre funcionan tan bien como el almacenamiento en caché basado en el servidor.

Un buen proveedor de alojamiento de WordPress se encargará del almacenamiento en caché por ti.

¿Y qué pasa con CloudFlare?

Si estás usando Cloudflare, puede que te preguntes si siguen siendo necesarias las diferentes capas de caché.

Para responder a esto, tenemos que entender que, por defecto, Cloudflare solo almacenará en caché tus activos estáticos (CSS, JavaScript, imágenes) en la CDN.

Esto significa que cuando un visitante llega a tu sitio, la versión en caché de esos activos se descargará del servidor de la red CDN más cercano a su ubicación. Esto reduce el tiempo de carga de los activos del sitio.

Una CDN como Cloudflare se puede utilizar además de las otras capas de almacenamiento en caché. Aunque la caché de páginas y la caché de objetos siguen siendo importantes para optimizar tu sitio WordPress.

Recuerda que es posible configurar reglas de página en Cloudflare para el almacenamiento en caché de la página completa. Sin embargo, la opción de omitir la caché basada en cookies solo está disponible para los planes Business y Enterprise.

La posibilidad de omitir la caché basada en las cookies es fundamental para un sitio WordPress con el fin de evitar servir las respuestas en caché a los usuarios que han iniciado sesión, o para otros contenidos dinámicos como el carrito de compra en una web de comercio electrónico.

Cloudflare ofrece la plataforma de optimización automática para WordPress, que puede resolver estos problemas a un coste de 5 dólares al mes por dominio para los usuarios del plan gratuito, e incluso tienes esta guía para aprovechar sus ventajas sin tener que pagar por la plataforma.

Hasta aquí y más allá

Bueno, espero que te haya gustado esta guía, aunque sólo he arañado la superficie en lo que se refiere al almacenamiento en caché en WordPress.

Eso sí, espero que hayas comprendido mejor cómo funcionan las distintas capas de almacenamiento en caché.

Si quieres profundizar, te recomiendo que consultes los recursos sobre caché HTTP de la web para desarrolladores de Google, que ofrece más información sobre el almacenamiento en caché del navegador.

La sección de artículos sobre optimización WordPress de Ayuda WordPress es otro excelente recurso para aprender más sobre cómo mejorar el rendimiento y velocidad de carga de sitios WordPress.

¿Te quedan dudas sobre la caché en WordPress? Pregunta en los comentarios de abajo.

¿Te gustó este artículo? ¡Ni te imaginas lo que te estás perdiendo en YouTube!