General

New Core Web Vitals and How They Work

Published Feb 14, 2024

Updated Feb 16, 2024

6 min read

This article was written over 18 months ago and may contain information that is out of date. Some content may be relevant but please refer to the relevant official documentation or available resources for the latest information.

Core Web Vitals, introduced by Google in 2020, have been around for a while now. And after four years, a significant change is coming in March 2024. In this article, I will try to tell you everything you need to know to be prepared. But first, let's briefly talk about what Core Web Vitals are.

What are Core Web Vitals?

Web Vitals is a Google initiative that aims to provide developers with guidance on authoring the best user experience on the web as well as tools to assess and measure it. Core Web Vitals are a subset of Web Vitals and currently consist of three main metrics:

Largest Contentful Paint (LCP): This metric measures the time it takes for the largest content element to be rendered on the screen. It should reflect the loading aspect of the user experience.
First Input Delay (FID): This metric measures the time it takes for the browser to respond to the first user interaction. It should reflect the interactivity aspect of the user experience.
Cumulative Layout Shift (CLS): This metric measures the amount of unexpected layout shifts of visual elements on the page. It should reflect the visual stability aspect of the user experience.

Part of the Core Web Vitals are also the thresholds that define what is considered a good experience. These thresholds are currently set to:

Metric	Good	Needs Improvement	Bad
LCP	≤ 2.5 s	2.5 - 4 s	> 4 s
FID	≤ 100 ms	100 - 300 ms	> 300 ms
CLS	≤ 0.1	0.1 - 0.25	> 0.25

While the reward of providing a good user experience should be enough for you to strive for great results in these metrics, that is not the only reason you should care about them. Google is reflecting these metrics in its search ranking algorithm as it wants it to "reward content that offers good user experience".

What's Changing in March 2024?

The change affects how interactivity is measured. The First Input Delay (FID) has been deemed no longer sufficient to measure the interactivity aspect of the user experience. It will be replaced by the Interaction to Next Paint (INP) metric on March 12, 2024.

INP, unlike FID, measures the response of all interactions up to a URL change. It then picks the slowest response from all interactions. (If there are more than 50 interactions, it picks a percentile instead, most often the 98th) making it much stricter than FID.

Why the Change?

There are three main reasons why FID is being replaced by INP:

FID is not strict enough: Upwards of 90% of websites meet the good threshold for FID nowadays, making it a poor differentiator between good and bad user experiences.
FID is not representative of the full interaction: FID only measures the first part of the reaction delay, up to the point before the response bubbles to JavaScript, not accounting for the (often quite long) time it takes for the JavaScript to process the response and for the browser to paint the next frame.
FID only measures the first interaction: According to Google, 90% of interactions happen after the first load, making FID not representative of the full user experience.

INP aims to address these issues by measuring the full interaction and by being stricter in its thresholds (according to Google, ~70% of websites should pass the good INP threshold now) and thus capturing a more representative picture of the user experience.

How Does INP Work?

As I previously mentioned, INP measures all interactions on the page and picks the slowest one or a percentile, which solves one of the issues with FID not representing the whole experience of interacting with a website. This way of measuring is not dissimilar to how CLS measures the unexpected layout shifts on the page as it also captures the full scope of the stay on the page.

The interactions considered by INP are:

Mouse clicks
Touchscreen taps
Keyboard presses (including virtual onscreen keyboards)

If an interaction is composed of multiple events, such as a keystroke, consisting of the keydown, keypress, and keyup events; INP groups them and measures the latency as the maximum duration of all the included events.

Unlike FID, it captures not only the time taken by tasks blocked by the main thread (the input delay) but also the processing time (events and JavaScript processing) and the presentation delay (the time it takes for the browser to paint the next frame), making it a much better reflection of the full user experience, but also much harder to pass.

So while FID reflects the first impression, INP should capture the overall responsiveness of a page.

For more information about interactions with comprehensive diagrams of what actually happens in the browser, check out the web.dev article on INP.

Google defined the thresholds for INP as follows:

Metric	Good	Needs Improvement	Bad
INP	≤ 200 ms	200 - 500 ms	> 500 ms

How to Prepare for INP?

Let's start with some general steps you should take to prepare for the new Web Vital:

1. Measure

Start with measuring your INP score. The easiest way to measure it is using PageSpeed Insights, but if you need to measure it locally, you can use Lighthose user flows which already support INP. If your INP scores are good, you're fine and you can probably stop reading further.

