Caché para WordPress 6.6

Hacer que un WordPress funcione mejor es algo básico, pero no debemos confundir poner un parche en un WordPress que va mal para que vaya mejor, con mejorar los recursos de uno que ya funciona bien. Aquí es donde entran las cachés.

---

Qué es una caché

Lo primero que deberíamos preguntarnos es qué es una caché y por qué es importante.

Básicamente, una caché es una copia de algo. Por ejemplo, si publicamos en nuestro blog una vez al día y pedimos las 10 últimas entradas, ahora esas 10 serán las mismas que dentro de 1 hora, y que dentro de 6, y 12 y 23… a las 24 horas esa consulta cambiará porque tendremos una nueva entrada que hará que todo cambie.

Teniendo esto en cuenta, ¿para qué queremos que todas las personas que visitan nuestro blog saturen la base de datos haciendo llamadas «a lo mismo»? Para eso está la caché.

En este caso, los resultados de nuestras 10 últimas entradas los vamos a guardar, para que la persona que venga después tenga una versión guardada, que es igual y que va a devolver lo mismo que la información guardada. Al estar cacheada, el sistema accede de forma mucho más rápida y sin tener que calcular.

Las cachés de WordPress

WordPress tiene distintas capas de caché que se pueden activar o no según necesitemos o sea interesante para nuestro sitio.

Hay que tener en cuenta que cada sitio es distinto, por lo que no todos van a necesitar todas las capas de caché, ni todas se han de configurar de la misma manera, ya que los recursos del hosting van a permitir hacer unas cosas u otras.

Cada capa de caché puede aplicar a uno o distintos elementos… en este caso, se ha planteado la caché desde lo más profundo/lejos del usuario, hasta lo más público/cercano al usuario.

OPcode Caché

Esta caché, también conocida como OPcaché, es una caché simple, pero muy efectiva.

Normalmente, se da con respecto a código, en este caso de PHP, que es el lenguaje de programación de WordPress.

PHP, entre otras cosas, permite hacer «includes» o «funciones», que permiten que distintas partes del código estén en distintos ficheros.

Gracias a este sistema de caché, todas esas funciones, inclusiones y elementos se precompilan/preparan y almacenan de forma calculada. De esta forma, cuando se va a ejecutar el código, todas esas llamadas de un sitio a otro no se tienen que hacer porque el sistema ya los ha hecho previamente.

Con este sistema, mientras el código no cambie, podemos tener una versión optimizada del funcionamiento de WordPress a nivel muy bajo.

Hay que tener en cuenta que esta caché se debe invalidar con cierta frecuencia, ya que cada vez que se cambia el código, o se incluyen nuevos elementos, se han de incluir.

Un ejemplo que se ha añadido en las últimas versiones es el de la caché de traducciones, que funciona mediante este sistema. Las traducciones ahora se almacenan en ficheros PHP, de forma que puedan precargarse en memoria.

Para que esta caché funcione, hay que configurar el PHP para ello. Hay que tener en cuenta que si tu servidor lo tiene configurado, esta caché estará sí o sí, por lo que, si está activa, necesitarás un plugin que invalide los cambios cuando corresponda. Si tu proveedor lo tiene activo, deberás buscar si se puede activar o no en su sistema/panel y configurarlo, ya que es una caché que no es muy gestionable por el usuario/WordPress.

Algunos plugins para invalidar esta caché los puedes encontrar en opcache.

Fragment Caché

La caché de fragmento es algo que en sí mismo no depende de WordPress, sino que es una tecnología que solo algunas herramientas soportan.

Como es algo que raramente se va a usar con WordPress, directamente la voy a ignorar, al ser compleja de aplicar en un proyecto real.

Object Caché

La caché de objetos es quizá una de las más interesantes para WordPress. Y es que el sistema utiliza mucho las consultas a la base de datos, y este sistema lo que hace es almacenar eso: resultados de la base de datos (principalmente).

En realidad, WordPress ya utiliza internamente una caché de objetos cada vez que carga una página. Por ejemplo, si en una misma página se hacen dos veces llamadas a la misma consulta, en realidad la segunda recoge los datos de la primera, en un cacheo interno.

