Los tres tipos de almacenamiento caché en WordPress

Publicado en WebPerf · 28 enero 2019.
Tres tipos de caché en WordPress

WordPress utiliza tres tipos de almacenamiento internamente que nosotros podremos utilizar para almacenar nuestras caché. Es importante conocer las características de cada uno, dado que una buena elección hará que nuestro sitio web tenga mejor rendimiento y, por tanto, cargue más rápido. Por contra, usar una caché en un almacenamiento equivocado hará el efecto contrario, es decir, nuestro sitio consumirá más recursos y esto dará lugar a una mayor lentitud de carga. También tienes que tener en cuenta que como WordPress los usa internamente, saber como funcionan nos dará más control sobre el CMS a bajo nivel y eso nos llevará a poder exprimir más el performance de nuestra web.

Dicho esto, veamos los tres almacenamientos de WordPress:

Object caché

Pese a que la API de Object cache es de las más antiguas de WordPress, es el sistema de almacenamiento más desconocido de este CMS.

Su funcionamiento es la mar de sencillo, ya que es similar a guardar en una variable global nuestros datos. De hecho, internamente trabaja así. Por lo que al guardar un valor en esta caché, sólo se mantendrá en RAM y mientras que dure la petición actual. Es decir, que si un navegador carga tu home y otro tu página de contacto. Este tipo de caché no se compartirá entre ambos y, además, cuando intenten cargar una nueva página esa caché no existirá y tendrá que generarse de nuevo.

Este tipo de caché es muy útil para evitar:

  • Realizar las mismas operaciones una y otra vez bajo la misma petición. Por ejemplo, calculas el total del carrito de la compra actual( recuerda que este tipo de caché no se comparte entre navegadores ) y lo guardas con esta caché( con la función wp_cache_add ). Si tienes que hacer más operaciones con este total o simplemente mostrarlo en más de una ubicación en la misma página, tan sólo lo recuperas de la caché( con la función wp_cache_get ).
  • Obtener los mismos elementos desde la base de datos una y otra vez. WordPress internamente usa sobretodo este caso. Es decir, cuando haces un get_post o get_posts o usas WP_Query, los datos de cada post es almacenado en Object caché y es recuperado si lo vuelves a pedir. También usa Object cache cuando obtiene los options de la base de datos para no tener que pedirlos si le solicitas de nuevo el valor. El desarrollador WordPress también puede usar este tipo de caché para uso propio, por ejemplo, ponte que obtienes todos los elementos de la miga de pan y lo guardas en la Object Caché de WordPress. Durante la creación del menú necesitarás obtener otra vez los elementos de la miga de pan, con la idea de marcar los menús pertenecientes a la miga de pan como activo. En vez de pedirlos de nuevo a la base de datos, los extraes del Object caché de WordPress reduciendo así el tiempo de carga de tu web.

Si sigues mis entradas de blog, seguramente te habrá resultado parecido Object caché a las variables estáticas que vimos en el post de Optimización de funciones PHP. Sí, porque básicamente es la misma cosa.

Transient

Existen plugins que hacen que Object caché se haga persistente, pero no está recomendado, pues terminará sobrecargando tu sistema, haciendo tu sitio web más lento que si no usaras caché. De hecho, antiguamente WordPress podía hacer persistente los datos de Object cache usando la constante WP_CACHE a true. Sin embargo, con la creación de los transients para solventar estos problemas de rendimiento, dejo de soportar esta característica.

Con la Transients API tenemos un sistema de almacenamiento medianamente persistente, ya que se mantiene entre peticiones, y entre diferentes navegadores. Recalco lo de medianamente persistente, porque lo recomendable es cachear nuestros datos como transients especificándoles un tiempo de expiración. Así evitaremos caer en los mismos problemas que cuando los Objects caché eran, o se hacen, persistentes. Aunque hay otro problema más grave y es que generalmente los desarrolladores desconocen el object caché y terminan guardando todo como transients, ocasionando que la base de datos de WordPress termine pareciendo un vertedero de basura. En fin...

Este tipo de almacenamiento caché es muy útil para:

  • guardar trozos html de nuestro sitio web que no suele cambiar muy a menudo: menus, sidebar, pie, … Así evitaremos que se tengan que generar por cada petición con lo que el tiempo de respuesta de nuestra web se reducirá.
  • conservar información de petición a petición pero que no necesitas que dure en el tiempo. Por ejemplo, podría usarse para llevar un tracking de los usuarios en línea: qué páginas están viendo, de qué página vienen, cuanto tiempo llevan, …

Wordpress internamente usa los transients para cosas como cachear los archivos de un tema.

Los transients se guarda internamente como options( que veremos ahora ), aunque lo recomendable es hacer uso de algún tipo de almacenamiento en memoria persistente( como Memcached ).

Options

La Options API es la manera que tiene WordPress para mantener ciertos datos persistentes( en la tabla wp_options ).

WordPress usa este sistema para, entre para otras cosas, guardar los transients como hemos visto antes. Sí, es cierto. Los transients no son más que un envoltorio( o wrapper ) de los options añadiendonles fecha de caducidad o expiración. De hecho, hay algo curioso sobre esto. Si guardas algo como transients especificándole un tiempo de expiración, cuando llegue ese tiempo de expiración el dato permanecerá guardado en la base de datos hasta que alguien entre en alguna de las páginas de tu sitio web. A veces eso crea problemas, pues los transients pueden durar más tiempo de lo que especificamos, así que tenlo en cuenta.

La Options API también se usa para guardar las opciones de configuración. De hecho, ese es su principal uso, de ahí el nombre de la API. Sin embargo, esto es un mal diseño, porque cada opción se guarda como un registro de la tabla wp_options. De manera, que si tu tienes un plugin y tienes 10 opciones de configuración para él, WordPress lo guardará como 10 registros. 10 registros que este CMS tendrá que recuperar por cada petición. Esto es muy lento, sin duda. Lo adecuado es agrupar todas las opciones de configuración del plugin como si fuera una única opción de configuración. Esto es fácil porque la options API permite almacenar datos no escalares como arrays u objetos.

Podemos usar los options también para almacenamiento caché, cuando el tiempo no es el factor determinante de refresco. Por ejemplo, cuando nuestra web usa una web API externa y esta utiliza un token de autenticación. Si ese token de autenticación caduca en el tiempo lo mejor es usar un transient para su almacenamiento, si caduca cuando lo establece la misma web API entonces mejor usar un option.

Más información

Pablo López ya escribió sobre esto en su post Optimizando el código y las consultas a base de datos para mejorar el rendimiento. Recomiendo su lectura.

¡ Compártelo !
Este sitio utiliza cookies propias y de terceros para mejorar tu experiencia con el sitio web. Al continuar con la navegación consideramos que acepta su uso.