Los propietarios de sitios web desean que éstos se ejecuten lo más rápido posible, y el conocido plugin W3 Total Cache (W3TC) es una opción popular para optimizar sus instalaciones de WordPress. Cuando W3TC está configurado correctamente, éste ayudará a tu servidor a servir mayores cargas de tráfico sin perjudicar el tiempo de respuesta de tu sitio web.

W3TC ofrece muchas funciones de forma gratuita, mientras que algunas funcionalidades premium se desbloquean cuando el usuario compra el plan Pro. Sin embargo, el plugin carece de documentación exhaustiva y no siempre es fácil entender qué funciones deben habilitarse y configurarse.

En el resto de este artículo revisaré las cachés principales que se pueden configurar con W3TC para optimizar WordPress. Veremos cómo funcionan y los principales ajustes que se pueden configurar. También indicaré algunas soluciones alternativas que podrías explorar en casos de uso más avanzados. ¡Empecemos!

Caché de Navegador

Si el navegador de un usuario almacena en caché algún contenido, la próxima solicitud del mismo recurso ni siquiera llegará a la red. Se servirá localmente desde la memoria o el disco, por lo que se consigue un gran ahorro de recursos para todos:

Para lograr esto, los servidores web envían algunas cabeceras de vuelta en las respuestas HTTP para indicar a los receptores (navegadores, proxies, etc.) si / cómo / por cuánto tiempo pueden almacenar el contenido en caché. HTTP 1.1 introdujo la cabecera Cache-Control: para gestionar esto. Veamos algunos casos de uso comunes.

P.ej. algunos sitios web tienen recursos versionados cuyos nombres siempre cambian a medida que cambia su contenido (por ejemplo, scripts-7457f3.js, donde «7457f3» es una suma de comprobación o checksum del contenido). Alternativamente, los desarrolladores pueden agregar un query string en las URL para distinguir entre versiones (p.ej. ?ver = 1.2). Esta última opción está muy extendida entre los desarrolladores de plugins y temas de WordPress. En estos casos, el servidor puede indicar al cliente que almacene en caché un recurso durante mucho tiempo – p.ej. un año – devolviendo la cabecera Cache-Control: max-age = 31536000. El valor en max-age especifica la cantidad de segundos que se puede almacenar en caché el contenido antes de que se considere obsoleto.

Antes de HTTP 1.1, la fecha de expiración tenía que darse como una marca de tiempo absoluta en la cabecera Expires:, p.ej. Expires: Wed, 22 Jan 2020 14:18:26 GMT. Aunque puedes usar simplemente la cabecera Cache-Control:, también es seguro incluir Expires: puesto que el primero tendrá prioridad cuando el cliente procese ambas cabeceras.

Por otro lado, los recursos no estáticos no pueden seguir la política anterior. En este caso, deberíamos dar una fecha de expiración mucho más cercana (max-age = 0 es un valor perfectamente válido en muchos casos, pero no lo uses si quieres que Cloudflare almacene en caché tu sitio web). También debes establecer un mecanismo para permitir que la caché valide si su copia local sigue siendo válida sin tener que descargar el archivo nuevamente –  después de todo, tal vez no haya cambiado. Dos opciones (no exclusivas):

• El servidor devuelve la cabecera Last-Modified: con una marca de tiempo, por lo que el cliente puede incluir la cabecera If-Modified-Since: en futuras peticiones. En caso de que el archivo no haya cambiado desde la fecha indicada, el servidor contesta con una respuesta HTTP 304 Not Modified.
• El servidor devuelve la cabecera ETag: con un checksum del contenido del recurso, por lo que el cliente puede incluir la cabecera If-None-Match: en peticiones futuras. En caso de que el checksum del archivo sea el mismo que el proporcionado, el servidor contesta con una respuesta HTTP 304 Not Modified.

Por último, si deseas que proxies intermedios (por ejemplo, tu CDN) cacheen tus archivos, también debes añadir el atributo public en las cabeceras Cache-Control:.

Bien, ahora podemos implementar nuestra política de Caché de Navegador en W3TC. Asegúrate de que está habilitada en la sección «General Settings» de W3TC:

En la sección «Browser Cache» podemos ver algunas configuraciones en la tarjeta General, y podemos ajustarlas para archivos CSS & JS, HTML & XML, y Media & Other Files. En el caso de un blog de empresa/producto como el nuestro, podemos aprovechar el almacenamiento en caché del navegador para mejorar la experiencia general de nuestros visitantes. Como no actualizamos las imágenes reutilizando el mismo nombre de archivo, podemos dejar que se almacenen en caché durante un año. Nuestros recursos estáticos (hojas de estilo y scripts del tema) no están versionados en este momento, por lo que establecemos una duración máxima de solo cuatro horas (de lo contrario, podría ser un año). Por otro lado, rara vez editamos una entrada de blog. Pero si lo hacemos, queremos que nuestros visitantes recuperen la publicación actualizada en un tiempo relativamente corto – una hora en el momento de escribir estas líneas. Y, finalmente, queremos que Cloudflare almacene en caché nuestros recursos, así que no lo impediremos. Ésta es la configuración resultante en W3TC:

