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.

_MG_7166

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

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

Autres

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

Pour se tenir informé des prochains événements webperf_fr :
https://sites.google.com/a/survol.fr/webperf‐user‐group/ (flux RSS disponible)
https://twitter.com/#!/webperf_fr

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

9 réponses sur “Atelier sur la performance web du 21 avril 2011 – Compte-rendu”

  1. « Indiquer la taille des images dans le code HTML » : sauf que sur mobile, ça bloque la technique du « maw-width: 100% » qui permet de limiter la largeur des images.

  2. Merci Delphine,

    est-ce que tu saurais me dire pourquoi c’est mieux de stocker le css sur le même domaine que le html stp ?

    Est-ce que la perte est visible si c’est hébergé sur deux domaines différents ?

    merci,

    Adri.

  3. CSS sur le même domaine : sur un autre domaine, il va falloir faire la résolution du nom de domaine avant de recevoir le fichier. Du coup, l’affichage de la page va en être d’autant plus ralenti.

  4. Merci pour cette réponse.

    Du coup c’est seulement au premier appel que tu perds un peu de temps ou est-ce que c’est à chaque appel vers ce serveur ?

    Je pensais que le fait d’héberger sous un autre domaine permettaient aux navigateurs suivant leur capacité à faire des requêtes multiple, du coup ce qu’on va gagner en requête multiple on va le perdre au niveau de la résolution du dns ?

  5. Tout à fait. Il faut faire des tests (je vais produire un article prochainement sur ce sujet justement).
    En gros, si plus de 10 images sur une page, ça peut-être intéressant en alternant le domain sharding et le domaine principal.
    Après quoi, il n’y a pas de cookie sur le domain sharding, donc moins de bande passante.
    Reste que les navigateurs « modernes » ont 6 connexions simultanées. Reste que IE6 et IE7 avec 2 connexions.

Laisser un commentaire

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