Introducción al cache en WordPress

En este artículo voy a tratar de acercar a los webmasters más nóveles y los no tan nóveles, en que consiste el cache en WordPress y como conseguimos que nuestro blog ofrezca tiempos de respuesta más rápidos. Estamos acostumbrados a leer que si queremos conseguir una mayor velocidad de respuesta en nuestros blogs WordPress debemos emplear un plugin de cache. Después de leer esto, cualquier administrador de un blog WordPress se lanza a por un plugin de cache y no quiere instalar cualquier plugin, quiere instalar el mejor. La primera sorpresa es que no hay un mejor plugin de cache, sino que tenemos varios a nuestra disposición y que se pueden adaptar mejor o peor a las necesidades y condiciones de cada usuario.

A continuación voy a tratar de describir una serie de conceptos que os ayudarán a entender el cache en WordPress y al mismo tiempo os pueden servir de ayuda a la hora de elegir opciones de configuración en plugins de cache.

Conceptos para entender el cache en WordPress

Cache estático de páginas (static page caching).

Cuando instalamos un plugin de cache en nuestro blog WordPress, en la mayoría de los casos estamos recurriendo a este tipo de cache. Esta técnica consiste en almacenar el contenido de las páginas de nuestro blog, es decir, se guarda todo el código HTML. De esta forma, conseguimos que WordPress no tenga que volver a generar todo el código de la página empleando PHP, que este a su vez hará peticiones SQL. De aquí ya os podéis imaginar que servir código HTML ya generado directamente, necesita muchos menos recursos que volver a generarlo y servirlo.

Está claro que consumimos menos recursos, pero esto tiene una desventaja cuando nuestro blog tiene elementos dinámicos, es decir, que cambian con el paso del tiempo. Para entender esto de “elementos dinámicos” vamos a imaginarnos que en mi blog WordPress, cada vez que alguien lo visita genera con PHP una imagen de un reloj que marca la hora especificando minutos y segundos. El plugin de cache guarda todo el código HTML incluida la imagen del reloj, que marcará la hora en la que el plugin generó la página (vamos a suponer que el reloj marca las 18 horas, 20 minutos y 5 segundos). El problema viene cuando un visitante llega a nuestra página a las 18 horas, 21 minutos y 2 segundos, porque el reloj marcará la hora en la que el plugin de cache generó la página y no la hora actual.

El ejemplo anterior es para que podáis entender de una forma más gráfica cual es el problema del caché estático de páginas, porque ese problema del reloj tendría fácil solución empleando tecnologías como AJAX o Javascript, pero no es el propósito de este artículo.

Por este motivo, los plugins de cache suelen tener opciones para establecer cada cuanto tiempo queremos que se vuelvan a generar las páginas almacenadas en el cache. Algunos plugins incluson vuleven a generar la página cuando modificamos el artículo e incluso llegan a generar nuevamente los archivos de categorías y etiquetas para que muestren el nuevo artículo publicado.

Cache de objetos (Object caching).

El cache de objetos consiste en almacenar pequeñas partes del código. Normalmente estos objetos son códigos del tipo get_option( ‘algo’ ); que se ejecutan en prácticamente la totalidad de nuestras páginas WordPress, el ejemplo más común es get_option( 'blogname' ); que obtiene el nombre de nuestro blog. La ejecución de estos objetos, generalmente implica hacer una o varias peticiones SQL, lo que consume una cantidad considerable de recursos.

Cache de objetos persistente (Persistent object caching).

Los objetos de los que hablábamos antes, necesitamos almacenarlos en el cache de forma persistente, es decir, que estén disponibles en el cache a lo largo del tiempo. Los diferentes plugins de cache de WordPress, para conseguir el cache de objetos persistente, necesitan crear un archivo llamado object-cache.php en la carpeta /wp-content/.

Una vez que se crea este archivo, se comienza a usar la API de cache de objetos de WordPress ahorrándonos así peticiones SQL y reduciendo el consumo de recursos. El proceso de optimización no termina aquí, ya que debemos determinar dónde y cómo se almacenará este cache de objetos. Generalmente se almacenan en el disco duro, lo cual no es la opción más rápida, nuestra mejor opción es emplear algún tipo de Opcode Cache como APC o eAccelerator (lamentablemente estas opciones no están disponibles en la mayoría de alojamientos compartidos).

Como información adicional, deciros que si empleáis PHP en su versión 5.5 o superior, ya no incluye APC, ya que se ha reemplazado por Zend Opcache, pero este último tiene el inconveniente de que no soporta el cache de objetos. A pesar de haberse detenido el desarrollo de APC de forma oficial, existe una versión la alternativa APCu, la cual podemos emplear como reemplazo a APC.

Llegados a este punto, muchos os estaréis preguntando: “Si empleo el cache estático de páginas que genera todo el código HTML y después lo sirve a los visitantes, ¿para qué quiero activar el caché de objetos?”

Disponer de un sistema de cache de objetos nos va a beneficiar durante la ejecución del plugin de cache, cuando realice la tarea de generar el código HTML de nuestras páginas. La teoría nos dice que empleando el cache de objetos en disco se tarda más en generar cada página, pero consume menos recursos del servidor. Si nuestro blog además ofrece la posibilidad de registro a los usuarios e interactuar con el blog (publicando comentarios, subiendo imágenes, etc), disponer de sistema de cache de objetos es altamente recomendado. Por esto terminamos con la conclusión de que disponer de un sistema de cache de objetos, es algo que siempre nos va a beneficiar ya que ahorraremos recursos.

En definitiva, cuando optimizamos WordPress hay que encontrar el equilibrio entre un consumo de recursos razonable, al mismo tiempo que ofrecemos el menor tiempo de respuesta posible.