• Set Last-Modified header
• Set expires header
  • Expires header lifetime para CSS & JS = 14400 segundos (cuatro horas)
  • Expires header lifetime HTML & XML = 3600 segundos (una hora)
  • Expires header lifetime para Media & Other Files = 31536000 segundos (un año)
• Set cache control header: «cache with max-age (public, max-age)»
• Set entity tag (ETag)
• Enable HTTP (gzip) compression
• Don’t set cookies for static files

Content Delivery Network

Tu CDN coloca tu contenido más cerca de tus visitantes, reduciendo así la latencia de red y el tiempo de carga de la página. Nosotros recomendamos Cloudflare, pero cualquier otra CDN puede hacer un gran trabajo.

Cloudflare es una CDN de tipo pull, es decir, no tienes que subir tus recursos a sus servidores. Cloudflare almacena en caché los recursos de tu sitio web a medida que tus visitantes los solicitan. Por lo tanto, realmente no necesitas configurar nada en W3TC para usar Cloudflare, puedes dejar la configuración predeterminada tal como está.

Dicho esto, es posible que desees habilitar la extensión Cloudflare en W3TC. Puedes proporcionar tus credenciales de Cloudflare y dicha extensión te permitirá personalizar algunas configuraciones de la CDN. Lo bueno de la extensión es que W3TC puede purgar tu CDN cuando actualizas tu contenido. Si bien esto es bastante conveniente, personalmente no lo hacemos porque no cacheamos HTML en Cloudflare y rara vez actualizamos nuestros recursos estáticos. Cuando lo hacemos, simplemente iniciamos sesión en nuestra cuenta de Cloudflare y limpiamos los cachés allí mismo. De esta manera, no tenemos que proporcionar nuestras credenciales de Cloudflare a nuestra instalación de WordPress. Sin embargo, si tú cacheas HTML en Cloudflare, actualizas tu contenido regularmente, y tu sitio web está bien protegido, deberías considerar la posibilidad de habilitar esta extensión.

Tres cosas adicionales a considerar si utilizas Cloudflare:

• Por defecto Cloudflare sobrescribe la fecha de expiración que establece tu servidor de origen en las cabeceras Cache-Control: y Expires:. Para centralizar esta configuración en un único sitio, dirígete a «Caching -> Browser Cache Expiration» en Cloudflare y establece el valor «Respect Existing Headers».

• Por defecto Cloudflare no cachea archivos HTML. Algunas personas sacan conclusiones erróneas sobre el rendimiento de sus sitios detrás de Cloudflare porque no son conscientes de esto. Si estás seguro de querer que Cloudflare almacene en caché tu HTML, sigue los pasos que se indican en este artículo.
• Por defecto Cloudflare no cachea respuestas que contengan una cookie o si la cabecera Cache-Control: contiene el valor private, no-store, no-cache, o max-age=0. Lo cual es muy útil, pues nos proporciona un mecanismo para asegurar de que nuestro contenido no cacheable será ignorado por nuestra CDN.

Por otro lado, si utilizas una CDN de tipo push – es decir, si subes tus recursos a sus servidores – puedes explorar los diferentes ajustes que ofrece W3TC para configurarla. Una revisión detallada de éstos está fuera del ámbito de este artículo, pero puedes consultar la wiki de W3TC al respecto.

Caché de Página

La Caché de Página es probablemente la característica que supondrá un mayor ahorro de recursos en tu servidor. Dirígete a la sección «Configuración general» de W3TC y habilita esta caché con el método «Disk: Enhanced».

Este método funciona de la siguiente manera. Cada vez que WordPress devuelve una página HTML tras una petición, W3TC guarda la respuesta en un archivo y añade una regla de redirección en el servidor web. Dicha redirección hace que el servidor web devuelva el contenido del archivo almacenado en caché la próxima vez que se solicite la misma página.

Por favor, lee de nuevo el párrafo anterior, puesto que en la web se leen algunos malentendidos al respecto. Algunas personas piensan que deben usar otras tecnologías de caché (más complejas) porque los plugin de caché de WordPress ofrecen un bajo rendimiento. Lo dicen porque piensan (erróneamente) que cada solicitud de página implica levantar un proceso PHP y ejecutar el código del plugin para que devuelva el documento almacenado en caché. Como acabamos de ver, simplemente eso no es cierto: el propio servidor web devuelve el documento almacenado en caché si está utilizando la Caché de Página de W3TC en modo «Disk: Enhanced». Y, en la mayoría de los casos, esto funciona realmente rápido.

