Performance web » conférence

Mesurer la performance avec Jiffy

Éric — Fri, 27 Mar 2009 11:00:27 +0000

Jiffy est un projet mené par Netflix et présenté aux conférences Velocity 2008 (en ligne, pdf, vidéo) par Bill Scoot (tiens, encore un ancien Yahoo!). Personne n’a l’air d’en avoir parlé depuis mais le projet est suffisamment intéressant pour mériter de s’y arrêter.

Le besoin est commun à celui de la plupart des sites important : avoir des statistiques et des mesures réelles venant des utilisateurs. Pour les performances la question est loin d’être évidentes et la plupart des outils dégradent les performances qu’ils sont en train de mesurer.

Mesurer

Dans sa présentation Bill Scott nous propose un tout petit script js, moins de 10ko. Il offre deux fonctionnalités de base : mark() et measure(). La première fonction prend un repère dans le temps, et la seconde mesure le temps passé depuis un repère donné. On peut donc avoir plusieurs mesures par repère, et tout est stocké dans le DOM pour réutilisation plus tard.

Bien entendu on voudra faire une marque à l’exécution du script, tout en haut du . On voudra faire une mesure à la fin du , sur le DOMContentLoaded et sur le onLoad. Probablement, puisque la publicité est souvent le plus gros problème de performance, on voudra faire une marque avant d’insérer la publicité et faire une mesure juste après. Faire une mesure après le contenu principal pourrait aussi être intéressant, de façon à mesurer la partie « importante pour l’utilisateur » quitte à ce que je reste mette plus longtemps à charger.

La seule chose qu’on ne mesure pas c’est le premier aller-retour serveur pour aller chercher la page HTML, et le second pour aller chercher le script Jiffy. Maintenant il ne s’agit pas d’avoir des mesures absolues, qui ne veulent rien dire en soi. Il y aura un décalage par rapport à Yslow mais on pourra avoir d’autres mesures, plus précises, et surtout on pourra mesurer les variations suivant les modifications de la page. C’est finalement ça l’important : pouvoir améliorer les choses, peu importe où on se situe.

Collecter

La seconde partie de Jiffy c’est l’envoi des résultats. Le but de Netflix est en effet la collecte statistiques. Il s’agit donc d’envoyer toutes les mesures faites avec tout ce qu’on peut collecter d’intéressant (version du navigateur, adresse ip, système, identifiant des publicités affichées, page visitée, etc.).

On nous propose d’envoyer les résultats à chaque mesure ou d’envoyer une requête groupée en fin de page. Le tout étant reçu par le serveur web pour alimenter une grosse base de données. Envoyer un résultat à chaque mesure risque de dégrader les performances, d’un autre côté envoyer les résultats en fin de page implique un biais si certains de vos utilisateurs quittent la page avant. Il doit aussi y avoir moyen de stocker ça en cookie pour le recevoir à la requête suivante mais cela implique d’autres biais.

Avec toutes les mesures, des filtres par navigateur, date, url, publicité … on pourra enfin détecter la source des problèmes. Lors des évolutions du site, on aura des mesures réelles sur la réaction des différents navigateurs. Mais on pourra être alerté si la courbe de performance pour une URL, un navigateur, une source géographique ou une publicité se dégrade ou s’améliore. Une publicité ou un partenaire ne respecte pas son SLA à cause des javascript qui appellent des javascript qui appellent des javascript ? on le verra.

Afficher

Avec tout ça, nous avons même droit à une extension firefox qui se branche sur firebug et qui permet de visualiser les statistiques de la page courante.

Google SDCH et HTTP

Éric — Thu, 12 Feb 2009 11:00:50 +0000

On vous a dit de compresser vos échanges HTTP avec gzip ou deflate, des les identifier avec des ETag, mais pouvons nous faire mieux ? C’est la question abordée par certaines équipes de Google (slides disponibles) en juin dernier aux conférences Velocity 2008. Ils partent du principe qu’une page web est composée de plusieurs éléments, dont certains sont communs à plusieurs pages et ne nécessitent pas d’être renvoyés.

Google propose donc un codage supplémentaire pour HTTP qui s’appelle SDCH, et qui peut s’ajouter avant gzip ou deflate. Le serveur découpe sa page en paquets, qui peuvent chacun avoir des métadonnées et une expiration explicite. Le tout est stocké dans un dictionnaire du côté du navigateur, un peu comme les cookies actuellement. Quand le navigateur demande une page il envoie les identifiants de paquet qu’il connaît déjà, le serveur peut donc se contenter de compléter ce qui manque. On a donc le même fonctionnement que les Etag du point de vue de la négociation.

