Sacha Morard est CTO du groupe Le Monde depuis 2018 (Le Monde, Courrier International, Télérama, Huffington Post, L’Obs). Ancien CTO du Parisien, la web performance est un sujet qu’il maîtrise de longue date. Pour Lemonde.fr qui enregistre 600 millions de pages vues par mois (jusqu'à plusieurs milliards en 2020), et dont le trafic est à 60% mobile, comment s’organisent les ressources pour optimiser la vitesse de chargement ? Avec quels outils et en suivant quels KPIs ? Entretien.
Combien de personnes composent les équipes techniques du groupe Le Monde, et comment gèrent-elles la webperf ?
Sacha Morard : La direction technique du numérique compte 75 membres : Développeurs, Tech Lead, VP Engineering et Product Owners organisés en feature teams, qui travaillent avec des Designers UI et UX, des profils Marketing… Mais il n’y a pas d’équipe qui ne fait que de la webperf.
La performance est centrale pour l’ensemble de notre roadmap - par exemple, même notre pôle Audience suit les Core Web Vitals, alors que ça pourrait être considéré comme un sujet purement technique ou SEO.
Ainsi, la plupart des équipes maîtrisent le sujet de la webperf, en s’appuyant sur des interlocuteurs experts en interne.
Comment avez-vous fait pour que la performance web devienne un sujet pour toutes les équipes, et pas seulement l’équipe technique ?
S. M. : Le Monde a quasiment une mission de service public. Derrière le titre, il y a une promesse. Les lecteurs sont de plus en plus des abonnés, et nous devons prendre soin d’eux en leur offrant une expérience utilisateur de qualité, une navigation fluide et des pages rapides. C’est la raison pour laquelle nous pensons performance web dès le début de tous nos projets.
En 2018, nous avons refondu le site web Lemonde.fr pour mettre la webperf au centre. En général, les grands travaux d’évolution sont réalisés en premier sur Lemonde.fr, et les autres titres du groupe en héritent.
C’est devenu un enjeu essentiel et j’ai imposé ce KPI à tout le monde : avoir des pages rapides et de bons temps de chargement était un prérequis avant de livrer cette nouvelle version. L’un des objectifs était de réduire le Speed Index de 60% sur mobile en 3G.
Nous aurions pu nous tourner vers Instant article et Google AMP, qui étaient tentants à l’époque, mais j’ai préféré rendre le site intrinsèquement rapide, en dehors d’AMP. Au final, on a pas eu besoin d’aller vers ce format, et les résultats ont été tellement probants que la webperf est un sujet qui est remonté jusqu’au Comex qui se l’est pleinement approprié.
Concrètement, le travail d’ensemble d’optimisation de l’expérience utilisateur nous a conduits à +24% de pages vues et +46% de prises d’abonnement.
Il faut savoir que l’essentiel de notre audience abonnée utilise le desktop et que l’audience mobile est plus volatile. Mais nous avons évidemment conscience de l’importance des usages mobiles, et surtout de l’importance d’avoir un site Mobile First, notamment pour notre référencement Google.
D’ailleurs, nous relevons toutes nos métriques webperf sur mobile, en simulant la navigation sur Iphone 6 en 3G. C’est un bon moyen de savoir si nos pages sont vraiment rapides, même dans des conditions de navigation avec un device et un réseau dégradés. Nous nous comparons aussi avec les performances de nos concurrents pour avoir un référentiel et nous situer dans notre écosystème.
Pour mesurer vos performances, quels indicateurs suivez-vous ? Les Core Web Vitals de Google sont-ils un game changer ?
S. M. : Historiquement, nous surveillons de près notre Speed Index, notre Time To First Byte (surtout le handshake), le poids des pages, ou encore le poids des JavaScript.
Nous utilisons le système d’alerting de SpeedCurve pour suivre notre Budget performance.
Par exemple, quand nous avons mis en production notre nouvelle Consent Management Platform (CMP), nous avons pu être prévenus immédiatement de l’impact sur les performances du site, et nous avons pu intervenir pour optimiser la vitesse de chargement.
Par ailleurs, depuis que Google a annoncé l’arrivée des Core Web Vitals avec la mise à jour Page Expérience update, nous avons intégré ces métriques à nos KPI. De toute façon, quand on optimise les Core Web Vitals, le Speed Index suit. Et puis, être en tête du classement webperf du JDN est grisant, nous nous donnons les moyens d’y rester.
En termes de KPI business et marketing, le trafic SEO est un point de repère important. Si on livre un produit pas optimisé, et qu’il dégrade la vitesse des pages et l’expérience utilisateur, on le voit très vite. C’est même un indicateur plus flagrant par rapport à ce qu’on pourrait observer sur les parcours utilisateur habituels, car évidemment, nous ne livrons jamais rien qui dégraderait les performances au point que les visiteurs quittent le site.
Comment anticipez-vous les pics de charge liés à l’actualité ? Ils peuvent être colossaux !
S. M. : L’avantage d’un site intrinsèquement rapide est qu’il peut absorber les pics de charge beaucoup plus facilement. En ce qui concerne Lemonde.fr, par exemple quand il y a des élections ou des allocutions officielles, notre site est dynamique, mais nous si besoin nous pouvons sécuriser notre plateforme avec la mise en cache de certaines pages sur notre CDN, et nous prévoyons un mode dégradé en cas d’incident technique critique, par précaution.
Mais en pratique, même en cas de pic de trafic très important, notre site est configuré pour tenir sans problème. Nous avons traversé des pics pendant les dernières municipales, ou pendant la crise du Covid, où la fréquentation passait de 50K visiteurs en temps réel à 240K en quelques minutes.
Ce qui nous permet de tenir la charge, outre le fait que la webperf est traitée côté serveur, c’est que notre infrastructure entière est optimisée. Nos serveurs répondent sur le HTML et les assets sont sur notre CDN.
Pourquoi avoir fait ce choix ? Parce que si nous mettions en cache le HTML sur un CDN, nous aurions besoin de maintenir à chaque fois deux versions d’une même page : version abonné et version visiteur gratuit. Il faudrait alors un JavaScript pour charger le contenu pour les visiteurs abonnés, avec un risque de flickering… Et ça ne correspond pas aux standards de qualité UX que nous voulons.
Autre point technique qui nous permet d’optimiser la vitesse de chargement sur nos sites : les tests AB réalisés Server side. Grâce à ce parti pris, plus besoin de librairie JavaScript qui risquerait d’alourdir les pages.
Nous faisons de la personnalisation First Party avec des recommandations light, sur des sites bel et bien dynamiques : session utilisateur, login, contenu adapté en fonction du device (adaptatif), affichage des éléments pour le mobile adaptés côté serveur…
Ainsi, comme tous les grands acteurs du marché, notre infrastructure nous permet de garantir la scalabilité et le dynamisme de nos sites, et surtout leurs performances et leurs temps de chargement. Nous faisons tout pour que nos fonctionnalités et nos contenus soient accessibles pour nos utilisateurs sans dégrader la vitesse, en jouant sur l’élasticité.
Au quotidien, quelles sont les optimisations dont vous mesurez le plus les effets sur la vitesse de chargement ?
S. M. : Les optimisations qui ont eu le plus d'impact sur la vitesse de chargement de nos pages sont les suivantes :
- La réduction du poids des pages : pour des raisons de contraintes SEO, nous n’avons pas souhaité aller vers des Single Page App (SPA), ce qui peut sembler antinomique par rapport à nos frameworks. Le site est dynamique, les couches HTML et JavaScript sont allégées, et la personnalisation peut alors se faire sans ralentir les pages.
- L’optimisation des images : nous avions développé un serveur d’images pour traiter les formats WebP, mais la dégradation était telle que ça nous éloignait de nos objectifs en termes d’expérience utilisateur. Comme la qualité des images ne nous semblait pas satisfaisante, nous avons finalement abandonné WebP, et il y a forcément un impact sur la bande passante. Au final, nous réussissons très bien à adapter la taille des images selon les écrans, et à les compresser correctement en JPEG, et tout le monde s’y retrouve des deux côtés du navigateur, surtout sur la qualité des visuels.
- Le critical CSS : c’est une technique qui nous est très utile, surtout pour la 1ère page où le CSS est chargé en inline. Toutefois, il faut savoir que cette technique est difficile à mettre en place sur un site qui n’est pas dynamique. Le principe est assez simple, mais complexe à mettre en place. Lors de la première visite, un bout de CSS (le critical) doit être écrit en inline directement dans le HTML, alors que le reste des feuilles de style doit être chargé en asynchrone. Chez nous, ce critical CSS est préalablement calculé par un bot qui sélectionne les règles CSS utiles au rendu de la partie visible de la page, et ce calcul est fait pour chaque type de device.
Aussi, comme je le disais un peu plus tôt, le HTML de nos pages est servi par nos serveurs, et c’est de cette façon que nous pouvons appliquer toutes ces techniques, ce qui serait plus difficile avec un CDN.
Et les Third Parties ? Sur un site de presse, la publicité est vitale, mais elle a aussi un poids.
S. M. : La gestion des Third Parties a pu être complexe mais ce n’est plus le cas maintenant. Le Monde est un site à fort trafic avec une mission d’information générale, donc forcément, il y a de la publicité. Il faut savoir faire quelques compromis.
Pour optimiser nos performances, nous avons isolé la partie pub du reste du site, ce qui fait qu’elle a moins d’impact sur la vitesse de chargement des pages - Speed Index et Cumulative Layout Shift (CLS), notamment. Grâce à cette dissociation entre contenu éditorial et contenu publicitaire, si une pub se charge lentement, l’emplacement est de toutes façons réservé, et l’impression de lenteur ne touche pas la page dans son ensemble, seulement la publicité le cas échéant.
La publicité est un cas parmi tous les tiers, de manière générale, nous faisons attention à tout ce qu’on intègre sur nos pages. Nous avons aussi fait le choix de ne pas avoir de tag manager pour éviter l’intégration de contenus qu’on ne maîtriserait pas. Il en reste seulement un sur notre tunnel d’abonnement que nous sommes en train de changer.
Pour finir, quels conseils pourriez-vous donner à des équipes qui souhaitent se lancer dans l’optimisation de la performance de leur site web ?
S. M. : Je dirais que l’un des points importants pour mener un projet d’optimisation de la performance web, c’est de réussir à évangéliser les équipes en interne. Très souvent, le sujet parle à une partie des équipes, et elles se renvoient la balle, sans se rendre compte que tout le business est en jeu. C’est exactement ça qu’il faut réussir à démontrer !
Et dans ce cas, pour installer cette culture, rien ne vaut un expert qui vient expliquer ce qu’est la webperf et ce qu’elle peut apporter.
Il faut ensuite des ambassadeurs en interne, et ancrer la performance dans la roadmap, sinon elle passera à la trappe. En d’autres termes, le sujet doit être sanctuarisé.
A cette fin, le Budget performance est un garde-fou nécessaire. A titre personnel, si je dois refuser l’ajout d’un script tiers, je peux facilement expliquer pourquoi : je teste et je montre l’impact sur la vitesse de chargement, scores Lighthouse, PageSpeed Insights ou WebPageTest à l’appui.
Les outils de mesure, les indicateurs, et les techniques pour optimiser l’expérience utilisateur ne manquent pas, et que ce soit en interne ou à l’aide de solutions d'optimisation, les équipes Techniques, SEO, Marketing, Produit… Tout le monde profite concrètement des bénéfices de pages web rapides.
Ces bonnes pratiques vous ont inspirées ? Nous aussi !
Elles font partie de ce qu'on préconise pour des pages rapides.
Continuez de vous inspirer, retrouvez nos interviews d’experts
et nos actus dans notre newsletter mensuelle :
