🏉 🚁 🧑🏼‍🤝‍🧑🏼 BFCache ou Là et retour. Rapport Yandex 💅🏼 🧝🏿 💾

Les gens utilisent le bouton de retour à la page précédente dans le navigateur très souvent - peut-être plus souvent que vous ne le pensez. Et si oui, alors pourquoi jeter immédiatement la page hors de la mémoire du navigateur, et après une seconde passer du temps et du trafic à la rouvrir? Afin que l'utilisateur puisse revenir rapidement en arrière, la technologie BFCache a été inventée, ce qu'il est important de retenir lors du développement des interfaces. Victor Khomyakovvictor-homyakov compris la "mise en cache aller-retour" et compilé une table de compatibilité BFCache avec différentes API.

- Bonjour, je m'appelle Victor. Je travaille au sein d'une équipe assez importante qui s'occupe de la page de recherche.

Au minimum, vous avez déjà vu la même page ou une page similaire sur Google. Et en particulier, je traite le problème de la vitesse de téléchargement de cette page - afin qu'elle s'affiche sur le serveur le plus rapidement possible et se télécharge et s'affiche aux clients le plus rapidement possible. Pourquoi c'est important? Moins le client attend que votre page se charge, moins il est probable qu'il n'attendra pas et ne vous quittera pas. Et plus il est probable que le client réussira à se convertir à quelque chose d'autre, plus le score net de promotion sera élevé. Autrement dit, le client se fera un plaisir de dire à tout le monde qu'il sait que c'est une page géniale géniale - elle se charge très rapidement, elle est très pratique à utiliser. Et finalement, plus vous gagnez d'argent. Ou votre entreprise, alors elle vous donnera un prix.

Je vais donner un certain nombre d'exemples d'entreprises bien connues. Google a mené une expérience. Ils ont intentionnellement intégré un retard sur la page de recherche et mesuré comment cela affecte les performances. Il s'est avéré qu'en moyenne, il y avait un demi pour cent de recherches en moins par utilisateur. Qu'est-ce qu'un demi pour cent? Calculer: un demi pour cent de centaines de millions d'utilisateurs de Google est un nombre assez important.

Bing a fait la même expérience. Ils ne croyaient pas Google, ils ont décidé de revérifier. Ils ont obtenu des résultats similaires: sensiblement moins de revenus par utilisateur lorsque la page ralentit. Pourquoi ralentir? Parce qu'il est plus facile de ralentir la page du nombre exact de millisecondes afin qu'elle puisse être facilement reproduite en production que de l'accélérer de la même quantité.

Exemple sur AliExpress. Ils ont accéléré leur site de 36% et reçu beaucoup plus de commandes des utilisateurs. Les commandes sont en argent direct. En général, il est déjà clair pour tout le monde que la vitesse est assez importante, elle affecte, à travers un certain nombre de métriques, l'argent gagné.

Et encore un facteur. Aujourd'hui, nous avons déjà parlé de l'optimisation d'image. En optimisant votre trafic, en réduisant le nombre de téléchargements, vous payez moins d'argent à vos hébergeurs pour le trafic sortant. C'est aussi l'argent qui restera dans votre poche. Et si je vous offre soudainement une remise de 10% sur le trafic de n'importe quel hôte sans aucune restriction ni condition? Et si je propose de m'assurer que la part de vos pages - par exemple, dix pour cent - est chargée par l'utilisateur presque instantanément? Personne ne refusera.

La technologie dont j'essaierai de parler aujourd'hui est l'une des solutions possibles qui impose peu de restrictions sur la pile avec laquelle vous travaillez, sur quelles technologies, mais promet en même temps de vous apporter des gains assez importants.

Pour commencer, Google collecte des statistiques sur la façon dont ces navigateurs sont utilisés dans leurs navigateurs. Et ils ont publié un tel nombre: il s'avère que, en moyenne, de toutes les ouvertures de pages, de toute la navigation dans Chrome mobile, environ 19% est un mouvement de va-et-vient à travers l'histoire. Pensez à ce que cela signifie? Si vous arrondissez, il s'avère que 20% de la navigation se déplace vers la page où l'utilisateur vient d'être.