¿Qué es lo que WordPress permite más o menos de forma nativa? Conectar con Memcached y Redis como sistemas de caché alternativos.

Para que esto ocurra hacen falta plugins que permitan activar la caché de memcached o de redis, y, de la misma forma que se hace nativo, se almacenarán los datos en alguno de estos sistemas con una diferencia: la caché no es solo para una página, sino constante.

Esto hace que si distintas páginas hacen las mismas consultas y los datos no cambian, la caché se mantendrá activa durante el tiempo que se haya marcado hasta su invalidación, o hasta que alguien cambie los datos y el plugin fuerce la invalidación.

Existen otros sistemas y herramientas con las que puedes obtener una caché de objetos. Algunos ejemplos son con SQLite, o en el propio sistema de ficheros.

Full-Page Caché

Este es probablemente el sistema de caché más antiguo implementado en WordPress y que tiene sus bases en tecnología española con WP-Cache optimizando unos primeros pasos de Staticize Reloaded.

El sistema de esta caché es sencillo: un usuario visita una página, lo que significa que se ha calculado todo lo necesario para que esa página exista. Si un usuario va a visitarla 1 segundo después, ¿hace falta calcular todo? No sería lo óptimo, y esto lo que hace es que la página, el HTML resultante, se almacene en un fichero del disco.

La siguiente visita, lo primero que hace es validar en el disco si ese fichero existe… si existe, directamente lo devuelve (sin pasar por WordPress ni PHP) y si no existe, se regenera.

En este caso, es muy importante tener un buen plugin que haga las invalidaciones correctas para eliminar contenidos obsoletos cuando corresponda mediante un plugin de caché de página.

Este tipo de caché siempre debería estar activado en tu sitio, como mínimo, para intentar minimizar la carga de trabajo del servidor, pero revisa bien la documentación para validar que esté bien configurado y que realmente funcione.

Proxy Caché

Como evolución del punto anterior, quizá no queramos que la caché se haga en el propio disco y servidor web donde está la web, y lo queremos poner en otra herramienta intermedia, entre el usuario y la web, a modo de proxy-caché.

En este caso, hará falta un servicio intermedio que haga de proxy, como suele hacerlo Varnish o nginx, aunque hay otros sistemas.

Esto es algo que por norma general tu proveedor de hosting no te va a ofrecer a menos que se pida o configure explícitamente.

En este caso, es muy importante que funcione la invalidación, ya que si no, el sistema cacheará sobre la base de las reglas y puede generar que aparezcan contenidos obsoletos durante mucho más tiempo del deseado.

Puedes encontrar algunos plugins para distintas herramientas de proxy caché.

Static Caché

La caché de estáticos es bastante similar a la del HTML, pero con ligeras diferencias.

En general, un contenido estático (a diferencia de uno dinámico) no debe variar. Esto significa que, por ejemplo, el contenido de un HTML; de una web, puede ir variando durante el tiempo, pero se supone que una imagen siempre va a ser la misma. Lo mismo pasa con los CSS y JavaScript.

Esta, por ejemplo, es la razón por la que los CSS y JavaScript, en WordPress, siempre llevan una cadena con su versión al final.

Y también por la que una vez has subido una imagen al servidor, no se debería sustituir, sino poner con otro nombre y cambiar la ruta donde sea necesario.

En cualquier caso, aunque la carga de imágenes está bien preparada en WordPress, la de los CSS y JavaScript es mejorable. Por defecto, las rutas con el símbolo de interrogante (o sea, el de la versión) no se cachean.

Además, WordPress suele llamar a cada CSS y JavaScript por separado, haciendo muchas consultas, lo que se traduce en muchas consultas al disco y, por lo tanto, más lentitud.

Existen distintos sistemas que mejoran estas cachés, por ejemplo, fusionando los CSS y JavaScript en uno o varios, con un proceso de fusión y minimizado.

Content Delivery Network (CDN)

A diferencia de la caché de página, como los contenidos estáticos no deben cambiar, podemos hacer un proceso similar al de los proxy y mandar esos CSS, JavaScript e imágenes a servidores repartidos por todo el planeta, en las llamadas.

