Loading Speed and Core Web Vitals (2026): Understanding the UX Shift to INP

LCP (Largest Contentful Paint): display speed

LCP is the time from opening a page until the largest piece of content within the viewport (often the main image or a large heading text) is displayed. It is a proxy for the moment a visitor feels "okay, this page has loaded properly." The threshold considered good is within 2.5 seconds. From 2.5 to 4.0 seconds is "needs improvement," and over 4.0 seconds is judged "poor." The main causes of slow LCP are overly heavy images, slow server response, and render-blocking CSS or JavaScript.

INP (Interaction to Next Paint): responsiveness

INP measures the time from when a user performs an interaction — clicking or tapping a button, typing a key — to when the screen is next updated (painted) as a result. Its distinctive feature is targeting every interaction during the stay on the page and evaluating the slowness of those responses in aggregate. The threshold considered good is within 200 milliseconds (0.2 seconds). From 200 to 500 milliseconds is "needs improvement," and over 500 milliseconds is "poor." The smaller the number, the more it means "a snappy site that responds the instant you press."

CLS (Cumulative Layout Shift): display stability

CLS quantifies the amount of unexpected layout shift while a page is displaying. It is a metric to prevent that unpleasant phenomenon where, just as you go to read, an ad or image is inserted afterward and the text shifts down, causing you to accidentally tap a button you did not intend to. The threshold considered good is 0.1 or under. From 0.1 to 0.25 is "needs improvement," and over 0.25 is judged "poor." CLS is a unitless score representing the proportion of shift rather than time, and the smaller the value, the more stable the screen.

FID looked only at "the wait for the first interaction"

FID was a metric that measured only the "wait time" until the browser began processing the user's first interaction. In other words, it evaluated a single time, right after the page displayed, and only "until the response began" — it did not look at whether the screen was subsequently updated properly. Because of this, a site where the post-interaction processing was heavy and the screen took a while to update could still look good in FID numbers. It had a weakness: the metric diverged from the user's actual feeling.

INP looks at "comprehensive responsiveness to interaction"

INP targets nearly every interaction during the stay on the page, not just the first one, and measures the whole span "from the interaction until the screen is actually next painted." Because it evaluates from the instant of pressing until a visible result returns, it is more faithful to the "sluggishness" a user feels. In other words, INP indicates comprehensive responsiveness to interaction, including not just the wait time but the weight of the processing itself and the delay in painting. It has become a stricter, and more experience-faithful, metric than FID.

Characteristics of sites that need INP work

INP tends to worsen on sites that do a lot of processing in JavaScript. When every click does heavy computation, processes huge data all at once, or lets heavy third-party scripts (chat, analytics, ads) monopolize the main thread, the post-interaction paint is delayed and INP grows. The direction of the fix is to split heavy processing and run it in small pieces, cut unnecessary scripts, and lighten event handling. For a typical corporate site centered on static content, simply not piling on too much JavaScript is the best INP measure.

Heavy images and media

The most common cause, and the one that yields results most readily, is images. It is not unusual to see a several-megabyte photo pasted in straight from the camera, or original data that is 4000px wide when the display size is only 400px. This directly worsens LCP. Auto-playing video and loading large numbers of icons are similar burdens.

Excessive JavaScript and third-party scripts

Scripts loaded from outside (third-party scripts) — analytics, ads, chatbots, social embeds, various plugins — are the archetypal cause of a heavy page. They monopolize the browser's processing and especially worsen INP. Each is convenient on its own, but they add up to cause interaction sluggishness and display delays. The same goes for self-authored JavaScript that is larger than necessary.

Layout shift and slow server response

Images without size specifications, and later-inserted ads or embeds, worsen CLS. A delay in loading web fonts can also cause characters to swap partway through display, shifting the layout. One more thing that is often overlooked is server response speed. If the time until the browser receives the first response (HTML) — TTFB — is long, everything downstream shifts back and LCP worsens too. A server that is merely cheap with low processing power, or a setup that regenerates the page with heavy processing every time, tends to become a fundamental bottleneck.

Image optimization and lazy loading (for LCP)

Images improve dramatically just by nailing three points. First is format: convert to lightweight formats such as WebP or AVIF. Second is size: compress and resize to match the display width, and further deliver the optimal resolution per device with srcset or the picture element. Third is lazy loading: for images below the initially visible area, load them as scrolling brings them near, keeping the initial display light. However, the hero image of the first view (the one likely to be the LCP element) should be specified to load with priority rather than deferred. Getting this backward actually makes LCP slower.

Cutting unnecessary scripts and font/CLS measures (for INP/CLS)

First, narrow it down to only the external scripts you truly need. Delete unused analytics tags and old plugins, and for those you keep, shift the loading timing later (defer or async, or load after interaction) to improve INP and initial display. As a CLS measure, always specify width and height (or aspect ratio) for images and video to reserve the display area in advance. For web fonts, display text with a substitute font while loading (adjusting font-display) to suppress the shift at swap time. When placing ads or embeds, reserving the box size in advance prevents the jitter of elements being pushed in later.

Cache, CDN, and rendering method (for LCP/TTFB)

To speed up server response, cache and a CDN (a delivery network placed around the world) are effective. Caching once-generated pages and images for reuse and delivering from a point near the user shortens TTFB and LCP. More fundamental is the choice of rendering method. A method that delivers statically generated pages (SSG, or a setup that generates in advance) is faster than one that assembles the page on the server every time. HaLVision Tech uses Next.js and React and makes "fast from the start" implementation standard, premised on static generation, caching, and image optimization. Rather than tacking on speed measures after building with a CMS, being mindful of Core Web Vitals at the design stage ultimately saves both effort and cost.

