Les manques à gagner de la publicité pour les éditeurs

Cet article et le précédent, plus technique, sur les tiers classiques sont une transcription d’une conférence donnée à Blend Web Mix 2016. Cliquez ici si vous êtes plus audio que texte.

La publicité et les performances

Mettre « pub » et « perf » dans la même phrase fait rire jaune tout travailleur du Web. Le peu de fois où nous désactivons nos adblockers, nous nous demandons comment font « les gens » pour arriver à naviguer. Le peu de fois où nous testons le site sur autre chose que nos mobiles personnels, généralement performants, nous prenons notre mal en patience car c’est pour le travail. Les vrais utilisateurs eux, sont déjà partis.

Performance perçue et Performance business

Il y a des palanquées de chiffres démontrant la relation business/temps de chargement, regardez ne serait-ce que cette collection 2016 chez wpostats (communautaire) ou ces traductions en français chez Dareboost (solution commerciale). Laissez moi vous sortir quelques chiffres de chez mes clients.

courbe de nombre de pages vues par session pour chaque temps de chargement

une très classique relation engagement / temps de chargement

Cette courbe (réalisée avec le produit commercial webperf.io) est assez classique et range les utilisateurs par temps de chargement (axe horizontal) et indique pour chaque segment le taux d’engagement (plus c’est haut, plus il consomme). Ici c’est un site de presse, donc c’est le nombre de pages consommées par session. Comme souvent, on voit que les utilisateurs sont moins consommateurs lorsque leurs pages se chargent en plus de 5 secondes. Puis au-delà de 20 secondes, la courbe s’aplanit, car ne restent que les fidèles et les motivés. Je précise que j’ai généré cette courbe en filtrant pour n’avoir que les utilisateurs Windows, afin de ne pas être influencé par les mobiles.

Autre constat en fouillant les chiffres :

Les utilisateurs avec adblock ont un engagement 50% supérieur aux autres

Quand on sait que la majorité des temps de chargement sont consacrés à la seule publicité, il devient évident que cette source de revenus a un coût qui dépasse de loin ce qui est écrit sur le contrat avec la régie.

Comment louper 85% des internautes français

Avec quoi vos utilisateurs mobiles naviguent-ils ? Vous trouverez sans doute dans vos analytics les modèles de smartphones et tablettes. Prenez le top 25 et allez récupérer pour chaque modèle son prix de vente actuel, occasions comprises (surtout pour les iPhones). Chez 3 clients (2 journaux, 1 site de e-commerce) j’obtiens à peu près la même valeur moyenne : 380€.
En voyant ces stats, je me suis longtemps dit que les français étaient plutôt privilégiés par rapport à leurs voisins et pouvaient mettre de beaux budgets dans leurs smartphones (merci Free ?). Jusqu’à ce que je trouve les prix d’achat du marché français des smartphones :

graphique de répartition du prix d'achat des mobiles dans la population française

prix d’achat des mobiles en 2015

L’étude de marché est faite par GFK pour le 1er semestre 2015 et montre clairement que la population qui possède des portables de plus de 300€ ne représente que 15% des français … La médiane est plutôt comprise entre 100 et 150€.
Utilisent-ils le Web ? Oui puisque d’après l‘ARCEP 70% des cartes SIM utilisent la 3G. Même en supposant que seuls les possesseurs des smartphones les plus chers achètent de la 3G, cela signifie qu’il n’est pas rare d’avoir des mobiles de 75-100€ accéder au Web.
Pourquoi ne les voyez-vous pas sur vos sites ? Tentez de charger une page de journal avec un mobile ou une tablette à moins de 200€ ! Je pense que les gens accèdent bien au Web mais que l’expérience d’un site chargé en pub est tellement pénible qu’ils restent sur les applications de Facebook ou Google (où la pub est parfaitement sous contrôle d’ailleurs).

Pour résumer, laisser ses pubs faire n’importe quoi, c’est se couper de la majorité du parc mobile français.

Pub lourdes ? Essayez avec moins!

Il y a des stratégies intéressantes pour laisser plus d’utilisateurs devant des publicités plus visibles. Elles jouent sur les modes de facturation de la pub (impression ou visibilité garantie), sur la notion de valeur moyenne de l’inventaire et sur la réalité technique qui est que moins on affiche de pubs, plus ça va vite, et plus l’utilisateur consommera de pages, donc d’affichage de pubs.
Prenons par exemple le journal anglais Guardian.


Lien direct vers la vidéo en MP4.
Sur un réseau que j’ai artificiellement ralenti avant de filmer l’écran, on voit les priorités données :

  • on affiche d’abord texte et photo principale, c’est ce qui fait que l’utilisateur va rester
  • notez qu’un espace blanc en haut de page est déjà prévu pour y afficher une bannière et éviter les désagréables effets de page qui saute
  • dans la plus pure tradition de l’amélioration progressive, la plupart des liens sont déjà cliquables et on peut interagir avec le menu même si les fonctionnalités JavaScript n’ont pas encore été récupérées
  • affichage progressif des fonctionnalités secondaires, comme les boutons de partage sur la gauche
  • enfin, affichage de deux emplacements pub classiques en haut et à droite
  • chose importante : aucune publicité en dehors du viewport ne commence à se charger, pour ne pas gêner le chargement des ressources plus visibles
  • au scroll, la pub de droite reste bien visible

Du côté de chez Yahoo!, où la performance frontend a été inventée il y a 10 ans (j’y étais !), on peut aussi espérer qu’un soin particulier ait été apporté aux pubs.


Sur la Homepage très chargée en informations, Yahoo! joue sur la visibilité d’une position en particulier (à droite) tandis que les autres positions sont remplies par des pubs très légères à gauche (Unicef) et au centre. Elles se confondent d’ailleurs avec le contenu, évitant au passage la « banner blindness », c’est à dire le masquage inconscient par l’utilisateur de tout ce qui ressemble à une pub.

En France, nous avons l’exemple de Libération :


Encore une fois, moins de positions au global (mais ils pourraient faire mieux), une position à droite qui reste très visible, et j’ai l’impression qu’ils affichent surtout des publicités vidéo, qui ont l‘avantage de se vendre plus cher. Ce ne sont pas mes clients (du coup ils n’ont peut être justement pas besoin de moi :) ), donc je ne sais pas si c’est rentable pour eux au final, mais en tout cas l’expérience utilisateur est plus agréable et en allant sur leur Une, l’identité visuelle du site se démarque quelque peu des autres sites de presse.

En résumé : on réduit l’inventaire, on y met des formats différenciants ou légers, et dans tous les cas on maximise la visibilité d’une position en particulier. Cette dernière étant vendue plus chère, elle compensera les pertes sur les positions disparues qui étaient vendues à l‘impression. L’amélioration de l’expérience utilisateur et l’ouverture à une gamme plus large de mobiles devraient remonter le nombre de pages vues.
Le fait d’avoir moins d’inventaire permet aussi aux équipes de se concentrer sur la qualité de ce qui est diffusé, ce qui est à mon avis un gros plus pour l’image de marque.

La pub et la qualité

L’image de marque

Une mauvaise publicité ne dégrade-t-elle pas l’image de marque des éditeurs ? Ça semble évident et pourtant je n’ai pas réussi à trouver d’étude sur ce sujet. Les éditeurs historiques devraient protéger leur image de marque, dont la crédibilité est encore un critère qui fait cliquer sur un article par exemple, mais on sent bien qu’ils ont partiellement abandonné la partie !
Rassurez-moi, il n’y a pas que moi qui pense que les services de « content discovery » (en France Outbrain, Ligatus ou Taboola) mettent à mal l’image de sérieux des titres de presse ?

captures d'écran de pubs sans liens avec le contenu

À gauche : « Le Monde » et Outbrain,
À droite « Le Parisien » et Taboola

Je n’ai pas eu à me forcer pour trouver sur « Le Monde » sous un article à propos du traité CETA la mise en avant d’articles aux sujets … variés : femme pulpeuse, mal au dos, fabriquer un vélo, Madonna VS Trump … Et pour « Le Parisien », les thèmes sont petites culottes, photos en bikini et poids des stars, juste sous deux articles à propos du sexisme… Oh Ironie.

Avoir une marque c’est aussi avoir une identité visuelle forte.

Extrait des slides de la conférence de Renaud Forestié sur le redesign des sites de presse

Extrait des slides de la conférence de Renaud Forestié sur le redesign d’un site de presse

Pas facile de se démarquer des autres quand il faut respecter la charte des régies : avoir une largeur de 1000 pixels (à 20 près), un contenu forcément centré et un pavé de droite visible dans les 800 premiers pixels. Compliqué également pour ces journaux de tenter des formats nouveaux, ce qui est un manque à gagner quand on sait que l’introduction de nouveaux formats augmente toujours le taux d’interaction pub (source).

Qui paye la non-qualité des pubs ?

Quand on arrive de l’extérieur comme moi, c’est compliqué de comprendre comment les régies et les fabricants de pub peuvent se permettre de diffuser les choses suivantes.

Des virus !

Titre d’article : MSN diffuse des virus via la publicité

Quand la pub diffuse des virus, c’est l’éditeur qu’on accuse.

Régulièrement des pubs vérolées sont diffusées, y compris par des grands éditeurs comme Yahoo! ou MSN. Les virus exploitent les failles des navigateurs non patchés pour s’installer automatiquement sur les machines. Ne croyez pas que ça ne concerne que les vieux IE sur XP, iOS 10.0 a récemment été vulnérable à ce même genre d’attaques : le simple affichage d’un JPEG permettait de l’infecter. Il est donc rentable pour des groupes criminels de pirater des serveurs de pub ou simplement d’acheter des emplacements avec très peu de budget (RTB + ciblage navigateur). Notez que dans ces cas là, c’est l’image de marque du diffuseur qui prend, pas la régie ni ses prestataires.

Des pubs qui ne marchent pas

Au hasard de mes audits de WebPerf qui se font sans adblocker (moment toujours pénible), il est fréquent de tomber sur des pubs qui non seulement font ramer le site mais qui en plus ne marchent pas. Comme cette pub qui tourne en boucle sur une erreur, fait plafonner le processeur mais ne réussira jamais à jouer la vidéo.

screenshot d’une pub vidéo en erreur

Non, cette pub ne s’affichera jamais, mais on va la facturer quand même.

Des pubs loooooongues

D’autres fois il faut tellement de temps à une publicité pour s’afficher qu’on se demande comment quelqu’un espère gagner de l’argent grâce à elle.

pub très longue à afficher (17 secondes)

La Vache Qui Rame™

Ici il a fallu 17 secondes à la marque pour s’afficher, sur une connexion tout à fait standard. Sur un article passe encore car il y a de bonnes chances que l’utilisateur soit encore là, mais sur une page type Home, résultat de recherche, il n’y a probablement plus personne pour voir la marque.

Qui paye pour ces pubs peu ou pas du tout visibles ?

Il y a deux cas de figure.

L’annonceur paye la régie pour un volume d’impressions. Techniquement tout se joue sur le moment où la comptabilisation de l’impression remonte. Dans le cas « Vache qui rit », il y avait plus de 12 secondes entre la comptabilisation par la régie et l‘apparition de la marque… Dans ces cas, c’est donc les annonceurs qui sont floués, mais ils doivent y être habitués puisque cela fait 20 ans que des pubs sont vendues à l’affichage même si aucun humain ne les voit (56% des pubs ne sont pas vues d’après Google).

L’annonceur achète avec une garantie de visibilité. La visibilité est, d’après le groupement des professionnels de la pub (IAB), lorsqu’au moins 50% des pixels d’une pub sont dans le viewport navigateur pendant plus d’une seconde. Si la comptabilisation se fait honnêtement, c’est à dire après le chargement de la pub mais que celle-ci est trop lente ou en erreur, c’est l’éditeur qui a un manque à gagner en ayant fait une page vue non facturable.

La régie gagne à tous les coups…

Ce ne sont pas de grandes méchantes pour autant : elles sont réactives dès lors qu’on leur signale des publicités en erreur ou qui font planter le site par exemple, et ensuite des rapports de force polis s’installent comme dans toute relation commerciale. Mais disons qu’elles n’ont pas le besoin économique impératif de vérifier toutes les créations de tous leurs prestataires.

Quelles solutions pour les éditeurs ?

Le rapport de force étant en faveur des intermédiaires de la pub, qui ont bien d’autres canaux de diffusion, c’est clairement aux éditeurs de s’organiser pour ne pas périr étouffés.
D’abord en définissant des contraintes de qualité technique (côté éditorial, ça ne peut se faire qu’au cas par cas). Ça tombe bien, l’IAB US a défini un cahier des charges précis où, pour chaque format, ils définissent des limites. Par exemple un Skyscraper ne doit pas dépasser 200Ko au démarrage, puis a le droit de récupérer 300Ko supplémentaires 1 seconde après le chargement de la page. Une vidéo doit se jouer en 24 images/seconde pendant 15 secondes max et un interstitiel animé ne doit pas dépasser 15 secondes.

De la contrainte nait la créativité … et une meilleure rentabilité

De la contrainte nait la créativité … et une meilleure rentabilité

C’est dommage que les pros français de la pub n’en aient jamais entendu parler, mais encore une fois ce n’est pas l’univers bouillonnant des intermédiaires de la pub qui va s’auto-imposer des contraintes tant que leurs clients ne leur demande rien.
On peut aussi définir un seuil de temps processeur à ne pas dépasser et exiger le respect des actions techniques de base (compression, concaténation, mise en cache …). Que l’on utilise ces guidelines ou que chaque site les adapte à sa cible (typiquement, nos réseaux mobiles nous permettent d’être moins stricts qu’aux US), le tout est d’en avoir et de s’accorder dessus avec sa régie.

Une fois les règles définies, il faut passer à la phase de vérification, si possible automatisée donc permanente et systématique.
Je n’ai pas eu connaissance de solution, même commerciale, qui permettrait de vérifier automatiquement les pubs délivrées à partir d’un cahier des charges. Même pour surveiller les tiers de manière générale il n’y a pas vraiment d’offre complète, à tel point que je suis en train de construire ce genre de dashboard sur commande.

Visualisation du poids servi par nom de domaine

Visualisation du poids servi par nom de domaine. Tiens une pub de 3 Mo a arrêté d’être distribuée.

On peut surveiller la consommation processeur, réseau, les temps de réponse des tiers… Pour certaines campagnes ciblées on pourrait récupérer les métriques de visibilité : savoir quand le logo de la marque est visible par exemple, vu depuis les postes utilisateur, information que certaines régies font payer. Lorsque le business model dépend des tiers, ce monitoring peut expliquer la variation de certaines métriques métier comme la baisse du nombre de vues le même jour qu’une défaillance partielle des serveurs de la régie.
À la fin, cela redonne matière à négocier un peu plus de qualité ou peut redonner confiance envers votre prestataire.

Conclusion

