Comment identifier et réduire les ressources bloquant le rendu – Gratuit : Audit complet de votre site internet

Avant de commencer !

Rendu de page optimisé
Share on facebook
Share on twitter
Share on pinterest

En 2018, le temps moyen de chargement complet d’une page mobile était de 15 secondes. C’est nettement plus long que le temps de chargement de page recommandé par Google de 3 secondes.

Donc, bien sûr, la réduction du temps de chargement total reste une priorité absolue pour permettre l’interaction de l’utilisateur le plus rapidement possible.

Mais la vitesse des pages ne concerne pas uniquement le temps total de chargement des pages; il s’agit également de l’expérience des utilisateurs au cours de ces 3 (ou 15) secondes. Il est essentiel de considérer l’efficacité du rendu des pages.

Ceci est accompli en optimisant le chemin de rendu critique pour arriver à votre première peinture le plus rapidement possible.

Fondamentalement, vous réduisez le temps que les utilisateurs passent à regarder un écran blanc vierge pour afficher le contenu visuel dès que possible (voir 0.0 ci-dessous).

Rendu de page optimisé Exemple de rendu optimisé et non optimisé de Google

Il existe tout un processus sur la façon de procéder, décrit dans la documentation du guide du développeur de Google (merci, Ilya Grigorik), mais je vais me concentrer sur un frappeur en particulier: réduire les ressources de blocage du rendu.

PUBLICITÉ

CONTINUER À LIRE CI-DESSOUS

Quel est le chemin critique du rendu?

Le chemin de rendu critique fait référence à la série d’étapes qu’un navigateur entreprend pour rendre une page, en convertissant le HTML, le CSS et le JavaScript en pixels réels à l’écran.

Essentiellement, le navigateur doit demander, recevoir et analyser tous les fichiers HTML et CSS (ainsi que certains travaux supplémentaires) avant de commencer à rendre tout contenu visuel.

Jusqu’à ce que le navigateur termine ces étapes, les utilisateurs verront une page blanche vierge.

Étapes pour rendre une page

Comment l’optimiser?

L’amélioration du chemin de rendu critique implique d’identifier et d’analyser vos ressources critiques (toute ressource qui bloque le rendu initial de la page) et de rechercher des opportunités pour:

  • Réduisez le nombre de ressources critiques en différant les ressources bloquant le rendu.
  • Raccourcissez le chemin critique en priorisant le contenu au-dessus de la ligne de flottaison et en téléchargeant tous les actifs critiques le plus tôt possible.
  • Réduisez le nombre d’octets critiques en réduisant la taille du fichier des ressources critiques restantes.

PUBLICITÉ

CONTINUER À LIRE CI-DESSOUS

Cet article se concentrera sur l’étape 1 – le report des ressources de blocage du rendu (c’est-à-dire, la réorganisation des éléments pour plus d’efficacité afin de donner l’impression que l’expérience est plus rapide sans supprimer des éléments).

Pourquoi devrais-je m’en soucier?

Eh bien, personne ne le dit plus franchement que l’homme de cent dollars lui-même:

« Le temps, c’est de l’argent. » – Benjamin Franklin

Les données sur le comportement des utilisateurs de Google indiquent que la plupart des utilisateurs abandonnent un site lent après environ 3 secondes.

Au contraire, une étude de vitesse de page par Unbounce a révélé que près des trois quarts des consommateurs ont déclaré qu’ils étaient prêts à attendre 4 secondes ou plus pour qu’une page se charge.

Ce qui donne?

« Le temps est une illusion. » – Albert Einstein

Une étude publiée par le Journal of Consumer Research a indiqué qu’il existe deux types de temps:

  • Temps objectif: Heure d’horloge standard.
  • Temps subjectif: Perception du temps par le consommateur.

Se concentrer trop fortement sur le temps objectif peut être problématique, car les humains (et nos utilisateurs réels) sont notoirement mauvais pour estimer le temps.

« Le temps passe vite quand vous vous amusez. » – Mon père

La perception du temps par les gens est basée sur une variété de facteurs subjectifs.

Parmi ceux-ci, mentionnons s’ils sont en «attente passive» ou en «attente active». En termes de rendu de page, ceux-ci peuvent être définis comme:

  • Attente passive: L’utilisateur regarde un écran blanc vierge
  • Attente active: Le contenu visuel s’affiche sur la page

Une recherche publiée par INFORMS a révélé que, même lorsque les temps d’attente sont mesurablement égaux, les personnes en attente passive surestiment leur temps d’attente de + 36%.