Pour nous, comme pour les auteurs des pages, cela signifie: même si l'utilisateur le quitte, il y a de fortes chances qu'il soit sur le point de revenir. D'une part, cela peut être précisément le problème des téléphones portables: tout est petit, il est facile de rater un doigt, cliquez sur le lien et quittez la page, puis dites: "Oh enfer! Je veux retourner". Mais sur les ordinateurs de bureau, la situation est à peu près la même: là, le nombre est moindre, mais il y a quand même un pourcentage important de retours.

Que faisons-nous en ce moment? Nous passons inefficacement sur le temps et le trafic des utilisateurs. Autrement dit, nous commençons à recharger la même page en arrière, à l'analyser, à recréer le DOM, à tout redessiner à l'écran, à charger, à exécuter JavaScript.

Le navigateur est une chose assez puissante. Il essaie d'utiliser des caches dans la mesure du possible. Et la plupart des ressources peuvent être dans son cache. Il ne les attendra pas sur le réseau, mais les récupérera directement dans le cache. Par exemple, dans le moteur V8, le résultat de l'analyse JavaScript est également mis en cache. Autrement dit, le navigateur ne rechargera pas et n'analysera pas JS, et dans la plupart des cas, il faudra pour l'exécuter immédiatement. Mais tout de même, la reconstruction du DOM, le rechargement des ressources non mises en cache et l'exécution de JS prennent beaucoup de temps.

La solution se suggère. Qu'est-ce que nous faisons? Nous, lorsque l'utilisateur quitte notre page, ne la nettoyons pas immédiatement. Nous sauvegardons simplement son état et le cachons visuellement à l'utilisateur afin que sous le capot il reste à la disposition du navigateur.

Que ferons-nous si l'utilisateur décide de revenir? Montrez-lui simplement la même page enregistrée. Il peut être affiché presque instantanément.

Cette technologie est appelée cache arrière / avant, à partir des mots «va-et-vient». Abréviation de bfcache.

Voici un exemple de la façon dont le même navigateur, le même assembly, se comporte lorsque bfcache est éteint et allumé. L'ouverture de la première page est tout aussi lente ici et là. Mais de plus, lorsque nous commençons à nous déplacer d'avant en arrière dans l'histoire, une pause est perceptible à gauche, et pas à droite. A gauche, le mouvement habituel à travers l'histoire prend du temps. A droite, tout se passe très, très vite.

Afficher le GIF

Un exemple similaire de notre recherche. À gauche se trouve le Safari habituel sur macOS avec bfcache désactivé, à droite se trouve le même Safari avec les paramètres par défaut et bfcache activé. C'est un cas assez courant: une personne vient à la recherche, peut ne pas savoir exactement ce qu'elle cherche, peut demander plusieurs options de requête. J'ai demandé la première demande - quelque chose ne va pas. La deuxième demande semble meilleure. Troisièmement - non, pire, revenez à la demande précédente. Et en ce moment ce serait bien de ne pas le faire attendre. Il vient de voir cette demande précédente, montrez-la tout de suite.

Ou la deuxième option, si vous avez la pagination et plusieurs pages sur le problème. Homme feuilletant la question. Je suis allé à la deuxième, troisième, quatrième page, j'ai regardé - non, il y a un problème, je reviens. Et nous, encore une fois, pouvons lui montrer les pages précédentes presque instantanément.

Un problème important est la sécurité. Bien que la page sur laquelle l'utilisateur n'était pas dans un état masqué, il peut accéder à diverses API qui vous permettent de lire l'état matériel de votre téléphone ou ordinateur. Voici une courte liste de ce qui m'est immédiatement venu à l'esprit: géolocalisation, modification de la position de votre appareil dans l'espace, accès à la caméra et son du microphone.

Ensuite, lorsque la page apparaît, il est important qu'elle n'accède pas à tous les événements qui se sont produits pendant la période où elle a été masquée. Sinon, un canal supplémentaire s'ouvrira pour espionner les utilisateurs. Il est important qu'elle n'obtienne pas un historique de vos mouvements pendant tout ce temps et des enregistrements du microphone et de la caméra. Les développeurs de navigateurs ne doivent pas non plus l'oublier.

