Saurabh Rajpal on web.dev

Economic Times quest for fixing INP

2023-05-10T00:00:00Z

Interaction to Next Paint (INP) is a metric that assesses a website's responsiveness to user input. Good responsiveness means that a page is quick to respond to user interactions. The lower a page's INP is, the better it is able to respond to user interactions.

The fuzzy beginning #

When Google initially introduced INP as an experimental metric with the potential to evolve into one of the Core Web Vitals metrics, the Economic Times team took up the challenge to fix it before it graduates into one, since providing a world class user experience is crucial to our core business values.

INP has been one of the most difficult metrics to solve thus far. In the beginning, it was unclear on how to measure INP effectively. What made it more difficult was the lack of community support—including most Real User Monitoring (RUM) providers not supporting it yet. However, we had Google RUM tools like Chrome User Experience Report (CrUX), the web-vitals JavaScript library, and others supporting it, which gave us a sense of where we stood while we were evaluating the path ahead. Our INP was close to 1,000 milliseconds at the origin level when we started.

One thing that emerged while fixing INP in the field was that one of the lab metrics to target could be Total Blocking Time (TBT). TBT was already well documented and supported by the community. Despite already meeting the thresholds for Core Web Vitals, however, we weren't doing as well on the TBT front, as it was over 3 seconds when we began.

What is TBT, and what steps did we take to improve it? #

TBT is a lab metric that measures the responsiveness of a web page to user input during page load. Any task that takes more than 50 milliseconds to execute is considered a long task, and the time after the 50 millisecond threshold is known as the blocking time.

TBT is calculated by taking the sum of the blocking time of all long tasks during page load. For example, if there are two long tasks during load, the blocking time is determined as follows:

Task A takes 80 milliseconds (30 milliseconds more than 50 milliseconds).
Task B takes 100 milliseconds (50 milliseconds more than 50 milliseconds).

The page's TBT will be: 80 milliseconds (30 + 50). The lower the TBT, the better, and TBT also correlates well with INP.

Here’s a quick lab comparison of our TBT before and after taking steps to improve it:

The main thread during startup before optimizing TBT. The TBT is 3,260 milliseconds.

The main thread during startup after optimizing TBT. The TBT is 120 milliseconds.

Minimize main thread work #

The browser’s main thread handles everything from parsing HTML, building the DOM, to parsing CSS and applying styles, as well as evaluating and executing JavaScript. The main thread also handles user interactions—that is, click, tap, and keypresses. If the main thread is occupied with doing other work, it may not respond to user inputs efficiently, and may lead to a janky user experience.

This was the most difficult task for us, since we have our own algorithms to detect user identity for serving ads based on subscription status and third party scripts for A/B testing, analytics, and more.

We took small steps at first, such as de-prioritizing loading of less critical business assets. Second, we used requestIdleCallback for non-critical work, which can help to reduce TBT.

if ('requestIdleCallback' in window) {
  this.requestIdleCallbackId = requestIdleCallback(fetchMarketsData.bind(this), {timeout: 3000});
} else {
  fetchMarketsData(); // Fallback in case requestIdleCallback is not supported
}

Specifying a timeout is recommended when using requestIdleCallback, since it makes sure that if the given time is elapsed and the callback is not already been called, it executes the callback immediately after the timeout.

Minimize script evaluation time #

We also lazy loaded third party libraries using Loadable components. We also removed unused JavaScript and CSS by profiling the page with the coverage tool in Chrome DevTools. It helped us to identify areas where tree shaking was needed to ship less code during page load, and therefore reduce the initial bundle size of the application.

Reduce DOM size #

Per Lighthouse, large DOM sizes increase memory usage, causes longer style recalculations, and produces costly layout reflows.

We reduced the number of DOM nodes in two ways:

First, we rendered our menu items at the user’s request (on click). It decreased the DOM size by around 1,200 nodes.
Second, we lazy loaded less important widgets.

Because of all these efforts, we reduced TBT significantly, and our INP was reduced accordingly by almost 50%:

At this point, we nearly ran out of easy wins to further reduce TBT (and INP by proxy), but we knew we had a lot of room for improvement. This is when we decided to upgrade our custom-built UI boilerplate to the latest version of React along with Next.js to make better use of hooks to avoid unnecessary re-rendering of components.