Passive vs Active Wait

Le même concept a inspiré l’utilisation répandue de la barre de progression (ou de chargement) dans l’informatique, car elle s’est avérée réduire l’anxiété, créant une expérience plus positive pour les utilisateurs.

PUBLICITÉ

CONTINUER À LIRE CI-DESSOUS

« Les pages Web n’ont pas de barres de chargement. Ainsi, lorsque la page est lente, le visiteur ne sait pas si le délai sera encore de 500 millisecondes ou 15 secondes. Peut-être qu’il ne se chargera jamais. Et le bouton de retour est là »(Andy Crestodina, Orbit Media cité par Unbounce).

Avec de nombreuses études associant des réductions des temps de chargement des pages à des améliorations de KPI précieux (conversions, taux de rebond, temps sur site), l’amélioration de la latence du site est devenue un objectif commercial prioritaire pour de nombreuses organisations.

Les professionnels du référencement sont dans une position unique pour guider cet effort, car notre rôle est souvent de combler l’écart entre les objectifs commerciaux et les priorités des développeurs Web.

Avoir la capacité d’auditer un site, d’analyser les résultats et d’identifier les domaines à améliorer nous aide à travailler avec les développeurs pour améliorer les performances et traduire les résultats aux principales parties prenantes.

Retour aux ressources de blocage de rendu

L’objectif principal de l’optimisation du chemin de rendu critique est de hiérarchiser les ressources nécessaires pour rendre le contenu significatif au-dessus de la ligne de flottaison.

Pour ce faire, nous devons également identifier et déprioriser les ressources bloquant le rendu – ressources qui ne sont pas nécessaires pour charger le contenu au-dessus de la ligne de flottaison et empêcher la page de s’afficher aussi rapidement qu’elle le pourrait.

PUBLICITÉ

CONTINUER À LIRE CI-DESSOUS

CSS bloquant le rendu

CSS est intrinsèquement bloquant le rendu.

Le navigateur ne commence à afficher aucun contenu de page tant qu’il n’est pas en mesure de demander, de recevoir et de traiter tous les styles CSS.

Cela évite l’expérience utilisateur négative qui se produirait si un navigateur tentait de restituer du contenu sans style.

Une page rendue sans CSS serait pratiquement inutilisable et la majorité (sinon la totalité) du contenu devrait être repeinte.

Page avec CSS désactivée

En repensant au processus de rendu de page, la boîte grise représente le temps nécessaire au navigateur pour demander et télécharger toutes les ressources CSS, afin qu’il puisse commencer à construire l’arborescence CCSOM (le DOM de CSS).

Le temps nécessaire au navigateur pour y parvenir peut varier considérablement, selon le nombre et la taille des ressources CSS.

Étapes pour rendre une page CSS

Recommandation officielle de Google:

PUBLICITÉ

CONTINUER À LIRE CI-DESSOUS

«CSS est une ressource bloquant le rendu. Remettez-le au client le plus tôt et le plus rapidement possible afin d’optimiser le délai de premier rendu. »

JavaScript bloquant le rendu

Attendez, qu’en est-il de JavaScript?

Contrairement à CSS, le navigateur n’a pas besoin de télécharger et d’analyser tout Ressources JavaScript pour rendre la page, donc ce n’est pas techniquement * une étape «obligatoire» (* la plupart des sites Web modernes nécessitent JavaScript pour leur expérience au-dessus de la ligne de flottaison).

Pourtant, lorsque le navigateur rencontre JavaScript avant le rendu initial de la page, le processus de rendu de page est suspendu jusqu’à ce que JavaScript soit exécuté (sauf indication contraire à l’aide des attributs defer ou async – plus à ce sujet plus tard).

Par exemple, ajouter une fonction d’alerte JavaScript dans le rendu de la page des blocs HTML jusqu’à l’exécution du code JavaScript (lorsque je clique sur «OK» dans l’enregistrement d’écran ci-dessous).

Exemple de script Java de blocage de rendu

En effet, JavaScript a le pouvoir de manipuler les éléments de page (HTML) et leurs styles associés (CSS).

PUBLICITÉ

CONTINUER À LIRE CI-DESSOUS

Étant donné que le JavaScript pourrait théoriquement modifier l’intégralité du contenu de la page, le navigateur suspend l’analyse HTML pour télécharger et exécuter le JavaScript au cas où.

