Most business owners don't think about website speed until someone mentions it. Then they go look at their site on their phone, and it loads in two seconds, and they think "seems fine to me."

Here's the problem: you load your website all the time. It's cached in your browser, cached on your device, familiar to your network. You're not measuring the same experience a first-time visitor has — especially one on a mid-range phone on a 4G connection in a coffee shop.

That visitor might be waiting four, five, six seconds. And they're leaving.

The business case first

Let me lead with the numbers that matter before getting into the technical stuff.

Google has published research showing that as page load time goes from one second to three seconds, the probability of a visitor bouncing increases by 32%. From one second to five seconds, it's a 90% increase. From one second to ten seconds, it's 123%.

Separately, Google uses page speed as a ranking factor for search results. Slow sites rank lower. Lower rankings mean less traffic. Less traffic means fewer leads. The math compounds quickly.

And on the conversion side: Amazon calculated years ago that every 100ms of latency cost them 1% in sales. They have more data than anyone else, and they take load time seriously at a scale most businesses can't imagine. The principle translates even at small business scale.

Speed isn't a nice-to-have. It's a revenue lever.

What actually makes a website slow

Images that haven't been optimized. This is the most common culprit. A photo from a camera is often 5–15MB. An optimized web image for the same visual quality should be under 200KB. That's a 50x size difference. Multiply it by ten images on a homepage and you're making visitors download 100MB of data to see a page that should be 2MB.

Too many HTTP requests. Every element on a page — images, fonts, stylesheets, scripts, icons — is a separate request to the server. Each one adds latency. A page with 80 requests will load significantly slower than one with 20, even if the total file size is the same.

Render-blocking JavaScript. When a browser loads a page, it has to stop and execute JavaScript before it can continue rendering. If there are large JS files loading in the wrong order, the visitor stares at a blank or partially rendered page while the browser works through it. This is fixable, but requires deliberate attention.

No caching. When someone revisits your site, or when a CDN serves your assets, caching means files are stored closer to the user and don't have to be fetched from the server every time. Without caching configured properly, every page load is a full round trip.

Shared hosting with limited resources. Budget hosting means your site shares server resources with hundreds or thousands of other sites. When your neighbor gets a traffic spike, your site slows down. This isn't a big deal for a low-traffic site, but it's a hidden cost of "cheap" hosting.

What Core Web Vitals actually measure

Google's Core Web Vitals are the specific metrics it uses to assess page experience. There are three main ones:

Largest Contentful Paint (LCP): How long until the largest visible element on the page loads. This is what users perceive as "the page loaded." Google wants this under 2.5 seconds. Above 4 seconds is poor.

Cumulative Layout Shift (CLS): How much the page jumps around as elements load. You've experienced this — you go to click a button and the page shifts and you click something else. Google measures this instability and penalizes pages with high CLS scores.

Interaction to Next Paint (INP): How quickly the page responds when you interact with it — clicking a button, typing in a field. A sluggish response signals poor JavaScript performance.

These aren't abstract — you can measure them for your site right now using Google's free PageSpeed Insights tool.

What to fix first

If you want to improve performance without rebuilding from scratch, these are the highest-impact changes roughly in order:

  1. Optimize and compress images — use modern formats like WebP
  2. Enable browser caching and use a CDN
  3. Remove or defer render-blocking scripts
  4. Audit and remove unnecessary plugins or third-party scripts
  5. Move to better hosting if you're on budget shared hosting

If your site has fundamental architectural problems — old platform, bloated codebase, no performance budget built in from the start — patches will only get you so far. At some point the right move is a rebuild designed for performance from the ground up.

Either way, the first step is measuring where you actually are. You can't improve what you haven't quantified.

If you want to know how your site performs and what it would take to fix it, reach out. I'll run it through the tools and give you an honest read.