Se retrouver à présenter la méthodo Opquast (car oui, vous n’êtes pas surpris, c’était basé sur Opquast), c’est aussi se rendre mieux compte de comment elle est cadrée et robuste.

Je ne reviens pas dessus, ici ; c’est plutôt l’objet du résumé de la présentation sur Webperformance France.

Par contre, je reviens sur l’atelier. Sur cette partie là, j’ai été autant la spectatrice que l’animatrice. J’ai vu les groupes se mettre au travail densément, en jouant le jeu du cadre à respecter (ou pas). Les niveaux au sein d’un même groupe étaient inégaux, les profils différents. Cela contribuait d’autant à la richesse des échanges.

J’ai aussi vu (et retenu !) comment Élie s’y prenait pour l’animation de ce type d’atelier. Les points de vigilance, quelle aide apporter comment aux groupes, etc.

Merci donc à tous pour votre participation.
Ça a été une belle expérience pour moi d’animer ce premier (ben oui, on peut rêver !) atelier.

Pour se tenir au courant :
www.webperf-france.net et @webperfParis

Jean-Pierre Vincent : « Merci à Anthony d’avoir repris les soirées ».

Merci 20minutes pour l’accueil (ce n’est pas facile de trouver une salle, si vous avez des options, parlez-en à Anthony il sera content)

Trois parties :

1. Organisation et présentation du concours par Vincent Voyer
2. Les techniques des participants à retenir par Jean-Pierre Vincent
3. Présentation de la participation du gagnant « start render et onload » par le gagnant en question, Cédric Morin

Encore une fois, il s’agit juste de notes. Les trois supports de présentation sont en ligne, le site du concours est disponibles et contient toutes les infos, les vidéos vont arriver.

Merci Vincent, Jean-Pierre et Cédric.

1. Organisation et présentation du concours

Vincent Voyer – @zeroload – http://fasterize.com/
Jean-Pierre Vincent

Le concours : optimiser le site web d’un client et classer les participants (lots grâce aux sponsors).
octobre – novembre 2010
Organisé par Eric Daspet, Jean-Pierre Vincent et Vincent Voyer.
http://webperf-contest.com/

Il fallait un site web représentatif, à fort trafic et d’accord pour donner son site comme exemple de mauvaise optimisation de la perf.
La FNAC a accepté. Le site était intéressant parce qu’un des très gros acteurs français + site avec beaucoup de pages et un historique ; le tout faisait qu’il y avait matière à amélioration.

La page ciblée était la page enfants : www.fnac.com/enfants.asp
(NB : Les optimisations sorties du concours semblent ne pas avoir été implémentées)
4′ avant le début de l’affichage
17′ avant images telles qu’ont peut s’y attendre dans un catalogue
Freeze au démarrage pendant la première seconde

Jury : pas que les chiffres mais également le style, le respect de l’utilisateur, etc.

50 participants qui devaient devaient suivre des règles.
Et comme il n’y a pas que les chiffres dans la vie, le « style » comptait aussi :

• rendu progressif du site
• temps avant premier rendu significatif (= disponibilité de l’interface)
• faisabilité de l’optimisation en environnement de production
• réalisation des optimisations (lazyload ne se remarquant presque pas, SEO, accessibilité)
• explications détaillées de la part du participant

3 gagnants :

• Plus bas nombre de requêtes et poids de la page : Alexandrine Boissière
• scrore YOTTAA : Gaël Métais
  (score calculé avec www.yottaa.com)
• Meilleur start render et onload : Cédric Morin

Les 3 gagnants affichent les premiers éléments en dessous de 1,5 secondes et la totalité entre 3,5 et 5 secondes.

2. Les techniques des participants à noter

Jean-Pierre Vincent –

LES TECHNIQUES DE BASES

• Gestion du cache navigateur
• Compression gzip
• Cookie (uploadé lors des 115 requêtes)
  • sous-domaine pour statique
  • redéfinir le cookie sur www.*
• Images :
  • la page avant optimisation contenait 80 images pour 500k. Une optimisation raisonnable (avec une qualité correcte) donnait 250k.
  • png 8bit
  • Introduction du nombres de couleurs
  • Outils tels que jpgtran, pngcrush…
• Concaténer et minifier

LES TECHNIQUES DE LA MORT

Limiter le nombre de requêtes HTTP

