Étiquette : CDN

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.

 

Analyser la performance Web à l’aide d’un graphique en cascade “waterfall”

Si vous êtes un habitué de la performance Web, vous avez sûrement remarqué à quelques reprises des graphiques tel que celui affiché un peu plus bas.  Les graphiques en cascade “waterfall chart” sont utilisés pour diagnostiquer les problèmes de performance.

Si vous vous souciez de la vitesse de chargement de votre site, vous devez avoir au moins une compréhension élémentaire des graphiques en cascade.

Qu’est-ce qu’un graphique en cascade?

Un graphique en cascade est un diagramme qui représente les données qui sont générées de façon cumulative et séquentielle. Un graphique en cascade spécifique à la performance vous permet de voir les requêtes qui se produisent entre un navigateur et un serveur pour permettre à l’utilisateur de visualiser une page Web.

Chaque requête, qu’elle soit HTML, Images, CSS, JavaScript ou bien une redirection sont représentés par leur propre ligne dans le graphique. Le graphique indique le moment où chaque ressource est appeler à partir du serveur jusqu’à son téléchargement et son rendu dans le navigateur.

Pratiquement tous les outils de mesure de la performance génèrent des graphiques en cascade. Si vous êtes un nouveau à cette notion, vous pouvez créer votre propre graphique très facilement en entrant une URL dans WebPagetest. Certains autres outils comme Pingdom vous donnent ce graphique plus rapidement, mais ils ont toutefois un peu moins précis.

Comprendre un graphique en cascade

waterfall-basic

Start Render : Indique que le contenu commence à s’afficher dans le navigateur de l’utilisateur. Attention, cela ne signifie pas que le contenu affiché est important ou qu’il s’agit simplement de publicité.

Document complete : Le temps nécessaire pour la plupart des éléments de la page à s’afficher dans le navigateur. Aussi connu comme “Load Time” ou temps de chargement. Cette donnée est calculée en mesurant le temps que prend l’événement “window.onload()” à être déclenché. Elle est utilisée comme unité de mesure grossière de la performance d’un site. Ce n’est pas nécessairement un indicateur fiable pour connaitre le moment où une page devient utile.

Fully loaded : Représente le moment où toutes les ressources de la page, y compris les ressources externes qui ne sont pas visibles, ont chargé et que le processus est terminé.

waterfall-101

DNS Lookup

Cette requête permet de résoudre l’adresse IP liée au nom de domaine demandé pour s’y connecter.

Comment optimiser cet élément : Vous ne pouvez pas faire grand-chose pour optimiser les requêtes DNS et il ne devrait pas y avoir de problème sur la plupart des sites.

TCP connection

Cette barre indique le temps de connexion TCP/IP afin de lancer le téléchargement de chaque fichier. Il est difficile d’accélérer la connexion TCP. Vous contrôlez toutefois le nombre de connexions.

Comment optimiser cet élément : Si chaque requête de votre tableau possède une barre orange, c’est que vous avez un problème. Vous pouvez résoudre ce problème en poussant vos développeurs à utiliser ce qu’on appelle keep-alive afin de réduire le nombre de connexions TCP.

Negociation SSL

Je ne veux pas entrer dans les détails ici. Sachez seulement que les requêtes TLS obligent des aller-retour serveur supplémentaires. Ce qui prend forcément du temps.

Comment optimiser cet élément : Le même principe que les connexions TCP s’appliquent ici. Si chaque requête de votre tableau possède une barre violette, c’est que vous avez un problème. Vous pouvez résoudre ce problème en poussant vos développeurs à utiliser ce qu’on appelle des connexions persistantes afin de réduire le nombre de négociations TLS.

Time to first byte ( TTFB )

Probablement la donnée la plus importante pour votre SEO. Le TTFB est une mesure qui est utilisée comme indicateur de la réactivité du serveur. Cela correspond au temps avant la réception du premier octet pour une requête.

Comment optimiser cet élément : Plusieurs facteurs peuvent affecter le TTFB. La connexion Internet de l’utilisateur. La charge de travail que votre serveur doit effectuer avant de répondre à la requête et la distance entre le serveur et l’utilisateur.

Recommandations:

  1. Implémenter une solution de caching. Cette solution est absolument obligatoire pour améliorer la réactivité de votre site.
  2. Utiliser un CDN pour rapprocher les ressources de l’utilisateur.
  3. Réduire le nombre de ressources. En effet, vous devriez concaténer vos ressources CSS / JavaScript et utiliser les sprites d’images.

Content download

Représente le temps qu’il faut pour chaque ressource de la page avant d’être complètement téléchargé.

Comment optimiser cet élément : Si votre site possède trop de longues barres bleues,  vous devez réduire la taille des ressources par la minification et la compression.

Conclusion

N’hésitez pas à utiliser les graphiques en cascade pour diagnostiquer les problèmes de performance de votre site et concentrez-vous sur les éléments suivants:

  • La ligne verticale “Star render” doit être affichée le plus rapidement possible.
  • Réduire le nombre de lignes.
  • Réduire le nombre de barres oranges ( TCP Conection ).
  • Réduire le nombre de barres violettes ( SSL Negociation ).
  • Réduire la longueur des barres vertes ( TTFB ).
  • Réduire la longueur des barres bleues ( Content download).