Diagnose a single page with PageSpeed Insights

PageSpeed Insights is a free tool that shows a page's score and improvement suggestions just by entering a URL. Check the pass/fail of LCP, INP, and CLS from the real-user data shown at the top (measured values over the past 28 days), while using the lab data and suggestion list at the bottom to concretely grasp "what is slow and how to fix it." The basic flow is to diagnose one page first and start with the most-flagged items.

See site-wide trends with Search Console

Using the "Core Web Vitals" report in Google Search Console, you can check the whole site's pages classified into "good, needs improvement, poor." Because similarly structured pages are evaluated together, you can get an overview of which template (product page, article page, and so on) the problems concentrate in, making it easier to set priorities. Dividing roles — deep dives on individual pages with PageSpeed Insights, overall trends with Search Console — is efficient.

CrUX (real-user data) is the basis of the judgment

CrUX (Chrome User Experience Report) is experience data collected anonymously from actual users who use Chrome. The pass/fail shown by PageSpeed Insights and Search Console is based on these measured CrUX values. That is exactly why, even if it looks fast on a developer's PC, your evaluation will not rise if it is slow on a poor connection or a low-performance phone. Improving with the view of "is it fast for actual visitors?" is what ultimately leads to passing Core Web Vitals.

Think of speed as effective in a "tiebreaker"

It is entirely normal for a substantive but slightly slow page to rank above a fast page with thin content. Search results are largely decided first by content relevance and trustworthiness, and Core Web Vitals then work on top of that to split "the difference between near-equal competitors" — grasping it as a tiebreaker-like role is close to reality. Therefore, pushing speed alone while content remains insufficient will not necessarily raise your ranking dramatically.

The real value is "preventing bounce and driving results"

The greatest effect of speed improvement lies not in ranking itself but in "not letting the people who arrived slip away." A slow-displaying, sluggish, jittery site tends to be abandoned before its content is even read. What to note here is that Google does not directly use figures like bounce rate or time on page as direct ranking factors. Even so, a comfortable site gets read after being clicked and more readily leads to results such as inquiries and repeat visits. Grasping speed improvement not as a "trick to directly manipulate ranking" but as "building the foundation to turn hard-won visitors into results" keeps your investment decisions sound. The accumulation of good experiences brings indirect, long-term benefit to SEO in the form of branded search, links, and sharing.

What to tackle first

To produce results in limited time, order matters. We recommend starting with three: (1) image optimization, (2) cutting unnecessary external scripts, and (3) reviewing your server and delivery (cache/CDN). These three have a large effect on many sites and are areas easy to start on without specialized knowledge. On top of that, it is realistic to revisit fundamental parts such as the rendering method at the timing of a renewal or new build. Being able to premise a speed-conscious standard implementation on Next.js/React, as HaLVision Tech does, holds down the cost of after-the-fact measures.

Q.What is the difference between INP and FID?

FID measured only "the wait time until processing began for the first interaction." INP targets nearly every interaction during the stay on the page and measures the whole span "from the interaction until the screen is actually next updated." In other words, INP is more faithful to the "sluggishness" a user feels, and stricter, because it evaluates not just wait time but the weight of processing and the delay in painting. It became the official metric in place of FID in March 2024.

Q.What are the passing thresholds for Core Web Vitals?

The thresholds considered good are LCP (display speed) within 2.5 seconds, INP (responsiveness) within 200 milliseconds, and CLS (display stability) at 0.1 or under. This judgment is made based on real-user data (CrUX) collected on the devices of actual visitors. Having all three good is the desirable state.

Q.If I raise loading speed, will my search ranking definitely rise?

Not necessarily. Core Web Vitals are one of the factors that affect ranking, but not the largest one — content relevance and trustworthiness matter most first. It is closer to reality to think of speed as effective in the scene of splitting the difference between near-equal competitors. Note that pushing speed alone while content remains insufficient makes a dramatic ranking rise hard to expect.

Q.Can I improve speed myself, or do I need a professional?

Image optimization (converting to lightweight formats, adjusting size, lazy loading) and deleting unnecessary external scripts are relatively approachable areas with a large effect. It is good to first diagnose with PageSpeed Insights and start from the most-flagged items. On the other hand, fundamental parts such as the rendering method and server setup require specialized judgment, so it is realistic to consult a professional at the timing of a renewal or new build.

Q.How do I use PageSpeed Insights and Search Console differently?

PageSpeed Insights is suited to diagnosing a single URL in detail and concretely learning "what is slow and how to fix it." The "Core Web Vitals" report in Search Console is suited to classifying the whole site's pages into good, needs improvement, and poor, and getting an overview of which template the problems concentrate in. Dividing roles — overall trends with Search Console, individual deep dives with PageSpeed Insights — is efficient.

Q.What is the difference between lab data and real-user data?

Lab data is speed data measured in a simulated way under fixed conditions, convenient for isolating causes and confirming improvement work. Real-user data (field data / CrUX) is experience data collected on the devices and connection environments of actual visitors. Since it is the real-user data that is used for the Core Web Vitals pass/fail judgment, it is important ultimately to improve on the basis of "is it fast for actual visitors?"