Pourquoi les navigateurs produisent des résultats de performances différents —

je discutais avec DéboguerBoreilleest Matt Zeunert et, ce faisant, il a mentionné avec désinvolture cette chose appelée Mode serré en décrivant comment les navigateurs récupèrent et hiérarchisent les ressources. Je voulais hocher la tête comme si je savais de quoi il parlait, mais j’ai finalement dû demander : Qu’est-ce que c’est que le mode « Tight » ?

Ce que j’ai récupéré, ce sont deux artefacts, l’un d’eux étant la vidéo suivante de Robin Marx, expert en performances Web d’Akamai, s’exprimant à We Love Speed ​​en France il y a quelques semaines :

L’autre artefact est un document Google initialement publié par Patrick Meenan en 2015 mais mis à jour quelque peu récemment en novembre 2023. Le blog de Patrick est inactif depuis 2014, je vais donc simplement déposez un lien vers le document Google pour que vous puissiez le consulter.

C’est tout ce que j’ai et ce que je peux trouver sur le Web à propos de ce truc appelé Tight Mode qui semble avoir tellement d’influence sur le fonctionnement du Web. Robin a reconnu le manque d’informations à ce sujet dans sa présentation, et la quantité de recherches à la première personne dans son discours est remarquable et mérite d’être soulignée car elle tente de décrire et d’illustrer comment différents navigateurs récupèrent différentes ressources avec des priorités différentes. Compte tenu du manque de matériel sur le sujet, j’ai décidé de partager ce que j’ai pu retenir des recherches de Robin et de l’article mis à jour de Patrick.

C’est la première des deux phases

Le fait que la date de publication originale de Patrick tombe en 2015 ne surprend pas que nous parlons à ce stade de quelque chose qui date d’environ 10 ans. La mise à jour 2023 de la publication est déjà assez ancienne dans les « années Web », mais le mode serré n’est toujours nulle part lorsque j’essaie de la rechercher.

Alors, comment définissons-nous le mode serré ? Voici comment Patrick l’explique :

« Chrome charge les ressources en 2 phases. Le « mode serré » est la phase initiale et les contraintes [sic] charger des ressources de priorité inférieure jusqu’à ce que le corps soit attaché au document (essentiellement, après que tous les scripts de blocage dans l’en-tête ont été exécutés).

—Patrick Meenan

OK, nous avons donc ce processus en deux parties que Chrome utilise pour récupérer les ressources du réseau et la première partie se concentre sur tout ce qui n’est pas une « ressource de moindre priorité ». Nous avons des moyens d’indiquer aux navigateurs quelles ressources nous pensent qu’ils sont peu prioritaires sous la forme de Récupérer l’API prioritaire et des techniques de chargement paresseux qui chargent les ressources de manière asynchrone lorsqu’elles entrent dans la fenêtre lors du défilement – ce que Robin couvre dans sa présentation. Mais le mode Tight a sa propre façon de déterminer quelles ressources charger en premier.

Le mode serré discrimine les ressources, en prenant tout ce qui est marqué comme priorité élevée et moyenne. Tout le reste est contraint et laissé à l’extérieur, jusqu’à ce que le corps soit fermement attaché au document, signalant que des scripts de blocage ont été exécutés. C’est à ce moment-là que les ressources marquées d’une priorité faible sont autorisées à entrer dans la porte lors de la deuxième phase de chargement.

Il y a une grande mise en garde à cela, mais nous y arriverons. La chose importante à noter est que…

Chrome et Safari appliquent le mode strict

Oui, Chrome et Safari disposent tous deux d’une forme fonctionnelle de mode serré s’exécutant en arrière-plan. Cette dernière image illustre le mode serré de Chrome. Regardons ensuite celui de Safari et comparons les deux.

Regardez ça ! Safari discrimine les ressources hautement prioritaires lors de sa récupération initiale, tout comme Chrome, mais nous obtenons un comportement de chargement très différent entre les deux navigateurs. Remarquez comment Safari semble exclure les cinq premières images PNG marquées avec une priorité moyenne là où Chrome les autorise. En d’autres termes, Safari fait attendre toutes les ressources de priorité moyenne et faible jusqu’à ce que tous les éléments de priorité élevée soient chargés, même si nous travaillons avec exactement le même code HTML. Vous pourriez dire que le comportement de Safari est le plus logique, comme vous pouvez le voir sur cette dernière image que Chrome exclut apparemment certaines ressources hautement prioritaires du mode serré. Il y a clairement des folies qui se produisent là-bas et auxquelles nous reviendrons.