CSS

Difficile (et encore assez nouveau à l’époque)

• minifié, concaténé / gzipé
• nettoyage à la main (mais délicat dans un contexte d’industrialisation) : 28 à 12 ko
• certains ont réussi à charger le CSS après le lancement de la page : star render à 200ms …mais la page s’affiche sans aucun style ! et le CSS était dépendant de JS.
• CSS inline : 2-3 ko de CSS en inline pour le layout et le reste ensuite via JS (bon 1er rendu, pas de dépendance JS mais pas de cache)

JS

Même gzipé cela faisait 60ko

Utilisation de <script defer> qui permet de charger de manière asynchrone et native le JS mais il y a du coup des corrections à faire à la main.

Paralléliser les téléchargements des JS : 70ms de gain mais il y a un pb de dépendances (souvent un des JS devaient attendre l’autre pour s’exécuter)

Lazy-loading (= télécharger le + tard possible images et JS) :

• Certains ont fait des téléchargements « onmousemouve » : technique de la mort mais qui donne une expérience utilisateur très mauvaise et il y a une dépendance à JavaScript.
• Avoir géré l’absence de JS était donc un plus auprès du jury.
• Le footer était affiché dans une iframe. La contrainte du concours était de garder cette iframe. Certains ont donc utiliser le lazy-load pour l’iframe.
• Le champ de recherche contenait de l’auto-suggestion. Là aussi, certain ont utiliser lazy-load : le JavaScript n’était appelé qu’au moment où l’internaute cliquait dans le champ.

Encoder les img en base 64 : 0 requête, mais 30% de poids par image (5 à 10% après gzip), pas de cache HTML et CSS spécifique IE

Tout encoder – en une seule requête ! Immédiat en téléchargement mais plusieurs secondes de charge CPU (8 secondes pendant lesquelles on ne peut rien faire).

DERNIÈRE ULTIME TECHNIQUE

…Savoir coder !
Ceux qui ont passé du temps à recoder le site y ont gagné beaucoup :
avant : 2000 nœuds DOM / 213 ko
après :  50% des nœuds / 50% du HTML
> ressenti utilisateur hyper optimisé

Certains ont repris le CSS :

• Reset CSS
• Suppression des filter() (dégradation gracieuse acceptée par le jury)
• Utilisation de :before (même si cible IE7)
• Dégradé png transparent

CONCLUSION

Le temps d’affichage a été divisé par 10 entre la version initiale et celles des gagnants.
Les techniques de base représentent 70% du gain.

Conclusion personnelle de Jean-Pierre :

• Les gagnants n’étaient pas des pro de la perf web mais le temps passé a payé
• Les bonnes pratiques de codage : ça paye aussi (en maintenance mais aussi en perf)
• L’époque des grandes découvertes est-elle finie ? Jean-Pierre a l’impression que oui.

Enfin :
À quand le prochain concours ?! (sur le mobile ? comme critère du Summer Refresh d’Alsacréations ?)

Voir :  braincracking.org/category/articles/performances/ : articles de JP Vincent suite au concours.

3. Présentation de la participation du gagnant « start render et onload »

Cédric Morin – yterium.net

.htacess

• forcer la compression gzip (deflate) sur HTML, JS et CSS
• forcer des expire lointains sur fichiers statiques

Images

• optimisation
• preloading en début de <body>
• Sprites CSS (images qui ne portent pas d’information, regroupement logique, injectée en image de fond CSS et optimisation du menu)
• Carrousel et animation : affichage avec une première image statique légère avant déclenchement via JS

Chargement asynchrone des morceaux de page

(paralléliser la construction de la page avec le chargement des ressources pour envoyer le HTML le plus vite possible)

• L’accessibilité (et référencement !) a été gérée via un hack <noscript> qui redirige le visiteur vers une version assemblée côté serveur.

Lazy-loading

• en envoyant les images sans attribut src
• en prévoyant, là aussi, une alternative si n’y a pas de JavaScript

CSS

• découpage des déclaration en unités logiques fonctionnelles > une feuille de style par unité logique
• une seule CSS servie générée automatiquement et qui inclue uniquement les feuilles de style nécessaires
• minification
• remplacement d’image par du CSS
• attributs width et height renseignés pour toutes les images

JS

