WordPress es el gestor de contenidos más utilizado hoy en día y una de esas razones es la de utilizar tecnología al alcance de todo el mundo, principalmente PHP y MySQL o cualquiera de sus derivados). Pero esto hace que el software sea dinámico de serie desde el servidor.
Pero partiendo de la dinámica del PHP; también podemos plantear una serie de capas de caché que vienen de serie dentro del propio WordPress, que se pueden extender con plugins o sobrepasar con sistemas.
WordPress tiene muchas opciones en cuanto a capas de caché. Caché de navegador, de página, de compilador, de objetos, de fragmentos, transitoria, de base de datos o de disco. La cuestión es ¿cuáles de esas debes activar?
Hay que tener presente que depende de cada proyecto se pueden activar o configurar las caché de una forma más o menos agresiva, así que antes de comenzar lo primero que has de hacer es probar las distintas caché y verificar que funcionan correctamente según tus necesidades. Al fin y al cabo la caché se resume en un verbo: reutilizar.
Una de las primeras capas de caché a configurar es la caché de navegador. Básicamente lo que vamos a hacer es configurar el servidor web para los elementos más repetitivos y que no suelen cambiar en una misma sesión se lean una vez quedando alojados en el navegador del usuario en su dispositivo y posteriormente, según el usuario va navegando por la web sólo tenga que cargar las partes que cambian pero no las estáticas. Habitualmente se suelen cachear elementos como los CSS, JS, TXT, imágenes, vídeos… vamos, todo aquello que no suele variar con muca frecuencia. Lo que normalmente no se cachea es el HTML, al menos no aquí. Con esto conseguiremos que el usuario tenga que hacer menos llamadas al servidor, reduciendo el consumo de ancho de banda (los GB del móvil).
Una capa similar es la llamada CDN (Content Delivery Network) que es una capa de caché entre el navegador del usuario y el servidor. La idea principal es doble: por un lado hacer que algunos elementos estáticos como los CSS, JS, imágenes y demás se sirvan desde un lugar más cercano al usuario según su conexión a Internet, y por otro que el servidor principal no tenga que procesar peticiones menos útiles. En estos casos los datos se almacenan de forma distribuida y si cambias algo en local deberás invalidar el contenido del sitio remoto.
Hasta ahora he comentado los elementos más estáticos, pero también se pueden cachear algunos elementos dinámicos. En este caso hablo de la caché de página, que puede hacerse de distintas maneras. La clave es que los sitios web no se actualizan con muchísima frecuencia por norma general, y aunque se hagan con muchísima frecuencia podríamos hablar de que 1 minuto es mucho tiempo (el sitio web de un diario digital, por ejemplo). SI tienes mucho tráfico, un minuto es mucho tiempo y muchas visitas. La idea es que mientras el sitio no cambie, se sirva una versión ya generada de la página en sí. WordPress lleva una serie de hooks de forma que en el momento en el que se producen algunas acciones como por ejemplo publicar o modificar un contenido o se añaden comentarios, de forma que en el momento en el que un editor hace cambios sobre el contenido se puede configurar el sistema para que la próxima visita regenere esa página, y los usuarios que vengan detrás ya verán la información actualizada.
La caché de página puede realizarse principalmente en dos niveles de sistemas. Uno de ellos sería el de montar una capa de proxy-caché. La idea es que un servicio externo a WordPress se haga cargo de esta caché. Normalmente suele ser un software que hace de punto intermedio entre el usuario y el servidor web y que almacena una copia de la página. El sistema, mediante unas reglas, decide si tiene el contenido y por tanto lo sirve, o si no lo tiene (o ha de renovarlo) y lo pide a WordPress para que lo genere y se almacene una copia por el tiempo establecido. La otra opción está en que sea el propio WordPress mediante PHP el que gestione esa capa de caché; este caso suele ser el más conocido y que se gestiona con los típicos plugins de caché.
Otra capa es la que nos encontramos en el código fuente de PHP. Al fin y al cabo ¿cada cuánto cambia el código PHP de WordPress? Aunque hagamos una actualización al día de todos los plugins, traducciones, themes o el propio núcleo de WordPress ¿cuántas ejecuciones hay de ese código que no cambia? Pues ahí tenemos otra capa de caché, y en el caso de PHP se puede hacer con el sistema de Opcode caché. La idea es que una vez se ejecuta el código una vez, todas las siguientes ejecuciones de PHP que se hagan igual y que van a ejecutar lo mismo estén mínimamente calculadas, de forma que la ejecución sea más rápida.
Las siguiente capas de caché afectan principalmente a los objetos. La definición de caché de objeto es poco clara pero uno de los mayores ejemplos puede ser el de cachear las consultas realizadas a la base de datos. AL fin y al cabo, cuando haces una consulta SQL, a menos que un contenido haya variado, la información suele ser siempre la misma. Es por esto que los resultados de esas consultas se pueden almacenar más o menos tiempo (suele ser poco). De esta forma puedes optimizar, por ejemplo, los recursos de la base de datos para que no se sature en momentos de picos de tráfico. En este bloque también podemos incluir la caché de los Transient. Este sistema básicamente permite cambiar el lugar de almacenamiento de la información dejando de estar en la base de datos MySQL a pasar a un lugar de caché que, en principio, será mucho más óptima en cuanto al almacenamiento, acceso de lectura y escritura de la información.
Una capa de caché poco utilizada (ya que no la permiten todos los servidores web) es la caché de fragmentos. La idea es muy interesante y se basa en el estándar ESI (Edge Side Includes). Si eres de los que programa en PHP seguramente utilizas muchísimo el include() como sistema para añadir elementos que siempre están ahí. Un ejemplo muy claro de este tipo de caché es el de las tiendas de comercio electrónico. Si aplicásemos una capa de caché de página en una donde hay un carrito de la compra, tenemos la opción de crear una página distinta para cada uno de los usuarios que han dejado algo en el carrito, aunque el resto de la página sea igual y lo único que cambia es el «número» que aparece en el icono de la cesta. Esto es absurdo desde el punto de vista puro ya que estás almacenando a lo mejor 20KB de algo que en realidad es distinto del otro en 10B. La idea en este caso es tener una copia de la caché de página y que, sólo el fragmento del icono del carrito, tenga una caché según cada usuario distinto.
En WPSysAdmin hay más explicación sobre las distintas capas de caché de WordPress. También tienes disponible la descarga del PDF de la WordCamp Sevilla en la que hablo de las 10 capas de caché.
Sobre este documento
Este documento está regulado por la licencia EUPL v1.2, publicado en WP SysAdmin y creado por Javier Casares. Por favor, si utilizas este contenido en tu sitio web, tu presentación o cualquier material que distribuyas, recuerda hacer una mención a este sitio o a su autor, y teniendo que poner el material que crees bajo licencia EUPL.