Windows 8 se vend mal. Même si une centaine de millions de licences se sont écoulées depuis la sortie de l'OS, toutes ne sont pas activées et Windows 8 ne représente que 3 à 5% du parc PC. Il y a des choses à changer dans Windows. Et vite.

Dans ce nouvel article consacré à la performance Web, nous nous attarderons sur la partie "stratégie et culture d'entreprise" ou comment un enjeu technique peut devenir une aventure de longue haleine...

Note : l’article ci-dessous a été publié sur Clever Age dans Mettre en place une stratégie de Performance Web.

Avertissement

Avant d’aller plus loin, explicitons deux non-dits.

Le premier est assez simple : on ne peut mettre en place une stratégie d’amélioration de la performance Web que dans une entreprise qui est consciente des ses avantages. Et avant d’y arriver, il faut souvent convaincre de l’intérêt de la performance Web. Cela pourrait être le sujet d’un article à part entière, mais pour l’instant partons du principe que l’entreprise est sensible à l’argument.

Le deuxième non-dit est que la performance Web n’est pas qu’un développement ou un ensemble de développements. Vous pouvez auditer un site, conseiller des corrections ou proposer de nouvelles implémentations, et la performance s’améliorera temporairement. C’est une première étape essentielle. Mais si le site ciblé est vivant, s’il évolue, alors la performance Web est plus compliquée à atteindre car elle devient un enjeu qualitatif à chaque livraison, voire même à chaque contribution (côté Back ou Front).

Maintenant que nous sommes d’accord sur tout ça, comment mettre en place une stratégie de performance Web ? Lentement, et par étapes.

Niveau 0 – la compréhension

La première étape consiste à comprendre ce que l’on entend par Performance Web, car la plupart du temps, cela consiste à répondre à deux questions : « à quelle vitesse ma page s’affiche-t-elle ? » et « comment cela modifie-t-il l’expérience de mes visiteurs ? ». Or, il n’y a pas de bonnes réponses à ces questions, il n’y a que des indicateurs qui permettent de se faire une idée. Et il est parfois difficile de s’y retrouver.

Ces indicateurs peuvent être de deux types : orientés métier ou purement techniques. Suivant le contexte, il vous faudra définir le juste assemblage. Côté métier par exemple, pour un site e-commerce, la participation d’une page à la génération de revenus est un indicateur incontournable. En revanche, sur un portail collaboratif, il s’agira de toutes autres mesures, comme le nombre de contributions par participant. Au niveau des indicateurs techniques, il y a aussi le choix comme nous l’avions vu dans cet autre article. A vous de faire votre sélection.

Souvent, dans cette première phase, vous n’avez pas l’oeil perpétuellement rivé sur les indicateurs, sinon vous ne feriez pas grand chose de concret. A la place, vous faites une extraction des mesures toutes les semaines ou tous les mois, suivant la criticité, souvent manuellement. Il ne s’agit pas de perdre du temps à sortir des métriques, mais bien d’améliorer rapidement les choses. Pas la peine de réinventer la roue, vous pouvez utiliser des outils publics, souvent gratuits et en ligne comme :

• pour l’analyse de Waterfall : WebPageTest.org, Pingdom Tools
• pour le respect des bonnes pratiques : Page Speed Online, YSlow

Niveau 1 – la réaction

Une fois la définition de vos indicateurs terminée, vous êtes normalement capable de mesurer les gains et les pertes dans le temps. Malheureusement, si vous êtes chargé de mettre en place cette stratégie, c’est qu’elle n’existe pas déjà et que donc l’entreprise n’a probablement aucune culture de la Performance Web. Vous êtes donc en mesure de trouver des problèmes, mais êtes probablement le seul à chercher à les résoudre. Et en plus de ça, on vous demande de faire vos preuves au milieu d’un milieu a priori hostile car mal informé.

C’est le moment privilégié des « Quick Win », ces optimisations rapides et efficaces qui permettent d’obtenir des résultats gratifiants au prix de peu de développement et de TNR [1]. Il s’agit souvent de solutions purement techniques, recommandées par des outils d’analyse automatique et dont la résolution ne remet pas en cause l’existence ou la dynamique de l’entreprise sur Internet. Profitez de la relative simplicité de ces premières optimisations pour généraliser l’usage de tests A/B. Cela vous permettra de démontrer le gain issu de la performance en comparant une version du site sans optimisation à une autre en bénéficiant.