2. Do not panic

While, according to Tim Kadlec, only 17% of React websites and 11.8% of Next.js websites in the "top 100k" pass the good INP threshold, so it's very likely that you will have to do some work to pass; framework authors have been working on improving their performance and things may be as hot as Tim paints them. According to Google’s stats, ~80-90% of desktop sites pass the good INP threshold depending on the framework as of June 2023:

Technology	Passing on Mobile [%]	Passing on Desktop [%]
Angular (v2.0.0+)	28.6	83.6
Next.js	28.5	87.3
Nuxt.js	32.0	91.2
Preact	48.6	92.8
Vue (v2.0.0+)	50.3	94.1
Lit	50.0	88.3

3. Optimize

In case your INP scores are not good, you should start optimizing your website. Identify the pages that perform the worst and start with them. Focus on:

Code splitting and tree shaking to make sure only the necessary JavaScript is included.
Deferring non-critical JavaScript events until the main thread is idle. Consider also offloading heavy tasks to a Web Worker.
Debouncing or throttling frequently fired events.
Breaking up long JavaScript tasks into smaller ones.
Using passive event listeners.
Reducing the presentational delay e.g. by using the will-change CSS property, and preferring transform and opacity over the display and position properties in animations.
Eliminating third-party scripts. Very often, third-party scripts, be it for analytics, cookie consent, or other purposes, have a significant impact on performance. Considering which of them are not absolutely necessary, and either removing them or replacing them with a more performant solution is highly recommended.
Upgrading your dependencies to make sure you are taking advantage of the latest performance-improving features.

If you want to read more about the general INP optimization tips, you can check out this Vercel article.

While a lot of these optimizations, such as code splitting and tree shaking, are already taken care of by modern frameworks, I believe that it’s worth going through this list to see what you can do to make your website faster and thus a better experience for your users. We will explore concrete performance tips for popular frameworks in the next article.

Conclusion

The change in Core Web Vitals is coming and it's going to be a significant one. The new metric, Interaction to Next Paint, is going to be much stricter than the current First Input Delay and it's going to be much harder to pass. However, the good news is that framework authors have already been working on making the frameworks more INP-friendly, and while it may take some effort, you should be able to improve your INP score.

INP, however, should not be just another Lighthouse threshold we have to satisfy. This change should encourage us to look beyond surface-level metrics and dive deeper into the nuances of user interaction. As we adapt to these changes, our focus should remain on the end goal: creating a good and inclusive user experience for our visitors.

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

About the author(s)

Jan Kaiser
Software engineer passionate about everything web-related. Particularly loves Angular, SCSS, TypeScript, soccer and dachshunds
@honzikec @honzikec

Next.js + MongoDB Connection Storming

