Core Web Vitals: How to Improve Page Experience for Australian Visitors

Core Web Vitals are the three numbers Google uses to rate what a visit to your page feels like: how soon the main content appears, how fast the page reacts to a tap, click or key press, and whether the layout holds still as it loads. Google's ranking systems use them, so a sluggish or jumpy page loses Australian visitors and some ground in search results. The phrase "core web vitals" draws about 450 searches a month in Australia, according to Ahrefs' Australian database. This guide covers each metric, the scores Google counts as good, the fixes for each one and the tools that report them. Aemorph's guide to how search engines work explains how Google crawls, renders, indexes and ranks pages.

See Aemorph's technical SEO service

Written by Kevin Dam, founder of Aemorph, who has practised SEO since 2010 and sits on the Forbes Agency Council. Aemorph is a Google Partner. LinkedIn

What Are Core Web Vitals?

Google scores every page on three Core Web Vitals: Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness and Cumulative Layout Shift (CLS) for visual stability. Each one sorts a page into "good", "needs improvement" or "poor", using the bands on Google's web.dev Web Vitals page. The thresholds are the same for an Australian site as for any other.

Core Web Vitals thresholds, as published by Google.

Sources: web.dev, October 2024 and others

What changed in March 2024?

On 12 March 2024, Interaction to Next Paint took over from First Input Delay (FID) as Google's responsiveness metric. FID only timed the wait before the browser began handling the very first interaction. INP follows every click, tap and key press for the whole visit, up to the moment the screen changes, so it tracks how responsive the page feels throughout (web.dev, INP becomes a Core Web Vital). Any Australian guide that still quotes FID and a 100-millisecond target describes a metric Google has retired.

How does Google decide whether a page passes?

Google passes a page when its 75th percentile of real visits lands in the "good" band for LCP, INP and CLS together. At the 75th percentile, three out of every four visits score at that value or better. Mobile and desktop are assessed separately, so a page that is fine on a desktop in a Sydney office fails on mobile when its phone visits are slower. Google also moves each metric through experimental, pending and stable stages, and only stable metrics count as Core Web Vitals.

Core Web Vitals in Australia: Mobile Visits, Search Share and Field Data

Mobile and desktop each carry close to half of Australian page views, so an Australian site needs to pass Core Web Vitals on both device types, and Google's search share makes its assessment the one that counts. StatCounter recorded mobile at 48.57% and desktop at 48.48% of Australian page views in September 2026, with tablets at 2.95% (StatCounter, Australia). Google held 87.9% of search engine market share in Australia in the same month, and Bing held 9.17%. Aemorph's guide to mobile SEO covers mobile-first indexing and the checks a phone layout needs.

Sources: StatCounter, September 2026 and others

The Chrome UX Report (CrUX) publishes country-level data, so you read how Chrome users in Australia experience your site rather than a worldwide average. CrUX holds real-user data at page and origin level, from Chrome users who opted in (Chrome for Developers, CrUX methodology). For a site whose buyers are mostly Australian, the Australian slice is the one to watch.

Why Do Core Web Vitals Matter for Australian SEO?

Google says its ranking systems use Core Web Vitals and advises good scores "for success with Search", which applies to Australian results as much as any. The same Google page adds that good scores in Search Console or other tools do not guarantee a top ranking, because page experience covers more than these three numbers (Google Search Central, page experience).

Do Core Web Vitals decide rankings on their own?

They do not: Google always tries to show the most relevant result, even when that page's experience falls short, so relevance leads and Core Web Vitals support it. Google groups Core Web Vitals with HTTPS, display on mobile devices, avoiding excessive ads, avoiding intrusive interstitials and main content that stands apart from everything else on the page. Outside Core Web Vitals, Google says those aspects give no direct ranking lift, though they make a site more pleasant to use. A quick page with thin content still loses to a slower page that answers the search better.

How do most websites score?

Most websites still fail on mobile: in June 2025, 48% of sites on mobile and 56% on desktop reached a good overall Core Web Vitals result. HTTP Archive's Web Almanac 2025 is the source, and the figures are worldwide rather than Australian. Australian search figures sit on Aemorph's AI search statistics for Australia page.

Source: HTTP Archive, 2025

How Do You Improve Largest Contentful Paint (LCP)?

LCP drops when the biggest element on screen, usually a hero image or a heading block, reaches the visitor sooner: a quicker server, an earlier start to the download, a lighter file and no render-blocking code. The elements LCP counts are images, video poster images, elements with a CSS background image and block-level elements that contain text (web.dev, LCP).

What slows LCP down?

LCP splits into four parts, and the longest part points to the fix: the server response, the wait before the LCP file starts downloading, the download itself and the delay before it paints. On a well-optimised page, Google's guide puts roughly 40% of LCP time on server response (time to first byte), under 10% on the load delay, roughly 40% on the download and under 10% on the render delay (web.dev, Optimise LCP). A long load delay usually means the browser discovered the image late, for example because a script adds it or a stylesheet references it.

How do you fix a slow LCP?

Work through the four parts in order: respond faster, let the browser find the LCP image early, make the file lighter and clear anything that blocks the render.

1. Cut the server response time. A content delivery network (CDN) with a node near your Australian visitors, plus cached HTML, gets the first byte to them sooner.
2. Leave the LCP image out of lazy loading. Lazy loading holds back the exact image the metric measures. Use loading="lazy" only for images further down the page.
3. Flag the LCP image as urgent. Add fetchpriority="high" to it, or preload it when a stylesheet references it, so the download begins alongside the HTML.
4. Send the main content in the HTML. Content that waits for JavaScript to build it paints later than content the server already rendered.
5. Make the image lighter. Serve WebP or AVIF at the size the layout shows. The Australian image SEO guide covers formats and compression.