Mais tout n’est pas rose : grâce aux indicateurs que vous avez mis en place, vous détectez des problèmes qui passaient inaperçus jusqu’à présent, dans la jungle des autres problèmes. Et dans la pure logique « Shooting The Messenger« , vous serez souvent rendu responsable de ne pas avoir déjà corrigé tous ces problèmes. La situation, qui semble assez positive, peut rapidement se retourner contre vous si vous vous retrouvez submergé par la tâche, ou si ne vous savez pas « vendre la performance » suffisamment bien, le temps que les premiers gains parlent d’eux-même.

C’est la phase de montée en compétence. La vôtre, au sein du SI de l’entreprise que vous apprenez à comprendre, mais aussi celle des personnes qui vous côtoient dans l’entreprise, qui vont petit-à-petit acquérir une certaine culture de la performance Web. Accrochez-vous, si on vous bouscule un peu, c’est que ça rentre.

Niveau 2 – Savoir et Faire

A ce niveau, vous avez suffisamment d’expérience sur le SI de l’entreprise pour connaitre les processus du(des) site(s) ciblé(s), bien évidemment, mais également ceux du SI et du métier/commerce. Vous connaissez les enjeux, êtes capable de trouver rapidement où sont les problèmes et chiffrer leur résolution. Vous êtes dans votre zone de confort. Vous savez comment améliorer le site, vous êtes un référent sur la Production car vous réalisez des mesures régulières et des analyses efficaces.

Problème : dans la mesure où vous analysez la production, vous arrivez toujours trop tard. Il est grand temps d’anticiper en réalisant des tests de performance sur les environnements internes, avant que le code ne soit livré. L’occasion, peut-être, de déployer une instance privée de WebPageTest.org et de passer par l’API pour lancer certains tests.

C’est une phase où la difficulté est organisationnelle, car suivant la taille du site ou sa volumétrie, vos relevés de performance « à la main » sur plusieurs environnements commencent à être coûteux en temps…

Niveau 3 – l’automatisation

Au bout d’un certain temps, vous surveillez tellement d’environnements que même en rôdant vos processus au maximum, vous finissez par passer moins de temps à résoudre les problèmes qu’à mesurer leur impact. Il est temps d’agir. Lorsque la mesure à la demande n’est plus envisageable, il faut automatiser.

Plusieurs solutions sont possibles : la première, la plus évidente, est d’automatiser l’utilisation des mêmes outils que précédemment. Plutôt que de lancer vos analyses WebPageTest à la main, vous passez désormais par leur API REST, et vous pouvez également imaginer le téléchargement et traitement des résultats HAR applicativement, pour générer une levée d’alerte automatique. Autres solutions possibles, utiliser WPT Monitor ou une instance privée d’HttpArchive.org, qui fournissent tous deux des services similaires.

Rien ne vous empêche cependant de réaliser l’investissement nécessaire à une véritable amélioration de votre trousse à outils en basculant vers la mesure de l’expérience réelle des utilisateurs. Il peut s’agir de Peer Testing, c’est-à-dire de mesurer la performance de votre site sur une population cible (à la façon d’un Focus Group), ou de mesures réalisées en JavaScript et renvoyées à vos serveurs ou à un service externe.

On peut citer, dans ce domaine : Gomez RUM, Google Analytics,Boomerang, New Relic RUM, Episodes 2…

L’avantage est évident : vous n’êtes plus dans un contexte de test provoqué, mais bien dans une visualisation de l’expérience réelle de vos visiteurs, qui ont probablement une façon bien à eux d’utiliser le site, différente de la vôtre. Vos mesures sont plus fiables et la corrélation avec les indicateurs métier n’en est que meilleure. Vous vous rapprochez des populations métier/commerce, car vous parlez désormais le même langage : celui qui s’articule non-pas autour d’une notion technique, mais autour du client.

Niveau 4 – l’analyse en amont

Vous arrivez à un moment où vous ne pouvez plus optimiser en vous concentrant uniquement sur l’aspect technique et où vous devez prendre en compte l’impact commercial pour prioriser vos développements, voire définir les évolutions du site en fonction de ce critère. D’intervenant de fin de cycle, vous pouvez alors basculer vers la définition des projets avant même leur mise en chantier. Vous participez aux définitions des nouvelles fonctionnalités et pouvez conseiller leur élaboration ou lever les alertes quand c’est nécessaire.

