Lab data (the score)
- A simulated device on a simulated connection
- Repeatable, which makes it good for comparing before and after
- Great at telling you what is wrong
- A diagnostic, not a goal
- Can look bad while real visitors are perfectly happy
Speed optimization
Find what is actually slow
Almost every slow site is slow for a reason you can measure, and almost nobody measures first. They buy a caching plugin, the score moves a little, and the page is still heavy. Diagnosis before treatment.
Website speed optimization is finding the specific reason a page is slow and removing it. In practice the cause is nearly always the same short list: images far larger than they are displayed, fonts blocking the first paint, third-party scripts nobody can account for, and a page shipping code for features it does not use.
Speed is a build property first. It is much easier to build fast, which is part of website development, than to retrofit speed onto something heavy. Keeping it from drifting back is part of website maintenance, because sites get slower on their own as things accumulate.
What is actually making it slow
In roughly the order we find them.
Images, nearly always
The most common single cause by a distance. A photo straight off a phone, uploaded at full resolution, displayed in a small box. The browser downloads all of it and throws most of it away. Correctly sized images in a modern format, loaded lazily below the fold, routinely make more difference than everything else on this list combined.
Fonts blocking the first paint
Custom fonts loaded so the browser waits for them before showing text. The visitor stares at a blank page that has technically already arrived. Fixable with how you load and declare them, not by giving up your brand typeface.
Third-party scripts
The chat widget nobody uses, three analytics tools where one would do, a tracking pixel from a campaign that ended, the embedded map on every page. Each one is a request to someone else's server, and their bad day is your bad day. This is also where the audit becomes uncomfortable, because these get added by people who are not the developer and never removed.
A page shipping everything for a page that needs little
Page builders and heavy themes load the code for every feature they can do, whether your page uses it or not. This is the ceiling that optimisation eventually hits, and it is why the fix sometimes is not a fix.
The server, sometimes
Slow hosting or an uncached, database-heavy page. Less often the main cause than people assume, which is exactly why measuring first matters. Cloudflare in front helps here, once the page itself is not the problem.
Lab scores and real visitors are not the same thing
Confusing these two is the most common reason speed work gets aimed at the wrong target.
Field data (real people)
- What actually happened to actual visitors on actual devices
- Visible in Search Console
- Noisier, slower to update, and far more meaningful
- This is what search engines use, and what your customers felt
- The only fair judge of whether the work worked
How we approach it
-
Measure before touching anything
What loads, in what order, how big, from where, and what the browser is waiting on. Without this you are guessing, and guessing usually means buying a caching plugin and hoping.
-
Find the actual cost, not the obvious one
There is normally one or two things responsible for most of the problem. Fix those and the rest is noise. Chasing every warning in a report is how you spend a budget on nothing.
-
Remove before you optimise
The fastest asset is the one that is not there. Half of most speed work is deleting things nobody could justify: the widget, the third pixel, the script from a campaign that ended.
-
Fix the images and fonts
Sized properly, modern formats, lazy loaded where it makes sense, fonts that do not hold the page hostage. This is where most of the real gain lives.
-
Then cache and deliver well
Caching and edge delivery, applied to a page that is now worth delivering quickly.
-
Measure again, and be honest
Same conditions, before and after, and field data over the following weeks. If it did not move, we say so rather than quoting a friendlier number.
Who this is for
- Businesses whose site is visibly slow on a phone, where the customers are
- Owners who bought a speed plugin and got a small number and no improvement
- Anyone told their site is slow but not told what specifically is slow
- Sites that got slower over time and nobody knows what was added
- Businesses whose Search Console is reporting real problems with real visitors
When this is not the right fit
- Anyone chasing a perfect score for its own sake. We will do it if you insist, but we will tell you first that it is not worth your money.
- Businesses whose site nobody visits. Making an unvisited page faster does not create visitors. That is local SEO.
- Sites whose real problem is the build. Optimisation has a ceiling and we will say when you have hit it, even though the smaller job is the easier sale. See redesign.
- Anyone expecting a fixed performance figure quoted in advance. That number depends on what we find, and quoting it before measuring would be inventing it.
What SolvenceHQ can help with
We measure first and tell you what we found, including when the finding is that your site is fine and something else is your problem. If you just want the diagnosis walkthrough, slow business website is free.
- A real diagnosis: what is heavy, what blocks, what nobody can account for
- Images sized, converted and loaded properly
- Fonts that do not block the first paint
- Third-party scripts audited, and the dead ones removed
- Caching and Cloudflare edge delivery configured correctly
- Build-level fixes where the code is the problem, via development
- Before and after measured the same way, with field data followed up
- Kept from drifting back, via website care
Common questions
Why is my PageSpeed score bad when the site feels fast to me?
Because you are not the test. Your browser has the site cached, you are probably on a desktop with a good connection, and you know exactly where you are going. The test simulates a mid-range phone on a throttled connection loading the page cold. That is closer to your customer than your own experience is.
The score itself is a lab measurement, not what real visitors experience. The useful data is field data: what actually happened to real people, visible in Search Console. Lab and field disagreeing is normal and is not a bug.
Should I be chasing a perfect score?
No, and this is where a lot of money goes to die. The score is a diagnostic tool that got mistaken for a goal. Going from genuinely slow to comfortably fast is worth real money. Grinding from good to perfect is engineering effort spent on a number that no customer will ever perceive.
Optimise until a real person on a real phone is not waiting. Then stop and go do something that grows the business.
Will making my site faster improve my Google rankings?
Speed is a ranking signal, but it is a modest one and it is nowhere near the strongest. A fast page about nothing does not outrank a slow page that answers the question. If your site is not ranking, speed is usually not why, and we will not sell you a speed project as an SEO fix.
Where speed clearly pays is conversion. People leave slow pages, especially on phones, especially on a bad connection. That is the real argument for it, and it does not depend on a ranking claim. If ranking is the actual problem, start at technical SEO or not showing on Google.
Can a plugin or a caching service just fix it?
Sometimes it helps, and it is rarely the fix. Caching makes the server hand over the page faster. It does nothing about the megabytes of images, fonts and scripts the browser then has to download and run. If the page is heavy, caching delivers a heavy page more promptly.
The honest sequence is: measure, find the actual cause, remove what is not needed, then cache what is left. Caching first is optimising the one part that was not the problem.
What if the site is just built badly?
Then we will tell you, even though the smaller job is the easier sale. There is a real ceiling to what optimisation can do for a build that ships a page-builder's worth of code to render four paragraphs. At some point you are polishing something whose problem is what it is, not how it is tuned.
That conversation leads to development or redesign, and it should only happen after measurement has proved it, not before.
Related services and guides
Slow business website
Find the real cause instead of guessing at it.
Website development
The build itself: structure, code, forms, and the systems behind the pages.
Cloudflare management
DNS, SSL, caching and protection, configured properly.
Website maintenance
Edits, updates, backups and monitoring so the site keeps working.
Technical SEO
The crawling, indexing and structure work search engines depend on.
Google Search Console setup
See how Google actually crawls, indexes and ranks your pages.
Get a Quote
Site feels slow, or a tool says it is?
Send us the URL. We will measure it properly and tell you what is actually costing you the time, including when the honest answer is that it is fine.