Continuous improvement in web performance with Dareboost (by M6 Web)

Alexandre Thuriot, SEO architect, explains how he has been using Dareboost to manage and optimize performance for a leading french coupon website: radins.com. Conversion rate increased by 12%.

Context and problems of media websites.

Most of the media websites we manage at M6 Web have a business model based on monetizing page views. That requires adding a lot of third-party scripts to register, analyze and customize browsing for internet users. We’re also going to incorporate programmatic RTB advertising to add value to our audience. Even if the technology improves with header bidding and server-side bidding, we are unfortunately forced to add a lot of third-party JavaScript to our pages. On average, our pages are going to make 600 requests, weight between 2 and 6MB and have a fully loaded time of 20 to 45 s.

Dareboost Cuisineaz test

Figure 1: Analysis from June 6, 2018, on a recipe page: https://www.cuisineaz.com/recettes/blanquette-de-veau-a-l-ancienne-1548.aspx

As a result, JavaScript often represents more than 60% of the total weight of our pages. In addition to being a big consumer of requests and bandwidth, it’s also a big consumer of CPU and a growing frustration for internet users, who are more and more demanding about the reactivity of their environment and information loading.

If we implement best practices internally by managing the cache and by minifying JS files, it’s not conceivable to make third parties change. A clear example we have on all of our pages: the integration of Krux script (DMP belonging to SalesForce). Because Krux refuses to minify its JavaScript file, it imposes a pointless excess weight of 58KB on internet users.

How did Dareboost enter the life cycle of M6 Web projects?

At M6 Web, we are quite agile. We don’t just say that to look cool. We can deploy a new feature in production several times a week and, sometimes, several times in the same day.

Those who know me know that I primarily work on www.radins.com, which we use internally as a pilot site. We currently have an architecture that’s rather classic with Symphony PHP, an Ngnix server, and a Varnish cache. Just 2 years ago, the site had a significant technical debt: a bunch of services with several back offices and frameworks to manage the site, no responsive web design, no HTTPS management, etc.

In order to simplify the maintenance and the changes to our back office, we decided to redevelop the entire site from scratch: front and back. This 2-month project was a success and the starting point for our collaboration with Dareboost.

I wanted to have a rather simple monitoring tool that, first, would allow me to audit and measure the version in production and, then, the new version to be deployed, so that I could benchmark and compare the performances.

That was in June 2016 when we had an average Fully Loaded Time close to 20 seconds. In July 2016, our new technical platform went online, beginning the continuous improvement of our web performance:

continuous improvement web performance

We started with simple optimizations to put online.

Without necessarily drawing up an exhaustive list of our actions, we apply these basic rules to the site:

  • useless assets removal, inline JS and CSS removal;
  • code coverage analysis to isolate code modules for major templates;
  • JavaScript minification;
  • image compression and resize;
  • critical CSS inlining to optimize the first page display;
  • secondary images lazy-loading;
  • CSS background-images removal;
  • fonts usage optimization to get the proper format accord to browser support;
  • Gzip / Deflate compression;
  • and Domain Sharding.

As these are mostly cosmetic items, my requirements were taken into account rather quickly and published in Production. We then assess our progress by analyzing the Speed Index. From the beginning, we set ourselves the goal of dropping under the 1000 mark on desktop computers.

A goal we’ve reached quickly.

Speed index under 1000

Site HTTP activation in April 2017

Our SEO needs persisted and, in April 2017, we decided to migrate the site to HTTPS. With an internal host (Odiso), it was a piece of cake. Once the HTTPS migration was complete, we activated HTTP/2 and HSTS support in our servers’ configuration. Everything was going fine then, despite a small slow down, as you might expect, caused by the SSL negotiations.

https activation

At first, we were only concerned with the desktop index speed, but today we’re actually looking to optimize the Start Render and the render time to be Visually Complete.

Do you have to switch to AMP for better mobile performance?

To keep up with our growing mobile audience, in September 2017, we started to differentiate between mobile and desktop performance. In September 2016, we also implemented AMP page templates to test the technology pushed by Google.

On sites like CuisineAZ.com, which content highlighting through carousels integrated into Google’s SERP, there is no doubt about the gain. It’s so easy, and the increased visibility is significant.

cuisineaz carousel

Source A: Presentation of results in the form of an AMP carousel in the world of cooking recipes.

Similarly, on sites that deal with current topics. It became an obligation, in order to be eligible in the “Top Stories” box at the top of the results pages.

Top headlines

As for other page templates, it’s possible to weigh whether it’s essential or not to shift to AMP. With a little time and work, it is possible to achieve the same results as an AMP page. That will depend on the budget allocated and the teams’ maturity when addressing the web performance best practices. If you don’t possess the required skills, AMP will be an easy solution that will give you a way to “hide the problem” from internet users.