Support API et navigateur

Plus proche du sujet. Supposons que je vous ai déjà convaincu, vous êtes: "Oui, un bon sujet, nous devons travailler avec cela." Quelles API avons-nous à notre disposition, avec quoi pouvons-nous travailler si nous acceptons de prendre en compte bfcache, et comment cela est-il pris en charge par les navigateurs?

Où bfcache existe-t-il déjà, où puis-je le voir?

- Il a longtemps été implémenté dans les navigateurs Firefox, Safari (et macOS et iOS), ainsi que dans Internet Explorer 11 (!). Habituellement, nous réprimandons les développeurs Microsoft, mais ici, ils ont juste essayé.

- Il est implémenté dans le navigateur UC Browser 11/12, version pour Android.

- Du coup, il n'est plus dans Chrome. Et dans Chromium, cette fonctionnalité est en cours de développement.

Ainsi, lorsqu'ils le font dans Chromium, presque tous ces navigateurs (et ce n'est pas une liste complète) obtiendront tôt ou tard cette fonctionnalité - gratuitement, sans SMS et sans inscription.

Existe-t-il une sorte d'API? Je veux gérer bfcache, je veux l'activer et le désactiver directement à partir de JavaScript, pour savoir s'il y a une page dans bfcache ou non. Que diriez-vous d'une telle API? Il n'y a pas une telle API. Et cela a été fait consciemment: la page ne devrait pas vouloir activer ou désactiver bfcache pour tout le monde et pour elle-même. Ou découvrez s'il y a quelqu'un dans ce bfcache ou non. Tout cela est dû à la sécurité.

^{_{Lien depuis la diapositive}}

Mais qu'avons-nous? Types de navigation. Il existe un type de lien - prérendeur de lien, lorsque nous voulons afficher une page à l'avance. Il existe pour lui un type de navigation particulier: cette page s'ouvrira avec le «Prerender» NavigationType. Si nous ouvrons simplement la page dans un navigateur, il y aura alors «naviguer». Si nous cliquons sur le bouton «Mettre à jour», ce sera «recharger».

Nous sommes intéressés par le type de navigation «back_forward» ici, cela indique clairement que l'utilisateur s'est déplacé d'avant en arrière dans l'histoire. C'est exactement le type de navigation avec lequel notre bfcache peut fonctionner.

Une autre API est les événements pageshow pagehide. Ils existaient déjà dans les navigateurs. En conséquence, pageshow est déclenché lorsque votre page est affichée dans le navigateur pour l'utilisateur, pagehide est déclenchée lorsque la page se cache pour une raison quelconque. Et ils ont été complétés par le champ persistant. Si la page se cache et en même temps sera placée dans bfcache, le champ persistant sera vrai. Si la page s'affiche lors de son élévation à partir de bfcache, le champ persistant sera à nouveau vrai.

Par conséquent, si le navigateur ne va pas mettre en cache la page, le masquage de page restera faux. Et si le navigateur affiche la page pendant le chargement normal, ou s'il n'utilise pas bfcache, alors pageshow persistera également faux.

^{_{Lien depuis la diapositive}}

La prise en charge des événements est disponible dans presque tous les navigateurs, même ceux qui ne prennent pas encore en charge bfcache.

^{_{Lien depuis la diapositive}}

Il en va de même pour le champ persistant. Il existe déjà dans Chrome et Chrome ne prend toujours pas en charge bfcache. Autrement dit, ce champ sera toujours dedans, mais pour l'instant il sera faux.

Quand je suis tombé sur ce phénomène, bfcache, j'ai dû l'étudier, taper de tous les côtés, regarder comment ça marche. J'ai immédiatement voulu voir sur ma page lorsque j'ouvre la valeur du champ persistant dans mes gestionnaires.