Où est Firefox dans tout ça ? Il ne prend aucune mesure de resserrement supplémentaire lors de l’évaluation de la priorité des ressources sur une page. Nous pourrions considérer cela comme l’approche « classique » en cascade pour récupérer et charger des ressources.

Chrome et Safari déclenchent le mode serré différemment

Robin le dit clairement dans son discours. Chrome et Safari sont tous deux partisans du mode serré, mais le déclenchent dans des circonstances différentes que nous pouvons décrire comme suit :

Notez que Chrome ne regarde que le document <head> lors de la priorisation des ressources, et seulement quand cela implique JavaScript. Safari, quant à lui, examine également JavaScript, mais également CSS, et partout où ces éléments peuvent se trouver dans le document, que ce soit dans le document ou non. <head> ou <body>. Cela aide à expliquer pourquoi Chrome exclut les images marquées comme haute priorité dans la figure 2 de son implémentation en mode serré : il ne se soucie que de JavaScript dans ce contexte.

Ainsi, même si Chrome rencontre un fichier de script avec fetchpriority="high" dans le corps du document, le fichier n’est pas considéré comme une priorité « élevée » et il sera chargé après le reste des éléments. Safari, quant à lui, à l’honneur fetchpriority n’importe où dans le document. Cela aide à expliquer pourquoi Chrome laisse deux scripts sur la table, pour ainsi dire, dans la figure 2, alors que Safari semble les charger en mode Tight.

Cela ne veut pas dire que Safari ne fait rien de bizarre dans son processus. Étant donné le balisage suivant :

<head>
  <!-- two high-priority scripts -->
  <script src="https://smashingmagazine.com/2025/01/tight-mode-why-browsers-produce-different-performance-results/script-1.js"></script>
  <script src="https://smashingmagazine.com/2025/01/tight-mode-why-browsers-produce-different-performance-results/script-1.js"></script>

  <!-- two low-priority scripts -->
  <script src="script-3.js" defer></script>
  <script src="script-4.js" defer></script>
</head>
<body>
  <!-- five low-priority scripts -->
  <img src="image-1.jpg">
  <img src="image-2.jpg">
  <img src="image-3.jpg">
  <img src="image-4.jpg">
  <img src="image-5.jpg">
</body>

… vous pourriez vous attendre à ce que Safari retarde les deux scripts de faible priorité dans le <head> jusqu’à ce que les cinq images dans le <body> sont téléchargés. Mais ce n’est pas le cas. Au lieu de cela, Safari charge ces deux scripts lors de sa version du mode serré.

Exceptions pour Chrome et Safari

J’ai mentionné plus tôt que les ressources à faible priorité sont chargées au cours de la deuxième phase de chargement une fois le mode serré terminé. Mais j’ai également mentionné qu’il y avait une grande mise en garde concernant ce comportement. Parlons-en maintenant.

D’après l’article de Patrick, nous savons que le mode serré est « la phase initiale et les contraintes de chargement des ressources de moindre priorité jusqu’à ce que le corps soit attaché au document (essentiellement, après que tous les scripts de blocage dans l’en-tête ont été exécutés). » Mais il y a une deuxième partie de cette définition que j’ai laissée de côté :

« En mode serré, les ressources faiblement prioritaires ne sont chargées que s’il y a moins de deux requêtes en cours au moment où elles sont découvertes. »

A-ha! Alors là est un moyen pour les ressources de faible priorité de se charger en mode serré. C’est lorsqu’il y a moins de deux demandes « en cours » lorsqu’elles sont détectées.

Attendez, que signifie « en vol » ?

C’est ce que l’on entend par moins de deux éléments de priorité élevée ou moyenne demandés. Robin le démontre en comparant Chrome à Safari dans les mêmes conditions, où il n’y a que deux scripts haute priorité et dix images normales dans le mélange :

<head>
  <!-- two high-priority scripts -->
  <script src="https://smashingmagazine.com/2025/01/tight-mode-why-browsers-produce-different-performance-results/script-1.js"></script>
  <script src="https://smashingmagazine.com/2025/01/tight-mode-why-browsers-produce-different-performance-results/script-1.js"></script>
