Ne luttez pas contre l'analyse du préchargement du navigateur

Découvrez ce qu'est l'outil d'analyse du préchargement du navigateur, comment il améliore les performances et comment l'éviter.

Un aspect négligé de l'optimisation de la vitesse de chargement des pages consiste à connaître un peu le fonctionnement interne des navigateurs. Les navigateurs effectuent certaines optimisations pour améliorer les performances d'une manière que nous, en tant que développeurs, ne pouvons pas faire, mais seulement tant que ces optimisations ne sont pas bloquées par inadvertance.

L'optimisation interne du navigateur à comprendre est le scanner de précharge du navigateur. Cet article explique le fonctionnement du scanner de préchargement et, surtout, comment éviter de l'entraver.

Qu'est-ce qu'un analyseur de préchargement ?

Chaque navigateur dispose d'un analyseur HTML principal qui tokenize le balisage brut et le transforme en modèle d'objet. Tout cela se passe sans problème jusqu'à ce que l'analyseur s'arrête lorsqu'il trouve une ressource bloquante, telle qu'une feuille de style chargée avec un élément <link> ou un script chargé avec un élément <script> sans attribut async ou defer.

Schéma de l&#39;analyseur HTML.
Fig. 1:Schéma illustrant comment l'analyseur HTML principal du navigateur peut être bloqué. Dans ce cas, l'analyseur rencontre un élément <link> pour un fichier CSS externe, ce qui empêche le navigateur d'analyser le reste du document (et même de l'afficher) tant que le CSS n'est pas téléchargé et analysé.

Dans le cas des fichiers CSS, le rendu est bloqué pour éviter un flash de contenu sans style (FOUC), c'est-à-dire lorsqu'une version sans style d'une page peut être vue brièvement avant que des styles ne lui soient appliqués.

Page d&#39;accueil de web.dev sans style (à gauche) et avec style (à droite).
Fig. 2:Exemple simulé de FOUC. À gauche se trouve la page d'accueil de web.dev sans styles. À droite, vous pouvez voir la même page avec des styles appliqués. L'état sans style peut se produire en un clin d'œil si le navigateur ne bloque pas le rendu pendant le téléchargement et le traitement d'une feuille de style.

Le navigateur bloque également l'analyse et le rendu de la page lorsqu'il rencontre des éléments <script> sans attribut defer ou async.

En effet, le navigateur ne peut pas savoir avec certitude si un script donné modifiera le DOM pendant que l'analyseur HTML principal effectue son travail. C'est pourquoi il est courant de charger votre code JavaScript à la fin du document afin que les effets de l'analyse et de l'affichage bloqués deviennent marginaux.

C'est pourquoi le navigateur doit bloquer à la fois l'analyse et l'affichage. Toutefois, il est déconseillé de bloquer l'une de ces étapes importantes, car elles peuvent retarder la découverte d'autres ressources importantes. Heureusement, les navigateurs font de leur mieux pour atténuer ces problèmes à l'aide d'un analyseur HTML secondaire appelé analyseur de préchargement.

Schéma de l&#39;analyseur HTML principal (à gauche) et du scanner de préchargement (à droite), qui est l&#39;analyseur HTML secondaire.
Fig. 3:diagramme illustrant le fonctionnement du scanner de précharge en parallèle avec l'analyseur HTML principal pour charger de manière spéculative des éléments. Ici, l'analyseur HTML principal est bloqué, car il charge et traite le CSS avant de pouvoir commencer à traiter le balisage d'image dans l'élément <body>. Toutefois, le scanner de préchargement peut regarder à l'avance dans le balisage brut pour trouver cette ressource d'image et commencer à la charger avant que l'analyseur HTML principal ne soit débloqué.

Le rôle d'un analyseur de préchargement est spéculatif, ce qui signifie qu'il examine le balisage brut afin de trouver des ressources à extraire de manière opportuniste avant que l'analyseur HTML principal ne les découvre.