Nous avons vu dans un précédent article que les tiers en général (pubs, widgets, trackers, services …) pouvaient vous coûter de l’argent pour des raisons de contre-performance perçue, de distraction, d’atteinte à l’image de marque ou présentaient un risque de fuite de données. Nous avions vu que les solutions techniques existaient mais qu’il faut se laisser le temps de les appliquer lors de l’intégration du tiers (principe « si c’est rapide à intégrer, c’est que ça va ramer »).

Nous venons de voir que la publicité posait ses propres difficultés qui demandent bien plus que les solutions techniques classiques. Les éditeurs ont intérêt à rapidement définir des cahiers des charges et à s’équiper pour s’assurer qu’ils seront respectés pour stopper les pertes de revenus dues aux mauvaises qualités de certaines pubs d’une part, et à l’excès de position d’autre part.
Des éditeurs ont choisi des stratégies d’affichage des publicités qui améliorent grandement l’expérience utilisateur (moins d’emplacements, vendus plus cher) et potentiellement les revenus : qu’attendez-vous pour étudier le sujet ?

Combien coûte un service tiers gratuit ?

Vous auriez tort de croire que la réponse est à moitié dans le titre : n’importe quel script ou service externe que vous rajoutez à votre site va vous coûter quelque chose, qu’il soit gratuit ou pas.

Cet article et le suivant sur les pubs sont une transcription d’une conférence donnée à Blend Web Mix 2016. Cliquez ici si vous êtes plus audio que texte.

De quels coûts parle-t-on ?
Ma spécialité étant la performance frontend, j’ai dû m’attaquer au sujet pour des raisons techniques qui m’ont amené à constater que les dégradations en qualité et en performance perçue se traduisaient par un certain nombre de coûts cachés:

  1. des pertes sèches d’activité
  2. un manque à gagner dû au ralentissement du chargement ou au gel de l’interface
  3. une ouverture pour le piratage industriel
  4. une image de marque entamée.

Qui sont les tiers ici ?

  • Analytics, tracking
  • Boutons de partage, réseaux sociaux
  • Tests A/B
  • Widgets divers : cartes, commentaires, chats…

Et étant donnéées leurs spécificités, citons-les à part : les publicités, auxquelles j’ai dédié un article moins technique.

Passons en revue les problèmes et solutions.

1. Les 20 secondes page blanche

Dans le plus spectaculaire des cas, vous pourriez avoir un site qui n’affiche rien pendant plusieurs secondes.

20 secondes de page blanche, puis affichage du site

Veuillez patienter, nous allons prendre votre temps.

Pour rajouter un peu de sel sur la plaie, disons que c’est le grand patron qui découvre cela un samedi après-midi de vacances. On va alors se lancer dans une partie de Cluedo pour savoir qui a tué le site et les premiers suspects sont les administrateurs système.
Heureusement pour eux, ce sont également fréquemment les seuls à être suffisamment bien équipés en monitoring pour démontrer que les serveurs de la boîte vont bien. Dans le meilleur des cas ils savent mener une analyse rapide du réseau, vue d’un navigateur.

outil chrome dev tools montrant une requête qui ne répond pas

la requête coupable est une longue barre grise, sur-lignée en rouge (forcément)

Après analyse, c’est un petit script hébergé sur un serveur qui ne répond pas qui bloque la page. On passe donc en revue les suspect suivants :

  • les développeurs frontend qui n’ont fait que leur devoir en implémentant la solution demandée par le métier,
  • les services marketing et commercial qui ont légitimement besoin de cette solution de [adserving | test A/B | widget | tracker]
  • le service tiers, qui avait donné comme garantie au moment de l’intégration : « On est sur un CDN ».

L’enfer c’est les autres

Il est très tentant d’incriminer le tiers à la moindre occasion, et parfois c’est justifié, comme cet incident il y a quelques années où certains tunnels de paiement se mettaient à afficher des erreurs de sécurité.

alerte de sécurité SSL de chrome dûe au serveur jquery

une alerte de sécurité du plus bel effet au moment de payer

Les pages touchées étaient celles en HTTPS qui incluaient jQuery depuis le CDN code.jquery.com … dont l’administrateur avait oublié cette après midi là de renouveler le certificat de sécurité.
Mais il y a plein d’autres raisons pour lesquelles un serveur tiers peut ne pas répondre comme :

  • des attaques mettant à mal votre prestataire ou ses propres prestataires. Dans le cas de l’attaque DDoS contre le DNS Dyn, Twitter n’était plus visible de certains endroits de la planète … tant pis pour les pages incluant les widgets.
  • des erreurs réseau de l‘hyper-espace comme la redirection temporaire du domaine Google vers un site de prévention du terrorisme du gouvernement … Uniquement pour les clients Orange un 17 octobre o_O
  • les wifis gratuits publics (hôtels, aéroports…) qui redirigent certaines requêtes pour insérer dans les pages leurs propres régies publicitaires
  • les firewalls d’états (Chine en tête) ou les proxys d’entreprise qui ont une opinion tranchée sur l’utilisateur Facebook ou Youtube et qui bloquent les domaines : dommage pour les widgets et analytics

Bref : il y a 1001 raisons pour qu’un serveur tiers plante ou ralentisse, il faut donc prévoir son intégration avec cet état de fait.

Savoir intégrer les tiers

Généralement l’intégrateur reçoit simplement comme instruction un mail disant :

Insérez ce script dans le <head>

J’exagère un peu, parfois on a droit à un document Word formaté proprement (mais qui dit la même chose).
Il arrive aussi que les développeurs décident d’eux même de faire une bêtise :

  • inclusion de librairies JS / CSS directement depuis leurs CDNs respectifs, comme le préconisent les documentations,
  • récupération des fichiers de polices depuis les serveurs Google Fonts ou autre.

Dans ce dernier cas, il peut y avoir l’excuse de la licence qui n’autorise pas forcément le rapatriement du fichier. Du coup vous faites subir à vos utilisateurs le comportement par défaut de tous les navigateurs (sauf IE) qui n’affichent pas le texte tant que le fichier de police n’est pas présent.

Je vois pas le problème

Pour visualiser les problèmes d’intégration, et surtout leurs conséquences pour l’utilisateur, je ne saurais trop vous recommander les outils suivants :

  • L’indispensable service en ligne WebPagetest : déplier « Advanced Settings », onglet « SPOF » et y mettre les noms d’hôtes à faire planter.
  • L’extension Chrome SPOF-o-Matic qui permet d’alerter, de tester et même de programmer un test comparatif sur WebPagetest.
  • En ligne de commande (pour l’intégration continue par exemple), je vous ai fait un petit script par dessus SPOF-check
capture de l’interface SPOF-o-Matic

l’extension SPOF-o-Matic débusquant les potentiels fauteurs de troubles

Solutions

Pour ne jamais dépendre d’un tiers, il n’y a qu’environ 2 stratégies :

  1. Les ressources critiques sont à rapatrier sur vos propres serveurs. Le CSS bien sûr, les dépendances JS, les polices si vous en avez le droit.
  2. Tout ce qui reste hébergé ailleurs doit passer en asynchrone : trackers, analytics, widgets, les polices

Il y a certains cas spéciaux comme l’inclusion des tests A/B qui sont à la fois dynamiques et critiques pour le rendu de la page, étant donné qu’ils essayent de le modifier. Mais si vous demandez poliment une mécanique de « timeout » ou un rapatriement périodique du fichier, vous n’aurez plus de soucis.

2. Les retards à l’allumage

Une fois traité le problème impressionnant mais rare de la page blanche dûe à un tiers, reste le problème sournois du ralentissement quotidien, moins visible mais bien plus coûteux. Même avec des inclusions asynchrones on peut se retrouver dans ces situations

un moteur de recherche de voyages mis en attente

Moteur de recherche (95% du business) attendant une régie pub (5% du business)

Beaucoup (trop) de fonctionnalités dépendent complètement de JavaScript et de moins en moins de développeurs tentent l’amélioration progressive. Dans certains cas comme ici un moteur de recherche complexe, il est même irréaliste de vouloir afficher un moteur sans JS, d’où l’idée de mettre une interface de chargement pour patienter. En sachant que ce code métier critique est inclus en haut de page, quand l’exécuter ? Du pire au mieux :

  1. en haut de page ! Bien sur que NON, le DOM n’est pas forcément disponible à ce moment-là (ce qui ne se voit pas forcément quand on développe sur son poste en local d’ailleurs :) )
  2. on fait confiance à StackOverflow et on attend que document.readyState === 'complete' … Cela correspond à l’événement window.load, c’est-à-dire qu’on va attendre patiemment que toutes les images, iframes et même certains scripts asynchrones soient chargés ! L’utilisateur n’attendra pas, lui.
  3. on attend l’événement document.DOMContentLoaded (en jQuery : $(document).ready(init) ou juste $(init)). Cet événement est retardé par les insertions de scripts même en bas de page, les scripts asynchrones avec l’attribut defer et toute exécution de script, dont le tueur de performances document.write(). La pub utilise toujours cette instruction.
  4. juste après le code HTML du formulaire : vous avez à la fois la garantie que le DOM est présent, et d’être exécuté avant tous les événements navigateur. C’est ce que je recommande pour du code critique comme ce formulaire.

Il y a donc un conflit ouvert entre le tiers inclus et votre code métier, que vous pouvez résoudre en exécutant plus tôt votre code. Si vous persistez à vouloir dépendre de l’événement DOMContentLoaded pour exécuter votre code, il va falloir travailler au corps l’inclusion des scripts des tiers :

  • s’ils ne sont pas lourds à l’exécution et importants, le plus bas possible dans la source avec l’attribut standard async (IE10 +)
  • s’ils sont secondaires, en inclusion asynchrone classique après le chargement de la page (natif façon Analytics ou $.getScript)
  • refuser les scripts dépendant ou utilisant document.write() (d’ailleurs partiellement dépréciée par Chrome).

La pub est spéciale : les régies ne peuvent pas se passer de l’instruction document.write() car leurs propres fournisseurs l’utilisent peut-être. La solution technique est simplement d’inclure la publicité en iframe, ce qui interdit certains formats invasifs. Désolé de vous le dire mais si votre business dépend de la pub et que vous vous êtes engagé à afficher des pubs qui peuvent déborder de leur cadre, il n’y a pas de solution purement technique ! On va voir dans un autre article qu’il y a matière à bien faire, mais que les décisions sont loins d’être techniques.

Après le chargement

Vous avez forcément déjà constaté les effets d’interface gelée voire de crash sur mobile, ou vous avez eu l’impression que votre ordinateur portable allait décoller de votre bureau par la seule force de ses ventilateurs. Pour faire le test, je vous conseille de visiter cette page parodique sans adblock, voire sur mobile : http://worldsmostshareablewebsite.greig.cc/, qui se contente d’inclure plusieurs fournisseurs de boutons de partage. Sur une tablette Nexus 7, l’interface est gelée pendant 20 secondes.
La nouvelle bataille de la performance frontend, est clairement les temps d’exécution abusifs côté client. J’ai déjà eu le cas avec de « simples » inclusions de bouton de partage (Facebook et G+ en tête) mais c’est le cas avec n’importe quel script qui va modifier l’interface. Il y a un principe général à comprendre avec les tiers :

Si c’est rapide à intégrer, c’est que ça va ramer

Les tiers, en particulier s’ils ont une version gratuite, ont 2 besoins antinomiques : simple et passe-partout. Le tutoriel doit paraître simple et consiste généralement en une inclusion de script et à la création d’un peu de HTML. À l’image du bouton Facebook.

code d’inclusion du bouton facebook

Trop simple pour être performant

Remarquez que l’insertion du script est généralement asynchrone comme ici, car les tiers ont fait des efforts pour ne pas bloquer les chargements ces dernières années.

Détecter le problème

Maintenant mettez vous à la place du développeur de ce code : comment faire pour savoir où afficher son widget ? La réponse est aussi simple que contre-performante : en s’auto-exécutant dès que possible, et en scannant le DOM régulièrement. Selon la lourdeur initiale de votre site, on peut vite arriver à de jolis blocages dont vous ne comprendrez l’origine qu’avec un profilage en règle. Notez qu’il faut utiliser de vraies machines pour tester correctement tout cela.

capture d’écran de l’outil de profilage chrome

3 longues secondes d’exécution pour ce seul tiers

Le fichier mis en cause ici (post-widget.js surligné en gris) provient effectivement d’un tiers qui inclut des boutons sociaux. Il bloquait l’interface et faisait même régulièrement planter un iPad mini 2. À sa décharge, la page visée était lourde et contenait 150 éléments que le script recherchait et modifiait.
Il n’existait pas d’outil dédié — même payant — permettant de déceler facilement qui était responsable des pics de charge processeur sur une page. J’ai du écrire un petit script du nom de 3rd-party-cpu-abuser qui exploite la timeline de Chrome Dev Tools pour mettre des noms sur les responsables :

tableau de statistiques de consommation CPU

80% du CPU consommé l’est par les tiers

WebPagetest a également récemment introduit une visualisation du CPU répartie par fichier JS : onglet « chrome », case « capture devtools timeline »).

Pour débloquer la situation, je me suis contenté comme souvent d’aller lire la documentation pour y chercher 2 optimisations classiques :

  • comment ne pas initialiser le script automatiquement, afin d’éviter l’effet Big Bang du début de construction de page et ne l’exécuter qu’au moment opportun.
  • comment indiquer le DOM à modifier, pour éviter les recherches DOM coûteuses

Pratiquement tous les fournisseurs de widget proposent maintenant ces options dans leurs APIs. Si ce n’est pas le cas, c’est mauvais signe donc partez chez le concurrent !

3. L’espionnage industriel

Les réseaux sociaux

La performance

Rajouter quelques boutons de partage n’est pas aussi gratuit que ça en a l’air. Il y a bien sûr la performance utilisateur, qui en pâtit.

comparaison de screenshot montrant le chargement d’une page wordpress avec et sans boutons

4 boutons = ralentissement de l’affichage et du temps de chargement

Sur cette page wordpress simple et optimisée, rajouter 4 boutons natifs multiplie le temps de 1er affichage et de chargement par deux !

Les taux de transformation

Mais il faut aussi se demander si ces boutons apportent vraiment quelque chose au site. Par exemple Smashing Mag en 2012 avait constaté qu’en ENLEVANT le bouton Facebook, leurs utilisateurs partageaient plus les articles sur Facebook !

le traffic depuis Facebook a augmenté depuis que nous avons enlevé les boutons FaceBook de nos articles

Smashing Mag : « le trafic depuis Facebook a augmenté depuis que nous avons enlevé les boutons FaceBook de nos articles » (2012)

NB: Entretemps Facebook a sorti un bouton « Partage » plutôt que simplement « Like », et Smashing Mag l’a ré-intégré de manière statique.

