There are about 7 lakh suppliers running their businesses in our ecosystem. Between them, there are approximately 1 crore products listed on the Meesho platform.

That’s a lot of content to display - both images and text. And yes, all are packaged and delivered to you through our 14.5 MB App and lightning-fast website.

This is a story of how we optimised our website’s performance to keep up with our growing popularity 😎

Let's go back in time ⏳

We started our journey with an android app in 2016, along with a basic website, where sellers were getting information on how Meesho operates and how they can use the platform.

Fast forward to January 2021, we had about ~ 52 million app downloads, averaging 7 million monthly hits on the website. With this growing popularity, there was an increasing need to make sure we give our web users the full app experience.

What it meant was - displaying about 1 crore+ product (read images) along with adding a transaction flow to the website.

With our “Speed Over Perfection” mantra driving us, the frontend team delivered the authentication and checkout functionalities in just three weeks! However, the performance of the website took a back seat.

Because more functionalities meant more load time.

The Theory 📝

As an e-commerce company, visual assets play a key role in determining the size of our web page. From product listing and display pages to customer reviews, we have images all over our web application.

And the size of these images majorly influenced our page performance. With ~ 70TB worth of assets, our existing web implementation could only serve JPG and PNG images. These images were heavy in size and needed to be optimised.

But, more assets meant more load time.

The Practicals 👨‍🔬

We went back to the drawing board. "How do you optimise for image size?" was the problem statement.

We found our solution in an image format developed by Google that provided ~ 30% size reduction as compared to its counterparts for the same quality (thanks to its superior compression) was an ideal choice for us.

Hello, WebP format 😎

Why WebP 🤷🏻

The issue with traditional image formats like JPEG and PNG lies in their compression, resulting in a tradeoff between the size of the image and quality.

Take the case of JPEG, where the clarity of the image is lost while reducing the image size. And in the case of PNG lossless compression, it does preserve the clarity of the image but does not have the same impact on image size as JPEG.

WebP lossy compression, on the other hand, employs techniques such as prediction coding (which assist in more accurately adjusting the pixels in an image) and entropy encoding to make the compression more efficient and effective, resulting in smaller file size. Even so, the image quality remains unchanged, but the size of the image is reduced.

Needless to say, with stellar compression, smaller image size and support from most modern browsers (Chrome, Mozilla, Opera Mini, and UC Browsers), WebP was one of the perfect choices for us.

The next step was to solve three basic questions:

How to deliver content when browser requests are made?

When a browser requested assets, we used a Content Delivery Network (CDN) to serve the static content rather than our own website servers. This was faster because a CDN cached all website assets to their servers (distributed globally). Acting as proxies, the CDN would pick the server that was physically closest to the user, allowing content to be delivered through a faster network nearby.

2. How to convert other image formats into WebP?

The battle was only half over with the content ready to be delivered via CDN. We had to figure out how to convert these existing JPEG and PNG images into WebP. That’s where the Lambda function came to the fore. (With Lambda, you can run code for almost any type of application or backend service with zero administration.)

Whenever the user accesses a product image, the request hit’s on the CDN with the WebP extension; the CDN cache miss triggers an invocation of our code on lambda.

This generates the WebP of the image using the original JPEG and then is returned to the caller. From then on, all subsequent calls for that product’s image in WebP format is being served from the CDN itself.

Side note: We avoided on-the-fly conversion (of other image formats into WebP) using the NPM library because for each and every user request, the next-optimized library would convert the image into WebP. This eventually would take time to load on the client (fetching jpeg images from server + on client conversion into WebP), resulting in our LCP getting impacted.

3. But what if the browser didn't support the WebP format?

When a browser did not recognise the WebP format, we served JPEG and PNG images, which helped us catch the exception cases.

The Impact 🎯

We achieved:

10% increase in PageSpeed score
~20% reduction on image individual size
~15% optimisation of network load
3% decrease in load time

All of these metrics translate into faster performance and a better user experience.

Fun fact: We had around ~ 31 million people who visited our website last month - July 2022.

Want to explore our website yourself? Click here!

Sidenote: To ensure faster load times, we primarily use WebP image format, but we also use a mix of JPEG and GIF. Here's a look at our website.

Found this interesting? Check out more blogs from our vault. 😄If you want to work on a rapidly evolving landscape with the best talent in India, head to our careers page to check out our openings!

Credits

Editing 📝 Mangala Dilip (Twitter, LinkedIn)

Creatives 🧑🏻‍🎨 Ved Sarkar (Portfolio, Linkedin)