Due to more frequent updates and comparatively lesser traffic as compared to the other portions of the website, we began to migrate our topic pages to Next.js. We also used PartyTown for offloading additional heavy main thread work to web workers, along with techniques like requestIdleCallBack for deferring non-critical tasks.

How has improving INP helped The Economic Times? #

Current TBT and INP on origin #

At the time of publishing this post, the TBT for our origin was 120 milliseconds, down from 3,260 milliseconds when we began our optimization efforts. Similarly, the INP for our origin was 257 milliseconds after our optimization efforts, down from over 1,000 milliseconds.

INP CrUX trend #

The traffic received on topic pages represents a significantly smaller portion of overall traffic. Hence, it was an ideal place for experimentation. The CrUX results along with the business outcomes were very encouraging, and led us to expand our efforts across the entire website to reap further benefits.

Akamai mPulse TBT Analysis #

We use Akamai mPulse as our RUM solution, which measures TBT in the field. We observed a consistent decrease in TBT, clearly mapping to the outcomes of our efforts to reduce INP. As can be seen in the screenshot below, TBT values eventually dropped from approximately 5 seconds in to around 200 milliseconds in the field.

Business outcome #

Overall, our efforts to bring down TBT by 30 times, along with migrating to Next.js helped us reduce INP nearly by 4 times, which eventually led to a 50% decrease in bounce rate and 43% uplift in pageviews on topic pages.

Conclusion #

To summarize, INP extensively helped to determine runtime performance issues on parts of the Economic Times website. It has proven to be one of the most effective metrics to positively impact business outcomes. Due to the very encouraging numbers we've observed as the result of this effort, we are motivated to scale our optimization efforts to other areas of our website and reap additional benefits.

How redBus improved their website's Interaction to Next Paint (INP) and increased sales by 7%

2023-05-10T00:00:00Z

The web and its capabilities are evolving at a fast pace. You can now build rich and full-featured experiences on the web that can achieve much of what native applications can in terms of capabilities.

JavaScript is a primary driver for interactivity across the web, but if it's not used with care, interactions can feel sluggish, and lead users to perceive your website to be non-responsive or altogether broken. Thankfully, the Interaction to Next Paint (INP) metric was created to address this specific user experience problem.

INP measures all interactions made with a page during its lifecycle, and reports a single value that is representative of a website's speed in responding to user inputs. Simply put, if a page's INP is at or below the good threshold, all interactions made with a page can be said to be reliably fast.

redBus, a bus booking and ticketing website based in India, undertook a substantial effort to improve their website's INP, even during the time when it was still considered an experimental metric. As a result of their efforts, they were able to increase sales by 7%, illustrating once again the relationship between web performance and business health. Here's what redBus did to improve their website's INP.

Top goals #

When redBus set out to optimize their website's INP, they had three goals in mind:

Provide a better user experience for users by focusing on interaction latency regardless of network speed and device capabilities.
Optimize their website to keep interactions as fast as possible.
Ensure that responses from their API were as light as possible to ensure fast data transfer to the front end.

The journey #

redBus categorized interaction latency in two ways:

Interaction latency caused by blocking JavaScript on the client. When interactions use excessive JavaScript that blocks the main thread, rendering is delayed, and this affects a page's INP.
Network latency caused by API calls. While network activity is not something that INP measures, an interaction reliant on a call to a remote API can feel sluggish on slower networks, or if requests result in large responses.

redBus was initially quite confident that the INP for their website would be good, but the Real User Monitoring (RUM) data for this metric at the 95th percentile told a different story.

How redBus measured INP #

redBus relied on the web-vitals JavaScript library built by Google to track not just INP, but all important user experience metrics for all pages across their website. In addition to the web-vitals JavaScript library, redBus used ELK to analyze INP data that was collected on the front end.

However, how you track your website's INP in the field may be quite different from how redBus approached the problem. We highly recommend that you read about how to find slow interactions in the field to learn how to best to track INP for your websites, and subsequently how to reproduce them in the lab before you begin optimizing interactions.

Once redBus had a system in place for tracking INP, they were able to analyze the data in order to gain a better understanding of where slow interactivity was present.

A screenshot of the logging system used by redBus to analyze INP values collected from the field. (Click for a higher resolution version of this image.)

Use cases #

When users search for fares on the redBus website, they can change the date on the search page to filter selected fares for the desired destination. The interaction to change the date on this page was slow, and was a cause of poor INP.

