Comprendre les règles PageSpeed Insights
Décryptez les règles PageSpeed Insights : JavaScript et CSS bloquants, chemin critique et bonnes pratiques pour des pages plus rapides.
PageSpeed Insights analyse vos pages et formule des recommandations pour les rendre plus rapides. Derrière ces règles se cache un objectif unique : raccourcir le chemin critique de rendu, c’est-à-dire la séquence de ressources que le navigateur doit traiter avant d’afficher la page. Comprendre cette logique permet d’agir efficacement plutôt que de corriger des symptômes au hasard.
Pour le SEO, ces règles sont précieuses : elles pointent les ressources qui retardent l’affichage et l’interactivité, deux dimensions au coeur de l’expérience utilisateur mesurée par Google. Les appliquer améliore directement la perception de rapidité de votre site.
Le piège avec PageSpeed Insights, c’est de traiter chaque recommandation comme une case à cocher sans voir ce qu’elles ont en commun : raccourcir le chemin critique de rendu. Une fois cette logique intégrée, vous priorisez les ressources qui bloquent vraiment l’affichage au lieu de corriger des symptômes au hasard. Lisez l’outil comme un diagnostic, pas comme une liste de tâches.
Réduire les ressources bloquant l'affichage
Le principe fondateur des règles PageSpeed est de réduire, et si possible d’éliminer, les ressources critiques qui bloquent l’affichage. Concrètement, cela revient à diminuer le nombre d’octets critiques téléchargés et à raccourcir la longueur du chemin critique.
JavaScript et CSS sont les deux grands responsables. Par défaut, un script bloque l’analyseur du document, et le CSS bloque la construction de l’arborescence de rendu : c’est tout l’enjeu d’éviter le CSS bloquant l’affichage. Moins ces ressources sont nombreuses et lourdes sur le chemin critique, plus le premier rendu arrive vite.
Optimiser l'utilisation du JavaScript
Un script bloque l’analyseur par défaut, sauf s’il est marqué async ou chargé via une technique adaptée. Privilégier les scripts asynchrones débloque l’analyse du document et participe à l’optimisation du chargement des ressources : si un script peut être asynchrone, c’est souvent qu’il n’est pas indispensable au premier rendu.
Évitez aussi les appels serveur synchrones, qui ralentissent les transitions de page. Pour envoyer des données au moment où l’utilisateur quitte la page, utilisez navigator.sendBeacon() plutôt qu’une requête synchrone. Enfin, différez l’analyse des scripts non essentiels et fractionnez les longues phases d’initialisation.
Charger des données sans bloquer le rendu
Pour récupérer des données de façon asynchrone, la méthode fetch() est recommandée. Elle traite les réponses via des promesses, ce qui évite de multiplier les gestionnaires d’événements et n’interfère pas avec le rendu initial de la page.
<script>
window.addEventListener('pagehide', function logData() {
navigator.sendBeacon('/api/log', 'Envoi via beacon');
}, false);
</script>Optimiser l'utilisation du CSS
Le CSS est nécessaire pour construire l’arborescence de rendu, et le JavaScript attend souvent que le CSS soit prêt. Il faut donc réduire au minimum la quantité de CSS critique et son temps de diffusion, tout en marquant comme non critique le CSS qui ne sert pas au premier affichage. Le tableau ci-dessous résume les bonnes pratiques.
| Règle | Action recommandée | Bénéfice |
|---|---|---|
CSS dans l’en-tête |
Déclarer les feuilles le plus tôt possible |
Découverte et requête CSS anticipées |
Éviter @import |
Ne pas importer une feuille depuis une autre |
Supprime des aller-retours sur le chemin critique |
CSS critique intégré |
Insérer le CSS critique dans le HTML |
Réduit la longueur du chemin critique |
CSS non essentiel |
Marquer en non critique (media, print) |
Libère le premier rendu |
Marquer un script async accélère le rendu, mais l’ordre d’exécution n’est plus garanti. Vérifiez qu’un script asynchrone ne dépend pas d’un autre script ou d’un élément du DOM pas encore disponible. Réservez le chargement asynchrone aux scripts réellement non essentiels au premier affichage.
À faire
- charger les scripts non critiques en asynchrone
- placer le CSS tôt dans le document
- intégrer le CSS critique
- différer l’analyse des scripts secondaires
À éviter
- multiplier les scripts bloquants
- utiliser des appels serveur synchrones
- recourir à @import dans vos feuilles de style
- exécuter de longues initialisations avant le premier rendu
Points clés à retenir
- Réduisez le nombre et le poids des ressources bloquantes
- Chargez les scripts non essentiels de manière asynchrone
- Remplacez les appels synchrones par fetch() ou sendBeacon()
- Placez le CSS tôt et intégrez le CSS critique
- Évitez les directives @import dans vos feuilles de style
Les règles PageSpeed visent à raccourcir le chemin critique de rendu.
Quiz : testez vos connaissances
Quiz : testez vos connaissances
-
Quel objectif unique se cache derrière les règles de PageSpeed Insights ?
- Garantir un score de 100 sur 100 à tout prix
- Raccourcir le chemin critique de rendu
- Augmenter le nombre de requêtes pour mieux paralléliser
Derrière les règles PageSpeed se cache un objectif unique : raccourcir le chemin critique de rendu, c’est-à-dire la séquence de ressources à traiter avant l’affichage de la page.
-
Faut-il rendre tous les scripts asynchrones ?
- Non, seuls les scripts non essentiels au premier rendu doivent l'être
- Oui, l'async accélère toujours sans aucun risque
- Oui, c'est obligatoire pour respecter les règles PageSpeed
Seuls les scripts non essentiels au premier rendu doivent passer en asynchrone. Marquer
asyncne garantit plus l’ordre d’exécution, à vérifier en cas de dépendance. -
Quelle méthode privilégier pour récupérer des données sans bloquer le rendu initial ?
- fetch(), qui traite les réponses via des promesses
- Un appel serveur synchrone, plus simple à écrire
- La règle @import dans la feuille de style
La méthode
fetch()est recommandée pour récupérer des données de façon asynchrone. Elle traite les réponses via des promesses et n’interfère pas avec le rendu initial.
À propos de l'auteur
Besoin d'un accompagnement SEO ?
Vous voulez savoir quelles ressources bloquent l'affichage de vos pages ?