How we managed to speed up the site 3x times

By Nursultan G., 14 April 2021

About Our Customer:

mySpaShop.com(mSS), founded by Kim Matheson Shedrick, started as an extension of  Natural Resources Spa Consulting (www.NRISpa.com “NRI”) to create an eCommerce Marketplace & Lifestyle Community. With the goal of providing a platform to showcase select and distinctive lifestyle and wellness products, our mission is to bring the spa experience to the mobile and time-limited consumer, with experiential content, commerce, and community. We will establish the foremost online community to provide knowledge and product to promote well-being, fitness, balance, and health as we serve the end-consumer with a virtual SPA experience. mSS is gathering new visions, products, and experiences in holistic lifestyle, beauty, fitness, health and transformative well-being. 

 

Before we started our work:

 

The initial PageSpeed Score results of the three main pages of the site were as follows: home page – 21, collection page-14 and product page-14. Below is a screen of the results of the main page only.

 

As you can see from the results, the indicators at the beginning were all in the red zone. From our experience, the main problems of Shopify sites are apps, third-party libraries, analytics, images, and videos. But this shop had problems mainly with JavaScript (JS) files, and these files belonged to the corresponding apps.

What happens when loading and why are the scores going down? When the page first loads, all the resources are loaded, and while they are loaded, parsed, and executed by the browser, the user has to wait all this time. Because at this time, the browser does not respond to user interactions. Below, you can skip the section on how the browser receives and displays the page you are visiting if you are not too interested.

 

How does the browser display the page?

 

The client, in this case, the browser, makes a request to the server, with the fact that the client wants to get a page of the site, with all the scripts, styles, other media resources, and the document itself.

 

As soon as the browser receives the scripts and styles, it should parse them. Depending on how and where the scripts are connected, the browser will either wait for these scripts to load or start rendering.

 

 

As soon as the page is rendered for the first time, the FCP(First Contentful Paint) time is clocked, which affects the User Experience. When enough resources are loaded, the metrics use their internal algorithms to decide what is LCP (Largest Contentful Paint) and fix this time (you can read more about what other metrics are available and why they are used here).

The Pagespeed Score documentation says that the overall score of FCP and LCP is affected by 40%. If the scripts are large and run for a long time, the TTI (Time to Interactive) score deteriorates. This is because the browser can do one action at a time. Either rendering, executing scripts or responding to user events. When one is executed, the rest is blocked and expected. This spoils the user experience.

TL;DR

To summarize. The site consists of the document itself, styles, scripts, and media resources such as images, videos, etc. The browser, namely the main thread, can perform only 1 action at a time: draw the page, respond to user actions (clicks, scrolling, etc.), or execute scripts. If the scripts are very large, then the rendering and response to the user suffer, which negatively affects the overall rating.

As mentioned above, the main sore of this site was in the scripts. How we can fix this? Prioritize resources and don't download all files at once. You should try not to occupy the main browser thread at the beginning for a long time. It is necessary to allow the main thread to draw the primary page, which has a positive effect on the user experience. The user at this stage understands that something is happening and the download is going on, and not that the site is frozen. The user can also immediately start interacting with the page. To do this, we need to divide the resources into critical and non-critical and load them depending on this. On secondary resources, put a delay on loading. We have this implemented almost exactly the same way as the LazySizes library.

After we did the app analysis and identified critical resources and set delays on secondary ones, the results improved significantly.

 

Before:

 

 

Results after:

 

 

Final Result:

 

 

We can't always affect the app speed. But we can manage the order of downloads in this way and thus achieve greater performance and evaluation. So we bypass the clumsy method of simply deleting the app. However, in some cases, we have to delete the excess. For example, with a large number of connected analytics, which greatly affect the performance of the page, the delay in loading will not help. Because after they are loaded, they will always be executed in turn, and often, thus hanging in the main thread.

Let's talk about your project


Contact Us