Toronto: 905-626-3857 Calgary: 403-456-6224

Core Web Vitals and INP in 2026: Why a Slow Website Costs You Rankings and AI Citations

by Paradigmmedia | Sep 15, 2026 | Search Engine Optimization

If ChatGPT or Perplexity can’t cite your website, the reason might not be your content. It might be your code.

GPTBot fetches JavaScript files on about 11.5% of its requests, and never executes a single one of them. ClaudeBot downloads JavaScript roughly 24% of the time and does the same, it never runs it. PerplexityBot parses static HTML only (SearchOptimo, citing Vercel’s crawler research). Googlebot is the exception. It eventually renders JavaScript through a secondary queue. AI crawlers don’t bother. They read whatever comes back in the initial server response and move on.

That means a site built to look fast to a human but slow to build to a machine, heavy scripts, client-side rendering, content that only appears after JavaScript runs, risks more than a Core Web Vitals penalty in Google. It can be functionally invisible to the AI systems increasingly answering your customers’ questions before they ever reach a search results page.

Here’s what Core Web Vitals actually measure, where most sites genuinely stand in 2026, and what to fix first.

What Core Web Vitals Actually Measure

Core Web Vitals are three metrics Google uses to judge real-world page experience: Largest Contentful Paint for loading speed, Interaction to Next Paint for responsiveness, and Cumulative Layout Shift for visual stability. Google measures all three using real user data collected through the Chrome User Experience Report, not a lab test, so your score reflects how your site actually performs for visitors on their own devices and connections.

The current, official thresholds:

MetricWhat it measuresGoodNeeds ImprovementPoor
LCP (Largest Contentful Paint)Time until the largest visible element loadsUnder 2.5s2.5s to 4.0sOver 4.0s
INP (Interaction to Next Paint)Time from a user’s click or tap to the next visual responseUnder 200ms200ms to 500msOver 500ms
CLS (Cumulative Layout Shift)How much visible content jumps around while loadingUnder 0.10.1 to 0.25Over 0.25

 

A site passes Core Web Vitals when it hits “good” on all three at the 75th percentile of real visitor traffic (confirmed against CrUX data via Core Web Vitals). We’ll flag it clearly here because a fair amount of content circulating right now claims Google quietly tightened these numbers in 2026. It didn’t. The thresholds above are the same ones in place since INP officially replaced First Input Delay as the responsiveness metric back in March 2024, a change Google made because FID only measured the delay before the very first interaction, missing everything that happened after (web.dev).

Where Sites Actually Stand in 2026

Here’s a real benchmark, not a scare number. As of January 2026, 55.7% of web origins globally pass all three Core Web Vitals thresholds, up from roughly 50% in early 2024. There’s a real gap by device: 57.1% of sites pass on desktop, compared to 49.7% on mobile (HTTP Archive CrUX data, reported by Whitehat SEO and DebugBear).

WordPress, the platform behind most of Paradigmmedia’s client sites, sits at a 43.44% overall pass rate, fifth among major CMS platforms, with 50% of WordPress sites passing on desktop and 46% on mobile. Duda leads the field at 83.63%, with Shopify close behind in second place. If you’re running WordPress with a heavy page builder and a stack of plugins, the average WordPress site is already behind the pack, and that’s before accounting for anything specific to your build.

That gap isn’t really about WordPress as a platform. A lean, well-built WordPress site can pass all three metrics without much trouble. The gap comes from what usually gets layered on top of it over the years, a drag-and-drop page builder, a dozen plugins nobody remembers installing, a theme built for flexibility rather than speed. Each one adds a little more JavaScript and a little more render delay, and none of them show up as a problem until you actually run the numbers.

The Revenue Case Behind the Ranking Case

Speed shows up on the balance sheet as much as it shows up in Search Console. A joint study from Deloitte and Google found that a 0.1 second improvement in load time lifted retail site conversion rates by 8.4%. Google’s own case study on Vodafone found that a 31% improvement in LCP correlated with an 8% increase in sales (web.dev). Neither of those numbers required a full site rebuild to move. They came from targeted fixes to the slowest, heaviest parts of an existing page, the kind of fixes most small business sites have never gotten around to making.

The AI Citation Mechanism, Explained Properly

This is the part most page speed content skips, and it’s worth walking through carefully because the connection is more direct than it sounds.

Google’s ranking algorithm renders your page, sees your real Core Web Vitals scores, and factors them into where you land. AI Overviews and Google’s AI Mode draw heavily from pages that already rank well, so a Core Web Vitals problem that hurts your ranking indirectly hurts your odds of being pulled into an AI-generated answer too.