Il semblerait que tout soit assez simple. J'ai écrit un gestionnaire et sorti sur console.log () ce qui m'arrive. Mais lors de l'ouverture de DevTools dans certains navigateurs, bfcache peut soudainement s'arrêter. Autrement dit, j'ai ouvert DevTools, je fais des allers-retours dans les pages, et ma persistance est toujours fausse, la page n'entre pas dans bfcache. D'accord, j'ai un autre outil puissant - alerte.

Mais non. Les navigateurs modernes lors du déchargement d'une page dans le masque de page, avant et après le déchargement ignorent simplement l'alerte, cela ne fonctionne tout simplement pas. Et encore une fois, je ne vois pas ce que je veux.

D'accord, j'ai un produit encore plus tueur. Je suis dans un bloc directement sur ma propre page, que j'explore, en ajoutant simplement le texte du contenu de mon événement et en enregistrant ainsi tout. Cette méthode a fonctionné.

Tout, s'il vous plaît, peut être utilisé. J'ai débogué mon code, ça marche pour moi, je peux continuer à continuer. Bien sûr, je n'oublie pas qu'après tout, un script statique externe est mieux adapté pour ne pas charger le même code en ligne sur la page, mais pour utiliser la mise en cache des fichiers.

J'ai mis ce code débogué dans un script externe.

Mais non, les gestionnaires de pageshowhide sont tombés dans Safari! Pour une raison quelconque, ils ne fonctionnent pas à partir d'un script externe.

D'accord, j'ai déjà une version fonctionnelle. J'ai dû le laisser comme ça.

Je vais énumérer brièvement ce que j'ai réussi à marcher en une seule journée. Tout d'abord, DevTools peut désactiver la mise en cache. Vous vous souvenez probablement que dans DevTools sur l'onglet Réseau dans Chrome, il y a une case à cocher "Désactiver le cache". Il désactive le cache réseau, il ne peut pas affecter bfcache, ou il peut. L'analogie est claire: nous avons ouvert DevTools, ce qui signifie que nous développons et que nous n'avons peut-être pas besoin de mise en cache. Peut-être que cela nous dérange.

La deuxième caractéristique est l'alerte. Firefox et Safari l'ignoreront en silence et continueront à exécuter les gestionnaires plus loin, comme s'il n'y avait pas d'alerte. Et un seul bon vieux Chrome dans la console écrira une erreur en rouge - vous avez une alerte, je l'ai bloquée, sachez-la!

Encore une fois, je vous rappelle que les gestionnaires d'un script externe dans Safari ne peuvent pas être appelés, c'est très étrange.

Et une autre nouvelle importante. Si votre page est mise en cache, c'est-à-dire que vous avez reçu un événement de masquage de page, et il dit persisté vrai, et le navigateur vous dit: "Oui, je l'ai mis dans le cache" - cela ne donne aucune garantie que la page sera plus tard à partir de ce cache est levé et affiché à l'utilisateur. Parce que le navigateur peut décider d'effacer ce cache s'il manque de mémoire. Parce que l'utilisateur peut fermer le navigateur et ne naviguer nulle part. N'oubliez pas cela.

Caractéristiques d'implémentation

J'ai commencé à approfondir la documentation, à rechercher comment vivre avec ces connaissances. Étonnamment, la documentation était. Autrement dit, vous pouvez trouver sur Internet une description du fonctionnement de bfcache dans les navigateurs. Mais, plus je lis, plus les différences s'accumulent entre les différents navigateurs.

Dans l'un, ça marche comme ça, dans l'autre ça marche. Dans l'un, l'un interfère, l'autre n'interfère pas. Les développeurs ne savent pas comment traiter correctement un certain nombre d'API lors du placement d'une page dans bfcache. Ils disent: ok, si la page utilise cette API, je l'ignore, je ne la mets en aucun cas dans le cache. Et cette liste est différente selon les navigateurs, chacun fait ce qui lui convient.

Et puis j'ai commencé à combiner ce que j'ai appris en une seule table. J'ai quelque chose comme ceci:

J'ai lu la documentation des navigateurs - pour Firefox, Safari, la famille Chromium. Il y avait de la documentation disponible sur IE, bien que dépassée. Nous programmeurs n'aimons pas mettre à jour la documentation après des changements dans le navigateur? Quand j'ai réalisé que les informations étaient obsolètes, j'ai commencé à tester mes petites pages dans les navigateurs et à vérifier quelle API fonctionnait et laquelle ne fonctionnait pas.

