Catch up on everything announced at Firebase Summit, and learn how Firebase can help you accelerate app development and run your app with confidence. Learn More

Administrar el comportamiento de la caché

Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

Firebase Hosting utiliza una poderosa CDN global para que su sitio sea lo más rápido posible.

Cualquier contenido estático solicitado se almacena automáticamente en caché en la CDN . Si vuelve a implementar el contenido de su sitio, Firebase Hosting borra automáticamente todo el contenido estático almacenado en caché en la CDN hasta la próxima solicitud.

Sin embargo, debido a que los servicios de Cloud Functions y Cloud Run generan contenido de forma dinámica, el contenido de una URL determinada puede variar según la entrada del usuario o la identidad del usuario. Para dar cuenta de esto, las solicitudes que son manejadas por el código de back-end no se almacenan en caché en la CDN de forma predeterminada.

Sin embargo, puede configurar el comportamiento de almacenamiento en caché para el contenido dinámico . Por ejemplo, si una función genera contenido nuevo solo periódicamente, puede acelerar su aplicación almacenando en caché el contenido generado durante al menos un período breve.

También puede reducir potencialmente los costos de ejecución de la función porque el contenido se sirve desde la CDN en lugar de a través de una función desencadenada. Obtenga más información sobre cómo optimizar la ejecución de funciones y los servicios en la documentación de Cloud Functions y Cloud Run .

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

Establecer control de caché

La herramienta principal que usa para administrar la memoria caché para el contenido dinámico es el encabezado Cache-Control . Al configurar este encabezado, puede comunicar tanto al navegador como a la CDN cuánto tiempo se puede almacenar en caché su contenido. En su función, configura Cache-Control así:

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

En este encabezado de ejemplo, las directivas hacen tres cosas:

  • public — Marca la memoria caché como public . Esto significa que tanto el navegador como los servidores intermedios (es decir, la CDN para Firebase Hosting) pueden almacenar en caché el contenido.

  • max-age : le dice al navegador y al CDN cuántos segundos pueden almacenar en caché el contenido. Cuando vence el tiempo establecido, el navegador y el CDN deben revalidar el contenido con el servidor de origen. En el encabezado del ejemplo, permitimos que el navegador y la CDN almacenen en caché el contenido durante cinco minutos (consulte s-maxage a continuación para conocer los controles específicos para el almacenamiento en caché de CDN).

  • s-maxage : anula la directiva max-age para el almacenamiento en caché de CDN; le dice a la CDN cuántos segundos puede almacenar en caché el contenido. Cuando vence el tiempo establecido, la CDN debe revalidar el contenido con el servidor de origen. En el encabezado del ejemplo, anulamos la configuración de max-age para la CDN y permitimos que la CDN almacene en caché el contenido durante diez minutos.

Para max-age y s-maxage , establezca sus valores en la cantidad de tiempo más larga en la que se sienta cómodo con los usuarios que reciben contenido obsoleto. Si una página cambia cada pocos segundos, utilice un valor de tiempo pequeño. Sin embargo, otros tipos de contenido se pueden almacenar en caché de forma segura durante horas, días o incluso meses.

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

¿Cuándo se sirve el contenido en caché?

El navegador y la CDN almacenan en caché su contenido en función de:

  • El nombre de host
  • El camino
  • La cadena de consulta
  • El contenido de los encabezados de solicitud especificados en el encabezado Vary

Variar encabezados

El encabezado Vary determina qué encabezados de solicitud deben usarse para proporcionar una respuesta adecuada (si el contenido almacenado en caché es válido o si el contenido debe revalidarse con el servidor de origen).

Firebase Hosting establece automáticamente un encabezado Vary apropiado en su respuesta para situaciones comunes. La mayoría de las veces, no necesita preocuparse por el encabezado Vary . Sin embargo, en algunos casos de uso avanzado, es posible que tenga otros encabezados que necesite para afectar el caché. Cuando ese sea el caso, puede configurar el encabezado Vary en su respuesta. Por ejemplo:

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

En este caso, el valor del encabezado Vary es:

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

Con esta configuración, dos solicitudes idénticas con diferentes encabezados X-My-Custom-Header se almacenan en caché por separado. Tenga 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 autorización de sesión o cookie que utilice se convierta en parte de la clave de caché, lo que evita fugas accidentales de contenido.

También tenga en cuenta:

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

  • Tenga cuidado al agregar configuraciones al encabezado Vary . Cuantas más configuraciones agregue, es menos probable que la CDN pueda servir contenido almacenado en caché. Recuerde también que Vary se basa en encabezados de solicitud , no en encabezados de respuesta .

Uso de cookies

Cuando se usa Firebase Hosting junto con Cloud Functions o Cloud Run, las cookies generalmente se eliminan de las solicitudes entrantes. Esto es necesario para permitir un comportamiento eficiente de la caché de CDN. Solo se permite que la cookie de __session con un nombre especial pase a la ejecución de su aplicación.

Cuando está presente, la cookie __session se convierte automáticamente en parte de la clave de caché, lo que significa que es imposible que dos usuarios con diferentes cookies reciban la respuesta almacenada en caché del otro. Solo use la cookie __session si su aplicación ofrece contenido diferente según la autorización del usuario.