Ce post est le dernier d’une série de 3 et est tiré de l’expérience des finalistes du concours de performance Web 2010

Tout développeur Web sera content de voir que les bonnes pratiques de codage aident réellement les performances de rendu, en plus de leur intérêt propre. J’ai également résumé les enseignements que j’ai tiré de ce concours

HTML, markup et DOM

Quand on me dit qu’on peut accélérer le rendu d’une page en modifiant le HTML, je commençais généralement à rigoler doucement : comme pour le CSS, je n’ai vu aucune démonstration du phénomène Mais à bien y repenser je me souviens des grandes années du Web où j’étais passé de layouts à base de tables imbriquées à un mix de divs et de règles CSS externalisées : non seulement le poids des pages était réduit (et à cette époque pré-ADSL, c’était encore important) mais sur les machines de l’époque on pouvait sentir la différence de rapidité d’affichage. Et aujourd’hui on retombe parfois sur des sites dont la maintenance n’est pas évidente, l’équipe sous pression et où chaque ajout au design s’accompagne d’une pléthore de div et de règles CSS ultra spécifiques. Même sur nos machines modernes, avec IE7 le rendu peut être ralenti sans que l’on s’en rende vraiment compte.

Force est de constater que les concurrents qui ont simplifié à la main le HTML (réduction de 30% à 50% des 1900 éléments du DOM) ont constaté un réel gain de vitesse de rendu. Je n’ai aucun graphe pour le prouver (imaginez la difficulté pour mesurer cela), juste les ressentis concordants de plusieurs concurrents et un constat sur leurs pages finales.

L’ordre d’affichage a aussi son importance : sur une page statique comme ici, ça n’était pas visible, mais un site dynamique comme la FNAC pourrait très bien envoyer son contenu par blocs en flushant dès que possible des blocs de HTML. Certains comme Cédric Morin ont donc travaillé le CSS pour pouvoir mettre en premier dans la source les éléments importants comme la colonne centrale.

Produire du bon code !

Certains concurrents comme la jusqu’au-boutiste Alexandrine Boissière sont partis sur un refactoring complet du code, du HTML au CSS en passant par JavaScript ! Même si ça ne ressort pas forcément bien sur les graphes (par rapport aux autres finalistes), le rendu au premier affichage est parfait (on voit en moins d’une seconde le contenu principal), et la sensation de fluidité au scroll ou à l’utilisation est saisissante : attendez le chargement et scrollez sur la page originale et sur cette page. Ce n’est pas le genre de donnée qui se calcule, sauf peut être en regardant les courbes CPU, mais un robot ne peut pas le calculer.

IE7 avait visiblement du mal à afficher un arbre DOM aussi gros (213Ko bruts pour 2000 éléments) et avec autant d’erreurs : plus de 2300 erreurs repérées par le validateur pour du HTML4.01 Transitional, c’est rare. On peut donc imaginer que le parser de IE souffrait pour afficher la page. Certains finalistes ont :

  • diminué de moitié le nombre de noeuds du DOM, ce qui influence clairement sur la fluidité finale
  • nettoyé le HTML des erreurs qui ont peut être une influence sur le parser ( IDs non conformes,
  • supprimé les tableaux : IE a toujours eu du mal avec l'affichage de tableaux imbriqués
  • nettoyé les appels JS inline
  • corrigé des erreurs de HTML comme des URLs malformées (!)
  • enlevé les paramètres de session des URLs, pour les rajouter en JS dynamiquement

Au niveau CSS :

  • mise en place d'un reset.css, ce qui permet de supprimer beaucoup de déclarations
  • suppression des filter() IE, consommateurs de ressources. Je note au passage que cela augure du mauvais pour CSS3 : il ne faudra pas abuser des opacités, ombrages et autres tranformations ou transitions
  • séparation des CSS texte des CSS avec images encodées
  • nettoyage des règles CSS inutiles sur cette page, soit 75% de la feuille. Ce nettoyage est largement discutable, car on a affaire à une feuille pour tout un site. Cependant 3/4 de règles non utilisées, ça vaut le coup à mon avis de soulager le parser en créant un CSS par type de page, généré automatiquement en concaténant une feuille de style par module par exemple.
  • utilisation de CSS3 et de dégradation gracieuse pour les bords arrondis ou les effets de reflets. C'est un choix que nous cautionnions, même s'il faut bien avouer que peu d'équipes Web arrivent à échapper au diktat du pixel-perfect
  • utilisation de :before pour certains éléments répétitifs (IE6 n'était pas à prendre en compte)
  • dégradés gérés avec un seul PNG transparent, la couleur étant définie en CSS

Au niveau JavaScript il y avait pas mal de ré-écriture de code à faire, même si j’estimais personnellement cela hors-sujet du concours. Certains candidats ont pourtant gagné en fluidité grâce à cela. Je les cite en vrac :

  • remplacement du widget d'autocomplete
  • moins de manipulations de DOM
  • plus de cache sur les variables
  • optimisation des sélecteurs jQuery
  • accès par ID et moins par sélecteurs (opinion personnelle : jQuery habitue mal les développeurs)
  • suppression du document.write()
  • remplacer les modifications de style sur des éléments par des changements de classe
  • mutualiser les XHR qui récupéraient les infos de stock

Les enseignements du concours sur la performance Web

  • MHTML est très consommateur de CPU et met à mal IE7. A utiliser avec précaution et lui préférer les sprites si nécessaire
  • la taille du DOM et sa complexité jouent réellement sur la vitesse et la fluidité d'affichage
  • diviser par 10 le temps de rendu et améliorer la fluidité d'une page comme La Fnac a maintenant un prix : une semaine à temps complet pour un développeur dans les conditions d'une page statique. A vue de nez, pour industrialiser cela, il faut peut être décupler ce temps ?
  • les optimisations de base sont déjà très efficaces et faciles à faire, mais dans ce cas ne suffisent pas : il faut peut être envisager un refactoring
  • les bonnes pratiques du développement Web et l'organisation de son code HTML/CSS aident réellement à garder de bonnes performances
  • les meilleurs concurrents étaient également les mieux organisés : versioning, tests automatisés des fonctionalités, processus de mise en ligne... Ils étaient également les plus clairs dans leurs notes ce qui je pense n'est pas un hasard
  • il y a des consultants en performance qui ont participé mais les finalistes et les vainqueurs ne disent pas être des pros de la performance Web. Juste beaucoup de travail, des bonnes pratiques et de l'auto-formation avant et pendant le concours
  • dans les techniques utilisées, il n'y a eu que du connu, malgré la cinquantaine de cerveaux qui se sont réellement penchés sur la question. Cela signifie peut être que l'on a fait le tour des techniques Webperf, et que le combat sera maintenant de les industrialiser et d'en répandre l'usage.
  • en France on n'a pas de pétrole, mais on a de bons Webdevs. Les 2 tiers des participants étant français, on peut se dire qu'il est statistiquement normal d'avoir 3 gagnants français. Mais si on regarde la quinzaine de finalistes en haut du tableau, il y a sur-représentation.