Savoir quand l'outil d'analyse de préchargement fonctionne

L'outil d'analyse de préchargement existe parce que le rendu et l'analyse sont bloqués. Si ces deux problèmes de performances n'avaient jamais existé, l'outil d'analyse du préchargement ne serait pas très utile. Pour déterminer si une page Web bénéficie du scanner de préchargement, il est essentiel de tenir compte de ces phénomènes de blocage. Pour ce faire, vous pouvez ajouter un délai artificiel aux requêtes afin de déterminer où le scanner de préchargement fonctionne.

Prenons l'exemple de cette page de texte et d'images de base avec une feuille de style. Étant donné que les fichiers CSS bloquent à la fois l'affichage et l'analyse, vous introduisez un délai artificiel de deux secondes pour la feuille de style via un service proxy. Ce délai permet de voir plus facilement dans la cascade du réseau où le scanner de préchargement fonctionne.

Le graphique en cascade du réseau WebPageTest illustre un retard artificiel de deux secondes imposé à la feuille de style.
Fig. 4:Graphique en cascade de réseau WebPageTest d'une page Web exécutée sur Chrome sur un appareil mobile via une connexion 3G simulée. Même si la feuille de style est retardée artificiellement de deux secondes via un proxy avant de commencer à se charger, l'image située plus loin dans la charge utile de balisage est détectée par l'outil d'analyse de préchargement.

Comme vous pouvez le voir dans la cascade, le scanner de préchargement détecte l'élément <img> même lorsque l'affichage et l'analyse des documents sont bloqués. Sans cette optimisation, le navigateur ne peut pas récupérer des éléments de manière opportuniste pendant la période de blocage, et un plus grand nombre de requêtes de ressources seraient consécutives plutôt que simultanées.

Maintenant que cet exemple fictif est terminé, examinons quelques exemples concrets où le scanner de préchargement peut être contourné, et ce que vous pouvez faire pour y remédier.

Scripts async injectés

Imaginons que votre <head> contienne du code HTML incluant du code JavaScript intégré, comme suit:

<script>
 
const scriptEl = document.createElement('script');
  scriptEl
.src = '/yall.min.js';

  document
.head.appendChild(scriptEl);
</script>

Les scripts injectés sont async par défaut. Par conséquent, lorsqu'ils sont injectés, ils se comportent comme si l'attribut async leur était appliqué. Cela signifie qu'il s'exécutera dès que possible et qu'il ne bloquera pas le rendu. C'est l'idéal, n'est-ce pas ? Toutefois, si vous présumez que cet élément <script> intégré vient après un élément <link> qui charge un fichier CSS externe, vous obtiendrez un résultat non optimal:

Ce graphique WebPageTest montre que l&#39;analyse de préchargement est contournée lorsqu&#39;un script est injecté.
Figure 5:graphique en cascade du réseau WebPageTest d'une page Web exécutée sur Chrome sur un appareil mobile via une connexion 3G simulée. La page contient une seule feuille de style et un script async injecté. Le scanner de préchargement ne peut pas détecter le script pendant la phase de blocage de l'affichage, car il est injecté sur le client.

Voyons ce qui s'est passé:

  1. À 0 seconde, le document principal est demandé.
  2. À 1,4 seconde, le premier octet de la requête de navigation arrive.
  3. À 2,0 secondes, le CSS et l'image sont demandés.
  4. Étant donné que l'analyseur est bloqué par le chargement de la feuille de style et que le code JavaScript intégré qui injecte le script async vient après cette feuille de style, à 2,6 secondes, la fonctionnalité fournie par le script n'est pas disponible dès que possible.

Ce n'est pas optimal, car la requête du script ne se produit qu'après le téléchargement de la feuille de style. Cela retarde l'exécution du script dès que possible. En revanche, comme l'élément <img> est détectable dans le balisage fourni par le serveur, il est détecté par l'explorateur de préchargement.

Que se passe-t-il si vous utilisez une balise <script> standard avec l'attribut async au lieu d'injecter le script dans le DOM ?

