Les requêtes critiques

Le fait d’afficher un site web semble assez simple: envoi du HTML, le navigateur indique les ressources à charger ensuite. Ensuite, nous attendons patiemment que la page soit prête.

En peu de temps, sans que vous le sachiez, beaucoup de choses se passent sous le capot.

Vous êtes-vous déjà demandé comment le navigateur détecte quels actifs doivent être demandés et dans quel ordre?

Aujourd’hui, nous allons examiner la façon dont nous pouvons utiliser les priorités de ressources pour améliorer la rapidité de livraison.

La plupart des navigateurs analysent le HTML à l’aide d’un analyseur (streaming parser). Les elements de la pages (assets) sont découverts dans le balisage (markup) avant qu’il ne soit entièrement livré. À mesure que les elements (assets) sont trouvés, ils sont ajoutés à une file d’attente réseau avec une priorité prédéterminée.

Dans Chrome aujourd’hui, il existe un certain nombre de niveaux de priorisation des actifs: très bas, bas, moyen, élevé et très élevé. La mise au point dans la source Chrome DevTools montre que ceux-ci sont alias sur des étiquettes légèrement différentes: le plus bas, le bas, le moyen, le haut et le plus élevé.

Pour voir comment votre site privilégie les demandes, vous pouvez activer une colonne de priorité dans la table de requêtes du réseau DevTools de Chrome.

Vous trouverez également la priorité pour une demande donnée dans l’onglet Performance.

Comment Chrome distingue-t-il les ressources prioritaires?

Chaque type de ressource (CSS, JavaScript, polices, etc.) a son propre ensemble de règles qui dicte comment elles seront prioritaires. Voici une liste non exhaustive des plans prioritaires de réseau:

HTML – La plus haute priorité.

Styles – La plus haute priorité. Les feuilles de styles qui sont référencées à l’aide d’une directive @import seront également priorisées Plus haut, mais elles seront mises en file d’attente après avoir bloqué les scripts.

Les images sont les seuls actifs qui peuvent varier en fonction de la priorité en fonction des heuristiques de la fenêtre. Toutes les images commencent avec une priorité de Low, mais seront mises à niveau en priorité moyenne lorsqu’elles seront rendues dans la fenêtre visible. Les images en dehors de la fenêtre (également appelées «sous le pli») resteront à faible priorité.

Au cours de la recherche de cet article, j’ai découvert (avec l’aide de Paul Irish) que Chrome DevTools émet actuellement des informations erronées sur les images qui ont été mises à niveau vers un moyen comme une priorité faible. Paul a rédigé un rapport de bogue, que vous pouvez suivre ici.

Si vous souhaitez lire la source Chrome qui gère la mise à niveau de la priorité de l’image, commencez avec UpdateAllImageResourcePriorities et ComputeResourcePriority.

Ajax / XHR / fetch() – Haute priorité.

Les scripts suivent un schéma complexe de priorité de chargement. (Jake Archibald a écrit à ce sujet en détail en 2013. Si vous voulez connaître la science derrière, je vous suggère de prendre une cuppa et de plonger). La version TL; DR est:

• Les scripts chargés à l’aide de < script src="name.js " ></script> seront priorisés en tant que High s’ils apparaissent dans le balisage avant une image.
• Les scripts chargés à l’aide de < script src="name.js " ></script> seront priorisés en moyenne s’ils apparaissent dans le balisage après une image.
• Les scripts qui utilisent des attributs asynchrones ou différés seront classés par ordre de priorité.
• Les scripts utilisant type = « module » seront priorisés comme étant bas.

Les polices sont une bête étrange; Ils sont des ressources extrêmement importantes (qui d’autre aime le jeu « ‘Je le vois! », « Maintenant c’est parti », « Whoa, une nouvelle police! »?), Il est donc logique que les polices soient téléchargées à la plus haute priorité.

Malheureusement, la plupart des règles @font-face se trouvent dans une feuille de style externe (chargée à l’aide de quelque chose comme: < link rel="stylesheet" href="file.css" >). Cela signifie que les polices Web sont habituellement retardées jusqu’à ce que la feuille de style ait été téléchargée.

Même si votre fichier CSS fait référence à une police @font-face, il ne sera pas demandé jusqu’à ce qu’il soit utilisé sur un sélecteur et que le sélecteur correspond à un élément de la page. Si vous avez construit une application de page unique qui ne rend aucun texte jusqu’à ce qu’elle soit rendue, vous réduisez encore plus les polices.

Qu’est-ce qui rend une requête critique?

