TL;DR
- A 1-second delay in load time reduces conversions by 7%; as load time increases from 1 to 3 seconds, bounce probability rises 32%
- Google's Core Web Vitals are a direct ranking signal since 2021 — a slow site loses search visibility on top of losing visitors
- The root cause of most slow sites is the server itself: shared hosting TTFB commonly runs 800ms–2000ms vs. under 100ms on managed platforms
- Most of the sites we inherit are losing 3–5 seconds to hosting before a single image loads
Here's something we see constantly: a business owner invests in a well-designed website, spends money on ads or SEO to drive traffic to it, and then wonders why the leads aren't converting the way they expected. We look at the site and find pages taking four seconds to load on a good connection. Six or seven on mobile.
The design is fine. The copy is fine. The hosting is the problem — and it's silently costing them customers every day.
Why load time affects conversions directly
Slow load time is not a minor annoyance — it is a measurable conversion barrier that costs money on every page view.
A few data points worth knowing:
- 47% of visitors expect a page to load in 2 seconds or less. (Akamai/Forrester — the underlying behavior has only gotten less patient)
- A 1-second delay in load time reduces conversions by 7%. (Portent) If your site generates $10,000/month, that's $700/month evaporating from one second of lag.
- As load time increases from 1 to 3 seconds, the probability of a visitor bouncing increases by 32%. (Google)
- Walmart found that every 1-second improvement in page load time increased conversions by 2%. At Walmart's scale that's enormous, but the principle applies to any site.
These aren't edge cases. They describe what happens on every slow website, including yours, when visitors hit a loading spinner and decide not to wait.
The underlying reason is straightforward: a slow website signals unreliability. If the page takes four seconds to load, a visitor reasonably wonders whether the company behind it is equally slow to respond, ship, or support. It may not be a conscious thought — but the decision to leave is real.
What Google measures: Core Web Vitals
Since 2021, Google has used a set of performance metrics called Core Web Vitals as a direct ranking signal. A slow site doesn't just lose visitors — it shows up lower in search results, meaning fewer visitors to lose in the first place.
The three metrics that matter:
Largest Contentful Paint (LCP) measures how long it takes for the largest visible element on the page — usually a hero image or headline — to load. Target: under 2.5 seconds. Most of the slow sites we inherit are in the 4–8 second range on LCP alone.
Interaction to Next Paint (INP) measures how quickly the page responds when a visitor clicks something. Target: under 200 milliseconds. Poorly optimized JavaScript is the usual culprit here. Note: INP replaced FID (First Input Delay) as a Core Web Vital in March 2024.
Cumulative Layout Shift (CLS) measures visual stability — specifically, how much the page jumps around as it loads. Target: 0.1 or less.
You can check your own scores for free using Google PageSpeed Insights or GTmetrix. If your LCP is over 3 seconds or your PageSpeed score is under 50, your hosting environment is likely a significant factor.
What actually causes slow load times
A lot of content about site speed focuses on code-level optimizations — compressing images, minifying CSS, enabling caching. Those things matter. But there's a ceiling to what code-level fixes can accomplish if the underlying server is slow.
Time to First Byte (TTFB) is the time between a browser making a request and receiving the first byte of a response from your server. It measures how fast your server is, before images or CSS even enter the picture. A well-configured server on quality hosting should have a TTFB under 200ms. Sites on shared hosting commonly run 800ms–2000ms — meaning the server itself is costing you a full second before your page even starts loading.
That said, here are the most common issues we find at the application level:
Unoptimized images are the most frequent culprit on business websites. A homepage hero image uploaded at 4000px wide when it's displayed at 1200px is doing three to four times the work it needs to. Convert images to WebP, size them correctly, and use lazy loading for anything below the fold.
Too many plugins is a WordPress-specific problem that compounds quickly. Each plugin can add database queries, CSS files, and JavaScript to every page load. Twenty moderately inefficient plugins will outweigh most other optimizations.
No page caching means WordPress rebuilds every page from scratch on every visit — running PHP, querying the database, assembling HTML — even when nothing has changed since the last visitor loaded it. A caching layer eliminates most of that overhead for repeat requests.
Render-blocking scripts are JavaScript files that force the browser to stop and wait before it can display anything on screen. Third-party scripts — chat widgets, ad tags, analytics, social embeds — are common offenders, and they're often loaded by well-meaning marketing teams without awareness of the performance cost.
No CDN means every visitor fetches assets from a single server in one geographic location. A content delivery network caches your static files on servers worldwide and serves them from the location closest to each visitor.
The hosting layer is the foundation
All of the above optimizations work better — or worse — depending on the quality of your hosting environment. This is where most of the performance gap between a 1-second site and a 6-second site actually lives.
Managed WordPress hosting handles several of these at the infrastructure level:
- Server-level page caching so PHP and MySQL aren't running on every request
- Object caching via Redis, so repeated database queries are served from memory
- CDN integration built in, not configured separately
- PHP-FPM tuned for WordPress workloads
- SSD storage with fast I/O throughout
When clients move to us from shared hosting, the before-and-after is rarely subtle. LCP dropping from 6 seconds to under 1.5, and PageSpeed scores jumping 30–40 points, with no changes to the site content at all — that's a routine outcome from a hosting migration done right.
How to check where you stand
Start with these two free tools:
- Google PageSpeed Insights — run both mobile and desktop. Mobile scores are typically lower and more consequential for most business sites.
- GTmetrix — gives you a waterfall view of what's loading and in what order, which makes it easier to identify specific bottlenecks.
Pay particular attention to TTFB and LCP. If your TTFB is over 400ms, that's a hosting or server configuration issue — no amount of image compression will fix it.
Frequently Asked Questions
What is a good LCP score? Google's threshold for a "Good" LCP is under 2.5 seconds. Between 2.5 and 4 seconds is "Needs Improvement." Above 4 seconds is "Poor." Most business websites on shared hosting land in the Poor category — 4–8 seconds is common before any optimization.
Does page speed affect Google rankings? Yes, directly. Google made page speed a ranking signal in 2010 and expanded it with the Core Web Vitals update in 2021. Sites with Poor Core Web Vitals scores rank lower than comparable sites with Good scores, all else equal.
How do I check my Core Web Vitals for free? Google PageSpeed Insights shows field data (real user measurements from Chrome users) and lab data for any URL. Google Search Console also shows aggregate Core Web Vitals data for your entire site under the "Experience" section.
What is TTFB and why does it matter? Time to First Byte (TTFB) measures how long a browser waits for the first byte of data from your server. A slow TTFB (over 400ms) means your server is the bottleneck — no front-end optimization will compensate for a server that responds slowly. TTFB is primarily a hosting and server configuration issue.
Can I improve my score without changing hosting? Yes, to a point. Image optimization, caching plugins, and removing unnecessary JavaScript can improve scores significantly on a slow server. But if your TTFB is high, you're working around the root problem rather than solving it. The ceiling for optimization on bad hosting is much lower than on purpose-built infrastructure.
What causes mobile scores to be lower than desktop? Mobile scores simulate a slower CPU and network connection (roughly a mid-range Android device on 4G). Render-blocking JavaScript and large images hit mobile harder because the device has less processing power. Mobile is also the more consequential score for most businesses since the majority of web traffic is mobile.
If you're not sure what you're looking at or what to do about it, get in touch. We've done enough of these audits that we can usually tell you in a short conversation whether the problem is fixable at the code level or whether the hosting environment is the real issue.