Somebody told you your site is slow. Maybe it was Google Search Console flagging Core Web Vitals. Maybe it was your ad manager showing a 4% landing page conversion rate against an 8% industry benchmark. Maybe you just opened it on your phone on mobile data and watched it stutter.
The instinct is to go looking for the problem. There usually isn't one. In the audits we run at Softshelf, the median slow site has five separate issues, none of which is fatal on its own, that together push a 1.4-second page to 6 seconds.
Get a number before you touch anything
You cannot fix what you have not measured, and you definitely cannot prove to a client (or yourself) that a fix worked without a baseline. Before changing a single line, record three things:
- Lab score — run your URL through Google PageSpeed Insights (or the free scanner on our homepage, which uses the same API). Note the mobile score, not desktop. Mobile is what Google indexes with.
- Field data — the "Discover what your real users are experiencing" panel at the top of the PSI report. This is Chrome User Experience Report data from actual visitors over the last 28 days. If it is present, it beats the lab score every time.
- Largest Contentful Paint (LCP) — the single number that correlates best with people leaving. Anything over 2.5 seconds needs work; anything over 4 seconds is bleeding money.
Google has indexed the mobile version of your site since 2023. A desktop score of 94 and a mobile score of 38 means, as far as ranking is concerned, your score is 38.
The nine causes, ranked by how often we see them
1. Images shipped at the size they were uploaded
This is number one by a wide margin. Someone uploads a 4,200 px hero photo straight from a phone camera, the theme scales it down with CSS, and every visitor still downloads all 3.8 MB of it. The browser has to fetch and decode that file before it can paint your headline.
The fix is unglamorous: resize to the largest size the layout actually renders (usually 1600 px wide for a full-bleed hero, 800 px for a card), convert to WebP or AVIF, and add width and height attributes so the browser reserves the space.
2. Plugins and apps you stopped using a year ago
Every WordPress plugin and Shopify app adds its own CSS and JavaScript to every page, whether that page uses the feature or not. The abandoned pop-up builder from a campaign you ran last Christmas is still loading 140 KB on your checkout page.
Audit the list. If you cannot name what a plugin does and where it appears, deactivate it, test, and delete it. On a typical WooCommerce site we remove 6–11 plugins and recover a full second.
3. Render-blocking CSS and JavaScript
By default, a <link rel="stylesheet"> or a plain <script> in the <head> stops the browser from drawing anything until that file has downloaded and parsed. Stack six of them and your visitor stares at a white screen while a queue drains.
<!-- Blocks rendering -->
<script src="/js/carousel.js"></script>
<!-- Does not block rendering -->
<script src="/js/carousel.js" defer></script>defer is safe for almost any script that touches the DOM after load. async is for independent scripts like analytics. Non-critical CSS can be loaded with a media="print" swap trick or simply moved below the fold.
4. Slow server response (TTFB)
Time to First Byte is how long your server takes to send back the first scrap of HTML. Under 200 ms is good, over 800 ms means the visitor waits nearly a second before anything can even start. Shared £3/month hosting, an uncached database query on every page load, and a server physically located on the other side of the planet from your customers all show up here.
Fixes, in ascending order of effort: turn on page caching, add a CDN, move to a host with servers in your customers' region, then optimise the queries.
5. Third-party scripts
Analytics, heatmaps, chat widgets, review badges, ad pixels, A/B testing tools, consent banners. Each one is a request to a domain you do not control, executing code you cannot optimise. We regularly find sites loading nine or more.
Open the Network tab, sort by domain, and ask of each one: is anyone reading this data? The heatmap tool nobody has logged into since March is costing you conversions to produce recordings nobody watches.
6. Web fonts loading the slow way
Custom fonts are worth having, but the default implementation hides your text until the font file arrives — the flash of invisible text. Three fixes, all one-liners: add &display=swap to the Google Fonts URL, preconnect to the font host, and cut the weights you load. Most sites request six weights and use two.
7. Layout that jumps around while loading
Cumulative Layout Shift is not a speed problem, it is a trust problem — and Google scores it anyway. Images without dimensions, ads that inject themselves, banners that appear after 800 ms and shove the page down as someone is reaching for a button. Everyone has tapped the wrong thing because of this, and everyone remembers how it felt.
8. No CDN when your audience is global
If your server is in London and a third of your traffic is Australian, those visitors are paying a round-trip penalty on every single asset. A CDN puts copies of your images, CSS and JS on servers near them. Cloudflare's free tier handles this for most small sites in an afternoon.
9. A theme trying to be everything
Multipurpose themes ship with sliders, portfolio filters, parallax effects, four icon libraries and eleven demo layouts — and load a large slice of that machinery on every page. This is the hardest cause to fix because the answer is often "change themes", which is a project, not a tweak. But it is worth knowing when your ceiling is the theme itself.
What each one actually costs in seconds
Rough medians from audits we have run on small business and e-commerce sites. Your numbers will vary, but the ranking rarely does.
| Cause | Typical time added | Effort to fix | Needs a developer? |
|---|---|---|---|
| Oversized images | 1.2–3.5s | Low | No |
| Unused plugins / apps | 0.6–1.8s | Low | No |
| Render-blocking assets | 0.5–1.4s | Medium | Usually |
| Slow TTFB / no caching | 0.4–1.2s | Low–Medium | Sometimes |
| Third-party scripts | 0.3–2.0s | Low | No |
| Font loading | 0.2–0.8s | Low | Sometimes |
| Layout shift | 0s (hurts CLS & trust) | Medium | Usually |
| No CDN (global traffic) | 0.3–1.1s | Low | No |
| Heavy multipurpose theme | 1.0–2.5s | High | Yes |
See your own numbers in 30 seconds
The free Softshelf audit runs your URL through Google's own PageSpeed data and returns your performance, SEO and accessibility scores plus the specific elements slowing the page down. No signup, no sales call.
The fix order that gets results fastest
Do not start with the interesting problem. Start with the one that returns the most seconds per hour of work. In practice that order is almost always:
- Compress and resize every image above the fold. One afternoon, biggest single win, zero risk.
- Delete plugins and apps you cannot justify. Take a backup first, remove them one at a time, test checkout after each.
- Turn on caching and a CDN. Usually a settings toggle plus a DNS change.
- Cut third-party scripts to the ones somebody reads.
- Add
deferto scripts anddisplay=swapto fonts. - Fix layout shift by setting dimensions on images and reserving space for anything injected late.
- Re-measure. Then decide whether the theme is your remaining ceiling.
Steps 1–5 are where roughly 80% of the improvement lives, and none of them require touching your theme's source code.
How fast is fast enough?
"Get a 100" is the wrong target — it is expensive, fragile, and past a point invisible to customers. These are the thresholds that actually matter:
| Metric | Good | Needs work | Poor |
|---|---|---|---|
| Largest Contentful Paint | ≤ 2.5s | 2.5–4.0s | > 4.0s |
| Interaction to Next Paint | ≤ 200ms | 200–500ms | > 500ms |
| Cumulative Layout Shift | ≤ 0.1 | 0.1–0.25 | > 0.25 |
| Time to First Byte | ≤ 800ms | 0.8–1.8s | > 1.8s |
Hit "good" on all four on mobile and you are ahead of most of your competitors. Chasing a perfect lab score after that is a hobby, not a business decision.
When to stop DIY-ing and hire someone
Do it yourself if the wins are in images, plugins, caching and scripts — that is a weekend, and you will learn your own site. Bring someone in when:
- You have done the easy list and mobile LCP is still above 4 seconds.
- The bottleneck is inside a theme or a custom build you did not write.
- You are paying for traffic. Every day at a 4% conversion rate instead of 6% has a number attached, and it is usually larger than the fix.
- Something broke last time you tried, and now you are (reasonably) afraid to touch it.
Whoever you hire, insist on a before/after report with the same tool and the same URL. "It feels faster" is not a deliverable.
Want this done for you this week?
Softshelf fixes performance and conversion problems on a flat fee — you approve a fixed number before anything starts, and you get a before/after report when it ships. Most speed sprints are delivered in 3–5 working days.
Frequently asked questions
Does website speed really affect Google rankings?
Yes, but as a tiebreaker rather than a primary factor. Core Web Vitals are a confirmed ranking signal; when two pages are comparable in relevance and authority, the faster one wins. The larger effect is on conversion: slow pages lose visitors before content ever gets a chance to rank or sell.
How long does it take to fix a slow website?
The image, plugin, caching and script work is typically one to two days. Deeper work inside a theme or custom codebase runs three to five days. Rebuilding on a lighter foundation is a two to four week project.
Will speeding up my site break anything?
It can if changes are made without a staging copy or backups. The safe order is: back up, change one thing, test the critical paths (checkout, contact form, search), then move on. Most damage we are called in to repair comes from an aggressive optimisation plugin turned on all at once.
Is a perfect 100 PageSpeed score worth chasing?
Usually not. The gap between 60 and 90 is worth real money in bounce rate and conversions. The gap between 90 and 100 is mostly invisible to customers and often requires removing tools your business actually uses.