👶🏼 👈🏻 👩‍✈️ BFCache, o There and back. Informe Yandex 🚴🏾 👨‍❤️‍👨 🔹

La gente usa el botón de retorno a la página anterior en el navegador muy a menudo, tal vez más a menudo de lo que piensas. Y si es así, ¿por qué tirar inmediatamente la página de la memoria del navegador y después de pasar un segundo tiempo y reabrir el tráfico? Para que el usuario pueda regresar rápidamente, se inventó la tecnología BFCache, que es importante recordar al desarrollar interfaces. Victor Khomyakovvictor-homyakov descubrió el "almacenamiento en caché de ida y vuelta" y compiló una tabla de compatibilidad BFCache con diferentes API.

- Hola, me llamo Victor. Trabajo como parte de un equipo bastante grande que se ocupa de la página de búsqueda.

Como mínimo, ya has visto la misma página o una similar en Google. Y en particular, me ocupo del problema de la velocidad de descarga de esta página, para que se muestre en el servidor lo más rápido posible y se descargue y muestre a los clientes lo más rápido posible. ¿Por qué es importante? Mientras menos espere el cliente a que se cargue su página, es menos probable que no espere y lo deje. Y cuanto más probable sea que el cliente se convierta con éxito en otra cosa, mayor será el puntaje neto de la promoción. Es decir, el cliente felizmente le dirá a todos los que conocen que esta es una página genial: se carga muy rápido, es muy conveniente de usar. Y en última instancia, cuanto más dinero pueda ganar. O su empresa, entonces le dará un premio.

Daré una serie de ejemplos de compañías conocidas. Google realizó un experimento. Intencionalmente incrustaron un retraso en la página de búsqueda y midieron cómo esto afecta el rendimiento. Resultó que, en promedio, había medio por ciento menos búsquedas por usuario. ¿Qué es medio por ciento? Calcular: medio porcentaje de cientos de millones de usuarios de Google es un número bastante grande.

Bing hizo el mismo experimento. No le creyeron a Google, decidieron verificarlo dos veces. Obtuvieron resultados similares: notablemente menos ingresos por usuario cuando la página se ralentiza. ¿Por qué ralentizar? Porque es más fácil ralentizar la página por el número exacto de milisegundos para que pueda reproducirse fácilmente en la producción que acelerarla en la misma cantidad.

Ejemplo de AliExpress. Aceleraron su sitio en un 36% y recibieron significativamente más pedidos de los usuarios. Los pedidos son dinero directo. En general, ya está claro para todos que la velocidad es bastante importante, afecta, a través de una cierta cantidad de métricas, el dinero ganado.

Y un factor más. Hoy ya hemos hablado sobre la optimización de imágenes. Al optimizar su tráfico, reduciendo la cantidad de descargas, usted paga menos dinero a sus anfitriones por el tráfico saliente. Este es también el dinero que permanecerá en su bolsillo. ¿Qué sucede si de repente le ofrezco un 10% de descuento en el tráfico de cualquier host sin restricciones ni condiciones? ¿Y si propongo asegurarme de que el usuario cargue casi al instante la parte de sus páginas, por ejemplo, el diez por ciento? Nadie se negará.

La tecnología de la que trataré de hablar hoy es una de las posibles soluciones que impone pocas restricciones con respecto a la pila con la que trabaja, con qué tecnologías, pero al mismo tiempo promete brindarle ganancias bastante significativas.

Para empezar, Google recopila estadísticas sobre cómo se utilizan estos navegadores en sus navegadores. Y publicaron tal número: resulta, en promedio, de todas las aperturas de página, de toda la navegación en Chrome móvil, aproximadamente el 19% es un movimiento de ida y vuelta a través de la historia. Piensa lo que eso significa? Si redondeas, resulta que el 20% de la navegación se mueve a la página donde el usuario acaba de estar.

Para nosotros, como para los autores de las páginas, esto significa: incluso si el usuario lo abandona, existe una posibilidad considerable de que esté a punto de regresar. Por un lado, este puede ser precisamente el problema de los teléfonos móviles: todo es pequeño, es fácil perder un dedo, hacer clic en el enlace y salir de la página, luego decir: "¡Oh, demonios! Quiero regresar". Pero en las computadoras de escritorio, la situación es casi la misma: allí el número es menor, pero todavía hay un porcentaje significativo de retornos.

