La performance web côté client : partie 1

Pourquoi est-ce important de se concentrer sur le front end pour améliorer la performance des sites ?

Notre ami Steve Souders, chef de la performance web chez Yahoo nous donne la réponse. Voici la répartition du temps de traitement du back end et du front end des 10000 sites les plus visités au monde :
top_sites
(source : http://www.stevesouders.com/blog/2012/02/10/the-performance-golden-rule/)

Nous voyons donc que le temps de chargement des pages est pratiquement entièrement dû au front end. Si nous travaillons bien cet aspect, nous pouvons donc nous attendre à des gains importants de performance.

Limiter le nombre de requêtes

Les allers-retours entre le client et le serveur (les requêtes HTTP) sont très coûteux en performances. Il est donc crucial de limiter au maximum le nombre de requêtes faites au serveur.
Il est plus profitable de faire peu de requêtes un peu plus lourdes que de nombreuses requêtes plus légères.

Pourquoi ?
Car pour chaque requête différente faite il y a un appel au serveur, le traitement de la requête, et son retour vers le client. A chaque requête du client et réponse du serveur, il y a des entêtes HTTP qui ont un poids, et augmentent donc la quantité de données transférées. De plus, il y a la latence du réseau, qui consiste au temps pour joindre le serveur et au temps pour que le client reçoive la réponse du serveur.
Ce temps est d'autant plus important qu'il y a d'utilisateurs sollicitant le serveur au même moment. Il est donc très intéressant de limiter au maximum les requêtes.

Voyons quelques techniques pour réduire le nombre de requêtes :

Faire un sprite CSS :

Souvent, un site possède de nombreuses images de décoration (pictos, icônes, textures...). Elles sont appelées via le CSS. Si chacune est appelée individuellement, cela crée autant de requêtes HTTP qu'il y a d'images.
Une technique connue pour éviter cela est de regrouper toutes les images de décoration en une seule, appelée sprite CSS. Voici par exemple un sprite pour afficher un drapeau différent à divers endroits du site, au lieu d'avoir un fichier par drapeau :

sprite_ok.jpg

Il est utilisé partout dans le site, mais seule la portion exacte du sprite nécessaire à l'endroit en question est affichée, en donnant ses coordonnées en CSS.
sprite_css.jpg

Faire un seul fichier CSS si possible :

Souvent, il faut faire des styles CSS spécifiques à Internet Explorer (IE), car il interprète différemment plusieurs règles. En général, les intégrateurs appellent le fichier CSS de base, puis ciblent IE par des commentaires que seul lui comprend (les commentaires conditionnels). Ils appellent dans ces commentaires un fichier CSS, qui ne sera lu que par IE, pour appliquer les corrections spécifiques à IE.
Le problème est qu'en faisant ainsi, IE télécharge le fichier CSS de base, PUIS le fichier CSS pour IE. Donc 2 fichiers, donc 2 requêtes HTTP vers le serveur.

Méthode classique :
html_classes_ancien.jpg

On peut avoir le même résultat en faisant une seule requête en procédant comme suit :
html_classes.jpg

Nous mettons des commentaires conditionnels sur l'élément <html>, en écrivant la version de IE détectée en tant que classe de l'élément <html>. La page vue depuis IE 8 aura les classes "ie8" et "lt-ie9" sur l'élément <html>.

Chaque version de IE ciblée par le commentaire conditionnel aura une classe précise sur l'élément <html>, et lira le CSS lui correspondant.
Puis en CSS, nous écrivons le fichier comme d'habitude, et à la fin, nous mettons les styles spécifiques pour IE ciblés grâce à la classe de l'élément <html>.

html_classes_css.jpg

En mettant ce code tout à la fin du fichier, nous avons le même résultat qu'en faisant 2 fichiers : ce qui est lu à la fin écrase les styles de base. Mais avec un seul fichier.

Faire du "domain sharding" (répartition des ressources entre domaines) :

Les navigateurs ont une limite au nombre de ressources qu'ils peuvent télécharger depuis un hôte. Actuellement, ils ne peuvent télécharger que 6 ressources maximum simultanément venant d'un même nom de domaine. Le téléchargement de toutes les ressources sera fait par groupes de 6. Une fois les 6 premières téléchargées, les 6 suivantes le sont, et une fois terminées, les 6 suivantes etc...
L'affichage de la page est donc d'autant plus long qu'il y a de ressources à télécharger.

Une solution pour accélérer le chargement est de répartir les ressources sur plusieurs nom de domaines, car cette restriction de 6 téléchargements simultanés est valable par nom de domaine. Avec les ressources sur 2 noms de domaines, nous avons donc 12 téléchargements simultanés.

Cette méthode s'appelle le domain sharding.

Exemple de site : ressources téléchargées sans domain sharding
sharding_no.jpg

Exemple de site : ressources téléchargées avec domain sharding
sharding_yes.jpg

Nous voyons que sans domain sharding, seules quelques ressources sont téléchargées en même temps, ce qui allonge énormément le temps total pour tout rapatrier.
Avec le domain sharding, bien plus de ressources transitent en même temps, le temps total peut être considérablement réduit.

Attention à utiliser cette technique avec précaution, elle n'est pas rentable dans tous les cas de figure. En effet, chaque connexion à un nouvel hôte implique un temps de connexion, de résolution DNS, qui s'ajoute au temps de téléchargement des ressources. Il faut donc avoir assez de ressources pour que cela en vaille la peine, et en aucun cas il n'est conseillé de dépasser 4 noms de domaines différents (lé résolution DNS prendrait trop de temps).

Youtube exploite cette technique pour toutes les images miniatures des vidéos, ce qui est nécessaire vu leur nombre ! Si vous regardez l'URL de ces images, vous verrez qu'elles sont réparties en 4 domaines :
i1.ytimg.com, i2.ytimg.com, i3.ytimg.com et i4.ytimg.com

Concaténer les scripts et les CSS :

Nous avons vu que chaque requête HTTP est coûteuse en performances et qu'il faut les économiser. Avoir plusieurs fichiers CSS et JS n'est donc pas optimal. Cependant, il est souvent impensable de faire autrement en phase de développement. Si nous sommes plusieurs à travailler sur différentes pages, il nous faut en général plusieurs fichiers.

Mais une fois que le développement fini, il est très recommandé de regrouper tous ces fichiers autant que possible : un seul fichier CSS et 1 ou 2 fichiers JS dans l'idéal. A voir au cas par cas, il ne faut pas alourdir énormément le CSS et JS appelés sur toutes les pages si la plupart du code n'est utile que sur une page. Mais cette méthode est souvent indispensable. Cela peut être fait manuellement ou par des scripts qui concatènent le Javascript. Ainsi nous diminuons le nombre de requêtes.

La suite de ce billet est dans la partie 2, ici !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.