What actually makes a business website fast

Most site speed advice starts in the wrong place: install a caching plugin, compress the images, enable a CDN. Those help. But they are remediation for decisions already made, and they cannot rescue a site whose weight is structural.

Speed is decided earlier than people think.

The biggest factor is how much code you agreed to run

Open the network tab on a typical business website and count the third-party requests. A chat widget, two analytics tools, a heatmap recorder, a marketing pixel or three, a review widget, a font service, a cookie banner, an A/B testing script. Each was added for a defensible reason. Together they frequently outweigh the entire site.

Worse, they are largely outside your control. They can slow down, break, or start loading more than they used to, and your site inherits that without warning.

The discipline: every third-party script must have a named owner and a stated purpose. Anything nobody will defend gets removed. Review the list quarterly — these accumulate silently.

The second factor is what has to happen before the page renders

A page is slow to appear when the browser has work to do before it can paint. Render-blocking stylesheets and scripts, fonts that hide text until they load, layouts that depend on JavaScript to position anything.

The practical fixes are unglamorous and effective: inline the CSS needed for the top of the page, load the rest asynchronously, use font-display: swap so text is readable immediately, and set explicit width and height on images so nothing jumps as it loads. That last one is the single most common cause of a poor layout-shift score, and one of the easiest to fix.

The third factor is images, and it is still images

Images are usually the heaviest thing on a page and the easiest to get wrong. The rules have not changed:

• Serve modern formats — WebP or AVIF — with a fallback.
• Serve the size actually being displayed, not a 4000px original scaled down in CSS.
• Lazy-load anything below the fold, and never lazy-load your hero image.
• Set explicit dimensions so the layout is stable before the image arrives.

What matters less than people think

Hosting matters, but is rarely the bottleneck on a site with four megabytes of scripts. Upgrading the server so a bloated page arrives marginally sooner is treating the symptom.

Your PageSpeed score is a diagnostic, not a goal. Chasing 100 has real diminishing returns past the point where the page is genuinely fast for real users on real connections. Field data from actual visitors beats a lab score.

Minification is worth doing and is almost never the reason a site feels slow.

Test the way your customers browse

Developers test on fast laptops on office connections, which hides most problems. Test on a mid-range phone on a real mobile network. That is where the majority of your traffic is, and it is where a heavy site stops being a metric and starts being a lost enquiry.

The uncomfortable summary

Speed is mostly a discipline problem, not a technology problem. Sites get slow the same way rooms get cluttered — one reasonable addition at a time, each individually justified, with nobody responsible for the total.

Give someone that responsibility and most of the problem disappears.