Performance Web

Personne n'aime un site lent

Règle de vitesse: Supprimer les fichiers JavaScript qui bloquent l’affichage

Supprimer les Fichiers Javascript qui bloquent l'affichage

Cette règle se déclenche dans Google PageSpeed Insights lorsqu’un ou plusieurs scripts bloque l’affichage de la page.

Le problème

Puisque les fichiers JavaScript peuvent modifier le HTML de la page, le navigateur doit attendre leurs chargements complets, avant d’afficher quoique ce soit à l’utilisateur.

Comment identifier les fichiers qui bloquent l’affichage

Analyser simplement votre site avec Google PageSpeed Insights. Si l’analyse détecte des scripts bloquant l’affichage de la page, l’erreur suivante sera affichée: “Elimitate render-blocking JavaScript ans CSS in above-the-fold content”.

Et oui, les fichiers CSS bloquent également le rendu de la page. Pour optimiser la diffusion de vos fichiers CSS rendez-vous sur cet article.

Remove render-blocking JavaScript

La fausse solution

Plusieurs développeurs vous diront de simplement mettre les scripts dans le bas de page.

Ce n’est pas suffisant…

Les solutions

Trois solutions sont possibles pour supprimer les scripts qui bloquent l’affichage de la page. À vous de voir quelles solutions s’adaptent le mieux à votre projet.

1. Intégrer les ressources JavaScript peu volumineuses

Si les scripts sont peu volumineux, il est préférable de les inclure directement dans le HTML. De cette façon, le navigateur n’a pas à attendre le chargement du script avant d’afficher le contenu à l’utilisateur.

Par exemple, disons que votre HTML est semblable à celui-ci.

<html>
    <head>
        <script type="text/javascript" src="small.js"></script>
    </head>
    <body>
        <div>Hello, world!</div>
    </body>
</html>

Vous devez remplacer le script de cette manière.

<html>
    <head>
        <script>
            /* Contenu de mon fichier JavaScript */
        </script>
    </head>
    <body>
        <div>Hello, world!</div>
    </body>
</html>

De cette manière, aucun script ne bloque l’affichage de la page.

2. Rendre async les ressources JavaScript

Le chargement “async” est la recommandation de Google. L’ajout de l’attribut “async” à vos scripts informe le navigateur qu’il n’a pas à attendre le chargement du script avant d’afficher le contenu à l’utilisateur.

Vous devez ajouter l’attribut de cette façon:

<script async src="my.js">

Pour les sites WordPress

WordPress inclut les fichiers JavaScript grâce à la fonction wp_enqueue_script() et à l’heure où j’écris ces lignes, il n’est pas facile d’ajouter l’attribut “async”, à moins d’utiliser une extension comme WP Rocket ou W3 Total Cache.

Pour ajouter l’attribut “async” à vos scripts et cela sans extension. Utilisez le bout de code suivant qui est à placer dans le fichier functions.php de votre thème.

add_filter( 'script_loader_tag', 'add_async', 10, 2 );
function add_async( $tag, $handle ) {
    return str_replace( ' src', ' async src', $tag );
}

Avec ce filtre, il est possible d’ajouter des conditions pour ajouter l’attribut uniquement sur certaines pages ou bien cibler uniquement certains scripts.

3. Différé complètement le chargement des scripts

La dernière technique consiste à différer complètement le chargement du script après le chargement de la page. Plus difficile à implémenter, cette technique offre toutefois les meilleurs résultats.

Pour conclure

Soyez vigilant avec les techniques deux et trois, car leur implémentation pourrait causer des erreurs. Vous ne pouvez pas différer le chargement d’un fichier si vous en avez besoin plus tôt lors du chargement de la page.

Analyse de la performance de sidlee.com

Cela faisait plus d’une heure que je cherchais un site connu sur lequel écrire une analyse de performance qui sort un peu de l’ordinaire. La plupart des sites ont de graves problèmes de performance, mais il n’est pas forcément intéressant d’en parler puisqu’il s’agit toujours des mêmes problèmes. Comme des dizaines de scripts qui ajoutent des animations pour tenter d’impressionner un futur client ou la concurrence.