Autre exemple : un test A/B fait par un site de e-commerce qui a consisté à SUPPRIMER ces boutons de la page produit et leur a permis de constater que cette suppression AUGMENTAIT les taux de conversion de 12%. Ils supposent que finalement ces boutons n’étaient qu’une distraction à ce moment-là, et que les chiffres de partage affichés, proches de 0 comme souvent dans le e-commerce, renvoyaient un sentiment négatif. J’y ajouterais que la légère dégradation de performance induite par ces boutons a dû contribuer :)

Bref : comme pour n’importe quelle fonctionnalité, demandez vous si elle ne dessert pas plutôt votre produit, ou s’il n’y a pas une meilleure manière de l’intégrer.

Nourrir vos concurrents

La raison d’être secondaire de ces boutons pour Google et Facebook est qu’il leur permet de mieux qualifier leurs propres utilisateurs, en dehors de leurs propres murs. Même lorsque l’utilisateur n’interagit pas avec, leur simple présence signale à G. et FB qu’un de leurs utilisateurs visite une page, leur permettant ainsi d’affiner les profils. Dans le cas de Google, l’utilisateur n’a même pas besoin d’avoir un compte. Ne me lancez pas sur le respect de la vie privée, d’autres le font mieux que moi, parlons plutôt argent.
À toute fin utile, il faut tout de même rappeler que Google mange 42% du marché de la publicité en France (95% des 47% du CA de la search).

Pour le marché qui vous intéresse probablement, c’est-à-dire le « display » (affichage de bannières classiques) on estime que Facebook en capte 30%. Ce que les annonceurs apprécient, outre l’audience, c’est que leur base est hyper qualifiée, et c’est en partie grâce aux sites qui incluent les boutons.
Déjà que ces boîtes s’évitent un maximum d’impôts en France, ce n’est pas la peine de leur faire de cadeau supplémentaire en utilisant leurs scripts tels quels.

Les solutions

En admettant que vous ayez déterminé que les boutons de partage étaient vraiment bons pour votre site (typiquement, un site d’articles), il existe des manières d’inclure qui ne nourrissent pas vos concurrents, sont performantes et respectent votre charte graphique :

  1. les boutons statiques, qui sont des liens simples formatés permettant le partage et que vous pouvez mettre par dessus de simples icônes
  2. si vous avez besoin de fonctionnalités supplémentaires comme des icônes toutes faites, afficher les compteurs ou avoir des analytics, vous pouvez rajouter un peu de JavaScript. Voici une solution open-source parmi d’autres
  3. enfin il existe quantité de services tiers (addThis, shareThis, shareAholic …) mais on retombe sur les travers habituels des tiers : il faut benchmarker les temps de chargement car ils vont du simple au triple et le business model de certains comme shareAholic est de revendre les données utilisateur

Les tiers des tiers de vos tiers

Le problème

Quand il n’y en a qu’un ça va

S’il est normal de faire confiance à un prestataire direct, la confiance ne peut que s’étioler au fur et à mesure de la chaîne d’appel de leurs partenaires. Or quand vous accordez techniquement les pleins pouvoirs à votre prestataire (une simple insertion de script), vous les accordez également à toute une chaîne de sociétés dont vous n’aviez peut-être jamais entendu parler. Je vais utiliser l’outil RequestMap pour visualiser un affichage sur la Une du journal Le Monde.

visualisation des requêtes faites vers les 1er tiers

Appels vers les tiers de 1er niveau

Chaque cercle est un nom de domaine, les flèches sont les appels. Au centre en bleu clair, le domaine principal www.lemonde.fr qui appelle 2 sous-domaines de statiques (s1 et s2.lemde.fr). Tous les autres domaines (cercles) appartiennent aux tiers de 1er niveau et correspondent à une quinzaine de sociétés. On y trouve 3 solutions d’analytics, une solution de test A/B (Kameleoon), un tracking de réseau social (Po.st), FaceBook, un moteur de recommandation d’articles (Outbrain ici), Cedexis … Ce sont les tiers de 1er niveau : ceux que l’on inclut de manière tout à fait consciente. Les relations avec ces tiers sont régies par un contrat direct ou par l’acceptation des CGU, et tant que les principes d’intégration cités plus haut dans cet article sont respectés, je n’ai plus rien à rajouter.

Puis arrive le moment où l’on contacte la régie pub (SmartAd en l’occurrence, à droite sur le graphe précédent, à gauche sur le graphe suivant).

Tiers de niveau 2, 3 et 4 … Oh la belle rose

Appel des tiers de niveau 2, 3 et 4 … Oh la belle rose


Une fois sur son domaine, la régie appelle une dizaine de sociétés, principalement des tags de tracking, puis 2 systèmes de mise aux enchères de mon profil utilisateur. C’est la société de RTB CasaleMedia qui prend le relai, et qui contacte une vingtaine d’autres sociétés. Cela c’est côté client, on ne sait pas combien d’enchérisseur ont accès au profil utilisateur côté serveur. L’enchère a été gagnée par une société de retargeting (Turn) qui elle-même contacte une vingtaine de sociétés.
En tout c’est 50 sociétés qui ont été contactées côté client. Si le script du 1er tiers inclus de manière classique, ces 50 sociétés avec qui vous n’avez aucun contrat ont tout pouvoir sur la page. Il leur est techniquement possible de la modifier (on a vu des sociétés malhonnêtes remplacer les publicités des autres) ou d’y récupérer des informations : outre les informations de navigation, elles pourraient cibler un site de e-commerce et estimer ses ventes et leur nature par exemple, simplement en scannant le DOM. Ces scénarii sont pratiquement indétectables et quand on voit qu’il arrive que des pirates diffusent des virus grâce aux régies publicitaires, il n’est pas irréaliste d’imaginer une société voulant récupérer des informations chez son concurrent.

Les solutions

Se parler !

Les premières actions ne sont pas techniques du tout.
D’abord, lister quelles sociétés atterrissent sur vos pages, avec des solutions :

Ensuite, du côté des contrats signés avec vos partenaires, vérifiez que leurs partenaires à eux vous conviennent et demandez-vous quels engagements de moyens ils ont et pourquoi pas imaginer un système de pénalités. Les régies savent se montrer réactives lorsqu’un de leurs clients leur signale un problème avec un prestataire, mais détecter le problème en question est très compliqué.
Enfin, il faut établir un dialogue entre les équipes IT et les utilisateurs des services tiers (marketing, produit, commerciaux …), en faisant un point régulier « Tiers », avec l’ordre du jour suivant :

  1. l’IT fait l’inventaire des tiers de 1er niveau et remontent éventuellement les problèmes rencontrés
  2. côté business, on classe par ordre d’importance les tiers … oui il va y avoir du débat !
  3. décisions de suppression
  4. décisions quant à l’ordre de chargement

On se retrouve à prendre des décisions complexes car comment décider de ce qui est plus important entre un test A/B, les analytics, le player vidéo, les pubs, la carte ou les boutons de partage ? Il faut pourtant que ce soit une décision réfléchie car jusqu’ici, cette décision était de fait laissée à l’intégrateur et au navigateur …

Côté technique

Si votre business model vous permet de vous passer des publicités invasives, ce qui est le cas des sites de e-commerce par exemple, alors je ne saurais trop vous recommander la bonne vieille technique de l’inclusion en iframe. Cela gomme les inconvénients de document.write(). L’attribut sandbox vous permet (depuis IE9) d’accorder aux tiers d’accéder à votre page, vos cookies ou le droit d’ouvrir une popup.
<iframe sandbox="allow-scripts" src="carre_pub.html" /> suffit pour les publicités classiques : il autorise JavaScript, mais la sous-page ne peut rien faire sur la page principale. Si vous avez besoin de communiquer, l’API postMessage est là pour ça !

Pour aller plus loin, mais je ne l’ai encore jamais vu en production, il y a le standard Content Security Policy (à partir de Edge) qui permet entre autres de limiter les pouvoirs donnés aux tiers inclus directement en JavaScript. Pour une transition en douceur, vous pouvez passer par une phase d’observation des erreurs côté client (report-uri). Maintenant on ne va pas se mentir : la vraie difficulté, c’est de faire admettre que l’on veut limiter le pouvoir des tiers, pas de les en empêcher !

Conclusion

Les tiers posent leurs lots de problèmes mais ils ont pratiquement tous une solution technique, au contraire des publicités. Du moment que l’on fait attention au moment de l’intégration et que l’on surveille les régressions de performance, on évite la plupart des écueils. Si vous avez plus de quelques services externes et qu’ils peuvent mettre en péril votre business, mettre en place une solution de monitoring dédiée est à envisager rapidement.

Le web mobile et la performance

Cet article a été rédigé initialement pour 24 jours de web : http://www.24joursdeweb.fr/2014/le-web-mobile-et-la-performance/

Tout site sortant aujourd’hui doit avoir été pensé avec des contraintes mobiles, et utiliser des techniques d’amélioration progressive pour délivrer rapidement les fonctionnalités sur toutes plateformes.

En attendant cette conclusion, nous commencerons par essayer de connaître notre utilisateur, puis nous verrons les tactiques et stratégies propres au mobile.

Où est le problème ?

La 4G a débarqué, des mobiles à 8 processeurs se vendent, et la plupart des gens utilisent leur mobile depuis chez eux : en Wifi ! À priori le métier de spécialiste performance web serait donc mort et vous me trouverez en train de parler HTML5 à mes chèvres dans le Larzac, merci au revoir. À moins que…

L’utilisation

La « situation de mobilité » est-elle un mythe ? L’expérience et une étude Googlemontrent clairement que les ¾ des gens utilisent majoritairement leur mobile depuis le confort de leur canapé / lit / lunette, derrière le wifi familial. 15% de ces mêmes Français ont même la fibre.

Le temps passé dans une situation confortable est majoritaire mais cela est justement dû à la réalité de la situation de mobilité : cela doit être très rapide. Dans un magasin, les gens vérifient les prix des concurrents sur le Web : si votre page ne s’affiche pas en plus de quelques secondes, vous avez perdu la guerre des prix dès la première bataille (afficher le prix) ! Dans la rue, l’utilisateur va vouloir connaître les horaires de cinéma ou les restaurants du coin : si c’est votre coeur de métier vous n’aurez toutes vos chances qu’en affichant rapidement l’information demandée. Dans les situations d’attente, les gens dégainent les téléphones pour consulter réseaux sociaux et mails : si votre page a la chance d’être dans leur fil d’information, il va falloir afficher la promesse très rapidement (un article sur les félins à travers les âges, une vidéo de chats, le lolcat du jour…). Enfin la préparation d’achat se fait fréquemment sur mobile (plus discret dans l’open space, à portée de main lors des pauses clope voire au feu rouge), même si la finalisation de la commande se fait encore majoritairement sur l’ordinateur du foyer voire sur tablette.

Tout cela ne compte que pour quelques secondes dans les statistiques mais les utilisateurs se souviendront de votre marque de manière très positive si vous avez résolu leur problème rapidement.

La connexion

Les données de cette année montrent clairement une amélioration des débits 3G (6 Mb/s en moyenne selon Akamai) et la 4G à la française envoie du poney au galop (21-32 Mb/s constatés selon Degrouptest, pointes de 34 Mb/s selon Akamai).

Mais si vous êtes utilisateur régulier du mobile, vous devinez la vérité derrière ces excellentes moyennes : même avec une puce et un abonnement 4G vous ne chargez parfois pas du tout les pages et vous esquissez un sourire triomphant lorsqu’un site web se charge aussi bien qu’au bureau. C’est parce que l’ennemi numéro 1 du chargement de page web reste la latence réseau, et même sur une 4G de bonne qualité les latences constatés par Degrouptest sont entre 50 et 100 ms.

Concrètement :

  • ligne du haut : une 4G de cadre parisien avec 20 Mb/s de débit mais 200 ms de latence (les murs de Paris sont épais),
  • ligne du bas : l’ADSL de la mamie du Cantal avec Mb/s et 20 ms de latence (oui son DSLAM est proche).

La mamie du Cantal gagne (et avec un ping pareil, elle frag aussi de l’ado à tout va).

La mamie du Cantal gagne
(et avec un ping pareil, elle frag aussi de l’ado à tout va).

L’affichage via la connexion à 2 Mb/s commence 1 seconde plus tôt, le formulaire est utilisable 2 secondes plus tôt et le site au complet se charge 5 secondes plus vite.

Ajoutez à cela que les réseaux 3G des grandes villes sont saturées, et qu’en fonction de l’endroit, de l’heure de la journée, du jour de la semaine et de la position de votre doigt sur le mobile, les performances ne sont pas du tout les mêmes. Dans certains cas pas un octet ne passe.

Tout ça pour dire que les grands principes de la limitation du nombre de requêtes d’abord, puis du poids du contenu restent valables.

L’utilisateur

Tout le monde n’investit pas dans un bidule avec 8 processeurs et 3 Go de RAM, par contre les utilisateurs mobiles sont clairement habitués à ce que les interfaces soient fluides et réactives, et même à ce qu’on leur affiche des données en l’absence de réseau. Ajoutez à cela le fait que l’on sert fréquemment des sites mobiles minimalistes et vous comprendrez que l’utilisateur a bien du mal à accepter que les sites qu’il consulte mettent du temps à apparaître, ou laggent lorsqu’il scrolle.

Du coup un tombereau d’études utilisateur ou d’analyse statistiques démontrent ce que l’on pressent déjà : le temps coûte cher.

Absolument tous les indicateurs marketing sont touchés :

  • le taux de rebond (Etsy : ajouter 160Ko d’images = +12% de taux de rebond),
  • le taux de clic (DoubleClick : supprimer 1 redirection = +12% de taux de clic),
  • l’abandon pur et simple de la page (Radware : 60% d’abandon après 4 secondes de page blanche),
  • l’abandon du processus d’achat (Wallmart : -50% de conversion par seconde),
  • l’abandon du visionnage (Akamai : -6% de vidéo vue par seconde d’attente),
  • la perception négative de la marque.

Le côté amusant de l’histoire : si vous surveillez vos taux de rebond sur mobile en vous disant « ça va encore, » dites-vous que les statistiques sont en dessous de la réalité puisque dans les cas des pages blanches, il est probable que la requête remontant sur le serveur qui comptabilise les hits ne soit jamais partie.

Nos sites !

Étant donné que les grands chefs regardent les sites sur des mobiles qui valent le prix de ma première voiture, via le wifi de la boite et qu’ils s’arrêtent à la homepage, forcément il y a un peu de laisser-aller sur les sites, y compris dédiés mobile. Le poids des sites dits dédiés mobile (mDot) augmente régulièrement. La bonne idée d’avoir un site mobile dépouillé et ergonomiquement efficace s’efface pour laisser la place aux mauvaises habitudes des sites desktop : on met tout sur la HomePage, et on rajoute un maximum d’information sur les pages intérieures.