<script src="/yall.min.js" async></script>

Vous obtenez le résultat suivant:

Cascade de réseau WebPageTest montrant comment un script asynchrone chargé à l&#39;aide de l&#39;élément de script HTML est toujours détectable par le scanner de préchargement du navigateur, même si l&#39;analyseur HTML principal du navigateur est bloqué lors du téléchargement et du traitement d&#39;une feuille de style.
Figure 6:graphique en cascade du réseau WebPageTest d'une page Web exécutée sur Chrome sur un appareil mobile via une connexion 3G simulée. La page contient une seule feuille de style et un seul élément <script> async. Le scanner de préchargement détecte le script pendant la phase de blocage de l'affichage et le charge en même temps que le CSS.

Vous pourriez être tenté de suggérer que ces problèmes pourraient être résolus à l'aide de rel=preload. Cela fonctionnerait certainement, mais cela pourrait avoir des effets secondaires. Après tout, pourquoi utiliser rel=preload pour résoudre un problème qui peut être évité en n'injectant pas d'élément <script> dans le DOM ?

Cascade WebPageTest montrant comment l&#39;indice de ressource rel=preload est utilisé pour favoriser la découverte d&#39;un script injecté asynchrone, bien que cela puisse avoir des effets secondaires involontaires.
Fig. 7:graphique en cascade du réseau WebPageTest d'une page Web exécutée sur Chrome sur un appareil mobile via une connexion 3G simulée. La page contient une seule feuille de style et un script async injecté, mais le script async est préchargé pour s'assurer qu'il est découvert plus tôt.

Le préchargement "résout" le problème ici, mais il en crée un autre: le script async des deux premières démonstrations, bien qu'il soit chargé dans le <head>, est chargé avec une priorité "Faible", tandis que la feuille de style est chargée avec une priorité "Élevée". Dans la dernière démonstration où le script async est préchargé, la feuille de style est toujours chargée avec la priorité "Élevée", mais la priorité du script a été définie sur "Élevée".

Lorsque la priorité d'une ressource est élevée, le navigateur lui alloue plus de bande passante. Cela signifie que, même si la feuille de style a la priorité la plus élevée, la priorité élevée du script peut entraîner un conflit de bande passante. Cela peut être un facteur dans les cas de connexions lentes ou lorsque les ressources sont très volumineuses.

La réponse est simple: si un script est nécessaire au démarrage, ne contournez pas le scanner de préchargement en l'injectant dans le DOM. Testez si nécessaire l'emplacement des éléments <script>, ainsi que les attributs tels que defer et async.

Chargement différé avec JavaScript

Le chargement paresseux est une excellente méthode de conservation des données, souvent appliquée aux images. Cependant, le chargement paresseux est parfois appliqué de manière incorrecte aux images qui se trouvent "au-dessus de la ligne de flottaison", pour ainsi dire.

Cela peut entraîner des problèmes potentiels de visibilité des ressources pour l'outil d'analyse de préchargement et retarder inutilement la découverte d'une référence à une image, son téléchargement, son décodage et sa présentation. Prenons cet exemple de balisage d'image:

<img data-src="/sand-wasp.jpg" alt="Sand Wasp" width="384" height="255">

L'utilisation d'un préfixe data- est un modèle courant dans les chargeurs paresseux JavaScript. Lorsque l'image est défilée dans le viewport, le chargeur paresseux supprime le préfixe data-. Par conséquent, dans l'exemple précédent, data-src devient src. Cette mise à jour invite le navigateur à récupérer la ressource.

Ce modèle ne pose pas de problème tant qu'il n'est pas appliqué aux images qui se trouvent dans le viewport au démarrage. Étant donné que le lecteur de préchargement ne lit pas l'attribut data-src de la même manière qu'un attribut src (ou srcset), la référence de l'image n'est pas découverte plus tôt. Pire encore, le chargement de l'image est retardé jusqu'à après le téléchargement, la compilation et l'exécution du code JavaScript du chargeur paresseux.