La plupart des sites Web demandent effectivement au navigateur de charger tout pour que la page soit entièrement rendue, il n’y a pas de concept concret de « au-dessus du pli ».

De retour dans la journée, les navigateurs ne feraient pas plus de 6 requêtes simultanées par domaine – les personnes piratées autour de cela en utilisant les assets-1.domain.tld, assets-2.domain.tld serveur pour augmenter le nombre de téléchargements asynchrones, mais n’ont pas réussi à Reconnaissent qu’il y aurait un succès DNS et une connexion TCP pour chaque nouveau domaine et les fichiers du site (assets).

Bien que cette approche ait eu des mérites, beaucoup d’entre nous n’ont pas compris les impacts complets et n’ont certainement pas des outils de développement de navigateurs de bonne qualité pour confirmer ces expériences.

Heureusement aujourd’hui, nous disposons d’excellents outils. En utilisant CNN comme exemple, identifions les actifs qui sont absolument nécessaires pour que la fenêtre soit visuellement prête (aussi connue comme utile pour une personne qui essaie de la lire).

Il n’y a vraiment que 5 choses qui sont nécessaires pour afficher cet écran (et tous ne doivent pas être chargés avant que le site ne soit utilisable):

• Plus important encore, le HTML. Si tout le reste échoue, l’utilisateur peut toujours lire la page.

CSS

• Le logo (une image de fond PNG placée par CSS. Ce pourrait probablement être un SVG en ligne).
• 4 (!) Poids de police Web.
• L’image principale de l’article.

Ces fichiers dans la page (assets) (notez le manque de JavaScript) sont essentiels aux visuels qui composent la fenêtre principale de la page. Ces fichiers (assets) sont ceux qui devraient être chargés en premier.

Plonger dans le panneau de performance de Chrome nous montre que près de 50 requêtes sont faites avant que les polices et les images avancées ne soient demandées.

Il existe un désaccord clair entre les demandes requises pour l’affichage et les demandes qui sont en cours.

Contrôle des priorités en matière de ressources

Maintenant que nous avons défini les demandes critiques, nous pouvons commencer à les classer en priorité à l’aide de quelques réglages simples et puissants.

Preload (< link rel="preload" href="font.woff" />) indique au navigateur d’ajouter font.woff à la file d’attente de téléchargement du navigateur à une priorité « High ».

Remarque: as = "font" est la raison pour laquelle font.woff serait téléchargé en tant que priorité élevée – C’est une police, donc il suit le plan de priorité décrit précédemment dans « Comment Chrome priorise les ressources? » section.

Essentiellement, vous dites au navigateur: Vous ne le savez peut-être pas encore, mais nous aurons besoin de cela.

C’est parfait pour les demandes critiques que nous avons identifiées plus tôt. Les polices Web peuvent presque toujours être classées comme absolument critiques, mais il existe des problèmes fondamentaux avec la façon dont les polices sont découvertes et chargées:

• Nous attendons que le CSS soit chargé, analysé et appliqué avant que les règles @ font-face ne soient découvertes.
• Une police n’est pas ajoutée à la file d’attente du réseau du navigateur jusqu’à ce qu’elle corresponde à ses règles CSS au DOM via les sélecteurs.
• Cette correspondance du sélecteur survient lors du recalcul du style. Cela ne se produit pas nécessairement immédiatement après le téléchargement. Il peut être retardé si le thread principal est occupé.

Dans la plupart des cas, les polices sont retardées de quelques secondes, simplement parce que nous n’inscrivons pas le navigateur pour les télécharger en temps opportun.

Sur un appareil mobile doté d’un CPU lent, d’une connectivité lâche, et sans un repli correctement construit, cela peut être un briseur absolu.

Préchargement en action: polices

J’ai effectué deux tests contre calibreapp.com. À la première étape, je n’avais rien changé du site. Sur le deuxième, j’ai ajouté ces deux balises:

< link rel="preload" as="font" href="Calibre-Regular.woff2" type="font/woff2" crossorigin />
< link rel="preload" as="font" href="Calibre-Semibold.woff2" type="font/woff2" crossorigin />

Ci-dessous, vous verrez une comparaison visuelle du rendu de ces deux tests. Les résultats sont assez étonnants:

La page a été rendue 3,5 secondes plus rapide lorsque les polices étaient préchargées.

< link rel="preload"> accepte également un attribut media="", qui priorisera de manière sélective les ressources en fonction des règles de requête @media :

< link rel="preload" href="article-lead-sm.jpg" as="image" type="image/jpeg" media="only screen and (max-width: 48rem)">

Ici, nous pouvons précharger une image particulière pour les périphériques à petit écran. Parfait pour cette « image principale du héros ».

