Los usuarios que carguen tu sitio por segunda vez utilizarán su caché HTTP, así que asegúrate de que y cómo funciona bien.
Esta publicación complementa el video Love your cache, parte de la serie Extended Contenido de la Chrome Dev Summit 2020. Asegúrate de mirar el siguiente video:
Cuando los usuarios carguen tu sitio por segunda vez, el navegador usará los recursos del sitio su caché HTTP para acelerar la carga. Pero los estándares para el almacenamiento en caché la web se remonta a 1999, y se definen de forma bastante amplia, lo que determina si un archivo, como CSS o una imagen, se puede recuperar de la red en comparación con cargar desde la caché es una ciencia inexacta.
En esta entrada, hablaré de una configuración predeterminada y moderna para el almacenamiento en caché No almacena en caché en absoluto. Pero esa es solo la configuración predeterminada, curso con más matices que simplemente "desactivarlo". Sigue leyendo para conocer todos los detalles.
Objetivos
Cuando se carga un sitio por segunda vez, se tienen dos objetivos:
- Asegúrate de que tus usuarios obtengan la versión más actualizada disponible (si cambió algo, debería reflejarse rápidamente
- Realiza el primer paso mientras recuperas lo menos posible de la red
En el sentido más amplio, solo quieres enviar el cambio más pequeño a tus clientes cuando vuelvan a cargar tu sitio. y estructurar el sitio para garantizar para distribuir cualquier cambio de manera eficiente (más información a continuación, y en el video).
Dicho esto, también tiene otros criterios cuando considera el almacenamiento en caché, como has decidido dejar que la caché HTTP del navegador de un usuario conserve tu sitio durante un tiempo para que no se necesiten solicitudes de red para entregarlo. O creó un service worker que entregará el contenido al sitio por completo sin conexión comprobar si está actualizado. Esta es una opción extrema, que es válida, y se usa para muchas experiencias web similares a las de las aplicaciones que priorizan el uso sin conexión, pero no es necesario que la Web en un extremo de solo caché o incluso en un extremo de solo red.
Información general
Como desarrolladores web, todos estamos acostumbrados a la idea de tener una "caché inactiva". Pero sabemos, casi de forma instintiva, las herramientas disponibles para resolver esto: hacer un análisis "Actualizar", o abrir una ventana de incógnito, o bien usar la combinación para borrar los datos de un sitio.
Los usuarios normales que existen en Internet no pueden darse ese mismo lujo. Si bien Tenemos algunos objetivos centrales de garantizar que los usuarios la pasen bien cargar, también es muy importante asegurarse de que no pasen un mal momento o se queden atascados. (Mira el video si quieres escucharme hablar sobre cómo casi quedó atascado el sitio web.dev/live).
Para más información, una razón muy común para la “caché inactiva” en realidad
la configuración predeterminada
de 1999 para el almacenamiento en caché. Se basa en el encabezado Last-Modified:
Cada archivo que cargues se conserva durante un 10% adicional de su ciclo de vida actual, ya que
el navegador la ve. Por ejemplo, si index.html se creó hace un mes,
y su navegador lo almacenará en caché durante otros tres días.
En aquella época, era una idea bien intencionada, pero dado el en la naturaleza integrada de los sitios web actuales. Este comportamiento predeterminado significa que es posible llegar a un estado en el que un usuario tenga archivos diseñados para diferentes versiones de su sitio web (p.ej., el JS del lanzamiento del martes y el CSS del lanzamiento del viernes debido a que esos archivos no se actualizaron exactamente al mismo tiempo.
El camino bien iluminado
Una configuración predeterminada moderna para el almacenamiento en caché es no almacenar CDN para acercar tu contenido a los usuarios. Cada vez que un usuario cargue su sitio, llegará a la red para ver si está actualizado. Esta solicitud tendrá una latencia baja, ya que se proporcionados por una CDN geográficamente cercana a cada usuario final.
Puedes configurar tu host web para que responda a las solicitudes web con este encabezado:
Cache-Control: max-age=0,must-revalidate,public
En pocas palabras, dice: de que el archivo sea válido sin tiempo en absoluto y debes validar desde la red antes de que puedas volver a usarlo (de lo contrario, es solo "sugeridas").
Este proceso de validación es relativamente económico en términos de bytes transferidos, si un no se haya modificado el archivo de imagen grande, el navegador recibirá un mensaje de error pero cuesta latencia, ya que un usuario debe ir a la red para encontrar y sale de ella. Y esta es la principal desventaja de este enfoque. Puede funcionar muy bien para las personas con conexiones rápidas en el primer mundo, y donde la CDN que elijas tiene pero no para quienes usan dispositivos móviles más lentos. conexiones o una infraestructura deficiente.
En cualquier caso, este es un enfoque moderno que es la opción predeterminada en una CDN popular, Netlify, pero se puede configurar en casi cualquier CDN. En el caso de Firebase Hosting, puedes incluir este encabezado en la sección de hosting de tu archivo firebase.json:
"headers": [
// Be sure to put this last, to not override other headers
{
"source": "**",
"headers": [ {
"key": "Cache-Control",
"value": "max-age=0,must-revalidate,public"
}
}
]
Entonces, si bien sugiero que esto es un valor predeterminado razonable, es solo eso, ¡el valor predeterminado! Continúa leyendo para descubrir cómo intervenir y actualizar la configuración predeterminada.
URLs con huellas digitales
Incluyendo un hash del contenido del archivo en el nombre de los activos, las imágenes, etcétera
que se publican en tu sitio, puedes asegurarte de que estos archivos siempre tendrán archivos
contenido; por ejemplo, se mostrarán archivos con el nombre sitecode.af12de.js. Cuándo
las solicitudes de estos archivos, puedes indicarle con seguridad
del usuario final para almacenarlas en caché durante mucho tiempo configurándolas con el
encabezado:
Cache-Control: max-age=31536000,immutable
Este valor es un año, en segundos. Y según las especificaciones, esto es efectivamente igual a "por siempre".
Es importante destacar que no debes generar estos hashes a mano, ya que es demasiado trabajo manual. Tú puedes usar herramientas como Webpack, Rollup, etc., para ayudarte con esto. Asegúrate de que para obtener más información al respecto en el Informe de herramientas.
Recuerda que no solo JavaScript puede beneficiarse de las URLs con huellas digitales, Los recursos como íconos, CSS y otros archivos de datos inmutables también pueden llamarse así. de una nueva manera. (Asegúrate de mirar el video de arriba para aprender un poco más sobre el código con la división, lo que te permite enviar menos código cada vez que cambie tu sitio).
Más allá de la forma en que tu sitio aborde el almacenamiento en caché, este tipo de almacenamiento son increíblemente valiosos para cualquier sitio que crees. La mayoría de los sitios solo no cambiarán en cada lanzamiento.
Por supuesto, no podemos cambiar el nombre de nuestras páginas “amigables” para el usuario de esta manera: cambiar el nombre
tu archivo index.html a index.abcd12.html. Eso es inviable, no puedes saber
que los usuarios vayan a una nueva URL cada vez que carguen el sitio. Estos productos "amigable" URL
el nombre y el almacenamiento en caché de esta forma, lo que me lleva a
en el suelo.
El punto medio
Obviamente, hay un punto medio para el almacenamiento en caché. Hice presentó dos opciones extremas: almacenar en caché nunca ni almacenar en caché nunca. Y habrá un número de archivos que quieras almacenar en caché por un tiempo, como el "amigable" URL que mencioné anteriormente.
Si quieres almacenar en caché estas las URLs y su código HTML, vale la pena teniendo en cuenta qué dependencias incluyen, cómo pueden almacenarse en caché y cómo almacenar en caché sus URLs durante un tiempo podría afectarte. Echemos un vistazo a una página HTML que incluye una imagen como esta:
<img src="/images/foo.jpeg" loading="lazy" />
Si actualizas o cambias tu sitio borrando o cambiando esta función de carga diferida
imagen, los usuarios que vean una versión almacenada en caché de tu código HTML podrían obtener una
falta una imagen, porque aún almacenaron en caché la /images/foo.jpeg original cuando
vuelven a visitar tu sitio.
Si tienes cuidado, es posible que esto no te afecte. Pero, en términos generales, es importante recuerden que su sitio (cuando los usuarios finales lo almacenan en caché) ya no existe solo en tus servidores. En su lugar, pueden existir en fragmentos dentro de las cachés del dominio navegadores.
En general, la mayoría de las guías sobre almacenamiento en caché si deseas almacenar en caché por una hora, varias horas, etcétera. Para configurar esto, sigue estos pasos: almacenar en caché, usar un encabezado como este (que almacena en caché por 3, 600 segundos o uno hora):
Cache-Control: max-age=3600,immutable,public
Un último punto. Si creas contenido oportuno, que normalmente solo a los que acceden los usuarios, como artículos de noticias, mi opinión es que estos nunca deben se almacene en caché, y debes usar nuestro valor predeterminado razonable, anterior. Creo que a menudo el valor del almacenamiento en caché sobre el deseo de un usuario de ver siempre más destacado, como una actualización crítica sobre una noticia o para cada evento.
Opciones no HTML
Además de HTML, hay otras opciones para los archivos que se encuentran en el medio. incluyen:
En general, busca recursos que no afecten a otros
- Por ejemplo, evita usar CSS, ya que cambia la apariencia de tu HTML renderizado
Imágenes grandes que se usan como parte de artículos oportunos
- Es probable que sus usuarios no visiten ningún artículo más que varias veces, así que no guardes fotos o imágenes destacadas por siempre almacenamiento de residuos
Un activo que representa algo que tiene vida útil
- Los datos JSON sobre el clima podrían publicarse solo cada hora, por lo que puedes almacenar en caché el resultado anterior durante una hora; no cambiará en tu ventana
- Las compilaciones de un proyecto de código abierto pueden tener un límite de frecuencia, así que almacena en caché de estado de compilación hasta que sea posible que el estado cambie
Resumen
Cuando los usuarios cargan tu sitio por segunda vez, ya obtuviste un voto de más confianza, quieren volver y obtener más de lo que ofreces. En este no siempre se trata de reducir el tiempo de carga, y hay un un montón de opciones disponibles para que te asegures de que tu navegador solo haga el trabajo. debe brindar una experiencia rápida y actualizada.
El almacenamiento en caché no es un concepto nuevo en la Web, pero quizá Opción predeterminada: considere usar una y optar por mejores estrategias de almacenamiento en caché cuando los necesites. ¡Gracias por leer esta información!
Consulta también
Para obtener una guía general sobre la caché HTTP, consulta Evita las solicitudes de red innecesarias con la caché HTTP.