Mais comme un grand pouvoir implique de grandes responsabilités, il est désormais capital que vous portiez vos tests automatisés sur l’ensemble de la chaîne de développement de manière à pouvoir valider que les développements suivent bien vos préconisations et n’impactent pas négativement les indicateurs de performance, avant même la mise en Production. A vous les joies du recoupement de données ou de l’intégration de votre tableau de bord à l’utilitaire de compilation/livraison. L’objectif est de pouvoir dire, lors d’une dégradation de performance, quelle contribution est responsable.

Niveau 5 – la constance

Vous y êtes, vous contrôlez la performance Web du ou des sites de l’entreprise. Votre vision de la performance est bien sûr troublée par des imprévus mineurs mais vous êtes globalement maître des temps de réponse du site. Il s’agit à cette étape de pérenniser le travail effectué : réalisation de tableaux de bord contenant des indicateurs mis-à-jour en temps réel sur les différents environnements mesurés, analyse de l’impact commercial avant la livraison, définition de refontes alliant métier et performance… etc.

Et si vous avez encore 5 minutes, n’hésitez pas à rejoindre la communauté des Web Performers français qui s’articule aujourd’hui autour du projet d’analyse des bonnes pratiques WebPerf OpQuast. On vous attends !

La situation est typiquement celle de l’hôtel de vacances et de l’agence de tourisme. L’hôtel est loin de ses clients, entouré d’autres hôtels équivalents, et cherche à promouvoir son offre. Il passe donc par une agence, dont le rôle est d’enrichir des catalogue d’offres à présenter à ses clients, une cible locale. L’agence agit donc en prestataire de référencement pour l’hôtel et prend une commission au passage. L’hôtelier peut négocier avec l’agence, pour que celle-ci baisse sa marge, mais pensez-vous qu’il lui viendrait à l’idée de demander à l’agence de le payer ? Il serait automatiquement sorti du catalogue, point barre. C’est ce qui va arriver à la Presse française aussi si elle s’en prend à Google, et ça me semblerait assez logique.

La meilleure position pour l’hôtelier serait de mettre lui-même en valeur son offre en faisant jouer le bouche-à-oreille, en vantant les prestations de son établissement sur d’autres canaux (print, web, buzz…), en modifiant son offre de manière à la rendre plus attirante.

La Presse aussi devrait innover, en offrant ce qui n’existe pas encore, ou très peu :

• Des abonnements évolutifs, et à la carte (« le sport et l’international ne m’intéressent pas, donc je les retire et je paie moins cher »).
• Une meilleures inclusions sociales et je ne parle pas de simples commentaires. Je pense plutôt à une fonctionnalité de partage « à la Tumblr » qui permettrait à chacun de re-publier des articles et de créer son propre magasine à proposer aux autres, sur des thèmes de niches.
• Un rapport différent aux auteurs, qu’on connait aujourd’hui peu, et créer le dialogue entre l’auteur et le lecteur, notamment sur les sujets de fond.
• Davantage d’interactivité de manière à permettre aux lecteurs d’entrer dans les rédactions et de dicter la politique éditoriale.
• …

Il s’agit de modifications de fond cruciales, adaptées à la façon dont notre société consomme l’information (attention, « consommer » est un gros mot dans le monde de la Culture, utilisez-le avec parcimonie) qui seront douloureuses à mettre en place mais qui sont obligatoires si la Presse veut retrouver le contact qu’elle a perdu avec le lectorat. Et arrêter de tout résumer à : « Comment faire cracher Google ? »

Un bon résumé de la situation chez Authueil.

Note : l’article ci-dessous a été publié sur Clever Age dans Avec TypeScript, Microsoft espère offrir à JavaScript les outils pour se développer.

TypeScript, le nouveau bébé de Hejlsbernt chez Microsoft, est un sur-ensemble de JavaScript ajoutant au langage un certain nombre d’extensions conceptuelles dont notamment le typage statique, et une orientation objet centrée sur les classes et non plus les prototypes.

Pour passer de TypeScript à JavaScript, le développeur utilisera un compilateur, mais TypeScript ne doit pas être confondu avec d’autres langages générant du JavaScript : il n’est ni une réinterprétation de JavaScript dans une syntaxe différente, comme CoffeeScript, ni destiné à être exécuté dans son propre runtime comme Dart

