Why your slow site is a sales problem, not an IT problem.

A slow website loses you customers before they read a single word. Speed is not a technical vanity metric — it is the first sales interaction anyone has with your business, and most slow sites are bleeding revenue in plain sight.

Most professional services firms treat page speed as an IT ticket. They ask their developer to "look into it" once a year, get a report full of jargon, and file it away. That is the wrong frame entirely. Speed is a buyer behaviour problem. It belongs in the same conversation as your pricing page, your proposal template, and your sales call script.

Why does a slow site kill sales?

A slow site kills sales because people leave before they convert. Google's own data shows that as page load time goes from one second to three seconds, the probability of a bounce increases by 32 percent. Push that to five seconds and the probability jumps 90 percent. Those are not hypothetical visitors — those are real people who had a real problem, found you in search, and then left because your site made them wait.

Think about what that means in practice. A solicitor's firm running paid search at £8 per click is paying for traffic that bounces before reading the headline. A consultancy that ranks on page one for a competitive term is handing that lead back to a competitor with a faster site. The spend is real. The lost revenue is real. The cause is a slow server or an unoptimised image file that costs nothing to fix.

Speed is also a trust signal. Buyers — especially in professional services — are making high-stakes decisions. They read the speed of your site the same way they read the tidiness of your office or the responsiveness of your email. A site that stutters communicates, at a visceral level, that the business behind it is not on top of things.

What does "slow" actually mean?

Slow means failing Core Web Vitals — Google's three-part measure of real-world user experience. The three signals are Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). LCP measures how fast the main content loads. INP measures how fast the page responds to a click or tap. CLS measures whether the page jumps around while loading.

Google uses these signals as ranking factors. A site that fails all three is penalised in search results relative to a competitor that passes them. For professional services firms competing on a handful of high-value search terms, that ranking gap translates directly into fewer enquiries. You do not need to understand the technical mechanics — you need to understand that Google is measuring the experience your buyers have and adjusting your visibility accordingly.

A practical threshold: aim for LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1. You can check your own scores in Google Search Console under "Core Web Vitals" or by running a free test at PageSpeed Insights. If you score red or amber on mobile, you have a sales problem sitting in your infrastructure.

Who actually owns the speed problem?

The business owner owns the speed problem — not the developer, not the hosting company, not the plugin vendor. Developers solve problems they are asked to solve. Hosting companies sell capacity. No one in that chain is sitting in your business watching enquiry rates and connecting the dots back to page load time.

That ownership gap is why slow sites persist for years at firms that are otherwise well-run. The firm's leadership assumes it is a technical matter outside their remit. The developer assumes it is running fine because no one complained. The result is a site that passes every functional test — buttons work, forms submit, nothing crashes — but quietly haemorrhages leads every single day.

Owning the problem means three things: putting speed on the agenda as a commercial metric, giving someone explicit responsibility to monitor it, and tying performance targets to measurable business outcomes — not Lighthouse scores in isolation.

What are the most common causes?

The most common causes of slow professional services websites are unoptimised images, bloated page builders, too many third-party scripts, and cheap shared hosting. These are not exotic problems. They are the standard residue of a site built quickly and never audited.

Images are the biggest single culprit. A law firm's site will often have a partner headshot uploaded as a 4MB JPEG. Compressed and converted to WebP, that same image is 120KB. The visual quality is identical. The load time difference is seconds.

Page builders — Elementor, Divi, WPBakery — add convenience but also load significant JavaScript and CSS regardless of what you actually use on a given page. A site built with a bloated page builder will almost always score worse than a leaner build, even on the same hosting.

Third-party scripts are the other major drag. Every chat widget, tracking pixel, analytics tool, and cookie consent banner is a script that has to load before or alongside your content. A site with eight third-party scripts running on every page is sending eight separate requests to eight separate servers on every page load. Each one adds latency.

Hosting matters more than most firm owners realise. Cheap shared hosting puts your site on a server alongside hundreds of others. When traffic spikes anywhere on that server, your site slows down. Moving to a managed WordPress host — WP Engine, Kinsta, Cloudways — typically cuts TTFB (time to first byte) by 300 to 600 milliseconds on its own, before any code changes.

What does fixing it actually look like?

Fixing a slow site is a sequence of targeted changes, not a full rebuild. The work falls into four buckets: image optimisation, script management, caching, and hosting.

Start with images. Run every image on the site through a compression tool — Squoosh is free and web-based — and convert to WebP format. Add lazy loading to images below the fold so they only load when a user scrolls to them. This alone can drop page weight by 40 to 60 percent on image-heavy sites.

Next, audit third-party scripts. Open your browser's developer tools, go to the Network tab, and reload the page. Every external domain loading a resource is a third-party dependency. For each one, ask whether you actually need it. Remove what you can. For what remains, load it asynchronously so it does not block the main content from rendering.

Caching stores a static version of your pages so that repeat visitors — and crawl bots — do not trigger a full database query every time. A caching plugin like WP Rocket (for WordPress) handles this without custom development.

If you have done all of the above and still score poorly, the hosting is the constraint. Upgrade the plan or move the site. It is a recurring monthly cost in the range of £20–£60 for a small professional services site — a fraction of the value of a single additional enquiry.

We walked through exactly this sequence with McShanes Solicitors, identifying the specific performance bottlenecks dragging down their visibility in a competitive local market. The changes were unglamorous. The outcome was not.

Where this breaks down

Fixing page speed will not rescue a site with weak content, no inbound links, or a proposition that does not match search intent. Speed is a floor condition — it stops Google and buyers from dismissing you before they engage. It does not replace the substance underneath.

If your pages rank on page three and you have a speed problem alongside a content problem, fix the content first. Speed gains on pages no one finds yet are low-priority. Sequence the work against where traffic actually flows.

What should you do this week?

The first step is measurement — you cannot manage what you have not looked at. Run your site through Google's PageSpeed Insights today. Check both desktop and mobile. Mobile is what matters most; Google indexes your mobile site, not your desktop site.

If you score below 50 on Performance on mobile, treat that as a commercial priority, not a backlog item. Assign it a deadline. Give it a budget. Review it the same way you would review a drop in enquiry volume — because it is causing exactly that.

Speed is one of the foundational signals we address inside Search Foundations — alongside crawlability, site structure, and on-page relevance. These are not glamorous problems. They are also not optional if you want search to work as a reliable acquisition channel.

A site that loads fast, is easy to crawl, and clearly answers buyer intent questions is not sophisticated. It is just doing the basics correctly. Most professional services firms are not doing the basics correctly. That gap is where the opportunity is.