Graphique en cascade du réseau WebPageTest montrant comment une image chargée de manière différée qui se trouve dans le viewport au démarrage est nécessairement retardée, car le scanner de préchargement du navigateur ne parvient pas à trouver la ressource d&#39;image et ne se charge que lorsque le code JavaScript requis pour le chargement différé fonctionne. L&#39;image est découverte bien plus tard que prévu.
Fig. 8:graphique en cascade du réseau WebPageTest d'une page Web exécutée sur Chrome sur un appareil mobile via une connexion 3G simulée. La ressource d'image est chargée de manière inutile, même si elle est visible dans la fenêtre d'affichage au démarrage. Cela annule le scanner de préchargement et entraîne un retard inutile.

Selon la taille de l'image (qui peut dépendre de la taille de la fenêtre d'affichage), elle peut être un élément candidat pour le Largest Contentful Paint (LCP). Lorsque le scanner de préchargement ne peut pas récupérer de manière spéculative la ressource d'image à l'avance(peut-être au moment où les feuilles de style de la page bloquent le rendu), le LCP en souffre.

La solution consiste à modifier la balise de l'image:

<img src="/sand-wasp.jpg" alt="Sand Wasp" width="384" height="255">

Il s'agit du modèle optimal pour les images qui se trouvent dans le viewport au démarrage, car le scanner de préchargement découvrira et récupérera la ressource d'image plus rapidement.

Graphique en cascade du réseau WebPageTest illustrant un scénario de chargement d&#39;une image dans le viewport au démarrage. L&#39;image n&#39;est pas chargée de manière paresseuse, ce qui signifie qu&#39;elle n&#39;est pas dépendante du script pour être chargée. Par conséquent, l&#39;outil d&#39;analyse de préchargement peut la découvrir plus tôt.
Fig. 9:graphique en cascade du réseau WebPageTest d'une page Web exécutée sur Chrome sur un appareil mobile via une connexion 3G simulée. Le scanner de préchargement détecte la ressource image avant le début du chargement du CSS et du JavaScript, ce qui donne au navigateur un avantage pour le charger.

Dans cet exemple simplifié, le résultat est une amélioration de 100 millisecondes du LCP sur une connexion lente. Cela peut ne pas sembler être une amélioration majeure, mais c'est le cas si vous considérez que la solution consiste à corriger rapidement la balise et que la plupart des pages Web sont plus complexes que cet ensemble d'exemples. Cela signifie que les candidats au LCP peuvent devoir se battre pour la bande passante avec de nombreuses autres ressources. Par conséquent, des optimisations comme celle-ci deviennent de plus en plus importantes.

Images de fond CSS

N'oubliez pas que le scanner de préchargement du navigateur analyse la mise en forme. Il n'analyse pas d'autres types de ressources, comme les CSS, qui peuvent impliquer des récupérations d'images référencées par la propriété background-image.

Comme pour le code HTML, les navigateurs traitent le code CSS dans leur propre modèle d'objets, appelé CSSOM. Si des ressources externes sont détectées lors de la création du CSSOM, elles sont demandées au moment de la détection, et non par l'explorateur de préchargement.

Imaginons que le candidat au LCP de votre page soit un élément avec une propriété CSS background-image. Voici ce qui se passe lorsque les ressources sont chargées:

Graphique en cascade du réseau WebPageTest représentant une page avec un candidat LCP chargé à partir de CSS à l&#39;aide de la propriété background-image. Étant donné que l&#39;image candidate du LCP se trouve dans un type de ressource que le scanner de préchargement du navigateur ne peut pas examiner, le chargement de la ressource est retardé jusqu&#39;à ce que le CSS soit téléchargé et traité, ce qui retarde le temps de peinture du candidat au LCP.
Fig. 10:graphique en cascade du réseau WebPageTest d'une page Web exécutée sur Chrome sur un appareil mobile via une connexion 3G simulée. Le candidat au LCP de la page est un élément avec une propriété CSS background-image (ligne 3). L'image qu'il demande ne commence à être extraite que lorsque l'analyseur CSS la trouve.

