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 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. Según la configuración predeterminada, las solicitudes que controla el código de backend no se almacenan en caché en la CDN para justificar esta variación.
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.
De manera similar, puedes configurar el comportamiento del almacenamiento en caché para reducir potencialmente los costos de ejecución de la función, 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.
La excepción son las solicitudes que muestran errores 404. La CDN almacena en caché la respuesta 404 del servicio en una URL inexistente durante 10 minutos, de modo que las solicitudes posteriores para esa URL se entreguen desde la CDN. Si cambias el servicio para que el contenido ahora exista en esta URL, la CDN continúa entregando los errores 404 almacenados en caché durante 10 minutos (como máximo) y, luego, entrega contenido desde esa URL normalmente.
Si una respuesta 404 ya contiene encabezados de almacenamiento en caché establecidos por el servicio de Cloud Run o Cloud Functions, estos anulan el valor predeterminado de 10 minutos y determinan por completo el comportamiento de almacenamiento en caché de la CDN.
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é comopublic
. 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 (consultas-maxage
más abajo a fin de conocer los controles específicos para el almacenamiento en caché de la CDN).s-maxage
anula la directivamax-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 demax-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
yHEAD
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 queVary
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.