A slow website almost never has a mysterious cause. When we measure one, the problem is nearly always one of the same seven things — and most of them are visible in a free tool within ten minutes, without reading a line of code.
This is the checklist we run first. Work through it with your own site open in another tab.
First, get a number
Opinions about speed are useless; numbers are not. Open PageSpeed Insights, paste your address and run the test. Look at the Mobile tab, because that is how most visitors arrive and how Google judges you. Three things matter on that page:
- The performance score, 0–100. Above 90 is good. Between 50 and 89 is where most small-business sites sit. Below 50 is costing you customers.
- Largest Contentful Paint (LCP) — how long until the main thing on the screen appears. Google’s “good” line is 2.5 seconds; a fast site is under 1.5.
- The “Diagnostics” list lower down. Each line is a cause, roughly in order of damage.
Or run the address through the meter on our homepage, which shows the same speed figure next to the site’s carbon footprint and page weight. Keep the result open; the seven causes below map onto what you’ll see there.
1. Images that are far bigger than the space they fill
The single most common cause, and the easiest to fix. A photo straight from a phone is 4,000 pixels wide and 3–6 MB. The slot it fills on a page is 800 pixels wide and should weigh 60–100 KB. Multiply that mistake by eight photos on a homepage and the page weighs more than a short video.
How to spot it: in PageSpeed, look for “Improve image delivery” or “Properly size images” — it names the files and the savings. On the meter, a page over 2 MB with images as the biggest category is almost always this.
The fix: resize images to the size they’re shown at, serve them in a modern format (WebP or AVIF), and load the ones below the fold only when the visitor scrolls to them. A well-built site does this automatically for every image.
2. Third-party scripts: chat widgets, pixels, embeds
Every tool you’ve added “for free” — a chat bubble, a Facebook pixel, Google Analytics, a booking widget, an embedded map, a review carousel — is code downloaded from someone else’s server and run before your page is usable. Each one is small on its own. Together they are often the heaviest thing on the page, and they run on the main thread, which is the one thing the browser has for drawing your page.
We measured this on our sister site, leavsy.com. The HubSpot analytics and consent script weighs 105 KB. Loaded the usual way, in the head of the page, it cost about 15 points on the mobile score and pushed the main content from 1.6 seconds to 3.5. Loading the same script after the page has painted brought the score back to 98. Same tool, same data, different timing.
How to spot it: PageSpeed → “Reduce the impact of third-party code”. It lists each outside service with the time it blocked the page.
The fix: remove what you don’t use (most sites have at least one dead pixel), and load the rest after the page is visible. A good developer does this by default; most page builders don’t.
3. A theme or page builder that ships everything
Page builders — Elementor is used on 31.5% of WordPress sites, according to W3Techs — let you drag any element onto any page. To make that possible, they load the code for every element on every page, whether you used it or not: sliders, counters, accordions, icon libraries, animation engines. Your three-paragraph About page downloads the same half-megabyte of machinery as a page with twenty widgets.
How to spot it: PageSpeed → “Reduce unused JavaScript” and “Reduce unused CSS”. If the unused share is above 70%, you’re paying for features you don’t use.
The fix is structural, not a setting: build the page from only the parts it needs. That’s the main reason a hand-built site is faster than a builder site with identical content.
4. The server assembles the page on every visit
A WordPress page doesn’t exist until someone asks for it. Each visit runs PHP, queries the database, runs every active plugin, and assembles the HTML — then sends it. On a busy or cheap server that assembly alone takes half a second to several seconds before a single pixel can appear.
How to spot it: PageSpeed → “Reduce initial server response time” (also shown as TTFB, time to first byte). Anything over 600 ms is the server, not your content.
The fix: caching, so the page is assembled once and reused; or a static site, where the page is built in advance and simply handed over. Static pages have a server response time of a few tens of milliseconds, because there is nothing to compute.
5. Web fonts: too many families, too many weights
A typeface is a download. Four families in six weights each is twenty-four font files, and the browser often waits for them before it shows your text at all. Fonts loaded from Google’s servers add a connection to a second domain on top.
How to spot it: PageSpeed → “Font display” or “Ensure text remains visible during webfont load”; in the meter, fonts listed as a large category.
The fix: two families at most, only the weights actually used, hosted on your own domain. On our bakery demo, trimming the display font from “all weights” to the three the page actually renders cut 23 KB on every visit, with no visible change.
6. Cheap hosting with no CDN
Your visitor in Dublin is loading a page from a server in Frankfurt, or in Virginia. Every file makes that round trip. On shared hosting, your site also queues behind hundreds of other sites on the same machine.
How to spot it: a high server response time (cause 4) that stays high even for small pages; speed that varies wildly by time of day.
The fix: a content delivery network (CDN) puts copies of your files in dozens of cities, so each visitor loads from the nearest one. For a static site this is free: we host on Cloudflare’s network, which has data centres in over 300 cities, at no monthly cost.
7. Autoplay video, sliders and animation libraries
A background video is 5–30 MB that downloads whether or not anyone watches it. A hero slider loads all five slides and a JavaScript library to rotate them — and research consistently finds almost nobody clicks past the first slide. Animation libraries bolted onto a page add hundreds of kilobytes to make things fade in.
How to spot it: big media files in the Network list, or simply watch the page: if things are moving before you’ve done anything, something is being downloaded to make them move.
The fix: one strong image instead of a slider; video only when the visitor presses play; animation done in CSS, which is built into every browser and weighs nothing. Our three demo sites have entrance animations, parallax photos and rotating elements, and ship zero kilobytes of JavaScript.
What “fast” looks like in numbers
So you know what you’re aiming at, these are the figures of a genuinely fast small-business page on mobile:
- Total weight under 500 KB; under 250 KB is excellent.
- Fewer than 30 requests.
- Main content visible in under 1.5 seconds.
- Performance score of 95 or above.
For comparison, the median web page weighs about 2.4 MB, according to the HTTP Archive. Our demo sites weigh 120–250 KB and score 98–100. The gap is not exotic engineering; it is the seven items above, done right.
The ten-minute version
- Run your site through PageSpeed Insights on Mobile and note the score and LCP.
- Read the Diagnostics list and match each line to a cause above.
- Count your third-party tools. Delete any you don’t actively use.
- Check the biggest images: if any is over 300 KB, that’s your first fix.
If the list is long and you’d rather someone else did the fixing, ask for a free 24-hour audit. You’ll get the numbers, the causes in plain language, and a fixed price to put it right — no obligation.