Why Your Website Is Slow: A 5-Minute Audit

A slow company website doesn't just test patience—it burns inquiries. Google's research puts numbers on it: on mobile, 53% of visits are abandoned when a page takes longer than three seconds to load; as load time stretches from one second to three, bounce probability climbs 32%, and every extra second costs roughly 7% in conversions1. Search engines notice too. Google folds page experience into rankings, and if China is one of your markets, Baidu has explicitly suppressed pages whose mobile first screen takes three seconds or more since its "Lightning" algorithm launched in 20172.

The good news: a slow small-business site is rarely a mystery. Three specific problems account for most of it—images, server and caching, and third-party scripts. HTTP Archive's annual crawl of millions of pages found the median mobile page now weighs 2.3 MB, with images alone accounting for 900 KB3.

This article walks through all three: how to tell if you have each problem, and how to fix it. A five-minute checklist wraps it up.

• The yardstick is LCP (Largest Contentful Paint) from Core Web Vitals: under 2.5 seconds passes, over 4 seconds fails4
• Suspect #1: oversized hero images—the single biggest weight on most homepages; at the 90th percentile, homepage images approach 6 MB3
• Suspect #2: a slow server with no caching—watch TTFB (time to first byte) and cache headers
• Suspect #3: third-party scripts piling up—analytics, chat widgets, maps, one snippet at a time
• Tools: PageSpeed Insights plus browser DevTools, ten minutes total

First, the yardstick: how slow is "slow"

Arguing about speed without a shared yardstick goes nowhere—"feels fast to me" versus "the customer says it won't open" is a permanent argument. The industry standard is Google's Core Web Vitals (CWV), and the metric that tracks "loads slow" is Largest Contentful Paint (LCP): the time it takes to render the largest content element in the viewport—usually the hero banner or the headline block. Under 2.5 seconds passes; over 4 seconds is rated poor4.

Check mobile first. In HTTP Archive's field data, the median desktop page hits LCP in 2.5 seconds, while the median mobile page takes 6 seconds—more than half of all pages rate "poor" on phones3. Your future customers are exactly the people who find you on a phone and decide whether to call.

To check yours: open PageSpeed Insights, enter the URL, wait a minute, and read the LCP under the "Mobile" tab. Everything below revolves around that number.

Suspect #1: the hero image nobody resized

The most common accident looks like this: the designer delivers a 4000px-wide render, and it goes straight into the CMS as the homepage banner. Or the owner photographs the factory floor on a phone and uploads 4-8 MB originals untouched. In the Web Almanac stats, median homepage images weigh about 1 MB (900 KB mobile, 1.05 MB desktop); the 75th percentile loads 2.5 MB of images, and the 90th percentile approaches 6 MB3—the further down the ranking you look, the less the images look processed.

How to check: F12 → Network → filter Img → reload, and read the total for above-the-fold images; or right-click the hero image, open it in a new tab, and look at its size. A single above-the-fold image over 500 KB almost certainly hasn't been compressed.

Fixes, in order of payoff:

1. Convert to WebP. At the 90th percentile, a JPG weighs 266 KB, the same image as WebP 107 KB, and AVIF gets it down to 46 KB3. Every mainstream browser in 2026 supports WebP—there is no excuse left for raw JPGs on a homepage.
2. Match the image to the display size. If the banner renders 1200px wide, don't ship a 4000px original—the extra bytes are pure waste, and the browser still has to scale it down.
3. Prioritize the hero, lazy-load the rest. Preload the one big above-the-fold image; give everything below the fold loading="lazy" so second-screen images never compete for first-screen bandwidth.

A trade-off from our own site: we wanted motion in the homepage hero. AI-generated video came out at tens of megabytes—unshippable on mobile—so we switched to a frame-sampled WebP animation compressed to 1.8 MB, with an 18 KB static image painted first and the animation taking over once it arrives. Motion is negotiable; first-screen time is not. Every image on our site is WebP, and the two hero images total 66 KB.

Suspect #2: a slow server and missing caches

If the images are already lean and the site still drags, look at the server side. Meet time to first byte (TTFB): the time from sending the request to receiving the first byte back from the server. It sets the floor for everything else—no amount of image optimization saves an LCP when the server freezes for half a second before responding.

The classic small-business setup pairs a bargain virtual host with dynamic rendering on every request: each visitor triggers a fresh round of database queries and page assembly, and once the CPU saturates, everyone queues. The second classic is missing cache headers: images, JS, and CSS that never change still get re-downloaded on every visit.

Check in two steps:

1. Measure TTFB. PageSpeed Insights reports it; or from a terminal:

curl -o /dev/null -s -w '%{time_starttransfer}\n' https://your-domain.com/

Run it three times and average. Anything under 0.8 seconds on a home connection is healthy; beyond that, investigate. 2. Inspect cache headers. F12 → Network → click any image or JS file → Response Headers → look for Cache-Control. A value like max-age=31536000, immutable means it's configured; nothing at all, or max-age=0, means every visit downloads from scratch.

Fixes:

• Go static where you can. A company site whose content changes weekly can pre-render pages at build time (or cache them server-side for the long term), dropping TTFB from hundreds of milliseconds to tens. On our own site, HTML responses measure around 0.15 seconds with zero rendering queue on the server.
• Set long cache lifetimes on static assets. Version the filenames (content changes → new name), pair with max-age=31536000, immutable, and returning visitors read everything from local cache without transferring a byte.
• Add a CDN when customers and server live half a world apart. Export businesses take note: a US-hosted site serving European customers loses two to three hundred milliseconds to physics before anything else happens. A CDN copies your content to nodes near the customer.

Suspect #3: third-party scripts that add up

After fixing the first two, one category of slowness remains self-inflicted: other people's code on your pages. In the Web Almanac stats, 92% of pages include third-party resources, and scripts account for roughly a third of third-party requests5. The typical small-business stack: analytics, a chat widget, a maps embed, a form widget, an embedded video—each one downloads, parses, and executes on your customer's phone, from servers you don't control: when they're slow, you're slow.

The insidious part: every stakeholder only ever adds "one small snippet," and nobody confesses when the page starts crawling.

How to check: F12 → Network → reload, and count the requests to domains that aren't yours; or simply count components—how many things on the page belong to someone else?

Fixes:

• Subtract. One analytics tool is enough. Three that nobody reads is homework, not insight.
• Load chat widgets on demand. Render a static image or button first, and pull the real widget only when the user clicks—visitors who never click never pay for it.
• Don't embed video directly. A video embedded on a homepage costs a median 410 KB on mobile3; a poster image that loads the video on click removes that cost for the majority of visitors.

The five-minute checklist

You don't need to memorize any of the above. Work through this table with two tools: PageSpeed Insights and browser F12.

A site green across all six typically opens within two seconds on mobile. If three or more rows fail, fix the biggest bottleneck first, then retest.

Where to start

A slow website is an engineering problem, not bad luck. Work through images, server caching, and third-party scripts in that order, and you can locate most of the slowness. Run the checklist first to get numbers—images are always the first cut, caching the second, scripts the third. Still slow after all three? Then the problem is likely the server or the site's architecture itself, and that's another conversation.