Les entêtes HTTP en jeu sont Avail-Dictionnary (l’équivalent de Etag pour SDCH) et X-SDHC (pour déclarer la version et l’implémentation de SDCH utilisée) du côté du navigateur, et X-SDCH-Dictionary du côté du serveur.

Reste que cela implique que la réponse du serveur soit codée suivant une forme bien particulière, non compatible avec les anciens clients HTTP. Google a donc prévu une auto-négociation et la réutilisation de l’entête Accept-Encoding. Grâce à cela, les navigateurs qui le peuvent auront un contenu SDCH puis compressé par gzip, les autres se contenteront du gzip.

Si vous voyez passer un Accept-Encoding: sdch, gzip c’est que votre navigateur supporte ce codage. Si en plus vous voyez une réponse Content-Encoding: sdch, gzip c’est que le serveur a bien compris que vous supportiez SDCH et va utiliser ce codage.

Je n’ai vu aucun mouvement ni aucune volonté de mouvement de la part de Mozilla, en fait depuis la communication de Google l’idée n’a pas l’air d’avoir fait recette où que ce soit. Seul un groupe de discussion, quasi vide, a fait suite à la communication de juin 2008.

Chrome a un premier support de SDCH (non activé par défaut pour la version publique actuelle) mais ça ne changera pas la face du monde. Le point intéressant est toutefois que SDCH est automatiquement intégré à Microsoft Internet Explorer si la Google toolbar est installée. La page d’aide de Google indique comment désactiver tout ça.

Si l’idée peut être intéressante, je suis un peu étonné que Google tente de l’imposer de lui-même sans avoir le support d’au moins un intervenant (Mozilla, Opera, Apple, Microsoft) ou une publication normative officielle de type RFC. La seule chose qui sauve cet unilatéralisme est la présence d’une version dans l’auto-négociation (donc on pourra gérer d’éventuelles évolutions dans les spécifications si jamais tout le monde se met autour de la table pour en rediscuter).

Vidéo de la phase de rendu du navigateur

Éric — Tue, 03 Feb 2009 11:00:40 +0000

Que fait le navigateur pendant le rendu ? pourquoi est-ce si long ?

La question est complexe à répondre pour qui n’a pas touché au moteur d’un navigateur. Pour vous donner un premier aperçu, vous avez toutefois trois vidéo (faites par Satoshi Ueyamai pour une présentation au Japon). Elles vous montrent les différentes étapes de rendu du moteur Gecko pour les sites Mozilla.org, Wikipedia.org, et Google.jp. Plus exactement on visualise le reflow, c’est à dire l’événement interne qui indique qu’il faut recalculer les tailles et positionnement (si je ne m’abuse, c’est un domaine que je ne connais pas bien et toute précision est la bienvenue). je ne sais pas bien comment exploiter, mais au moins ça permet de constater.

Ces vidéos ont été obtenues en modifiant le code de Mozilla. Daniel Glazman nous avait dit aux dernières conférences Paris Web qu’il était désormais possible de réaliser cela via une extension depuis les dernières versions de Mozilla. Si quelqu’un souhaite se lancer…

En attendant Matthew Buchanan vous propose une extension pour voir le rendu progressif au fur et à mesure que la feuille de style est interprétée.

À mettre aussi en rapport avec l’intervention de David Baron dont je parlais en novembre.

Vidéo de Performances Web à l’AFUP

Éric — Mon, 05 Jan 2009 11:00:27 +0000

Je vous en parlais le mois dernier, désormais c’est la vidéo de mon intervention au forum PHP AFUP 2008 qui est disponible en ligne. Les slides eux sont toujours dans mon précédent billet.

Je vous laisse donc regarder la vidéo performance web sur PHPTV, qui a enregistré ça le jour des conférences et publié à Noël. J’espère que certaines choses seront plus claires maintenant.

Velocity 2009 – Appel à participation

Éric — Wed, 12 Nov 2008 17:04:31 +0000

Plusieurs de mes billets ont pris comme base des présentations données aux conferences Velocity de 2008. Il s’agit d’un événement organisé par O’Reilly où on y parle performance en long en large et en travers.

