Optimising the Performance of a React App
Improving the site speed of our Isomorphic React App at Missguided
In 2020 Missguided began a journey to transition from a PHP and Vanilla JavaScript-based site architecture to serverless with a React front end. We are currently still in the transition phase, having made a significant amount of progress along the way. Alongside learning new things about micro-services and React, one of our main priorities is to consider the performance impact of what we create.
In 2017, Google conducted an analysis on mobile ad landing pages and found that page load time directly impacts the probability of a user bouncing and converting to varying degrees depending on just how slow the page load time was. Unsurprisingly, they found that a faster page load correlates to a higher conversion rate and a lower bounce rate. These findings were echoed in a 2020 report by Deloitte who, for retail specifically, found that even a 0.1-second improvement in speed can increase conversion rates by 8.4% and AOV by 9.2%.
With the undeniable evidence that site speed can affect the bottom line of a business, we have embarked on trying to optimise our page speed metrics through continuous efforts — all of which have had varying degrees of impact on our React App.
How we assess our site speed
There are a variety of site speed assessment tools out there but we tend to mostly use a mix of WebPageTest and Lighthouse. Lighthouse is great at giving a snapshot of how we’re doing overall whilst WebPageTest is really useful in allowing us to delve deeper into detail in order to better understand how our React app is performing and what we need to do to improve it.
Optimisations we have made so far
Of the optimisation improvements we have tried, below are the ones that have brought the biggest improvements for us.
Loadable Components
This was a real game-changer for us and made one of the most significant improvements to our whole React App’s site speed metrics. For our app, we use Server-Side Rendering and then hydrate the client-side, something which the Loadable Components library is able to handle. Although we had quite a few teething problems when implementing the library (namely with Typescript & with having to partly re-structure our app) the results were worth it.
Lazy loading images
This has had the biggest impact on our Product Listing Page (PLP) which is the most image-heavy page on our React App. In addition to this, we also utilised useMemo in order to prevent unnecessary re-renders.
Limiting requests to Third Parties
Whilst the need to use third parties for various purposes (such as analytics, A/B testing etc.) goes hand in hand with having a modern commercial website, we have tried to limit some of the calls we make to these third parties to only the pages that absolutely need them. For example for our A/B testing tool, we only make the call to the third party on pages where experiments run (such as the PLP and the Product Display Page). Nonetheless, this area is still a work in progress as we work out how and when to limit unnecessary requests.
There are also other optimisations we have made with a lesser degree of impact individually but that cumulatively have made a positive impact:
- Using async/defer for scripts that are not vital for above the fold content
- Utilising preconnect, dns-prefetch and preload
- Reducing the size of our Redux store to decrease CPU usage
- Setting default height/width to improve the Cumulative Layout Shift metric
- Switching to HTTP2
So at this point, you might be wondering how our React app performance is looking based on the above improvements we have made so far. A quick run of our PLP (which is the page that is most image-heavy and handles the largest amount of data) on Lighthouse tells us that we have made some positive improvements.
The above metrics include third parties which are called into our app, so it is arguably not a completely accurate depiction of the improvements we have made, which on the PLP, have largely focused on optimising our app rather than third parties. To properly assess our efforts, we cannot simply just run a Lighthouse report as that won’t give us an accurate assessment of our React app itself. We need to exclude third parties.
Running the Lighthouse report again, but this time excluding requests to third parties shows us a very different picture — especially on mobile.
There are two things that are evident by the latter two Lighthouse snapshots:
- The positive impact our improvements have made on our app’s performance
- The amount of impact third parties have on our app
Further optimisations on our roadmap
Whilst we have made plenty of headway with our site speed metrics, we are continuously working on improving our performance. If you want to find out what the immediate future holds for us in terms of improvements, here is a quick summary:
- Third-party optimisations
- Caching assets
- Multiplexing
- Utilising NodeJS for further server-side optimisations
If you are on a similar journey of optimising a React app, hopefully, this article has provided some inspiration.
If you would like to follow our journey of site speed improvements and re-platforming, make sure to “follow” us here on Medium.
