Why do most Carrot sites fail Core Web Vitals — and when is it worth fixing?

REI Spark is a B2B SEO platform run by a licensed California real estate agent (DRE #02006033). The operator personally rebuilt three legacy investor sites onto a custom Next.js stack between 2024 and 2026. Yuba Home Buyer is one of those rebuilds and runs as the operator-verifiable benchmark for this article. Most Carrot performance advice on the open web frames the platform as broken. It is not. Carrot's defaults are tuned for fast launch, conversion-tested templates, and broad compatibility across thousands of investor sites — reasonable trade-offs that show up as a performance ceiling on real-world hardware. This post sits within the entity-based SEO root post as the performance-side branch of the topical map.

What are Core Web Vitals?

Core Web Vitals are Google's user-experience metric set: Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift. The thresholds are 2.5 seconds, 200 milliseconds, and 0.1 respectively. Google ranks pages on real-user field data, not lab simulations.

Largest Contentful Paint measures how long the largest visible element on the page takes to render. On most investor sites, the LCP element is the hero image at the top of the homepage. INP — Interaction to Next Paint — replaced First Input Delay in March 2024 and measures how responsive the page is to the user's first tap, click, or keypress. Cumulative Layout Shift sums up unexpected visual movement during page load — buttons jumping, images popping in, text reflowing. The scale runs 0 to 1, and anything above 0.1 is "needs improvement."

Two data sources surface these metrics, and the distinction matters. Lab data comes from Google's PageSpeed Insights tool running a simulated mobile audit through Lighthouse — throttled connection, mid-tier CPU, headless Chrome. Field data comes from the Chrome User Experience Report, aggregating real measurements from real Chrome users hitting the page over the prior 28 days. Google ranks pages on field data when it exists. For sites with insufficient real-user traffic, the field dataset is empty and operators see only lab data — which is what most cash-buyer sites experience by default. Confirmed as a ranking signal since 2021, Core Web Vitals matter most on competitive queries where two or three sites differentiate on performance. See Google's Core Web Vitals documentation for the canonical reference.

Why do most Carrot sites fail INP?

Carrot sites fail INP because the default install bundles conversion-optimized JavaScript — form widgets, exit intent scripts, chat, tracking pixels — that block the main thread on a user's first tap. On low-end mobile they compound into delay.

INP measures the time between a user's first interaction and the next visual paint. The browser's main thread does the work — running JavaScript, recalculating layout, painting pixels. When that thread is busy executing scripts, every tap waits in line behind whatever the browser is currently doing. A Carrot install ships with three categories of script that all want main-thread time during page load.

Bundled tracking and conversion scripts are the largest INP contributor. A typical Carrot site runs Google Tag Manager, Facebook Pixel, the Carrot platform's own analytics, and frequently a call-tracking script — each fires on page load, each blocks the main thread for tens of milliseconds. On desktop with a fast CPU, the user never notices. On a mid-tier Android device the cumulative blocking time stretches into several hundred milliseconds. Third-party chat and form widgets — Drift, Intercom, ChatBot, custom form scripts — are the second contributor. These widgets are loaded as separate JavaScript bundles, each with its own initialization cost, each running on the same main thread that needs to respond to the user's tap. Carrot theme JavaScript is the third, smaller contributor: scroll-triggered animations, exit-intent modal triggers, sticky-header recalculation. Each script earns its place at typical traffic volumes — the form widget improves conversion by 5%, the exit-intent modal recovers 8% of abandoning visitors. The trade-off is real: the same scripts that lift conversion on a desktop visitor at 2pm compound into INP failure on a mid-tier mobile device at 9am. See Google's INP documentation for the metric specification.

Which Carrot defaults cause CLS?

Carrot defaults that cause Cumulative Layout Shift include hero images without explicit width and height, web fonts loading without font-display swap fallback dimensions, and review or testimonial widgets that inject DOM after first paint. Each is fixable but requires touching the theme.

Layout shift happens when the browser paints something, then has to re-paint because new content arrived. Three default Carrot patterns reliably produce shift.

Hero images without explicit width and height attributes are the largest CLS contributor. The browser begins rendering the page before the image finishes downloading. Without explicit dimensions, the browser cannot reserve the right amount of vertical space for the image — it paints whatever's below the image first, then the image arrives, and everything reflows downward. A single unsized hero image can produce a CLS score of 0.15 to 0.30 by itself. Web fonts loading without font-display swap fallback dimensions is the second. Carrot's default theme loads custom fonts via Google Fonts or local @font-face declarations. While the font is downloading, the browser shows a fallback font with different metrics — different x-height, different character widths. When the custom font arrives, every block of text reflows to the new metrics, shifting everything below. Late-injected widgets — review carousels, testimonial sliders, social proof badges — are the third. These widgets render their HTML via JavaScript after the page has already painted. Whatever was below the widget gets pushed down when the widget arrives, generating shift in the post-load window that CLS measures.

Each is fixable in Carrot — set image dimensions in the theme, add font-display: swap with size-adjust descriptors, reserve container space for late-loading widgets. Each requires touching theme files, which most operators understandably avoid. Carrot's defaults work across thousands of investor sites with thousands of different brand assets; strict layout reservation would constrain template flexibility.

Can you fix it without migrating?

Improve Carrot Core Web Vitals without migrating using three optimization layers: image discipline with explicit dimensions and lazy-loading, script triage with deferred non-critical scripts, and font loading with display swap and selective preload. The ceiling is PageSpeed 60–75 mobile.

Yes, for most sites and most scores. Carrot's underlying infrastructure has gotten better — the platform delivers through a tier-one CDN with image optimization and HTTP/2, and platform-level investments in defaults continue. The gap between the platform's capability and what a typical install actually ships is largely in operator-controlled settings. Three optimization layers stack without leaving the platform.

Layer one is image discipline. Compress every image with a tool that targets WebP or AVIF — most Carrot installs ship JPEG hero images at file sizes 3-5x larger than necessary. Set explicit width and height attributes on every image so the browser can reserve layout space. Lazy-load every image below the fold using the native loading="lazy" attribute. This single layer typically lifts mobile PageSpeed by 10-20 points. Layer two is script triage. Audit the Tag Manager container for scripts that no longer fire — most operator-managed GTM containers accumulate dead tags from old marketing experiments. Defer non-critical scripts using the defer attribute or by moving them into Tag Manager triggers fired on user interaction rather than page load. Remove any third-party widget the site doesn't actually use — the chat widget that gets a message a month, the exit-intent popup that hasn't converted in six months. Each removed script returns main-thread time directly to INP. Layer three is font loading. Add font-display: swap to every @font-face declaration so text renders immediately in fallback fonts while the custom font loads. Preload only the one or two critical fonts the homepage needs above the fold; let other weights and styles load naturally. Combined with size-adjust descriptors that match fallback font metrics to custom font metrics, font-driven CLS drops to near zero.

The realistic ceiling these three layers reach is PageSpeed 60-75 on mobile. That clears the "needs improvement" threshold for some queries but rarely the "good" threshold for competitive ones. The unfixable layer is server response time. Time to First Byte on Carrot's shared hosting architecture sits at 600-900 milliseconds — multi-tenant infrastructure, shared database, no edge caching. Operators cannot tune TTFB without leaving Carrot's hosting.

When does migration to Next.js pay off?

Migration to Next.js pays off when marketing spend outgrows Carrot's optimization ceiling, when competitors already ship sub-two-second LCP, or when twelve months of compounding content justifies the rebuild. Small operators with stable rankings should stay on Carrot.

Lead with who should not migrate. Operators with stable rankings, low traffic, and low marketing spend pay the full disruption cost — transition risk, link-equity preservation work, content re-mapping, redirect surface — without seeing a meaningful return from the performance gain. PageSpeed 65 versus PageSpeed 95 on a site getting 200 organic visits a month produces a difference no one notices. The Carrot install was the right choice when the site launched; it remains the right choice while the operator grows organic visibility from zero.

Three patterns flip the calculation toward migration. Marketing spend has outgrown the optimization ceiling. When an operator is spending $5,000 to $10,000 a month on Google Ads or Facebook Ads driving traffic to a Carrot landing page, every percentage point of bounce rate caused by slow load directly costs ad budget. PageSpeed 65 instead of 95 is roughly 1.5 seconds slower on mid-tier Android. That costs 8-12% of paid traffic to bounces before any conversion attempt. At $7,000 ad spend the burn is $560-840 monthly. Competitors already ship sub-two-second LCP. When two or three competitors in the same metro have already migrated, Google's ranking model rewards the faster sites on competitive queries — the operator on Carrot's optimization ceiling becomes the slow one in the SERP. Twelve-plus months of compounding content. A site with 60 to 100 ranking blog posts has accumulated link equity and topical authority that justifies the migration cost; the rebuild ports the content asset onto a stack that no longer caps performance. The full strategic comparison — content/SEO compounding, transition cost modeling, link-equity preservation, six-versus-twelve-month math — sits in a separate analysis. For operators ready to evaluate the rebuild option, REI Spark's custom Next.js websites for real estate investors are built on the same stack the YHB benchmark in the next section was rebuilt onto.

What does Yuba Home Buyer's CWV look like vs Carrot showcase benchmarks?

Audited May 3, 2026 — Yuba Home Buyer on Next.js returns mobile Lighthouse 97, LCP 2.5 seconds, Total Blocking Time 0 milliseconds, CLS 0.000. Five Carrot showcase sites returned mobile Lighthouse 40 to 76, LCP 3.8 to 8.3 seconds.

The data is from a live audit run on May 3, 2026 using Google's PageSpeed Insights API against six domains. The Carrot set is the same five showcase domains used in the entity-based SEO root post's structural-similarity study — drawn from Carrot's own public showcase page, representing the cluster of sites running the platform's default theme most tightly. None of the six domains has sufficient real-user traffic to surface Chrome User Experience Report field data. All reported metrics are lab-simulated mobile audits — the same harness Google's PageSpeed Insights tool defaults to for lower-traffic sites and the same one most cash-buyer operators see when they check their own performance.

Yuba Home Buyer (operator's custom Next.js stack): Mobile Lighthouse score 97. Largest Contentful Paint 2.5 seconds — narrowly within the "good" threshold. Total Blocking Time 0 milliseconds, the lab proxy for INP. Cumulative Layout Shift 0.000.

Carrot showcase set (n=5): Mobile Lighthouse scores were 40, 47, 57, 60, and 76 — median 57. Largest Contentful Paint ranged from 3.8 seconds to 8.3 seconds, with a median around 4.6 seconds; every site sat in "needs improvement" or "poor" territory for that metric. Total Blocking Time ranged from 0 milliseconds to 1,659 milliseconds, with three of five sites in the "poor" range. Cumulative Layout Shift ranged from 0.000 to 0.39, with one site at 0.39 — the worst score in the set.

The numbers are descriptive of the audit window, not a marketing claim. The point is not platform criticism. The point is that the performance ceiling on a custom stack is materially higher, that ceiling is what some operators need, and the gap between defaults and tuning is quantifiable rather than theoretical. The 30-to-50-point Lighthouse gap is what the trade-off costs in measurable terms.

The action: open PageSpeed Insights, enter your own URL, run a mobile audit, and record LCP, INP (or TBT as the lab proxy), and CLS. Compare against the optimization-ceiling estimate above and against the operator-verifiable numbers in this section. If the result lands in the 60-75 PageSpeed range and marketing spend is modest, the optimization layers in H2 #4 are the next move. If the result lands below that range and marketing spend is meaningful, the migration question is open. Return to the entity-based SEO framing for investor sites for the topical-authority context this performance diagnosis sits within.

By YK Kuliev, California DRE #02006033 — operating cash-buyer brand sites since 2018, REI Spark since 2025.