Additionally, when a user scrolls through fares, additional fares are lazy-loaded from the API. Though scrolling itself isn't factored in how INP is measured, the scroll event listener itself schedules a lot of work that must run on the main thread. This work was causing contention on the main thread that increased interaction latency, leading to poor INP on the search page.

The lazy-loading behavior used to load additional fares from the API on scroll. (Click for a higher resolution version of this video.)

How redBus optimized INP for the search page #

To improve the search page's INP, redBus made several optimizations:

The scroll event handler was debounced in order to reduce the amount of times the event callback would fire in a given period. By lowering the frequency in which scroll event callback ran, the main thread was able to respond more quickly to user interactions on the search page.
The resulting rendering work was prioritized by using a requestAnimationFrame callback. requestAnimationFrame tells the browser that the work in the callback must be done before the next frame.

Before: scroll handlers firing without debouncing applied to the event callback. A considerable number of blocking tasks on the main thread are present, which will delay interactions.

After: scroll handlers firing with debouncing applied. The scroll event callbacks fire less frequently, giving the main thread more opportunities to respond to user interactions.

Additionally, the following further optimizations were made to the search results page:

New batches of results were fetched on the second to last card on the search results page in order to improve the user experience and visual performance by triggering lazy loading earlier.
Fewer results were fetched on each network call during lazy loading. By reducing fetches from 30 to 10 results, a reduction in INP ranges at 870 to 900 down to 350 to 370 were observed.

The lazy-loading behavior used to load additional fares from the API on scroll. (Click for a higher resolution version of this video.)

While these changes significantly improved the INP of the search page, there was still the problem where the change event on the search page's input fields would call an expensive reducer function to update the user interface. This resulted in unnecessary rerendering of the user interface, which affected the page's INP.

INP values reported in the console while the user types in an input field. The resulting INP value of 344 observed in a lab setting falls within the "need improvement" thresholds. (Click for a higher resolution version of this video.)

To optimize this interaction, redBus managed the state of input components locally and synced it with the Redux store only when an input's blur event was fired. This change reduced the number of rerenders and eliminated unwanted rerendering of the user interface by calling the reducer less frequently.

Improved INP as a result of calling the reducer less frequently on an input field change. (Click for a higher resolution version of this video.)

With this change, the page's INP improved by 72%, resulting in a faster and smoother user experience that users are more likely to engage with.

Business impact #

The relationship between business health and page performance is well-known. Though INP is a relatively new metric compared to other Core Web Vitals, redBus observed better business outcomes by focusing on improving this important user-centric performance metric. The result was a 7% overall increase in sales.

In short, INP helped to paint a picture of runtime performance issues on the redBus website. With the knowledge that there were improvements to be made, redBus was able to observe the problem, reproduce it, and use that crucial information to make optimizations that were beneficial to redBus and its business.

The business impact of Core Web Vitals

2021-05-18T00:00:00Z

Are you struggling to convince your stakeholders to adopt Core Web Vitals? Or are you wondering if it actually helps your business? This article will help you understand how Core Web Vitals correlate with key business metrics by exploring examples of companies which have already seen positive impact for their users and business.

If you prefer video, check out this talk from Google I/O:

Why Core Web Vitals matter to your users and business #

Different stakeholders in an organization can have different priorities. Core Web Vitals can bring them all on the same page by focusing on optimizing user-centric metrics and the resulting business growth.

The path to good Core Web Vitals can vary from site to site depending on where they are in the performance journey and how complex the site design is. It can range from grabbing the low-hanging fruit and getting meaningful results; to implementing complex solutions that fix challenging issues. Regardless of the amount of time spent, decision makers should treat this as a long term investment into growth of their business. Delivering a fast and seamless navigation experience delights users and helps turn them into loyal and returning customers. For product managers, performance should be an important criteria that defines the quality and success of new product features. And product excellence and working on interesting challenges improves developer satisfaction as well.

While Core Web Vitals as a ranking signal gives additional motivation to invest time in performance, adopting Core Web Vitals has many other short- and long-term benefits beyond ranking. Let's explore several case studies of global and local brands who adopted Core Web Vitals (before it had impact on ranking) because of its focus on user experience.

Case studies #

Vodafone #

Vodafone (Italy) improved LCP by 31% to achieve 8% more sales.

Techniques #