How Do You Improve Interaction to Next Paint (INP)?

INP improves when the browser's main thread stays free enough to show a visible response to every click, tap and key press within 200 milliseconds. INP watches the interactions in a visit and reports the slowest one, setting aside rare outliers on pages with many interactions (web.dev, INP).

What makes INP slow?

Every interaction passes through input delay, processing duration and presentation delay, and slowness in any one of them pushes INP up. Input delay is the wait before your event handler starts, usually because another script is still busy. Processing duration is how long the handler itself runs. Presentation delay is the time the browser takes to lay out and paint the next frame, which grows on a large or complicated page.

How do you fix a slow INP?

Split long JavaScript tasks, keep each event handler as small as possible and keep the page's structure lean.

1. Give the main thread breaks. Break long tasks into pieces so the browser handles input between them; web.dev shows setTimeout as one way to yield (web.dev, Optimise INP).
2. Trim event handlers. Update what the visitor sees first, then push analytics and other background jobs to later.
3. Shrink the DOM. Fewer elements mean faster layout and painting after each interaction.
4. Hold back off-screen rendering. The CSS property content-visibility lets the browser postpone rendering content outside the viewport.
5. Stop layout thrashing. Reading layout values straight after a style change forces repeated layout work; batch the reads before the writes.

How Do You Improve Cumulative Layout Shift (CLS)?

CLS improves when every late-arriving element has space set aside for it, so text and buttons stay put after the visitor first sees them. CLS collects layout shifts into session windows that close after a one-second gap or five seconds in total, and reports the biggest window. A shift within 500 milliseconds of a visitor's own input is excluded, because the visitor expected it (web.dev, CLS).

What causes layout shifts?

The usual culprits are images, videos, ads, embeds and iframes with no set size, content inserted above what is already on screen, and web fonts that swap in at a different size. Animations that change an element's size or position also push the content around them.

How do you fix CLS?

Hold space for every element that loads late and load fonts in a way that keeps text steady.

1. Give images and videos a width and height, or a CSS aspect-ratio, so the browser saves the space before the file lands.
2. Set aside room for ads, embeds and banners. Give each slot a fixed minimum height, and place new content below the part the visitor is reading, never above it.
3. Manage web fonts. Preload key fonts, use font-display: optional where a late swap is not worth a shift, and use size-adjust so the fallback font matches in size.
4. Animate with transforms. CSS transform animations move an element without nudging what sits around it.
5. Keep pages eligible for the back/forward cache. web.dev includes this in its CLS fixes (web.dev, Optimise CLS).

Which Other Performance Metrics Help You Diagnose Problems?

Time to First Byte (TTFB) and First Contentful Paint (FCP) help explain a slow LCP, and Total Blocking Time (TBT) stands in for INP in lab tests; none of the three is a Core Web Vital. Google calls them diagnostic metrics, because they lead you to the cause behind a poor Core Web Vitals score. Lighthouse, Google's lab testing tool, combines five metrics into its performance score.

Lighthouse 10 performance score weights, from Chrome for Developers. Scores of 90 to 100 are good, 50 to 89 need improvement and 0 to 49 are poor.

Does a high Lighthouse score mean your page passes Core Web Vitals?

A high Lighthouse score does not settle it: Lighthouse runs one simulated load, while the Core Web Vitals assessment rests on 28 days of real visits. A simulated load has nobody clicking, so Lighthouse reports Total Blocking Time in place of INP. Use Lighthouse to track down causes and the field data from your Australian visitors to judge the outcome.

Sources: Chrome for Developers and others

Which Tools Measure Core Web Vitals in Australia?

Five Google tools report Core Web Vitals for an Australian site: PageSpeed Insights, the Search Console Core Web Vitals report, Chrome DevTools, Lighthouse and the Chrome UX Report (CrUX). Field data records what real visitors went through; lab data is one controlled test that you rerun while you fix.

Core Web Vitals tools compared.

How does the Search Console report group your pages?

Search Console puts URLs with a similar experience into groups and rates each group by its weakest metric, so one failing metric makes the whole group poor. A page without enough data of its own takes the rating of its origin group. Once you fix a group, select "Start Tracking" to begin a 28-day validation (Search Console Help, Core Web Vitals report).

Why do field data and lab data disagree?

Field data comes from real Chrome visitors on their own phones, computers and connections, while lab data comes from a single simulated load, so the two seldom match. CrUX only collects from Chrome users who opted in, and it excludes Chrome on iOS, Android WebView and other Chromium browsers. A page also needs enough public traffic before it shows in CrUX at all (Chrome for Developers, CrUX methodology). PageSpeed Insights' mobile lab test simulates a mid-tier phone (Moto G4) on a mobile network, so its result reflects one device and one connection, not the mix your Australian visitors use.

What happened to the Web Vitals Chrome extension?

Google stopped supporting the Web Vitals extension on 7 January 2025 and folded its features into the Performance panel in Chrome DevTools. The panel's real-time metrics view shipped with Chrome 129 in September 2024 (Chrome for Developers blog). A guide that still points you to the extension recommends a tool that gets no more updates.

Sources: Google Search Console Help and others

Turn Core Web Vitals Into a Faster Australian Site

Core Web Vitals move when you fix the cause in the page template and then watch 28 days of field data, because one template fix repairs every page built on it. Begin with the Search Console report to find the failing groups, use PageSpeed Insights and DevTools to find the cause, make the fix and start validation. If you want an experienced team to run this for your Australian site, Aemorph's technical SEO service crawls the site, checks each template against Google's good thresholds and writes each fix for your developers, who decide the pace. Aemorph is headquartered in Singapore and has no office in Australia.