Almacenamiento en caché de WordPress: todo lo que necesitas saber

Aquí está Ashley Rich de Delicious Brains escribiendo sobre todas las capas de almacenamiento en caché que son relevantes para un sitio de WordPress. Creo que todos sabemos que el almacenamiento en caché es complicado, pero cielos, es un viaje para comprender todos los cachés que funcionan aquí. El objetivo del caché es la velocidad y la reducción de la carga en los peores cuellos de botella y las partes más lentas/ocupadas de una pila web.

Aquí está mi propio entendimiento:

• El navegador puede almacenar en caché los archivos. Este es el caché más rápido posible ya que no se produce ninguna solicitud de red. Los activos como imágenes, CSS y JavaScript a menudo se almacenan en caché de esta manera porque no cambian con mucha frecuencia, pero debe asegurarse de decirle a los navegadores que está bien hacer esto y tener un mecanismo para romper ese caché si es necesario (por ejemplo, cambiando los nombres de los archivos). Rara vez se almacena en caché el HTML de esta manera, ya que es lo que más cambia y la eliminación del caché de nombres de archivos de HTML parece más complicada de lo que vale.
• Los archivos se pueden almacenar en caché a nivel de CDN. Esto es fantástico porque, aunque hay tráfico de red, los servidores CDN son muy rápidos y probablemente estén geográficamente más cerca de los usuarios que su servidor de origen. Si los usuarios obtienen archivos desde aquí, ni siquiera molestarán a su servidor de origen. También necesitará una forma de romper este caché, lo que probablemente sea cambiando los nombres de los archivos. Puede almacenar HTML en caché en este nivel incluso sin cambiar los nombres de los archivos si tiene un mecanismo para borrar ese caché globalmente cuando cambia el contenido.
• El servidor de origen puede almacenar en caché las páginas HTML creadas. En un sitio de WordPress, las páginas están construidas con PHP, lo que probablemente genera consultas MySQL. Si el servidor puede guardar el resultado de las cosas que ya se han ejecutado, eso significa que puede servir un archivo “estático” como respuesta, lo que puede hacer mucho más rápido que tener que ejecutar PHP y MySQL. Eso funcionará para los usuarios que han iniciado sesión, quienes obtienen la misma respuesta, pero no para los usuarios que han iniciado sesión y que tienen contenido dinámico en la página (como la barra de administración de WordPress).
• La base de datos tiene su propio almacenamiento en caché especial . Después de ejecutar una consulta MySQL, los resultados se pueden guardar en una caché de objetos , lo que significa que la misma solicitud puede provenir de esa caché en lugar de tener que ejecutar la consulta nuevamente. Lo obtienes automáticamente hasta cierto punto, pero lo ideal es que se conecte a una tienda más persistente, que no se obtiene automáticamente.

Uf. Se vuelve un poco más fácil con Jamstack ya que sus páginas ya están prediseñadas y alojadas en CDN, y en el caso de Netlify, ni siquiera tiene que preocuparse por la detección de caché.

Pero a pesar de lo complejo que es esto, no me preocupo mucho. Este sitio de WordPress utiliza Flywheel para el alojamiento, que se ocupa de la base de datos y el almacenamiento en caché a nivel de servidor, tengo Cloudflare frente a él con una optimización especial de WordPress para el almacenamiento en caché de CDN y la eliminación de caché de mi propio nombre de archivo (deseo que esta parte fue más fácil). Ciertamente también confiaría en SpinupWP para hacerlo bien, dado el excelente artículo de Ashley al que estoy enlazando aquí.