Aller au contenu

Retour sur le Webperf contest 2010

Avant de commencer, rappel sur l’organisation et les soirées à venir :
Normalement, tous les 2ème lundi du mois.
webperfParis est preneur de vidéos et de compte-rendus.Si vous avez des idées de sujets (à présenter ou à réclamer) faites un mail à Anthony.Prochaine soirée : 13 février – Atelier de mise en place d’un référentiel de bonnes pratiques webperf
Delphine Malassingne (ben moi, quoi !) et Élie Sloïm.

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 :

Crédit photo et photos de la soirée : Prélude – Webperf janvier 2012

Laisser un commentaire

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