Slow websites are often less mysterious than they look.
Somebody opens the homepage.
The logo appears.
Then the page thinks about life for a while.
Eventually the hero image arrives like it had to clear customs.
The first instinct is usually: "The hosting is slow."
Sometimes that is true.
Sometimes the server is doing fine and the page is simply trying to deliver twenty megabytes of assets before the visitor can see what the business does.
That is not a hosting problem.
That is a packing problem.
Before changing hosts, check what the page is actually downloading. Moving a 12 MB image to a faster server still leaves you with a 12 MB image.
Start with images because images are very good at getting huge quietly.
A phone takes a beautiful photo.
Somebody uploads the original.
The website displays it at 900 pixels wide.
The source file is 6,000 pixels wide.
Congratulations. The browser just downloaded a billboard so it could print a postcard.
This happens constantly because the image still looks normal once the browser squeezes it into the layout.
The visitor does not see the waste.
They just feel the delay.
Resize images for the size they actually need to serve. Compress them. Use a modern format where it makes sense. Give responsive images multiple source sizes instead of making every device download the desktop monster.
Image dimensions and file size are not the same problem.
Two images can both be 1600 by 900 pixels and have wildly different file sizes.
One might be a few hundred kilobytes.
The other might be several megabytes because it was exported with aggressive quality settings, unnecessary metadata, or a format badly matched to the content.
This is why "but I resized it" does not close the case.
Check both:
- the actual pixel dimensions,
- and the actual transfer size.
A hero image should not need its own loading dock.
Lazy loading is good. Lazy-loading your hero image is not.
Lazy loading below-the-fold images is useful because it delays downloads until those images are actually needed.
That saves bandwidth and lets the browser focus on what is visible first.
The mistake is applying the same treatment to the image that is already sitting at the top of the page.
web.dev specifically warns against lazy-loading an image that is likely to be the Largest Contentful Paint element because doing so delays when the browser starts fetching it.
In plain English: if the big hero image is supposed to appear immediately, do not tell the browser to wait before downloading it.
Lazy-load what can wait. Prioritize what the visitor is already staring at.
After images, find out who invited all the JavaScript.
Chat widget.
Review widget.
Analytics.
Heatmap.
Appointment scheduler.
Social feed.
Marketing popup.
Three trackers from tools nobody remembers installing.
Each one might be defensible.
Together they can turn a small-business homepage into a software convention.
Third-party scripts can add network requests, parsing work, execution time, layout changes, and delays before the page responds smoothly.
Do not ask only: "Does this widget work?"
Ask: "Is this widget worth what it costs the page?"
Background video is where tasteful restraint sometimes goes missing.
Video can look great.
It can also become the single heaviest thing on the homepage by an absurd margin.
Autoplay video deserves an especially hard look on mobile.
If the first screen exists mainly to say "We remodel kitchens", the visitor may not need an eight-second cinematic drone shot of a faucet before receiving that information.
Use video when the motion communicates something.
Compress it. Provide a poster image. Avoid loading more than necessary.
Your homepage is a sales tool, not the opening credits to a prestige drama.
Core Web Vitals are not a personality test for your website.
Google currently describes Core Web Vitals as real-world measurements of loading performance, responsiveness, and visual stability.
How quickly the main visible content appears.
How quickly the page responds to user interactions.
How much the page unexpectedly shifts while loading.
Those are useful targets, not a reason to spend three days chasing a perfect score while the business phone number is still wrong.
Google itself says there is no single page-experience signal and recommends looking at the overall experience rather than obsessing over one metric.
Good.
Because the goal is not to impress Lighthouse.
The goal is to make the site fast and usable for actual people.
The 15-minute speed audit I would do before touching the server.
If you want a quick baseline before opening DevTools, run the free Template Forge SEO Health Checker. It can flag oversized-image pressure, page-weight problems, LCP issues, and other homepage signals so you know where to start looking.
If you find a 12 MB hero image in step two, you are allowed to stop looking mysterious for a minute.
Fix the obvious thing.
Measure again.
Then move down the list.
Performance work gets much easier when you treat the page like a shipment: inspect what is being sent, remove what does not belong, shrink what is too large, and prioritize what has to arrive first.
Sources behind the speed lecture
- Google Search Central: Core Web Vitals and Google Search
- Google Search Central: Understanding page experience
- web.dev: Optimize Largest Contentful Paint
- web.dev: The performance effects of too much lazy loading
Make the page carry less before asking the server to run faster.
Measure the payload.
Fix the obvious weight.
Then optimize what remains.