Cela ne suffisait pas non plus: je ne sais pas quelles API examiner en principe, mais pas pour tout trier du tout? Et j'ai dû examiner le code source des moteurs de navigateur eux-mêmes, c'est-à-dire que le code s'est avéré être la source de connaissances la plus précise et la plus fiable. Pour le moment, cette plaque (devant vous en est une partie, voici un lien vers la version complète) est la collection la plus complète de connaissances sur les API qui autorisent ou interdisent à bfcache de fonctionner dans les navigateurs.

Les API qui n'interfèrent pas avec une coche et une couleur verte, celles qui empêcheront définitivement la page d'entrer dans bfcache sont marquées en rouge. Les champs blancs sont des espaces qui ne sont décrits nulle part.

Firefox

Voici quelques détails intéressants de navigateurs spécifiques. Je vais commencer par Firefox, il a été le premier à tout faire.

^{_{Lien depuis la diapositive}}

La chose la plus importante que j'ai apprise des sources de Firefox est que lorsque vous travaillez avec bfcache, il peut écrire dans le journal de texte sur le disque toutes les raisons pour lesquelles il ne peut pas mettre la page dans le cache.

^{_{Lien depuis la diapositive}}

Et j'ai même réussi à savoir comment le faire. Il y a deux variables d'environnement secrètes: dans l'une, nous indiquons ce qu'il faut enregistrer, dans la seconde - dans quel fichier écrire un journal. Après cela, nous lançons le binaire, et le tour est joué! Nous verrons approximativement que sur la diapositive précédente, les lignes du formulaire «un tel html ne peut pas être mis en cache pour une telle raison, telle pour une autre raison». Nous pouvons le lire tout de suite, très pratique.

Si vous souhaitez tester une fois, vous pouvez ouvrir la page about: networking dans Firefox. Là, vous pouvez entrer les mêmes champs dans la section "Journal". Nous pouvons indiquer dans deux champs quoi et où se connecter, et avec les boutons démarrer et arrêter le journal.

^{_{Lien depuis la diapositive}}

Quand Firefox refuse-t-il de mettre en cache la page? Si vous avez des demandes incomplètes, y compris des demandes AJAX ou des demandes de ressources telles que des images, alors il refusera de mettre la page en bfcache. Il pense que ce n'est pas terminé, n'a pas fini de télécharger, il y a une sorte d'activité suspecte. Mais tout cela ne s'applique pas au favicon. Si vous avez oublié le favicon, s'il ne se charge pas, il pense - d'accord, il le fera, c'est normal pour votre site.

Si vous avez un script de longue durée, le navigateur vous demandera: comme cela prend du temps, bloque l'interface utilisateur, peut-être le battre? Et si vous êtes d'accord, une telle page est considérée comme un peu fausse et nous ne la mettons pas en cache.

Si vous utilisez IndexedDB ... Ceci est une histoire instructive. Auparavant, dans la première implémentation, ils avaient l'air: si vous avez IndexedDB et qu'il y a une transaction incomplète, alors une telle page n'est pas mise en cache, car il n'est pas clair comment travailler avec elle (nous essayons de la cacher en plein milieu de la transaction). Mais ils ont simplement perdu ce morceau de code lors de la refactorisation. Et comme vous pouvez l'imaginer, ils n'avaient pas de tests pour cela. Ils ont même un bug dans le bugtracker. Il a déjà deux ans avec quelque chose. Les gens ont écrit: "Mon bfcache avec IndexedDB ne fonctionne pas correctement, que dois-je faire?" Les développeurs de Firefox ont répondu - il tombe vraiment en panne, nous venons de perdre ce morceau de texte lors du refactoring, d'accord, laissez-le continuer. Moralité: écrivez des tests, même si vous écrivez Firefox, sinon tout peut malheureusement se terminer.

Et un autre facteur intéressant de non-disponibilité dans bfcache - si le contenu mixte est explicitement autorisé. Ce que c'est?