Le RWD devient la norme pour les refontes graphiques, mais rarement le « mobile first » : on se retrouve donc avec des spécifications planifiant 5 breakpoints, devant afficher des images « retina » tout en gérant IE 6 (oui cette spécification existe vraiment). Le poids des sites en général a doublé en 3 ans et grâce au RWD on demande maintenant d’afficher des sites de 2 Mo et 100 requêtes sur mobile. Ça finirait par arriver si l’utilisateur était encore là pour le voir.

Sur ces même sites cross-device, votre département marketing a bien sûr opté pour la totale :

  • de l’analytics (augmentation du nombre de requêtes),
  • des publicités (poids, temps d’exécution, requêtes),
  • de l’A/B Testing (retardement volontaire de l’affichage, temps d’exécution),
  • des boutons sociaux (le moindre bouton G+ rajoute 100 Ko et des dizaines de requêtes)

Et les tendances webdesign du moment ne sont plus aux coins arrondis qu’on aurait pu régler en CSS3 en pouffant, mais aux polices de caractère (blocage temporaire du rendu, texte invisible, poids), aux « hero images » (l’image principale en 1200×800, retina-ready, cordialement) ou pire aux slideshows (pourtant une mauvaise idée) qui peuvent charger de grosses images invisibles.

Chargement du site Promovacances

Chargement du site LEquipe.fr

Veuillez patienter, un opérateur va prendre votre appel

L’arsenal technique

Le problème est donc bien réel et s’inscrit dans la durée : les utilisateurs seront de plus en plus exigeants, les sites de plus en plus gourmands, et la latence des réseaux mobiles ne fera pas de grands progrès. Ce qui tombe bien c’est qu’on peut y faire quelque chose.

Le chemin critique

D’accord le chemin critique est connu depuis 2006, désolé de redire les choses mais sur mobile il ne faut surtout pas se rater sur les bases. Prenons un cas un peu extrême (iOS < 8, grosse latence, débit correct).

Chargement du site LeMonde.fr

La fameuse angoisse de la page blanche (1 case = 1 seconde)

Pourquoi 9 secondes avant le premier pixel, et 10 avant de voir quelque chose d’utile ? Regardons l’action au ralenti, avec la trace réseau suivante.

Vue réseau sur LeMonde.fr

Le trait vert est le premier Graal.

Vous pouvez considérer que tout ce qui est à gauche de la ligne verticale verte (l’affichage du premier pixel) est sur le chemin critique. Un effort d’optimisation est déjà en place car les CSS sont déjà groupés et les JavaScript sont chargés de manière asynchrone. Sauf que c’est à cause de cette dernière optimisation que le site est ralenti : ce qui marche sur navigateur de bureau n’est pas forcément vrai sur mobile.

Déplacer les JavaScript en bas de page aurait aussi été une mauvaise idée, grâce à notre ami Safari iOS qui refuse d’afficher quoi que ce soit tant que ces fichiers ne sont pas là. Ici comme sur la plupart des sites, on gagnerait plusieurs secondes en chargeant de manière classique les fichiers JS agglomérés, en haut de page.

Pour résumer :

  • testez sur les vraies plate-formes avant d’appliquer des recettes qui marchent ailleurs.
  • choisissez la bonne stratégie de chargement des JS : de manière classique en haut de page, ça marche souvent très bien
  • les recettes classiques doivent être appliquées : groupement en 6 requêtes maximum des HTML / CSS / JS
  • minification et gzip des ressources de type texte

La police

Les fonts sont la grosse tendance 2013 et sont maintenant présentes sur la moitié des sites. C’est joli tout plein mais ça retarde encore le moment où l’utilisateur peut accéder au contenu. En fait il y a 3 états possibles pour l’affichage de votre texte.

Chargement des polices sur LEquipe.fr

Les phases possibles pour un chargement de police

Phase 1 : pas de bras, pas de chocolat, le texte est là mais masqué. Un peu dommage pour un site essentiellement basé sur le contenu textuel.

Phase 2 : le navigateur en a marre et vous sauve la mise en affichant le texte. Mal stylé mais fonctionnel.

Phase 3 : tout va bien, le site est quasiment comme sur la maquette. On espère que l’utilisateur regarde encore.

Savoir coder

L’art ancestral de l’amélioration progressive doit aussi s’appliquer aux polices : la phase 2 n’existe que si vous avez bien pensé à préciser une police système de fallback. Dans le cas contraire l’utilisateur regardera plus longtemps le site sans rien pouvoir y lire.

Pour raccourcir voire éliminer la phase sans tete lisible, il s’agit de faire un travail approfondi de coopération intégrateur / designer : 1 ou 2 polices maximum, de moins de 40Ko, testées sur toutes les plate-formes (mention spéciale à Chrome sur XP)

Ensuite vient le travail d’optimisation :

  • la font critique doit avoir sa place dans vos 6 premières requêtes.
  • chargement asynchrone des polices secondaires (variantes, titres invisibles, police d’icônes…).

Il y a des techniques plus avancées permettant de toujours afficher du texte même si ça n’est pas la font finale, ce qui ne plaît pas toujours. Vous pouvez également utiliser les data:uri et un encodage base64 de votre police directement dans le CSS, mais vous l’alourdissez du poids de la police.

Testez.

Se méfier des autres

Je vois encore des développeurs inclure des scripts depuis des serveurs qui ne leur appartiennent pas. Il s’agit le plus souvent d’une version plus ou moins à jour de jQuery ou de HTML5 shim. Les bénéfices sont nuls, et le risque énorme. Vous pensiez sérieusement que les serveurs des grands de ce monde sont disponibles 100% du temps ? Ou qu’ils répondent toujours plus vite que vos propres serveurs ?

Non.

Single Point Of Failure Facebook

SPOF ? pouf.

Sur ces graphes, on voit les temps d’affichage de sites majeurs (ligne du haut) augmenter de 20 secondes pendant le temps où les serveurs Facebook sont moins disponibles. Pour faire le point des dangers page par page, je vous conseille d’utiliser SPOF-O-Matic.

Sur mobile la résolution du nouveau nom de domaine est particulièrement pénible à cause de la latence. Les stratégies sont relativement simples, en fonction de la nature de la ressource :

  • widget / bouton : utiliser la version asynchrone pour ne pas dépendre des autres,
  • widget / bouton : mieux, une version statique vous évite 100-200Ko et des temps d’exécution énormes,
  • JavaScript ou CSS tiers : rapatriez le script bien au chaud chez vous, groupez-le avec les autres si il est critique
  • polices : rapatriement sur vos serveurs, quitte à payer une licence

Publicités, trackers et autres A/B testing

Ils requièrent tous d’être en haut de page pour être exécutés en premier et sont massivement déployés sur les sites même dédiés mobiles. Le département marketing moderne se doit de posséder au moins un exemplaire de chaque catégorie.

Poignée de main

« J’ai dépassé mon objectif de 42 régies pub sur la home, et toi ?
— Je viens de découvrir 4 fournisseurs d’A/B testing, ça part en prod demain »

Les solutions techniques non bloquantes sont à négocier d’abord en interne pour faire prendre conscience du problème, puis auprès des fournisseurs, de moins en moins réfractaires. On arrive fréquemment à mettre les publicités dans des iframes et les scripts de tracking en asynchrone. Pour l’A/B testing ou certaines zones de publicité vitales, une bonne option, techniquement complexe, consiste à rapatrier en local, de préférence de manière automatisée, le code JS du prestataire, puis à l’inclure comme le reste des JS critiques en haut de page.

Les 3 caches

C’est comme les 3 coquillages : on peut faire sans, mais les gens du futur se moqueront. Partant du principe qu’il n’y a pas plus rapide qu’une requête qu’on ne fait pas, il convient de maîtriser rapidement les 3 techniques suivantes sur mobile.

Le cache HTTP

Depuis toujours la recette est simple :

  • mettre des temps de cache très longs sur toutes les ressources statiques (plus d’1 mois),
  • en cas de mise en production d’une nouvelle version, la mise à jour des caches clients se fait par le changement des URLs pointant sur les statiques.

Point.

Sur navigateurs de bureau, on pourrait s’arrêter là mais sur mobile le cache HTTPpeut se révéler très volatile, voire capricieux. Si l’OS estime qu’il a besoin de mémoire, il peut vider le cache du navigateur. C’est la raison pour laquelle certains sites ont développé leur propre système de mise en cache, en se basant sur localStorage.

DOM Storage

localStorage est un système simplissime de stockage de clé / valeur, de 5Mominimum. Pour limiter les accès au serveur, stockez-y des informations aussi simples qu’un historique de navigation ou lourdes et complexes, comme une liste de toutes les marques automobile et des modèles. L’utilisation en est tellement facile que c’en est ennuyeux.

Du coup certains en abusent.

localStorage sur Google

Tiens, du CSS dans mon localStorage

Certains sites stockent carrément du HTML, du CSS, du JavaScript, des images ou des fonts puis via un système classique de gestion de session évitent de renvoyer les ressources au client.

Application Cache (dit offline)

L’énorme avantage ergonomique d’une application native installée chez l’utilisateur, c’est qu’elle va s’ouvrir quand vous appuyez dessus, même si à ce moment-là vous transitez par le tunnel sous la manche. Imaginez que l’on puisse faire de même avec nos sites : il suffirait d’aller une seule fois sur une des pages pour rapatrier l’ensemble de l’interface, et toute la navigation se ferait en local. Les mises à jour du contenu ne se feraient que lorsque la connexion est rétablie et on ne dépendrait pas de la validation d’un store pour mettre à jour son application.

Figurez-vous que la technologie existe, et date même d’une époque lointaine où Apple ne pensait pas encore à l’app store et à Objective C pour écrire des applications mais bien au Web et ses langages . Faites-moi plaisir et enfourchez votre mobile pour aller sur l’URL suivante :

http://appcache.offline.technology/demo/

Une fois la page chargée complètement (scrollez en bas pour voir les logs), passez offline (mode avion), puis allez sur la 2de page nommée cache. Non seulement la page s’affiche comme si de rien n’était mais l’image du machin vert est également présente alors qu’elle ne peut pas être dans le cache HTTP classique.

Belle bête

Belle bête

Si vous utilisez Chrome, vous pouvez regarder sur chrome://appcache-internals/votre liste des sites utilisant cette technologie.

À ce stade de la compétition vous avez peut être déjà entendu dire beaucoup de malsur appCache. C’est effectivement le genre d’API qui demande du temps et de l’amour pour être bien comprise, mais elle apporte un énorme confort utilisateur et est très bien supportée sur mobile et même sur bureau. Elle est très adapté aux sites qui se comportent comme des applications (une seule page) mais il existe des techniques à base d’iframe pour partager ce super cache entre plusieurs pages d’un site plus classique.

Les images

Elles représentent fréquemment les deux tiers du poids des sites et ralentissent le chargement des ressources critiques.

Éviter de les charger

Captain Obvious a dit : c’est plus rapide sans image. C’est pas faux et il commence à y avoir pas mal de techniques permettant d’éviter des requêtes :

  • CSS3 pour les dégradés, arrondis, rotations et opacités. Dommage que ça ne soit plus à la mode.
  • Les caractères unicodes des polices fournies avec les OS : ►★✓ ⇨ (attention si vous visez également IE8 sur Windows XP)

Lorsque certaines images sont critiques pour votre interface, vous pouvez les embarquer directement dans le HTML ou le CSS. C’est la technique du data:uricouplé à l’encodage en base64. Oui ça a l’air sale mais uniquement si c’est mal fait.

L’image la plus importante à charger est celle indiquant justement qu’il y a chargement ! Pourquoi ne pas mettre également le logo ou une image de contenu réellement importante.

Chargement du site Promovacances

L’image d’attente arrive bien avant toutes les autres

Il ne faut pas abuser de la technique car elle alourdit le HTML et le CSS qui sont des ressource critiques, mais sur quelques petites images stratégiques cela fait patienter l’utilisateur.

Chargement à la demande

C’est à se demander pourquoi les navigateurs ne le font pas déjà d’eux-mêmes : l’idée est bêtement de ne pas charger les images qui ne sont pas visibles ! C’est radical pour les sites avec beaucoup d’images car cela libère la bande passante pour les ressources critiques et les images qui sont visibles. Voici un bon exemple de librairie, utilisé notamment sur lequipe.fr, bureau ou mobile. Naviguez dessus (c’est pour le travail) et scrollez très vite : vous verrez les images apparaître au fur et à mesure de votre progression dans la page.

Cette technique seule sauve des dauphins tous les jours.

Les images responsive

Comment servir le meilleur rapport poids / qualité à l’utilisateur mobile ?

Le standard

Votre plus grand problème concernant les images à délivrer sur mobile est de comprendre ce que vous voulez réellement en faire. Le problème est de définir le problème si vous voulez, en répondant à ces 4 questions :

  • adaptation à la taille du viewport : veut on servir des petites images aux petits écrans ?
  • écran haute densité de pixels (ok, retina©) : veut-on leur servir des images de très haute qualité ?
  • art direction : pourquoi ne pas afficher des images au cadrage différent en fonction de la taille de l’écran ?
  • format de l’image : veut-on servir du WebP à Chrome, du JPG XR à windows et du JPG 2000 à iOS ?

Pour compliquer l’affaire, sachez que :

  • un écran retina peut avoir un petit viewport,
  • deviner la bande passante de l’utilisateur est hautement hasardeux,
  • vous ne connaissez pas la seule valeur qui compte : la taille physique de l’écran et la distance écran-œil.

Si vous êtes capable d’écrire un cahier des charges répondant à ces questions, alors vous pouvez vous pencher sur la réponse officielle et standard au problème : <picture>. Le temps que ça marche partout, la librairie JS officielle est picturefill 2.0.

La balise <picture>

La question est complexe, la réponse aussi.

La peinture étant un peu fraîche, il n’y a pour l’instant pas de retour sur la mise en production de cette technique. L’amélioration de performances devra donc se tester chez vous, en particulier sur les plateformes sans support.

Fait à la main, roulé sous les aisselles

Difficile pour une solution générique de faire mieux que du code écrit spécifiquement. À force j’utilise généralement chez mes clients un petit ensemble de techniques :

  • JPG grande résolution, qualité 0 : pour une image unique à faire passer sur tous type d’écran, éditée à la main. Ça passe pour 90% des JPG. (à essayer sur un écran haute densité),
  • images basse définition pour remplir l’espace, suivies du chargement de la haute définition. Le JPG progressif marchant mal sur iOS, c’est une manière d’avoir le même effet,
  • lazy-loading pour la majorité des images, images embarquées pour les critiques,
  • quand on peut, des formats vectoriels : SVG et polices d’icônes.

Combinez, testez et saupoudrez de JS pour obtenir de beaux effets. La maintenance n’est pas facile mais les résultats sont bons.

Interfaces fluides

Vous avez remarqué que les smartphones sont capables de jouer de manière fluide des jeux 3D mais ont des difficultés dès qu’il s’agit de retailler des divs ou de jouer avec du texte ? Au contraire de la 3D, il n’existe pas de puce dédiée à recalculer un DOM qui bouge ou l’écoulement des caractères. Il va donc falloir aider un peu nos pages.