¿Qué estamos haciendo en este momento? Gastamos de manera ineficaz el tiempo y el tráfico del usuario. Es decir, comenzamos a volver a cargar la misma página, analizarla, recrear el DOM, volver a dibujar todo en la pantalla, cargar, ejecutar JavaScript.

El navegador es una cosa bastante poderosa. Él está tratando de usar cachés siempre que sea posible. Y la mayoría de los recursos pueden estar en su caché. No los esperará de la red, sino que los recogerá directamente del caché. Por ejemplo, en el motor V8, el resultado del análisis de JavaScript también se almacena en caché. Es decir, el navegador no volverá a cargar y analizar JS, y en la mayoría de los casos se necesitará ejecutarlo de inmediato. Pero aún así, la reconstrucción del DOM, la recarga de recursos no almacenados en caché y la ejecución de JS requieren una cantidad considerable de tiempo.

La solución se sugiere por sí misma. ¿Que estamos haciendo? Nosotros, cuando el usuario abandona nuestra página, no la limpiamos de inmediato. Simplemente guardamos su estado y lo ocultamos visualmente al usuario para que, bajo el capó, permanezca a disposición del navegador.

¿Qué haremos si el usuario decide regresar? Solo muéstrele la misma página guardada. Se puede mostrar casi al instante.

Esta tecnología se llama caché hacia atrás / adelante, de las palabras "adelante y atrás". Corto para bfcache.

Aquí hay un ejemplo de cómo se comporta el mismo navegador, el mismo ensamblaje cuando bfcache está apagado y encendido. La apertura de la primera página es igualmente lenta tanto allí como allí. Pero además, cuando comenzamos a avanzar y retroceder por la historia, se nota una pausa a la izquierda y no a la derecha. A la izquierda, el movimiento habitual a través de la historia lleva un tiempo notable. A la derecha, todo sucede muy, muy rápido.

Mostrar GIF

Un ejemplo similar de nuestra búsqueda. A la izquierda está el Safari habitual en macOS con bfcache deshabilitado, a la derecha está el mismo Safari con la configuración predeterminada y bfcache habilitado. Este es un caso bastante común: una persona viene en busca, puede no saber exactamente lo que está buscando, puede pedir varias opciones de consulta. Hice la primera solicitud, algo no está bien. La segunda solicitud parece ser mejor. Tercero: no, peor, regrese a la solicitud anterior. Y en este momento sería muy bueno no hacerlo esperar. Acaba de ver esta solicitud anterior, muéstrela de inmediato.

O la segunda opción, si tiene paginación y varias páginas sobre el tema. Hombre hojeando el tema. Fui a la segunda, tercera, cuarta página, miré, no, hay algo mal, volveré. Y nosotros, nuevamente, podemos mostrarle las páginas anteriores casi al instante.

Un tema importante es la seguridad. Si bien la página en la que el usuario no estaba oculto, puede acceder a varias API que le permiten leer el estado del hardware de su teléfono o computadora. Aquí hay una breve lista de lo que se le ocurrió de inmediato: geolocalización, cambio de la posición de su dispositivo en el espacio, acceso a la cámara y sonido desde el micrófono.

Luego, cuando aparece la página, es importante que no obtenga acceso a todos los eventos que ocurrieron durante el tiempo que estuvo oculta. De lo contrario, se abrirá un canal adicional para espiar a los usuarios. Es importante que ella no tenga un historial de sus movimientos durante todo este tiempo y la grabación del micrófono y la cámara. Los desarrolladores de navegadores tampoco deberían olvidarse de esto.

API y soporte de navegador

Más cerca del tema. Supongamos que ya lo he persuadido: "Sí, un buen tema, debemos trabajar con esto". ¿Qué API tenemos a nuestra disposición, con qué podemos trabajar si aceptamos tener en cuenta bfcache y cómo los navegadores lo admiten?

¿Dónde ya existe bfcache, dónde puedo verlo?

- Durante mucho tiempo se ha implementado en los navegadores Firefox, Safari (y macOS e iOS), así como en Internet Explorer 11 (!). Por lo general, regañamos a los desarrolladores de Microsoft, pero aquí simplemente lo intentaron.