^{_{Lien depuis la diapositive}}

Supposons que votre page s'ouvre via HTTPS, mais que vous chargez toujours certaines ressources via HTTP, en particulier des scripts. Autrement dit, vous avez un script non sécurisé, il peut être modifié par n'importe qui.

^{_{Lien à partir de la diapositive}}

Par défaut, Firefox, comme les autres navigateurs, n'exécute pas un tel script sans sécurité maintenant. Mais si c'est très important pour vous, vous êtes monté dans les paramètres et avez autorisé son exécution, puis, en conséquence, il ne mettra pas en cache une telle page. Il dira - eh bien, vous m'avez dit de ne pas exécuter le code, mais non, non!

Un autre ajustement est la taille de bfcache lui-même. Ici, la valeur par défaut est moins un. Cela signifie la quantité de mémoire de Firefox, autant de pages qu'il tente de mettre en cache. Mais nous pouvons forcer la désactivation du cache en mettant un zéro ou en définissant explicitement un nombre - par exemple, n'oubliez pas plus de cinq pages.

Avertissement: la diapositive suivante contient un exemple de code dans le langage effrayant C ++, cela peut être dangereux lors d'une conférence front-end. N'essayez pas de le copier, exécutez-le dans la console du navigateur. Votre disque peut être formaté, l'écran peut exploser ou des bitcoins peuvent être extraits. Je t'avais prévenu.

^{_{Lien depuis la diapositive}}

Donc, le code Gecko. Il peut être ouvert, lu, consulté gratuitement sur Internet. Et j'ai fouillé. Il existe la méthode la plus importante - CanSavePresentation (), elle répond à la question: est-il possible de mettre en cache ce document? Autrement dit, c'est la source ultime de vérité sur ce qui est maintenant implémenté dans Firefox. Et pourtant - c'est à partir de là que j'ai appris que vous pouvez lire le journal. Il existe une telle variable - gPageCacheLog. Ceci est le journal dans lequel tout est écrit. Voici une histoire tellement intéressante sur une excursion en C ++.

C'est-à-dire que vous ouvrez le lien, regardez le code, recherchez (il y a une recherche pratique et, en plus, rapide) et vous pouvez trouver les détails d'implémentation réels dans la dernière version du navigateur - ceux qui manquent simplement dans la documentation.

Safari

La chose la plus cruelle que fait Safari lorsqu'une page apparaît sur bfcache: si vous avez des demandes AJAX en attente, Safari les tue.

Même si vous les superposez avec des gestionnaires d'erreurs et essayez de tout vérifier, corrigez-le - il semble que la demande n'existe pas du tout. Après avoir récupéré de bfcache, vous n'aurez aucune erreur, aucun «OK», rien du tout.

Les gestionnaires de pageshow pagehide, comme je l'ai dit, dans Safari ne sont appelés que s'ils sont écrits dans un script en ligne dans la page. À partir d'un script externe, ils peuvent ou non fonctionner - quelle chance. Mais je vous ai prévenu.

Autre différence intéressante: les gestionnaires beforeunload et unload n'interfèrent pas avec l'entrée de la page dans bfcache. Dans ce cas, beforeunload est toujours appelé, et quand il entre dans le cache, et lorsqu'il n'est pas touché. Mais décharger lorsque la page atteint le cache n'est pas appelé. Et voici un autre rake localisé: la page peut aller dans le cache et ne jamais en apparaître, et si vous avez écrit un code important en déchargement, il ne sera jamais appelé, bien qu'aucune erreur ne se soit produite sur la page. Autrement dit, il est allé correctement dans le cache, et de là vers nulle part, et votre déchargement ne sera jamais appelé.

Un autre point intéressant. Comme vous le savez, vous pouvez ouvrir plusieurs fenêtres via window.open (). Et en même temps, ces fenêtres ont des liens entre elles. Autrement dit, ils peuvent simultanément grimper dans la fenêtre de l'autre, lire / écrire différentes propriétés. Cette ouverture des fenêtres enfants n'interfère pas avec bfcache. Et ici, très probablement, Safari est tout aussi cruel qu'avec les demandes AJAX, c'est-à-dire que tout se déchire et au revoir. Les développeurs d'Apple l'aiment plus.

