Your site has three seconds to convince someone to stay. Most B2B companies spend them loading uncompressed images, plugins accumulated over years, and a server that charges the minimum for reasons that show. By the time the visitor sees the menu, they’ve already decided.
Google documented this years ago and the number hasn’t essentially changed: when load time goes from one to three seconds, the probability of the visitor abandoning the site increases by 32%. At five seconds, that rises to 90%. These aren’t mass e-commerce figures — they apply just as well to the procurement manager looking for an industrial services supplier on a Tuesday afternoon.
The real problem isn’t that the site is slow. It’s that most companies don’t know, or know and assume “for what we use it for, it’s fine”. That logic has a concrete cost worth reviewing.
Why corporate sites accumulate weight without anyone noticing
Corporate websites aren’t born slow. They become slow gradually, by accumulation. Every time someone uploads a photo from their computer without resizing it, the site gains 3 to 8 MB of unnecessary weight. Every time a plugin is installed to solve one specific problem and never uninstalled when it stops being used, it keeps running in the background. Every time “economical” hosting with shared resources is bought, processing capacity is shared with dozens of other sites.
The typical result on a B2B site three or four years old with no technical maintenance: images ten to twenty times heavier than necessary, fifteen to thirty active plugins of which half serve no visible function, a theme or template with JavaScript that blocks page rendering, and a server located overseas answering requests from Australia.
This isn’t negligence — it’s the natural consequence of building a site without long-term technical judgement. Someone designed the site to look good on screen, delivered it, and since then nobody with technical judgement has reviewed it.
Cheap hosting has a price that doesn’t appear on the invoice
A low-cost shared server can work reasonably well when the site receives few simultaneous visits. The problem appears at the moments that matter: when a LinkedIn campaign generates traffic, when an article starts ranking, when a prospect arrives after a commercial meeting and wants to review the services properly.
At those moments, the server takes 400 to 800 milliseconds just to answer the first request — before transferring a single line of content. That time is called Time to First Byte (TTFB) and is one of the indicators Google uses to evaluate user experience. A healthy TTFB is under 200 milliseconds. The difference can seem technical and abstract until it translates into a prospect closing the tab before seeing the value proposition.
The most common causes of slowness
Unoptimised images. The most frequent problem and the easiest to fix. A photo taken with a modern camera can be 5 or 6 MB. Served directly on the site, that image is the main bottleneck. Web images should be in WebP format, compressed, and sized to the container they appear in.
Unnecessary JavaScript. Many sites built on content management systems load dozens of JavaScript files that are largely unnecessary — active plugins nobody uses, duplicated tracking scripts, entire libraries included when only one function is needed. All of that JavaScript has to be downloaded, parsed and executed before the page is fully interactive.
Slow hosting. The server hosting the site has a baseline response time that no amount of site optimisation can compensate for. An overloaded shared host can take 800 milliseconds to respond before the browser has received a single line of content. On well-configured hosting, that number should sit below 200 ms.
No caching configured. Caching lets browsers and intermediate servers keep a copy of the site’s resources rather than downloading them on every visit. Without caching correctly configured, every visit downloads everything from scratch.
Unoptimised web fonts. Custom fonts (Google Fonts, Typekit and the like) are external resources the browser has to download. If they aren’t correctly configured with font-display: swap, they can block text rendering until they load.
What Google measures and why it affects your position
Since 2021, Google has included Core Web Vitals as a ranking factor. It isn’t a trend or a novelty — it’s an established standard that partly determines whether your site appears before or after a competitor’s when someone searches for what your company offers.
Core Web Vitals come down to three metrics:
LCP (Largest Contentful Paint): measures how long the largest visual element on the page takes to appear — usually a main image or a prominent block of text. The acceptable threshold is 2.5 seconds. Most unoptimised corporate sites sit between 4 and 7 seconds.
FID / INP (Interaction to Next Paint): measures how long the site takes to respond when the user clicks something. A site with heavy JavaScript can take 300 to 500 milliseconds to process a click — enough for the interaction to feel clumsy.
CLS (Cumulative Layout Shift): measures whether page elements move while loading. It’s that phenomenon where the user goes to click a button and the content shifts a centimetre at the last second. A high CLS signals badly structured front-end code.
A site failing all three doesn’t just frustrate visitors. It tells Google the experience it offers is inferior to other sites on the same topic. The algorithm adjusts positions accordingly. The impact on a B2B site’s technical SEO is direct and measurable.
How speed connects to conversion
Consider an engineering services company receiving 400 monthly visits with a 2% contact conversion rate — 8 enquiries a month. If average load time exceeds four seconds, a technical optimisation bringing it under two seconds can recover 30% to 40% of the traffic that abandons before interacting.
In numbers: if 35% of visitors leave because of speed, and that problem is corrected, the site can go from 400 to 540 effective visits without spending a dollar more on advertising. At the same conversion rate, that translates into 3 to 4 additional enquiries a month. For a B2B company with a substantial average contract value, the calculation justifies itself.
How to evaluate your site’s speed today, without hiring anyone
Before making any decision, measure. These tools are free and require no technical knowledge for an initial diagnosis:
-
Google PageSpeed Insights (pagespeed.web.dev): enter your URL and it returns a score from 0 to 100 for mobile and desktop, along with the specific problems ordered by impact. A score above 80 on mobile is the minimum acceptable threshold for an active corporate site.
-
GTmetrix (gtmetrix.com): shows the page’s total weight, the number of server requests, and a loading waterfall letting you see exactly which element is slowing everything down. The free version is enough for an initial diagnosis.
-
Google Search Console: if the site is already verified there, the “Page experience” section shows directly how many URLs pass or fail Core Web Vitals based on real user data.
Reference scores for a B2B corporate site:
- Mobile: ideally above 70, acceptable above 55
- Desktop: ideally above 85, acceptable above 70
A mobile score below 40 is an active problem affecting both rankings and user experience.
Once you have the results, review this basic checklist. Every point you can confirm as resolved means the site is in better technical shape:
- The site’s images are in WebP or AVIF format (not uncompressed JPG or PNG)
- The site uses an active caching system
- The hosting is located in Australia, or there’s a CDN with local nodes
- The site has no more than ten active plugins in WordPress (or the equivalent elsewhere)
- The LCP measured in PageSpeed Insights is under 2.5 seconds on mobile
- No third-party scripts load synchronously in the header (a badly configured Google Tag Manager is the most frequent case)
- The TTFB measured in GTmetrix is under 200 milliseconds
If more than three of these are unresolved, the site’s speed is actively affecting its performance as a digital asset — in both rankings and conversion.
What to prioritise if the score is low
Not every speed problem has the same impact. In general, the order of priority should be:
- Optimise images — the biggest impact for the least technical complexity
- Review and remove unnecessary JavaScript
- Configure caching correctly
- Evaluate the hosting if TTFB is very high
- Optimise web fonts
80% of the speed improvement usually comes from 20% of the optimisations. It isn’t always necessary to refactor everything — in many cases, optimising images and cleaning up scripts resolves the main problem. When the problems run deeper, technical SEO covers the complete analysis of performance and indexing.
What to do with what you find
Technical diagnosis doesn’t require rebuilding the site from scratch in most cases. The highest-impact optimisations — image compression, caching configuration, server migration — usually resolve 60% to 80% of the problem on a standard corporate site.
What does require judgement is distinguishing when the problem is accumulated technical maintenance and when it’s base architecture. A site built on a generic template loaded with unused functions has an optimisation ceiling: there comes a point where optimising on top of a weak base costs more than starting with a correct technical foundation.
The difference between those two cases isn’t visible at a glance — it requires reviewing the code, the file structure, the active dependencies and the server’s real behaviour under load. That is exactly the kind of analysis PTW’s digital diagnostic covers.
If the metrics you found reviewing your site are far from the thresholds described here, there’s a logical step before any investment decision: understanding precisely what’s failing and what impact it has on the business. PTW’s diagnostic is designed to answer that question with technical and commercial judgement, not with a generic list of recommendations.