L’Équipe.fr compte chaque mois environ 1,5 milliard de pages vues, avec des pics jusqu’à 600 000 pages vues par minute pendant les événements majeurs. 80 % des visites provenant du mobile, le quotidien sportif doit offrir une expérience fluide sur ce device avec des pages rapides – surtout pendant le feu de l’action. La vitesse fait partie des préoccupations de l’équipe technique qui souhaitait pousser les optimisations encore plus loin. Cette recherche de performance a conduit à faire appel à Fasterize pour réaliser un audit de vitesse et identifier les leviers d’amélioration – une étape qui aura constitué le point de départ d’une migration technique importante. Rencontre avec Raphaël Dardeau, Directeur des développements numériques de L’Équipe.
Fasterize : Qu’est-ce qui vous a décidé à réaliser un audit de vitesse ?
Raphaël Dardeau : Jusqu’à notre refonte en juin 2019, nous avions des sites mobile et desktop indépendants. Les performances étaient bonnes sur mobile (nous avons même atteint la première place du classement webperf mobile du JDN en 2018), mais la version desktop reposait sur une technologie plus ancienne et nous avions des temps de chargement qui méritaient d’être améliorés, car cela reste un support dont les enjeux publicitaires sont importants.
La refonte a bien permis d’améliorer nettement la vitesse des pages sur desktop, mais comme nous avons unifié le site web pour tous les devices, le mobile s’est légèrement dégradé parce qu’il embarquait plus de contenus. C’était une alerte qui a commencé à nous faire réfléchir.
Avec le contexte de crise sanitaire, les compétitions sportives à l’arrêt et une activité ralentie, nous nous sommes concentrés sur des sujets de fond dont la web performance fait partie.
La vitesse nous a toujours concernés, mais je dois dire que parfois nous l’avons un peu mise de côté par manque de temps. Et pour remettre le pied à l’étrier, j’ai eu la conviction que nous avions besoin d’un regard extérieur pour compléter nos compétences en interne.
Un audit nécessite beaucoup de temps d’analyse, et le faire en externe permet de nous soulager. Par ailleurs, des intervenants extérieurs experts aident à appuyer le propos et à envisager des KPI et des solutions auxquelles nous n’aurions pas forcément pensé.
Fasterize : Comment avez-vous fixé vos objectifs de performance ?
R.D. : Nous visons différents axes de progression. Pour le monitoring de la vitesse, nous suivons différents dashboards SpeedCurve et avons défini des budgets performance basés sur les recommandation de Lighthouse. Aussi, nous recevons des alertes lorsqu’une mise à jour du site entraîne le franchissement du seuil fixé pour un indicateur donné.
Le deuxième aspect est davantage tourné vers l’extérieur : nous surveillons le classement JDN qui nous permet de nous comparer avec nos concurrents directs dans la catégorie médias.
Si nos indicateurs internes progressent mais que dans le même temps nos concurrents progressent plus vite que nous, ça signifie que nous devons agir pour rester compétitifs en améliorant encore notre UX pour nos visiteurs, mais aussi pour réserver un meilleur accueil aux robots des moteurs de recherche pour le SEO.
En parlant de SEO, l’audit nous a permis de confirmer que notre attention doit maintenant se porter davantage sur les Core Web Vitals pour nous aider à faire progresser notre ranking.
D’ailleurs, ce changement dans le choix des métriques illustre bien à quel point mesurer les améliorations de la vitesse peut être compliqué, car les indicateurs changent régulièrement.
C’est aussi pour cette raison que les connaissances de consultants experts de la web performance est utile : le travail de veille doit être constant, les pratiques évoluent vite, et ce n’est pas toujours évident d’assumer cette charge en interne.
Par exemple, nous avions mis en place du pré-rendering avec l’ambition d’optimiser notre First Meaningful Paint (FMP). Notre refonte nous a permis de le diviser par deux, mais ç’aura été au détriment de notre Time To Interactive et de notre First Contentful Paint… alors que le FMP a finalement été déprécié. Nous avons fourni des efforts conséquents pour un indicateur qui a été abandonné par Google Lighthouse.
Fasterize : Quels sont les points d’amélioration que l’audit vous a permis d’identifier, et quels enseignements en tirez-vous ?
R. D. : Le quick win le plus important que l’audit nous a permis d’identifier, c’est l’optimisation de notre script d’A/B Test. Il était chargé tout le temps alors qu’on ne fait que 1 à 2 campagnes de tests sur quelques jours chaque mois. Inutile, donc, de le charger systématiquement. Nous avons une interface à disposition de l’équipe Produit qui permet de désactiver des scripts tiers à la demande, et programmer des périodes pendant lesquelles ils doivent être actifs.
Mettre en lumière l’impact de ces Third Parties sur la vitesse des pages nous a permis de sensibiliser les équipes Marketing et Produit sur l’importance de désactiver les scripts quand il n’y a pas de campagne en cours.
De plus, notre solution d’A/B Test utilisait un voile anti-flickering. C’est-à-dire que pendant 1 seconde, une page blanche apparaissait pendant que l’A/B Test se mettait en place. Nous avions donc notre page pré-rendue qui s’affichait, ensuite le voile blanc de la solution d’A/B Test, et ensuite la page qui se rechargeait. Le flickering était alors accentué bien que la page soit déjà bel et bien chargée. Pour l’expérience utilisateur, ce n’était vraiment pas optimal. Nous avons donc demandé à notre fournisseur d’A/B Test de faire évoluer leur solution pour ne plus avoir cet effet de flickering intempestif. L’audit nous a aussi permis d’avancer sur ce point.
Par ailleurs, nous nous interrogions beaucoup sur notre système de pré-rendering, permettant aux robots de lire des pages HTML complètes bien que notre site soit une SPA. Sur ce point, l’audit nous a été d’une grande aide à la décision, car il nous a permis de voir que cette architecture représenterait toujours un facteur limitant pour notre progression.
En conclusion, nous avons décidé de partir sur un nouveau framework (Nuxt) qui permet de faire du server-side rendering (SSR), ce qui nous exonère du pré-render grâce à des pages rendues côté serveur en JS. La réhydratation devient alors transparente pour l’utilisateur.
Ainsi, de façon presque inattendue, cet audit aura été le point de départ d’un chantier de migration plus conséquent qu’une optimisation de l’existant. Si nous n’avions pas fait cet audit de vitesse de notre site web, nous aurions peut-être continué à hésiter encore longtemps en étant contraints par des limites techniques. Notre nouveau framework nous permet de nous en affranchir, nous avons fait un véritable bond technologique !
Parmi les autres techniques pour des pages plus rapides, nous avons suivi les recommandations de l’audit telles que le Tree Shaking, l’utilisation de la directive rel=”preload”, ou encore l’optimisation de notre script de header bidding.
Après la migration en SSR et la réalisation des recommandations de l’audit webperf de Fasterize, nos tests ont montré une accélération significative de nos pages :
- le Speed Index a baissé de 45 %,
- le First Contentful Paint de 25 %,
- et le Cumulative Layout Shift (l’un des Core Web Vitals) de 90 % ;
- nous avons aussi réduit notre Time To Interactive de 20 % – et il va encore s’améliorer car notre travail d’optimisation est toujours en cours.
Fasterize : Comment avez-vous organisé vos équipes pour déployer les recommandations de l’audit de Fasterize ?
R. D. : Pour passer à l’action suite à l’audit webperf, nous sommes partis du document de synthèse et nous avons créé des tickets Jira en distinguant les tickets qui permettent des gains immédiats à faire sur le framework actuel de ceux offrant des gains à plus long terme, à planifier sur le prochain framework.
Nous fonctionnons avec des feature teams qui occupent différents périmètres et s’activent selon la nature des tickets.
Nous n’avons pas d’équipe dédiée à la web performance, mais nous faisons un maximum de pédagogie auprès des développeurs front en priorité.
Les membres de l’équipe les plus anciens sont déjà sensibilisés parce que la web performance fait partie de nos priorités depuis longtemps, mais il y a naturellement du turn-over et de nouvelles ressources à former pour conserver cette culture. Aussi, nous responsabilisons quelques membres qui évangélisent en interne.
Ces moteurs de la webperf en interne permettent de faire infuser le sujet côté technique et côté métier – sachant que comme tout média, nous sommes confrontés à des enjeux publicitaires qui viennent nuancer les résultats de performance brute.
Enfin, j’ajoute que nous aimerions pouvoir réaliser le même type d’audit pour nos applications mobiles, dont la part est très importante chez nous, mais pour lesquelles nous disposons de moins de moyens de suivi de la performance. Nous avons hâte qu’un classement similaire à celui du JDN pour la webperf mobile existe pour les apps !
Vous souhaitez échanger avec nos experts
pour vous aider à accélérer votre site ?