Core Web Vitals are three measures of how your pages feel to real visitors. They cover main content speed, response to taps and typing, and how steady the layout stays. They matter for customers and for Google's ranking systems, though a green report doesn't guarantee rankings. Find which page type and metric are failing, then confirm the cause before you pay for a fix.
What do LCP, INP and CLS measure?
Each one covers a different moment in a visit. All three are measured on real visits rather than on a test machine.
Largest Contentful Paint (LCP): how long until the biggest image or text block in the first screen appears. It's loading, as a visitor experiences it.
Interaction to Next Paint (INP): how long until a tap, click or key press gets a visible response. It's responsiveness.
Cumulative Layout Shift (CLS): how much the content moves around unexpectedly while someone is on the page. It's visual stability.
Google's Web Vitals article sets out the pass mark. A page passes when all three are good, judged at the 75th percentile of page loads. Mobile and desktop are assessed separately. There's one exception for pages with too little INP data, covered in the PageSpeed Insights section below. LCP is measured in seconds and INP in milliseconds (ms).
Those are the top of the Good band. Here's the full scale.
Metric | Good | Needs improvement | Poor |
|---|---|---|---|
LCP | 2.5 seconds or less | Over 2.5 to 4 seconds | Over 4 seconds |
INP | 200 ms or less | Over 200 to 500 ms | Over 500 ms |
CLS | 0.1 or less | Over 0.1 to 0.25 | Over 0.25 |
Good includes its boundary. A page at exactly 2.5 seconds, 200 ms or 0.1 is good. One at exactly 4 seconds, 500 ms or 0.25 still needs improvement rather than being poor.
The 75th percentile is the value that three in four page loads meet or beat. It isn't an average or a promise about every visit. The slowest quarter can be much worse. Mobile and desktop are judged separately. So one page can pass on a laptop and fail on a phone.
Because CLS is a score, not a time, it has no unit. Each layout shift is scored by how much of the screen moved multiplied by how far it moved.
You may have seen First Input Delay in older reports. INP replaced it as the responsiveness metric in March 2024. Supporting measures such as Time to First Byte and Total Blocking Time help with diagnosis. But they aren't Core Web Vitals.
How to recognise LCP, INP and CLS problems
Each metric fails in a way you can see on a real phone. Reproduce the problem first. Then ask the developer to confirm the cause, because one symptom can have several causes. Our guide to why your website is slow covers the wider speed fixes. This section is about reading each metric and briefing the right repair.
LCP: the main content arrives late
Google's Largest Contentful Paint article defines LCP as the render time of the largest visible element. That means the largest image, text block or video in the first screen. The clock runs from when the visitor started loading the page.
The LCP element is often a hero image, but not always. Google's article on the most effective ways to improve Core Web Vitals puts a number on it. Images were the LCP element on 73% of mobile pages in 2024. That leaves about a quarter where it's something else, like a heading or a block of text. Have the developer find the actual LCP element on each template and device before choosing a fix.
For an LCP image, Google's Optimize Largest Contentful Paint guide splits the LCP time into four parts. As a rough guide, about 40% each should go to the server response and the image download. The two delays should get under 10% each. The part that's far bigger than that is where the fix is.
Part of the LCP time | What it covers | If it's the big one, check |
|---|---|---|
Server response | From the request to the first byte of the page | Hosting, redirects, caching and server work |
Load delay | From that first byte to the browser starting on the image | Lazy loading, or an image set in CSS or added by a script |
Load duration | Downloading the image itself | File size, format and dimensions |
Render delay | From the image arriving to it appearing on screen | Render blocking CSS and scripts, fonts and sliders |
One mistake is easy to make. Lazy loading suits images further down the page. Applied to the LCP image, it delays the content visitors are waiting to see. Google's guide puts it bluntly: never lazy load the LCP image.
What you notice: the main photo or heading arrives late, after the page frame appears. It's worst on a phone using mobile data.
Reproduce it: on a phone using mobile data, open the page in a private window so nothing's cached. Then note when the main image or heading appears.
Likely causes: a slow server response, an image the browser finds late, or an oversized image. Render blocking CSS or scripts are also likely causes, as is a web font holding text back.
Ask the developer: measure the four parts of LCP on the slow template. Then fix the part that's out of proportion. And make sure the likely LCP image isn't lazy loaded.
INP: the page is slow to respond
Google's Interaction to Next Paint article explains what INP measures. It's the delay between a click, tap or key press and the next visual update on screen. Across a visit, INP reports the slowest interaction, ignoring one outlier for every 50 interactions. Hovering and scrolling don't count. A visit with no interactions has no INP at all.
The delay has three parts.
INP stops at the next visible update, not at the end of the whole task. Take a form that shows "Sending" straight away, then takes four seconds to email you. That form has a fine INP and a slow back end.
A submit button that does nothing for a second has a poor INP. The customer may tap it again. A slow back end and a poor INP are different problems with different fixes.
What you notice: a menu, accordion, filter or button that hesitates before anything changes on screen.
Reproduce it: on a mid range phone, tap the menu and open an accordion. Change a product option or filter, type in the search box and submit the form. Watch for a pause before the screen reacts.
Likely causes: long JavaScript tasks from the theme, apps, tag managers or chat widgets keeping the browser busy. Another is too much work running on each tap.
Ask the developer: record the slow interaction in the Performance panel of Chrome's developer tools. Google's Manually diagnose slow interactions in the lab guide shows how. Find the phase that takes the time. Then break up or delay that work.
CLS: the layout jumps
Google's Cumulative Layout Shift article measures unexpected movement of visible content. Shifts less than a second apart, and within five seconds in all, are grouped into a burst. CLS is the largest burst during the whole time the page is open. It's not the total of every shift, and not only what happens while the page loads.
Not every movement counts. Shifts within half a second of a tap, click or key press are expected and left out. Scrolling doesn't count as that kind of input, though.
Animations that use CSS transforms don't shift the layout. Nor does new content that appears without pushing anything else. So a moving element isn't automatically a CLS problem.
The classic case is a widget that loads late and shoves the page down.
The widget pushes the enquiry button down after the page appears.
A reserved area lets the widget load without displacing the button.
Fonts need a check too. The font-display: swap setting keeps text visible while a web font loads. But if the web font renders larger or smaller than the fallback, the swap itself shifts the layout. So the setting isn't a CLS cure on its own.
What you notice: text or buttons jump just as you go to read or tap them. Sometimes it happens well after the page appears.
Reproduce it: load the page on a phone. Straight away, start reading or reach for the main button. Then scroll and use the page for a minute, watching for late banners, embeds, ads and fonts.
Likely causes: images, ads or embeds without set dimensions, and content inserted above what's already showing. Fonts that swap at a different size are another.
Ask the developer: reserve space for every late element. Insert new content below what the visitor is reading. And match the fallback font's size to the web font. Test after the load too. That's because lab tools mostly measure during the load and can report a lower CLS than real visits.
How to read field and lab results
Field data, lab tests and real journeys answer different questions. A sound brief usually needs all three.
Here's what each can and can't establish.
Evidence | Use it for | Don't infer |
|---|---|---|
PageSpeed Insights field data | Real visits to the displayed URL or origin, on one device type, over 28 days | Every URL passes because the origin passes |
PageSpeed Insights lab test | A controlled load test with diagnostic clues | A score of 90 or 100 proves real visits are good |
Search Console Core Web Vitals report | Patterns across groups of similar pages | The issue rows add up to a count of affected URLs |
A journey on a real device | Reproducing a menu, booking, filter or checkout complaint | One phone represents your whole audience |
Read them in this order:
Confirm the URL, the device tab and whether the field data covers this URL or the whole origin.
Read each metric's value and the collection period.
Inspect the lab diagnostics for likely causes.
Reproduce the affected journey on a real phone and a desktop.
Field data in PageSpeed Insights
Run a page through PageSpeed Insights. The top section, when it appears, is field data from real Chrome users. Google's About PageSpeed Insights page sets out the rules behind it. The data covers the previous 28 day collection period. So a fix released today shares that window with weeks of visits from before it.
When a URL has too little data, PageSpeed Insights falls back to the origin. The origin covers every page on the site. When the origin has too little as well, PageSpeed Insights shows no field data at all.
The exception to the all three rule matters for quiet pages. Some pages have enough LCP and CLS data but not enough INP data. For those, the assessment passes when LCP and CLS are good. That pass is no evidence that the interactions nobody measured work well. If LCP or CLS has too little data, the page or origin can't be assessed at all.
Then check who the data describes. Google's Chrome UX Report methodology counts eligible Chrome users on desktop and Android, not Chrome on iPhone. So the mobile field data leaves out every iPhone visit. The bigger your iPhone audience, the less it tells you about phone visits.
So test on an iPhone as well. Safari 26.2 arrived in December 2025. Since then, a real user monitoring tool can include iPhone visits for LCP and INP. CLS isn't covered, as Google's LCP and INP are now Baseline Newly available post explains.
The lab run and the performance score
Below the field data sits a lab test. PageSpeed Insights runs Lighthouse in a simulated environment. For mobile, that means a mid range phone on a mobile network. Lab data is good for debugging because the conditions are controlled. It isn't a record of your customers' visits.
The performance score at the top of the lab section comes from Lighthouse. The Lighthouse performance scoring page explains how it's built. Google's Lighthouse bands put 0 to 49 as poor and 50 to 89 as needs improvement. Scores of 90 to 100 count as good.
The score is lab data. The field Core Web Vitals are what Google's ranking systems use.
The score is a weighted blend of lab measures. In that page's latest weights, for Lighthouse 10, Total Blocking Time (TBT) carries the most at 30%. LCP and CLS get 25% each, with First Contentful Paint (FCP) and Speed Index on 10% each.
SourceGoogle, Lighthouse performance scoring
Nearly a third of the score rests on TBT, a lab measure that isn't a Core Web Vital. And INP isn't in it at all. That's why a lab score can disagree with the field result in either direction. Google's scoring page also says a perfect 100 is extremely challenging to achieve and not expected.
INP is missing because a standard lab run loads the page without touching it. Google's Total Blocking Time article says INP usually can't be measured accurately in the lab. It calls TBT a reasonable lab proxy for INP. But TBT isn't a substitute for INP itself.
A developer can still measure INP in the lab, by recording interactions as they perform them. They can use Lighthouse user flows or the Performance panel in Chrome.
Search Console's Core Web Vitals report
PageSpeed Insights looks at one URL at a time. Search Console's Core Web Vitals report uses the same kind of field data for the whole site. Mobile and desktop get separate reports. You need a verified property to see the report. Our guide on how to set up Google Search Console covers that.
Four things trip people up in this report:
Groups, not pages. Search Console groups URLs that give a similar experience. A group takes the slowest status of its metrics. Open several example URLs before you approve a fix for a whole template.
Gaps. A group without enough LCP and CLS data is left out. So a short report can mean thin data rather than a healthy site.
Double counting. A URL with two issues appears in two table rows. But the chart counts each URL once. Adding up the issue rows overstates the problem.
Different scopes. Group values are the 75th percentile across visits to the whole group over the last 28 days. So one URL in PageSpeed Insights can disagree with its group without either being wrong.
After a fix, clicking Start Tracking on the issue begins a 28 day monitoring session. It doesn't trigger reindexing or any other action from Google. The issue counts as fixed only if no URL on your site shows it during that window. If validation fails, fix the cause and start a new validation.
Google recommends fixing everything labelled Poor first. Our Google Search Console guide covers the other reports.
If there is no field data
No field data means there were too few eligible Chrome visits to report. That's missing evidence, not a penalty and not a pass. Small sites often don't have the traffic for it.
An origin result is context, not proof that a given page passes. Without field data, build your own evidence:
Test the homepage and a representative service, article, product and contact or checkout page, not a single URL.
Run each lab test several times under the same conditions. Compare the middle result, not the best one.
Watch someone complete the main task on a phone and a desktop, and note where it stalls.
Where the commercial value justifies it, ask a developer for real user monitoring (RUM) of your own visitors. Make sure it's privacy appropriate. Write down which visitors and browsers it covers, and what it can't see.
What load tests miss in real journeys
A clean load test can miss the complaint a customer actually made.
After the load. Interactions and layout shifts that happen once someone starts using the page never appear in a load test.
Returning visitors. They arrive with files cached and a cookie choice already made. So the page behaves differently from a first visit.
Consent choices. Accepting or rejecting tracking changes which scripts load, and so how the page performs.
Embedded tools. Booking, chat, payment and checkout tools run their own code, often from another company. You may not control it.
So test the task, not just the page. Book the appointment, filter the products or start the checkout. Do it once with the cookie banner accepted and once with it rejected.
How much do Core Web Vitals matter for SEO?
Less than the sales pitches suggest, and more than zero. Google's Understanding page experience in Google Search results page says its ranking systems use Core Web Vitals. It recommends good results for success with Search.
But the same page says good reports don't guarantee top rankings. It adds that there's more to page experience than Core Web Vitals scores. It notes Google always seeks to show the most relevant content, even when the page experience is poor.
Google also says there's no single page experience signal. It publishes no weight for Core Web Vitals and says nothing that makes them a guaranteed tiebreaker. So anyone quoting their share of the algorithm is guessing. Google even warns that chasing perfect scores just for SEO may not be your best use of time. Our guide to whether website speed affects SEO covers the wider evidence on speed, rankings and sales.
Failing is also common. Google's Chrome UX Report release notes track the share of websites with good results each month. In September 2026, most were good on each metric alone, but only 55.9% passed all three.
LCP is the metric that most often lets a site down. And one weak metric is enough to fail. That's why the combined figure is so much lower. Our own audits give the inside view. We ran 100 website audits from May 2023 to September 2026.
Of those, about 2 in 5 sites had a mobile LCP slower than 2.5 seconds. That was on the homepage or main service page. We used field data, or a lab test where a site had none.
Interaction to Next Paint replaced First Input Delay in March 2024. In audits since then, about 1 in 2 sites failed at least one Core Web Vital on mobile. We checked the same pages. Don't compare the two figures directly, because they count different sets of audits.
So treat Core Web Vitals as a customer problem first and a ranking input second. A slow, jumpy page loses people whatever it does for rankings. And relevance still comes first in search. Our guide to SEO for small business shows where speed fits in the wider plan.
A Core Web Vitals problem can explain a traffic drop only when the timing and pages line up. Field data rolls over 28 days. So a new problem shows up gradually on the templates it affects. A sudden site wide drop, or one that lines up with a Google update, points elsewhere first. Our guide to Google algorithm updates covers how to check.
Keep mobile first indexing separate, too. It's about which version of your pages Google crawls and indexes, not how fast they are. Our guide to mobile SEO covers it. Core Web Vitals are also one part of the wider technical review in our technical SEO checklist.
Choose fixes for your platform
The likely cause depends on the page type and the platform. So does the person who can fix it. Start with the page type. These rows are starting points to test, not a measure of how common each problem is.
Page type | Likely issue to test | First check |
|---|---|---|
Homepage | A large hero image, video or slider as the LCP element | Find the LCP element and confirm it isn't lazy loaded |
Service page | A booking widget that slows taps or shifts the layout | Time a tap on the booking button, then watch for jumps |
Article | Embedded videos, social posts or ads pushing text down | Check that every embed has reserved space |
Product and category pages | Large galleries, variant pickers and filters that respond slowly | Tap filters and options on a phone and time the response |
Location page | A map embed loading heavy scripts early | Check whether the map loads before anyone asks for it |
Start with the templates most visitors land on. That's often the homepage. On a store, test the checkout as well, because that's where a slow step costs sales. Our guide to ecommerce SEO covers how product and category templates fit the wider store strategy.
Then the platform decides where to look and who does the work.
Platform | Investigate first | Owner and boundary |
|---|---|---|
WordPress | Theme weight, the number and quality of plugins, image sizes, page caching and server response | The developer and host work together, removing one proven burden at a time and keeping the features the business needs |
Shopify | Theme sections and animations, apps and leftover app code, tag managers, large product images and long collections | The theme or app developer owns storefront code. Shopify already supplies hosting and a CDN |
Webflow | Large images, third party scripts and custom code, and how much each page loads | The designer or developer changes the build. Webflow's hosting doesn't make every design fast |
WordPress's Advanced Administration Handbook says a lightweight theme performs much better than a heavy, inefficient one. It adds that the optimisation techniques available depend on your hosting. Shopify's Improving your online store performance page says a CDN is included by default. So advice to add one doesn't apply.
Webflow's Improve your site performance page notes that images below the fold are lazy loaded by default. It also says design and development choices set the baseline you start from.
No theme, plugin or platform passes Core Web Vitals automatically, whatever the sales page says. Shopify also notes that uninstalling an app doesn't automatically remove its code from your theme. So check the page's actual requests before you call a script removed. And don't strip out or delay analytics, consent, payment or accessibility scripts to chase a number. List every script before anyone touches one.
Script: [name, vendor and how it's added]
Purpose: [what it does for the business]
Owner: [who can approve a change]
Loads on: [pages, templates and consent state]
Value: [what breaks or goes unmeasured without it]
Proposed change: [keep, remove, limit to some pages or load later]
Test after: [the journey and events to check]
Published pass rates by platform are easy to misread. Each one pools a huge mix of very different sites. Both the WordPress and Webflow pages above point to how the site is built. So test your own site. If you're weighing a move anyway, our Shopify vs WooCommerce comparison covers the wider trade offs.
Diagnose hosting and Australian latency
Time to First Byte (TTFB) is the wait between asking for a page and getting its first byte. Google's Time to First Byte article counts redirects, the connection and the server's own work in it. It suggests most sites aim for 0.8 seconds or less. That's a rough guide, not a fourth Core Web Vital. Google says a site needn't meet it if a slow TTFB doesn't hold back the metrics that matter.
The 40% comes from Google's LCP guide linked above. If TTFB takes far more of a slow LCP, look at the server first. Either way, TTFB is a diagnostic, not a pass mark.
A slow TTFB doesn't prove the host is bad, either. Distance, redirects, caching and the work the application does for each request all add to it. Google's Optimize Time to First Byte guide points to three traps for anyone testing it:
Caching hides the problem. A cached page often shows no TTFB issue at all. But the first visitor after the cache clears still waits on the server. So do pages that are rarely visited or personalised. Test with a cold cache and a warm one.
Lab tools can miss redirects. Google says they're often run on the final URL. When they are, a redirect from an ad, an old link or http to https doesn't show up. Field data includes it. So start the test from the address people actually click.
Distance still counts. A CDN brings cached content closer to visitors. But anything it can't cache still travels from your server.
For an Australian business, test from Australia and record where each test ran. The lab in PageSpeed Insights can't do that. That's because Google's About PageSpeed Insights page says it reports running from North America, Europe or Asia.
Nearby hosting or an Australian CDN edge can cut a delay caused by distance. But a booking or cart page that can't be cached still waits on the origin server. If the developer adds a Server-Timing header, the response itself shows where the time went.
The decision rule is simple. Look at the timing breakdown before you buy hosting or commission a rebuild.
Sometimes the evidence does point at the server. When it does, our guide to the best web hosting for Australian small businesses covers what to compare.
Prioritise and brief the developer
Rank the work by harm to customers, not by the colour of a report. Weigh up:
how many people the problem reaches
how important their journey is
how many pages share the template
how sure you are of the cause
the effort
the risk of breaking something
A broken checkout outranks a small gain on an article few people read. Search Console's advice to fix everything labelled Poor first is a sensible default. But it doesn't override a failure customers are hitting today.
Don't assume mobile always comes first, either. Check your own GA4 device report to see how visitors actually arrive. And because mobile and desktop are assessed separately, look at both.
Before anyone changes code, record a baseline for a representative set of URLs:
the pages, their template and the device
the data source, with the field window or lab conditions (tool, location, device profile and number of runs)
the consent state during the test
each metric, with its unit
the symptom a customer would see
the likely shared cause
Then name a business owner who decides and a technical owner who does the work. Name the acceptance criteria too, and who makes the rollback call. Put it in one brief.
Pages and template: [URLs and page type]
Evidence: [metric, device, scope, dates and conditions]
Customer symptom: [action and observed problem]
Investigate: [suspected cause, not an assumed solution]
Accept when: [performance and journey checks]
Owner and rollback: [names and release decision]
It's a request to investigate, not a specification that promises a perfect score. A good developer will tell you if the evidence points somewhere else.
A worked example: faster isn't passing
Here's an example record of lab LCP before and after a round of work on three templates. Each figure is the median of five lab runs. Every run used the same tool, device profile, network, test location and consent state. A real record would add the dates and the release time.
Template | Before | After | Change |
|---|---|---|---|
Home | 4.8 seconds | 2.9 seconds | 1.9 seconds faster, about 40% |
Service | 4.1 seconds | 2.6 seconds | 1.5 seconds faster, about 37% |
Product | 5.2 seconds | 3.7 seconds | 1.5 seconds faster, about 29% |
Each percentage is the saving divided by the starting time. For the home page, (4.8 minus 2.9) divided by 4.8 is 0.396, or 39.6%. That rounds to about 40%.
Chart data:
| Before | After | |
|---|---|---|
| Home | 4.8 | 2.9 |
| Service | 4.1 | 2.6 |
| Product | 5.2 | 3.7 |
SourceTeaching example, lab medians
Every template got faster. But none reached the good threshold of 2.5 seconds. Faster isn't the same as passing.
A lab improvement isn't a field result either. It shows the change worked under the recorded conditions. It doesn't show that real visits are now good, or that rankings or orders will follow. Nor does it show that this one change caused the whole difference. Only field data gathered after the release can confirm it.
Keep a record like this at each stage. Here's how a month of that work can run. It's a sequence, not a promise that the site will pass in 30 days. If something is broken for customers right now, fix it straight away. Don't wait for a phase or a report window.
DAYS 1–7Set the baseline
Choose the pages that matter: the homepage, main service or product templates and the enquiry or checkout route
Record field data, repeated lab runs and a real journey for each, on phones and desktops
DAYS 8–14Confirm the cause
Identify the LCP element, slow interaction or shifting element, and look for one cause several templates share
Write the developer brief with acceptance checks and a rollback owner
DAYS 15–21Make one bounded change
Change one cause at a time in a test environment
Repeat the same lab runs and the real journey
Confirm that forms, payments, consent and tracking still work
DAYS 22–30Release and start watching
Release with a timestamp and a named decision owner
Test the live journey and record comparable lab results
Start Search Console validation where an issue was flagged
Watch the field data build over the next 28 days
We'll read your field data and reproduce the slow journey on a real phone. Then we'll tell you which cause we'd fix first.
Verify the release and keep the gains
Before a change goes live, check the key templates in a test environment. Agree how you'd roll it back, too. Straight after release, repeat the same measurements. Then complete the real customer route on the phones and desktops your customers use. A faster page that stops enquiries, purchases or accessibility features working hasn't been fixed.
Check | Evidence to keep |
|---|---|
Navigation and interaction | Menus, accordions, search, product options and filters respond and stay usable |
Enquiries and orders | A real test enquiry arrives correctly, and an approved test order reaches the intended systems |
Consent and measurement | Consent choices work, and the agreed analytics and conversion events still fire correctly |
Layout and accessibility | Images, fonts and late widgets stay stable, keyboard navigation works and content stays readable |
Performance and rollback | A comparable metric record, the release time, remaining issues and a named decision owner |
Our guide to website accessibility for Australian businesses covers the accessibility checks a speed fix must not break.
The deployment check tells you the release works. The field data tells you, weeks later, whether real visits improved. Keep the two separate. No report turns green the day you release.
Gains slip. A theme update, a new app or a tracking tag can undo the work in a day. So can a campaign landing page or an embedded widget. Check again after each of those.
Also set a routine check that suits how often your site changes and how much traffic it gets. A quarterly check alone can miss a new problem on a store that changes every week.
If a fix grows into a replatform or a redesign, the release risk grows with it. The URLs, redirects and tracking all have to survive the move. Our guide to migrating a website without losing SEO rankings covers them.
What we recommend at Elev8d
Start with field data for the pages that earn you enquiries or sales, on mobile and desktop. If a page has none, test the journey on a real phone before you trust any score.
Fix what stops customers first. Think of a form that won't submit, or a button that jumps away. Fixing those is worth more than a green score on an article nobody reads. Then work through the poor templates in order of how many customers they carry.
Confirm the cause before you buy anything. We find the LCP element, the slow interaction or the shifting element. Then we decide whether the culprit is an image, a script, a font or the server. New hosting, a speed plugin or a rebuild only makes sense when the evidence points there.
Don't chase 100. In our view, a mobile score in the 70s is usually fine for a small business. That holds when the field Core Web Vitals pass.
Release every fix with acceptance checks and a named rollback owner. Then test the enquiry or checkout again before you call it done.
You might not be sure speed is the problem at all. If so, our DIY website audit checklist puts it beside the other checks. Say the platform blocks fix after fix. That's when we'd bring in our web design team to scope a rebuild.
FAQ
What can I fix without a developer?
More than you'd think, and less than the plugin ads promise. Resize and compress images before you upload them. And don't open a phone screen with a video or slider unless it earns its place. Anything involving templates, scripts, fonts or caching needs a developer. The investigation template above is how to ask.
Why does my PageSpeed score change every time I run it?
Because the conditions change between runs. Google's scoring page says a lot of the variation isn't due to Lighthouse at all. It lists causes such as A/B tests, changes in the ads being served and internet traffic routing. The list also includes browser extensions and antivirus software when you test on your own computer.
The same page suggests treating performance as a spread of scores rather than a single number. Compare several runs, and judge the outcome on field data.
Does one slow page drag down the whole site?
Google says its core ranking systems generally evaluate content page by page, including page experience. But Google also has some site wide assessments. So treat a slow page as that page's problem first.
The catch is that a slow page often shares its template with others. That's why Search Console groups similar pages. Fix the template rather than one URL.
Next steps
Check your two most important pages
Run your homepage and your main service or product page through PageSpeed Insights on mobile and desktop. Write down whether the field data covers the URL or the origin, and which metric fails.
Find the template in Search Console
Open the Core Web Vitals report and note any Poor groups. Then open a few example URLs to see whether they share a template.
Write one brief
Fill in the investigation template for the worst template. Send it to your developer with the evidence attached.
