Lab data (Lighthouse, PageSpeed)
- One simulated load on a simulated device
- Repeatable, controlled, comparable between runs
- Tells you exactly what is heavy and why
- Perfect for diagnosis and for testing a fix
- Not what any of your customers experienced
Common problem
Your website is slow
Almost everyone guesses at this and almost everyone guesses wrong. The cause is measurable, it is usually images, and buying faster hosting before you have looked is the most common wasted spend in this whole category.
On a small business site the cause is almost always images, in that order: unoptimised images first, then render blocking JavaScript, then hosting, then third party scripts. A single photo straight off a phone camera can weigh more than every other file on the page combined.
Measure before you change anything. Run the page through a speed test, then open it on a real phone with wifi off and no cache. Those two together tell you what is slow and for whom. Everything else is guessing with money.
And sometimes the honest answer is that the site is fine and your wifi is not.
The likely causes, ranked by how often they turn out to be it
Roughly ordered by how frequently each one is the real culprit on a small business site.
1. Images
This is the answer most of the time, and it comes in several flavours at once:
- Far too large. A photo at 4000 pixels wide displayed in a 600 pixel slot still downloads all 4000 pixels. The browser shrinks it after paying full price for it.
- Wrong format. A photograph saved as PNG can be many times the size of the same image as WebP or a sensibly compressed JPEG, with no visible difference.
- No width and height in the markup. This does not slow the download, it makes the page jump around as images arrive, which feels worse than slow. It is also trivially fixable.
- Everything loading at once. Images far below the fold should wait until they are nearly needed.
Fixing images is unglamorous and it is usually where the win is.
2. Render blocking JavaScript and CSS
Scripts in the page head stop the browser drawing anything until they load and run. The page may be almost ready and still show white. Moving non essential scripts out of the critical path is often a large improvement for a small change.
3. Third party scripts and trackers
Chat widgets, tag managers, ad pixels, review embeds, font services, map embeds. Each one is a request to someone else's server, running at their speed, subject to their outages. Sites frequently carry five or six of these and use one. Every tag you keep should be one you actually read.
4. Hosting and server response time
Real, but lower down the list than the sales pitch suggests. The signal to watch is time to first byte on a page that is otherwise light. If the server takes over a second to say anything at all, hosting is genuinely in the frame. If the server responds fast and the page is still slow, a faster host changes nothing.
A content delivery network in front of the site helps with distance and caching. That configuration sits in Cloudflare management.
5. Plugin and theme bloat
Common on older content management system sites. Twenty plugins each loading their own stylesheet and script on every page, including the pages that do not use them. This tends to be diagnosed alongside an outdated site generally.
6. Fonts
Custom fonts loaded from a third party, in six weights nobody uses, blocking text from appearing. Smaller than the image problem, easy to fix, and it directly affects when a visitor can read anything.
Lab data and field data disagree, and both are right
This confuses everyone and it matters, because acting on the wrong one wastes real effort. They measure different things and neither is the liar.
Field data (real users)
- Collected from actual visits on actual devices
- Reflects real phones, real networks, real distance
- Tells you whether it is genuinely a problem in practice
- Slow to update, so it lags any fix you ship
- Cannot tell you which file to blame
Check these yourself, in this order
-
Open the site on a real phone, on mobile data
Turn wifi off. Use a private window so nothing is cached. Count the seconds until you can read the main content. This is the test that matters, and it costs nothing.
-
Run a lab test on your most important page
Not just the homepage: test the page people actually land on. Ignore the headline score at first and read the list of opportunities. It names the specific files.
-
Look at the total page weight and what makes it up
Almost every report shows the byte breakdown by type. If images dominate, and they usually do, you already know where to start and can stop reading the rest of the report.
-
Check your largest single file
Find the biggest thing on the page. If one hero image is heavier than everything else combined, that one file is your project.
-
Count your third party scripts
Go through the list and ask, honestly, which of these do we use? Chat widgets nobody answers and pixels from finished campaigns are pure cost.
-
Check the server response time
If time to first byte is high on a light page, the server is the bottleneck. If it is low, stop blaming hosting.
-
Test again after each change, one at a time
Change several things at once and you will never know which one worked, or which one broke something.
Quick wins that rarely go wrong
- Resize images to the size they display at. Not the size the camera produced. This one change routinely does more than everything else on this list combined.
- Serve photographs as WebP. Broadly supported now, and usually a large reduction with no visible quality loss.
- Set width and height on every image. Stops the layout jumping as the page loads. Cheap, and it removes a genuinely irritating experience.
- Lazy load anything below the fold. The browser will handle it natively. Do not lazy load your hero image, which is the one mistake people make here.
- Remove tags you do not read. Every tracker is a performance cost you pay forever for data you may never look at.
- Turn on caching and compression. Usually a setting rather than a project. Repeat visitors stop re-downloading things that have not changed.
- Do not buy a plugin to fix a plugin problem. Speed plugins on a bloated site often add another layer of code on top of the actual cause.
When it is worth bringing in help
Everything above is genuinely doable by an owner with an afternoon. Bring someone in when:
- The report names problems in code you did not write and cannot edit, such as a theme or plugin internals.
- Images are already optimised and the page is still slow. That means the cause is further down the stack and needs a proper look. This is what speed optimization exists for.
- The fix means touching the build, the server, caching rules or DNS and you do not want to be the one who takes the site down finding out.
- Speed is a symptom of a site that is genuinely past its life. Then the honest conversation is about a redesign rather than a tune up.
- It keeps coming back. A site that is fast for a month after every cleanup has a process problem, which is what maintenance is for.
Who this is for
- Owners who have been told the site is slow and want to know what to actually do
- Businesses whose visitors leave before the page finishes loading
- Anyone who has been quoted for a rebuild when the real problem might be six photos
- Sites that got slower over time as plugins and tags accumulated
When this is not the right fit
- Anyone chasing a perfect score for its own sake. Past a point the effort costs more than it returns, and we will tell you where that point is.
- Sites that already load quickly on a real phone. If field data looks fine, a middling lab score is not a business problem.
- Businesses whose real issue is that nobody visits at all. Speed is not your bottleneck. Start at not showing on Google.
What SolvenceHQ can help with
We measure first and tell you where the time actually goes. Often the fix is smaller and cheaper than the rebuild someone else quoted for, and we would rather say that than sell the bigger job.
- Measure lab and field data together and explain what each one is telling you
- Image audit: sizing, format, lazy loading, and the dimensions that stop layout shift
- Get render blocking scripts and styles out of the critical path
- Audit third party tags and remove what nobody reads
- Caching, compression and delivery through Cloudflare where it earns its place
- An honest verdict on whether this is a tune up or a rebuild
Common questions
Why does my site feel fast to me but test badly?
Because you are testing on a desktop, on good wifi, with the whole site already cached in your browser. Your customer is on a phone, on mobile data, seeing it for the first time. That is a completely different experience of the same site, and it is the one that counts.
Open the site on a real phone with wifi turned off, in a private window so nothing is cached. That thirty second test tells you more than most reports.
What is a good score to aim for?
Scores are a diagnostic tool, not a goal. A perfect score on a page nobody wants to read is worth nothing, and chasing the last few points usually costs more than it returns. The useful targets are the ones tied to what a person experiences: the main content visible quickly, nothing jumping around as it loads, and taps that respond immediately.
Fix the causes the report names, in the order they cost you the most, then stop.
Will a faster site improve my rankings?
Speed is one input among many, and it is not the strongest one. A fast page about nothing will not outrank a slow page that answers the question. What speed reliably does is stop people leaving before they see anything, which is worth doing whatever search engines make of it. If ranking is the real goal, look at technical SEO rather than at speed alone.
Do I need a faster host?
Often not. Hosting is the cause people reach for first and it is rarely the biggest factor on a small business site. Unoptimised images and third party scripts usually account for far more. Move hosting when the evidence points there, such as a slow server response time on an otherwise light page, not because it is the easiest thing to buy.
Can I just remove the tracking scripts?
You can, and it usually helps, but be deliberate about it. Each third party script you load is someone else's code running on your site and slowing it at their pace, not yours. Audit what is actually there: many sites carry tags from campaigns that ended years ago. Keep what you genuinely read, such as a properly configured analytics setup, and drop the rest.
Related services and guides
Website speed optimization
Find what is actually slowing the site down, then fix it.
Website maintenance
Edits, updates, backups and monitoring so the site keeps working.
Cloudflare management
DNS, SSL, caching and protection, configured properly.
Outdated business website
Decide whether to refresh, rebuild, or leave it alone.
Website redesign
Rebuild an existing site without losing the rankings you already have.
Website maintenance checklist
What to check weekly, monthly and yearly.
Get a Quote
Want to know what is actually slowing it down?
Send us the URL. We will tell you where the time is really going and whether it is worth fixing, before anyone touches anything.