- Se implementa en el navegador UC Browser 11/12, versión para Android.

- De repente no está en Chrome. Y en Chromium esta característica está en desarrollo.

Entonces, cuando hacen esto en Chromium, casi todos estos navegadores (y esta no es una lista completa) tarde o temprano obtendrán esta funcionalidad, de forma gratuita, sin SMS ni registro.

¿Hay algún tipo de API? Quiero administrar bfcache, quiero activarlo y desactivarlo directamente desde JavaScript, para averiguar si hay alguna página en bfcache o no. ¿Qué tal una API de este tipo? No existe tal API. Y esto se hizo conscientemente: la página no debería querer activar o desactivar bfcache para todos y para sí misma. O averigüe si hay alguien en este bfcache o no. Todo esto se debe a la seguridad.

^{_{Enlace de la diapositiva}}

Pero que tenemos? Tipos de navegación. Hay un tipo de enlace: representación previa de enlaces, cuando queremos representar una página por adelantado. Hay un tipo especial de navegación para él: esta página se abrirá con el tipo de navegación "prerender". Si solo abrimos la página en un navegador, habrá "navegar". Si hacemos clic en el botón "Actualizar", será "recargar".

Aquí estamos interesados en el tipo de navegación "hacia atrás", esto indica claramente que el usuario avanzó y retrocedió a través de la historia. Este es exactamente el tipo de navegación con el que nuestro bfcache puede trabajar.

Otra API son los eventos de presentación de páginas. Ya existían en los navegadores. En consecuencia, pagehow se activa cuando su página se muestra en el navegador para el usuario, pagehide se activa cuando la página se oculta por cualquier motivo. Y se complementaron con el campo persistente. Si la página se está ocultando y al mismo tiempo se colocará en bfcache, entonces el campo persistente será verdadero. Si la página se muestra al subirla desde bfcache, el campo persistente volverá a ser verdadero.

En consecuencia, si el navegador no va a almacenar en caché la página, entonces el ocultamiento de la página persistirá falso. Y si el navegador muestra la página durante la carga normal, o no usa bfcache, pagehow también persistirá falso.

^{_{Enlace de la diapositiva}}

La compatibilidad con eventos está disponible en casi todos los navegadores, incluso en aquellos que aún no admiten bfcache.

^{_{Enlace desde la diapositiva}}

Lo mismo ocurre con el campo persistente. Ya existe en Chrome, y Chrome todavía no es compatible con bfcache. Es decir, este campo siempre estará en él, pero por ahora será falso.

Cuando me encontré con este fenómeno, bfcache, tuve que estudiarlo, tocar todos los lados y ver cómo funciona. Inmediatamente quise ver en mi página cuando abro a qué es igual el valor del campo persistente en mis controladores.

Parece que todo es bastante simple. Escribí un controlador y salida a console.log () lo que viene a mí. Pero al abrir DevTools en algunos navegadores, bfcache puede cerrarse repentinamente. Es decir, abrí DevTools, voy y vengo a través de las páginas, y mi persistencia siempre es falsa, la página no entra en bfcache. Bien, tengo otra herramienta poderosa: alerta.

Pero no. Los navegadores modernos al descargar una página en la página oculta, antes de descargar y descargar los controladores simplemente ignoran la alerta, simplemente no funciona allí. Y de nuevo, no veo lo que quiero.

De acuerdo, tengo un producto aún más asesino. Estoy en un bloque justo en mi propia página, que estoy explorando, simplemente agrego el texto del contenido de mi evento y, por lo tanto, registro todo. Este método funcionó.

Todo, por favor, se puede usar. Depuré mi código, funciona para mí, puedo continuar para continuar con él. Por supuesto, no olvido que, después de todo, un script estático externo es más adecuado para no cargar el mismo código en línea en la página, sino para usar el almacenamiento en caché de archivos.

Puse este código depurado en un script externo.

Pero no, ¡los manejadores de pie de página cayeron en Safari! Por alguna razón, no funcionan desde un script externo.

Bien, ya tengo una versión funcional. Tuve que dejarlo así.