El stack de servidores web predeterminado para WordPress en Moss es Nginx como proxy inverso delante de Apache. Esto significa que W3TC agrega sus reglas de redirección dentro del archivo .htaccess raíz de tu sitio, de forma que Apache devuelva el archivo almacenado en caché tan pronto como se solicite.

Pero Moss también te permite elegir Nginx como servidor independiente para tus sitios de WordPress. En general no puedes hacer funcionar la Caché de Página «Disk: Enhanced» de W3TC con Nginx en un entorno compartido, pero este no es el caso con Moss y tu servidor VPS o Cloud 😎. W3TC detecta que se está ejecutando detrás de Nginx y crea un archivo nginx.conf con las redirecciones adecuadas. Para aplicarlas, sigue estos pasos [sólo válido para usuarios de Moss]:

1. Entra en tu servidor vía SSH como usuario moss
2. Ejecuta sudo su
3. Ejecuta cat /home/<user-name>/sites/<site-name>/public/nginx.conf > /etc/openresty/server_params.<site-name> (utiliza tus valores reales para user-name y site-name)
4. Ejecuta rm /home/<user-name>/sites/<site-name>/public/nginx.conf (utiliza tus valores reales para user-name y site-name)
5. Configura tu sitio desde Moss

Ahora que sabemos cómo habilitar esta caché y cómo funciona, vayamos a los ajustes de la sección «Page Cache» en W3TC y personalizamos su comportamiento. Puedes encontrar las configuraciones más relevantes en la tarjeta General, así que tómate unos minutos para pensar en ellas:

• Normalmente quieres cachear tu página principal (frontal) porque suele ser la más visitada.
• También querrás cachear las peticiones HTTPS por norma general. De hecho, siempre deberías servir tu sitio web sobre HTTPS [por cierto, Moss redirecciona automáticamente de HTTP a HTTPS].
• Si llevas un blog de empresa como el nuestro, no querrás cachear páginas para usuarios logueados. Sin embargo, hay otros casos de uso en los que esto es importante para mejorar la experiencia de usuario en tu sitio web. Puedes ver algunas consideraciones al respecto de cómo cachear contenido para usuarios logueados en la sección de abajo.

Ahora que los conceptos básicos están claros, puedes seguir personalizando la Caché de Página en W3TC. Hay muchos ajustes diferentes – demasiados para discutirlos todos aquí. Sin embargo, resaltamos la lista de configuraciones a mirar más detenidamente:

• Purge Policy. Indica las páginas y los feeds que se deben purgar cuando se crean y editan artículos o se publican comentarios. Esta configuración depende mucho de la naturaleza del sitio web, pero también es muy fácil de determinar para los dueños del mismo (p.ej. nosotros no borramos la página principal porque no muestra ninguna publicación del blog, pero sí eliminamos la página de artículos y el feed del blog).
• Contenido no-cacheable. Si hay contenido que no debe almacenarse en memoria caché, debes decírselo a W3TC – puedes excluir ficheros por nombre de archivo, categoría, etiqueta, autor y campo personalizado. Si no tienes contenido de este tipo, no te preocupes por esta configuración.
• En algunos casos de uso avanzados, puedes considerar precargar la caché de forma proactiva. Lo más probable es que no sea necesario, pero podría ayudar en tu caso de uso.

Si no sabes realmente qué significan estas configuraciones, puedes dejarlas con sus valores por defecto.

Caché de Objetos

WordPress proporciona un API de Caché de Objetos para permitir a los desarrolladores almacenar los resultados de operaciones complejas (es decir, que requieren mucho tiempo) – generalmente consultas de base de datos. Al habilitar la Caché de Objetos en W3TC, te aseguras de que dichos resultados se conservarán para reutilizarlos en futuras solicitudes.

Si puedes beneficiarte o no de este tipo de caché depende de la naturaleza de tu sitio web y del software (plugins y temas) que ejecuta. En general, sitios muy dinámicos como comunidades online pueden obtener mayores ahorros al habilitar esta caché. Los sitios mayormente estáticos, como páginas de empresa o blogs personales, no experimentarán una aceleración significativa con la Caché de Objetos. En cualquier caso, tu escenario podría ser diferente: puedes experimentar con tu sitio para verificar si esta caché vale la pena en tu caso.