Building a Next.js application connected to MongoDB can feel like a match made in heaven. MongoDB stores all of its data as JSON objects, which don’t require transformation into JavaScript objects like relational SQL data does. However, when deploying your application to a serverless production environment such as Vercel, it is crucial to manage your database connections properly. If you encounter errors like these, you may be experiencing Connection Storming: * MongoServerSelectionError: connect ECONNREFUSED <IP_ADDRESS>:<PORT> * MongoNetworkError: failed to connect to server [<hostname>:<port>] on first connect * MongoTimeoutError: Server selection timed out after <x> ms * MongoTopologyClosedError: Topology is closed, please connect * Mongo Atlas: Connections % of configured limit has gone above 80 Connection storming occurs when your application has to mount a connection to Mongo for every serverless function or API endpoint call. Vercel executes your application’s code in a highly concurrent and isolated fashion. So, if you create new database connections on each request, your app might quickly exceed the connection limit of your database. We can leverage Vercel’s fluid compute model to keep our database connection objects warm across function invocations. Traditional serverless architecture was designed for quick, stateless web app transactions. Now, especially with the rise of LLM-oriented applications built with Next.js, interactions with applications are becoming more sequential. We just need to ensure that we assign our MongoDB connection to a global variable. Protip: Use global variables Vercel’s fluid compute model means all memory, including global constants like a MongoDB client, stays initialized between requests as long as the instance remains active. By assigning your MongoDB client to a global constant, you avoid redundant setup work and reduce the overhead of cold starts. This enables a more efficient approach to reusing connections for your application’s MongoDB client. The example below demonstrates how to retrieve an array of users from the users collection in MongoDB and either return them through an API request to /api/users or render them as an HTML list at the /users route. To support this, we initialize a global clientPromise variable that maintains the MongoDB connection across warm serverless executions, avoiding re-initialization on every request. ` Using this database connection in your API route code is easy: ` You can also use this database connection in your server-side rendered React components. ` In serverless environments like Vercel, managing database connections efficiently is key to avoiding connection storming. By reusing global variables and understanding the serverless execution model, you can ensure your Next.js app remains stable and performant....

Jul 11, 2025

3 mins

NextJSJavaScript

“Music and code have a lot in common,” freeCodeCamp’s Jessica Wilkins on what the tech community is doing right to onboard new software engineers

Before she was a software developer at freeCodeCamp, Jessica Wilkins was a classically trained clarinetist performing across the country. Her days were filled with rehearsals, concerts, and teaching, and she hadn’t considered a tech career until the world changed in 2020. > “When the pandemic hit, most of my gigs were canceled,” she says. “I suddenly had time on my hands and an idea for a site I wanted to build.” That site, a tribute to Black musicians in classical and jazz music, turned into much more than a personal project. It opened the door to a whole new career where her creative instincts and curiosity could thrive just as much as they had in music. Now at freeCodeCamp, Jessica maintains and develops the very JavaScript curriculum that has helped her and millions of developers around the world. We spoke with Jessica about her advice for JavaScript learners, why musicians make great developers, and how inclusive communities are helping more women thrive in tech. Jessica’s Top 3 JavaScript Skill Picks for 2025 If you ask Jessica what it takes to succeed as a JavaScript developer in 2025, she won’t point you straight to the newest library or trend. Instead, she lists three skills that sound simple, but take real time to build: > “Learning how to ask questions and research when you get stuck. Learning how to read error messages. And having a strong foundation in the fundamentals” She says those skills don’t come from shortcuts or shiny tools. They come from building. > “Start with small projects and keep building,” she says. “Books like You Don’t Know JS help you understand the theory, but experience comes from writing and shipping code. You learn a lot by doing.” And don’t forget the people around you. > “Meetups and conferences are amazing,” she adds. “You’ll pick up things faster, get feedback, and make friends who are learning alongside you.” Why So Many Musicians End Up in Tech A musical past like Jessica’s isn’t unheard of in the JavaScript industry. In fact, she’s noticed a surprising number of musicians making the leap into software. > “I think it’s because music and code have a lot in common,” she says. “They both require creativity, pattern recognition, problem-solving… and you can really get into flow when you’re deep in either one.” That crossover between artistry and logic feels like home to people who’ve lived in both worlds. What the Tech Community Is Getting Right Jessica has seen both the challenges and the wins when it comes to supporting women in tech. > “There’s still a lot of toxicity in some corners,” she says. “But the communities that are doing it right—like Women Who Code, Women in Tech, and Virtual Coffee—create safe, supportive spaces to grow and share experiences.” She believes those spaces aren’t just helpful, but they’re essential. > “Having a network makes a huge difference, especially early in your career.” What’s Next for Jessica Wilkins? With a catalog of published articles, open-source projects under her belt, and a growing audience of devs following her journey, Jessica is just getting started. She’s still writing. Still mentoring. Still building. And still proving that creativity doesn’t stop at the orchestra pit—it just finds a new stage. Follow Jessica Wilkins on X and Linkedin to keep up with her work in tech, her musical roots, and whatever she’s building next. Sticker illustration by Jacob Ashley....

Apr 25, 2025

3 mins

JavaScriptSoftware Engineering

Vercel & React Native - A New Era of Mobile Development?

Vercel & React Native - A New Era of Mobile Development? Jared Palmer of Vercel recently announced an acquisition that spiked our interest. Having worked extensively with both Next.js and Vercel, as well as React Native, we were curious to see what the appointment of Fernando Rojo, the creator of Solito, as Vercel's Head of Mobile, would mean for the future of React Native and Vercel. While we can only speculate on what the future holds, we can look closer at Solito and its current integration with Vercel. Based on the information available, we can also make some educated guesses about what the future might hold for React Native and Vercel. What is Solito? Based on a recent tweet by Guillermo Rauch, one might assume that Solito allows you to build mobile apps with Next.js. While that might become a reality in the future, Jamon Holmgren, the CTO of Infinite Red, added some context to the conversation. According to Jamon, Solito is a cross-platform framework built on top of two existing technologies: - For the web, Solito leverages Next.js. - For mobile, Solito takes advantage of Expo. That means that, at the moment, you can't build mobile apps using Next.js & Solito only - you still need Expo and React Native. Even Jamon, however, admits that even the current integration of Solito with Vercel is exciting. Let's take a closer look at what Solito is according to its official website: > This library is two things: > > 1. A tiny wrapper around React Navigation and Next.js that lets you share navigation code across platforms. > > 2. A set of patterns and examples for building cross-platform apps with React Native + Next.js. We can see that Jamon was right - Solito allows you to share navigation code between Next.js and React Native and provides some patterns and components that you can use to build cross-platform apps, but it doesn't replace React Native or Expo. The Cross-Platformness of Solito So, we know Solito provides a way to share navigation and some patterns between Next.js and React Native. But what precisely does that entail? Cross-Platform Hooks and Components If you look at Solito's documentation, you'll see that it's not only navigation you can share between Next.js and React Native. There are a few components that wrap Next.js components and make them available in React Native: - Link - a component that wraps Next.js' Link component and allows you to navigate between screens in React Native. - TextLink - a component that also wraps Next.js' Link component but accepts text nodes as children. - MotiLink - a component that wraps Next.js' Link component and allows you to animate the link using moti, a popular animation library for React Native. - SolitoImage - a component that wraps Next.js' Image component and allows you to display images in React Native. On top of that, Solito provides a few hooks that you can use for shared routing and navigation: - useRouter() - a hook that lets you navigate between screens across platforms using URLs and Next.js Url objects. - useLink() - a hook that lets you create Link components across the two platforms. - createParam() - a function that returns the useParam() and useParams() hooks which allow you to access and update URL parameters across platforms. Shared Logic The Solito starter project is structured as a monorepo containing: - apps/next - the Next.js application. - apps/expo or apps/native - the React Native application. - packages/app - shared packages across the two applications: - features - providers - navigation The shared packages contain the shared logic and components you can use across the two platforms. For example, the features package contains the shared components organized by feature, the providers package contains the shared context providers, and the navigation package includes the shared navigation logic. One of the key principles of Solito is gradual adoption, meaning that if you use Solito and follow the recommended structure and patterns, you can start with a Next.js application only and eventually add a React Native application to the mix. Deployments Deploying the Next.js application built on Solito is as easy as deploying any other Next.js application. You can deploy it to Vercel like any other Next.js application, e.g., by linking your GitHub repository to Vercel and setting up automatic deployments. Deploying the React Native application built on top of Solito to Expo is a little bit more involved - you cannot directly use the Github Action recommended by Expo without some modification as Solito uses a monorepo structure. The adjustment, however, is luckily just a one-liner. You just need to add the working-directory parameter to the eas update --auto command in the Github Action. Here's what the modified part of the Expo Github Action would look like: ` What Does the Future Hold? While we can't predict the future, we can make some educated guesses about what the future might hold for Solito, React Native, Expo, and Vercel, given what we know about the current state of Solito and the recent acquisition of Fernando Rojo by Vercel. A Competitor to Expo? One question that comes to mind is whether Vercel will work towards creating a competitor to Expo. While it's too early to tell, it's not entirely out of the question. Vercel has been expanding its offering beyond Next.js and static sites, and it's not hard to imagine that it might want to provide a more integrated, frictionless solution for building mobile apps, further bridging the gap between web and mobile development. However, Expo is a mature and well-established platform, and building a mobile app toolchain from scratch is no trivial task. It would be easier for Vercel to build on top of Expo and partner with them to provide a more integrated solution for building mobile apps with Next.js. Furthermore, we need to consider Vercel's target audience. Most of Vercel's customers are focused on web development with Next.js, and switching to a mobile-first approach might not be in their best interest. That being said, Vercel has been expanding its offering to cater to a broader audience, and providing a more integrated solution for building mobile apps might be a step in that direction. A Cross-Platform Framework for Mobile Apps with Next.js? Imagine a future where you write your entire application in Next.js — using its routing, file structure, and dev tools — and still produce native mobile apps for iOS and Android. It's unlikely such functionality would be built from scratch. It would likely still rely on React Native + Expo to handle the actual native modules, build processes, and distribution. From the developer’s point of view, however, it would still feel like writing Next.js. While this idea sounds exciting, it's not likely to happen in the near future. Building a cross-platform framework that allows you to build mobile apps with Next.js only would require a lot of work and coordination between Vercel, Expo, and the React Native community. Furthermore, there are some conceptual differences between Next.js and React Native that would need to be addressed, such as Next.js being primarily SSR-oriented and native mobile apps running on the client. Vercel Building on Top of Solito? One of the more likely scenarios is that Vercel will build on top of Solito to provide a more integrated solution for building mobile apps with Next.js. This could involve providing more components, hooks, and patterns for building cross-platform apps, as well as improving the deployment process for React Native applications built on top of Solito. A potential partnership between Vercel and Expo, or at least some kind of closer integration, could also be in the cards in this scenario. While Expo already provides a robust infrastructure for building mobile apps, Vercel could provide complementary services or features that make it easier to build mobile apps on top of Solito. Conclusion Some news regarding Vercel and mobile development is very likely on the horizon. After all, Guillermo Rauch, the CEO of Vercel, has himself stated that Vercel will keep raising the quality bar of the mobile and web ecosystems. While it's unlikely we'll see a full-fledged mobile app framework built on top of Next.js or a direct competitor to Expo in the near future, it's not hard to imagine that Vercel will provide more tools and services for building mobile apps with Next.js. Solito is a step in that direction, and it's exciting to see what the future holds for mobile development with Vercel....