Comment le navigateur gère JavaScript Comment le navigateur gère JavaScript, image de Bits of Code

Recommandation officielle de Google:

«JavaScript peut également bloquer la construction DOM et retarder le rendu de la page. Pour offrir des performances optimales… éliminez tout JavaScript inutile du chemin de rendu critique. »

Comment identifier les ressources bloquant le rendu

Pour identifier le chemin de rendu critique et analyser les ressources critiques:

  • Exécutez un test en utilisant webpagetest.org et cliquez sur l’image «cascade».
  • Concentrez-vous sur toutes les ressources demandées et téléchargées avant la ligne verte «Démarrer le rendu».

PUBLICITÉ

CONTINUER À LIRE CI-DESSOUS

Analysez votre vue en cascade; recherchez les fichiers CSS ou JavaScript qui sont demandés avant la ligne verte de «début de rendu» mais qui ne sont pas critiques pour le chargement de contenu au-dessus de la ligne de flottaison.

WPT Start Render Line

Après avoir identifié une ressource (potentiellement) bloquant le rendu, testez-la pour voir si le contenu au-dessus de la ligne de flottaison est affecté.

Dans mon exemple, j’ai remarqué certaines demandes JavaScript adressées à l’API Google Maps qui ne semblent pas critiques. Mais c’est une bonne idée de tester la suppression de ces scripts pour tester la manière dont le déplacement d’éléments sur le site affecte l’expérience.

Exemple de blocage de rendu JavaScript

Pour tester dans le navigateur sur la façon dont le report de ces ressources affecterait le contenu au-dessus de la ligne de flottaison:

PUBLICITÉ

CONTINUER À LIRE CI-DESSOUS

  • Ouvrez la page dans une fenêtre de navigation privée Chrome (meilleure pratique pour les tests de vitesse de page, car les extensions Chrome peuvent fausser les résultats, et je suis un collectionneur d’extensions Chrome).
  • Ouvrez Chrome DevTools (ctrl + shift + i) et accédez à l’onglet «Demander le blocage» dans le panneau Réseau.
  • Cochez la case à côté de «Activer le blocage des demandes» et cliquez sur le signe plus.
  • Tapez un modèle pour bloquer la ou les ressources que vous avez identifiées, en étant aussi précis que possible (en utilisant * comme caractère générique).
  • Cliquez sur « Ajouter » et actualisez la page.

Test de suppression de scripts Exemple

Méthodes pour réduire le blocage du rendu

Une fois que vous avez confirmé qu’une ressource n’est pas critique pour rendre le contenu au-dessus de la ligne de flottaison, explorez les différentes méthodes disponibles pour différer les ressources et améliorer le rendu des pages.

Méthode Impact Marche avec
JavaScript en bas du HTML Faible JS
Attribut asynchrone ou différé Moyen JS
Solutions personnalisées Haute JS / CSS
Requêtes multimédias CSS Bas-haut CSS

Placer JavaScript au bas du HTML

Si vous avez déjà suivi un cours de conception Web 101, celui-ci peut vous être familier: placez des liens vers des feuilles de style CSS en haut du code HTML et placer des liens vers des scripts externes au bas du HTML .

PUBLICITÉ

CONTINUER À LIRE CI-DESSOUS

En revenant à mon exemple en utilisant une fonction d’alerte JavaScript, plus la fonction est élevée dans le HTML, plus elle sera téléchargée et exécutée rapidement par le navigateur.

Comment identifier & # 038; Réduisez les ressources de blocage du rendu Exemple de JavaScript placé en haut du HTML, le rendu de page est immédiatement bloqué par la fonction d’alerte et aucun rendu de contenu visuel.

La

Comment identifier & # 038; Réduisez les ressources de blocage du rendu Exemple de JavaScript placé en bas du HTML, du contenu visuel apparaît avant que le rendu de page ne soit bloqué par la fonction d’alerte.

Bien que placer des ressources JavaScript au bas du code HTML reste une bonne pratique standard, la méthode en elle-même n’est pas optimale pour éliminer les scripts de blocage du rendu du chemin critique.

Continuez à utiliser cette méthode pour les scripts critiques, mais explorez d’autres solutions pour vraiment différer les scripts non critiques.

PUBLICITÉ

CONTINUER À LIRE CI-DESSOUS

Utilisez l’attribut Async ou Defer

le attribut asynchrone signale au navigateur de charger JavaScript de manière asynchrone, récupère le script lorsque les ressources deviennent disponibles (par opposition à la suspension de l’analyse HTML).