Animations

Elles peuvent être fluides si on les travaille au corps. D’abord il y a un certain nombre de propriétés CSS qu’il vaut mieux ne pas animer comme topleftwidth et height. On leur préférera les variations de transforms comme translateX() ou scale() qui ont la bonne idée d’être pris en charge directement au niveau du processeur graphique.

Vous pouvez essayer dans l’ordre :

  • les transitions CSS, qui suffisent à la plupart des sites,
  • les animations CSS, quipermettent des effets plus avancés
  • enfin si JS doit tout piloter (un jeu par exemple), utilisez requestAnimationFramearrêtez jQuery animate et préférez des librairies spécialisées comme D3.js, GSAP ou TweenJS qui génèrent du CSS3.

CSS 3 avec modération

Remplacer les images de décoration par CSS c’était une bonne idée jusqu’à ce que vous réalisiez que le scroll lag sérieusement depuis que vous avez rajouté une ombre portée sur toute la hauteur de votre liste. De fait, tous les effets d’ombre, de transparence et de coins arrondis sont calculés en continu et cela peut coûter cher.

Une seule règle : tester, et sur de vrais mobiles bien sûr.

Calculs

On ne calcule pas tous les jours une suite de Fibonacci mais si ça vous arrive, utilisez les Web Workers. Sur les mobiles modernes ça vous donne accès à un second processeur pour exécuter du JavaScript. Sur les autres, la bonne veille technique du setTimeout(0) reste valable pour exécuter des boucles lourdes sans bloquer l’interface. Devinez qui vous a écrit un script pour ça ?

Testez !

Les derniers navigateurs mobiles acceptent enfin le déboguage à distance ! Cela signifie que vous allez pouvoir utiliser le profiler que vous connaissez sur de vrais téléphones et débusquer les endroits qui font ramer votre interface.

Vue réseau

Oh la belle verte : c’est mon CSS qui est gourmand

Pour les anciens OS comme Android 2.3, cela reste la devinette, rassurez vous.

Impliquer, mesurer, surveiller

On ne peut pas résoudre le problème qu’on ne voit pas. Avant de commencer tout projet de performance, il faut définir ce que doit être la performance, prendre un point de départ, choisir ses métriques, et surveiller automatiquement les performances dans le temps.

Sinon le projet performance s’arrêtera après la mise en prod des premières améliorations de performance.

Il fut un temps où il était possible d’avoir une équipe Web composée d’une seule personne : référencement, accessibilité, code, design, administration système, c’était fun. Mais aujourd’hui, à toutes vos compétences techniques il faut maintenant rajouter une grosse capacité à comprendre pourquoi l’on code et comment dialoguer avec le reste de la boite.

Donc par pitié, ne partez pas en croisade solitaire contre les lenteurs de votre site, au risque que personne dans la boîte ne s’en aperçoive. Il faut d’abord sensibiliser et évangéliser sur le coût du manque de performance pour la société et l’image du produit. Toute l’introduction de cet article est là pour cela.

Une fois que vous avez l’oreille des décideurs, faites écrire dans ce qui se rapproche le plus d’une spécification les objectifs de performance : en dessous de quels temps considère-t-on qu’il faut agir ? Vous pouvez par exemple prendre ces chiffres, relativement universels sans être trop ambitieux :

  1. Pour 80% des utilisateurs
  2. Premier rendu en moins de 2 secondes
  3. Fonctionnalité principale en moins de 5 secondes
  4. Navigation de page en page en moins de 2 secondes

Les utilisateurs et le premier rendu

Les deux premiers points demandent à déterminer l’équipement des utilisateurs :

  • Quels navigateurs ?
  • Quelle est la puissance des mobiles ?
  • Quelle est la qualité de leur connexion ? (l’origine géographique peut suffire à la deviner)

Les seuls moments où on vous a dit que le site était lent, c’est lorsque vos collaborateurs ont essayé de l’utiliser sans le Wifi du bureau. Comme des vrais gens donc. Il faut reproduire ces conditions de manière systématique et certaine pour constater les dégâts et juger des progrès avec le temps.

Le temps de premier rendu est relativement facile à vérifier avec des outils comme WebPagetest.org. Ce qui est plus compliqué c’est de paramétrer WebPagetest avec une simulation de connexion qui soit réaliste par rapport à vos utilisateurs. Comme ce n’est pas le cas de Webpagetest.org par défaut, je vous donne mes paramètres beaucoup plus représentatifs de la France.

Connexions WebPageTest

Des paramètres de connexion plus réalistes.

WebPagetest s’installe également en interne, et peut piloter des mobiles.

La fonctionnalité principale

Là ça se complique : comment déterminer le temps d’accès à la fonctionnalité principale ? Aucun outil ne peut faire cela automatiquement pour vous car seul vous connaissez bien votre interface (prends ça Skynet). Par contre vous pouvez collecter automatiquement des temps en JavaScript et vous les envoyer dans l’outil de tracking qui vous sied (G. Analytics peut suffire au début).

Si vous êtes un site de news ou à contenu visuel, trackez la fin de téléchargement de la première image visible utile par exemple (tiens, voici du code qui peut vous y aider). Si votre fonctionnalité principale dépend de JavaScript (vidéo, moteurs de recherche complexes, application…), il est encore plus facile de minuter le moment où le contenu devient interactif.

La navigation interne

Le dernier point consiste à ne pas décevoir l’utilisateur après la première page, que ce soit la vitesse de chargement des pages suivantes ou la fluidité de l’interface.

Là vous pouvez surveiller les taux de mise en cache client (utilisation avancée de WebPagetest Monitor) et simuler des navigations dans vos tests de performance.

Note de F en Cache Static Content

Attention chérie ça va ramer

Il n’y a pas de moyen facile et automatique de surveiller que l’interface elle-même est fluide sur mobile : contentez-vous d’une vérification systématique et digitale.

Stratégies de chargement

Il faut jouer avec la perception utilisateur et afficher quelque chose d’utile le plus rapidement possible. Cela demande à s’asseoir autour d’un café avec les autres équipes et à écrire la liste des priorités d’une page. Charge à vous de traduire cela en code pour régler l’ordre dans lequel les ressources vont être chargées par le navigateur.

Prenons 2 exemples de sites qui ont fait ce travail de priorité des requêtes.

Home Google

La fonctionnalité principale est évidemment l’affichage du champ texte. Mais les fonctionnalités secondaires sont légion : autocomplete sur ce champ, l’obligatoire intégration Google+, le menu, la suggestion de géolocalisation et même une bannière d’auto-promotion.

Home de Google

Ils ont de l’avenir

Google n’attend pas : il embarque un CSS minimaliste et suffisant dans le HTML, le HTML ne contient que le champ et des éléments pour définir la structure de la page. En 1 requête et 22Ko, soit l’équivalent de 2 allers-retours réseau, la fonctionnalité principale est déjà utilisable. Ensuite arrivent plus de 200Ko de ressources diverses pour afficher et rendre fonctionnel le reste de la page.

Home avec carrousel massif

Cette homepage était principalement vue depuis la Chine, il a donc fallu la calibrer pour des petits débits / grosses latences : elle était déjà optimisée pour le mobile. Par contre il fallait également afficher dans un carrousel plusieurs images de haute qualité de 1200 pixels de large.

Home de CMA

Le carrousel classique

Du point de vue du réseau, charger plusieurs ressources en parallèle est généralement vu comme une bonne idée. Sauf lorsque le débit est ténu et les ressource trop grosses comme c’est le cas ici. Le chargement de plusieurs images en simultané ralentissait le chargement des ressources du chemin critique.

Il a donc fallu prioriser : logo, texte, et image principale d’abord.

Les fonctionnalités secondaires sont les icônes, un moteur de recherche (non visible ici) les autres images du carrousel et des images bien plus bas.

Adieu donc la police, utilisation de data:uri pour embarquer le logo en base64, inclusion en <img src> traditionnel de la première image du carrousel (et seulement elle) et on développe un petit script pour aller chercher de manière asynchrone les photos suivantes avant de vraiment démarrer le carrousel.

Conclusion : Mobile first

Ça n’est pas du lâcher de buzzword gratuit mais bien une adaptation à la manière dont nos utilisateurs utilisent nos sites, qu’ils soient en situation de mobilité, dans un pays lointain ou qu’ils fassent partie des 20% de français avec moins de 2Mb/s.

Le mobile first est l’héritier de la pensée « amélioration progressive » : délivrons très rapidement la promesse initiale, chargeons les fonctionnalité supplémentaires après et en fonction des capacités du client. Cela oblige à se poser la vraie question : quelles sont les priorités de chaque page ?

Cela s’intègre parfaitement avec un processus de conception moderne où designer et intégrateur web passent pas mal de temps l’un à côté de l’autre pour fignoler les maquettes sur les mobiles.

Nous avons évoqué une palanquée de techniques : certaines sont connues depuis bientôt 10 ans, beaucoup émergent et certaines sont devenues dangereuses. Toutes répondent à une situation particulière donc c’est à vous de tester ce qui marche ou pas, page à page.

Le processus de travail est presque aussi important que les techniques individuelles : la communication et l’effort de groupe sont vitaux pour maintenir la qualité à travers le temps. Sans monitoring ou automatisation des déploiements cela va rester amateur et pénible. Sans soutien hiérarchique du client (interne, externe, hiérarchique, bref celui qui vous paye) vous n’irez pas bien loin seul. Ou pire vous serez frustré par ce métier pourtant formidable qui est le nôtre.

Quel est le débit moyen en France

À quelle vitesse s’affiche un site ? La question est importante tant le confort d’utilisation et les revenus d’un site peuvent dépendre de cette réponse. Vous intégrez probablement déjà des pratiques visant à améliorer le rendu des pages et leur réactivité, et si vous êtes en phase d’industrialisation, vous faites peut-être du monitoring de la performance. Au moment de paramétrer votre solution, une question a dû vous poser problème : quelle est la connexion type en France ? Et pour les mobiles ?

Nous allons non seulement répondre à ces deux questions, mais en plus nous apercevoir qu’il y a une question plus pertinente à se poser.

Pourquoi et comment calibrer ses test ?

Les solutions de monitoring du marché testent les pages généralement sans vous dire avec quel navigateur (probablement des Webkit headless, pour accélérer les tests), et le font depuis des datacenters qui sont beaucoup trop proches des nœuds principaux du Web. Potentiellement, les sondes sont exécutées à partir de machines hébergées physiquement dans le même datacenter que votre hébergeur ou avec un peering privilégié avec le CDN.

Autant dire que les tests standard ne sont pas représentatifs de ce qu’endurent vos utilisateurs et c’est la raison pour laquelle on limite volontairement débit et latence, par exemple sur l’indispensable WebPageTest ou chez certaines solutions payantes. WebPageTest a le mérite d’être transparent car vous avez une liste de connexions pré-paramétrées cependant nous allons voir qu’elles ne représentent pas du tout la France.

Paramètres par défaut de WebPageTest.org