But the more immediate problem is architectural. GPTBot, ClaudeBot, and PerplexityBot don’t run your JavaScript at all. If your key content, your service descriptions, your pricing, your answers to customer questions, only appears in the browser after a script executes, those crawlers never see it. They see the initial HTML response and nothing more (SearchOptimo). The exact same technical debt that drags down your INP score, oversized JavaScript bundles, client-side rendering, long-running scripts blocking the main thread, is very often the same debt keeping your actual content out of the one place AI crawlers look. Fix the code for Core Web Vitals, and you’re very often fixing your AI visibility at the same time.

Fixes, Ranked by Actual Impact

Server response time. Every millisecond your server takes to respond delays everything downstream, your LCP score and how much of your site a crawler, human or AI, gets through before it moves on. Quality hosting and proper caching solve more of this than any front-end tweak.

Reduce reliance on client-side JavaScript. Where possible, render your primary content, headings, body copy, pricing, key answers, server-side so it’s present in the initial HTML response. This is the single highest-leverage fix for both INP and AI crawler visibility, since it solves the exact gap AI crawlers can’t cross on their own.

Optimize images for LCP. Compress and correctly size your largest visible image or hero element, and load it early rather than behind other scripts.

Reserve space for dynamic elements. Ads, embeds, and images that load without a defined size push everything around them, which is what drives CLS. A fixed width and height attribute solves most of this outright.

Break up long JavaScript tasks. INP suffers most when a single script ties up the browser’s main thread. Splitting long tasks into smaller chunks keeps the page responsive to actual clicks and taps.

Audit your plugin and page builder stack. On WordPress specifically, plugin bloat and heavy visual builders are the most common cause of failing scores. Every plugin you can remove or replace with lighter code is a direct win.

How to Check Your Own Site

Run your homepage and two or three key service pages through PageSpeed Insights for both the lab and field data, then check the Core Web Vitals report inside Google Search Console for your site’s real, aggregated performance across actual visitors. The Search Console numbers are the ones that matter most, since they reflect the CrUX field data Google actually uses.

While you’re in there, take one extra step most site owners skip: view your page’s source through “view page source” rather than the rendered DOM in your browser’s inspector. If your main service content, headings, pricing, key answers, isn’t visible in that raw source, that’s the same gap an AI crawler runs into. What you see in a fully loaded browser tab and what a non-rendering crawler sees are often two different pages entirely.

A short version to run through on your own site:

  • Does PageSpeed Insights show “good” for LCP, INP, and CLS in the field data, not only the lab data?
  • Does Search Console’s Core Web Vitals report show most URLs in the “good” group?
  • Does your homepage’s raw HTML source, viewed without JavaScript rendering, actually contain your core content?
  • Are your largest images compressed and sized correctly rather than scaled down in the browser?
  • Does anything visibly shift on the page in the first two seconds after it loads?

Any “no” on that list points straight to where to start.

Frequently Asked Questions

What replaced First Input Delay?

Interaction to Next Paint (INP) officially replaced First Input Delay as Google’s Core Web Vital for responsiveness on March 12, 2024. Where FID only measured the delay before a page’s very first interaction, INP measures every interaction throughout a visit, giving a far more complete picture of how responsive a page actually feels.

What counts as a good INP score?

Under 200 milliseconds, measured at the 75th percentile of real visitor sessions. Between 200 and 500 milliseconds needs improvement. Above 500 milliseconds is considered poor.

Does page speed actually affect ChatGPT and AI Overviews?

Indirectly through ranking, and directly through architecture. A page with strong Core Web Vitals tends to rank better, which improves its odds of being pulled into an AI Overview. More directly, AI crawlers like GPTBot and ClaudeBot don’t render JavaScript, so any content that only appears after a script runs is invisible to them regardless of how fast your Google ranking is. Fixing the same technical debt that hurts your Core Web Vitals score usually fixes this at the same time.

How is this different from a basic “speed up your site” post?

Most page speed advice stops at rankings and bounce rate. The piece that’s missing, and the one covered here, is that the technical choices behind a poor INP or LCP score, especially heavy client-side JavaScript, are often the exact same choices making a page invisible to AI search crawlers. Fixing performance and fixing AI visibility are, in a lot of cases, the same project.