• uniquement JS externes (un script par fonctionnalité)
• concaténation des JS en un seul
• minification
• appel des JS en pied de page (mais contexte spécifique ici)
• chargement en parallèle et asynchrone de deux fichiers JS
• JS de l’auto-complétion n’est chargé qu’au focus sur le champ

Requêtes JSON

• une seule requête (éléments en argument, tableau de réponse, dispatching à la réception)

HTML

• minification (espaces redondants et commentaires)
• suppression de toute mise en page en tableau et utilisation d’un layout
• reprise du code du menu pour qu’il soit lisible sans les images

Cookies

• utilisation des sous-domaines au maximum pour images et CSS
• JS, morceaux de page asynchrone, et JSON servis sur domaine principal

Cédric explique ses choix, donne ses sources et des détails dans son article et dans son diaporama :

Tout a été versionné et est à disposition sur : https://github.com/Cerdic/webperf-contest-2010/

(Certains des ) outils  cités :

• optimisation des image : ImageOptim
• pour les sprites CSS : http://spriteme.org/
• lazy-loading sur images : jquery.lazyload.js
• génération d’une CSS à partir de plusieurs : Sever Side Inclusion
• Minification de CSS : CSS Tidy
• Concaténation des JS : Server Side Inclusion
• Minification des JS : Google Closure Compiler – http://closure-compiler.appspot.com/home
• Chargement parallèle et asynchrone de JS : https://github.com/Cerdic/jQl
• Layout pour avoir le contenu HTML en premier : LayoutGala – http://blog.html.it/layoutgala/

Un navigateur, comment ça marche ?

> comprendre le navigateur pour aider à faire des choix.
Anthony Ricaud

Introduction

Cette présentation n’a, initialement, pas été faite dans le contexte de la performance web. Elle permet de comprendre ce qu’un navigateur fait lors d’une requête (et cela inclue les temps d’attente et de traitement.)

D’un point de vue optimisation de la performance, les éléments présentés ci-dessous sont souvent minimes.

Voir les liens qui ont permis à Anthony de préparer sa présentation : Blogmarks > Marks de Rik lié au tag « navigateur-marche ».

Le navigateur a énormément de choses à traiter (parser les URL, rendu des polices, s’adapter aux OS, téléchargement, etc.)
Ici, on va voir ce qu’il se passe depuis la requête (clic sur un lien ou barre d’adresse) jusqu’au chargement de la page.

La requête et la réponse

La requête est envoyée. Nous sommes ici dans le cas où tout se passe bien. Le navigateur lit alors les premières lignes du html pour choisir le mode qu’il va appliquer pour interpréter la page.
Il y a trois modes possibles : xml, quirks et standard.

Avec « Content-Type: application/xhtml+xml » > Mode XML

Il est très peu utilisé parce que IE ne le supportait pas jusqu’à la version 9 et parce qu’en cas d’erreur : ça se voit
Pas de pb de performance par contre.
=> Tous les navigateurs sauf IE 7 et 8

Avec « Content-Type: text/html » > Mode Quirks

Modifie le box model (celui du W3C ou celui d’IE)
=> Tous les navigateurs

Avec un doctype > Mode Standard

Considère le doctype comme un indice, au moment où ça a été créé, de la qualité du code.
=> Tous les navigateurs

Les navigateurs se fichent des versions de spécifications (HTML5, HTML4, XHTML1.0, CSS3, etc.)

Conseil aux intégrateurs : d’un point de vue pragmatique, il vaut mieux se référer à ce qui est implémenté et fonctionne plutôt qu’aux specifications qui ne sont pas toujours à jour.

Le DOM

= la compréhension qu’a le navigateur du HTML qu’il stocke en mémoire
C’est le DOM qui est manipulé par JS.
Il est composé de nœuds éléments et de nœuds texte.

NB :
Même si espaces et retours à la ligne créent des nœuds texte vides, il n’est pas préconisé de minifier le HTML : le gain serait négligeable alors que parallèlement, il y aurait des problèmes de rendu à gérer.

Le HTML sera identique dans tous les navigateurs à partir de IE9/10. C’est-à-dire, par exemple que l’erreur <p><strong></p></strong> sera interprétée de la même manière par tous les navigateurs.

Les sous-ressources

Pendant que le navigateur récupère le HTML, il va chercher les sous-ressources (images, les CSS, JS).

Les images