Alors voilà, ils viennent de publier un appel à participation pour l’année prochaine en Californie, juin 2009 exactement. Si vous avez de quoi partager, tentez l’aventure. Dans le cas contraire tentez d’y assister, c’est l’événement le plus pertinent sur le sujet. Pour ma part je tenterai d’y être, tout dépendra de mon employeur.

Entre temps, vous pouvez toujours voir les présentations données en 2008, fichiers et vidéos.

Paris Web 2008

Éric — Wed, 24 Sep 2008 10:00:29 +0000

Certains le savent, d’autres, pas encore, mais vous me retrouverez mi-novembre à Paris Web 2008 pour une conférence et un atelier sur les performances web, en collaboration avec Nicole Sullivan de l’équipe performance de Yahoo!

Paris Web c’est un cycle de conférences sur le milieu du web que j’ai cofondé il y a quelques temps avec Stéphane Deschamps et Adrien Leygues. Depuis nous avons notre petit atmedia à nous, à Paris. C’est 500 persones au total pour deux jours de conférences et une journée d’ateliers.

Les deux jours de conférences techniques se tiennent cette année les jeudi 13 et vendredi 14 novembre 2008 dans les locaux IBM de La Défense, avec des gens très bien comme Chris Wilson (architecte Microsoft Internet Explorer 8 et chairman HTML 5 au W3C), Daniel Glazman (entre autres choses chairman CSS 3 au W3C). …et moi au milieu de tous ces gens bien plus célèbres. Nous y parlerons qualité, standards, web mobile, navigateurs, technologie … et performance, donc. Pour 100€ les deux jours, si vous manquez ça j’espère que vous avez une bonne raison.

En parallèle le vendredi 14 vous aurez cette année une salle dédié aux décideurs. Derrière ce terme il y a un « emmenez votre patron » car même s’il ne comprend rien à la technique, nous aurons une salle adaptée à ses problématiques : mise en oeuvre, pourquoi de standards, bonnes pratiques, éditorial, etc. Là aussi nous invitons des experts reconnus et plus qu’intéressants.

Enfin, et sans que la dernière place implique une différence d’intérêt, nous vous proposons le samedi 15 novembre une journée d’ateliers technique sur Paris. Là c’est quatre salles au moins en parallèles avec des ateliers techniques d’une heure et demi. Encore les mêmes experts, accompagnés par plein d’autres, pour des sessions plus techniques, des questions réponses et des TP. Le but est de proposer un espace plus communautaire, ouvert aux étudiants et aux passionnés, pour un tarif symbolique de 10€. Cette journée là si vous la manquez c’est plus qu’une bonne raison qu’il faut avoir.

Donc voilà, si vous manquez Paris Web il vous faudra attendre l’année prochaine, et lire partout après coup pendant des mois combien c’est dommage que vous n’y étiez pas. Vous vous en mordriez les doits alors inscrivez vous.

Optimiser les performances d’un site web

Éric — Fri, 11 Jul 2008 10:00:45 +0000

je vous en avais parlé, maintenant c’est fait. Camille Roux et Nicolas Chevallier ont ont réalisé une présentation sur l’optimisation des performances d’un site web aux Intellicore Tech Talks.

Vous avez donc maintenant la vidéo et les slides disponibles en ligne. Commentaires et comptes rendus bienvenus.

Intellicore Tech Talks sur les performances web

Éric — Fri, 04 Jul 2008 11:06:55 +0000

Camille Roux me fait part qu’il co-animera avec Nicolas Chevallier une présentation sur l’optimisation des performances d’un site web dans le cadre des Intellicore Tech Talks. Cette présentation se tiendra le mardi 8 Juillet à 13h à Sophia-Antipolis.

Les Intellicore Tech Talks (ITT) sont des mini conférences hebdomadaires sur des technologies innovantes, données à Sophia Antipolis. Ces conférences sont à priori gratuites.

Camille Roux est élève ingénieur chez Intellicore (organisateur des conférences). Nicolas Chevallier est consultant chez Astek. Il est aussi le créateur de Allogarage et intervient régulièrement ici dans les commentaires. Ils sortent tous deux de Polytech’Nice.

Si vous animez un événement concernant les performances web, ou que vous avez connaissance d’un événement sur ce même sujet, n’hésitez pas à me faire suivre l’information, je la relaierai avec plaisir.