Publié le 17 août 2018
Ce guide examine les règles PageSpeed Insights dans leur contexte: à quoi faire attention lorsque vous optimisez le chemin de rendu critique et pourquoi.
Supprimer les codes JavaScript et CSS qui bloquent l'affichage
Pour accélérer le délai de premier affichage, réduisez et (dans la mesure du possible) éliminez le nombre de ressources critiques sur la page, réduisez le nombre d'octets critiques téléchargés et optimisez la longueur du chemin critique.
Optimiser l'utilisation de JavaScript
Les ressources JavaScript sont bloquées par l'analyseur par défaut, sauf si elles sont marquées comme async ou ajoutées à l'aide d'un extrait JavaScript spécial. Le blocage du code JavaScript par l'analyseur oblige le navigateur à attendre le CSSOM et met en pause la création du DOM, ce qui peut retarder considérablement le premier rendu.
Privilégier les ressources JavaScript asynchrones
Les ressources asynchrones débloquent l'analyseur de document et permettent au navigateur d'éviter le blocage sur CSSOM avant d'exécuter le script. Souvent, si le script peut utiliser l'attribut async, cela signifie également qu'il n'est pas essentiel pour le premier rendu. Envisagez de charger les scripts de manière asynchrone après le rendu initial.
Éviter les appels de serveur synchrones
Utilisez la méthode navigator.sendBeacon() pour limiter les données envoyées par XMLHttpRequests dans les gestionnaires unload. Étant donné que de nombreux navigateurs exigent que ces requêtes soient synchrones, elles peuvent ralentir les transitions de page, parfois de manière notable. Le code suivant montre comment utiliser navigator.sendBeacon() pour envoyer des données au serveur dans le gestionnaire pagehide au lieu du gestionnaire unload.
<script>
function() {
window.addEventListener('pagehide', logData, false);
function logData() {
navigator.sendBeacon(
'https://putsreq.herokuapp.com/Dt7t2QzUkG18aDTMMcop',
'Sent by a beacon!');
}
}();
</script>
La méthode fetch() offre un meilleur moyen de demander des données de manière asynchrone. fetch() traite les réponses à l'aide de promesses plutôt que de plusieurs gestionnaires d'événements. Contrairement à la réponse à une XMLHttpRequest, une réponse fetch() est un objet de flux. Cela signifie qu'un appel à json() renvoie également une promesse.
<script>
fetch('./api/some.json')
.then(
function(response) {
if (response.status !== 200) {
console.log('Looks like there was a problem. Status Code: ' + response.status);
return;
}
// Examine the text in the response
response.json().then(function(data) {
console.log(data);
});
}
)
.catch(function(err) {
console.log('Fetch Error :-S', err);
});
</script>
La méthode fetch() peut également gérer les requêtes POST.
<script>
fetch(url, {
method: 'post',
headers: {
"Content-type": "application/x-www-form-urlencoded; charset=UTF-8"
},
body: 'foo=bar&lorem=ipsum'
}).then(function() { // Additional code });
</script>
Différer l'analyse JavaScript
Pour réduire la quantité de travail que le navigateur doit effectuer pour afficher la page, différez les scripts non essentiels qui ne sont pas essentiels à la création du contenu visible pour l'affichage initial.
Éviter les scripts JavaScript de longue durée
Le code JavaScript exécuté pendant une longue période empêche le navigateur de créer le DOM, le CSSOM et d'afficher la page. Reportez donc toute logique d'initialisation qui n'est pas essentielle pour le premier rendu. Si une longue séquence d'initialisation doit s'exécuter, envisagez de la diviser en plusieurs étapes pour permettre au navigateur de traiter d'autres événements entre-temps.
Optimiser l'utilisation du CSS
Le CSS est nécessaire pour créer l'arborescence de rendu, et JavaScript bloque souvent sur le CSS lors de la création initiale de la page. Assurez-vous que tout CSS non essentiel est marqué comme non critique (par exemple, les requêtes de médias et d'impression), et que la quantité de CSS critique et le temps de diffusion sont aussi faibles que possible.
Placer le code CSS dans l'en-tête du document
Spécifiez toutes les ressources CSS le plus tôt possible dans le document HTML afin que le navigateur puisse découvrir les balises <link> et distribuer la requête pour le CSS dès que possible.
Éviter les importations CSS
La directive d'importation CSS (@import) permet à une feuille de style d'importer des règles à partir d'un autre fichier de feuille de style. Toutefois, évitez ces directives, car elles introduisent des aller-retours supplémentaires dans le chemin critique: les ressources CSS importées ne sont détectées qu'après la réception et l'analyse de la feuille de style CSS avec la règle @import elle-même.
Code CSS intégré qui bloque l'affichage
Pour des performances optimales, vous pouvez envisager d'intégrer le CSS critique directement dans le document HTML. Cela élimine les aller-retours supplémentaires dans le chemin critique et, si vous le faites correctement, vous pouvez obtenir une longueur de chemin critique "aller-retour", où seul le code HTML est une ressource bloquante.