Apr 4, 2025

6 mins

NextJSReact NativeDevOps

What does it actually look like to build software with AI today? Not in theory, but in practice.

What does it actually look like to build software with AI today? Not in theory, but in practice. At the Leadership Exchange, this was the question at the center of the Developer Panel, where leaders from across the industry unpacked what’s really changing inside engineering teams and what organizations need to do right now to keep up. The Developer Panel at the Leadership Exchange explored the cutting edge of AI in software engineering and examined what organizations should focus on today to prepare for the future. Moderated by Jeff Cross, Co-Founder & CEO at Nx, the panel featured Victor Savkin, Cofounder & CTO at Nx, Alex Sover, Vice President of Engineering at OpenAP, Brent Zucker, Senior Director of Engineering at Visa, and Jonathan Fontanez, AI Engineering Lead at This Dot Labs. Panelists shared insights into how AI is transforming the software development lifecycle and how teams can adopt tools effectively while preparing for organizational change. Panelists discussed emerging workflows, including CI-in-the-loop, agentic healing, and context engineering. They examined how validation, code reviews, and PRDs are evolving alongside AI capabilities and how teams are integrating external sources such as production traces to improve quality and reliability. The discussion also covered what the next generation of agentic tools might look like and how these capabilities will shape engineering practices in the near future. Adoption of AI comes with challenges. Teams often rely on plugins or extensions without foundational understanding, and individual contributors may fear displacement. Panelists emphasized that education, governance, and skill-building are essential for teams to manage AI agents effectively while maintaining quality. They also highlighted the need to standardize workflows and ensure organizational alignment to fully leverage AI capabilities. The conversation extended beyond technical challenges to organizational implications. Panelists discussed how teams can avoid issues like Conway’s Law, manage distributed teams effectively, and evolve engineering practices alongside AI adoption. Leadership and management strategies play a crucial role in ensuring that AI integration delivers meaningful outcomes while maintaining efficiency and alignment with business objectives. Key Takeaways - AI workflows require both technical and organizational preparation. - Education, governance, and skill development are essential for successful implementation. - Forward-looking teams are rethinking validation, CI pipelines, and context management to fully leverage agentic AI. The discussion highlighted that adopting AI at the cutting edge is not just about new tools - it is about rethinking processes, workflows, and organizational culture. Companies that embrace this holistic approach are most likely to succeed in leveraging AI to its full potential. Are you interested in more conversations like this? Message us for an invite to the next, or for a private discussion around these topics. Tracy can be reached at tlee@thisdot.co....

Mar 27, 2026

2 mins

AI AdoptionAILeadership ExchangeEngineering Leadership

Let's innovate together!

We're ready to be your trusted technical partners in your digital innovation journey.

Whether it's modernization or custom software solutions, our team of experts can guide you through best practices and how to build scalable, performant software that lasts.