A business owner opens PageSpeed Insights, sees a score of 38, reads terms like Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift, and closes the tab. The numbers look bad, the terminology is unintelligible and the suggested fixes might as well be in a different language.
Core Web Vitals are not a technical beauty contest. They measure three things that affect how people experience a webpage: how fast the main content appears, how quickly the page responds when someone interacts with it and how stable the layout remains while loading. This guide explains each metric in plain English, shows what causes problems and gives you enough understanding to have a useful conversation with your developer. It connects to the broader SEO foundations in our SEO guide.
A fast, stable, responsive page does not guarantee rankings. But a slow, janky, unresponsive page makes everything else harder.
The short version
Key info |
Core Web Vitals measure three things: LCP (did the main content load within 2.5 seconds?), INP (did the page respond to interaction within 200 milliseconds?) and CLS (did the layout stay still while loading?). Google uses real user field data to grade pages as Good, Needs Improvement or Poor. Fix Poor groups first. Most problems come from oversized images, heavy scripts, render blocking resources, layout shifts from ads or embeds and slow server response. |
What Core Web Vitals actually measure
Google introduced Core Web Vitals as a set of metrics representing critical aspects of real world user experience. They currently consist of three metrics, each measuring a different stage of the page experience.
LCP (Largest Contentful Paint): How long until the largest visible content element finishes loading. This is usually the hero image, a video poster or a large heading block.
INP (Interaction to Next Paint): How long the page takes to visually respond after a user interaction (click, tap, key press). This replaced First Input Delay (FID) in March 2024.
CLS (Cumulative Layout Shift): How much the visible content moves around unexpectedly during the page lifecycle. This measures visual stability.
Together they answer: Did it load? Did it respond? Did it stay still?
LCP: did the main content load fast enough?
Largest Contentful Paint measures when the largest visible content element in the viewport finishes rendering. For most business websites, this is the hero image, a background video poster or the main heading and text block.
LCP threshold | Rating |
Under 2.5 seconds | Good |
2.5 to 4.0 seconds | Needs Improvement |
Over 4.0 seconds | Poor |
What typically causes slow LCP
Oversized hero images: A 4MB uncompressed photograph as the first thing a visitor sees. This is the single most common LCP problem on small business websites.
Slow server response: The server takes too long to start delivering the page. Cheap shared hosting under load is a frequent cause.
Render blocking resources: CSS and JavaScript files that must fully download before the browser can display anything.
Web font loading: Custom fonts that delay text rendering while the font file downloads.
Client side rendering: JavaScript frameworks that build the page in the browser rather than delivering ready HTML from the server.
Third party scripts: Chat widgets, analytics, review platforms, social embeds and advertising scripts competing for bandwidth.
What a business owner can check
Open your homepage on a phone using a normal mobile connection. If the main content takes noticeably longer than two to three seconds to appear, LCP is likely a problem. Test your most important pages, not just the homepage.
What to tell your developer
"Our hero image loads slowly on mobile. Can you check the image size, format and whether it could be served in WebP or AVIF? Also check whether CSS or JavaScript is blocking the initial render and whether the server response time is reasonable."
Tip: The hero image fix is usually the biggest single win |
Compress the hero image, serve it in a modern format, set appropriate dimensions and use a responsive srcset. This one change fixes more LCP problems than any other single action on a typical small business website. |
INP: did the page respond when someone tapped?
Interaction to Next Paint measures the delay between a user interaction (click, tap or key press) and the next visual update the browser produces. It replaced First Input Delay in March 2024 because FID only measured the first interaction, while INP measures responsiveness throughout the entire page visit.
INP threshold | Rating |
Under 200 milliseconds | Good |
200 to 500 milliseconds | Needs Improvement |
Over 500 milliseconds | Poor |
What typically causes poor INP
Heavy JavaScript execution: Large scripts that block the browser from responding while they run. Common sources include page builders, analytics, chat widgets, form platforms, cookie consent tools and social media embeds.
Too many event handlers: Every click, scroll and input triggers processing that competes for the browser's attention.
Long running tasks: Any JavaScript operation that blocks the main thread for more than 50 milliseconds can delay visual response.
Large DOM size: A page with thousands of HTML elements takes longer to update visually after an interaction. Page builders are a common cause of inflated DOM.
Form and filter interactions: Product filters, search inputs, accordion toggles and booking widgets that freeze momentarily after a click.
What a business owner can check
Tap a button, open a menu or interact with a form on your phone. If there is a noticeable pause before anything happens, INP may be a problem. Pay attention to navigation menus, booking forms, product filters and any interactive element.
What to tell your developer
"When I tap the navigation menu on mobile, there is a noticeable delay before it opens. Can you check whether heavy scripts are blocking the main thread and whether any long tasks need optimising?"
CLS: did the layout stay still?
Cumulative Layout Shift measures how much visible content moves unexpectedly during the page lifecycle. It captures the frustrating experience of text jumping as images load, buttons moving as ads appear or the page shifting when a web font replaces the fallback.
CLS threshold | Rating |
Under 0.1 | Good |
0.1 to 0.25 | Needs Improvement |
Over 0.25 | Poor |
What typically causes layout shifts
Images without dimensions: The browser does not know how much space to reserve until the image loads, then the content below jumps.
Ads, embeds and iframes: Third party content injected after the page loads pushes everything below it down.
Web fonts: Text rendered in a fallback font reflows when the custom font arrives (FOUT: Flash of Unstyled Text).
Dynamic content injection: Cookie consent banners, notification bars, chat widgets and promotional overlays that push page content when they appear.
Late loading navigation or header elements: A sticky header that loads after the page content, pushing everything down.
What a business owner can check
Load a page on your phone and watch carefully. Does anything jump, shift or move while loading? Does the text reflow? Do buttons change position? Does a banner push the content? If it moves, it is probably contributing to CLS.
What to tell your developer
"Images on the blog pages seem to cause the text to jump when they load. Can you check whether width and height attributes are set, whether the cookie consent banner is reserving space before loading and whether the web font is causing a visible reflow?"
Field data versus lab data
This distinction matters because PageSpeed Insights shows both, and they can tell very different stories.
Field data (real user data): Collected from real Chrome users visiting the page over the previous 28 days. This is what Google uses for the Core Web Vitals ranking signal and what appears in the Search Console report. Not every page has enough traffic to generate field data.
Lab data (simulated test): A one time automated test under controlled conditions. Useful for diagnosing specific problems but does not represent real user experience. PageSpeed Insights, Lighthouse and Chrome DevTools produce lab data.
Key info: Which one matters for SEO? |
Google uses field data for the page experience ranking signal. Lab data helps diagnose problems. A page can score 95 in a lab test and still fail Core Web Vitals in the field because real users on slower phones and weaker connections have a different experience. |
What to tell your developer: "PageSpeed Insights shows a high lab score but Search Console flags Poor CWV. Can you check the field data section in PageSpeed Insights? The real user experience seems to be different from the lab test."
How Google uses Core Web Vitals for ranking
Google says good page experience, including Core Web Vitals, can be a tiebreaker when content relevance is similar. It also says page experience is just one of many systems used to rank content and that great page experience does not override having great, relevant content. Google uses field data (from the Chrome User Experience Report) to evaluate Core Web Vitals at the page URL level. Where a specific URL lacks sufficient data, Google may use data from groups of similar pages. Where no page level or group data exists, the site level data may be used.
Warning: Do not oversell the ranking impact |
Core Web Vitals are a confirmed ranking signal, but they are one of many signals. A page with perfect CWV scores will not outrank a substantially more relevant, authoritative and useful competitor just because it loaded faster. Content relevance, links, expertise and business authority matter more. |
The practical sequence: fix content and authority first, then fix page experience. Do not delay publishing useful content because PageSpeed Insights shows 60 instead of 90. |
How to read PageSpeed Insights without panicking
PageSpeed Insights shows a performance score (0 to 100), field data assessments for each Core Web Vital, lab diagnostic metrics, a list of opportunities (potential savings) and a list of diagnostics (issues to investigate).
Read it in this order:
1. Check the toggle: Are you viewing mobile or desktop? Mobile is usually worse and more important.
2. Read the field data section first: This is what real users experience and what Google uses.
3. Note the Core Web Vitals assessment: Passed, failed or not enough data.
4. Then check the performance score: A useful reference but it is lab data, not the ranking signal.
5. Review opportunities and diagnostics: Focus on the largest estimated savings first.
Do not chase a perfect 100 score. Aim for all three field data metrics in the Good range. That is the threshold that matters.
Core Web Vitals in Search Console
The Search Console Core Web Vitals report groups indexed URLs by mobile or desktop, performance status (Good, Needs Improvement, Poor), metric type and groups of similar pages. It uses real user field data. URLs without enough field data may not appear.
What to do:
Prioritise Poor groups
Identify the template or page type responsible
Open example URLs in PageSpeed Insights to diagnose the cause
Fix the shared root cause on the template, not individual pages
Test that forms, tracking and functionality still work after changes
Start validation in Search Console
Allow 28 days of field data collection to see the impact
A single template fix can move hundreds of URLs from Poor to Good if they share the same page layout.
Common CWV problems by page type
Different page types tend to have different performance profiles.
Homepage
Common issues: oversized hero image or video, multiple carousels, heavy chat widget, social feed embeds, several tracking scripts loading simultaneously and auto playing background media. The homepage often carries the heaviest third party script load.
Service pages
Common issues: large background images, embedded maps, booking or scheduling widgets, review platform embeds and video testimonials loading immediately rather than on interaction.
Blog articles
Common issues: uncompressed inline images, heavy social sharing widgets, related post carousels, comment systems and embedded content from external platforms.
Product pages
Common issues: multiple high resolution product images without lazy loading, product review widgets, zoom functionality, dynamic pricing and size selectors triggering layout shifts.
Location pages
Common issues: embedded Google Maps loading eagerly on every location page, gallery images and location specific widgets adding weight.
Page builders and Core Web Vitals
Page builders are one of the most common causes of poor Core Web Vitals on small business websites. Elementor, Divi, WPBakery and similar tools can produce inflated HTML, excessive inline CSS, heavy JavaScript, large DOM sizes and render blocking resources. The guide to page builders explained compares performance impact across the main options.
Why this matters: A page builder may produce 3,000 to 15,000 DOM elements for a page that could be built with 300 to 500. Every additional element adds to render time and interaction delay.
Tip: You do not need to abandon your page builder |
Many performance problems are solvable within the existing tool through image optimisation, script deferral, component choices and layout practices. A full platform switch is sometimes justified, but it is usually the last resort rather than the first action. |
Third party scripts: the hidden performance cost
A typical small business website may load Google Analytics, Google Tag Manager, Meta Pixel, Google Ads conversion tracking, a chat widget, a cookie consent tool, font loading, social media embeds, a reviews platform, a booking system and a CRM integration. Each script competes for bandwidth and processing time.
What to audit:
Which scripts are installed?
Which are actually used?
Which load on every page versus only needed pages?
Which block rendering?
Which fire on page load versus on interaction?
Which can be deferred, delayed or loaded conditionally?
The most impactful scripts to defer or delay are usually chat widgets, social embeds and review platforms that are not needed immediately on page load.
Images: the most fixable performance problem
Images cause more LCP and CLS problems on small business websites than any other factor. The good news is that image optimisation produces the largest measurable improvement with the least technical risk.
Image checklist:
Serve images in WebP or AVIF format where browser support exists
Compress images appropriately (a hero image rarely needs to be over 200KB)
Set explicit width and height attributes on every image to prevent layout shifts
Use responsive srcset to serve appropriate sizes for different devices
Lazy load images below the fold
Do not lazy load the hero image (it is the LCP element and needs to load immediately)
Use a CDN for image delivery where available
A developer can fix CSS and JavaScript. A business owner can immediately check whether hero images are 4MB JPEG files that should be 150KB WebP files.
Web fonts and text rendering
Custom fonts create two common problems: delayed text rendering (text is invisible until the font loads) and layout shifts when the custom font replaces the fallback (text reflows because the fonts have different dimensions).
Practical font checklist:
Use font-display: swap so text remains visible while fonts load
Preload the primary font file
Limit the number of font families and weights
Use system font stacks where brand requirements allow
Choose a fallback font with similar proportions to reduce reflow
Every additional font weight or family adds a file to download. Three weights of one family is usually sufficient for most business websites.
Hosting and server response time
A slow server delays everything. If Time to First Byte (TTFB) is consistently above 600ms, the page starts at a disadvantage regardless of how well the frontend is optimised.
Common hosting problems:
Cheap shared hosting under load
Server located far from the target audience (US server for Australian users)
No page caching or object caching
Unoptimised database queries
No CDN for static assets
For Australian businesses targeting Australian users, a server in Sydney or Melbourne (or at minimum, a CDN with Australian edge locations) makes a measurable difference. The broader speed picture is covered in the website speed and SEO guide.
Mobile versus desktop: why mobile matters more
Google predominantly uses the mobile version of pages for indexing and ranking. Mobile users typically have slower connections, less processing power and smaller screens. A page that scores well on desktop may fail all three CWV metrics on mobile. The mobile SEO guide covers the broader mobile picture.
Mobile specific checks:
Test on a real phone, not just a desktop browser's responsive mode
Check on a mid range device, not just the latest model
Test on mobile data, not just WiFi
Check whether heavy hero video or carousels are still present on mobile
Verify tap targets are usable without zooming
Confirm the mobile menu does not cause layout shifts
How to prioritise CWV fixes
Not every PageSpeed suggestion deserves equal attention. Prioritise based on impact and feasibility.
Priority | Action | Typical impact |
1. Fix Poor groups first | Address pages flagged Poor in Search Console | Moves pages from penalty territory to eligible |
2. Fix the template, not one page | Most CWV issues are shared across page types | One fix can improve hundreds of URLs |
3. Hero image optimisation | Compress, convert format, set dimensions, use srcset | Often the single largest LCP improvement |
4. Defer non essential scripts | Delay chat, social embeds, review widgets | Reduces main thread blocking |
5. Reserve space for dynamic content | Add dimensions to images, ads, embeds | Prevents layout shifts |
6. Fix font loading | font-display swap, preload, limit families | Reduces render blocking and CLS |
7. Improve server response | Better hosting, caching, CDN | Foundational improvement for all metrics |
8. Reduce DOM complexity | Simplify page builder output where possible | Improves INP and overall responsiveness |
Warning: Do not break functionality chasing a score |
Test forms, tracking, booking systems and conversion events after every performance change. A page that loads in 1.2 seconds but has broken conversion tracking is worse than one that loads in 2.8 seconds with everything working. |
What to send your developer
Do not send: "PageSpeed says 38. Fix it."
Send a structured ticket:
Page URL: The specific page or template affected
Metric: Which CWV metric is failing (LCP, INP, CLS)
Source: Field data from Search Console or PageSpeed Insights
Device: Mobile, desktop or both
Suspected cause: Hero image, chat widget, page builder, font, hosting
Business priority: Service page, product category, homepage, landing page
Acceptance criteria: "All three CWV metrics in the Good range on mobile field data within 28 days of deployment"
A 30 day Core Web Vitals action plan
Week | Focus | Actions |
Week 1 | Measure and baseline | Open Search Console CWV report. Record Poor, Needs Improvement and Good page counts for mobile and desktop. Test the homepage, main service page, one blog article and one product or location page in PageSpeed Insights. Record field data for each. Screenshot the current state. |
Week 2 | Diagnose and plan | Identify which metric fails on which template. List suspected causes per page type. Check image sizes, scripts, fonts and server response. Review page builder configuration. Prioritise by business importance and estimated impact. Create developer tickets. |
Week 3 | Implement high impact fixes | Compress and convert hero images. Defer non critical scripts. Add image dimensions. Fix font loading. Address the largest LCP contributor. Test forms, tracking and booking after each change. Deploy one template fix at a time. |
Week 4 | Validate and monitor | Re test affected pages in PageSpeed Insights. Confirm field data is beginning to improve (allow 28 days). Start CWV validation in Search Console. Check that forms, analytics and conversion tracking still function. Document changes. Schedule 90 day follow up review. |
Use the website launch checklist alongside CWV fixes to ensure no functional elements are broken during optimisation.
Core Web Vitals during a website redesign
A redesign is the best opportunity to set CWV foundations correctly from the start. If you are working with a web design Melbourne team, include CWV requirements in the project scope from the beginning, not as an afterthought.
Pre launch CWV checklist:
Hero images optimised and properly sized
Image dimensions set on all images
Scripts deferred or delayed where possible
Font loading strategy implemented
Page builder output reviewed for DOM complexity
Third party scripts audited
Mobile tested on real devices
Forms, tracking and conversion events confirmed working
All three CWV metrics tested in Good range on mobile
Fixing CWV after launch costs more time, more money and carries more risk than building it right during development.
Common Core Web Vitals mistakes
Mistake | Better approach |
Chasing a perfect 100 lab score | Focus on all three field data metrics reaching Good |
Optimising desktop only | Mobile is the priority for both users and indexing |
Deferring everything including critical CSS | Critical rendering resources still need to load early |
Removing all images to improve speed | Optimise images rather than removing useful content |
Installing a caching plugin and calling it done | Caching helps but does not fix image, script or font problems |
Testing only the homepage | Test every template type: service, blog, product, location |
Breaking forms to improve scores | Always test conversion actions after performance changes |
Treating PageSpeed score as the ranking signal | Google uses field data, not the lab score |
Ignoring INP because FID was fine | INP replaced FID and measures the full session, not just first interaction |
Panicking over a 60 score on a page that ranks and converts | Prioritise by business impact, not score anxiety |
What we recommend at Elev8d
Core Web Vitals are part of every website project and SEO programme we deliver. During a build, we set image standards, font loading, script deferral and mobile testing from the start. During an optimisation programme, we prioritise Poor groups in Search Console, fix template level issues and confirm functionality after every change. Our approach as an SEO Melbourne provider treats performance as a permanent requirement, not a one time project.
For most small businesses, the highest impact CWV work is three things: compressing hero images properly, deferring non essential third party scripts and ensuring images have explicit dimensions. Those three changes resolve the majority of Poor assessments without requiring a platform switch or a full rebuild.
FAQs
What are Core Web Vitals?
Three Google metrics measuring real user page experience: LCP (loading speed of main content), INP (responsiveness to interaction) and CLS (visual stability during loading).
Do Core Web Vitals affect Google rankings?
Yes, they are a confirmed ranking signal, but one of many. Content relevance, authority and usefulness typically matter more. CWV can act as a tiebreaker between similarly relevant pages.
What is a good PageSpeed Insights score?
The score is lab data and not the ranking signal. Focus on the field data section: all three CWV metrics (LCP, INP, CLS) should be in the Good range.
What replaced First Input Delay?
Interaction to Next Paint (INP) replaced FID in March 2024. INP measures responsiveness throughout the full page visit, not just the first interaction.
Does my website need a perfect 100 score?
No. The goal is all three field data metrics in the Good range. A score of 70 with good field data is better than a score of 95 with poor real user experience.
Why does my mobile score differ from desktop?
Mobile users typically have slower connections, less processing power and smaller screens. The same page often performs significantly worse on mobile.
Do Core Web Vitals matter for Google Ads landing pages?
Google Ads uses landing page experience as a Quality Score factor. Fast, stable, responsive pages tend to receive better Quality Scores, which can reduce cost per click.
Will fixing Core Web Vitals guarantee better rankings?
No. CWV improvements ensure the page is not held back by poor experience, but they do not override content quality, relevance, authority or links.
How long do CWV improvements take to show?
Field data updates over a 28 day rolling window. Search Console may take several weeks to reflect changes. Ranking impact, if any, may take longer.
Can I fix Core Web Vitals without a developer?
Some changes like image compression and removing unused plugins can be done without a developer. Script optimisation, font loading and template changes typically need technical help.
Next steps: pick your path
Path 1: Check your numbers. Open PageSpeed Insights, test your homepage and main service page on mobile. Read the field data section. If all three metrics are Good, you are in solid shape. If any are Poor, follow the 30 day plan.
Path 2: Fix it yourself. Start with the hero image. Compress it, convert to WebP, set dimensions. Then defer your chat widget and social embeds. Those two changes often move a page from Poor to Needs Improvement or better.
Path 3: Get it done properly. If your CWV numbers are Poor across multiple templates and you are not sure where to start, get in touch. We will audit every template, prioritise by business impact and fix the performance problems without breaking what is already working.
Core Web Vitals are not a beauty contest. They measure whether a page loads fast enough, responds fast enough and stays still. Fix the worst problems first, protect what is working and measure the result with real user data.
Sources and further reading
Google: Core Web Vitals overview. Google's official CWV documentation for site owners.
web.dev: Core Web Vitals. Technical definitions, thresholds and measurement guidance.
Google: PageSpeed Insights. Test your pages and view field and lab data.
Google: INP documentation. Interaction to Next Paint explained.
Google: Page experience in search results. How Google uses page experience signals.
Chrome UX Report. The field data source behind CWV reporting.
General information only. Rules vary by situation, particularly around advertising claims, privacy, reviews and consumer law. If you are unsure about compliance, get professional advice.
