The Problem Statement
In the rapidly evolving fintech domain, web applications play a critical role in delivering financial services to customers. Our customers started reporting that our web applications are taking a very long time to load for the first time. In order to give the best experience for our customers as well as to reduce incoming supporting tickets regarding the loading time, we wanted to improve the performance of our web applications across the Yubi platforms.
Why is Web App’s Performance important?
Performance plays a major role in the success of any online platform. Slow sites have a negative impact on revenue, and fast sites are shown to increase conversion rates. The BBC found they lost an additional 10% of users for every additional second their site took to load.
“Performance has directly impacted the company’s bottom line.” – Pinterest
The speed of a web app directly impacts user experience, as faster loading times and responsiveness lead to improved user satisfaction and engagement, while slow performance can frustrate users and drive them away.
The Lighthouse Web Performance Tool
There are a handful of website performance testing tools available in the market like GTMetrics, Pingdom, Lighthouse etc. We settled with Lighthouse, because of its ability to assess the performance of web applications with authenticated pages securely and also it’s an open source tool.
Lighthouse churns out performance scores based on key metrics like FCP, Speed Index, TBT, LCP, and CLS, each carrying its own weightage.
Our quest to enhance the performance of Yubi Applications began with an in-depth audit using Lighthouse. Our primary focus was on improving these metrics in order of their importance.
As you take a glimpse at the Lighthouse report, the ‘Opportunities’ section has detailed suggestions and documentation on how to implement them. Additionally, the Diagnostics section lists additional guidance that developers can explore to further improve their performance. So let’s dig deeper on how we improved each metric to boost the overall performance score!
Metrics, and possible ways to improve them
Let’s take a look at what these web performance metrics mean in detail, and how we can improve them practically via code.
Total Blocking Time (30%)
Total Blocking Time (TBT) measures the total amount of time that a page is blocked from responding to user input, such as mouse clicks, screen taps, or keyboard presses. The sum total is calculated by adding the blocking portion of all long tasks between First Contentful Paint and Time to Interactive.
Any task that executes for more than 50 ms is a long task. The amount of time consumed after 50 ms is the blocking portion.
Improving the TBT is done by:
- Removing unused JavaScript by uninstalling unused third party components/libraries and deleting the old or unused components/modules.
- Minimizing main-thread work by reducing execution time of CSS and JS, which can be achieved by optimizing the overall JS and CSS bundle size
- Replacing large JavaScript libraries with smaller alternatives
Largest Contentful Paint (25%)
Largest Contentful Paint (LCP) represents how quickly the main content of a web page is loaded. Specifically, LCP measures the time from when the user initiates the loading page until the largest image or text block is rendered within the viewport.
LCP can be improved by reducing the time spent transferring the bytes of the resource over the network to the user’s device
- Compress and resize the images. Choose WEBP, JPEG or PNG formats over SVG for large sized detailed illustrations.
- Preload critical resources, eg.: <link rel=”preload” src=”logo.png” />
- Prefetch to third-party origins eg.: <link rel=”dns-prefetch” href=”https://api.amplitude.com” />
- Remove unused font imports
- Reduce render-blocking stylesheets by reducing initial CSS load size
Cumulative Layout Shift (25%)
CLS (Cumulative Layout Shift) is a measure of the largest burst of layout shift scores for every unexpected layout shift that occurs during the entire lifespan of a page.
Layout shifts can be distracting to users. Imagine you’ve started reading an article when all of a sudden elements shift around the page, throwing you off and requiring you to find your place again. This is very common on the web, including when reading the news, or trying to click those ‘Search’ or ‘Add to Cart’ buttons. Such experiences are visually jarring and frustrating. They’re often caused when visible elements are forced to move because another element was suddenly added to the page or resized.
To provide a good user experience, sites should strive to have a CLS of 0.1 or less for at least 75% of page visits as recommended by Google.
CLS can be improved by taking care of following items:
- Statically reserve space for late-loading content, this can be as simple as adding a min-height styling to reserve space for containers, ads & iframe embeds.
- Always include width and height size attributes on your images and video elements in your above the fold contents.
First Contentful Paint (10%)
FCP (First Contentful Paint) measures how long it takes the browser to render the first piece of DOM content after a user navigates to your page. Images, non-white <canvas> elements, and SVGs on your page are considered DOM content; anything inside an iframe isn’t included.
To provide a good user experience, sites should strive to have a First Contentful Paint of 1.8 seconds or less as recommended by Google based on data from the HTTP Archive.
FCP score can be improved by
- Preload web fonts, eg.: <link rel=”preload” as=”font”>
- Specify @font-display: swap; when defining custom fonts to avoid showing invisible texts when fonts are loading
Speed Index (10%)
Speed Index measures how quickly content is visually displayed during page load. Lighthouse first captures a video of the page loading in the browser and computes the visual progression between frames. The following helps to improve the speed index as recommended in this blog post by Google web performance team,
- Minimize main thread work
- Reduce JavaScript execution time
- Ensure text remains visible during webfont load
Results
After improving all the above five metrics, the overall performance score of our Web applications improved drastically. On average, our apps were having Lighthouse scores in the range of 40% to 50% before optimization. After this optimization, the scores improved significantly up to 85% – 95% range.
In conclusion, the journey to supercharged web app performance is not only about numbers but also about delivering an exceptional user experience. By implementing these strategies, we’ve not only improved our metrics but also ensured our users enjoy faster, more responsive applications.
