Rupeek’s 4-step Approach to Increase Landing Page Performance by 2X and Lead Conversion Rate by 15%!
“A good first impression isn’t just about design, but also how fast that design loads.”– Tommy Walker
At Rupeek, we continuously look for opportunities to improve the overall user experience, starting from the user landing on our landing pages until the loan transaction is complete. This article will focus on the customer experience on our landing pages and will throw light on how we have improved the conversion rate by 15%, by reducing the page load time from 5.5 secs to 3 secs.
As per this study, “A 1-second delay in page response can result in a 7% reduction in conversions”. Optimizing core web vitals like FP, FCP, and LCP provide a better user experience and improve the conversion rate.
Key Levers for Performance Improvement
Here are the top 4 pointers that helped us improve the web application performance by 2x.
1. Image optimization
2. SSR with Partial Hydration
3. Smart use of lazyload and preload
4. Cautious use of third-party scripts
1. Image optimization
Images play a vital role in the page load time of a website/application. On average, images contribute to around 40% of the overall page size. To reduce the image file size, we started using .webp images. You can find the screenshot of the browser support below -
We can see that almost all major browsers support .webp images.
Below is a file size comparison between .webp and .png
Using .webp images, we reduced the banner image size by ~65%. Similarly, we moved all our images to .webp, reducing the overall image sizes by ~60%. We used .png image as a fallback for browsers that don’t support .webp.
2. SSR with partial hydration
Sending our entire application code to end-users, including React components for every headline or text paragraph anywhere on the page, was challenging when developing pages with SSR.
As a result, we ended up with a huge bundle that needed to be fetched, parsed, and executed, resulting in a higher page load time (around 5 seconds), especially for mobile users.
To solve it, we came up with a solution called Hybrid SSR.
The basic idea behind Hybrid SSR is that instead of doing SSR and then sending our entire application to the client, only the viewport components are rendered at the server end, while the rest are rendered at the client’s side. We used the following techniques for Hybrid SSR -
Dynamic Import:
We used the inbuilt next js dynamic function to import our components dynamically and secured it from SSR by running ssr:false
import dynamic from ‘next/dynamic’
const DynamicComponentWithNoSSR = dynamic(
() => import(‘../components/hello3’),
{ ssr: false }
)
Lazy loading components using Intersectionobserver:
Using intersectionobserver API, we’ve lazyloaded the components that are not there in the viewport.
function handleIntersection(entries) {
entries.map((entry) => {
if (entry.isIntersecting) {
console.log(‘Log event and unobserve’)
observer.unobserve(entry.target);
}
});
}
const observer = new IntersectionObserver(handleIntersection, options);
observer.observe(target);
By following this technique, we reduced our initial request from ~75 to 50 and reduced the bundle size by 30%.
3. Smart use of lazyload and preload
The idea of lazy loading is simple — Defer anything that is not required in the initial load. It can be an image, CSS, or js.
To provide a better user experience and improve our First contentful paint (FCP) and LCP, we should first know what to lazyload and how to lazyload.
What to lazyload?
The content that is on the second fold (which is outside the viewport) can be lazyloaded. However, in most cases, developers lazyload or defer the images of the entire website, which takes a hit on performance and user experience.
What to Preload?
The content that comes on the first fold (which is inside the Initial viewport) can be preloaded. E.g. the banner section in LP. With this and image optimization, we reduced the LCP by 20%.
4. Cautious use of third-party scripts
Unless you know the third-party scripts loaded by your site and their performance impact, it’s impossible to know how to optimize them. Many free web speed test tools can highlight costly third-party scripts, including Chrome DevTools, PageSpeed Insights, and WebPageTest.
The abovementioned tools helped us diagnose the list of third-party scripts loaded by our site and understand which of those take the most time to execute.
How Do We Load Third-party Scripts Efficiently?
If a third-party script is slowing down your page load, you have several options to improve performance. Some of them are -
- Load the script using the async or defer attribute to avoid blocking document parsing.
- Consider self-hosting the script if the third-party server is slow.
- Consider removing the script if it doesn’t add clear value to your site.
- Consider Resource Hints like <link rel=preconnect> or <link rel=dns-prefetch> to perform a DNS lookup for domains hosting third-party scripts.
Also, we tend to add third-party scripts for improved analytical purposes, but we seldom see ‘all’ scripts helping the product make decisions. Being choosy with scripts can further improve page load time.
Here is our final score in lighthouse post the optimization of our application using the above techniques.
Post implementing the above techniques, we reduced our page load time to ~3 seconds from ~5.5 seconds and improved our conversion rate by 15% (this 15% comes with the above improvements & through other experiments).
I hope the techniques mentioned in this blog will help you to improve the performance of your application. Meanwhile, if you are interested in solving exciting engineering problems like what we did above, apply here to join our team!
Stay tuned for more updates!
