Core Web Vitals are Google’s user-experience metrics for speed, responsiveness, and visual stability. Here’s what LCP, INP, and CLS mean, what “good” looks like, and how to improve them without guesswork.
WebHouz
Core Web Vitals are three user-experience metrics that Google uses to evaluate how fast and stable your website feels for real visitors. They are part of Google's page experience signals and influence search rankings — but more importantly, they measure things that directly affect whether someone stays on your page or leaves.
In one sentence: Core Web Vitals measure how quickly the main content loads (LCP), how responsive the page feels when someone interacts with it (INP), and whether the layout jumps around while loading (CLS).
Understanding each metric, what causes poor scores, and what fixes actually work is the foundation of any performance improvement project. This guide gives you all three.
Field data: Real-user performance data collected from actual visitors to your site via the Chrome browser. This is what Google uses for ranking signals.
Lab data: Simulated test results generated by tools like Lighthouse. Useful for debugging and reproducing issues, but not what your real users experience.
TTFB (Time to First Byte): How quickly your server starts sending a response. High TTFB usually means slow hosting, no caching, or heavy server-side processing.
Render-blocking: CSS or JavaScript that prevents the browser from displaying content until it has finished loading and parsing. Common cause of slow LCP.
Third-party scripts: Code loaded from external services — analytics, chat widgets, heatmap tools, advertising pixels, social media embeds. Often the biggest performance liability on a business website.
LCP measures how quickly the largest visible element on the page — usually a hero image, headline, or product photo — becomes visible to the user. It answers the question: "How long did the user stare at a mostly empty page before seeing something meaningful?"
Target: ≤ 2.5 seconds Needs improvement: 2.5s – 4.0s Poor: > 4.0 seconds
LCP is the metric most closely correlated with whether a visitor will stay or bounce. If the main content of your page takes more than three seconds to appear on mobile, a significant portion of your visitors will be gone before they see anything.
For Australian businesses running Google Ads, a slow LCP also affects your Quality Score — which directly increases your cost-per-click.
1. Oversized hero image (most common) The hero image is the LCP element on the majority of marketing websites. If it's a large JPEG that hasn't been compressed or converted to a modern format, it will load slowly on mobile — particularly on 4G or congested networks.
2. Slow server response (TTFB) If your server takes more than 600ms to respond, your LCP will suffer regardless of how well-optimised your images are. Common causes: shared hosting, no page caching, slow database queries on dynamic pages.
3. Render-blocking resources CSS and JavaScript files that load in the <head> can delay when the browser starts rendering the page. Every millisecond of render-blocking delay adds to your LCP.
4. Web fonts delaying text rendering If your primary headline is rendered in a custom web font, and that font takes time to load, the text will appear late — making the headline your LCP element, and slowing the perceived load.
<link rel="preload"> hint for the LCP image so the browser fetches it earlier in the loading process.INP measures how quickly your page responds after a user interacts with it — clicking a button, opening a navigation menu, typing in a search field, or submitting a form. It replaced First Input Delay (FID) as a Core Web Vital in March 2024 because it measures the full lifecycle of all interactions, not just the first one.
Target: ≤ 200 milliseconds Needs improvement: 200ms – 500ms Poor: > 500 milliseconds
A high INP score means your site feels laggy or unresponsive to users. Even if your page loads quickly (good LCP), if clicking a button produces a noticeable delay before anything happens, the experience feels broken — especially on mobile devices with less CPU power.
1. Too many third-party scripts (most common) Every third-party script loaded on your page — analytics tools, chat widgets, heatmap tools, advertising pixels — competes for the browser's main thread. When a user tries to interact, these scripts can block the browser from responding quickly.
2. Heavy JavaScript bundles Modern web frameworks can ship large amounts of JavaScript that must be parsed and executed before interactions work. Page builders are particularly guilty of this — Elementor, Divi, and similar tools load enormous JavaScript bundles regardless of what's actually on the page.
3. Long tasks blocking the main thread JavaScript tasks that take more than 50ms to complete are called "long tasks." When a user interacts during a long task, the browser has to wait for it to finish before processing the interaction.
4. Complex animations on mobile Heavy CSS animations, parallax scrolling effects, and JavaScript-driven motion compete with interaction processing on mobile devices that have limited CPU headroom.
For a practical audit workflow to find your INP bottlenecks: How to audit your website speed (Lighthouse + CrUX).
CLS measures the total amount of unexpected layout movement on a page during its lifetime. If elements jump around while the page loads — buttons moving, text reflowing, images popping in and pushing content down — each jump contributes to your CLS score.
Target: ≤ 0.1 Needs improvement: 0.1 – 0.25 Poor: > 0.25
Layout shift is infuriating on mobile. If a button shifts just as a user goes to tap it, they either miss it or tap the wrong element. Beyond the frustration, significant layout shift signals to Google that the page experience is poor.
1. Images and iframes without dimensions If an image loads without explicit width and height attributes, the browser doesn't know how much space to reserve for it. When it loads, it pushes everything below it down — classic layout shift.
2. Late-loading content injected above existing content Cookie banners, promotional bars, chat widget bubbles, and notification bars that appear after the page has loaded push content down. If they appear above the fold, they cause significant CLS.
3. Web font swaps changing text size When a web font loads and replaces a system fallback, the text size and spacing may change slightly — which shifts surrounding content.
4. Dynamically injected ads or embeds If an advertising slot or social embed loads and expands without pre-allocated space, it shifts everything around it.
width and height attributes. This allows the browser to reserve the correct space before the element loads.Use this decision framework:
If all three are poor, start with LCP — it's usually the highest-impact fix and often resolves through a single image optimisation change.
For a copy-paste checklist and report template you can hand to a developer: Website performance audit checklist + report template.
For a full breakdown of every tool worth using: Best Core Web Vitals tools (free + paid) in 2026.
Your CMS or framework sets the performance ceiling. A carefully optimised WordPress site can achieve good Core Web Vitals — but a page builder setup with many plugins is fighting against that goal from day one.
Sites built on modern frameworks like Next.js start with structural advantages: server-rendered or statically-generated HTML, built-in image optimisation, minimal client-side JavaScript, and no plugin conflicts. This is why our builds consistently hit Lighthouse scores of 90+.
If you've done the image and script work and your scores are still poor, the platform may be the bottleneck. Next.js vs WordPress vs Webflow: speed & SEO compared helps you decide whether optimisation or a rebuild is the right next step.
Yes. They are part of Google's page experience signals, which are used as ranking factors globally. The effect is most significant in competitive markets where multiple sites are competing for the same keywords — a faster site with better Core Web Vitals can outrank a slower competitor with otherwise similar content quality.
Often, yes. Image optimisation, script removal, and CLS fixes can be done on most platforms without a rebuild. The cases where a rebuild becomes necessary are when the platform itself (typically a page builder) is generating the excess JavaScript and CSS that's causing the problem.
Lab scores (Lighthouse) depend on test location, network throttling settings, device simulation, and cached resources. Run multiple tests and use the median. Always validate improvements with field data, not just lab scores.
If performance is tied to revenue — leads from local SEO, paid search, or ecommerce conversion — the investment in professional optimisation typically pays for itself quickly. If you want professional audit and implementation support: Website Performance service.
Run PageSpeed Insights on your homepage and your top service or product page right now. Note your weakest metric and your LCP element — that's where you start. Then follow the full audit and fix process in the hub guide: Website Performance & Core Web Vitals: the Australian business guide.
If you want a professional audit with a developer-ready fix backlog, or you're ready to discuss a performance-first rebuild, get in touch.
Let's talk about your project and how we can help you build a website that actually performs.