With Radins.com, we have mobile performances comparable to, and sometimes better than, our responsive mobile version and its AMP equivalent.

AMP Google vs AMP domain

With the above example, you can see, in dark blue, our AMP version served by our domain. The AMP version served by Google is in light blue. Regardless of the metric considered – the Time To First Byte, the Start Render, the Visually Complete or the Fully Loaded – our AMP page on Radins.com is better than Google’s AMP version.

Now, if I compare the AMP version of Google with our reactive version, we are always better, whatever the metric.

Responsive vs AMP

However, Google outdoes us by benefiting from its own platform to perform a preload: AMP is therefore only fast starting from the SERP.

We cannot compete with that, but with a Start Render under 1 second and a Visually Complete in less than 3 seconds, I think we can do without AMP on this type of page. The page loading experience for our internet users is very good.

What problems were detected?

The main difficulty consists of integrating all of the actors into the process. Ultimately, the web performance must be a priority for everyone. The whole value chain is involved: SEO, devs, admins, products, UX, clients, etc.

We appreciate the accessibility of Dareboost’s recommendations, as well as the score, which allows us to set initials goals and measure progress. Next, as with all tools, the important thing is the loading experience, not the score. I hear a lot of people say they do whatever they can to get 100 / 100 on Google PageSpeed Insights. And I’ve seen sites that really do get 100 / 100 PSI, but their Start Render is 3s and the page is visually complete after 10s. I usually reply that this website is not fast, it is just optimized for PSI.

It’s important to consider all feedback, but always judge the user experience before giving value to a third-party tool. And I won’t list them all here, but out of PSI, Webpage Test, GtMetrix and LightHouse, Dareboost is by far the most complete.

While I do have a natural preference for technical aspects, I am not a network and security expert. With Dareboost, I’ve discovered some optimizations I would never have been able to come up with (Content-Security-Policy, MIME Sniffing, etc.).

To return to the integration of the whole team in the project, it is essential to communicate clearly on objectives, actions, and results to challenge, motivate and value everyone’s actions.

When the whole team is committed, we are surely moving in the right direction. We conducted A/B tests to evaluate the conversion differences in our pages.

We managed to reduce our bounce rate by 25%

bounce rate change

We increased our conversions by 12%

conversion change

Fact: performance optimization improves our business and gives value to our work tools. When you work in web design and spend your day on a slow website, it can be demotivating. Speed adds value at all levels.

We have been fully committed to the continuous improvement of our web performance for 1 year. The added value generated by our improvements is undeniable.

And tomorrow, what are the next steps or projects to further improve web performance?

Like many websites, we use JQuery, which weighs on average 80Kb. While the library is very popular and often cached on CDNs, there are alternatives to JQuery such as Vanilla JS, for example, in other words going back to JavaScript without a framework. For a lot of processes that uses the DOM tree, Vanilla JS offers significant gains:

Vanilla JS

However, even if the expected gains are attractive, we still hesitate to change the core of our JavaScript base.

Another change I would like to test would consist of using Brotli, a compression format developed by Google’s teams at Mountain View. According to different studies, the gains would be close to 25% of the size of the files.

To go even further in optimizing the bandwidth, I would change the format of my images for webp. This image format, also pushed by Google, can reduce image weight by 70%. As it’s not compatible with all browsers, we would have to implement a server rule in the request’s Accept header or use a support requirement for a source within a picture. That, however, would double the size of our image server cache. Given our current audience, that’s not a cost we currently wish to commit to.

With the increased power of RUM (Real User Monitoring) solutions and CrUX, we’re currently working on API User Timing in order to have customized indicators more fitted to our business. We also plan to implement PWA (Progressive Web App) recommendations to also offer uses in offline mode.

Lastly, I’ve recently been addressing e-commerce issues on Déco.fr, which opens with a decoration, home and garden marketplace. My new challenge is to reach, with the Magento architecture I’ve discovered, the same performance level as an editorial website like Radins.com.

Quick Introduction

Alexandre ThuriotFor the last 3 years, Alexandre Thuriot has been an SEO architect at M6 Web, the Internet advertising arm of Groupe M6, better known for its TV channels. M6 Web is developing the TV 6Play.fr catch-up service in-house and the monetization of around fifteen themed web portals such as Radins.com, CuisineAZ.com, Déco.fr and Turbo.fr.

Having completed his master’s degree in web development, he joined a web team at Groupe RTL (acquired by M6 at the end of 2017) and worked on some large web portals like RTL.fr in 2006. Alexandre is a self-taught SEO expert who discovered the sector whilst implementing the recommendations of an agency. Passionate about SEO to the point of making it his main activity, he has always remained “employed with the advertiser” and has belonged to the Technical SEO team for 6 years.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.