Server Side Render the critical HTML.
Reduce render blocking Javascript.
Image optimization techniques.
Resize hero image; defer non critical resources.

Key learnings #

A/B testing is the best way to measure the meaningful impact.
A/B should be a server side one.

iCook #

iCook improved CLS by 15% to achieve 10% more ad revenue.

Techniques #

Less variability in ad unit size and fixed size ad slots pre-allocated in UI.
Optimized ad script loading logic to prioritize header bidding and defer non-critical JS.

Key learnings #

Fill rate might get impacted but eventually revenue uplifts with ads viewability improvement.

Tokopedia #

Tokopedia improved LCP by 55% and saw 23% better average session duration.

Techniques #

Server-side render (SSR) LCP element.
Preload LCP Element.
Image optimization (compression, WebP, lazy load non-critical images).

Key learnings #

Built a performance monitoring dashboard to monitor progress and impact across teams.
Experimented with different rendering techniques (for example, SSR LCP element vs SSR above the fold content vs Full client-side rendering).

Redbus #

CWV fixes contributed to 80-100% mobile conversion rates(mCVR) and significant domain ranking uplift across Redbus’s global market properties.

Techniques #

Fixing slots for page components and removing unoptimized tag insertion scripts improved CLS.
Optimizing third-party scripts and building microservices with single responsibility principle significantly reduced TTI and TBT.

Key learnings #

Reducing CLS from 1.65 to 0 significantly uplifted their domain rankings globally.
Reducing TTI from around 8 s to around 4 s and TBT from around 1200 ms to around 700 ms contributed to an 80-100% increase in mCVR across global properties.
Using RUM tools helped capture the real world performance metrics in lower tier markets.
Adopting a performance culture is very important to avoid regression. This also improves team productivity thanks to optimized code, faster releases, and fewer production issues.

The case studies above show that you can achieve a lot by adopting best practices and implementing quick wins. Here are a few more real-world examples of this point.

The above results were achieved by grabbing low hanging fruit such as:

Image optimization	JavaScript optimization	Ads and dynamic content
Using WebP image format	Deferring third-party JS	Reserving space for ads above-the-fold
Using image CDNs	Removing render-blocking and unused JS	Setting height for dynamic content
Compression	Lazy loading non-critical JS
Deferring non-critical images	Preloading critical JS
Preloading hero images
Specifying aspect ratio

For more best practices, check out the Web Vitals guidance. Use PageSpeed Insights to audit your website and get actionable recommendations immediately.

There are several more global brands which have also benefited from investing in Core Web Vitals.

Tencent Video saw 70% better CTR for videos by passing Core Web Vitals.
Cdiscount improved all 3 metrics which contributed to 6% revenue uplift in their Black Friday sale.
Wix increased mobile origins passing Core Web Vitals by over 250% year-on-year.
Nykaa found that a 40% improvement in LCP led to 28% more organic traffic from T2/T3 cities.
NIKKEI STYLE's 18% LCP improvement resulted in 9% more pageviews per session.
NDTV gained a 50% better bounce rate after halving LCP, along with other product changes..
Agrofy Market's 70% better LCP correlated to 76% reduction in load abandonment..
Flipkart achieved 2.6% reduction in bounce rate by improving Core Web Vitals metrics.
Ameba Manga improved the number of comics read by 2-3 times by improving the CLS score 10 times.
Yahoo! Japan fixed CLS which led to a 98% reduction in poor pages and 15% uplift in page views per session..
AliExpress improved CLS by 10 times and LCP by double, which translated to 15% lesser bounce rates.
GEDI saw 77% reduction in CLS and an 8% reduction in bounce rate.

How can you get started now? #

Step 1: Start measuring #

Start by measuring field data for your site using Real User Monitoring (RUM) tools. There are various Google and third-party (3P) RUM tools available already.

Google RUM tools #

Search Console
PageSpeed Insights
web-vitals JavaScript library
Chrome User Experience Report (CrUX)

Third-party RUM tools #

Cloudflare
New Relic
Akamai
Calibre
Blue Triangle
Sentry
SpeedCurve
Raygun

Pick the tool that works best for you. You can go a step further and integrate with Google Analytics 4 to correlate Core Web Vitals with your business metrics.

Step 2: Convince your stakeholders #

Educate your stakeholders about the importance of adopting Core Web Vitals to improve user experience and its correlation with company's business metrics.
Get a sponsor internally to start a small experiment.
Create a shared goal among stakeholders to improve Core Web Vitals across teams.