Voy a enumerar brevemente lo que logré pisar en solo un día. Primero, DevTools puede deshabilitar el almacenamiento en caché. Probablemente recuerde que en DevTools en la pestaña Red en Chrome hay una casilla de verificación "Desactivar caché". Deshabilita la memoria caché de la red, puede no afectar a bfcache o puede hacerlo. La analogía es clara: abrimos DevTools, lo que significa que estamos desarrollando y es posible que no necesitemos almacenamiento en caché. Tal vez nos molesta.

La segunda característica es alerta. Firefox y Safari lo ignorarán en silencio y continuarán ejecutando controladores aún más, como si no hubiera ninguna alerta. Y solo un Chrome antiguo en la consola escribirá un error en rojo: tiene una alerta, la bloqueé, ¡conózcalo!

Una vez más, les recuerdo que los controladores de un script externo en Safari pueden no ser llamados, esto es muy extraño.

Y una noticia más importante. Si su página está en caché, es decir, recibió un evento de ocultación de página, y dice que persiste como verdadero, y el navegador le dice: "Sí, lo puse en la caché", esto no garantiza que la página vuelva a ser posterior. desde este caché se genera y se muestra de nuevo al usuario. Porque el navegador puede decidir borrar este caché si se queda sin memoria. Porque el usuario puede cerrar el navegador y no navegar a ningún lado. Recuerda esto.

Características de implementación

Comencé a profundizar en la documentación, a investigar cómo puedo vivir con este conocimiento. Sorprendentemente, la documentación fue. Es decir, puede desenterrar en Internet una descripción de cómo funciona bfcache en los navegadores. Pero, cuanto más leo, más diferencias se acumulan entre los diferentes navegadores.

En uno, funciona así, en el otro funciona. En uno, uno interfiere, el otro no interfiere. Los desarrolladores no saben cómo procesar correctamente una serie de API al colocar una página en bfcache. Dicen: está bien, si la página usa esta API, simplemente la ignoro, nunca la guardo en la caché bajo ninguna circunstancia. Y esta lista es diferente en diferentes navegadores, cada uno hace lo que le conviene.

Y luego comencé a combinar lo que aprendí en una sola mesa. Tengo algo como lo siguiente:

Leí la documentación para los navegadores: para Firefox, Safari, la familia Chromium. Había documentación disponible en IE, aunque desactualizada. A los programadores no nos gusta actualizar la documentación después de los cambios en el navegador. Cuando me di cuenta de que la información no estaba actualizada, comencé a probar mis páginas pequeñas en los navegadores y a verificar qué API funciona y cuál no.

Esto tampoco fue suficiente: no sé qué API mirar en principio, pero no ordenar todo en absoluto. Y tuve que buscar en el código fuente de los motores del navegador, es decir, el código resultó ser la fuente de conocimiento más precisa y confiable. Por el momento, esta placa (frente a usted es una parte de ella, aquí hay un enlace a la versión completa) es la recopilación de conocimiento más completa sobre qué API permiten o prohíben que bfcache funcione en los navegadores.

Las API que no interfieren con una marca de verificación y un color verde, aquellas que definitivamente evitarán que la página entre en bfcache están marcadas en rojo. Los campos blancos son espacios que no se describen en ninguna parte.

Firefox

Aquí hay algunos detalles interesantes de navegadores específicos. Comenzaré con Firefox, él fue el primero en hacerlo todo.

^{_{Enlace de la diapositiva}}

Lo más importante que aprendí de las fuentes de Firefox es que cuando trabaja con bfcache puede escribir en el registro de texto en el disco todas las razones por las que no puede colocar la página en la memoria caché.

^{_{Enlace de la diapositiva}}

E incluso logré descubrir cómo hacerlo. Hay dos variables de entorno secretas: en una indicamos qué registrar, en la segunda, en qué archivo escribir un registro. Después de eso, lanzamos el binario, ¡y listo! Veremos aproximadamente que en la diapositiva anterior, las líneas del formulario "dicho html no se pueden almacenar en caché por tal razón, por una razón diferente". Podemos leerlo de inmediato, muy conveniente.

Si desea experimentar una vez, puede abrir la página about: networking en Firefox. Allí puede ingresar los mismos campos en la sección "Diario". Podemos indicar en dos campos qué y dónde registrar, y con los botones iniciar y detener el registro.

^{_{Enlace de la diapositiva ¿}}

