On this page7 sections
A red PageSpeed score is a starting point, not a diagnosis. Speed problems tend to come from a handful of specific things: a hero image the browser finds too late, a script that blocks the page, a font that swaps in and shoves everything down. I find the actual cause, fix that, and measure before and after so the difference is visible. This guide shows how I do it, and the first step runs right here on the page.
Test your page
Pick a page that matters to the business, not just the homepage. A service page, a project, a product, or the first step toward booking. Start with mobile if your customers are on phones, then check desktop separately. Different pages use different templates, and a fast homepage can hide a slow service page.
What is holding your page back?
Test a public page. Get the evidence, a prioritized improvement plan and a clear next step.
Your submitted URL is sent to Google PageSpeed Insights to run the test. Use a public page without private information in its address. Results are open; no email is required.
Already have a Lighthouse report?
Export JSON from a Lighthouse report, then import it here for the same interpretation. Imported results keep their original date and device; they are not a new test. The file is sent to this website for analysis and is not retained.
Loading, browser work and layout stability from Google’s test.
Relevant audit evidence connected to specific improvements.
What to investigate, how to change it and what to verify.
I built this check to read the Lighthouse results and turn them into a short, prioritized plan. Each finding names the evidence, the work to look at, and how to confirm the change worked. Where the report identifies the specific file or image, the plan includes it. Where it only shows a slow number, the plan says "investigate" instead of guessing.
A public test can't see your server, your database, or your admin area. It can tell me the main image was discovered late. It can't tell me a plugin must go or the hosting must change. How PageSpeed runs its analysis
If you don't have a website yet, skip the test. Speed gets designed in from the start of a new website project: the right templates, realistic content, and the integrations you actually need.
What I'd do with the result
The first thing I produce is a short scope with the evidence behind it. Not a list of every warning in the report. A list of what to fix, in order, and how we'll know it worked.
| Step | What I establish | What you get |
|---|---|---|
| Baseline | The pages, templates, and devices that matter, tested the same way each time | Saved reports with dates and conditions |
| Diagnosis | The real bottleneck, and what's still unconfirmed | A finding tied to a specific image, script, or interaction |
| Fix | The changes in scope and what they must not break | An agreed plan covering code, images, fonts, scripts, or delivery |
| Release check | The speed change and the business behavior it preserved | Before-and-after numbers plus working forms, bookings, and checkout |
| Follow-up | What the lab shows now and what real visitors show later | A dated comparison and a plan for anything left |
Here's a typical example, made up for illustration. A service page's main photo waits for JavaScript before the browser even knows it exists. I move that image so the browser finds it in the first response, give it the right size and priority, confirm the request starts sooner, and retest the mobile layout. That's the whole fix. Compressing every file on the site, moving hosting, and adding three optimization plugins would be far more work than the evidence supports.
Focused performance work sits in my $1,000–$3,000 planning range for small projects and optimizations. If the site's structure and editor no longer fit the business, the honest answer is a new website, which sits at $4,000–$10,000. Those are my ranges, not a quote from this test; I still need to see the templates and confirm the causes. Project pricing
A great lab score and a failing real-visitor grade can both be right
PageSpeed Insights shows two kinds of evidence. The Lighthouse score comes from one controlled test on a simulated device. The Core Web Vitals assessment comes from real Chrome visitors over the past 28 days. You can score 99 in the lab and still fail with real visitors, because your visitors have slower phones, worse connections, or a different page than the one you tested. Google's lab and field explanation
Try it. Change the real-visitor values below while the lab score stays at 99.
A good score does not overwrite the field.
Lighthouse performance
Changing field values does not change this example’s lab score.At least one p75 value is outside the good range. The lab score stays independent.
27 collection days before release; 1 after. Days do not have equal traffic. Even a fully post-release window does not prove that caches and partial rollouts delivered new code to every visitor, or guarantee a pass.
Illustrative values you can edit, not measured traffic. Fields represent reported p75 values; this tool does not average visits or daily percentiles.
Two details trip people up. First, the field data might describe your whole site, not the page you tested, if that page doesn't have enough visits on its own. Second, a new or quiet page may have no field data at all. "Unavailable" is a real answer. It means we have lab evidence and nothing else yet; it does not mean "all good." PageSpeed Insights documentation
Find the metric that matches the frustration
Core Web Vitals is three separate measurements. Each one describes a different annoyance, and each one needs a different fix. "Make the score higher" hides which one you have. Web Vitals definitions and thresholds
| Metric | What the visitor feels | Good threshold |
|---|---|---|
| Largest Contentful Paint (LCP) | The main content takes too long to show up | 2.5 seconds or less |
| Interaction to Next Paint (INP) | I tapped something and nothing happened | 200 milliseconds or less |
| Cumulative Layout Shift (CLS) | The page jumped while I was reading or about to tap | 0.1 or less |
If LCP is slow, I find the element being measured
LCP measures when the biggest thing on the first screen appears, usually a hero image or a headline. I identify that exact element, then look at when the browser discovered it, when it started downloading, and when it was drawn. An image that starts downloading late stays slow no matter how small you make the file. Google's LCP optimization guide
Which part of the wait can this change reach?
Check whether the LCP resource is discoverable early and given appropriate priority.
An additive teaching model for an image LCP. All durations are invented. In real traces, a change can shift time between parts, so the total must be measured again.
If INP is slow, I test a real interaction
INP measures how quickly the page responds visually after you tap, click, or type. Not how long the whole task takes, just how long before something visibly changes. I name the action that's slow: opening the menu, filtering projects, picking a date. Then I find the JavaScript that's hogging the browser at that moment. INP's definition and INP optimization guidance
A standard Lighthouse run doesn't click anything, so it can't measure INP directly. It reports Total Blocking Time, which hints at the problem but isn't the same number.
A tap has three kinds of waiting.
The largest part in this sample is input delay. Investigate that work before choosing a repair.
The field INP assessment summarizes eligible visits, each containing its own interaction history. This single trace cannot pass or fail your whole website.
An invented interaction when a visitor opens a booking control. This does not measure the browser you are using, a visit’s INP, a field percentile, or the duration of the eventual appointment confirmation.
If CLS is poor, I watch the page past the first screen
CLS measures how much content jumps around unexpectedly. The usual culprits arrive late: an image with no reserved space, a web font that swaps in at a different size, an embed, an announcement bar. I reserve room for anything that loads late and check how fonts swap. CLS's definition and CLS optimization guidance
Give arriving content a place to land.
No space reserved
The newly occupied area pushes the reading position down.
Space reserved
The embed fills its reserved area. The reading position below stays put.
For a real page, inspect late-loading images, fonts, embeds, and banners. Reserve suitable space and test different sizes and failure states. A guessed height that is too small can still allow movement.
A controlled reserved-space comparison, not a CLS measurement. This reader-triggered transition is different from unexpected late content in a real visit. Each miniature keeps a fixed outer height so the article itself stays in place.
Why your fast laptop doesn't disprove the report
Each field metric is judged at the 75th percentile. Line up 100 visits from fastest to slowest; the 75th one is the number Google reports. If 60 visits were fast and 40 were slow, the reported number is slow, even though most people had a fine experience.
Find the 75th observation.
Outside the good LCP range
A different summary; not used for this assessment.
Move the good count from 74 to 75. The 75th observation crosses the threshold, while the arithmetic average answers a different question. These are illustrative LCP observations only; INP and CLS still require their own evidence.
100 equally weighted fictional observations, sorted from quickest to slowest. This teaching model uses the nearest-rank method: p75 is observation 75. It does not reproduce CrUX’s underlying aggregation or your traffic.
This is why "it loads fine for me" and a failing report can both be true. Your laptop on office Wi-Fi is somewhere in the fast 60. Your customer on a three-year-old phone in a parking lot is in the slow 40.
After a fix ships, the report catches up slowly
The real-visitor data covers a rolling 28-day window and updates daily. Fix something today and the report still contains 27 days of the old experience tomorrow. The number improves as old visits age out, not the moment the fix goes live. CrUX API collection periods
So I report in two tracks. First, what I changed and verified in the lab, with dates and conditions you can repeat. Second, what the field data currently says and which dates it covers. "The lab test improved on the 10th; this field window still includes visits from before that" is honest. "Wait 28 days and it will pass" isn't a promise I can make.
One more thing I check: that visitors are actually getting the new version. A cached page, a gradual rollout, or a template I missed can keep serving the old behavior after the fix is live.
Fix, rebuild, or manage
A speed report doesn't make the business decision for you. It's one piece of evidence next to how well the site serves customers and how easy it is to keep current.
| Your situation | What I'd recommend | What we'd confirm first |
|---|---|---|
| The site works for the business; a few templates or interactions are slow | A focused performance project | Affected pages, confirmed causes, access to the code |
| The structure or editor no longer fits, or you need your first site | A new website with speed designed in | Content, customer journeys, integrations, migration |
| The site changes often and nobody owns updates or checks | Ongoing website management with a baseline and regular checks | Included work, recurring fee, how bigger fixes get approved |
Good hosting and good code work together. I'm DreamHost's CMO; the hosting is DreamHost's product and billed separately, and the work described here is my own. If the evidence points to a slow first response from the server, I look at the server and the application together. I don't assume a hosting move fixes an image or script problem, because it usually doesn't.
A red score is a starting point. Find the metric that matches the frustration, trace it to the specific image, script or interaction, fix that, and measure before and after under the same conditions. Keep lab results and real-visitor data separate, and don't read a rebuild into one number.