A business website should feel fast enough that the visitor is not noticeably waiting for the main content or fighting with a page that shifts around while loading. Google's current Core Web Vitals give useful targets, but a perfect performance score is not the objective.
This is an area where numbers can become a distraction.
A client sees a PageSpeed score of 93 and asks whether 100 would rank better.
A developer spends hours chasing the final few points.
Meanwhile the homepage contains vague copy and no obvious route to contact.
Performance matters.
It is not the whole website.
Google's current performance targets
Google's Core Web Vitals currently focus on three real-world experience measures.
Largest Contentful Paint, or LCP, measures loading performance. Google recommends an LCP within 2.5 seconds for a good experience.
Interaction to Next Paint, or INP, measures responsiveness. Google's good threshold is under 200 milliseconds.
Cumulative Layout Shift, or CLS, measures visual stability. Google's good threshold is below 0.1.
Those are useful targets.
They tell you much more than simply asking how many seconds it took for every last network request to finish.
"Load time" is not one moment
A page begins doing useful things before everything is finished.
The headline may appear.
The main image may load.
The page may become interactive.
A background analytics request may finish later.
That is why modern performance measurement uses several metrics rather than one stopwatch number.
The visitor cares about perception.
Can I see the page?
Can I interact with it?
Does it stay where I expect?
That is the real experience.
Do I need a PageSpeed score of 100?
No.
Google itself says that trying to achieve a perfect score purely for SEO reasons may not be the best use of time.
That is an important bit of perspective.
A score can help identify problems.
It is not a trophy.
If the site is already delivering a strong real-world experience, I would rather spend the next hour improving a weak service explanation than removing a useful font just to move Lighthouse from 97 to 100.
Optimisation should improve the website, not become the website.
Gavin's take
I would not chase a perfect performance score at the expense of the website itself. A useful site can justify good photography, analytics or an integration that adds some weight. The goal is to remove waste and make the experience feel immediate, not to strip out anything valuable just so a testing tool displays 100.
Speed still affects commercial performance
Visitors notice slow sites.
A page that hesitates before showing the content creates friction.
A button that appears unresponsive damages confidence.
A layout that jumps while somebody is trying to tap a link is irritating.
These are not abstract technical problems.
They directly affect how professional the business feels.
For a mobile user on a weaker connection, the difference becomes even more obvious.
That is why mobile-first design and performance belong together.
Images are often the obvious problem
A modern phone can produce enormous photographs.
Upload those originals directly and a simple homepage can become unnecessarily heavy.
Good image handling means using appropriate dimensions and formats, compressing sensibly and avoiding the download of pixels the visitor will never see.
I do not want every image compressed until it looks awful.
The aim is visual quality at a sensible file size.
That balance is part of the build.
Fonts can become surprisingly expensive
Custom typography can add a lot of character.
It can also add more network requests and font files.
That does not mean every site should use system fonts.
It means typography choices should be deliberate.
If one carefully chosen type family gives the site the right personality, great.
If the page downloads ten weights and styles that are barely used, that is technical waste.
Scripts are where simple sites become heavy
Analytics.
Chat widgets.
Tracking pixels.
Cookie tools.
Animation libraries.
Review widgets.
Booking embeds.
Third-party forms.
Each may have a legitimate purpose.
Together, they can make a small website surprisingly complicated.
This is one reason I am cautious about adding software simply because it exists.
Every integration should earn its place.
What I'd do
If a straightforward business site feels slow, I would investigate oversized images, unnecessary scripts, fonts, plugins and page-builder weight before assuming the answer is a more expensive hosting package. Better infrastructure can help, but paying more to serve avoidable bloat is the wrong order of operations.
Hosting matters, but architecture matters too
A fast infrastructure platform helps.
Cloudflare can distribute static assets through its global network.
A static website also avoids generating ordinary content through a database on each request.
That can make good performance easier to achieve.
But a badly built static site can still be heavy.
And a carefully optimised dynamic site can be fast.
There is no substitute for sensible implementation.
Does speed affect Google rankings?
Google says Core Web Vitals are used by its ranking systems and recommends achieving good results for Search and user experience.
But Google also makes clear that there is no single "page experience" signal and that relevant helpful content can still rank even when page experience is imperfect.
That is the right perspective.
Speed is part of SEO.
It is not a replacement for relevance, content or authority.
If somebody sells website speed as the secret to ranking first, they are oversimplifying.
Lab tests and real users are different
Tools such as Lighthouse and PageSpeed Insights can test a page under controlled conditions.
Real-user data reflects what actual visitors experienced across devices and connections.
Both are useful.
A lab test is excellent for finding problems.
Real-world Core Web Vitals tell you how the site performs in practice.
On a new or low-traffic site, there may not be enough field data immediately.
That does not mean you cannot optimise it.
It simply means you should understand what the measurement represents.
A simple site has an advantage
Every extra layer has a cost.
Another plugin.
Another font.
Another animation.
Another tracker.
Another huge hero video.
Sometimes the value is worth it.
Often it is not.
This is one reason Built by Gavin tends toward lean architecture and focused design.
A small-business site should not need enterprise-scale machinery to display a handful of strong pages.
How fast do I want a Built by Gavin site to feel?
Immediate enough that speed does not become part of the customer's thought process.
That is the practical standard.
I want good Core Web Vitals where reasonably achievable.
I want images handled properly.
I want mobile to feel responsive.
I want the site to avoid avoidable bloat.
But I am not going to sacrifice useful design or functionality to boast about a meaningless perfect score.
Performance is a means to a better experience.
The bottom line
A good website should feel fast, responsive and visually stable.
Google's current good Core Web Vitals targets are LCP within 2.5 seconds, INP below 200 milliseconds and CLS below 0.1.
Use those as useful technical targets.
Then remember why you are optimising them:
for the person using the website.
Not for the screenshot of the score.
Is your current site noticeably slow?
See my website options or send me the URL.
If performance is part of the problem, I can look at whether the cause is images, scripts, architecture or simply too much unnecessary technology.
---