Cuándo Firefox se niega a almacenar en caché la página? Si tiene solicitudes incompletas, incluidas solicitudes AJAX o solicitudes de recursos como imágenes, entonces se negará a poner la página en bfcache. Él cree que no se ha completado, no ha terminado de descargar, hay algún tipo de actividad sospechosa. Pero todo esto no se aplica al favicon. Si olvidó el favicon, si no se carga, piensa: está bien, lo hará, es normal para su sitio.

Si tiene un script de larga ejecución, el navegador le preguntará: ya que lleva tiempo, bloquea la interfaz de usuario, ¿tal vez lo supera? Y si está de acuerdo, se considera que esa página es un poco incorrecta y no la almacenamos en caché.

Si usa IndexedDB ... Esta es una historia instructiva. Anteriormente, en la primera implementación, buscaban: si tiene IndexedDB y hay una transacción incompleta, esa página no se almacena en caché, porque no está claro cómo trabajar con ella (estamos tratando de ocultarla justo en el medio de la transacción). Pero luego simplemente perdieron este fragmento de código durante la refactorización. Y como te puedes imaginar, no tenían pruebas para esto. Incluso tienen un error en el rastreador de errores. Él ya tiene dos años con algo. La gente escribió: "Mi bfcache con IndexedDB no funciona correctamente, ¿qué debo hacer?" Los desarrolladores de Firefox respondieron: realmente se descompone, acabamos de perder este fragmento de texto durante la refactorización, está bien, déjenlo continuar. Moraleja: escribe pruebas, incluso si escribes Firefox, de lo contrario todo puede terminar tristemente.

Y otro factor interesante de no disponibilidad en bfcache, si se permite explícitamente contenido mixto. ¿Lo que es?

^{_{Enlace desde la diapositiva}}

Suponga que su página se abre a través de HTTPS, pero aún carga algunos recursos a través de HTTP, especialmente scripts. Es decir, tiene un script que no es de seguridad, puede ser modificado por cualquier persona.

^{_{Enlace desde la diapositiva}}

De manera predeterminada, Firefox, como otros navegadores, no ejecuta una secuencia de comandos que no sea de seguridad ahora. Pero si es muy importante para usted, subió a la configuración y permitió que se ejecute, por lo tanto, no almacenará en caché dicha página. Él dirá, bueno, ¡me dijiste que no ejecutara el código, pero luego no, no!

Otro ajuste es el tamaño de bfcache en sí. Aquí, el valor predeterminado es menos uno. Eso significa cuánta memoria tiene Firefox, tantas páginas que intenta almacenar en caché. Pero podemos deshabilitar por la fuerza el caché al poner un cero, o establecer explícitamente un número; por ejemplo, recuerde no más de cinco páginas.

Advertencia: la siguiente diapositiva contiene código de muestra en el lenguaje aterrador de C ++, esto puede ser peligroso en una conferencia front-end. No intente copiarlo, ejecútelo en la consola del navegador. Su disco puede estar formateado, la pantalla puede explotar o se pueden extraer bitcoins. Te lo adverti.

^{_{Enlace de la diapositiva}}

Entonces, el código Gecko. Se puede abrir, leer, ver de forma gratuita en Internet. Y rebusqué. Existe el método más importante: CanSavePresentation (), responde a la pregunta: ¿es posible almacenar en caché este documento? Es decir, esta es la última fuente de verdad sobre lo que ahora se implementa en Firefox. Y sin embargo, fue a partir de ahí que aprendí que puedes leer el registro. Existe tal variable: gPageCacheLog. Este es el registro en el que todo está escrito. Aquí hay una historia tan interesante sobre una excursión a C ++.

Es decir, abre el enlace, mira el código, busca (hay una búsqueda conveniente y, además, rápida) y puede encontrar los detalles de implementación reales en la última versión del navegador, aquellos que simplemente faltan en la documentación.

Safari

Lo más cruel que hace Safari cuando una página llega a bfcache: si tiene solicitudes AJAX pendientes, Safari simplemente las mata.

Incluso si los superpuso con controladores de errores e intenta verificar todo, corríjalo; parece que la solicitud no existía en absoluto. Después de recuperarse de bfcache, no tendrá ningún error, ningún "OK", nada en absoluto.

