Étiquette : Indice de vitesse

Voici Light & Bold

En tant que développeur Web et évangéliste en performance Web, je passe beaucoup de temps à améliorer la vitesse de mes sites.

Avoir eu à ma disposition un thème déjà optimisé m’aurait grandement facilité la tâche.

C’est ainsi qu’après un an environ, le thème a complété le processus d’acceptation sur Themeforest. Je suis très fier de présenter officiellement Light & Bold.

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.

 

La vitesse de chargement est une donnée dépassée

Il y a quelques jours, je participais à un Hangout sur Google+ à propos de performance Web. Le sujet était “Comment mesurer le temps de chargement”. Plusieurs outils, tels que Pingdom Tool, que j’utilise très souvent d’ailleurs, ont été présentés rapidement. La présentation était toutefois limitée strictement au temps de chargement. Or ce n’est absolument pas un bon indicateur de vitesse. Il y a d’autres variables à prendre en compte.

Qu’est-ce que la vitesse de chargement?

En résumé, le temps de chargement est une donnée métrique qui est calculée en mesurant le temps que prend l’événement “window.onload()” à être déclenché.

Dans le passé, le temps de chargement était un très bon indicateur de la rapidité d’un site. De nos jours, la complexité des sites à exploser et de ce fier uniquement au temps de chargement pour mesurer la vitesse serait une erreur. Les outils de partages, les widgets, le défilement infini et les systèmes de commentaires externes sont de bons exemples de la complexité grandissante des pages Web.

Introduction à l’indice de vitesse (speed index)

L’indice de vitesse est calculé en prenant le progrès visible de la page et en calculant une note globale pour la rapidité à laquelle le contenu est affiché. Normalement, un indice de vitesse se situe entre 1000 et 10 000. Les petits nombres sont meilleurs.

D’après vous, quel site est le plus intéressant? Sachant en fait, que les deux sites ont un temps de chargement de 4 secondes.

Indice de vitesse

Pour le site numéro #1, le visiteur peut commencer à lire et à interagir avec le site dès la première seconde. Tandis que le site numéro 2 est accessible à l’utilisateur seulement à la quatrième seconde. Les deux sites ont pourtant le même temps de chargement. Voyez-vous la différence?

C’est exactement le constat qu’un lecteur m’a transmis dans les commentaires d’un article:

Bonjour, pourquoi lorsque je test cette page (l’article) sur pingdoom il me renvoi 2 secondes alors que j’ai l’impression que votre site est instantané ?

Alors, la page en question est effectivement chargée en un peu plus de 2 secondes. Par contre, l’indice de vitesse est de 800, ce qui signifie un chargement visuel en 800 millisecondes.

Les visiteurs de votre site n’ont rien à faire de ce qu’il y a dans votre bas de page et de la liste de vos suiveurs Twitter. Un visiteur veut trouver l’information qu’il veut, et ce, le plus rapidement possible. Pour cela, vous devez optimiser votre site pour le “Critical rendering Path”. C’est à dire, optimiser votre site de façon à prioriser le contenu et les éléments qui se trouvent au-dessus de la ligne de flottaison “above the fold”.

Conclusion

À mon avis, quand il s’agit de performances Web, nous devrions nous concentrer sur la rapidité avec laquelle un visiteur est en mesure de commencer à interagir avec le site. Le plus vite ils peuvent commencer à interagir le mieux ce sera.

Alors, la vitesse de chargement est toujours aussi importante pour vous?

Vidéo complémentaire

Paul Irish à la conférence Front End Ops Conf 2014 qui présente l’indice de vitesse.