The usual culprits
In order of how often we actually find them on client sites: unoptimized images — photos exported straight from a phone or stock library at 4-8MB, displayed in a 400px-wide card; bloated page builders and plugin stacking, especially WordPress sites running 25-40 plugins where five would do the job; no caching layer at all, so every visitor triggers a fresh database query and full page render; cheap shared hosting with oversold server resources that slow to a crawl under any real traffic; render-blocking JavaScript and CSS that stops the browser from painting anything until third-party scripts finish loading; and too many web fonts, often three or four font families loaded when one with two weights would cover the whole design.
If you're seeing several of these together, it's worth reading our broader guide on website redesign — sometimes speed is the presenting symptom of a site that's outgrown its platform in several ways at once, not just a performance problem in isolation.
How to diagnose it properly
Run the site through Google PageSpeed Insights (or Chrome DevTools' Lighthouse panel) and look at three Core Web Vitals specifically: Largest Contentful Paint (LCP) — how long until the main content is visible, ideally under 2.5 seconds; Cumulative Layout Shift (CLS) — how much elements jump around as the page loads, ideally under 0.1; and Interaction to Next Paint (INP) — how responsive the page feels when someone actually clicks something, ideally under 200 milliseconds. PageSpeed Insights also lists specific opportunities ranked by estimated savings in milliseconds — that ranking is usually a reliable guide to where your time is actually going, not just a generic checklist.
We've taken sites from a PageSpeed mobile score in the 30s to the 80s purely by compressing and resizing images and adding a caching plugin — no code changes, no hosting migration, two afternoons of work. Always check the cheap fixes before assuming you need a rebuild.
The fix priority order
Fix in this order, because each step tends to produce diminishing returns if done out of sequence: images first. Compress and resize every image to the actual dimensions it displays at, convert to WebP or AVIF, and lazy-load anything below the fold. This alone typically accounts for more than 50% of the total speed improvement on a small business site. Then hosting and caching. Move off oversold shared hosting if that's what you're on, and add a proper caching layer — a caching plugin on WordPress, or a CDN in front of the site — so repeat visitors and unchanged pages don't hit the server fresh every time. Then code bloat. Audit plugins and remove anything unused, defer non-critical JavaScript so it loads after the visible content, and consolidate to one or two font families max.
Realistic expectations
Here's the part most speed-optimization advice skips: you cannot out-optimize a fundamentally bloated platform. A site built on a heavy page builder with a dozen third-party app embeds has an architectural speed ceiling that image compression and caching plugins will get you closer to but never past. We've had clients spend real money on "speed optimization" packages from other agencies that shaved 15% off load time on a site that needed a 70% improvement to hit competitive Core Web Vitals — because nobody told them the platform itself was the constraint. If you've gone through the priority order above and you're still looking at a mobile score under 60, that's usually the signal that patching has hit its limit and a rebuild, on a lighter platform or a hand-coded template, will get you further for less ongoing effort than continued optimization work.
This is a case where the more expensive-sounding option is often the cheaper one over time. A client who spent eighteen months and several thousand dollars across three separate "optimization" engagements with different freelancers eventually rebuilt on a lighter template and hit their target Core Web Vitals scores in three weeks — the cumulative patching cost had already exceeded what the rebuild ended up costing outright, without ever solving the underlying problem.
Measuring the win afterward
Don't just glance at a single PageSpeed score and call it done — the tool's live score can vary run to run depending on network conditions and server load at that exact moment. Run it three to five times and look at the trend, and cross-check against the Chrome User Experience Report (CrUX) data in Search Console's Core Web Vitals report, which reflects real visitor experience over a rolling 28-day window rather than a single lab test. A lab score that looks great but a field score (real users) that stays poor usually means the improvement didn't reach the conditions most of your actual visitors browse under — slower phones, weaker connections, more crowded networks than a lab test simulates.
Once the technical work is done, keep an eye on whether it actually moved business outcomes: bounce rate on your key pages, and conversion rate on your contact or booking flow. Speed for its own sake doesn't pay the bills — speed that keeps visitors on the page long enough to convert does, and that's the number worth tracking three to four weeks after the fixes go live.
One more thing worth flagging: mobile and desktop scores can diverge sharply, and mobile is the one that matters most for most service businesses given where their traffic actually comes from. It's common to see a desktop PageSpeed score in the 90s on the same page that scores 45 on mobile, because desktop testing runs on a fast simulated connection with no throttling while the mobile test simulates a mid-range phone on a slower network — closer to what a large share of real visitors actually experience. Always optimize against the mobile number, not the desktop one, even if the desktop score looks reassuring.