Dans ce cas, le scanner de préchargement n'est pas tant contourné que non impliqué. Toutefois, si un candidat au LCP sur la page provient d'une propriété CSS background-image, vous devez précharger cette image:

<!-- Make sure this is in the <head> below any
     stylesheets, so as not to block them from loading -->

<link rel="preload" as="image" href="lcp-image.jpg">

Cette information rel=preload est petite, mais elle aide le navigateur à découvrir l'image plus tôt qu'il ne le ferait autrement:

Graphique en cascade du réseau WebPageTest montrant qu&#39;une image de fond CSS (qui est le candidat au LCP) se charge beaucoup plus tôt grâce à l&#39;utilisation d&#39;un indice rel=preload. Le temps LCP s&#39;améliore d&#39;environ 250 millisecondes.
Fig. 11:graphique en cascade du réseau WebPageTest d'une page Web exécutée sur Chrome sur un appareil mobile via une connexion 3G simulée. Le candidat au LCP de la page est un élément avec une propriété CSS background-image (ligne 3). L'indice rel=preload aide le navigateur à découvrir l'image environ 250 millisecondes plus tôt que sans l'indice.

Avec l'indice rel=preload, le candidat au LCP est découvert plus tôt, ce qui réduit le temps de LCP. Bien que cette indication aide à résoudre ce problème, il est peut-être préférable d'évaluer si votre image candidate au LCP doit être chargée à partir du CSS. Avec une balise <img>, vous pouvez mieux contrôler le chargement d'une image adaptée au viewport, tout en permettant au scanner de préchargement de la découvrir.

Insérer trop de ressources

L'intégration consiste à placer une ressource dans le code HTML. Vous pouvez intégrer des feuilles de style dans des éléments <style>, des scripts dans des éléments <script> et pratiquement n'importe quelle autre ressource à l'aide de l'encodage Base64.

L'intégration de ressources peut être plus rapide que leur téléchargement, car aucune requête distincte n'est émise pour la ressource. Il se trouve dans le document et se charge instantanément. Cependant, cette approche présente des inconvénients importants:

  • Si vous ne mettez pas en cache votre code HTML (et vous ne pouvez pas le faire si la réponse HTML est dynamique), les ressources intégrées ne sont jamais mises en cache. Cela affecte les performances, car les ressources intégrées ne sont pas réutilisables.
  • Même si vous pouvez mettre en cache du code HTML, les ressources intégrées ne sont pas partagées entre les documents. Cela réduit l'efficacité de la mise en cache par rapport aux fichiers externes qui peuvent être mis en cache et réutilisés dans l'ensemble d'une origine.
  • Si vous insérez trop de contenu intégré, le scanner de préchargement est retardé dans la découverte des ressources plus loin dans le document, car le téléchargement de ce contenu supplémentaire intégré prend plus de temps.

Prenons cette page comme exemple. Dans certaines conditions, le candidat au LCP est l'image en haut de la page, et le CSS se trouve dans un fichier distinct chargé par un élément <link>. La page utilise également quatre polices Web qui sont demandées en tant que fichiers distincts de la ressource CSS.

Graphique en cascade du réseau WebPageTest d&#39;une page avec un fichier CSS externe contenant quatre polices référencées. L&#39;image candidate du LCP est découverte par le scanner de préchargement en temps voulu.
Figure 12:graphique en cascade du réseau WebPageTest d'une page Web exécutée sur Chrome sur un appareil mobile via une connexion 3G simulée. Le candidat LCP de la page est une image chargée à partir d'un élément <img>, mais il est détecté par l'outil d'analyse de préchargement, car le CSS et les polices requises pour le chargement de la page se trouvent dans des ressources distinctes, ce qui ne retarde pas l'outil d'analyse de préchargement dans l'exécution de sa tâche.