Para habilitar la Caché de Objetos, dirígete a la «Configuración general» de W3TC. Debes elegir un backend de almacenamiento para la caché. Siempre que sea posible, elige Memcached o Redis como el método de caché de objetos, ya que así los objetos se almacenarán en memoria – acceso más rápido que si usas el backend de disco Disk [puedes instalar Memcached o Redis con Moss con un solo clic].

Ahora dirígete a la sección «Object Cache» para afinar la configuración.

• Si tu backend es Memcached o Redis, proporciona el hostname:puerto que WordPress utilizará para conectar con el servicio.
• Yo nunca he tenido que habilitar el cacheo para peticiones a wp-admin, pero tu caso podría ser distinto.
• Normalmente no almaceno los transients en la base de datos, puesto que purgarlos de la caché nunca ha supuesto un problema de rendimiento en los sitios web que he visto.
• Probablemente los valores por defecto del resto de configuraciones están bien para tu sitio web, pero revísalos para estar seguro.

Otros temas

• Verás que también hay una Database Cache en W3TC. Déjala deshabilitada: si necesitas algo así, usa la Caché de Objetos en su lugar.
• Además del almacenamiento en caché, W3TC proporciona características como la minificación – es decir, puede reducir el tamaño de tus recursos para minimizar el tiempo de descarga. Te animamos a que minimices tus recursos, y W3TC es una opción que puedes usar para conseguirlo. Pero si estás utilizando Cloudflare, no minifiques en Cloudflare y W3TC a la vez – elige uno de ellos y deshabilita la minificación en el otro.
• En algunos sitios web, p.ej. membership sites, la mayoría de los usuarios inician sesión y acceden a contenido específico para ellos. En muchos casos, la Caché del Navegador y la Caché de Objetos son suficientes para ofrecer un buen rendimiento. Pero si realmente necesitas cachear páginas por usuario, podrías considerar usar otro plugin como WP Rocket.
• Si necesitas sacar el máximo rendimiento a tu tienda online, podrías considerar configuraciones más avanzadas. Por lo general, un comercio electrónico presenta en una misma página contenido cacheable (p.ej. descripciones de productos) y no-cacheable (p.ej. el contenido de la cesta de la compra). Puedes editar tus plantillas para agregar marcas que indiquen a W3TC que no almacene en caché una sección determinada de la página. A continuación, puedes activar la Fragment Cache de W3TC y configurarla – ten en cuenta que esta funcionalidad no está incluida en la versión gratuita de W3TC, necesitas actualizar al plan Pro. Si tu comercio electrónico genera ingresos importantes, otra alternativa es considerar Varnish como solución de caché predeterminada. Varnish soporta Edge Side Includes (ESI) que proporcionan la funcionalidad de cacheo parcial que acabamos de describir.
• El uso de cachés es una optimización obligada para tu web, pero no la única que puedes aplicar para mejorar el rendimiento de tu sitio WordPress. Si usas menos plugins y de mayor calidad comprobarás que el tiempo de respuesta puede disminuir. También puedes mejorar la infraestructura subyacente de tu sitio web (escalado vertical, es decir, mejores servidores, discos y red) o distribuir la carga entre varios servidores (escalado horizontal, la configuración es bastante más compleja en este caso) para lograr niveles más altos de rendimiento y escalabilidad.

Conclusión

Brindar a tus usuarios la mejor experiencia posible debe ser tu principal preocupación. Pero es difícil lograrlo si tu sitio web tarda una eternidad en cargar. Para evitarlo, una buena política de caché es una de las primeras cosas que debes considerar para mejorar el tiempo de respuesta de tu sitio web. Además, servir documentos cacheados es «más barato» en términos de recursos del servidor, por lo que puedes dar servicio más usuarios / visitantes con el mismo hardware.

Existen muchas alternativas de almacenamiento en caché, pero si operas sitios WordPress, un buen plugin de caché es la mejor manera de proceder en muchos casos. Si eliges usar W3 Total Cache – una opción gratuita muy popular – no olvides habilitar y configurar correctamente la Caché del Navegador y la Caché de Página en el modo «Disk: Enhanced». Usa también una CDN siempre que sea posible, ya que minimizará aún más la carga en sus servidores. En caso de que utilices Cloudflare, revisa los diversos comentarios que he hecho al respecto en este artículo. Finalmente, recuerda que no hay una única solución para todo el mundo: dependiendo de los requisitos de tu web, es posible que necesites un plugin diferente o una solución de caché completamente alternativa.

Si te ha gustado el artículo, compártelo y subscríbete a nuestro blog para que te enviemos un correo electrónico cuando publicamos nuevo contenido. Y si aún no ha probado Moss, ¡regístrate ahora y comprueba cómo puede ayudarte a administrar tus servidores y sitios web!