Côté transit réseau, il y a essentiellement 4 données qui influencent l’affichage d’un site :

  • la latence ou ping, qui est le temps d’un aller / retour entre un navigateur et le serveur qui lui répond. Pour le site moyen, en HTTP 1.1, basé sur TCP, c’est la mesure la plus importante. C’est aussi la plus difficile à obtenir.
  • le download ou bande passante descendante, qui reste importante pour récupérer de gros objets. On nous vend des ADSL à plus de 20Mb/s (1, 2, 3 et des mobiles à 5Mb/s, qu’en est il vraiment ?
  • l’upload qui est rarement pertinent dans la webperf.
  • la perte de paquets : pratiquement inexistante sur des connexion filaires, mais omniprésent sur mobile. Là par contre impossible de trouver des chiffres, en supposant qu’ils signifient quelque chose

Idéalement, il faudrait récupérer ces métriques de vos propres utilisateurs, grâce à du Real User Monitoring (RUM), mais la mise en œuvre est moins aisée que de récupérer les informations de sources externes, telle que nous allons le faire ici.

Si vous êtes pressé ou si vous me faîtes aveuglément confiance (et je vous comprends), vous pouvez sauter directement à « En résumé »

à la pêche aux chiffres

En cherchant dans mes archives et sur Google, je me suis rendu compte qu’il existait très peu de rapports rendus publics. J’en liste ici 6 en extrayant des données brutes. N’hésitez pas à m’en indiquer d’autres ou à décortiquer plus avant les sources.

Etude Akamai / Pingdom de 2010

Akamai est le leader mondial des CDNs, autant dire qu’ils voient passer du traffic et ont une bonne idée de ce qui se fait à l’échelle mondiale. L’étude de cette année là comprend la répartition des débits en France.

  • Débit moyen : 3,3 Mb/s
  • Répartition :
    • 25 % moins de 2 Mb/s
    • 60 % entre 2 et 5 Mb/s
    • 15 % plus de 5 Mb/s

Akamai 2012

Chiffres plus récents, mais dont l’échelle de répartition a changé.

  • Débit moyen : 4,6Mb/s
  • Débit moyen des réseaux mobiles : 2,8Mb/s
  • Répartition :
    • 0,1% moins de 256Kb/s
    • 45% plus de 4Mb/s
    • 4% plus de 10Mb/s

DegroupTest, 2012 et 2011

La population des utilisateurs de Degrouptest est probablement biaisée, car on a affaire à des gens qui au minimum s’inquiètent de leur débit. Ce qui exclut ma mère et probablement la votre. Mais ils ont l’avantage de mesurer le ping, et d’isoler les extrêmes comme la fibre, le mobile et l’outre-Mer.

  • Débit moyen : 8,27 Mb/s (5,4Mb/s hors fibre )
  • Débit moyen des réseaux mobiles : 2.5Mbps (chiffres 2011)
  • Ping moyen : 80ms (86ms hors fibre)
  • Ping moyen réseaux mobiles : 200ms
  • Débit montant moyen : 1,3 Mb/s ( 641Kbp/s hors fibre)
  • Répartition :
    • 13% à 27Mb/s de débit moyen
    • 87% à 5,4Mb/s
  • à noter :
    • Meilleur latence possible : Fibre Orange avec 19ms. Les opérateurs ADSL se situent entre 70ms (Free) et 100ms (SFR)
    • 1s-1.5s de latence sur satellite
    • 270ms de latence depuis l’outre-mer, 3Mbps de débit moyen

A noter que le débit et la latence moyenne ont baissé entre 2011 et 2012. J’imagine que leur public a du s’élargir à des zones moins bien couvertes.

60 millions de consommateurs, 2012

Leur testeur de débit a tourné pendant 1 an en 2011 et leur public est probablement plus proche du français moyen que DegroupTest. En plus on y quantifie les variations périodiques de débit.

  • Débit moyen : 5.6Mb/s
  • Répartition :
    • 11.8% moins de 1Mb/s
    • 12.8% de 1 à 2Mb/s
    • 31,8% de 2 à 5Mb/s
    • 30% de 5 à 10Mb/s
    • 12% plus de 10Mb/s
  • A noter :
    • -20% de débit à 21h
    • -10% le dimanche

Etude ARCEP

De cette étude sur les chiffres d’affaire des FAI et opérateurs mobile, j’ai extrait les volumes de population pour confirmer ou requalifier les chiffres des autres :

  • 22 millions d’abonnements ADSL et fibre
  • 0,6 million d’abonnement fibre / cable
  • 0,3 million abonnés RTC
  • 32 millions d’abonnés mobile « data »
  • +80% de volume de data mobile par an

Statistiques Cedexis

Les statistiques de “l’aiguilleur du net” mesurent le temps d’aller-retour moyen entre un utilisateur de FAI et un CDN afin de choisir le meilleur. Les valeurs de latence y sont plus hautes qu’ailleurs car les CDN ne font pas que servir des fichiers statiques, il y a beaucoup d’intelligence lorsqu’une requête arrive chez eux. Je les prends car elles donnent une bonne idée de la vitesse avec laquelle les fichiers arrivent chez l’internaute qui visite des sites utilisant les CDN.

  • 118 ms de latence pour des fichiers hébergés sur Akamai (leader)
  • 134 ms de latence pour des fichiers sur Amazon EC2 Europe

Après les chiffres bruts, passons à l’analyse.

Quelle analyse ?

Il faut bien se dire que l’on compare des études avec des buts différents : mesurer l’efficacité des CDNs, des FAI ou avoir un vision plus globale oriente les méthodologies. C’est pour cela que j’explicite ma réfléxion, pour que vous utilisiez les commentaires pour critiquer ma tentative de compréhension.

Le débit moyen

Les statistiques d’abonnement de l’ARCEP montrent 2,7% d’abonnés fibres par rapport au nombre total d’abonnement, alors que Degrouptest reçoit 13% de ses mesures depuis la fibre. Nous pouvons donc requalifier le débit moyen de Degrouptest : 5,01Mb/s (97,3 % * 5,4 Mb/s + 2,7 % * 27,3 Mb/s = 5,01 Mb/s).
Cette nouvelle moyenne se situe entre celle d’Akamai pour la France (4,6 Mb/s), et celle de 60 millions de consommateurs (5,6 Mb/s). Akamai ne détaille pas sa méthode mais on suppose qu’elle est plus représentative, car non volontaire. Elle ne mesure cependant que la connexion entre Akamai et un internaute et Cedexis nous indique qu’Akamai n’est pas le plus performant. Il faudrait donc légèrement remonter ce chiffre. D’un autre côté, 60 millions de consommateurs a fait son étude en 2011, et entre-temps DegroupTest semble indiquer une baisse de débit ADSL de 600 Ko/s. Il faudrait donc revoir leur moyenne à la baisse. Les chiffres convergent vers la valeur DegroupTest, que j’estime légèrement surestimée (population trop “aware”).

Pour arrondir, on peut donc situer un débit moyen à 4,8Mb/s sur ligne fixe. Concernant le débit mobile moyen, Akamai et Degrouptest ont à 30Kb/s près la même moyenne, on peut l’arrondir à fixer à 2,5Mb/s.

La latence

On applique la correction des stats ARCEP sur les stats DegroupTest et on obtient cette valeur arrondie : 85ms. Cependant en regardant les données Cedexis, on voit des temps de réponse bien supérieurs, de 110ms par exemple pour récupérer un statique sur un CDN populaire comme Akamai. Cela est assez cohérent avec le fait qu’un CDN rajoute forcément un peu de latence (temps de routage supplémentaire, mise en cache, etc.) et que la population Degrouptest est surement un peu moins représentative que celle mesurée par Cedexis.

Concernant le ping sur mobile, on manque cruellement de données, la seule qu’on ait trouvé pour la France est celle de Degrouptest de 200ms. Dans des études bien moins larges dans d’autres pays, les chiffres varient de 200ms à 300ms.

Pour la latence, nous nous fixons donc une moyenne arrondie de 95ms sur ligne fixe et 200ms sur mobile.

Le cas du mobile

Donc le débit moyen sur réseau mobile (2,5Mb/s) est plus élevé que 25% des ADSL de France. La latence est tout de même deux à trois fois plus élevée. Mais même en calibrant vos tests avec ces données et en supposant que vous les exécutiez depuis un vrai mobile, vous réalisez vite que quelque chose cloche : le ressenti utilisateur n’est pas du tout le même. En fait il manque une dernière composante, assez rare en ADSL : la perte de paquets TCP. Constamment les connexions ouvertes entre votre téléphone et l’antenne relai sont interrompues par des obstacles physiques, électro-magnétiques ou un changement d’antenne. Je n’ai pas trouvé d’étude avec un taux moyen de perte de paquet, aussi c’est un peu au pifomètre que j’utilise la valeur 25%. à débattre.
Il manque également le côté aléatoire de la connexion qui fait tout le charme des réseaux mobiles : parfois vous téléchargez une image en une demie seconde, parfois vous n’arrivez pas à avoir un octet pendant plusieurs minutes.
Exécutez régulièrement les applications speedtest ou Degroupest (iOS, Android) pour halluciner sur la variabilité des caractéristiques réseau.

Test débit mobile

Sur quelques tests ci-dessus, sur 2 tests effectués à moins d’une minute d’intervalle et sans bouger, vous pouvez voir une différence de latence de 1 à 4. Vous pouvez également voir des tests qui vont de 14Kb/s à 9Mb/s, sans compter ceux qui n’aboutissent pas.

Mais non seulement il n’existe pas d’étude sur les trous réseau (en supposant qu’une telle étude puisse être représentative), mais en plus nous ne voulons pas introduire d’aléa dans le cadre du monitoring, ou alors comment savoir si une alerte en est vraiment une ? Nous devons malheureusement choisir des mesures dégradées mais fixes.

En résumé

Les connexions moyennes françaises en 2012
Lignes Fixes Réseau mobile
Débit descendant 4,8Mb/s 2,5Mb/s
Latence 95ms 200ms
(+25% de perte de paquets)

Il n’y a pas de connexion type

Mon prof de stats me tirerait les oreilles si on s’arrêtait là. En effet une moyenne seule est à peu près inutile sans l’écart-type qui permet de juger de la représentativité de cette moyenne. En fait une moyenne est certes pratique à manipuler, et il est utile de surveiller son évolution, mais elle est particulièrement trompeuse si la répartition des mesures n’est pas concentrée autour de la moyenne.
Et justement les études d’Akamai, de l’ARCEP et de 60 millions de consommateurs montrent qu’il y a de fortes disparités dans l’équipement des utilisateurs.

  • L’ARCEP nous dit qu’il reste 1,4% de gens en RTC (56Kb/s), soit à l’échelle de la France 300 000 personnes. Dur de savoir si c’est leur unique moyen d’accéder au Web, mais c’est un débit 500 fois inférieur aux mobiles ! Akamai signale également un faible taux de débit inférieurs à 256Kb/s
  • DegroupTest nous avertit sur le fait que depuis la France d’outre-mer, on a du 250ms de ping en moyenne, l’équivalent du mobile, et un débit 40% inférieur à la métropole
  • 60 millions de consommateurs et Akamai montrent que 50% des utilisateurs ont moins de 5Mb/s, avec une répartition qui a l’air à peu près égale par tranche de 1Mb/s : 10% ont moins de 1Mb/s, 20% moins de 2Mb/s, etc.
  • les tuyaux du Web français sont embouteillés le soir, avec une perte de 20% de débit entre 21h et 22h.

Il n’y a pas d’ADSL type en France

Nous nous sommes donc posés la mauvaise question : calibrer vos tests sur LA moyenne française est à peine moins trompeur que de mesurer depuis votre poste avec votre navigateur récent, sur votre réseau d’entreprise branché à la fibre (oui tout le monde le fait, et c’est MAL).

Enfin : quelle stratégie de test ?

Tous ces chiffres vont nous permettre de définir une vraie stratégie de test de la performance perçue. Cela commence par définir des objectifs de réactivité raisonnables en terme de confort d’utilisation, par exemple :

  • afficher quelque chose avant 1 seconde (start render)
  • promesse / fonction principale de la page affichée avant 2 secondes
  • fonction principale interactive avant 5 secondes

Note : les valeurs que j’indique ici sont un peu génériques, et sont à définir entre les équipes “produit” (marketing, ergonomie) et les équipes techniques (développeurs, sysadmins).
Vous devez maintenant être cruel et déterminer quelle proportion d’utilisateurs n’aura pas droit à cette rapidité. C’est un peu rude dit comme ça, mais une page rapide pour “tout le monde” coûte très cher. Généralement on vise à satisfaire par exemple 80 % de la population.

Voici un petit tableau qui devrait vous aider à prendre vos décisions :

Calibrage des tests pour ligne fixe
Un débit de X Mb/s et une latence de Y ms laissent de côté Z % des visiteurs
5.0Mb/s 95ms 50%
4.0Mb/s 100ms 40%
3.0Mb/s 110ms 30%
2.0Mb/s 120ms 20%

Remarques :

  • Les débits et pourcentages semblent joliment arrondis. C’est de la chance.
  • Pour le ping, on n’a aucune stat sur la répartition réelle, ce sont donc des suppositions personnelles que je vous invite à critiquer

Pour le réseau mobile, on est bien embêté car on n’a aucune idée de la répartition ! On sait juste qu’elle est très volatile, ne serait-ce que pour le même utilisateur. Donc, soit on joue ça au doigt mouillé avec la certitude de se tromper, soit on utilise la moyenne qui est pratiquement un mensonge. Mmmm. Choix cornélien mais, à choisir, autant partir sur une valeur un tout petit peu objective, c’est-à-dire la moyenne constatée, et y rajouter de la perte de paquets.

Je mettrais donc ces 3 valeurs par ordre de priorité :

  1. 3,0Mb/s avec une latence de 110ms pour représenter 70% de vos utilisateurs
  2. 2,5Mb/s avec une latence de 200ms et une perte de paquets de 25% pour l’ensemble des utilisateurs de réseau mobile
  3. 4,80Mb/s avec une latence de 95ms pour « la moyenne » des connexion filaires

La moyenne reste là surtout parce que c’est un chiffre que tout le monde (croit) comprendre et pour comparer mobile et bureau.

Si vous avez une population particulière (outre-mer, visiteurs à 21 h, habitant une grande ville, professionnelle, très mobile, etc.), il va vous falloir fouiller dans les chiffres ci-dessus pour trouver ce qui se rapproche le plus de vos utilisateurs. Ou, bien sûr, monter votre propre monitoring des capacités de vos utilisateurs.

Résultats

Pour conclure, comparons les valeurs DSL par défaut de WebPageTest.org avec celles que nous avons déterminées pour représenter 70 % des français. J’ai lancé un test sur un site moyennement complexe, qui n’a pas (encore) été optimisé et qui fait partie des sites à forte audience de France : Pluzz.fr.

Comparaison valeurs par défaut et personnalisées

Pour plus de détails, voir le détail du déroulé. Avec les valeurs par défaut, ce site s’affiche en moins d’une seconde, donnant l’impression que l’optimisation n’est pas nécessaire. Avec nos valeurs plus réalistes prenant en compte 70 % de la population, le start render se situe à 1,4 seconde, confirmant le besoin d’entamer des travaux si l’on veut atteindre les objectifs de performance perçue.

Performance web mobile, chargement de page 2/2

Reprioriser les optimisations

On l’a vu dans le premier article, certaines techniques pourtant reconnues peuvent devenir contre-productives si l’on ne fait pas les tests nécessaires. Ne jetons cependant pas tout aux orties, voici les techniques que vous devrez maîtriser plus que jamais et pousser dans leurs extrêmes si vous voulez obtenir un résultat correct sur mobile ; par ordre de priorité :

1. Travailler le chemin critique

La notion de performance est plus un ressenti qu’une collection de chiffres. Lorsque vous devez retravailler une page pour un réseau mobile, demandez-vous ce que l’utilisateur est vraiment venu voir et dégagez le passage pour afficher au plus vite la zone ou la rendre fonctionnelle :

  • pas (trop) de redirections, et surtout pas côté client ;
  • concaténation ou mise en ligne des CSS ;
  • un code HTML / CSS prêt à « marcher » sans JavaScript : pour un article, c’est facile, on affiche le texte (sans police de caractère, jamais) ; pour une vidéo, on peut utiliser HTML5 comme interface de lecture en attendant JavaScript. Si vous dépendez de JavaScript pour afficher la fonctionalité (un webmail par exemple), affichez au moins un indicateur de chargement ;
  • scripts asynchrones comme vu dans le premier article ;
  • JavaScript chargé et exécuté par ordre de priorité : on peut très bien imaginer de charger d’abord les fichiers JavaScript concaténés qui concernent la zone principale, puis un second pack de fichiers qui concernerait tout le reste de la page.

2. Minimiser le nombre de requêtes HTTP

On l’a vu lors de l’exemple du domain-sharding, la première limite vient du réseau : le même mobile sur la même session de surf pourra passer d’un WiFi de bonne qualité à une absence complète de réseau. Vous ne pouvez jamais prévoir quand la latence va s’allonger jusqu’au timeout ou quand le débit passera en dessous de ce dont vous auriez besoin pour afficher une simple image. En supposant que vous serviez votre site classique sur mobile (1 Mo, 100 requêtes, 15 domaines… source http archive), il va falloir faire baisser de manière drastique le nombre de requêtes pour minimiser les effets de latence ou de timeout et maximiser l’utilisation de la bande passante. Cet objectif est là pour durer et la plupart des techniques classiques utilisées jusqu’ici sont non seulement à investiguer, mais à pousser dans leurs extrêmes.

La concaténation

Il est plus que jamais temps de faire de vos CSS et JS des fichiers uniques ou presque. De base dans Ruby on Rails, avec des plugins divers pour Spip ou Drupal, avec Assetic pour Zend 2, des dizaines de librairies pour d’autres projets PHP, avec SASS côté CSS et des outils comme YUI Compressor.
Il n’y a plus vraiment d’excuses pour ne pas gérer correctement vos JS et CSS, sauf peut être le coût de refactoring initial, mais il reste généralement négligeable par rapport aux bénéfices attendus.

À noter que les stratégies de concaténation vont varier en fonction de la taille de votre site : si il est relativement petit, mettez tous vos CSS dans une seule feuille ; si il est plus grand, mettez le CSS commun dans une première feuille et les CSS de chaque type de page dans une autre. Ne dépassez jamais 2 feuilles par page. En JavaScript, les stratégies sont plus variées du moment que vous utilisez l’asynchrone : un fichier unique pour tout le site si il est petit, un fichier par zone fonctionnelle sinon (avec chargement asynchrone).

Les images

Les images sont généralement petites et nombreuses, c’est donc votre seconde cible après le CSS. Vous avez forcément déjà entendu parler du spriting ; sur mobile, vous pouvez aller encore plus loin avec les caractères unicode : lorsque vous avez beaucoup d’icônes, essayez de voir si vous pouvez en réutiliser (♻) qui viendraient directement des polices du système !
Attention à la compatibilité navigateur ET système d’exploitation. Pour les mobiles, c’est généralement bon ; pour IE sur XP, vous n’aurez qu’un choix limité.

Encodage des images : visez le zéro requête en encodant vos images en texte directement dans le CSS, voire dans le HTML. C’est un peu fastidieux à faire à la main mais un simple script PHP suffit :

print '<img src="data:image/png;base64,'.base64_encode(file_get_contents('/path/to/image.png')).'" />';

Qui vous donnera en sortie quelque chose de ce genre :


<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAMAAAAoLQ9TAAABO1BMVEX92RlCQj+7vLzvzSzmhgnXgybyz3uLj5T13mj99cDwrmWMfzXmyTz78bT1zUf++uX437bxzqzmpj/dlDdcVUbuxnjszDLq6uvqmS/43Hv99t+foaOMgl5tYDjsu1vfwT388NijlXr52Vn22Y3999Z2bmD34svhrFlQTD378ajuwWXThzH668PpsFbvw5zrtU2Vh03x0Y3MzMz73kr664qZmZnmnUblqm/7w1HokRbefBb//e324HL2z0TsuENYRC399s/343z46paYijr88s/z1KXvyIvspkzroTj81yL56cnajjLwxm9KSkLmqj1gVj+Xg2H3vkv+/tz35XL+3CD89cj45Lf88MSipab13FnvtGP224T45Yb78rr++uv3zij25Grz1Ub1yi7wxFztu2vYiTH95kfqs2v45csXvxkaAAAAAXRSTlMAQObYZgAAAMlJREFUaN5jYAACY0llQzafZFsGCAiJDvNSkJJSEEjR9wQLROvw86s4OISqxLkJgfhKYfz8/NZA4MBrnW4HFGBzkZKKAwlIxWpmCAMFRKVCQ1VUXFzCY52CpVKBAlpeKo4xUVFR7jGRJmreQAE+N2sbCRsbDhuWxCBzP5Cpcq5BHjYJCTaWnIKsYHs9dV25bIDAXY81CeIyT3WzwLQ0CyvteKhTGcQCFJ25Ve2ZGeBAJiLClN0fwWcwYBI3kpZFEuAR8WXUkGfACgC55CKssDjPhQAAAABJRU5ErkJggg==" />

Des frameworks complets comme SASS permettent de le faire dans le CSS. Vous pouvez utiliser cette technique à partir de IE8, et envisager l’équivalent MHTML pour IE7.

Le nombre de domaines

Le site moyen a entre 10 et 15 domaines à faire résoudre et il n’y a pas eu d’études sur l’utilisation du cache DNS sur mobile. Pratiquement invisible sur ordinateur de bureau, le coût de recherche DNS est peut être dix fois plus important sur mobile à cause de la latence. Chaque recherche de domaine va bloquer une file de téléchargement en attendant la réponse. Donc, soit vous sacrifiez trackers, publicité, widgets et autres sources externes, soit vous les dépriorisez fortement, tout simplement en les appelant après vos propres fichiers.

Connexions permanentes

Si vous avez une version dédiée mobile de votre site (pas de problématique de référencement, code spécifique), autant y aller à fond et utiliser une technologie très prometteuse pour contrer les effets de la latence : WebSocket. Pointez deux navigateurs cette page de démo, et observez le peu de délai dans la transmission d’une info d’un navigateur à l’autre, réseau mobile ou pas. Websocket ou d’autres techniques de connexions permanentes peuvent être détournées : vous chargez en une seule requête une page initiale ne contenant que le strict nécessaire de CSS, de contenu et de JS, puis vous chargez tout le reste (images, CSS, JS, contenu) via cette connexion, que vous pouvez même réutiliser pour renvoyer des informations (AJAX, tracking…), sans payer le prix d’ouverture de nouvelles connexions HTTP.
Je n’ai pas encore vu d’équipe web déclarer avoir implémenter cela, mais ça ne saurait tarder. Au pire, patientez un peu, je vais coder une démo sur de vrais sites.

3. Le cache et l’offline

Comme avant, il va falloir que vous commenciez par maîtriser absolument toutes les URLs vers les statiques de votre site pour pouvoir les servir avec des caches agressifs, sur des domaines sans cookies. Ça c’est surtout pour les navigateurs de bureau car le cache des navigateurs mobile est une vraie calamité en terme d’efficacité ! Il y a beaucoup trop de limites (nombre d’objets, taille maximale par objet, taille maximale par site et taille maximale pour tout le navigateur) pour espérer de vrais gains avec les comportements par défaut. Attention il ne faut pas les ignorer pour autant, si votre visiteur va d’une page à l’autre, il sentira la différence.

Les sites très efficaces en sont donc à utiliser HTML5 localStorage pour stocker des JS, des CSS et même des images (encodées en base64). C’est la technique choisie par LinkedIn mobile, Bing ou GMail, et elle demande un certain niveau de maîtrise de son application. Par exemple, imaginez-vous sur une page d’accueil : vous allez télécharger via XHR tous les objets dont vous avez ou aurez besoin, puis les stocker dans localStorage.

var loader = new XMLHttpRequest();
loader.open("GET", "http://example.com/js/main.js");
loader.onload = function(e) {
    localStorage.setItem('main.js', e.response);
}
loader.send();

Ensuite, au moment ou vous en avez besoin, vous vérifiez la présence des fichiers voulus dans votre cache maison.

if( localStorage.getItem('main.js') !== null ) {
    eval( localStorage.getItem('main.js') );
}

Oui, vous faites à la main le boulot du navigateur (télécharger, gérer le cache, insérer…) mais c’est avec ce genre de code un peu extrême que l’expérience utilisateur sur mobile fera la différence. En prime, les navigateurs de bureau en profiteront aussi.

Une note pour ceux qui ont entendu dire que LocalStorage était contre-performant car synchrone (lorsque vous écrivez, vous bloquez le programme le temps que le disque ait fini de travailler) :

  • c’est évitable facilement en passant par un wrapper qui va simplement effectuer l’écriture en asynchrone ;
  • les mobiles écrivant tout en RAM / Flash disk, les temps d’accès sont de toute façon négligeables.

Vous pouvez encore passer au niveau supérieur en utilisant une technique qui a autant fait ses preuves que montré ses limites : l’utilisation de la spécification Application Cache. Native, bien supportée par tous les navigateurs modernes mobiles ou de bureau, elle permet de déclarer en un fichier (le manifeste) quels sont les fichiers à télécharger, quelles ressources doivent continuer à être servies en ligne, et quoi afficher lorsque la connexion n’est plus là. Au contraire de la gestion du cache présentée précédemment qui est personnalisée et donc très adaptée à votre application, Application Cache vous force à coder d’une certaine manière (maîtriser absolument toutes ses URLs), présente certains manques (invalider le cache de certains fichiers seulement) et il faut un petit temps d’adaptation pendant la phase de développement pour comprendre son fonctionnement intrinsèque. En revanche, en terme de performance et de mode de distribution, c’est parfait !

4. Réduire la taille

Minification et compression des JS / CSS

La minification est généralement exécutée au déploiement du site juste après la concaténation et vous pouvez généralement gagner 50 % du poids des fichiers avec des outils solides comme YUI Compressor. Activez la compression gzip par-dessus et vous aurez gagné au final 90 % du poids initial de vos fichiers. Sachant qu’il n’est plus rare de trouver des sites avec 200-500 Ko de CSS et de JS, le gain est assez important.

Les photos

Pour les images de l’interface, comme pour les photos, vous avez beaucoup à gagner en compressant au maximum les images servies. Encore plus efficace : ne les afficher que si elles sont nécessaires. Dans le cas d’une application Web Mobile ou l’interface permet de beaucoup scroller, considérez comme une amélioration majeure de faire du lazy-loading sur les images, c’est à dire de ne télécharger l’image que lorsqu’elle est sur le point d’être affichée.
En terme de compresseur d’image sans perte de qualité, voyez avec PNGout (ligne de commande) et PNG Gauntlet (son interface visuelle) pour compresser efficacement les PNG, ou JPGoptim (ligne de commande) et Image Optim (meta interface pour Mac) pour les JPG.

Les cookies

Là aussi, investissez du temps pour maîtriser toutes les URLs de toutes les ressources statiques de votre site , afin de les mettre sur des domaines séparés du domaine principal. Imaginez un cookie d’un peu moins d’un Ko qui serait envoyé à la centaine d’objets généralement appelée par une page Web classique : vous demandez à votre utilisateur d’uploader 100 Ko de données inutiles. Une autre piste pour remplacer les cookies qui sont parfois servis sur des pages statiques qui n’utilisent même pas de données personnalisées est de ne pas les utiliser du tout… pour les remplacer par HTML5 localStorage si vous avez tout de même besoin de persistance côté client (préférence d’affichage, historique…). Pour la compatibilité navigateur, passez par des petites librairies spécialisées.

En résumé

Vous voilà donc paré pour arrêter de perdre vos clients dès qu’ils essayent d’accéder à votre site à partir d’un réseau mobile. Nous avons vu que :

  • la performance est empirique : testez même les grands classiques avant de choisir vos solutions ;
  • la plupart des techniques déjà connues marchent mais sont à traiter dans un autre ordre ;
  • ces techniques sont à pousser dans leurs extrêmes ;
  • de nouvelles possibilités sont apparues.

Et ne comptez pas sur l’évolution future de l’équipement réseau : sauf inversion de la tendance actuelle, non seulement vos sites vont continuer à grossir mais en plus les futurs utilisateurs des réseaux 4G voire Wimax auront toujours des doigts, des murs, des gens et de l’atmosphère à traverser avant d’arriver sur vos serveurs.

L’optimisation, c’est maintenant.

Performance web mobile, chargement de page 1/2

Cet article a été initialement publié sur le train de 13h37, magazine du développement web de grande qualité, qui a le double mérite de rémunérer ses auteurs et de proposer les articles avec une licence CC BY-NC-SA.

Introduction

Vos utilisateurs viennent chez vous sur mobile : 5 % selon StatsCounter ; 10 % selon ATInternet ; 9 % d’après ce que je vois chez mes clients dont le site n’a PAS été pensé pour du mobile. Évidemment cette part est en augmentation constante, a déjà largement dépassé IE7, va dépasser IE8, et il est raisonnable de penser que, ces statistiques étant récoltées via JavaScript, certaines tentatives d’accès ne soient même pas comptabilisées ! Que vous le vouliez ou non, que votre site ait été fait ou pas pour cet usage, vos utilisateurs essaient de venir sur votre site dans des conditions de réseau qui ne vous arrangent pas forcément, mais qui vont vous poser quelques défis intéressants.

De quels mobiles parle-t-on ?

Plus on rentre dans les détails des navigateurs, des systèmes d’exploitation et des capacités matérielles, et plus il semble illusoire de définir ce qu’est vraiment un mobile. Restons pragmatiques et, dans le cadre de cet article sur la performance, précisons ce que nous allons considérer comme notre cible :

  • capacité du navigateur à afficher des sites non spécifiquement prévus pour mobiles ;
  • navigation « tactile » ;
  • matériel sous-dimensionné par rapport à la machine de bureau moyenne ;
  • qualité de réseau fluctuante.

Ce dernier critère peut prêter à discussion, tant on observe d’utilisateurs mobiles accéder aux sites depuis le confort du WiFi de la maison : par exemple, la moitié des visiteurs dits « mobile » sont en fait sur iPad, ce qui implique (le plus souvent) le WiFi.

Mais dans le cadre de cet article nous allons surtout nous intéresser aux « problèmes supplémentaires à résoudre pour le chargement des pages » : les temps de chargement depuis une tablette / mobile sur WiFi sont largement comparables aux temps de chargement sur certains navigateurs de bureau.

Comment tester ?

Tout développement commence par la mise dans de bonnes conditions pour tester ; la mesure a lieu ensuite dans un chantier performance web. Le banc de test idéal pour le mobile est simplement impossible à monter et force est de constater que les éditeurs de sites, de l’indépendant aux sites avec des millions de pages vues, se contentent généralement de l’iPhone de l’intégrateur et éventuellement de l’Android-qui-s’appelle-revient du collègue.

Si l’on regarde les parts de marché en France, cela correspond effectivement à une réalité : nous avons Safari pour iOS partagé entre les différents iPhone et iPad, et le navigateur par défaut d’Android distribué avec les version 2.x. En queue de peloton et souvent ignorés, à tort pour les valeurs d’interopérabilité du Web, viennent les Opera (mini ou mobile) pourtant ultradominants dans d’autres pays, Firefox mobile, ainsi que différentes variantes de Webkit sur les OS mobiles survivants (Blackberry, SymbianOS, LG…), ainsi que IE Windows.

Ah, et ne comptez pas sur les émulateurs : ils sont déjà à peine acceptables pour tester les fonctionnalités, alors question performance ils sont tout simplement disqualifiés d’office ! Entre l’utilisation du processeur de la machine hôte, une connexion filaire sans défaut et les approximations inhérentes à tout émulateur, vous n’aurez jamais quoi que ce soit de réaliste dans votre quête de la fluidité.

La solution minimale du pauvre, c’est de conserver ses mobiles et d’attendre qu’ils vieillissent ou d’acheter des occasions datant d’un an ou deux, sans mettre à jour le système d’exploitation. Pour simuler un réseau 3G, on pourra utiliser des proxys via WiFi qui dégradent volontairement la connexion. Il y a une grosse dizaine de solutions, généralement limitées à un seul OS (souvent Mac). La plus compatible et reconnue est le proxy payant Charles mais la gratuité de Trickle (Linux), Network Link Conditioner (OSX 10.6) ou Slowy App (OSX 10.5) peut vous séduire.

Le principe est simple : ces logiciels contiennent de quoi dégrader artificiellement une connexion (débit, latence, perte de paquets). Vous configurez votre téléphone pour utiliser votre machine comme proxy via WiFi, et voilà ! En prime, vous pouvez analyser les trames réseau qui passent. C’est moins cher que de vraies cartes SIM et la constance de la dégradation permet de faire des tests répétés, là où la qualité d’un vrai réseau data peut varier d’une minute à l’autre.

Pour être honnête, les techniques décrites dans cet article ont surtout été testées sur le navigateur Android 2.3 et Safari iOS 6, avec des vérifications fonctionnelles sur Firefox et Opera mobile sur Android, les deux absents notoires étant le Safari de Blackberry et Internet Explorer.

Signalons également que nous ignorons délibérément un bon milliard d’habitants sur cette planète qui se connectent au Net avec des mobiles pré-smartphones : techniquement difficiles à adresser sérieusement, ils sont également une minorité en France à posséder ces anciens mobiles et avoir souscrit un abonnement 3G.

Chargez !

L’importance du réseau

Croyez-le ou non, les débits théoriques en 3G et technologies au-delà peuvent être plus rapides que les débits constatés des ADSL. Mais comme finalement assez peu de gens font du Web depuis les laboratoires de tests des constructeurs, il va falloir composer avec la réalité physique : une couverture nuageuse un peu forte, un déplacement un peu rapide, un doigt mal placé, un mur un peu épais, ou des gens autour de vous également équipés de mobiles (incroyable en 2012), et vous vous retrouvez rapidement avec des débits ridicules, des pertes de paquets énormes et le sentiment global qu’on vous a un peu survendu la « meilleure couverture réseau de France ».

Lorsque le réseau marche, l’utilisateur français moyen a en moyenne 2,50 Mb/s (sources) ce qui est plus rapide que 25% des ADSL de France. Par contre, la latence ou ping est en moyenne à 200 ms soit le double de la moyenne en ADSL.

Depuis toujours, la latence est l’ennemi numéro 1 de nos pages Web. Ceci est du à la nature même de HTTP et signifie que pour un débit moyen seulement deux fois inférieur, le temps de chargement sera en fait 3 à 6 fois plus long sur mobile ! Pire, la perte de paquets est assez conséquente et inhérente à la technologie radio utilisée pour communiquer entre le mobile et l’antenne de l’opérateur. Et cette perte de paquets arrive plus fréquemment pour les petites requêtes… Exactement la manière dont sont composées la majorité de nos pages Web actuelles !

Ajoutez à cela qu’accrocher et maintenir le réseau data est une des opérations les plus coûteuses en terme de batterie : passez en mode avion sur votre smartphone, utilisez-le presque comme d’habitude (lectures, jeux…) et vous verrez qu’il peut tenir une seconde journée sans recharge. Et souvenez-vous des anciens portables sans data qui tenaient une semaine…

Bref, c’en est au point que les constructeurs optimisent comme ils peuvent le matériel, par exemple en mettant en veille la radio après un certain temps d’inutilisation. On se retrouve donc dans des situations où, le temps de lire cet article, l’antenne s’est déconnectée et il vous faudra plusieurs secondes pour que la requête suivante aboutisse !

Malgré cela, les utilisateurs ne sont pas beaucoup plus patients que sur un ordinateur de bureau : après 5 à 10 secondes de page blanche, une majorité d’utilisateurs a déjà rebroussé chemin, et autant vous dire qu’ils n’apparaissent même pas sur les statistiques collectées en JavaScript. Comment faire pour vaincre l’hémorragie de visiteurs et proposer des services de meilleure qualité perçue ?

Eh bien il va nous falloir revisiter tout l’arsenal des classiques de la Performance Web.

Remettre en cause les classiques

Lorsque le pape de la performance, Steve Souders, a émis chez Yahoo! les premières recommandations de performance Web, c’était en faisant du reverse-engineering sur les moteurs IE6-IE7 et Firefox 2. C’était en 2005 et, avec l’abandon progressif du support de ces navigateurs antédiluviens (à l’échelle du Web) d’un côté et la banalisation de l’ADSL de l’autre, certaines règles ou astuces sont devenues moins importantes.

L’apparition de la navigation sur mobile en a même rendu certaines dangereuses !

Le domain-sharding

Citons par exemple le domain-sharding, qui consiste à répartir ses fichiers statiques sur plusieurs sous-domaines différents. Étonnamment populaire, à l’origine cette technique permettait de passer outre la limitation à 2 files de téléchargement par domaine et de bénéficier de toute la largeur des bandes passantes modernes. Mais à partir de IE8, sorti en 2009, cette technique devient inutile car le nombre de téléchargements simultanés passe de 2 à généralement 6 : les navigateurs se sont adaptés à la banalisation des gros débits et tentent d’en tirer parti.

Utilisons le service Cuzillon qui va nous permettre de simuler une page avec 24 images réparties sur 4 domaines et une autre page avec 24 images sans domain-sharding. Le service WebPageTest nous permet de voir qu’il y avait effectivement une amélioration sur le temps de chargement sur IE7 :

WebPagetest – Test de chargement d’une page sous IE7 avec (en bas) et sans sharding (en haut). Voir la source

Le test sur les mêmes URLs sur IE8 nous montre que l’on ne gagne plus grand chose en premier rendu (les petites images chargées) :

WebPagetest – Test de chargement d’une page sous IE8 avec (en bas) et sans sharding (en haut). Voir la source

On ne gagne plus rien car la parallélisation des téléchargements est assurée de base par le navigateur. On a en fait rajouté deux mini-problèmes en rajoutant un temps de résolution DNS supplémentaire par domaine, et en faisant concourrir plusieurs images pour la même bande passante. Je dis « mini-problème » en supposant qu’on ne ciblait que les navigateurs de bureau (c’est mal) où ces problèmes sur des vrais sites (75-150 requêtes, 10-15 domaines) passent finalement inaperçus, mais vous ciblez les mobiles, pas vrai ?

Sur mobile, les navigateurs ouvrent également plusieurs connexions par domaine et font même du multiplexing HTTP (plusieurs requêtes HTTP dans le même tuyau TCP) pour minimiser les problèmes liés à la latence. Vous prenez alors le risque de couper court à ces optimisations. Résultat ?

WebPagetest – Test de chargement d’une page sous iOS avec (en bas) et sans sharding (en haut). Voir la source

L’affichage a été ralenti ! En forçant encore plus de domaines, vous demandez à plus d’objets de se partager la même bande passante, que vous devez considérer a priori comme rare sur mobile. Donc vous ralentissez l’affichage des premières images alors même que les suivantes ne sont pas immédiatement utiles. Ici, le temps de chargement total est en plus augmenté car le multiplexing n’a pas pu être utilisé, ce qui peut être le cas sur des sites avec un ratio ressources / domaine faible.

Les scripts en bas de page

Le temps avant le premier rendu (l’affichage des premiers pixels du site) est un peu le but ultime de la performance Web, car il y a une très forte corrélation entre ce temps et une augmentation des taux de transformation ( + rapide = + d’argent ).

Dans ce cadre, une autre technique populaire consiste à déplacer toutes les balises script en bas de page. Cette technique marche effectivement bien sur les anciens navigateurs et continue à faire ses preuves dans une moindre mesure sur les nouveaux malgré leurs progrès dans la prioritisation des téléchargements.

Regardons l’effet attendu avec IE8 sur une page simple où le téléchargement du JavaScript est retardé côté serveur.

Bureau : tests de comparaison de chargement d’une page avec les scripts en bas et en haut de page. voir la source

En haut, la page améliorée par déplacement des balises script ; on voit que le contenu (une simple phrase) s’affiche rapidement, alors qu’en bas la page blanche de la mort est de rigueur.

Passons sur mobile, si vous le voulez bien, et testons Safari iOS et Android Browser 2.3.

Mobiles Android et iOS : tests de comparaison de chargement d’une page avec les scripts en bas de page. Voir la source

Android se comporte comme nos navigateurs de bureau et affiche le contenu dès qu’il l’a. Safari iOS préfère attendre le script avant d’afficher quoi que ce soit, sans doute par peur du FOUC (Flash Of Unscripted Content).

On peut débattre sur le fait qu’ergonomiquement il vaut mieux attendre une page bien faite (complètement scriptée) plutôt que d’afficher rapidement du contenu pas finalisé, mais les taux de tranformation montrent que l’affichage rapide rapporte plus.
Et de toute façon, en tant qu’auteur de la page, c’est à vous de juger si elle peut être vue momentanément sans scripting ou pas : si vous utilisez des méthodes de développement par couche (HTML, puis CSS, puis JS), ça devrait être bon. Si vous voulez de la performance, il va donc falloir faire évoluer votre technique d’inclusion de script pour passer à une version asynchrone.

Le chargement asynchrone à la base est bête comme chou :

var oNode = document.createElement('script'); 
oNode.type = 'text/javascript'; 
oNode.src = 'http://domaine/monscript.js'; 
document.getElementsByTagName('head')[0].appendChild(oNode); 

Vous utilisez le DOM pour créer dynamiquement de nouveaux noeuds script qui vont charger des fichiers JS. Cette technique est notamment utilisée par les Google Analytics, boutons G+ et autres Like Facebook pour s’insérer dans vos sites sans introduire de dépendance forte vis-à-vis de leurs serveurs.
Autrement dit, lorsque leurs serveurs sont en rade ou bloqués par un proxy, le navigateur va tout de même afficher votre page (trop aimable). Utiliser cela avec ses propres scripts est globalement une bonne idée, et devient vital sur mobile. Vous aurez probablement besoin d’aller plus loin avec le chargement dynamique de scripts (exécuter du code lorsque le fichier est arrivé, gestion des dépendances et de l’ordre de chargement, concaténation de fichiers à la volée…), aussi pensez à utiliser des frameworks solides comme requireJS, YepNope.js (inclus avec Modernizr), HeadJS, LabJS… Chacun a sa philosophie.
Et puisque je vous tiens, voici le mien : LazyLoadLight, qui se veut léger et facile :)