Los controladores de pagehow ocultan páginas, como dije, en Safari solo se llaman si están escritos en un script que está en línea en la página. Desde un script externo, pueden o no funcionar, qué suerte. Pero te lo advertí.

Otra diferencia interesante: los controladores antes de descargar y descargar no interfieren con el ingreso de la página a bfcache. En este caso, siempre se llama a beforeunload, y cuando entra en el caché, y cuando no se golpea. Pero descargar cuando la página llega al caché no se llama. Y aquí hay otro rastrillo ubicado: la página puede ir al caché y nunca aparecer de ella, y si escribió algún código importante en la descarga, nunca se puede llamar, aunque no se produjo un solo error en la página. Es decir, fue correctamente al caché, y de allí a ninguna parte, y nunca se llamará a su descarga.

Otro punto interesante. Como sabes, puedes abrir varias ventanas a través de window.open (). Y al mismo tiempo, estas ventanas tienen enlaces entre sí. Es decir, pueden subir simultáneamente a la ventana del otro, leer / escribir diferentes propiedades. Esta apertura de ventanas secundarias no interfiere con bfcache. Y aquí, lo más probable, Safari es tan cruel como lo es con las solicitudes de AJAX, es decir, todo se está rompiendo y adiós. A los desarrolladores de Apple les encanta más.

De nuevo un minuto C ++! Las fuentes de WebKit tampoco son secretas, también se pueden abrir, leer y estudiar.

^{_{Enlace desde la diapositiva}}

Están en GitHub, allí

destaqué dos funciones importantes: - canCacheFrame () - verifica si este marco se puede almacenar en caché.
- En diferentes objetos de la página, como un elemento HTML o una fuente, existen métodos canSuspendForDocumentSuspension (). Este objeto es responsable de si puede almacenar en caché, congelar o no.

Y un aspecto más importante: WebKit tiene pruebas muy convenientes. Allí, justo en la carpeta LayoutTests / fast / history, en forma de html pequeño, compacto y conciso, hay pruebas para el trabajo de diferentes API que se implementan en Safari con bfcache. Este es un ejemplo vivo de cómo puede escribir código en Safari con estas API y cómo afectan o no afectan si permiten o no los golpes de bfcache. Muy interesante de ver.

A partir de ahí, aprendí que Safari también escribe todo su conocimiento sobre bfcache, todas las funciones, en un registro de texto. Pero, desafortunadamente, nunca descubrí cómo habilitar este registro o, si está habilitado, dónde encontrar este archivo en el disco. Si alguien lo sabe, dígame, le estaré muy agradecido.

Cromo.

Como ya dije, todavía hay trabajo en progreso, todo está cerrado bajo la bandera. Puede descargar el nuevo canario de Chrome, vaya a las banderas. La configuración está oculta allí; puedes intentar jugar con ella. Puede que veas algo.

De lo interesante: ya hablé sobre abrir una página a través de window.open (). En Chromium, tales páginas no están en caché hasta ahora. No descubrieron cómo resolver todo esto correctamente y lo cortaron descaradamente, como en Safari, su conciencia no se lo permite.

Si DOMContentLoaded no se produce, la página tampoco se almacenará en caché.

Hay muchas API nuevas que comienzan con "Web"; también es difícil e incomprensible con ellas, y hasta ahora todas ellas desactivan bfcache de forma predeterminada. Es decir, si se usa algo moderno, nuevo en la página, como WebGL, WebVR, WebUSB, WebBluetooth, etc., dicha página no entrará en bfcache.

Trabajador del servicio. Además, todavía no almacenamos en caché dicha página, pero planeamos procesarla correctamente, ocultarla de los ojos vigilantes del Trabajador de servicio.

Si la geolocalización está habilitada, todavía no la almacenamos en caché. Tan simple por ahora.

Si durante el tiempo que la página estaba en el caché, las cookies estaban podridas, creemos que ha expirado algún tipo de autorización. Quizás fue la banca en línea o alguna otra cosa. Esto significa que la página ya no es válida; la borramos del caché.

^{_{Enlace de la diapositiva}}

Los chicos de Google fueron aún más lejos. Propusieron unificar todo formalizar, unificar en todos los navegadores, propusieron una especificación del ciclo de vida de la página para todos los estados, propusieron agregar nuevos eventos a las transiciones entre diferentes estados. Puedes mirar el enlace que pensaron allí.

