Administra el comportamiento de la caché

Firebase Hosting usa una potente CDN global para que el sitio sea lo más rápido posible.

Todo el contenido estático que se solicita se almacena en caché automáticamente en la CDN. Si vuelves a implementar el contenido de tu sitio, Firebase Hosting borra de forma automática todo el contenido estático almacenado en caché en la CDN hasta la siguiente solicitud.

Sin embargo, debido a que los servicios de Cloud Run y Cloud Functions generan contenido de manera dinámica, el contenido de una URL determinada puede cambiar en función de variables como las entradas o la identidad del usuario. Para dar cuenta de esto, las solicitudes que controla el código de backend no se almacenan en caché en la CDN de forma predeterminada, a excepción de las solicitudes que muestran errores 404. Para borrar los resultados 404 almacenados en caché, vuelve a implementar Firebase Hosting. Volver a implementar Cloud Functions y Cloud Run no invalida automáticamente la caché.

Sin embargo, puedes configurar el comportamiento del almacenamiento en caché del contenido dinámico. Por ejemplo, si una función genera contenido nuevo solo de manera periódica, puedes almacenar en caché el contenido generado durante un período breve, como mínimo, para acelerar la app.

Además, se pueden disminuir potencialmente los costos de ejecución de las funciones, ya que el contenido se entrega desde la CDN y no desde una función activada. Consulta la documentación de Cloud Functions y Cloud Run, y obtén más información para optimizar los servicios y la ejecución de funciones.

Consulta la documentación para desarrolladores web de Google y obtén más información sobre el comportamiento del almacenamiento en caché.

Configura Cache-Control

El encabezado Cache-Control es la herramienta principal que usas para administrar el almacenamiento en caché del contenido dinámico. Tras configurar este encabezado, podrás comunicar al navegador y a la CDN el tiempo máximo en que se puede almacenar tu contenido en caché. En la función, configura Cache-Control de la siguiente manera:

res.set('Cache-Control', 'public, max-age=300, s-maxage=600');

En este encabezado de ejemplo, las directivas realizan las siguientes tres acciones:

• public marca la caché como public. Esto significa que el navegador y los servidores intermedios (la CDN de Firebase Hosting) pueden almacenar el contenido en caché.

• max-age indica al navegador y a la CDN cuántos segundos puede almacenar el contenido en caché. Una vez transcurrido ese tiempo, el navegador y la CDN deben volver a validar el contenido con el servidor de origen. En el encabezado de ejemplo, se permite que el navegador y la CDN almacenen el contenido en caché durante cinco minutos (consulta s-maxage más abajo a fin de conocer los controles específicos para el almacenamiento en caché de la CDN).

• s-maxage anula la directiva max-age solo para el almacenamiento en caché de la CDN y, también indica a la CDN la cantidad de segundos en la que se puede almacenar el contenido en caché. Una vez transcurrido ese tiempo, la CDN debe volver a validar el contenido con el servidor de origen. En el encabezado de ejemplo, se anula la configuración de max-age solo para la CDN y se permite que esta almacene el contenido en caché durante diez minutos.

Configura los valores de max-age y s-maxage según el período más prolongado que te parezca adecuado para que los usuarios reciban contenido obsoleto. Usa un valor de tiempo reducido si se trata de una página que cambia cada pocos segundos. Sin embargo, otros tipos de contenido se pueden almacenar en caché de forma segura durante horas, días o incluso meses.

Consulta la Red de desarrolladores de Mozilla y la documentación para desarrolladores web de Google a fin de obtener más información sobre el encabezado Cache-Control.

¿Cuándo se entrega el contenido almacenado en caché?

El navegador y la CDN almacenan el contenido en la caché según estos parámetros:

• Nombre de host
• Ruta de acceso
• Cadena de consulta
• El contenido de los encabezados de la solicitud que se especificaron en el encabezado Vary

Encabezados Vary

Con el encabezado Vary, se determinan los encabezados de la solicitud que se deben usar para brindar una respuesta adecuada (ya sea que el contenido en la caché sea válido o si se debe volver a validar con el servidor de origen).

Firebase Hosting configura automáticamente un encabezado Vary adecuado en tu respuesta para situaciones comunes. En la mayoría de los casos, no debes preocuparte por el encabezado Vary. En algunos casos de uso avanzados, es posible que necesites otros encabezados para la caché. En esas situaciones, puedes configurar el encabezado Vary en la respuesta. Por ejemplo:

res.set('Vary', 'Accept-Encoding, X-My-Custom-Header');

En este caso, el valor del encabezado Vary es el siguiente:

vary: X-My-Custom-Header, x-fh-requested-host, accept-encoding, cookie, authorization

Con esta configuración, si hay dos solicitudes idénticas, pero con distintos encabezados X-My-Custom-Header, se almacenan en caché por separado. Ten en cuenta que Hosting agrega Cookie y Authorization al encabezado Vary de forma predeterminada cuando se realiza una solicitud de contenido dinámico. Esto garantiza que cualquier encabezado de sesión o de autorización de cookies que uses forme parte de la clave de caché, lo que evita filtraciones de contenido accidentales.

También ten en cuenta lo siguiente:

• Solo las solicitudes GET y HEAD se pueden almacenar en caché. Las solicitudes HTTPS que usan otros métodos nunca se almacenan en caché.

• Ten cuidado cuando agregues la configuración al encabezado Vary. Mientras más agregues, menos probable será que la CDN pueda entregar contenido almacenado en caché. Recuerda también que Vary se basa en encabezados de solicitud y no de respuesta.

Uso de cookies

Por lo general, cuando usas Firebase Hosting en conjunto con Cloud Functions o Cloud Run, se separan las cookies de las solicitudes entrantes. Esto es necesario para permitir un comportamiento eficiente de la caché de CDN. Solo se permite que la cookie con nombre especial __session pase a la ejecución de la app.

Cuando está presente, la cookie __session forma parte de la clave de caché automáticamente, lo que significa que es imposible que dos usuarios con cookies diferentes reciban la respuesta almacenada en caché de cada uno. Solo debes usar la cookie __session si tu app entrega contenido diferente según la autorización del usuario.