Atelier sur la performance web du 21 avril 2011 – Compte-rendu

Chers débutants en web performance, j’ai testé pour vous l’atelier #webperf. Cela se passait le 21 avril, dans les locaux d’Octo, à Paris. Le but de la soirée était d’échanger autour de différents sites web et de proposer de quoi améliorer leur performance.
Il y avait du haut niveau dans la salle et j’ai donc eu l’occasion de saisir plein de mots, plein de notions à aller explorer.
Voici donc un petit « en vrac » de cette soirée.

Les outils

Voici une liste des outils qui ont été cités à l’occasion de cette soirée.

WebPageTest.org

www.webpagetest.org

Ancien AOL Page Test (qui lui permet de tester en local)
Je connais WebPageTest depuis quelques temps. Outre qu’il permet de simuler des tests de connexion en affinant les paramètres, il génère aussi des copies d’écran permettant de voir ce que l’internaute voit pendant le chargement. Voilà qui m’intéresse beaucoup.

Firebug

http://getfirebug.com/

Speed Tracer (sous Chrome)

http://code.google.com/intl/fr/webtoolkit/speedtracer/

Speed Tracer à l’avantage de renseigner aussi l’exécution du JavaScript (et pas seulement son chargement)

YSlow

http://developer.yahoo.com/yslow/

Google Page Speed

http://code.google.com/intl/fr/speed/page-speed/

DOM Monster

http://mir.aculo.us/dom-monster/

DOM Monster est un « bookmarklet » qui permet d’avoir de nombreuses informations sur le DOM et son chargement.

Dyna Trace

Dyna Trace permet de faire, sur IE et Firefox, du profiling JavaScript.

Mobitest7

http://www.blaze.io/mobile/

509inc.com

http://509inc.com/

(en beta pour l’instant – Androïd uniquement)

A noter également :
Akamaï donne régulièrement des statistiques par pays sur les connexions (à voir s’il s’agit de moyennes ou de médianes)

http://www.akamai.fr/enfr/stateoftheinternet/

Et bien sûr, le code source de la page (où j’ai pu trouver, moi aussi, une petite opti à faire, ouaiii !)

Les conseils à la volée

Les conseils ci-dessous ne représentent ni la totalité des optimisations à faire sur un site, ni la totalité de ce qui a été dit à la soirée WebPerf. Il s’agit de ce que j’ai réussi à noter et à (plus ou moins) comprendre.
De plus, chacun de ces conseils a été donné dans le contexte d’un site. Comme toujours, il ne s’agit pas de préconisation à appliquer à la lettre, mais ce sont des pistes à valider en fonction de chaque cas.

Images

• Utiliser, à bon escient toujours, la technique des « sprites CSS »
  http://www.pompage.net/pompe/sprites/
  http://www.alsacreations.com/tuto/lire/1068‐sprites‐css‐background‐position.html
• Prévoir un script pour charger d’abord les images du haut de page avant celles du bas de page (mais bien faire attention aux autres impacts notamment pour les mobiles)
• Indiquer la taille des images dans le code HTML
• Ne pas hésiter à mettre les vignettes en PNG, et même en PNG-8 car, dans une taille réduite, il n’y aura pas de perte visuelle.

CSS

• Ne pas séparer une CSS qui est appelée à chaque fois.
• Servir les CSS plutôt sur le même domaine que le HTML
• La CSS pour l’impression n’est pas utile dès le début. La télécharger, via un JS, à la fin (ou la concaténée avec une autre si elle est légère)
• Se poser la question de la nécessité d’une CSS spécifique pour IE 7. IE 7 étant le navigateur le plus lent de tous, autant ne pas le charger en plus.
• Dès qu’on utilise des commentaires conditionnels, insérer un commentaire conditionnel vide tout en haut. En effet, l’appel à commentaire conditionnel bloque 100ms.

CSS et JavaScript

• Mettre CSS et JS en cache
• Ajuster la durée de vie des CSS et des JS générés

HTML

• Limiter le plus possible les styles en ligne et les « document.write »

Marqueurs d’audience

• Réduire la taille de Google Analytics (une astuce permettrait de réduire le code asynchrone ; même si les différences seraient faibles selon certains tests, ça vaut toujours le coup). L’asynchone peut être mis en haut de page.

Serveur

• Utiliser un serveur type Nginx ou LightHTTPD pour traiter les demandes statiques et un serveur type Apache ou TomCat qui lui, enverrai les éléments dynamiques.
• Utiliser la méthode de « DNS prefetching »
  https://developer.mozilla.org/En/Controlling_DNS_prefetching
  http://performance.survol.fr/2009/06/dns‐prefetch/

Autres

• Fusionner les multiples fichiers CSS et les multiples fichiers JS
• Utiliser gZip qui peut gagner jusqu’à 90% de la taille d’un fichier
• Différer les chargements qui peuvent l’être
• Utiliser la technique du « flush » : envoyer par paquet : dès que x Ko sont prêts, les envoyer et ainsi de suite. Attention à l’affichage qui peut alors paraître chaotique à l’internaute.
  http://www.stevesouders.com/blog/2009/05/18/flushing‐the‐document‐early/
• Utiliser les eTags dans la mesure où ils ne font pas redondance avec le cache.
  http://performance.survol.fr/2008/06/desactiver‐les‐etags/
  http://en.wikipedia.org/wiki/HTTP_ETag
• Faire du domaine sharding (utiliser un sous‐domaine pour les images, par exemple, pour multiplier ainsi le nombre de téléchargement simultané par deux)

Je rappelle donc que ces conseils ne sont pas des vérités absolues mais bien des pistes à revoir en fonction du contexte.

Merci www.prelude.me pour les photos (et les réponses, ci-dessous, aux questions auxquelles je ne savais pas répondre !)