How slow is too slow?
There are published thresholds, so nobody has to guess or argue. Largest Contentful Paint under 2.5 seconds, which is the main thing on the page appearing.
Interaction to Next Paint under 200 milliseconds, which is the page answering a tap.
Cumulative Layout Shift under 0.1, which is how far things move while it loads. And you have to hit all three at the 75th percentile of real visits rather than on your own laptop.
Core Web Vitals
That last detail is the one that catches everybody out. Your site feels quick to you because you're on the office wifi with the whole thing already cached. The 75th percentile is a customer on a phone, on mobile data, who has never been to your site before.
What's usually the cause?
Images, nine times out of ten. A photo straight off a phone is several megabytes, and it's usually being displayed at a fraction of its actual size, so the browser downloads an enormous file and then throws most of it away. Serving a properly sized image in a modern format like WebP buys you more than anything else on nearly every site I look at, and it costs nothing except somebody paying attention.
Optimise images
Then scripts. Every plugin, chat widget, analytics tag, heatmap tool and tracking pixel is code that has to be fetched and run before the page settles down. Each one seemed harmless the day it went on. Collectively they're usually why a page is slow to respond rather than slow to appear.
Hosting is third, and it's real but it gets blamed far more than it deserves. Cheap shared hosting adds server response time to everything you do, and it's worth fixing. But if your images are unoptimised, better hosting just delivers the same bloat slightly sooner.
How do you find out which one it is?
Run the page through PageSpeed Insights and read the field data section first, not the big score at the top.
How PageSpeed Insights works The score is a simulation on a machine somewhere. The field data is what actually happened to real people on your site, and it's what Google's own assessment is built on.
Then look at what the report names as your largest contentful element. It's almost always a hero image, and that image is almost always far bigger than it needs to be. Fix that one thing before you touch anything else, and quite often you're done.
Does layout shift matter as much as speed?
It matters more than people give it credit for, because it's the one your customers consciously notice and get annoyed by. Cumulative Layout Shift is the metric for content jumping around while things load, and the usual cause is trivially fixable. Images and ad slots without width and height set, so the browser never reserves the space and everything below jumps when they finally arrive.
Width and height on images
If you have ever gone to tap a link and hit a completely different one because the page moved under your thumb, that was CLS. Setting dimensions on your media fixes most of it in an afternoon.
What order should you fix things in?
Compress and correctly size your images. Set dimensions on everything so nothing moves. Remove every script you can't give a reason for. Then, and only then, have the argument about hosting.
That order is deliberate. The first three are cheap, reversible and usually enough on their own. Migrating hosts is disruptive, and it's the step people reach for first because it feels like buying a solution instead of doing the work.
- Resize and compress every image.
Export at roughly the size it's displayed, not straight off the camera, and serve
WebP where you can. On most sites this alone moves you inside the threshold.
- Set width and height on everything.
Images, embeds, ad slots. It reserves the space so nothing jumps, which is most of your layout shift gone in an afternoon.
Width and height on images
- Delete the scripts nobody can justify.
Go through the tag list and remove anything you can't name a reason for. The heatmap tool from a trial two years ago is still loading on every page view.
- Re-measure on field data, not the lab score.
Run
PageSpeed Insights again and read the field section. If you're inside the thresholds, stop. There's no prize for a hundred.
- Only then argue about hosting.
If server response is genuinely the remaining problem, move. Doing this first is how people spend money and change nothing.
Is my host the problem?
Sometimes, rarely first. Cheap shared hosting adds response time to everything, but if the images are unoptimised, faster hosting just delivers the same weight slightly sooner.
Do I need to remove my chat widget?
Not necessarily, but you should be able to say what it earns. Every third-party script is code fetched and run before the page settles, and most sites are carrying several nobody can account for.
What's a realistic target?
The published ones. Under 2.5 seconds to render the main element, under 200 milliseconds to respond to a tap, under 0.1 of layout movement, at the 75th percentile of real visits. Core Web Vitals