Frontend Performance (Part 1)

The biggest Elephant is down

The day when I joined Smartbox, the first thing I found is that the website performance is as slow as a snail. When I opened up the inspector to take a look on the network tab, I was shocked by the assets downloaded to the browser. I went through the various tools to examine the homepage, after getting dozen of blame and tips from SpeedCurve, New Relic, Google Lighthouse, WebPageTest, Chrome audit & performance, etc… There are tons of information indicating that we are pretty bad on the size, speed, support, rendering, caching, etc… I was quickly blown up by all these noises.

I decided to put all my findings aside, think again about what we are doing here. If we go back to the browser rendering behavior, we are just telling browsers to render HTML, CSS, JS, image, font, but nothing more. All different tools just give us a different angle to report the performance, it will not help to solve our problem piece by piece. Those ratings and marks from other competitors even make me feel more jealous.

There is no quantity work to just surpass our competitors, but the goal is clear, we need to load the website as fast as thunder, or as close as we can. The general principle to improve the performance are 1. keep the response as small as possible, 2. keep the request as less as possible, 3. remove the critical rendering path

This article is the first part of a series of article on frontend performance, I started with the image performance improvement and will continue with JS, CSS, HTML, and Font later

What is exactly happening on our web site? I would like to explain by giving an example. If I pick up the biggest player, we can start from the images (50% of traffic and size). On Smartbox France homepage, We have 46 image requests as the time I write this article, and the size of them varies from 50 B to 449 KB, the total size image we have to download for the homepage is over 1.5 MB! I was really sad about this finding, and they are the top things we need to change to improve the performance. As an E-commerce website, images are essential to give user’s impression about the products, especially those promotion images are the entry points for bringing up the sales.

We have been using Thumbor (image scale filter) to parse and return the image from Amazon S3 in real-time, by giving different size and quality value, we can decrease the image size to a relatively small version. We find out that images were controlled by digital so that we have to help them to use a minimum resource to achieve the maximum efficiency. We have been testing on different quality filters on the product images, from 70 to 95. We had several experiments, we were getting a low user experience by decreasing the quality filter to 80% and we were suffering a bad performance by increasing the quality filter to 95%. Finally, we all agree on 90% in general, which is higher than the industry standard 85%.

We only can solve half of the problems here, because there are two types of images, product images and promo images. For product images, we load them dynamically based on product id on our frontend, it needs our frontend developer to update the image src attribute value and any CSS background-image URL with agreed thumbor resolution and quality parameters. Promotion images are coming from web producer, we need to check and educate the team to use the correct thumbor filters in those Magento CMS blocks.

From the above process, we decrease the image size to meet our expectation by using thumbor service, if you think about loading a desktop image onto a mobile device, it is still a huge waste! More and more users are using a mobile browser to visit our website, we should not decrease their satisfaction with our amazing products. Especially, a mobile device is using less power, and the internet connection is not fast and stable, we should load even less on user mobile devices.

We could use <picture> element plus <source> tag to load different image depending on the media attribute value. First of all, we need to define the breaking point, 640px for mobile, 1240px for tablet, 1400px for desktop, the rest of the work still lies to two teams to deliver. The development team can generate the product images programmatically, and the marketing team can inject promo images through CMS. Now we are not loading the same picture on different devices anymore, 60KB on desktop, but 20KB on mobile.

Since we use thumbor to provide the smaller size of the image to improve the performance, the digital team is not happy with the blurry text on top of the gift-finder image, especially on the mobile devices. Text on top of an image is a general problem on websites, in order to scale the image smoothly, the text should be a part of the image, but it adds up the difficulty for internationalization, it also has this blurry problem when showing on a bigger resolution, it is even worse when we have a low contrast between the text with its background.

SVG technology, introduced in 1999, provides a vector image and is widely used and supported by all browsers. Especially on a mobile device, the user does not need to download colorful and meaningful promo images as desktop. SVG should play the basic informative role and the user will not lose the quality of the picture at all. Thanks to our designer from the digital team, we have decreased this image size from 500KB to 144KB on desktop and even more to 4.5KB on mobile. What a big achievement!

Are we there yet? The answer is no, we know our viewport is smaller enough on a mobile device, and it could not display all the images we have download, so why do we have to render all the images to the user if user cannot see them? Could we have a way to load the images only showing in the viewport, and with user scrolling down the screen, could we progressive load the images in the background? Yes, we can rely on the bLazy library to help us progressively load images.

Sweet! On the first-page load, we could only see the image above the folding area get downloaded, when user scrolling the pages, image calls are firing to S3 bucket to download the rest images respectively. Thanks to our Opex team, we have images cached and zipped already, and our S3 is amazon distributed close to the user. We should not have problems to load an unused image on the user’s device anymore. In this case, we are removing over 90 percent of the images that need to be downloaded after the first meaningful paint (FMP). We decrease the first meaningful paint (the blue line below) from 40 image calls to 5, and time from 4.5 to around 1.6 seconds in the end.

Before we move on, let’s run an audit on the inspector again, from the statics result, it is still complaining about the image size, and it recommends that we consider the next-generation format (.webp), which has been widely used in Chrome, Firefox, Opera. For unsupported IE browser and Safari, we need to provide fall back images as for now. Thumbor also has a webp support plugin, it seems we will get rid of the last complaint from Google. This topic is still in the investigation at this moment, hopefully, we can see this article get an update with webp support in the end.

Another issue needs to be addressed here is the lossless compression, which might not be relevant if webp get implemented, but it is worth to mention since we have been working with the digital team a lot to discuss how to upload an image. Off this topic, there are two levels of compression to serve the images on the internet, the first level of compression is to remove the space, line break, quality decrease, which we have done by using thumbor. The second level of compression is removing the metadata such as date to create, author, resolution… we call this second level the lossless compression. On S3 bucket, we have to do a sanity copy on all existing images. If we implement thumbor lossless compression plugin, for some ridiculous big images, which were introduced way back earlier before the thumbor get implemented, they will blow up the s3 server. In the end, we have to call a halt on this solution.

I hope this article can help you to understand the image performance, help you to learn what you can do to improve your website performance and enjoy the journey we have done so far. As frontend is not only about images, we have more articles coming, please stay tuned!