En general, el almacenamiento en caché puede mejorar el rendimiento almacenando datos para que las solicitudes futuras de los mismos datos se entreguen más rápido. Por ejemplo, un recurso almacenado en caché de la red puede evitar un viaje de ida y vuelta al servidor. Un resultado de procesamiento almacenado en caché puede omitir el tiempo para hacer el mismo cálculo.
En Chrome, el mecanismo de caché se usa de varias maneras, y la caché HTTP es un ejemplo.
Cómo funciona actualmente la caché HTTP de Chrome
A partir de la versión 85, Chrome almacena en caché los recursos recuperados de la red y usa sus respectivas URLs de recursos como clave de caché. (Se usa una clave de caché para identificar un recurso almacenado en caché).
En el siguiente ejemplo, se ilustra cómo se almacena en caché y se trata una sola imagen en tres contextos diferentes:
https://x.example/doge.png }
Un usuario visita una página (https://a.example) que solicita una imagen (https://x.example/doge.png). La imagen se solicita a la red y se almacena en caché con https://x.example/doge.png como clave.
https://x.example/doge.png }
El mismo usuario visita otra página (https://b.example), que solicita la misma imagen (https://x.example/doge.png). El navegador verifica su caché HTTP para ver si ya tiene este recurso almacenado en caché, con la URL de la imagen como clave. El navegador encuentra una coincidencia en su caché, por lo que usa la versión almacenada en caché del recurso.
https://x.example/doge.png }
No importa si la imagen se carga desde un iframe. Si el usuario visita otro sitio web (https://c.example) con un iframe (https://d.example) y el iframe solicita la misma imagen (https://x.example/doge.png), el navegador aún puede cargar la imagen desde su caché porque la clave de caché es la misma en todas las páginas.
Este mecanismo ha funcionado bien desde una perspectiva de rendimiento durante mucho tiempo. Sin embargo, el tiempo que tarda un sitio web en responder a las solicitudes HTTP puede revelar que el navegador accedió al mismo recurso en el pasado, lo que lo expone a ataques de seguridad y privacidad, como los siguientes:
- Detectar si un usuario visitó un sitio específico: Un adversario puede detectar el historial de navegación de un usuario si verifica si la caché tiene un recurso que podría ser específico de un sitio o una cohorte de sitios en particular.
- Ataque de búsqueda entre sitios: Un adversario puede detectar si hay una cadena arbitraria en los resultados de la búsqueda del usuario. Para ello, verifica si una imagen de "no hay resultados de la búsqueda" que usa un sitio web en particular está en la caché del navegador.
- Seguimiento entre sitios: La caché se puede usar para almacenar identificadores similares a cookies como un mecanismo de seguimiento entre sitios.
Para mitigar estos riesgos, Chrome particionará su caché HTTP a partir de la versión 86.
¿Cómo afectará la partición de la caché a la caché HTTP de Chrome?
Con el particionamiento de la caché, se asignará a los recursos almacenados en caché una "Clave de Aislamiento de Red" además de la URL del recurso. La Clave de Aislamiento de Red está compuesta por el sitio de nivel superior y el sitio del marco actual.
Vuelve a mirar el ejemplo anterior para ver cómo funciona la partición de caché en diferentes contextos:
https://a.example, https://a.example, https://x.example/doge.png }
Un usuario visita una página (https://a.example) que solicita una imagen (https://x.example/doge.png). En este caso, la imagen se solicita a la red y se almacena en caché con una tupla que consta de https://a.example (el sitio de nivel superior), https://a.example (el sitio del marco actual) y https://x.example/doge.png (la URL del recurso) como clave. (Ten en cuenta que, cuando la solicitud de recursos proviene del marco de nivel superior, el sitio de nivel superior y el sitio del marco actual en la clave de aislamiento de red son los mismos).
https://b.example, https://b.example, https://x.example/doge.png }
El mismo usuario visita una página diferente (https://b.example) que solicita la misma imagen (https://x.example/doge.png). Aunque se cargó la misma imagen en el ejemplo anterior, como la clave no coincide, no se realizará una coincidencia en la caché.
La imagen se solicita a la red y se almacena en caché con una tupla que consta de https://b.example, https://b.example y https://x.example/doge.png como clave.
https://a.example, https://a.example, https://x.example/doge.png }
Ahora, el usuario vuelve a https://a.example, pero esta vez la imagen (https://x.example/doge.png) está incorporada en un iframe. En este caso, la clave es una tupla que contiene https://a.example, https://a.example y https://x.example/doge.png, y se produce un acierto de caché. (Ten en cuenta que, cuando el sitio de nivel superior y el iframe son el mismo sitio, se puede usar el recurso almacenado en caché con el marco de nivel superior).
https://a.example, https://c.example, https://x.example/doge.png }
El usuario vuelve a https://a.example, pero esta vez la imagen se aloja en un iframe de https://c.example.
En este caso, la imagen se descarga de la red porque no hay ningún recurso en la caché que coincida con la clave que consta de https://a.example, https://c.example y https://x.example/doge.png.
https://a.example, https://c.example, https://x.example/doge.png }
¿Qué sucede si el dominio contiene un subdominio o un número de puerto? El usuario visita https://subdomain.a.example, que incorpora un iframe (https://c.example:8080), que solicita la imagen.
Debido a que la clave se crea en función de "esquema://eTLD+1", se ignoran los subdominios y los números de puerto. Por lo tanto, se produce un acierto de caché.
https://a.example, https://c.example, https://x.example/doge.png }
¿Qué sucede si el iframe se anida varias veces? El usuario visita https://a.example, que incorpora un iframe (https://b.example), que incorpora otro iframe (https://c.example), que finalmente solicita la imagen.
Debido a que la clave se toma del fotograma superior (https://a.example) y del fotograma inmediato que carga el recurso (https://c.example), se produce un acierto de caché.
Preguntas frecuentes
¿Ya está habilitada en mi Chrome? ¿Cómo puedo verificarlo?
La función se lanzará a fines de 2020. Para comprobar si tu instancia de Chrome ya la admite, haz lo siguiente:
- Abre
chrome://net-export/y presiona Start Logging to Disk. - Especifica dónde quieres guardar el archivo de registro en tu computadora.
- Navega por la Web en Chrome durante un minuto.
- Regresa a
chrome://net-export/y presiona Stop Logging. - Ve a
https://netlog-viewer.appspot.com/#import. - Presiona Elegir archivo y pasa el archivo de registro que guardaste.
Verás el resultado del archivo de registro.
En la misma página, busca SplitCacheByNetworkIsolationKey. Si le sigue Experiment_[****], la partición de la caché HTTP está habilitada en tu Chrome. Si le sigue Control_[****] o Default_[****], no está habilitado.
¿Cómo puedo probar el particionamiento de la caché HTTP en mi Chrome?
Para probar la partición de la caché HTTP en Chrome, debes iniciar Chrome con un indicador de línea de comandos: --enable-features=SplitCacheByNetworkIsolationKey. Sigue las instrucciones que se indican en Cómo ejecutar Chromium con marcas para aprender a iniciar Chrome con una marca de línea de comandos en tu plataforma.
Como desarrollador web, ¿hay alguna acción que deba realizar en respuesta a este cambio?
Este no es un cambio rotundo, pero puede imponer consideraciones de rendimiento para algunos servicios web.
Por ejemplo, es posible que los que publiquen grandes volúmenes de recursos altamente almacenables en caché en muchos sitios (como fuentes y secuencias de comandos populares) vean un aumento en su tráfico. Además, es posible que quienes consumen esos servicios dependan más de ellos.
(Existe una propuesta para habilitar bibliotecas compartidas de una manera que preserve la privacidad, llamada Bibliotecas compartidas web (video de presentación), pero aún está en consideración).
¿Cuál es el impacto de este cambio de comportamiento?
La tasa general de fallas de caché aumenta en aproximadamente un 3.6%, los cambios en el FCP (primer procesamiento de imagen con contenido) son modestos (~0.3%) y la fracción general de bytes cargados desde la red aumenta en alrededor de un 4%. Puedes obtener más información sobre el impacto en el rendimiento en la explicación del particionamiento de la caché HTTP.
¿Está estandarizado? ¿Otros navegadores se comportan de manera diferente?
Las "particiones de caché HTTP" están estandarizadas en la especificación de recuperación, aunque los navegadores se comportan de manera diferente:
- Chrome: Usa el esquema de nivel superior esquema://eTLD+1 y el esquema de marco esquema://eTLD+1.
- Safari: Usa eTLD+1 de nivel superior.
- Firefox: Planean implementar con el esquema de nivel superior://eTLD+1 y consideran incluir una segunda clave como Chrome.
¿Cómo se trata la recuperación de los trabajadores?
Los trabajadores dedicados usan la misma clave que su marco actual. Los trabajadores de servicio y los trabajadores compartidos son más complejos, ya que se pueden compartir entre varios sitios de nivel superior. Actualmente, se está analizando la solución para ellos.