Mejorando el rendimiento con cabeceras HTTP

El uso inteligente del cacheado y las cabeceras HTTP te permite optimizar el rendimiento de tu sitio web, a la vez que fortaleces su seguridad contra posibles amenazas. En este artículo, nos centraremos en describir cómo podemos mejorar el rendimiento usando cabeceras HTTP.

Acelerando el Acceso a Recursos

Lo primero, es determinar el protocolo que tienes en tus servidores, ya que no es lo mismo tener HTTP/1 que HTTP/2 o superior. En HTTP/1 todo el tema de cacheado es algo a lo que tenemos que prestar especial atención, puesto que no permite hacer peticiones en paralelo sobre una misma conexión TCP como en la versión 2 o superiores.

Cuando hablamos de cabeceras de cacheado, podemos dividirlas en dos categorías

Cabeceras que evitan la petición

En esta categoría tenemos la pareja `cache-control` y `expires`.

Supongamos que tenemos una serie de estáticos que queremos evitar que se soliciten una y otra vez, como por ejemplo, el código JavaScript o las imágenes estáticas de nuestra aplicación.

Para este tipo de archivos, podemos configurar un servidor de estáticos con (por ejemplo) las cabeceras:

Cache-Control: max-age=360000, public

Expires: Sat, 09 Apr 2024 13:00:00 GMT

• ‘Cache-control’ en este caso, está indicando que, como máximo, se pueden almacenar 100 horas en la caché del navegador y `public` indica que puede ser almacenado por proxies compartidos

• `Expires` indica la fecha y hora en la que el recurso expirará y, por lo tanto, a partir de esa fecha, se volverá a solicitar el recurso

Acabamos de evitar que el navegador esté solicitando estáticos al servidor, pero… ¿y si necesito hacer un hotfix?

Es costumbre acompañar esas peticiones a estáticos con un parámetro en la query del tipo http://mipagina.com?_=version

De esta forma cuando desplegamos una nueva versión, el recurso cambia e invalida cualquier caché preexistente

De la misma forma si quieres invalidar totalmente estas cabeceras puedes hacer que el servidor devuelva en lugar de la versión desplegada, un timestamp con la hora del servidor.

Cabeceras que evitan la comunicación con el servidor

Las cabeceras que se suelen utilizar para evitar que el servidor devuelva recursos pesados (ya sea en transferencias o procesamientos), son `last-modified` y `etag`.

• `Last-modified`, es más sencilla de implementar, ya que se puede utilizar la última fecha de modificación del archivo o la última hora de ejecución de la operación pesada de forma que, cuando la petición llega al servidor, indica al navegador que utilice la versión cacheada sin necesidad de llevar a cabo ejecuciones costosas en el servidor.

• `Etag` funciona de una forma parecida, pero en lugar de con una fecha, con un código que devuelve el servidor, este código puede consistir en un hash del archivo o un identificador de alguna operación pesada.

Veamos un ejemplo:

Aquí tenemos un servidor Node. Cuando se realiza una solicitud, el servidor incluye una cabecera de control de caché que indica al navegador que almacene en caché el archivo durante un año. Este ejemplo ilustra cómo servir archivos estáticos y configurar cabeceras HTTP para controlar el caché de los recursos.

Si levantamos ese servidor y consumimos cualquier archivo html que tengamos dentro, podremos apreciar que la primera petición no será cacheada, mientras que a partir de la segunda vez que lo llamamos, la respuesta indica que el recurso devuelto, es el cacheado.

¿Cuándo usar cada cabecera?

Puedes utilizar `Cache-control` cuando quieras cachear estáticos y puedas definir claramente por cuanto tiempo deben permanecer en cache, por ejemplo, el logotipo de la empresa, puedes cachearlo durante todo un año reduciendo solicitudes al servidor de esta forma.

`Expires`, sin embargo, es más apropiado cuando alguno de tus archivos tiene claramente una fecha de “caducidad”. Por ejemplo, si tu web tiene una imagen de banner promocional que cambia cada tres meses, puedes utilizar una cabecera que obligue al navegador a solicitar uno nuevo únicamente cuando tenga sentido. Al igual que cache-control, evita peticiones al servidor.

Por otro lado, `Last-modified` lo emplearemos con archivos que cambian periódicamente, como podría ser un listado pesado datos que se actualiza todas las semanas en tu web, en este caso, la petición se realiza de todas formas, pero se ahorra ancho de banda y recursos del servidor mientras que estamos asegurando que los usuarios siempre disponen de la versión actualizada del archivo de datos.

Por último, utilizaríamos `ETag` si algún proceso está modificando alguno de tus archivos (cambiando la fecha de modificación), pero no su contenido. Imagina que tienes un sitio web bastante extenso en el que tu proceso de construcción sólo cambia algunos archivos cada vez que los subes al servidor. En este caso, cada vez que despliegas una versión, todas las fechas de modificación se ven afectadas, pero no su contenido, por lo que puedes calcular un hash en base al contenido de tus archivos, almacenarlo junto con los archivos y comprobarlo antes de descargar la nueva versión. Proporciona precisión en la identificación de cambios, asegurando que el navegador sólo descarga nuevas versiones del archivo cuando realmente han cambiado reduciendo el uso de ancho de banda al evitar descargas innecesarias.

En conclusión, implementar estrategias que nos permitan ahorrar peticiones de red o minimizar la información transmitida en estas comunicaciones, a menudo, no requiere complicadas implementaciones y se enfoca en reflexionar brevemente sobre la naturaleza del dato que pretendemos consumir. Las estrategias de este artículo son estándar y gestionadas por el navegador web, pero esta sencillez no está reñida con su eficacia y nos dotan de herramientas simples para optimizar el rendimiento de nuestras aplicaciones web y mejorar la experiencia del usuario.