C’est ainsi que je suis tombé sur le site de Sidlee. La vitesse de chargement de sidlee.com a piqué ma curiosité, 488ms! Si je ne peux pas parler des problèmes de performances d’un site, je pourrais écrire sur ce qui est fait correctement. Mais il n’en est rien. Comme vous le remarquerez vous-même, les bonnes performances du site ne sont en fait qu’un nuage de fumée.

By the way, Sidlee est une agence internationale spécialisée dans la création d’expériences de marque (marketing, Web, etc… ).

Analyse préliminaire

Pour un audit de performance, je commence normalement par un test de vitesse sur Pingdom Tools.

Rapport Pingdom Sidlee.com

Génial, je n’ai rien à redire pour le temps de chargement. Malheureusement, le temps de chargement n’est pas un bon indicateur de vitesse. C’est pourquoi j’ai poussé l’analyse un peu plus loin avec Webpagetest.

Tout d’abord, le temps de chargement est plus près des 4 secondes. Ensuite, voici ce que nous avons à l’écran à 5 secondes de chargement à partir d’une connexion DSL.

Sidlee Chargement Initial

Filmstrip Sidelee

Test complet

Un peu moins intéressant n’est ce pas?

Améliorations rapides

Il est très facile de mettre le doigt sur les problèmes de performance de sidlee.com.

Sidelee Performance Lettre

  • Activer la compression: je ne suis pas un expert des serveurs IIS, mais il semblerait que la compression Gzip soit aussi facile à activer qu’un serveur Linux.
  • Optimiser les images: il est nécessaire d’optimiser le poids des images de façon automatique. Ce n’est pas toujours une tâche facile, cela dépend beaucoup du CMS utilisé. Quand il s’agit d’images ajoutées par un développeur il y a plusieurs outils disponibles.
  • Minifier les ressources JavaScript: en effet, plusieurs scripts ne sont pas minifier et il est facile d’implémenter une solution automatiser de minification pour les développeurs.
  • Combiner les ressources JavaScript: l’analyse révèle 27 différents scripts pour la page d’accueil. Je crois qu’il y a de bons gains de performance à faire ici. Encore une fois, il y a plusieurs solutions pour les développeurs.
  • Utiliser un CDN pour tous les fichiers statiques: spécialement pertinent pour un site international, le CDN peut améliorer grandement les performances générales d’un site. Sidlee.com utilise bien un CDN, malheureusement pas pour toutes les ressources statiques.

Concernant l’optimisation des images, il semblerait que le site soit doté d’une solution d’image responsive. C’est-à-dire qu’une image de plus petite taille est affichée quand un appareil de petite résolution est détecté.

C’est excellent, peut-être faudrait-il que ce module fonctionne?

image-non-optimiser-sidlee

Améliorations plus complexes

Les points soulevés dans la section “Améliorations rapide” sont faciles à implémenter, mais ne règle pas le problème en soi.

Le problème est de rendre disponible le contenu à l’utilisateur, et ce le plus rapidement possible. Idéalement, en moins d’une seconde. Ce qui n’est pas réaliste avec la technique de chargement en Ajax utilisé sur sidlee.com.

Comprenez-moi bien, je n’ai rien contre les requêtes en Ajax, mais je pense qu’elles doivent être utilisées dans un contexte pertinent et ce n’est pas le cas présentement. Un bon exemple d’implémentation du chargement en Ajax est visible dans le bas de la page d’accueil. Je parle ici du bouton “Load more”.

Conclusion

Malgré ses problèmes de performances, sidlee.com n’est pas nécessairement mal construit. Le serveur répond rapidement, ce qui suggère une solution de caching installé. L’utilisation partielle d’un CDN et l’exploitation de la cache du côté navigateur suggèrent un certain souci de performance.

Il est important de penser à l’utilisateur avant toute autre chose lors de la création d’un site. C’est pour cela qu’il est préférable de construire les sites en gardant comme objectif l’optimisation du rendu critique de la page. Faites-le pour vos clients/utilisateurs et donc, finalement, pour vous même.