Comme démontré ci-dessus, une vérification simple et quelques tags plus tard et nous avons considérablement amélioré la livraison et la phase de rendu. Super!

Testons les polices de caractères web

69% des sites utilisent des polices Web et, malheureusement, ils fournissent une expérience décevante dans la plupart des cas. Ils apparaissent, puis disparaissent, puis apparaissent à nouveau, changent de poids et secouent la page pendant la séquence de rendu.

Franchement, cela dérange presque tous les niveaux.

Comme vous l’avez vu ci-dessus, contrôler l’ordre de la demande et la priorité des polices a un effet massif sur la vitesse de rendu. Il est clair que nous devrions chercher à prioriser les requêtes de police Web dans la plupart des cas.

Nous pouvons apporter d’autres améliorations à l’aide de la propriété CSS font-display. Nous permet de contrôler la manière dont les polices s’affichent pendant la procédure de requête et de chargement des polices web.

Il existe 4 options à votre disposition, mais je suggère d’utiliser font-display: swap ;, qui affichera la police de secours jusqu’à ce que la police Web ait été chargée, auquel cas elle sera remplacée.

Étant donné une pile de polices comme celle-ci:

body {
font-family: Calibre, Helvetica, Arial;
}

Le navigateur affiche Helvetica (ou Arial, si vous n’avez pas Helvetica) jusqu’à ce que la police Calibre ait été chargée. À l’heure actuelle, Chrome et Opera sont les seuls navigateurs qui supportent l’affichage des polices, mais c’est un pas en avant, et il n’y a aucune raison de ne pas l’utiliser à partir d’aujourd’hui.

Atteindre les performances optimales de la page

Comme vous le savez bien, les sites Web ne sont jamais «complets». Il y a toujours des améliorations à faire et il peut se sentir accablant, rapidement.

Calibre est un outil automatisé pour la vérification des performances, de l’accessibilité et des meilleures pratiques Web, il vous aidera à rester au courant des choses.

Comme vous l’avez vu ci-dessus, il existe quelques mesures qui sont essentielles pour comprendre les performances de l’utilisateur.

• La première problématique nous dit quand le navigateur passe de «rien à quelque chose».
• La première vrai problématique nous indique quand le navigateur a « rendu utile ».
• Enfin, First Interactive vous indiquera quand la page a été entièrement rendue, et le thread principal de JavaScript s’est installé (activité CPU faible pendant plusieurs secondes).

Vous pouvez définir des budgets sur toutes ces métriques d’expérience utilisateur clés. Lorsque ces budgets sont dépassés (ou rencontrés), votre équipe sera informée par Slack, par courrier électronique ou par vous-même.

Calibre affiche la priorité de la demande réseau, de sorte que vous pouvez être sûr que les requêtes sont en cours. Ajuster les priorités et améliorer les performances.

J’espère que vous avez acquis des compétences précieuses pour vérifier les demandes et leurs priorités, ainsi que quelques idées à expérimenter pour apporter des améliorations significatives.

Votre liste de contrôle de requête critique:

• Activez la colonne Priorité dans Chrome DevTools.
• ✅ Décidez quelles requêtes doivent être faites avant que les utilisateurs puissent voir une page entièrement rendue.
• ✅ Réduire le nombre de requêtes critiques requises lorsque cela est possible.
• ✅ Utilisez pour des fichiers du site (assets) qui seront probablement utilisés à la page suivante du site.
• ✅ Utilisez < link https://example.com/other/styles.css rel=preload as=style> nopush En-têtes HTTP pour indiquer au navigateur quelles ressources précharger avant que le HTML ne soit entièrement livré.
• ? La poussée du serveur HTTP / 2 est épineuse. Probablement l’éviter. (Voir ce document informatif de Tom Bergan, Simon Pelchat et Michael Buettner, ainsi que Jake Archibald « HTTP / 2 Push est plus dur que ce que je pensais« )
• ✅ Utiliser font-display: swap; Avec des polices Web si possible.
• ⏱ Les polices Web sont-elles utilisées? Peut-on les enlever? Si non: les hiérarchiser et utiliser WOFF2!
• ⏱ Un script de chargement en retard retarde votre application de page unique pour afficher n’importe quoi?
• ? Vérifiez cette excellente vidéo gratuite par Front End Center qui montre comment charger webfonts avec la meilleure expérience de retour possible.
• ? Afficher chrome://net-internals/#events et charger une page – cela enregistre les événements liés au réseau.
• Aucune requête n’est plus rapide qu’aucune requête. ✌️

source : https://css-tricks.com/the-critical-request/