Que se passe-t-il si le CSS et toutes les polices sont intégrées en tant que ressources base64 ?

Graphique en cascade du réseau WebPageTest d&#39;une page avec un fichier CSS externe contenant quatre polices référencées. Le scanner de préchargement est retardé de manière significative lors de la découverte de l&#39;image LCP .
Figure 13:graphique en cascade du réseau WebPageTest d'une page Web exécutée sur Chrome sur un appareil mobile via une connexion 3G simulée. Le candidat LCP de la page est une image chargée à partir d'un élément <img>, mais l'intégration du CSS et de ses quatre ressources de police dans le "retarde la découverte de l'image par l'outil d'analyse de préchargement jusqu'à ce que ces ressources soient entièrement téléchargées.

Dans cet exemple, l'impact de l'intégration a des conséquences négatives sur le LCP et sur les performances en général. La version de la page qui n'intègre rien affiche l'image LCP en environ 3,5 secondes. La page qui inclut tout en ligne n'affiche l'image LCP qu'au bout de 7 secondes.

Il ne s'agit pas seulement du scanner de préchargement. L'intégration des polices n'est pas une bonne stratégie, car le format base64 est inefficace pour les ressources binaires. Un autre facteur est que les ressources de polices externes ne sont pas téléchargées, sauf si elles sont jugées nécessaires par le CSSOM. Lorsque ces polices sont intégrées au format Base64, elles sont téléchargées, que ce soit nécessaire pour la page actuelle ou non.

Un préchargement pourrait-il améliorer les choses ? Bien sûr. Vous pouvez précharger l'image du LCP et réduire le délai de LCP, mais gonfler votre code HTML potentiellement non en cache avec des ressources intégrées a d'autres conséquences négatives sur les performances. Ce modèle affecte également le First Contentful Paint (FCP). Dans la version de la page où rien n'est intégré, la valeur FCP est d'environ 2,7 secondes. Dans la version où tout est intégré, le FCP est d'environ 5,8 secondes.

Faites très attention à insérer des éléments dans le code HTML, en particulier des ressources encodées en base64. En règle générale, cette pratique n'est pas recommandée, sauf pour les ressources très petites. Insérez le code inline le moins possible, car trop d'éléments intégrés peut s'avérer dangereux.

Rendre le balisage avec JavaScript côté client

Il n'y a pas de doute: JavaScript a un impact sur la vitesse des pages. Les développeurs s'appuient sur elle pour fournir de l'interactivité, mais aussi pour diffuser du contenu. Cela améliore l'expérience des développeurs d'une certaine manière, mais les avantages pour les développeurs ne se traduisent pas toujours par des avantages pour les utilisateurs.

Un modèle qui peut contourner le scanner de préchargement consiste à afficher du balisage avec JavaScript côté client:

Cascade de réseau WebPageTest montrant une page de base avec des images et du texte entièrement affichés sur le client en JavaScript. Étant donné que le balisage est contenu dans JavaScript, l&#39;outil d&#39;analyse de préchargement ne peut détecter aucune des ressources. Toutes les ressources sont également retardées en raison du temps réseau et de traitement supplémentaire requis par les frameworks JavaScript.
Fig. 14:graphique en cascade du réseau WebPageTest d'une page Web rendue côté client exécutée sur Chrome sur un appareil mobile via une connexion 3G simulée. Étant donné que le contenu est contenu dans JavaScript et repose sur un framework pour le rendu, la ressource d'image dans le balisage rendu par le client est masquée par le scanner de préchargement. L'expérience équivalente avec rendu côté serveur est illustrée dans la figure 9.

Lorsque les charges utiles de balisage sont contenues dans JavaScript et entièrement affichées par celui-ci dans le navigateur, toutes les ressources de ce balisage sont effectivement invisibles pour le scanner de préchargement. Cela retarde la découverte de ressources importantes, ce qui a certainement un impact sur le LCP. Dans ces exemples, la requête de l'image LCP est considérablement retardée par rapport à l'expérience équivalente rendue par le serveur qui n'a pas besoin de JavaScript pour s'afficher.

