fix guide · public browser check + paid fix

core web vitals report 'poor' on google search console

lcp, inp, or cls is failing on the mobile column. the fix is almost always one of four images, fonts, javascript, or layout.

core web vitals are google's three numeric measures of page experience: lcp (how long until the biggest visible thing appears), inp (how fast the page responds to a tap), cls (how much the layout jumps as it loads). google measures these on real visitors via the chrome user experience report. they affect rankings as a tiebreaker. they affect visitor behaviour much more directly — slow lcp loses people before they read; high cls makes them mistap; bad inp makes the site feel broken.

what this looks like to a visitor

google search console → core web vitals report shows 'poor urls' on mobile
lcp (largest contentful paint) is over 4 seconds
inp (interaction to next paint) is over 500 ms
cls (cumulative layout shift) is over 0.25

what a public browser check can see

lcp candidate

we identify the largest element shown above the fold on mobile and measure how long it takes to paint. usually a hero image, sometimes a heading.

render-blocking resources

we list every css and javascript file that blocks the first paint. each one is a fix candidate (defer, async, or preload).

image sizing

we check whether images have width and height attributes set. missing dimensions cause the browser to reflow on image load, which spikes cls.

third-party widget list

third-party widgets (chat, analytics, ads) are almost always the inp killer. we list which load on the homepage so you know which to defer.

we do not log into your site. we do not scrape customer data. we open your public homepage in a real browser session and report what we see. no security claims unless we can prove them from the public surface.

the deeper picture

the four causes that explain almost every fail: (1) the hero image is too heavy. a 2 mb png at the top of your homepage will dominate lcp. fix: webp, sub-300 kb, served at the right resolution for the viewport. (2) render-blocking css. every <link rel="stylesheet"> in the head delays first paint until it finishes downloading and parsing. fix: inline critical css, defer the rest. (3) cls from images without dimensions. an image loading at unknown size shifts everything below it. fix: add width and height attributes; the browser reserves the right amount of space upfront. (4) inp from third-party scripts. ten analytics tags and three chat widgets fighting for the main thread make tap response feel laggy. fix: defer or remove the ones not earning their place.

fix it yourself

shrink the largest above-the-fold image and serve it as webp. set width and height attributes on every <img> tag. add font-display: swap to your font css. defer non-essential javascript with the defer attribute. remove any chat widget or analytics tag you are not using. test again from pagespeed.web.dev — same data google uses.

run the audit on YOUR site — check for "core web vitals report 'poor' on google search console"

we open your homepage in a real headless browser and report what we see. no login, no plugin install.

public browser check · no signup · result on the next page

paid fix

or pay us once.

you can fix all four if you are willing to learn pagespeed insights. it is the same dashboard google uses, free, and the recommendations are specific. if the site is more complex than a single homepage, or you have tried and the score still fails, the $149 emergency fix: we fix the four patterns on the homepage and up to two key landing pages, ship before/after lighthouse scores, done in two days.

let us fix it — emergency website fix $149 run a deeper audit

frequently asked

how much does cwv affect my google ranking?

as a tiebreaker. google has stated this directly. the bigger effect is on bounce rate and conversion — fast pages keep visitors longer, which itself feeds rankings.

do i need to fix cwv on every page or just the homepage?

the report ranks by impressions. fix the top three urls first — they are usually 80% of your traffic. then the next three. you do not need to fix the long tail.

is pagespeed insights the same as the public check?

the public check uses a single load to surface visible issues. pagespeed insights runs both lab and field data and gives you the formal cwv numbers. use both — public check for first pass, pagespeed insights for the formal score.

what if my host is slow no matter what i do?

some shared hosts cannot deliver good ttfb (time to first byte). a cdn in front (cloudflare free tier) fixes ttfb for most visitors. if it does not, the host is the problem and migration is the real fix.

other fix guides

why is my wordpress site slow— what an external browser sees when your wordpress homepage takes too long to render — and the four things that are almost always behind it.
shopify checkout feels broken — how to find out why— a public browser check of your shopify storefront can surface the visible reasons people abandon. here is what we look for.
contact form looks fine but i'm not getting emails— this is the most common silent failure mode of small-business websites. four reasons it usually is — and how a public check can rule out the wrong ones.
wix site not showing on google — what a public check can tell you— your wix site exists, but it does not appear in google search results. four reasons that explain almost every case.

built by vøiddo — a small studio shipping ai-flavoured products, free dev tools, chrome extensions and weird browser games. legal · support@voiddo.com