L’Équipe.fr has around 1.5 billion page views every month, with peaks of up to 600,000 page views per minute during major events. With 80% of visits coming from mobile devices, the sports daily has to offer a fluid experience on this device, with fast pages – especially during the heat of the action. Speed was one of the concerns of the technical team, who wanted to push optimizations even further. This quest for performance led them to call on Fasterize to carry out a speed audit and identify the levers for improvement – a step that was the starting point for a major technical migration. Interview with Raphaël Dardeau, Director of Digital Development at L’Équipe.
Fasterize: What made you decide to carry out a speed audit?
Raphaël Dardeau: Until our redesign in June 2019, we had independent mobile and desktopsites. Performance was good on mobile (we even reached first place in JDN’s mobile webperf ranking in 2018), but the desktop version was based on older technology and we had loading times that needed improving, as this remains a medium with high advertising stakes.
The redesign did enable us to significantly improve page speed on desktop, but as we unified the website for all devices, the mobile experience deteriorated slightly because it contained more content. It was a warning that started us thinking.
With the health crisis, sports competitions at a standstill and business slowing down, we focused on core subjects, including web performance.
We’ve always been concerned with speed, but I have to say that sometimes we’ve put it to one side for lack of time. And to get our feet back on the ground, I became convinced that we needed an outside viewpoint to complement our in-house skills.
An audit takes a lot of time to analyze, and doing it externally relieves us. What’s more, having outside experts on board helps us to make our point and consider KPIs and solutions we might not otherwise have thought of.
Fasterize: How did you set your performance targets?
R.D.: We’re aiming for different areas of improvement. For speed monitoring, we follow various SpeedCurve dashboards and have defined performance budgets based on Lighthouse recommendations. We also receive alerts when a site update causes a given indicator threshold to be crossed.
The second aspect is more outward-looking: we monitor the JDN ranking, which enables us to compare ourselves with our direct competitors in the media category.
If our internal indicators are improving, but at the same time our competitors are progressing faster than we are, it means that we need to take action to remain competitive by further improving our UX for our visitors, but also to give a better welcome to search engine spiders for SEO purposes.
Speaking of SEO, the audit confirmed that we now need to focus more on Core Web Vitals to help us boost our ranking.
Incidentally, this change in the choice of metrics illustrates just how complicated measuring improvements in speed can be, as indicators change regularly.
It’s also for this reason that the knowledge of expert web performance consultants is useful: monitoring work must be constant, practices evolve quickly, and it’s not always easy to take on this task in-house.
For example, we had implemented pre-rendering with the ambition of optimizing our First Meaningful Paint (FMP). Our redesign enabled us to halve it, but this was at the expense of our Time To Interactive and First Contentful Paint… while the FMP was ultimately depreciated. We put a lot of effort into an indicator that has been abandoned by Google Lighthouse.
Fasterize: What areas for improvement did the audit enable you to identify, and what lessons have you learned from it?
R. D.: The most importantquick win that the audit enabled us to identify was the optimization of ourA/B Test script. It was loaded all the time, whereas we only run 1 or 2 test campaigns over a few days each month. So there was no need to load it systematically. We have an interface available to the product team which allows them to deactivate third-party scripts on demand, and schedule periods when they should be active.
Highlighting the impact of these Third Parties on page speed has enabled us to make the Marketing and Product teams aware of the importance of deactivating scripts when there is no campaign in progress.
What’s more, our A/B Test solution used ananti-flickeringveil. In other words, for 1 second, a blank page appeared while the A/B Test was being set up. So we had our pre-rendered page displayed, then the whiteout from the A/B Test solution, and then the page reloaded. The flickering was accentuated, even though the page had already loaded. For the user experience, this was far from optimal. We therefore asked our A/B Test provider to upgrade their solution so as to no longer have this untimelyflickering effect . The audit also enabled us to make progress on this point.
We were also very concerned about our pre-renderingsystem , which allows robots to read complete HTML pages even though our site is an SPA. On this point, the audit was a great help in our decision, as it enabled us to see that this architecture would always represent a limiting factor for our progress.
In conclusion, we decided to go for a new framework (Nuxt) which enables us to do server-side rendering (SSR), which exempts us from pre-rendering thanks to pages rendered server-side in JS. This makes rehydration transparent to the user.
So, almost unexpectedly, this audit was the starting point for a migration project that would have been much more significant than simply optimizing the existing site. Had we not carried out this audit of our website’s speed, we might have continued to hesitate for a long time yet, constrained by technical limitations. With our new framework , we’ve made a real technological leap forward!
Among other techniques for faster pages, we have followed the audit’s recommendations, such as Tree Shaking, use of the rel=”preload” directive , and optimization of our header bidding script.
After migrating to SSR and implementing the recommendations of the Fasterize webperf audit, our tests showed a significant acceleration of our pages:
- Speed Index down by 45% ,
- First Contentful Paint by 25%,
- and Cumulative Layout Shift (one of the Core Web Vitals) by 90%;
- we’ve also reduced our Time To Interactive by 20% – and it’s set to get even better as our optimization work continues.
Fasterize: How did you organize your teams to implement the recommendations of the Fasterize audit?
R. D.: To take action following the webperf audit, we started with the summary document and created Jira tickets, distinguishing between tickets offering immediate gains to be made on the current framework and those offering longer-term gains, to be planned on the next framework.
We work with feature teams who occupy different perimeters and are activated according to the nature of the tickets.
We don’t have a team dedicated to web performance, but we do a maximum of educational work with front-end developers as a priority.
The most senior members of the team are already aware of this, because web performance has been one of our priorities for a long time, but there is naturally some turnover and new resources need to be trained to maintain this culture. We are also empowering a few team members to evangelize internally.
These in-house webperf drivers enable us to infuse the subject on both the technical and business sides – bearing in mind that, like all media, we are confronted with advertising issues that add nuance to the raw performance results.
Finally, I’d like to add that we’d like to be able to carry out the same type of audit for our mobile applications, which account for a very large proportion of our business, but for which we have fewer means of tracking performance. We can’t wait for a ranking similar to JDN’s for mobile webperf to exist for apps!
Would you like to talk to our experts
to help you speed up your site?