Dominando el Control de Caché: Optimizando el Rendimiento para Aplicaciones React

Hola a todos. Hoy vamos a hablar sobre cómo utilizar el almacenamiento en caché para optimizar el rendimiento de nuestra aplicación web. Soy Yael Bala. Somos una startup de salud digital y FinTech. Es un placer estar aquí en React Day Berlin.

Comencemos. Cuando hablamos de almacenamiento en caché en el contexto de aplicaciones web de React, generalmente discutimos la gestión del estado y cómo evitar solicitudes de red redundantes. Sin embargo, aquí vamos a hablar sobre lo que podemos hacer para almacenar en caché datos y recursos fuera de nuestra aplicación de React, cómo se comporta este almacenamiento en caché y cómo podemos controlarlo y evitar problemas de almacenamiento en caché.

Pero primero, comencemos con por qué necesitamos almacenamiento en caché. Incluso hoy en día con Wi-Fi rápido, división de código, SSR, todavía toma tiempo para que una aplicación web cargue. Y una de las formas de mejorarlo es usando caché. También podemos usar caché, por cierto, para servir contenido sin conexión o cuando el servidor no está disponible, y también podemos reducir la carga en el servidor de origen, lo que en última instancia puede mejorar el rendimiento de todos los usuarios.

Entonces, ¿qué deberíamos almacenar en caché? Entonces, los recursos estáticos son candidatos naturales para el almacenamiento en caché, imágenes, archivos multimedia, scripts y CSS. Pero también es importante notar que también podemos almacenar datos de la aplicación, como la lista de los últimos artículos o publicaciones, o configuraciones predeterminadas que pueden ayudarnos a cargar más rápido. No queremos almacenar datos que no serán correctos cuando estén desactualizados, por ejemplo, mostrar un saldo de usuario. Si mostramos un valor desactualizado, el usuario no estará contento.

También debemos ser cuidadosos con el almacenamiento en caché de contenido seguro, porque no queremos que se muestre a menos que el usuario esté autenticado. ¿Dónde podemos almacenar en caché? ¿Cuáles son nuestras opciones de almacenamiento en caché? Para eso, veamos el recorrido de la solicitud. Cuando emitimos una solicitud desde una aplicación web, esperaría que fuera al servidor y obtuviera el valor de vuelta, ¿verdad? En realidad, tenemos varias paradas en el camino que pueden ayudarnos a almacenar en caché los datos. La primera parada es el service worker. Puede interceptar todo tipo de solicitudes de red y puede cargar la respuesta desde su caché. El service worker, si no puede manejar la solicitud, el navegador puede entonces servir el contenido desde su propia caché. Y si no, la solicitud continuará a la siguiente parada, el CDN. Se recomienda tener un CDN en su lugar, y si el recurso está almacenado en caché allí, es genial. Y si no, irá todo el camino hasta el servidor. Y el servidor, al devolver el contenido, también proporciona información adicional sobre el almacenamiento en caché. Lo hace usando diferentes encabezados que discutiremos más adelante.

Veamos nuestra primera parada, el service worker. El service worker es solo un script, un JavaScript. Se ejecuta en segundo plano fuera de tu aplicación, y puede hacer muchas cosas, incluyendo interceptar solicitudes de red y decidir si devolver el contenido desde la caché o no. Aquí hay un ejemplo de un script que escucha una solicitud de fetch y devuelve datos desde la caché. Hay estrategias muy comunes que puedes usar dentro de un service worker. No necesitas reimplementarlas. Puedes importarlas desde una biblioteca y paquete de NPM y usarlas. Ofrecen una variedad de opciones. Por ejemplo, network first es la básica. Esta estrategia intenta obtener datos de la red. Y si el servidor no devuelve el contenido, tomará el último valor de la caché. Otra útil es tail while revalidate. Esta estrategia sirve el contenido sin conexión desde la caché inmediatamente, pero también emite una nueva solicitud, y cuando los resultados regresan, actualiza su contenido para el usuario. Si el service worker no puede devolver los datos, la siguiente parada es la caché del navegador. La caché HTTP del navegador es un mecanismo incorporado en el navegador.

Almacena recursos que tienen encabezados o reglas de almacenamiento en caché establecidas por el servidor. Y si miras en la pestaña de red en las herramientas de desarrollo, puedes ver qué recursos se cargan desde la red y cuáles se cargan desde el disco. Por ejemplo, aquí puedes ver una biblioteca. Y también puedes ver el tiempo, solo tomó tres milisegundos.

