What Core Web Vitals actually are
Core Web Vitals are three measurements of how a real user experiences a real page load. Largest Contentful Paint (LCP) measures how quickly the biggest piece of content above the fold becomes visible. Interaction to Next Paint (INP) measures how quickly the page responds when a user taps, clicks or types. Cumulative Layout Shift (CLS) measures how much the layout jumps around as the page loads. The three together capture the felt experience: did it load fast, does it respond fast, does it stay still.
Google uses these as a ranking signal under the wider Page Experience umbrella. The Page Experience umbrella also covers mobile usability, intrusive interstitials and HTTPS. The signal is small. It is not a tiebreaker boost; it is closer to a baseline check. A page with the best content for a query will outrank a faster page with weaker content. A page with great Core Web Vitals will not climb the rankings on Vitals alone. We see this play out in client data every month.
The reason to still take Core Web Vitals seriously is that the second-order effects matter more than the SEO signal. Slow pages convert worse. Pages that jank under the user's finger convert worse. Pages that take three seconds to respond to a tap on a "Get a quote" button lose the lead. Speed work pays for itself in conversion rate, and the small SEO benefit is a bonus, not the headline. Kinda unsexy advertising but the best money you'll ever spend if your site is genuinely slow. See speed optimisation for the service breakdown.
The ranking impact, honestly
Three things to be honest about with Core Web Vitals as a ranking factor.
It is confirmed. Google has stated repeatedly since the 2021 Page Experience update that Core Web Vitals are part of the ranking system. That has not changed. INP replaced FID in March 2024 as the responsiveness metric, but the broader signal is intact.
It is small. Google has also been clear that Page Experience is one of many signals and that great content with weak Vitals beats weak content with great Vitals. Internally we frame it as table stakes: do not have poor Vitals on your important pages, but do not expect a ranking jump from going from green to greener. The diminishing returns kick in fast.
It is field-data driven, not lab-data driven. The data Google uses for ranking is sourced from CrUX, the Chrome User Experience Report. CrUX captures real Chrome visitors on their real connections. The Lighthouse score in DevTools is lab data: a simulated load on a throttled connection. Lighthouse is for diagnosis. CrUX is for ranking. Optimising for the Lighthouse score without checking field data is one of the most common Page Experience mistakes we see.
The practical implication is straightforward. Fix the worst pages first. Get them out of Poor and into Needs Improvement. Then move Needs Improvement pages into Good where the conversion-rate upside justifies the engineering effort. Do not chase 100 Lighthouse scores; chase passing field-data Core Web Vitals on the pages that drive revenue. See Core Web Vitals explained for the full breakdown.
How Page Experience looks in 2026
Six patterns from auditing Perth and WA client sites this year. None of these are algorithmic claims; all are observation from running performance audits as part of website audits.
INP exposes JavaScript-heavy sites
INP replaced FID in March 2024 and is much less forgiving. FID only measured the first input; INP measures the worst interaction across the session. Sites with heavy third-party scripts (chat widgets, analytics, A/B testing tools, marketing pixels) often pass FID and fail INP. The fix is usually script pruning, deferring or moving work into web workers, not a CMS migration. See INP explained.
Hero images dominate LCP results
On the majority of Perth client sites, the LCP element is the hero image at the top of the page. Optimising that one image (correct format, correct dimensions, fetchpriority high, no lazy-load on above-fold) usually moves LCP from 4 seconds to under 2.5 seconds without any other changes. The image-SEO chapter covers the format and sizing discipline; the LCP chapter covers the preload and fetchpriority part.
CLS is mostly ad slots and embeds
CLS issues in 2026 cluster around three causes. Image dimensions missing from the markup. Ad slots that load late and push content. Third-party embeds (YouTube, Instagram, TikTok, maps) that resize after the initial paint. Each one has a fix. The discipline is reserving space for everything that loads after the initial HTML. See CLS fixes.
Mobile usability is no longer a separate report
Google deprecated the standalone Mobile Usability report in GSC in late 2023. The signal is now folded into Core Web Vitals (the report is split into Mobile and Desktop) and the wider crawl process. The practical workflow is to test on a real mid-range Android phone, not just on Chrome DevTools mobile emulation. The emulator misses real-device issues that affect a meaningful share of Australian users on $400 Android phones. See mobile usability.
Intrusive interstitials are still triggered by aggressive popups
The signal has been live since 2017 and it still fires. Newsletter popups that cover the main content immediately on mobile arrival from organic search hurt rankings for that page. We see it most on e-commerce sites with discount overlays and on publishers with email signup walls. Cookie banners required by AU privacy law are exempt; the rule is about content blocking, not consent UI. See intrusive interstitials.
HTTPS is now baseline, not a signal
HTTPS as a ranking factor was announced in 2014 and was always a small signal. In 2026, every reputable site is on HTTPS. The Chrome address bar marks HTTP as Not Secure. The ranking lift is functionally zero because the baseline has moved. The reason to be on HTTPS is user trust and modern-web compatibility (HTTP/2, service workers, modern browser APIs all require HTTPS). See HTTPS as a ranking factor and the technical HTTPS implementation guide.
The 8 sub-topics that make up the pillar
This pillar splits into eight chapters. Each one covers a sub-topic you will hit the moment you start taking Page Experience seriously for an Australian business.
- Core Web Vitals explained. The three metrics in plain English. What LCP, INP and CLS measure, the published thresholds, and how field data differs from lab data.
- LCP optimisation. The step-by-step for finding your LCP element, optimising the hero image, preloading the right resources, and getting LCP under 2.5 seconds.
- INP explained. Why INP replaced FID, what gets measured, how to identify long tasks tied to interactions, and the JavaScript-pruning workflow.
- CLS fixes. The four causes of layout shift, the reserving-space discipline, and the ad and embed patterns that ship without breaking CLS.
- Mobile usability. Why the standalone report is gone, what mobile-first actually means in 2026, and the real-device testing workflow.
- Intrusive interstitials. What triggers the signal, what is exempt, and how to run promotional popups without hurting rankings.
- Lighthouse explained. What the Lighthouse score is and is not. How to read each audit category and where it fits in the diagnosis-to-fix workflow.
- HTTPS as a ranking factor. The 2014 announcement, why it matters now, and the HTTPS migration checklist that does not destroy organic traffic.
Our framework: the Page Experience stack
Every Page Experience engagement we run for a Perth or WA client is built around four layers. Skip a layer or work them out of order and the speed work returns no measurable benefit.
Layer 1: Measure the field data
Before touching code, pull the field data. The GSC Core Web Vitals report shows which URL groups pass, need improvement or fail. The CrUX field-data view in PageSpeed Insights shows the same data per URL. This is what Google uses; this is what you optimise for. The lab data in Lighthouse is for diagnosis only. See Google Search Console for the reporting workflow.
Layer 2: Diagnose with lab tools
Once you know which pages have the problem, run Lighthouse and the Chrome DevTools Performance panel on those pages. Identify the LCP element. Find long tasks tied to INP. Trace the layout shifts that drive CLS. Lab tools give per-element diagnostics that field data does not. See Lighthouse explained.
Layer 3: Fix the templates, not the pages
One badly optimised hero image is a page-level fix. The same image being badly optimised on every product template is a template-level fix that improves thousands of pages at once. GSC groups URLs by template-style similarity for exactly this reason. Always fix at the template level when the same issue affects multiple URLs. See image SEO for the image-level fixes and JavaScript SEO for the JS-level fixes.
Layer 4: Wait 28 days and re-measure
Field data is a 28-day rolling 75th percentile. A fix shipped today only starts showing in the field data report two to four weeks later, and only fully reflects after 28 days. Do not panic when the lab score is green and the field report still shows red for a few weeks. Do not declare victory either; the field number is the one Google uses.
The order matters. Most teams skip Layer 1 (field data) and jump to Layer 2 (Lighthouse) because Lighthouse is in DevTools and CrUX feels harder to find. The result is teams chasing a Lighthouse 100 on pages that already pass the field data and ignoring the pages that fail. Pull the field data first.
Where most businesses get this wrong
From auditing Perth and WA businesses through 2025 and 2026, the same six failure modes come up.
- Pulling field data from GSC and CrUX before touching code.
- Fixing the worst URL group first, not the most interesting page.
- Treating LCP, INP and CLS as three separate engineering problems.
- Optimising at the template level so one fix improves hundreds of pages.
- Real-device testing on a mid-range Android phone, not just on the office MacBook.
- Reserving space for every image, ad and embed to keep CLS at zero.
- Chasing a Lighthouse 100 on pages that already pass field data.
- Optimising a single page while ignoring the template that drives the issue.
- Adding a chat widget, an A/B testing tool and three marketing pixels and wondering why INP tanked.
- Treating the standalone Mobile Usability report as still active when it was deprecated in 2023.
- Running aggressive newsletter popups on mobile organic landing pages.
- Selling Core Web Vitals work to clients as if it will double their rankings.
The single biggest mistake we see in 2026 is the Lighthouse 100 chase. The agency builds a beautiful score on the homepage, the homepage was already green in field data, and the e-commerce product pages that drive revenue still fail Core Web Vitals because nobody pulled the field-data report. The fix is to always start with field data, always fix the worst URL group first, and only invest engineering effort where it will move the field-data number on a page that matters.
Tools and a checklist
You do not need an expensive stack to run Page Experience properly. Six inputs, most of which are free.
- Google Search Console Core Web Vitals report. Free. The field-data view grouped by URL template. Start here every month. See Google Search Console.
- PageSpeed Insights. Free. Combines CrUX field data with a Lighthouse lab run for a single URL. The fastest way to see both data sources side by side.
- Lighthouse in Chrome DevTools. Free. The diagnostic tool. Use the Performance panel alongside Lighthouse for deeper traces. See Lighthouse explained.
- Chrome DevTools Performance panel. Free. The trace view for diagnosing long tasks (INP) and layout shifts (CLS). Use CPU throttling at 4x to simulate a mid-range Android phone.
- A real mid-range Android phone. Cheap. Emulation misses real-device issues. We keep a sub-$400 Pixel A in the office for mobile testing.
- WebPageTest or DebugBear. Paid, optional. For deeper waterfall traces, geographic testing, and historical monitoring. Useful for large sites; overkill for small ones.
For the wider Hub context this pillar plugs into, the Technical SEO pillar covers the broader crawler and indexing layer, the On-Page SEO pillar covers the markup-level work (image SEO and header structure in particular), and the SEO Measurement pillar covers how to track the impact alongside other KPIs. The speed optimisation service is the most directly aligned service we run.
A 10-point Core Web Vitals readiness checklist
- Is the GSC Core Web Vitals report being pulled monthly?
- Is the field data in CrUX reviewed alongside Lighthouse lab data?
- Are the worst URL groups identified by traffic, not by interest?
- Is the LCP element documented for each major template?
- Is every above-fold image preloaded with fetchpriority high?
- Are width and height attributes set on every image?
- Is JavaScript audited quarterly for unused scripts and third-party bloat?
- Are ad slots and embeds reserving space to prevent CLS?
- Is real-device testing on a mid-range Android phone part of the QA flow?
- Is HTTPS configured properly with HSTS and modern TLS, not just an SSL cert?
What to read next
Once you have read this pillar, the natural next steps are:
- Core Web Vitals explained. Start here. The three metrics, the thresholds, and the field-versus-lab distinction.
- LCP optimisation. The single highest-impact fix on most sites: get the hero image right.
- INP explained. The new responsiveness metric that exposes JavaScript-heavy sites.
- CLS fixes. The reserving-space discipline that prevents the jank.
- JavaScript SEO. The cross-pillar piece on the JS-level decisions that affect both crawl and performance.
- Image SEO. The cross-pillar piece on image-level optimisation that drives LCP wins.
- Google Search Console. The reporting tool where you pull the field data.
- SEO Glossary. Page Experience entries (core-web-vitals, page-speed, lighthouse, render-blocking, mobile-first, https-ssl) all defined in plain English.