Une fois le script récupéré et téléchargé, l’analyse HTML est interrompue pendant l’exécution du script.

Attribut asynchrone Comment le navigateur gère JavaScript avec un attribut asynchrone, image à partir de bits de code

le différer l’attribut signale au navigateur de charger JavaScript de manière asynchrone (identique à l’attribut async) et attendre d’exécuter JavaScript jusqu’à ce que l’analyse HTML soit terminée, ce qui entraîne des économies supplémentaires.

Attribut différé Comment le navigateur gère JavaScript avec un attribut de report, image de Bits of Code

Les deux méthodes sont relativement faciles à implémenter et aident à réduire le temps que le navigateur passe à analyser le HTML (la première étape du rendu de page) sans modifier de manière significative la façon dont le contenu se charge sur la page.

PUBLICITÉ

CONTINUER À LIRE CI-DESSOUS

L’asynchronisation et le report sont de bonnes solutions pour les «éléments supplémentaires» de votre site (boutons de partage social, barre latérale personnalisée, flux sociaux / d’actualités, etc.) qui sont agréables à avoir, mais ne font ni ne cassent l’expérience utilisateur principale.

Utilisez une solution personnalisée

Vous vous souvenez de cette alerte JS ennuyeuse qui empêchait ma page de s’afficher?

L’ajout d’une fonction JavaScript avec un événement «onload» (de Patrick Sexton sur Varvy.com) a résolu le problème une fois pour toutes.

Le script ci-dessous utilise l’événement onload pour appeler la ressource externe «alert.js» uniquement après que tout le contenu de la page initiale (tout le reste) a fini de se charger, en le supprimant du chemin critique.

Événement de chargement JavaScript Événement onload JavaScript utilisé pour appeler la fonction d’alerte
Comment identifier & # 038; Réduisez les ressources de blocage du rendu L’alerte ne s’affiche que lorsque tout le contenu de la page initiale est entièrement chargé.

Ce n’est pas une solution universelle.

PUBLICITÉ

CONTINUER À LIRE CI-DESSOUS

Bien que cela puisse être utile pour les ressources de priorité la plus faible (c’est-à-dire les écouteurs d’événements, les éléments du pied de page, etc.), vous aurez probablement besoin d’une solution différente pour le contenu important situé en dessous de la ligne de flottaison.

Travaillez avec votre équipe de développement pour trouver la meilleure solution pour améliorer le rendu des pages tout en conservant une expérience utilisateur optimale.

Utiliser les requêtes CSS sur les médias

Requêtes multimédias CSS peut débloquer le rendu en signalant des ressources qui ne sont utilisées qu’une partie du temps et en définissant des conditions sur le moment où le navigateur doit analyser le CSS (en fonction de l’impression, de l’orientation, de la taille de la fenêtre, etc.).

Tous les actifs CSS seront demandés et téléchargés malgré tout, mais avec une priorité inférieure pour les ressources non bloquantes.

Exemple de requête multimédia CSS Exemple de requête multimédia CSS qui indique au navigateur de ne pas analyser cette feuille de style à moins que la page ne soit imprimée.

Dans la mesure du possible, utilisez les requêtes multimédia CSS pour indiquer au navigateur quelles ressources CSS sont (et ne sont pas) essentielles pour afficher la page.

TL; DR

  • L’objectif d’optimisation du chemin de rendu critique est de fournir aux utilisateurs un contenu significatif aussi rapidement que possible.
  • Le report du CSS et du JavaScript bloquant le rendu permet au contenu important au-dessus de la ligne de flottaison de s’afficher plus rapidement.
  • Pour identifier les ressources bloquant le rendu:
    • Recherchez le chargement des ressources non critiques avant la ligne de rendu de démarrage (via webpagetest.org).
    • Testez la suppression de ressources via Google Dev Tools pour voir comment le contenu de la page est affecté.
    • Une fois identifié, travaillez avec les développeurs pour trouver la meilleure solution pour différer les ressources bloquant le rendu.

PUBLICITÉ

CONTINUER À LIRE CI-DESSOUS

Davantage de ressources:


Crédits d’image

Image vedette: Capture d’écran prise par l’auteur, juillet 2019
Toutes les captures d’écran prises par l’auteur, juillet 2019

Inscris-toi à notre newsletter !

Partage cet article avec tes amis !

Share on facebook
Share on google
Share on twitter
Share on linkedin