Step 3: Deliver successful implementation using these tips #

Prioritize: Pick a page with high traffic and/or conversion significance to deliver meaningful results (for example, ads landing page, conversion page, or popular pages).
A/B Test: Use server side testing to avoid any rendering cost. Compare results between optimized and unoptimized versions.
Monitor: Use continuous monitoring to prevent regressions.

Lastly, we believe that performance is a journey not a destination. On that note, we plan to keep this article updated with the latest case study highlights. If you also have a compelling business win and would like to be featured in this article, submit a content proposal.

How Goibibo's PWA improved conversions by 60%

2020-09-29T00:00:00Z

Goibibo is India's leading online travel booking portal. By building a full-featured and reliable Progressive Web App that matched the capabilities of their iOS and Android apps, Goibibo achieved a 60% increase in conversions (compared to their previous web flow).

60_%

Increase in conversions

20_%

Increase in logged-in users

Highlighting the opportunity #

In their journey to improve user experience, Goibibo noticed a few trends:

With users either already shifted or quickly shifting to mobile, their initial strategy towards mobile web was to build a lightweight and functional application. This worked, with search-to-details-page conversions equalizing on web and iOS/Android, but the iOS/Android apps won in all further steps of the conversion funnel.
There were significant drop offs at the payment stage of the PWA compared to their iOS/Android apps. This was when they decided to invest in their PWA with the goal of letting users experience the same UX on their PWA as on their iOS/Android apps.
They also noticed nearly 20% of their users were starting a session on the web and converting on the app. This reiterated their belief that a chunk of users will go untapped without an aligned PWA and iOS/Android app strategy.

The tools they used #

Contact Picker API #

Nearly 15% of Goibibo's logged-in users make bookings for family or friends on the mobile web. Goibibo used the Contact Picker API to enable PWA users to fill in forms on behalf of others hassle-free.

WebOTP #

Because secure authentication is a big challenge in India, Goibibo used the WebOTP (One-Time Password) API to reduce sign-in friction on their PWA.

To bridge the gap between their web and iOS/Android experiences, Goibibo adopted the Web Share API to make it easier to share links, text, or files around hotel details, train availability, and so on.

Push notifications #

Goibibo used web push notifications to retarget bounced users with relevant updates like flight fare alerts and other customized content.

How new web capabilities improved Goibibo's funnel #

Overall business results #

Iterations to PWA interfaces resulted in a 60% jump in conversion rate (compared to the previous mobile web flow) and delighted users.
New web capabilities improved UX and caused a 20% increase in logged-in users (who convert 6x more).

We always strive for seamless user experience and in turn better conversion rates. We saw improved user engagement and better conversion rates on PWA than on the original mobile web flow. Hence, investing in PWA is critical to our success and if we had not, it would have cost us a fortune.
Rithish Saralaya, VP Engineering, Goibibo

Check out the Scale on web case studies page for more success stories from India and Southeast Asia.

Saurabh Rajpal on web.dev

Economic Times quest for fixing INP

The fuzzy beginning #

What is TBT, and what steps did we take to improve it? #

Minimize main thread work #

Minimize script evaluation time #

Reduce DOM size #

How has improving INP helped The Economic Times? #

Current TBT and INP on origin #

INP CrUX trend #

Akamai mPulse TBT Analysis #

Business outcome #

Conclusion #

How redBus improved their website's Interaction to Next Paint (INP) and increased sales by 7%

Top goals #

The journey #

How redBus measured INP #

Use cases #

How redBus optimized INP for the search page #

Business impact #

The business impact of Core Web Vitals

Why Core Web Vitals matter to your users and business #

Case studies #

Vodafone #

Techniques #

Key learnings #

iCook #

Techniques #

Key learnings #

Tokopedia #

Techniques #

Key learnings #

Redbus #

Techniques #

Key learnings #

How can you get started now? #

Step 1: Start measuring #

Google RUM tools #

Third-party RUM tools #

Step 2: Convince your stakeholders #

Step 3: Deliver successful implementation using these tips #

How Goibibo's PWA improved conversions by 60%

Highlighting the opportunity #

The tools they used #

Contact Picker API #

WebOTP #

Web Share API #

Push notifications #

How new web capabilities improved Goibibo's funnel #

Overall business results #