Kiwi Party 2013 : accélerer ses pages Web

Après les CSS pour les livres numériques, Google Analytics et l’ergonomie et l’accessibilité, voici le compte-rendu d’une autre conférence suivie lors de la Kiwi Party : les techniques d’accélération de ses pages web, présentée par Jean-Pierre Vincent (lien externe).

Ayant loupé le début de la conférence (temps pour déjeuner et rentrer un peu plus long que prévu 😛), mon compte-rendu commence là où j’ai commencé à suivre. Ça correspond au slide 8 de sa présentation disponible sur Slideshare (lien externe).

Le coût de l’absence de performance

Bref, au moment où je fus enfin installé, Jean-Pierre parlait du coût d’une seconde de perdue au chargement d’une page. 1 seconde de perdue correspond à :

• 7% de conversions en moins dans un tunnel d’achat ;
• une baisse de 6% des vues sur une vidéo ;
• 50% de conversion de perdus sur un site e-commerce ;
• 10% de pages vues en moins sur mobile.

Il conclut sur ces chiffres éloquents en rapportant que 60% des personnes sur mobile abandonnent complètement après 4 secondes d’attente. Autant dire que l’absence d’optimisation de la performance de nos pages web peut coûter très cher, ou du moins rapporter beaucoup moins !

Gestion de la performance web

Les chiffres parlent d’eux-même, il est crucial de mettre en place une gestion de la performance web. Jean-Pierre détaille alors les étapes de ce chantier :

1. Fixer des objectifs
2. Mesurer
3. Coder
4. Surveiller

Ce n’est pas une coïncidence de retrouver les étapes de la gestion de la qualité. La performance fait partie intégrante des domaines directement lié à la qualité d’un site ou d’un service web. Et ce n’est pas la checklist webperf d’Opquast (lien externe) qui contredira ça.

Accès à la fonctionnalité et premier rendu

Concernant les objectifs, Jean-Pierre présente les 2 principales métriques à prendre en compte :

• L’accès à la fonctionnalité. Le nom parle de lui-même, il s’agit du temps nécessaire avant de pouvoir accéder et interagir avec la fonctionnalité.
• Le premier rendu. Un peu plus technique, il s’agit du temps nécessaire pour afficher le premier pixel. C’est à dire le temps pour afficher le premier contenu.

Ces 2 données sont très proches mais peuvent être « vécues » par l’utilisateur très différemment suivant le code de la page. Par exemple, suivant que les scripts sont placé dans l’entête du document ou en bas de page, le premier rendu sera beaucoup plus long (si les scripts sont dans l’entête) tandis que le temps d’accès à la fonctionnalité ne sera pas nécessairement différent.

Pour mesurer ces 2 métriques, plusieurs outils sont disponibles.
Concernant l’accès à la fonctionnalité, il s’agit surtout de scripts à insérer dans sa page comme Google Analytics « User Timings » (lien externe) ou Boomerang (lien externe).
Pour mesurer le premier rendu, il cite particulièrement WebPagetest (lien externe).

Passée la présentation des outils de mesure, Jean-Pierre parle du chemin critique.
Le chemin critique, c’est tout ce qu’il se passe entre l’ouverture de la page et le premier rendu. Et c’est donc là qu’on doit travailler.
Les principaux éléments sur lesquels on peut jouer sont les redirections et les appels aux fichiers externes : CSS, scripts et fonts.

En résumé, voici les actions qu’on peut mener :

• Redirections : faire maximum 1 redirection. Ne pas faire de redirection en javascript et privilégier une solution côté serveur.
• CSS : concaténer et minifier les feuilles de styles. Avoir maximum 2 feuilles de styles.
• Fonts : limiter leur usage. En cas d’utilisation de font, prêter une attention particulière au poids (50 ko maximum) ainsi qu’à sa compatibilité (OS/navigateur). Privilégier un chargement asynchrone.
• Javascript : sans doute le domaine où il y a le plus de travail de gain à espérer. En fonction des cas, on pourra privilégier d’appeler les scripts en bas de page ou en haut de page, on peut utiliser les attributs defer ou async.
  • On placera les scripts en bas de page si la page est légère, qu’il n’y a pas de dépendance ou de document.write dans la page. Il faut aussi savoir que cette technique n’a aucune influence sur iOS.
  • L’attribut defer permet de mettre en attente l’exécution du javascript jusqu’au chargement complet de la page. Habituellement, le temps d’exécution du javascript met en pause le chargement du reste de la page, utiliser cet attribut permet d’exécuter le script une fois la page entièrement chargée.
  • Le chargement asynchrone permet de bloquer le chargement des scripts tant que la page n’est pas chargée. Mais cela implique de respecter des contraintes fortes comme la nécessité de gérer une file de téléchargements ainsi que la priorité et les dépendances entre les différents scripts. C’est donc une pratique à réserver aux équipes expérimentées. Heureusement des outils existent pour faciliter le travail. Il cite notamment LABjs (lien externe) et RequireJS (lien externe).
  • Enfin il conseille de conserver l’appel des scripts en haut de page s’ils répondent à quelques conditions : s’il n’y en a pas plus de 2 et s’ils sont optimisés (légers, concaténés…)

