Fostering a web performance culture on leroymerlin.fr (1/3)

Who am I? Bertrand!

I’ve been a front-end developer for 10 years now at Leroy Merlin France and I’ve been involved in Core Vitals themes since 2014.

My main focus over the last years has been Web performance. We have achieved a lot thanks to a widely adopted WebPerf culture. I want to tell you a story. At the beginning we were working on a legacy platform, a monolithic HTTP 1 frontend. And we managed to achieve a lot at this time. This article is focused on this period. If you are starting to look into Web performance you will find useful insights and actionnables.

In the following articles, I will explain what are the different evolutions (micro frontends, HTTP2) and how we are working today. Make sure to subscribe!

At the beginning, in 2014…

The work was focused on the back-end to improve server response times, the infrastructure for network times and the front-end for browser performance. To start our analysis, we used the following tools:

• GTmetrix

GTmetrix combine multiple tools like Lighthouse and displays a good first global vision, especially a clear waterfall

• Yellow labs

Gives more advanced and relevant recommendations than GTMetrix, especially by bringing the notion of render-blocking elements or DOM size

• Web page Test

Available on webpagetest.org. This is the reference tool to calculate the Speed Index (definition here: https://docs.webpagetest.org/metrics/speedindex/).

We have come a long way in this adventure: our pages used to take several seconds to display at the time, and sometimes exceeded ten seconds. This led us to go through:

• lighter images
• less requests
• cleaning up unused, repeated CSS
• minification / uglification of scripts
• setting up a CDN on several domains
• render blocking resources
• and so on

This approach allowed us to be first on the Journal du Net (a famous IT website in France) e-commerce ranking for the whole year 2016 (https://www.journaldunet.com/solutions/dsi/1176805-classement-la-webperf-des-tenors-du-e-commerce-en-france-en-mars/).

This ranking was not an end in itself. First of all, it was a clear highlight regarding the efforts of our teams, particularly in non-IT areas. Both marketing & technical people were united around this challenge. From now on, web performance would remain a priority in project approaches.

To monitor our quality on web performance, we have mainly monitored these four indicators:

• TTFB — Time To First Byte: DNS resolution + SSL negotiation since we are in HTTPS + server response time + time to download the first byte
• HTTP requests count
• Total weight of all page resources and HTML page
• Speed Index

About SpeedIndex, Dareboost blogs has a very good article about it : https://blog.dareboost.com/fr/2018/02/speed-index-performance-web/

2018 : the birth of a new platform

Starting in 2018, we started to adopt a Micro Front-end architecture. It’s for sure a challenge to maintain web performance with this new paradigm! Micro Front-end is required so we can add more people working on the website, ship more feature and bring at scale multiple use of LeroyMerlin.fr. Our WebPerf strategy had to change.We’ll write about these specific challenges in a next article.

Easy to read timeline about WebPerf at Leroy Merlin

2014 : We started working on WebPerf. Main tools were GTmetrix, Yellow Labs, Web page test

2016 : Achievement : 1st position in Journal Du Net’s ranking. It allowed us to involve all stakeholders into Web performance.

2018 : Leroymerlin.fr is starting to adopt Micro Frontends paradigm. So we adapted our WebPerf strategy. You are reading this.

At that time, the number of frontend developers increased tenfold to implement the new architecture. That’s in itself a challenge. We had to ensure that newcomers are well onboarded in our mission for Web Performance. And we had to bring them the tools and knowledge to do so.

At first, we focused on two projects to have leverage :

• Writing a repository of good practices, many of which concerned web performance
• Using Dareboost’s solution for web page analysis to provide indicators

Dareboost has several advantages, but the one that stands out the most, in my opinion, is the provided knowledge. In addition to a large number of metrics, the tool’s recommendations are always very relevant.

Threshold strategy

Web performance monitoring was very centralized. This was not a problem given the number of front-ends developers at that time but it had to be opened up to be effective with the growing number of teams. Every team had access to Dareboost to make shots and monitor if their pages were below these thresholds. They have been defined with the Leroy Merlin front-end community based on standards :

• TTFB < 500ms
• Speed Index < 2000ms on desktop and < 3000ms for mobile
• Number of global requests below 100
• Page weight under 800Kb

These results did not take into account the third party resources because they penalized too much the scores of the requests and the weight and thus drowned problems related to the site itself. We did this because we were not monitoring the impact of third-party scripts on the CPU.

Thresholds enable us to maintain a high level of quality, even with a high number of teams, but it doesn’t allow us to achieve the best result possible.

Need to have a common reference frame

To challenge metrics, it is obvious to have a common repository to talk about it. Michel, a front-end developer who tests his mobile user experience by emulating Chrome desktop with a fiber connection, will inevitably have better results than Maurice with an Android 4.4 in 3G connected to his computer over USB.

Lighthouse is a very good tool made available in Chrome browsers, but above all it brought us a lot of noise. It contains the essential web performance KPIs but it is too dependent on the developer’s computer: connection, hardware and browser. Therefore, it is necessary to agree on a common base of figures to avoid wasting time in confrontation. A common tool in the company for monitoring metrics is therefore essential.

From synthetic analysis to real user monitoring

Two definitions before going further:

Synthetic analysis emulates user behavior. We configured this solution to be as close as possible to our users’ profile to carry out regular tests.

Real User Monitoring (RUM) is not an emulation but captures real user behavior from the browser.

Monitor the “real” metrics, those of our users

Until now, our analyses had always been synthetic. Synthetic analysis is very powerful because it allows us to go into the details of the page’s behavior, but it comes up against a major problem: how can we ensure that the test cases are relevant? Testing a desktop with fiber or an iPhone in 5G will inevitably bring back very good figures but it is advisable to be more pessimistic to better transcribe the user experience. Analyses of real user speeds are rare on this subject and remain global and not contextual to Leroy Merlin. For example, to calibrate our synthetic tests we used a Chrome Desktop ADSL and a Chrome on Android 8 with 4G based on ARCEP figures.

Real user monitoring allows us to get rid of this doubt by collecting field data. Today we use two tools to do this:

Google CrUX

More information here: https://developers.google.com/web/tools/chrome-user-experience-report

Google CrUX is free and available without too much effort, it’s a very good solution to get webperf scores from the field. This is what the “Journal Du Net” has been based on since the beginning of the year. Beware, however, its limits are clearly announced by Google: it is only Chrome users who have given their consent and Google “chooses” the pages whose data it exposes.

This tool also gives additional data such as the connection of users.

Speedcurve LUX

Where Google takes user data via its browser, Speedcurve collects it via an asynchronous tag dropped on the site. You have to put this tag on top of the page to collect relevant data. The earlier it will be declared, the more Speedcurve will be able to absorb all the timing of the page. We will find almost all the Core Web Vitals with notably the First Input Delay which is not possible to calculate in synthetic. The solution also allows us to follow the RUMs of the Single Page Application via a very simple API.

Synthetic and RUM are two complementary analyses: the RUM will be more useful for alerting and monitoring the state of health of the site, while the synthetic allows us to be better equipped to look for ways to improve.

Speedcurve integrated in the development factory

Private agents for non-prod environments

Speedcurve is based on the results of Webpagetest for its synthetic data. The problem of testing environments not accessible to the outside world with a SaaS solution often leads to concessions on security.

The problem is solved with the creation of a private Webpagetest agent hosted on our Google Cloud Platform zone. It is configured to receive test request events from Speedcurve and send back the data. Be careful with the readability of the results of these environments: the less stable they are (load tests, development environments), the less usable the webperf curves will be.

Data integrated in Datadog and Google Datastudio

The Speedcurve API allows you to extract synthetic data to make them available to teams and thus create interfaces that are more usable according to usage:

• We prefer Google Data Studio for more global communications to the group
• Datadog for a finer monitoring and more exploitable in time by the development teams. It also allows you to correlate web performance data with other data such as deployment dates.
• And access to Speedcurve for expert analysis to identify optimizations.

As said above, the key to success is a common culture in the group for web performance with KPIs that everyone in the company is ready to achieve. The expertise comes from knowing the numbers and the data so that everyone can identify normal or faulty results.

Alerting via Slack

Boards are created in the Speedcurve interface to monitor each KPI on which a budget is set. A board concerns a page on a particular device. In case of overrun, an alert is now sent to a global Slack. We are in the process of onboarding the teams to associate page monitoring with dedicated perimeters.

After this first history and overview of the solutions we have implemented to monitor our web performance, we will see in a future article the issues that these data have raised and the solutions we have implemented to address them.

What’s next !

This article will be followed by two more. In the next article I will describe how we are working today. Especially now that HTTP2 is mainstream and micro-frontend are widely adopted and very well tooled at LeroyMerlin.fr.
Finally, in a third article, I will explain what are our next steps to ensure that LeroyMerlin stays ahead in terms of performance..

Are you having a KPI-overload reading this article ? This is happening to some of us too and you will read about it.

Make sure to subscribe to get notified when the next articles are released !