Le langage semble pensé pour l’avenir. La syntaxe de déclaration des classes, par exemple, est issue de l’ECMAScript ES6, tant et si bien que lorsque cette version sera supportée par les navigateurs, TypeScript n’aura tout simplement plus qu’à arrêter de compiler ces classes qui seront interprétées nativement.

Niveau support, Microsoft proprose une extension Visual Studio pour sa communauté de développeurs et de l’autre, un package NodeJS. Et niveau ouverture, on signalera que le compilateur proposé (développé lui-même en TypeScript) est sous licence Apache 2.0 et que le langage est sous licence Open Web Foundation (OWFa 1.0).

TypeScript n’est pas le seul dans la course à la succession de JavaScript mais il se démarque en se positionnant non pas comme un remplaçant, mais plutôt comme une extension facilitant l’usage de JavaScript pour du développement objet. En somme, un cri d’amour de Microsoft envers une technologie en pleine émancipation sur le Web, côté client comme côté serveur.

De plus :

• Respectant la syntaxe JavaScript, il peut être utilisé dès maintenant sur des projets en Production, sans coût de migration
• Quand c’est possible, TypeScript infère le type. Cela veut dire que même si vous lui passez vos JavaScripts actuels, il les validera en vérifiant que les types sont respectés
• Il n’exclut pas de continuer à utiliser les outils JavaScript déjà présent dans votre intégration continue : compilateurs, réducteurs, concaténeurs s’appliqueront sur le JavaScript en sortie de TypeScript.
• En ajoutant un compilateur, il ajoute une sécurité supplémentaire contre les erreurs de développement
• Son compilateur est lui-même en JavaScript, ouvrant la porte à des compilations à la volée
• Il est livré avec des add-ins pour la coloration syntaxique sous Sublime Text 2, Vim et Emacs

A vous d’essayer désormais, et de vous faire une idée…

Si les fonds sont récoltés, le jeu verra le jour en version boite. sinon, il sera livré en Creative Commons donc vous pourrez l’imprimer chez vous si vous le souhaiter. Pour ma part, je trouve l’initiative sympa donc j’ai soutenu le projet. N’hésitez pas à soutenir aussi si ça vous plait : la contribution à 14€ est accessible et correspond en fait à acheter le jeu à tarif réduit.

Note : l’article ci-dessous a été publié sur Clever Age dans GitHub communique sur son monitoring de la performance.

La société y présente notamment son tableau de bord dont le design est assez pertinent et les données traitées de manière statistiques. Mieux, elle y rappelle l’essentiel : un tableau de bord est fait pour informer, pas pour expliquer. L’explication se fait au moyen d’autres outils, plus fins, page par page et surtout, plus manuels.

J’espère que, dans un prochain article, ils nous parleront de la façon dont ils incluent la performance Web dans leur intégration continue, et des modalités de leurs levées d’alertes. La performance Web a bien besoin d’évangiles, et GitHub est le bienvenu.

Lire l’article de GitHub.

Note : l’article ci-dessous a été publié sur Clever Age dans WebPerf : « A quelle vitesse ma page se charge-t-elle ? ».

Il n’y a pas de façon « standard » de mesurer la performance web mais plusieurs, qui correspondent à ce qui se passe dans le navigateur lors de l’accès à une page Web. Quand vous tapez dans votre barre d’adresse l’URL de Clever Age et attendez que la page s’affiche, votre navigateur :

1. Se connecte au serveur hébergeant le site et lui demande de renvoyer le contenu de la page HTML
2. Reçoit le contenu de la page HTML
3. Interprète le code HTML pour comprendre comment est structurée la page et de quels objets supplémentaires (images, mises en forme, scripts…) elle a besoin pour être rendue
4. Charge l’ensemble des ressources en question
5. Affiche la page
6. Exécute d’autres script après le chargement, impliquant eux-même le chargement de nouvelles ressources et le déclenchement d’animations

La mesure de la performance du site passe alors par la compréhension de plusieurs indicateurs :

Le « Time To First Byte »

Description : le « Time To First Byte » est le temps séparant la demande de votre navigateur et la réponse du serveur hébergeant la page que vous souhaitez consulter.