En conclusion il n’y a pas de recette miracle, seulement une diversité de solutions à utiliser ou non en fonction du contexte.

L’affichage de la page

Jusque là on a parlé uniquement de tout ce qu’il se passe avant que la page ne commence à s’afficher.
Naturellement, il y a encore beaucoup de choses à optimiser après cette étape. L’affichage de la page, c’est à dire le HTML et tous les contenus qui y sont appelés, peut être aussi amélioré à de nombreux niveaux.

Ça commence par la mise en cache des ressources. Selon la complexité et la fréquence des mises à jour des contenus, il peut-être utile de mettre en cache la totalité des pages web. Le cas échéant, les ressources de la page ne seront chargées qu’à la première connexion et toutes les connexions suivantes exploiteront les contenus mis en cache. Différentes solutions existent : cache serveur, mécanisme de cache intégrés aux CMS, outils spécialisés comme Varnish (lien externe)…
Bien sûr, tous les sites ne peuvent pas être totalement mis en cache. Par exemple sur les sites de e-commerce, certains contenus doivent être constamment frais (prix, stocks…).
Il convient donc de mettre en cache toutes les ressources statiques (notamment tout ce qui relève purement de l’interface) et d’y insérer des contenus dynamiques à la demande avec XHR ou SSI par exemple.
L’exemple extrême de cette logique est Facebook dont la quasi-totalité du contenu est personnalisé pour chaque utilisateur.

Enfin, le dernier indicateur important à prendre en compte est le temps nécessaire au chargement complet de la page ou « onload », incluant l’ensemble des ressources présentes dans la page. Cet indicateur est particulièrement important pour le référencement car il fait partie des critères pris en compte par Google dans son algorithme.
Les principales ressources problématiques sont les images, les objets flash et vidéo et les iframes.

Jean-Pierre se concentre sur le cas des images et donne toutes les pistes d’optimisations possibles :

• Remplacer les images de décoration par des caractères unicodes ou des effets CSS3 (dégradés, arrondis, ombres, rotations, opacités…)
• Charger les images « à la demande » avec la technique du lazy-load (lien externe)
• Réduire le nombre d’images à l’aide des sprites. Pour une maintenance plus facile, un pré-processeur CSS peut être utilisé.
• Limiter le nombre de requêtes en encodant les petites images en base64 (attention à IE8 et inférieur cependant).
• Utiliser le meilleur format d’images possible en fonction de chaque cas (PNG pour les images avec aplats ou textes, JPG pour les images photo-réalistes) et utiliser les outils de compression automatique pour réduire le poids des images au maximum.

Enfin, toujours concernant les ressources appelées dans la page, il est nécessaire de porter une attention particulière à toutes les ressources fournies par un tiers.

Pour finir, Jean-Pierre présente une grosse liste d’outils et techniques pour gérer son cache et monitorer les performances de son site. Je ne vais pas tout lister ici car la liste et longue, je vous conseille donc plutôt de consulter sa présentation sur Slideshare (lien externe). 😉

Conclusion

Voilà pour cette conférence extrêmement riche et intéressante ! 😀
Personnellement, je trouve que c’est un sujet passionnant mais aussi complexe. Ça demande des connaissances et compétences techniques avancées si on souhaite s’investir réellement dans une démarche d’amélioration des performances de son site. Mais une présentation comme celle-ci donne toutes les informations nécessaires pour creuser la question sérieusement, et ça donne vraiment envie de scruter de prêt les résultats des sites qu’on produit.
Comme dirait l’autre, y’a plus qu’à ! 😛