Quick Core Web Vitals Fixes You Can Request This Week

The fastest way to waste a week on site speed is to fix the right thing in the wrong order. Teams feel a laggy click and go hunting for JavaScript. The pass they lost was almost certainly gone before the page ever finished drawing.

Aim at LCP First. That Is Where Most Sites Lose the Pass.

In the May 2026 CrUX release, 55.9% of the 18,445,974 tracked origins passed all three Core Web Vitals. The individual pass rates say where the failure lives: LCP 68.6%, CLS 81.3%, INP 86.6%^[1]. Loading is the weakest link on most sites, not responsiveness.

One note on that source. Google publishes CrUX as a public dataset of real Chrome visits^[2], but it does not ship a single tidy document with the monthly roll-up. The figures above come from an aggregator reading the same public data. Treat them as directionally solid rather than as an official Google press release, and check the underlying dataset yourself if the exact decimal matters to a board deck.

The ordering matters more than the decimal. INP is the best-passing of the three, by a wide margin. If a site is failing the overall assessment, the odds strongly favor LCP as the culprit. That runs against instinct, because slowness is something you feel when you click, and clicking is the thing INP measures. Before you brief anyone, read what each of the three metrics actually measures. If the field data genuinely points at interactivity, go straight to the INP deep dive instead of the list below.

LCP breaks into four parts. Google’s own guidance puts roughly 40% of it in Time to First Byte, and another 40% in how long the LCP resource takes to download. Resource load delay and element render delay each account for under 10%^[3]. That split is the whole map. Two of the fixes below shrink the download. One removes a delay that should not exist. One touches the server response, and it is not a quick win at all.

The Two Fixes You Can Request Without a Sprint

Two changes move LCP more than anything else a marketing team can do alone: shrink and convert the image that is the LCP element, and stop lazy-loading it. In 2024, HTTP Archive found an image is the LCP element on 73.3% of mobile pages^[4]. Fix the image, fix the metric.

Start with weight and format. Google’s own guidance puts WebP files 25% to 35% smaller than the JPEG or PNG equivalent, with Facebook reporting roughly 80% savings on PNGs specifically^[5]. That win is still sitting unclaimed on most sites. As of the 2024 Web Almanac, WebP accounted for 12% of images on the web and AVIF for 1.0%, against JPEG at 32.4% and PNG at 28.4%^[7]. A Series B B2B SaaS marketing team I worked with had a homepage hero exported straight from a design file at full canvas resolution. CSS then scaled it down to a third of that size. Nobody had done anything wrong. Nobody had been asked to check either.

This one is genuinely marketer-reachable. Most modern CMS setups and image plugins convert on upload or serve WebP automatically once the setting is on. You do not need a ticket to re-export a hero at the dimensions it actually renders at.

The second fix is the one that surprises people. Lazy loading is the classic quick-win listicle entry, and applied to the wrong image it makes the page slower. Google’s guidance is blunt about it: never lazy-load the LCP image, because that always adds resource load delay^[3]. In 2022, a controlled A/B test on WordPress archive pages found that turning off above-the-fold lazy loading improved LCP by 13% on desktop and 15% on mobile^[6]. In 2024, HTTP Archive still found 16% of mobile sites lazy-loading their LCP element^[4].

That same Series B team had a page builder set to lazy-load every image on the page, hero included. Two settings, one CMS session, no deploy. The pattern repeats because the toggle is usually global and nobody thinks of the hero as an image to exclude.

Below the fold, lazy loading is fine and mostly already happening: 33% of pages use loading=lazy^[7]. It saves bytes. It rarely saves the pass. Rank it accordingly.

Is font-display: swap Actually a Safe Quick Win?

Not always. font-display: swap stops the browser from hiding text for up to three seconds, which helps LCP and FCP. It also introduces a font swap, and Google’s own font guidance lists swap among the values that can cause layout shifts^[8]. One vital improves while another can regress.

This is the honest edge of the “quick wins” genre. The fix is real and the mechanism is real. Text hidden behind an unloaded web font is text that cannot count toward LCP. But swapping a fallback for a web font of a different width moves everything below it, and that movement is exactly what CLS scores. Google’s more conservative recommendation, font-display: optional, caps the text-render delay at 100 milliseconds and avoids the swap entirely, at the cost of sometimes not using the font at all^[8].

Preloading has the same shape of trade. It makes one font discoverable earlier by taking bandwidth away from everything else in the queue, including, on a bad day, the LCP image you just spent a week shrinking. Preload the one font that renders above the fold. Preloading four weights because they are all in the brand kit is how a speed fix becomes a speed problem.

None of that is a reason to skip it. It is a reason to route it through someone who will measure CLS before and after, rather than someone who will flip the toggle and close the ticket. Fonts are the first item on this list that genuinely needs a developer, and the first one where “we shipped it” and “it worked” are different claims.

Who Actually Owns the Chat Widget?

Usually nobody. In 2024, HTTP Archive found 92% of pages carry at least one third party, and scripts are the largest slice of those requests at 30.5%^[9]. Every one of those scripts competes for the same main thread a visitor’s first click needs. Auditing the list is a decision, not a build.

INP measures the gap between a click and the browser painting the result, and the good threshold is 200 milliseconds or less at the 75th percentile. Google names main-thread activity, including script loading, parsing and compiling, as a primary source of input delay^[10]. A chat widget, a heatmap recorder, and three ad pixels all doing that work while someone taps a nav link is how a site with clean code still feels slow.