Référence : on considère qu’un « Time to First Byte » acceptable est bien inférieur à la seconde, et idéalement de l’ordre de 100ms, même si peu de sites importants atteignent ce niveau (la tendance globale du Web allant même vers une certaine lenteur).

Quels problèmes ? : le « Time To First Byte » est utile pour déterminer les problèmes relatifs au réseau (latences), à la résolution du nom DNS (le lien entre l’URL du site et le serveur qui l’héberge) ou à un problème de délivrance du code HTML du site (absence ou mauvaise stratégie de cache, par exemple).

Impacts: à moins d’être véritablement catastrophique, le « Time To First Byte » n’a que peu d’impact sur l’utilisateur. En revanche, le « Time To First Byte » a énormément d’impact sur le référencement, il est donc nécessaire de le chouchouter.

Les temps d’affichage

Description : suivant la qualité du code HTML renvoyé par le serveur, un site s’affichera avant même que le navigateur n’ait reçu l’ensemble de la page ou bien longtemps après. Le moment auquel le premier élément est affiché est appelé « Start Render Time ». Le moment auquel le dernier élément de la fenêtre du navigateur (qui n’est pas forcément le dernier élément de la page si la page est plus longue qu’un écran) est appelé « Perceived Render Time » ou parfois « Above-The-Fold Render Time » bien que l’utilisation du terme « Fold » n’ait que peu de sens aujourd’hui, avec la multiplication des formes d’écrans).

Quels problèmes ? : un mauvais temps de rendu signifie le site est soit trop « lourd » (il contient tellement d’objets qu’il est nécessaire aux navigateurs de récupérer de très nombreux fichiers avant de l’afficher). Cependant, tous ces objets ne sont pas forcément utiles à l’affichage et un site riche en contenu multimédia, par exemple, mettra certainement plus de temps à s’afficher qu’un site contenant uniquement quelques lignes de textes.

Impacts: le temps du rendu est celui de l’utilisateur, il est donc votre vitrine. Optimisez ce temps pour satisfaire vos visiteurs. Certains sites, comme Twitter ou Facebook, utilisent même une « coquille vide » qu’ils alimentent ensuite, zone par zone.

Le « Load Time »

Description : une site n’est pas qu’une page HTML mais également un ensemble de ressources multimédia. Le Load Time est le temps nécessaire au navigateur pour rendre tous les éléments visibles (textes, images, mises en forme) et invisibles comme les scripts Javascripts. La mesure du Load Time étant renvoyée nativement par tous les navigateurs, il est facile à capturer et est donc souvent utilisé comme élément de comparaison pour la performance Web de deux sites, souvent à tort.

Quels problèmes ? : le Load Time doit être recoupé avec ce qu’il représente, en l’occurence le temps de chargement des ressources utilisées par la page. Un fort Load Time peut donc être symptomatique d’un trop grand nombre de ressources (le navigateur ayant des limitations sur le nombre de téléchargement simultanés qu’il peut lancé), d’un problème dans la récupération de celles-ci (réseau, par exemple) ou tout simplement de ressources trop grosses (images mal dimensionnée, contenus animés…).

Impacts: le Load Time est souvent considéré comme le moment auquel un site devient interactif, à tort. Gonflé par des scripts de récupération de statistiques qui n’ont aucun impact sur l’utilisateur, le Load Time est alors déclenché bien après que la page soit devenue véritablement interactive. Ceci étant, le Load Time étant souvent utilisé comme mesure comparative, un site a tout intérêt à le minimiser et donc à déporter ces scripts plus tard dans la chronologie d’exécution.

Le « Time To Last Byte » (ou à tort : « Response Time »)

Description : le Time To Last Byte est le moment auquel plus aucune information n’est échangée (récupérée ou envoyée) par la page du site chargée. Ce temps est parfois appelé Response Time, même si ce nom fait croire « à tort », qu’il s’agit d’un moyen simple de mesurer la performance d’une page, alors que pas du tout !

Quels problèmes ? : le Time To Last Byte n’a pas beaucoup d’intérêt. En revanche, c’est à son lancement qu’il est intéressant de mesurer le nombre d’objets total et le poids qu’ils représentent pour les internautes.

Impacts : le Time To Last Byte n’a aucun impact sur l’internaute. Certains sites, d’ailleurs, ne l’atteignent jamais car ils sont constamment en situation d’échange telles les messageries ou les réseaux sociaux, qui se mettent souvent à jour en temps réel.