Cela s'écarte un peu de l'objet de cet article, mais les effets du rendu du balisage sur le client vont bien au-delà de la désactivation du scanner de préchargement. D'une part, l'introduction de JavaScript pour alimenter une expérience qui n'en a pas besoin entraîne un temps de traitement inutile qui peut affecter l'interaction jusqu'à la prochaine peinture (INP). L'affichage d'une quantité extrêmement importante de balisage sur le client est plus susceptible de générer des tâches longues par rapport à la même quantité de balisage envoyée par le serveur. En dehors du traitement supplémentaire impliqué par JavaScript, cela s'explique par le fait que les navigateurs transmettent le balisage du serveur en streaming et découpent le rendu de manière à limiter les tâches longues. En revanche, le balisage côté client est géré comme une tâche monolithique unique, ce qui peut affecter l'INP d'une page.

La solution à ce problème dépend de la réponse à cette question: Existe-t-il une raison pour laquelle le balisage de votre page ne peut pas être fourni par le serveur au lieu d'être affiché sur le client ? Si la réponse est "non", le rendu côté serveur (SSR) ou le balisage généré de manière statique doivent être envisagés dans la mesure du possible, car ils aideront le scanner de préchargement à découvrir et à récupérer de manière opportuniste des ressources importantes à l'avance.

Si votre page a besoin de JavaScript pour associer des fonctionnalités à certaines parties de son balisage, vous pouvez toujours le faire avec le SSR, soit avec du JavaScript standard, soit avec l'hydratation pour profiter des avantages des deux approches.

Aidez le préchargeur à vous aider

L'analyseur de préchargement est une optimisation de navigateur très efficace qui permet de charger les pages plus rapidement au démarrage. En évitant les modèles qui empêchent le navigateur de découvrir à l'avance des ressources importantes, vous ne simplifiez pas seulement le développement, mais vous créez également une meilleure expérience utilisateur qui génère de meilleurs résultats pour de nombreuses métriques, y compris certaines métriques Web Vitals.

Pour résumer, voici les points clés à retenir de cet article:

  • Le scanner de préchargement du navigateur est un analyseur HTML secondaire qui analyse avant l'analyseur principal s'il est bloqué afin de découvrir de manière opportuniste les ressources qu'il peut récupérer plus tôt.
  • Les ressources qui ne figurent pas dans le balisage fourni par le serveur lors de la requête de navigation initiale ne peuvent pas être détectées par l'explorateur de préchargement. Voici quelques exemples de méthodes permettant de contourner le scanner de préchargement (liste non exhaustive) :
    • Injecter des ressources dans le DOM avec JavaScript, qu'il s'agisse de scripts, d'images, de feuilles de style ou de tout autre élément qui serait mieux placé dans la charge utile de balisage initiale du serveur.
    • Chargement paresseux des images ou des iFrames au-dessus de la ligne de flottaison à l'aide d'une solution JavaScript.
    • Rendu du balisage sur le client, qui peut contenir des références aux sous-ressources de document à l'aide de JavaScript.
  • Le scanner de préchargement n'analyse que le code HTML. Il n'examine pas le contenu d'autres ressources, en particulier les fichiers CSS, qui peuvent inclure des références à des éléments importants, y compris des candidats au LCP.

Si, pour une raison quelconque, vous ne pouvez pas éviter un schéma qui affecte négativement la capacité du scanner de préchargement à accélérer les performances de chargement, envisagez l'indice de ressource rel=preload. Si vous utilisez rel=preload, testez-le dans des outils de laboratoire pour vous assurer qu'il produit l'effet souhaité. Enfin, ne préchargez pas trop de ressources, car si vous priorisez tout, rien ne sera prioritaire.

Ressources

Image principale issue de Unsplash, par Mohammad Rahmani .