A slow site used to cost you rankings and patience. Now it can cost you a place in the answer entirely, before a human ever gets the chance to click through. If you want a real Core Web Vitals and AI-crawlability audit of your site, get a professional website quote or see how we build performance in from the start on our web design services page. For the fuller picture of how AI search is reshaping visibility beyond speed, read our 2026 guide to GEO for small businesses.

Product, Offer markup, and Merchant Center

In structured data, a Product describes what the item is. An Offer describes how to buy it: price, currency and availability.

Google's merchant listing guidance requires a name, an image, and an offer with a price and currency. It recommends availability, shipping details, return policy, identifiers and brand. Only pages where a shopper can buy the product are eligible. Google's product structured data page adds that enhancements appear at the discretion of each experience and may change.

Eligibility is not guaranteed display. Google says the same about Merchant Center. Its free listings page states that approval to show products does not guarantee they will be shown. Free listings cover surfaces including Search, Shopping and Gemini, and surface availability can change.

Merchant Center's Diagnostics section lists problems by severity. Fix the ones that stop products from serving first.

One warning for WooCommerce stores. Your theme, an SEO plugin and WooCommerce itself may each print Product markup on the same page. Conflicting blocks send mixed signals. Check how many appear, choose one source of truth, and switch the others off. If you use Google's official WooCommerce extension, it syncs from your product fields, so fix the fields first.

A six-step audit

  1. Select five products. Pick top sellers, high-margin items, products with variations and products customers ask about most.
  2. Reconcile fields and feeds. Fill in the worksheet below for each product.
  3. Validate structured data. Run each product URL through Google's Rich Results Test. Count the Product blocks. Check price, currency and availability.
  4. Check diagnostics. Open Merchant Center Diagnostics and note issues on your five products.
  5. Test variants. Select every variation. Confirm that price, stock, image and SKU change on the page and in the markup.
  6. Review checkout. Confirm that price, shipping cost, taxes and return wording match what the product page promised.

A reusable catalogue-quality worksheet

Copy one table per product. Mark any row where the four sources disagree.

FieldVisible pageWooCommerce fieldStructured dataFeedMatch?
Product name
Price (CAD)
Sale price and dates
Availability
Variant options and SKUs
Brand
GTIN or MPN
Material
Dimensions and weight
Compatibility
Shipping cost and timing
Return terms

Prioritized correction

IssueCustomer impactWhere to fixHow to verify
Price or stock differs between page, markup and feedShopper sees one price and pays another. Listings may be disapproved.Product fields, caching, SEO plugin settings, feed syncWorksheet shows four matching values after the cache is cleared
Shipping and returns missing or vagueShopper cannot judge cost or deadline.WooCommerce shipping zones, Merchant Center shipping settings, returns pageTest checkout to two provinces. Wording matches the page.
Variants share one description or imageShopper cannot tell which size or colour they get.Variations tabSelect each variation and confirm the page and markup change
More than one Product markup blockMixed signals about the same item.Theme, SEO plugin, WooCommerce settingsPage source shows one Product block
Invalid or invented identifiersProduct disapproved.Product fields, feedValues match supplier packaging. Diagnostics clear.
Missing material, size or compatibilityCommon questions stay unanswered.Product description and attributesA stranger can answer your opening question from the page alone

A two-week plan

Week 1. Days one and two: choose five products and fill in the worksheets. Days three and four: gather shipping and returns facts from your own policies, then correct identifiers and fields. Day five: remove duplicate markup.

Week 2. Days six and seven: fix variations. Days eight and nine: validate markup and clear the Diagnostics issues you can. Day ten: run a full test purchase on each product. Then set a calendar reminder to recheck after your first holiday sales week.

BOOK A FREE CONSULTATION

Need help clarifying your shopping cart database to enhance your product pages and improve AI search?

Request a product catalogue and feed audit

Paradigmmedia builds and maintains WooCommerce stores for businesses in Toronto, Calgary and across Canada. No audit can promise placement or sales. A catalogue and feed audit gives you a ranked list of corrections your store can act on before the holidays. Our GEO guide for small businesses explains the wider search context.

Frequently asked questions

Does every AI shopping tool require structured data?

No source says so. Tools gather product information in different ways. Google lists Product and Offer markup to become eligible for its merchant listing experiences. Accurate markup helps machines read your page and gives no guarantee of display.

What should I do if my product has no GTIN?

Leave the field blank and provide the brand and, where the maker (is this marker) or maker)assigns one, the MPN. Never create a number. Google's specification says incorrect GTINs lead to disapproval.

How long should a product description be?

As long as it takes to answer a buyer's questions. WooCommerce's guidance says to aim for completeness and not worry about word count.