C’est non-bloquant, le téléchargement continue.
Le décodeur (le machin qui traite les images) n’a pas non plus d’impact sur le temps de traitement car il compose l’image de son côté et l’envoie quand elle est prête.

Le CSS

C’est non-bloquant, le téléchargement continue.

CSS Buckets

Le navigateur ne prend que les sélecteurs et les place dans des « seaux » (hashtable) :

• id : #sidebar ; div#sidebar pour une raison de spécificité
• class : .item
• tagname : div
• autres : :visited

Dès qu’il y a un combinateur de sélecteurs( espace , « ~ », « > » et « + »), c’est celui qui est le + à droite qui l’emporte

Les sélecteurs dans Autres vont ralentir la performance.

CSS maching

Les navigateurs prennent tous les nœuds et vont chercher les règles CSS qui leurs correspondent.

div#sidebar et #sidebar sont dans le même seau mais div#sidebar oblige à une vérification de plus.
Dragonfly sort un profiler de CSS qui va permettre de voir les performances de chaque sélecteur (beta). En effet, sur la performance de sélecteur, il y a beaucoup de  cas particulier. (un outil du même type est en préparation chez Webkit)

• div p : on ira pas chercher « div »
• ul p : il faudra vérifier tous les parents avant de passer à la suite
• ul > p : il n’y a qu’un parent à remonter
• body > div p : il a dû monter et descendre beaucoup de fois pour établir la règle

Là encore, à moins d’avoir un très grand DOM ET un très grand nombre de sélecteurs, tout ça est négligeable en matière d’optimisation de la performance. S’il n’y avait que deux choses à avoir en tête :

• Plus un sélecteur est court, plus il est rapide à analyser.
• Essayer d’avoir le moins possible de sélecteur dans « Autres »

(webkit stocke + d’informations sur le DOM pour pouvoir descendre et remonter dans les noeuds plus vite ensuite)

Render Tree

Les images et le CSS ayant été traités, le « render tree » peut être fabriqué.

Reflow ou layout (selon les navigateurs)

A moins d’un timeout ou d’un JS qui demande une position, le reflow n’est lancé qu’une fois que toutes les CSS ont été chargées.

Chaque bloc est placé dans la page selon sa position et sa taille.

> Voir la vidéo sur Wikipédia Japon qui montre le reflow
On voit dans la vidéo qu’il commence par le centre, fait le côté et, à la fin …recommence : car il se rend compte en bas de colonne de gauche qu’il n’a pas assez de place en hauteur et qu’il doit donc ajouter un ascenseur à droite. Il recalcule alors les largeurs en fonction.

NB : Sur IE, la scrollbar est mise d’office.

A ce propos, Vincent Voyer
propose une astuce : « Forcer la barre de défilement et empêcher un reflow au chargement : body{overflow-y: scroll;} »

NB : Chrome et Safari ont des outils géniaux pour se faire une idée également de ce qui se passe pour l’affichage de la page. Voir aussi Firefox Affiliates.

Le reflow est donc une étape relativement longue (compte-tenu de notre échelle). On peut donc garder en tête de veiller à ne pas générer de reflow inutiles.

Les 2 cas fréquents qui déclenchent le reflow alors que cela pourrait être facilement évité :

• images dans le code HTML sans width / height
• l’insertion des Flash avec des librairies JS comme swfobject

Painting

= la vue de ce qui est affiché à l’écran

Avant, c’était le processeur qui dessinait tout. De ++ c’est le GPU (Processeur Graphique) (+ puissant pour ces tâches (dont les transformations pour certains navigateurs)

Le JS

Rappel : c’est bloquant (= le parseur s’arrête et télécharge, interprète et exécute le JS avant de continuer)
Depuis deux, trois ans, un parseur secondaire va chercher en parallèle les URL (pour gagner un peu de temps) mais pas plus

Il  y a des opérations JS hyper rapide. par contre, les éléments entres JS et DOM prennent forcément du temps.
Le DOM c’est lent.
Si on demande des dimensions, on déclenche le reflow : faire toutes les demandes de lecture au début et ensuite seulement toutes les écritures.

EX : si on change couleur ou opacité, par exemple, pas de reflow déclenché

Display none libère de la mémoire mais est plus long à remettre en place.
Visibilty hidden : ne libère pas de mémoire mais est ré-affiché plus vite.

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 !)