^{_{Enlace de la diapositiva}}

Fuentes. Como saben, las fuentes de cromo también están disponibles. Todo esto se encuentra en una clase llamada BackForwardCacheImpl: muy buena denominación, casi no tenía que buscar. El método principal que verifica si se puede guardar un documento se llama CanStoreDocument (). También hay un método GetDisallowedFeatures (), que simplemente enumera todas las nuevas funciones y API que no son compatibles con bfcache. Muy conveniente: concentrado en un solo lugar, leyó y se dio cuenta de lo que actualmente es posible y lo que no se puede usar.

Internet Explorer 11

Una excursión a la historia para quienes aún tienen IE 11. Para quienes tienen todo mal.

Hay bfcache allí, y este es el problema principal, porque tienes que lidiar con eso. La documentación dice que bfcache supuestamente solo funciona a través de HTTP. De hecho, en producción, también funciona en HTTPS por alguna razón. Moraleja: si es desarrollador, preste atención a su documentación. Entonces tienes que sufrir por ella.

Si hay un controlador anterior a la descarga, evitará que ingrese al caché. No dijeron nada sobre la descarga en la documentación, tal vez no lo supieron ni lo olvidaron.

Si la página no ha terminado de cargarse, tampoco se almacena en caché. Si alguien usa componentes ActiveX, tampoco almacenamos en caché. Y si DevTools también está abierto allí. Éste es un punto importante.

¿Cómo sin errores? Se agregó un campo persistente, pero a veces no funciona. Es decir, la página realmente ingresa al caché, regresa de ella y persiste no se establece en verdadero. ¿Qué hacer?

Teníamos un código hermoso que determina si volvimos del caché o volvimos a cargarlo desde el servidor.

Ahora tenía que ser complementado con una muleta para IE. Determinamos que tenemos IE y, en algunas soluciones, entendemos que la página todavía se extrajo de la memoria caché y, al mismo tiempo, teníamos un historial de navegación (hacia atrás).

Además, ¿cómo saber si una página está en caché? Tomamos su tiempo de carga. Si se cargó desde el servidor en 50 milisegundos o más rápido, esto básicamente no puede estar en IE, ¡significa que es del caché! :)

Ya mencioné la navegación a través de la historia. Si tenemos el tipo de navegación back_forward, revisamos el historial, y si la página es del caché, significa bfcache, no hay otras opciones en IE.

¿Que sigue?

¿Qué hacer a continuación con este conocimiento? No quisiera que salgas y olvides todo esto como una pesadilla.

- En primer lugar, aquí está lo más valioso que encontré y a lo que quiero empujarlo: ¡use navegadores de código abierto! En el acceso abierto a Internet en este momento se encuentra el código fuente de todos los principales navegadores que utilizan nuestros clientes. Y esta es la documentación más relevante sobre cómo y cómo se admite, dónde y cómo funciona. Incluyendo hay pruebas que se escriben directamente en HTML y JS. Uso, mira!

- En segundo lugar, considere en las aplicaciones existentes que pueden ejecutarse en bfcache. Informe a sus evaluadores sobre esto para que cuando verifiquen la navegación, sepan que al navegar por el historial, la página se puede abrir tanto desde el servidor como desde bfcache. Aquí hay un video del error real que corregimos cuando bfcache funcionó para nosotros:

GIF abierto

El usuario ingresa cuatro solicitudes, ve cuatro problemas. Después de eso, vuelve, ve el problema 3 y la consulta 4. Otro problema anterior es el 2 y la consulta 3. Es decir, tiene un estado no coincidente de la página: el contenido de las cadenas de búsqueda y búsqueda se contradice entre sí. Tenga esto en cuenta en sus aplicaciones.

- Y en tercer lugar, si está escribiendo un nuevo código, piense si necesita bfcache. Si es así, use la tabla de compatibilidad API. Si no, no lo use, pero si accidentalmente entra en bfcache, considere las características de Safari y otros navegadores que mencioné. Algunas cosas pueden romperse insolentemente y no podrás entender por qué sucede esto.

Según lo prometido, un enlace a los materiales.

BFCache, o There and back. Informe Yandex