La caché del navegador y la caché del service worker tienen como objetivo reducir las llamadas de red, pero sus propósitos divergen. La caché del navegador se limita al almacenamiento en caché HTTP, adhiriéndose a las reglas definidas por el servidor. Mientras que el service worker permite a los desarrolladores crear una lógica de almacenamiento en caché personalizada. Permite escenarios más complejos como estrategias offline first o cualquier tipo de almacenamiento en caché dinámico.

Confiar en el almacenamiento en caché HTTP del servidor significa que estás usando el servidor para decirnos cómo almacenar en caché un recurso y por cuánto tiempo. Los desarrolladores pueden influir en este comportamiento configurando el encabezado apropiado en el lado del back-end. Hay dos encabezados principales que se utilizan, cache control y eTag. El encabezado cache control especifica si y por cuánto tiempo un recurso puede ser almacenado en caché. Puede incluir valores como max age, que indica el número de segundos que la caché puede almacenar el archivo antes de que expire. Pero también podemos establecer valores como no store o must revalidate para definir reglas de almacenamiento en caché más estrictas.

Por ejemplo, si tienes una biblioteca cargada desde el disco y el encabezado cache control devuelto por el servidor back-end tiene el valor máximo posible de almacenamiento en caché de un año. La URL en sí contiene una versión que significa que el contenido del archivo nunca cambiará. Esto también se llama cache busting. Cuando cambias el contenido del archivo, cambias la URL. Este enfoque permite un almacenamiento en caché seguro en cada parada y es una práctica recomendada para bibliotecas y escuelas.

El encabezado eTag ayuda a controlar la validación de la caché. El servidor devuelve un ID que representa la versión del contenido y el HTTP, la próxima vez que la caché del navegador quiera usar este valor, preguntará al servidor si el contenido ha cambiado enviando el valor eTag. Y si el servidor responde con un estado 304, significa que el navegador puede usar el valor de la caché. Esta es una gran opción para archivos grandes que son difíciles de consultar o enviar a través de la red. Aquí hay un ejemplo donde el servidor respondió con un estado 304 confirmando que los datos de la caché aún son válidos.

Si la caché del navegador no puede devolver el valor, la solicitud va al CDN. El CDN, es una red de entrega de contenido, consiste en servidores proxy, servidores ubicados globalmente. El objetivo del CDN es entregar contenido de manera eficiente. Estos servidores mantienen recursos en caché, permitiendo a los usuarios recibir contenido del servidor más cercano y reduciendo los retrasos de red. Los servidores proxy del CDN también utilizan el almacenamiento en caché HTTP y respetan estos encabezados de cache control y eTag. Puedes establecer diferentes valores para el CDN.

Por ejemplo, puedes usar S max age para la duración específica de almacenamiento en caché del CDN. También puedes especificar si es contenido privado que solo puede ser almacenado en caché localmente. El CDN proporciona otra herramienta importante en la validación. Puedes usar esto para emitir solicitudes para borrar contenido en caché de los proxies del CDN, que se propagan a través de la red. A diferencia de la caché del navegador, cuando el borrado requiere acción del usuario, la validación del CDN se puede hacer desde una ubicación central.

Bueno, casi terminamos nuestros 10 minutos. Veamos qué podemos almacenar en cada punto de caché. En el service worker, podemos almacenar respuestas de API prefetch para uso offline. Por ejemplo, una lista de tareas en una aplicación de tareas. Por ejemplo, podemos usar propiedades de usuario predeterminadas. Solo asegúrate de que los datos sensibles estén cifrados o protegidos para mitigar el riesgo de seguridad. En la caché del navegador, puedes usarla para almacenar imágenes, fuentes, scripts y otro contenido estático. Asegúrate de que el nombre del archivo cambie cuando el contenido cambie para evitar problemas de caché obsoleta. En el CDN, puedes almacenar recursos estáticos por una duración mucho más larga y también compartir datos como categorías principales, productos principales, artículos, contenido, etc.

Para resumir, la caché ayuda a mejorar el rendimiento y habilitar la funcionalidad offline. Existen diferentes mecanismos de caché a lo largo del viaje de la solicitud, y tenemos herramientas para controlar el comportamiento de la caché. La clave, echa un vistazo a la pestaña de red, ve qué solicitudes tienes y qué toma mucho tiempo, y verifica qué caché puedes usar para mejorar el rendimiento. Gracias. Espero que encuentres esta sesión interesante. Si tienes preguntas o comentarios, no dudes en contactarme en LinkedIn o a través del chat de la conferencia. Que tengas un gran día.