Content Delivery Network, o CDN, que están pensadas para servir contenidos estáticos de forma muy rápida.

WordPress dispone de unos sistemas para poder optimizar el sistema como si de una CDN se tratase de forma nativa, y que permite cachear de una forma mejor.

Aun así, siempre se puede buscar herramientas de CDN de terceros que permitan escalar el sitio, sobre todo útil cuando tu sitio tiene mucho tráfico de muchos países distintos, ya que si no, una CDN tiene mucha pérdida de caché aplicable.

Existen muchas CDN y plugins para ellas.

Caché local

No debemos olvidar nunca la caché local del navegador. Y es que, si ya te has descargado el logo de mi sitio, ¿necesitas descargarlo a la próxima página que visites? La respuesta es no.

La caché local permite que el servidor le diga a tu navegador que, durante una serie de horas, días o el tiempo que se defina, lo que se ha descargado no cambie y, por lo tanto, si vuelves a visitar el sitio no haga falta descargarlo de nuevo «porque ya lo tienes».

Este sistema también es básico tenerlo bien configurado, ya que permite que al navegar por el propio sitio, por ejemplo entrar en la página principal, ir a una entrada y volver a la página principal, haga que el sistema cargue muy rápido porque el contenido va quedando en el propio navegador del usuario, y no se tenga que hacer llamadas al servidor.

La caché local se configura en el servidor web, por lo que no requiere de ningún plugin o configuración en el propio WordPress.

Cuándo cachear

Ante la pregunta de cuándo hay que cachear contenidos o cualquier elemento, la respuesta es sencilla: siempre que se pueda.

Hay que tener en cuenta algunas casuísticas y excepciones.

La más sencilla son los entornos de desarrollo. Cuando estás montando un sitio con WordPress, o programando un tema o plugin, o revisando cualquier cosa, lo mejor es no tener cachés para ver exactamente y en tiempo real qué está pasando.

Sí, el sistema va a ir más lento, pero estás en modo desarrollo, por lo que lo importante en ese momento no es tanto la velocidad como poder validar que todo funciona correctamente.

Otro caso en el que no se debe cachear es cuando se está en «modo DEBUG», es decir, buscando errores. En este caso, lo mejor es no tener nada activo, aunque puede ser interesante para ese momento, precisamente, tener las cachés activadas al ser lo que se está revisando.

La web va mal

Si tu sitio va mal, cachear es un parche. Sí, está bien, puedes (y casi debes) hacerlo, pero no es la solución.

Si un sitio va mal has de encontrar el origen del problema, ya que la caché ha de ser una ayuda a algo que funciona bien, no una solución o parche para hacer que algo vaya mejor.

En los casos en los que un sitio va mal, hay que analizar cuál es el origen e intentar corregirlo y, posteriormente, poner una caché que lo mejore aún más.

La caché no mejora

Si al activar una caché no mejora la optimización de un sitio, lo más probable es que la caché esté mal configurada.

Es muy raro que un sistema de caché, cualquiera que sea, no funcione, porque significa que el sistema de origen no es cacheable, algo que va en contra de la propia filosofía.

Como decía, en las distintas capas de caché cada una tiene una función, y si esa función no mejora tras activar la caché, quiere decir que hay algo ahí que no está bien planteado.

Un ejemplo claro pueden ser los plugins que hacen consultas a una API externa, por ejemplo, y no especifican que los datos se almacenen en la caché durante un tiempo, lo que hace que cada vez que el usuario acceda, se haga esa llamada, algo que ralentiza todo.

Cachear no es optimizar

Debemos tener en cuenta que estos dos elementos van de la mano, pero no son lo mismo.

Podemos tener un muy buen sistema de caché, una muy buena CDN, pero eso no significa que aunque tengamos todo pre calculado el sistema esté optimizado para funcionar de la mejor manera.

Sí, el sitio irá más rápido porque ha de calcular menos elementos, pero sigue sin estar optimizado que el sistema haga 10 llamadas a los CSS, pudiendo hacer solo 1.