The audit is not technical. Open the tag manager, list every marketing script currently firing, and put a name next to each one. A Series C team I worked with found a session-recording script still loading on every page eight months after the trial had ended. Nobody had removed it because nobody had ever owned it. That is the Website Ownership Gap showing up as a performance number. It is also why this fix sits mid-axis on effort rather than at the left edge. The decision is yours. The implementation, at least for anything hardcoded into a template rather than deployed through a tag manager, is not.

Two rules make the cleanup safe. Marketing tags belong in the tag manager, not in the theme, so removing one is a config change rather than a deploy. And anything that can wait until after the first interaction should load after it, which is a developer conversation, not a checkbox.

The Order: What to Ship Monday, and What Needs a Sprint

Ship in descending order of impact per unit of risk: image weight and format, then the hero’s lazy-load flag, then the third-party script list, then fonts, then the CDN. The last one has the highest ceiling and the longest tail. It is a project, not a quick win.

That last item deserves its honesty. Time to First Byte is roughly 40% of LCP^[3], which makes edge caching the highest-ceiling item on any performance list. It is also the one that touches origin configuration, cache rules, and anything personalized or logged-in. Checking whether a CDN is in front of the site takes five minutes. Changing what it caches is a real engineering change with a real regression surface, and it belongs in a full performance audit rather than in a week of quick wins.

There is one more free item worth naming. As of the 2024 Web Almanac, only 32% of images carry both width and height attributes^[7]. Missing dimensions are a direct CLS cause and usually a one-line template fix. It will not rescue an LCP failure, but it is the cheapest CLS insurance available.

Ship them one at a time. A Series A team once turned on every toggle in a caching plugin in a single afternoon. The mobile nav broke, and two days went into working out which toggle did it. Batching changes destroys the only thing that makes a quick win defensible: knowing which change produced the number. Make one change, regression-proof the change, then wait for field data rather than a lab score to confirm it.

None of this is a substitute for knowing why the speed matters in the first place. It is the shortest path to a measurable move while the business case for marketing site speed is still being made internally. Two fixes you can request yourself, three you cannot, and an order that stops the effort from landing on the vital that was already passing.

Sources

1. Digital Applied, Core Web Vitals Benchmarks 2026: Pass Rate Reference – Secondary aggregator reporting the May 2026 CrUX release (published June 9 2026), 18,445,974 origins measured; 55.9% pass all three (down 0.8pp from April); LCP 68.6%, CLS 81.3%, INP 86.6% rated good. Cited as an aggregator because the CrUX release itself publishes no single roll-up document; figures are reproducible from the public CrUX dataset via the HTTP Archive Core Web Vitals Technology Report ↩
2. Google, Chrome UX Report Documentation – Primary documentation for CrUX, the public dataset of real Chrome user experiences supplying the field data behind every Core Web Vitals assessment ↩
3. Google web.dev, Optimize Largest Contentful Paint – Official guidance; LCP subparts run roughly 40% Time to First Byte, under 10% resource load delay, roughly 40% resource load duration, under 10% element render delay; states “Never lazy-load your LCP image”; recommends fetchpriority=”high” on the likely LCP image ↩
4. HTTP Archive, 2024 Web Almanac: Performance – Published November 2024, built on Chrome UX Report field data from January through October 2024; an image is the LCP content type on 73.3% of mobile pages vs 26.3% text; 16% of mobile sites lazy-load their LCP image; 15% use fetchpriority=high on it ↩
5. Google web.dev, Serve Images in WebP Format – Official guidance; WebP files are “usually on the magnitude of a 25-35% reduction in filesize” against JPEG and PNG; cites Facebook measuring 25-35% savings on JPEGs and 80% on PNGs, and YouTube measuring 10% faster page loads on WebP thumbnails ↩
6. Google web.dev, The Performance Effects of Too Much Lazy Loading – Published 2022; controlled A/B test on WordPress archive pages showed 13% LCP improvement on desktop and 15% on mobile when above-the-fold lazy loading was disabled; HTTP Archive correlational data put the median page without lazy loading at a 75th-percentile LCP of 2,922ms vs 3,546ms with it ↩
7. HTTP Archive, 2024 Web Almanac: Media – Published December 2024; WebP accounts for 12% of images and AVIF 1.0%, against JPEG at 32.4% and PNG at 28.4%; 33% of pages use loading=lazy; only 32% of images carry both width and height attributes ↩
8. Google web.dev, Best Practices for Fonts – Official guidance; browsers typically delay text rendering up to three seconds while a web font loads; font-display auto, block, swap and fallback “all have the potential to cause layout shifts when the font is swapped”; font-display: optional caps text-render delay at 100ms with no swap-related shift ↩
9. HTTP Archive, 2024 Web Almanac: Third Parties – Published November 2024; “the percentage of pages with one or more third parties remains high at 92%”; script is the largest third-party request type at 30.5%, ahead of image at 26.0% and html at 11.7% ↩
10. Google web.dev, Optimize Interaction to Next Paint – Official guidance; the good INP threshold is 200 milliseconds or less at the 75th percentile of page loads; input delay is caused by main-thread activity including script loading, parsing and compiling ↩

Written by Yasser Soliman

Fractional Head of WebOps

I've spent 5+ years embedded in marketing teams at B2B SaaS companies. I own the marketing website — performance, analytics, SEO, integrations — so your team ships without bottlenecks.