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é 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.