Voir la suite de cet article qui parle des chemins à explorer pour des pages toujours plus rapides sur mobile.

HTML5, aujourd’hui

L’article suivant est la retranscription de l’article que j’ai écrit pour le magazine PHP Solutions, dans le numéro hors série de 2011 consacré à HTML5. Le monde compliqué du droit d’auteur veut que ce texte ne m’appartienne pas, c’est donc avec leur permission express que j’en fait bénéficier mes lecteurs (oui toi). Toute reproduction est donc interdite.

Cet article se veut une introduction générale à HTML5, notamment pour les développeurs PHP qui sont généralement les mieux placés pour prendre au sérieux ce qu’il se passe au frontend. Si vous avez lu mon livre sur HTML5 ou que vous suivez déjà régulièrement l’actualité, je doute que vous y appreniez grand chose. Il explique :

  • l’origine de la spécification
  • comment les sites d’aujourd’hui peuvent en bénéficier
  • le futur des applications Web
  • les rares synergies entre HTML5 et PHP

Historique

Une définition variable

Le terme même « HTML5 » couvre plusieurs définitions, et nous allons voir que le W3C a surpris tout le monde dans son choix final. Avant que le terme HTML5 n’apparaisse, HTML 4.01 était stabilisé et le W3C planchait sur XHTML 2 car pour eux la syntaxe stricte de XML allait permettre à tous les navigateurs d’être enfin d’accord sur les règles de parsingdes pages.
Lire la suite »

