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 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'outil d'analyse de préchargement des navigateurs est une optimisation interne à comprendre. 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écharge ?

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.

Diagramme 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 de façon éclair si le navigateur ne bloque pas l'affichage pendant le téléchargement et le traitement d'une feuille de style.

Le navigateur bloque également l'analyse et l'affichage 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.
Figure 3:Schéma illustrant le fonctionnement de l'analyseur de préchargement en parallèle avec l'analyseur HTML principal pour charger les éléments de manière spéculative. 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 de préchargement ne serait pas très utile. La clé pour déterminer si une page Web bénéficie de l'analyseur de préchargement dépend de ces phénomènes bloquants. Pour ce faire, vous pouvez introduire un délai artificiel pour les requêtes afin de savoir où fonctionne le scanner de préchargement.

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 artificiellement retardée de deux secondes par un proxy avant le début de son chargement, l'image située plus tard dans la charge utile du balisage est découverte par l'outil d'analyse du 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 les éléments avec opportunisme pendant la période de blocage, et davantage de demandes 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. Cela semble optimal, 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écharge a été annulé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é. L'outil d'analyse de préchargement ne parvient pas à découvrir le script pendant la phase de blocage du rendu, car il est injecté dans le client.

Analysons ce qui s'est passé ici:

  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 visible dans le balisage fourni par le serveur, il l'est par l'analyseur 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 dans 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 peuvent ê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 ?

Une cascade WebPageTest montrant comment l&#39;indice de ressource rel=preload est utilisé pour favoriser la découverte d&#39;un script injecté asynchrone, même si cela peut avoir des effets secondaires imprévus.
Figure 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 être découvert plus rapidement.

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émo où le script async est préchargé, la feuille de style est toujours chargée avec la priorité "Highest" (Élevée), mais la priorité du script a été définie sur "High" (É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 provoquer des conflits de bande passante. Cela peut être un facteur en cas de connexion lente ou de ressources importantes.

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 différé 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 le temps nécessaire pour découvrir une référence à une image, la télécharger, la décoder et la présenter. 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 l'analyseur 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 d'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.

En fonction de 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 LCP (Largest Contentful Paint). 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 différée, ce qui signifie qu&#39;elle ne dépend pas du script à charger, ce qui signifie que l&#39;outil d&#39;analyse du préchargement peut la détecter 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 temps d'avance sur le chargement.

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écouvertes lors de la construction du CSSOM, elles sont demandées au moment de la découverte, et non par l'analyseur 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é depuis CSS à l&#39;aide de la propriété d&#39;image de fond. É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 LCP candidat de la page est un élément ayant une propriété CSS background-image (ligne 3). L'extraction de l'image demandée ne commence pas tant que l'analyseur CSS ne l'a pas trouvée.

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 candidat LCP d'image doit être chargé à partir du CSS. Avec un tag <img>, vous aurez davantage de contrôle sur le chargement d'une image adaptée à la fenêtre d'affichage, tout en permettant à l'analyseur 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, il existe des inconvénients majeurs:

  • 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 intégrez trop d'éléments intégrés, vous retardez l'analyse de préchargement pour qu'ils ne découvrent pas les ressources ultérieurement 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 LCP est découverte par l&#39;outil d&#39;analyse 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és en tant que ressources en base64 ?

Graphique en cascade du réseau WebPageTest d&#39;une page contenant un fichier CSS externe avec quatre polices référencées dans celui-ci. L&#39;analyseur de préchargement est considérablement retardé dans la détection 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'est pas intégré affiche l'image LCP en 3,5 secondes environ. La page qui inclut tout en ligne n'affiche l'image LCP qu'au bout de plus de sept 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 n'est pas efficace 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.

Le préchargement pourrait-il améliorer les choses ici ? 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é, le 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 permet d'améliorer 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 du réseau WebPageTest affichant une page de base avec des images et du texte affichés entièrement sur le client en JavaScript. Comme 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 et affichées entièrement par JavaScript dans le navigateur, toutes les ressources de ce balisage sont effectivement invisibles pour l'analyseur 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 introduit un temps de traitement inutile qui peut affecter INP (Interaction to Next Paint). 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. Le balisage rendu par le client, en revanche, est géré comme une seule tâche monolithique, 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 du 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 certains signaux Web.

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

  • L'analyseur de préchargement du navigateur est un analyseur HTML secondaire qui analyse avant le principal s'il est bloqué afin de découvrir avec opportunisme les ressources qu'il peut extraire 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é de l'outil d'analyse de précharge à accélérer les performances de chargement, tenez compte de l'indice de ressource rel=preload. Si vous utilisez rel=preload, testez les outils de l'atelier pour vous assurer que vous obtenez 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.