Encore une minute en C ++! Les sources WebKit ne sont pas non plus secrètes, elles peuvent également être ouvertes, lues et étudiées.

^{_{Lien depuis la diapositive}}

Ils sont sur GitHub, là j'ai mis en évidence deux fonctions importantes:

- canCacheFrame () - vérifier si ce cadre peut être mis en cache.
- Dans différents objets de la page, tels qu'un élément HTML ou une police, il existe des méthodes canSuspendForDocumentSuspension (). Cet objet est responsable de savoir s'il peut mettre en cache, geler ou non.

Et un autre aspect important: WebKit propose des tests très pratiques. Là, directement dans le dossier LayoutTests / fast / history, sous la forme d'un petit html concis et compact, il y a des tests pour le travail de différentes API qui sont implémentées dans Safari avec bfcache. Ceci est un exemple vivant de la façon dont vous pouvez écrire du code dans Safari avec ces API et comment elles affectent ou non si elles autorisent ou non les hits bfcache. Très intéressant à voir.

De là, j'ai appris que Safari écrit également toutes ses connaissances sur bfcache, toutes les fonctionnalités, dans un journal de texte. Mais, malheureusement, je n'ai jamais découvert comment activer cette journalisation ou, si elle est activée, où trouver ce fichier sur le disque. Si quelqu'un le sait, dites-moi, je vous en serai très reconnaissant.

Chrome.

Comme je l'ai déjà dit, il y a encore du travail en cours, tout est fermé sous le drapeau. Vous pouvez télécharger le nouveau Chrome Canary, allez aux drapeaux. Le réglage y est caché - vous pouvez essayer de jouer avec. Vous pourriez voir quelque chose.

De l'intéressant - j'ai déjà parlé d'ouvrir une page via window.open (). Dans Chromium, ces pages ne sont pas mises en cache jusqu'à présent. Ils n'ont pas compris comment résoudre correctement tout cela, et l'ont coupé sans vergogne, car dans Safari, leur conscience ne le leur permet pas.

Si DOMContentLoaded ne se produit pas, la page ne sera pas non plus mise en cache.

Il existe de nombreuses nouvelles API qui commencent par «Web» - elles sont également difficiles et incompréhensibles avec elles, et jusqu'à présent, toutes désactivent bfcache par défaut. Autrement dit, si quelque chose de branché, de nouveau est utilisé sur la page, comme WebGL, WebVR, WebUSB, WebBluetooth, etc., une telle page n'entrera pas dans bfcache.

Travailleur de service. De plus, nous ne mettons pas encore en cache une telle page, mais nous prévoyons de la traiter correctement, de la cacher aux yeux vigilants du technicien de service.

Si la géolocalisation est activée, nous ne la mettons pas encore en cache. Si simple pour l'instant.

Si pendant le temps où la page était dans le cache, les cookies étaient pourris, nous pensons qu'une sorte d'autorisation a expiré. C'était peut-être des services bancaires en ligne ou autre chose. Cela signifie que la page n'est plus valide - nous la supprimons du cache.

^{_{Lien depuis la diapositive}}

Les gars de Google sont allés encore plus loin. Ils ont suggéré que nous unifions tout formaliser, unifier dans tous les navigateurs, a proposé une spécification du cycle de vie des pages pour tous les états, a suggéré d'ajouter de nouveaux événements aux transitions entre les différents états. Vous pouvez regarder le lien qu'ils ont pensé là-haut.

^{_{Lien depuis la diapositive}}

Sources. Comme vous le savez, des sources de chrome sont également disponibles. Tout cela réside dans une classe appelée BackForwardCacheImpl - très bonne dénomination, n'a presque pas eu à chercher. La principale méthode qui vérifie si un document peut être enregistré s'appelle CanStoreDocument (). Il existe également une méthode GetDisallowedFeatures (), qui répertorie simplement toutes les nouvelles fonctionnalités et API qui ne sont pas prises en charge dans bfcache. Très pratique: concentré en un seul endroit, lu et réalisé ce qui est actuellement possible et ce qui ne peut pas être utilisé.

