Short answer: measure first, on a phone, using real-user data. Then work through the fixes in the order Google's own guidance suggests: make sure the main image or heading can be found and loaded early, stop anything delaying it from showing, shrink what has to be downloaded, and only then look at the server. Doing them out of order wastes money.
If you're still deciding whether you need a website at all, start with Does a Small Business Still Need a Website in 2026?. This article is for a site you already have.
Why speed is worth the effort
Google commissioned Deloitte and the agency 55 to look at what small improvements in mobile speed did for real sites. The study monitored 37 brand sites over 30 days at the end of 2019, covering more than 30 million user sessions. It found that a 0.1 second improvement in the measured speed metrics was associated with several gains, including retail consumers spending 9.2% more, and a 21.6% rise in users reaching the form submission page on lead-generation sites.
Read that with care. These were large brands, the data is from 2019, and the page reports progression rates through the funnel rather than a guaranteed sales uplift. The direction is still clear: small speed gains can compound across a funnel. It is not a promise about your site.
Step 0: measure before you fix anything
Google's PageSpeed Insights shows two kinds of data, and the difference matters.
- Field data comes from real users, via the Chrome User Experience Report, over the previous 28 days. Google describes it as "a historical report about how a particular URL has performed."
- Lab data comes from a simulated load "on a single device and fixed set of network conditions." Google notes it is useful for debugging because it is collected in a controlled environment.
The two can disagree. Use field data to decide whether you have a problem, and lab data to work out why. Small sites sometimes have too little traffic for field data; if so, rely on lab data and say so.
Google's "good" thresholds for Core Web Vitals, assessed at the 75th percentile of page loads across mobile and desktop, are:
| Measure | What it is, plainly | Good |
|---|---|---|
| Largest Contentful Paint (LCP) | How long until the main thing on the screen appears | 2.5 seconds or less |
| Interaction to Next Paint (INP) | How quickly the page reacts when someone taps or clicks | 200 milliseconds or less |
| Cumulative Layout Shift (CLS) | How much the page jumps around while loading | 0.1 or less |
For most small business sites, LCP is the one that needs work first, so the rest of this guide focuses on it.
Step 1: find out what your LCP element is
The "largest contentful paint" is usually one thing: the hero image, a banner or the main heading. PageSpeed Insights names it. Everything below is about getting that one element on the screen sooner.
Google's guide splits LCP time into four parts that add up to the total:
- Server response (time to first byte): how long until the browser receives the page's first data.
- Load delay: the gap between that and the browser starting to download the main image.
- Load duration: how long the download takes.
- Render delay: the gap between the download finishing and the element appearing.
Google's rough guideline is that the vast majority of LCP time should go on loading the page and the main image, with only a small share (under about 10% each) spent on load delay and render delay. It stresses these are guidelines, not fixed targets.
The order to fix things in
Google's guide ranks the sub-parts by likely impact: first load delay, then render delay, then load duration, then server response. In plain English:
1. Make the main image easy for the browser to find, and don't delay it.
The main image should be visible in the page's initial code. If it's only added later by a style sheet or a script, the browser finds out late. Two specific points from Google's guide: setting a high fetch priority on the likely main image helps, but "setting a high priority on more than one or two images makes priority setting unhelpful," and "never lazy-load your LCP image."
2. Stop things blocking it from appearing.
Once the image has downloaded, anything that holds up painting it adds render delay. Ask your developer what is blocking the display of the main element, such as heavy scripts or fonts loaded in a way that holds the page back.
3. Make the file smaller.
Oversized images are the most common avoidable cost. Serve an image sized for the screen it appears on, in a modern format, and compress it.
4. Then look at the server.
Server response is important and can be a large share of the total, but it is last in Google's impact order because the first three are often quicker and cheaper to fix. If the server is slow after those fixes, look at hosting, caching and any content delivery network.
What to ask your developer or agency
Copy this into an email:
- Please tell me which element is our LCP on the home page and our main landing page, on mobile.
- Is that image findable in the initial HTML, and is it lazy-loaded?
- Have you set a high fetch priority on it, and on no more than one or two images?
- What is delaying it from rendering after it downloads?
- What are the dimensions and file size of that image versus the size it is displayed at?
- What is our server response time, and what is our field data over the last 28 days?
What this won't tell you
A faster site won't fix an unclear offer or a weak page, and speed work has diminishing returns once you're within Google's "good" range. Results also vary by audience, device mix and traffic source. Measure again after each change so you know which one helped.
Common questions
What's a good page speed score?
Rather than chase a single score, check whether LCP, INP and CLS are within Google's "good" thresholds in real-user data.
Why does my score differ between tools or runs?
Lab results come from a simulated load on one device and set of network conditions; field data reflects many real users and devices over 28 days. Google notes they may differ.
Do I need a developer?
For image sizing and a few settings, sometimes not. For script, font and server changes, usually yes.
Will a faster site improve my Google ranking?
Google lists Core Web Vitals as measures of page experience. We wouldn't promise a ranking change from speed alone; the clearer benefit is that visitors can reach and use the page.
Should I fix speed or my ads first?
If you're paying for clicks, check tracking first, then speed. See Why Your Ad Spend Isn't Turning Into Enquiries for the full leak audit.
Velocity Branding builds SEO and AI search visibility for small businesses and startups across the US and South Africa.
Want to know what's slowing your site and in what order to fix it? Book a free strategy call for a speed review.