Usage avancé des fonctions JavaScript

Cet article est un complément à l’article sur les 3 fondamentaux de JavaScript, il vaut mieux être déjà à l’aise avec JavaScript avant de crier au scandale en voyant ce qu’on peut en faire. Pour reprendre un bon mot de quelqu’un qui avait assisté à ma conférence sur JavaScript :

javascript == la pornstar des langages de dev: souple, puissant, tu lui fait faire ce que tu veux, et ça peut finir bien crade.

Admettons donc que vous ayez digéré sans problème les portées et les fonctions, passons à deux choses vraiment particulières à JavaScript :

  1. le renvoi de fonction qui permet de belles optimisations et qui ouvre la voie à des patterns que les amoureux de la théorie du langage apprécieront,
  2. une implémentation de classe statique, pour reprendre le terme utilisé en PHP ou en Java.

Et enfin nous verrons une proposition d’implémentation de deux design pattern célèbres et particulièrement utiles en JavaScript : Singleton et Factory.
Lire la suite »

JavaScript : 3 fondamentaux

Après quelques années à écrire dans un langage, on finit facilement par oublier les premières difficultés que l’on avait rencontrées. Et à force de faire de la veille, de l’autoformation et de parler entre experts dans des conférences, j’ai un peu quitté la réalité de la majorité des équipes Web.

Maintenant que je suis consultant indépendant je retourne dans des équipes qui avaient autre chose à faire que de se demander si on a le droit de parler de classe en JavaScript, quelle est la bonne définition d’une closure, ou quelles sont les fonctionnalités de EcmaScript 5 qui auraient du rester dans Ecmascript.Next.

J’avais déjà parlé sur ce blog de JavaScript et la programmation orienté objet pour les développeurs PHP, nous allons explorer ici les 3 notions fondamentales de JavaScript qui sont probablement les plus grosses sources de bugs, d’incompréhension et de frustration pour le développeur Web moyen. Et qui accessoirement sont la base d’une programmation plus évoluée par la suite.

JavaScript est différent : apprenez le

Le monde du développement Web semble dominé par les langages dérivés de la syntaxe du C, PHP en tête, avec des paradigmes qui se ressemblent. Forcément en abordant JavaScript dont la syntaxe n’est pas vraiment révolutionnaire, on est tenté d’appliquer la même logique. Mais c’est oublier un peu vite que ce langage a été créé il y a déjà 15 ans, quand Java était seulement à mode et pas encore ultra dominant comme aujourd’hui, et qu’il est principalement l’héritier de langages comme Erlang et Lisp, aujourd’hui très peu connus. En fait le mot Java dans JavaScript a été rajouté pour des raisons commerciales, et seuls quelques concepts comme la syntaxe et je crois la gestion des dates ont contribué à former JavaScript. JavaScript n’est donc qu’un cousin éloigné des langages mainstream.

Le maître mot de ses concepteurs semble avoir été la versatilité. Nous allons voir qu’en explorant seulement 3 bases à priori simples, il est possible d’obtenir à peu près n’importe quoi, ce que les grands maître de JavaScript s’amusent tous les jours à faire. En attendant de passer dans la catégorie des maîtres, il faut déjà maîtriser ces bases pour faciliter son travail au quotidien.

Nous allons donc nous baser sur EcmaScript 3 (le javascript de IE6-7-8) dont les trois fondamentaux sont :

  • La portée des variables ( var + function)
  • Les fonctions
  • Le contexte (this)

Commençons par la portée.
Lire la suite »

HTML5 maintenant, chapitrage de la conférence

La vidéo sur la conférence que j‘ai donné à Paris Web 2010 vient de sortir, aussi comme pour la conférence sur les Performances Web je l‘ai chapitré et je vous remets les slides pour que vous vous y retrouviez.

Mes capacités d‘orateur valent ce qu‘elles valent, mais le contenu et le discours restent d‘actualité et devraient permettre je l‘espère à certains développeurs de se décoincer face à HTML5 : les fonctionnalités sont utilisables maintenant en production, pour peu qu‘on sache coder, utiliser des librairies faites pour ça et qu‘on soit suffisamment curieux pour tester tout cela. Les bénéfices sont soit immédiats soit à venir, et il y a certains écueils à connaître.
Le maître mot est : testez ! Dans la plupart des cas vous vous rendrez compte que vous pouvez mettre en production et donc améliorer votre site pour vos utilisateurs.
Lire la suite »