</head>
<body>
  <!-- ten low-priority images -->
  <img src="image-1.jpg">
  <img src="image-2.jpg">
  <img src="image-3.jpg">
  <img src="image-4.jpg">
  <img src="image-5.jpg">
  <!-- rest of images -->
  <img src="image-10.jpg">
</body>

Regardons d’abord ce que fait Safari, car c’est l’approche la plus simple :

Rien de bien compliqué là-dedans, non ? Les deux scripts haute priorité sont téléchargés en premier et les 10 images arrivent juste après. Regardons maintenant Chrome :

Les deux scripts haute priorité sont chargés en premier, comme prévu. Mais Chrome décide ensuite d’autoriser les cinq premières images avec une priorité moyenne, puis exclut les cinq dernières images avec une priorité faible. Quoi. Le. Zut.

La raison est noble : Chrome souhaite charger les cinq premières images car, vraisemblablement, La plus grande peinture de contenu (LCP) sera souvent l’une de ces images et Chrome parie que le Web sera globalement plus rapide s’il gère automatiquement une partie de cette logique. Encore une fois, c’est un raisonnement noble, même s’il n’est pas précis à 100 %. Cependant, cela brouille les cartes et rend la compréhension du mode strict beaucoup plus difficile lorsque nous voyons des éléments de priorité moyenne et faible traités comme des citoyens de haute priorité.

Ce qui est encore plus confus, c’est que Chrome semble n’accepter que jusqu’à deux ressources de priorité moyenne dans ce processus discriminatoire. Les autres sont marqués d’une priorité faible.

C’est ce que nous entendons par « moins de deux demandes en vol ». Si Chrome constate que seuls un ou deux éléments entrent en mode restreint, alors il donne automatiquement la priorité aux cinq premières images non critiques dans le cadre d’un effort d’optimisation du LCP.

À vrai dire, Safari fait quelque chose de similaire, mais dans un contexte différent. Au lieu d’accepter les éléments de faible priorité lorsqu’il y a moins de deux demandes en cours, Safari accepte les éléments de priorité moyenne et faible en mode strict et depuis n’importe où dans le document, qu’ils se trouvent ou non dans le <head> ou non. L’exception concerne tout script asynchrone ou différé car, comme nous l’avons vu précédemment, ceux-ci sont de toute façon chargés immédiatement.

Comment manipuler le mode serré

Cela pourrait constituer un excellent article de suivi, mais c’est ici que je vous renvoie directement à la vidéo de Robin, car ses recherches à la première personne méritent d’être consommées directement. Mais voici l’essentiel :

• Nous disposons de fonctionnalités de haut niveau qui peuvent aider à influencer la priorité, notamment conseils sur les ressources (c’est-à-dire preload et preconnect), le Récupérer l’API prioritaireet techniques de chargement paresseux.
• Nous pouvons indiquer fetchpriority="high" et fetchpriority="low" sur les articles.

<img src="https://smashingmagazine.com/2025/01/tight-mode-why-browsers-produce-different-performance-results/lcp-image.jpg" fetchpriority="high">
<link rel="preload" href="defer.js" as="script" fetchpriority="low"

• En utilisant fetchpriority="high" est un moyen de réduire les éléments dans la source incluse dans le mode serré. En utilisant fetchpriority="low est un moyen d’obtenir des éléments plus élevés dans la source exclus du mode serré.
• Pour Chrome, cela fonctionne sur les images, les scripts asynchrones/différés et les scripts situés en bas de l’écran. <body>.
• Pour Safari, cela ne fonctionne que sur les images.

Encore une fois, regardez le discours de Robin pour l’histoire complète à partir de 28h32 environ.

C’est serré… Mode

C’est dingue pour moi qu’il y ait si peu d’informations sur le mode serré qui circulent sur le Web. Je m’attendrais à ce que quelque chose comme ça soit bien documenté quelque part, certainement chez Chrome Developers ou quelque part similaire, mais tout ce que nous avons est un document Google léger et une présentation approfondie pour brosser un tableau de la façon dont deux des trois principaux navigateurs récupèrent et hiérarchisent. ressources. Faites-moi savoir si vous avez des informations supplémentaires que vous avez publiées ou trouvées – j’aimerais les inclure dans la discussion.

(ouais)