Internet Explorer 11

Une excursion dans l'histoire pour ceux qui ont encore IE 11. Pour ceux qui ont tout mal.

Il y a bfcache là, et c'est le principal problème, car il faut y faire face. La documentation indique que bfcache ne fonctionne que sur HTTP. En fait, en production, il fonctionne également sur HTTPS pour une raison quelconque. Moralité: si vous êtes développeur, faites attention à votre documentation. Ensuite, vous devez souffrir à cause d'elle.

S'il existe un gestionnaire beforeunload, il l'empêchera de pénétrer dans le cache. Ils n'ont rien dit au sujet du déchargement dans la documentation - peut-être qu'ils ne le savaient pas ou l'ont oublié.

Si la page n'a pas terminé son chargement, elle n'est pas non plus mise en cache. Si quelqu'un utilise des composants ActiveX, nous ne mettons pas non plus en cache. Et si DevTools y est également ouvert. C'est un point important.

Comment sans bugs? Champ persistant ajouté, mais parfois cela ne fonctionne pas. Autrement dit, la page pénètre vraiment dans le cache, en revient et persiste n'est pas définie sur true. Que faire?

Nous avions un beau code qui détermine si nous sommes revenus du cache ou rechargés depuis le serveur.

Maintenant, il devait être complété par une béquille pour IE. Nous déterminons que nous avons IE, et dans certaines solutions de contournement, nous comprenons que la page a néanmoins été extraite du cache et en même temps, nous avons eu une navigation dans l'historique (back_forward).

De plus, comment savoir si une page est mise en cache? Nous prenons son temps de chargement. S'il est chargé à partir du serveur en 50 millisecondes ou plus rapidement, cela ne peut pas être dans IE - cela signifie qu'il provient du cache! :)

J'ai déjà mentionné la navigation dans l'histoire. Si nous avons le type de navigation back_forward, alors nous avons parcouru l'historique, et si la page provient du cache, cela signifie bfcache, il n'y a pas d'autres options dans IE.

Et après?

Que faire ensuite avec cette connaissance? Je ne voudrais pas que vous sortiez et oubliez tout cela comme un cauchemar.

- Tout d'abord, voici la chose la plus précieuse que j'ai rencontrée et ce sur quoi je veux vous pousser: utilisez des navigateurs open source! Dans le libre accès à Internet en ce moment sont le code source de tous les principaux navigateurs que nos clients utilisent. Et c'est la documentation la plus pertinente sur comment et comment elle est prise en charge, où et comment cela fonctionne. Y compris il y a des tests qui sont directement écrits en HTML et JS. Utilisez, regardez!

- Deuxièmement, considérez dans les applications existantes qu'elles peuvent s'exécuter dans bfcache. Informez vos testeurs à ce sujet afin que lorsqu'ils vérifient la navigation, ils sachent que lors de la navigation dans l'historique, la page peut être ouverte à la fois depuis le serveur et depuis bfcache. Voici une vidéo du vrai bug que nous avons corrigé lorsque bfcache fonctionnait pour nous:

Ouvrir GIF

L'utilisateur entre quatre demandes, voit quatre problèmes. Après cela, il revient en arrière, voit le problème 3 et la requête 4. Un autre problème précédent est 2 et la requête 3. C'est-à-dire qu'il a un état incompatible de la page - le contenu de la recherche et les chaînes de recherche se contredisent. Gardez cela à l'esprit dans vos applications.

- Et troisièmement, si vous écrivez du nouveau code, pensez si vous avez besoin de bfcache. Si tel est le cas, utilisez le tableau de compatibilité des API. Sinon, ne l'utilisez pas, mais si vous entrez accidentellement dans bfcache, pensez aux fonctionnalités de Safari et des autres navigateurs que j'ai mentionnés. Certaines choses peuvent se déchirer insolemment et vous ne pourrez pas comprendre pourquoi cela se produit.

Comme promis, un lien vers les matériaux.

BFCache ou Là et retour. Rapport Yandex