Nearly every "our site is slow" conversation starts with the same suspects: hosting, the CMS, too many plugins. Occasionally that's it. Usually it isn't — and the fix costs a lot less than the migration someone has already been quoted for.
Here's what actually goes wrong, roughly in the order we find it.
Measure the right thing first
Before touching anything, separate two numbers that get conflated constantly.
Lab data is what a tool like Lighthouse reports when it loads your site on a simulated device. It's repeatable, which makes it good for comparing before and after — and it's a simulation, which makes it bad evidence about real users.
Field data is what actually happened to real visitors on their real phones on their real networks. Google publishes it for most sites in the Chrome UX Report, and it's the data that affects your search ranking.
Sites that score 95 in Lighthouse and fail in the field are common. It usually means the lab test ran on a fast connection against a warm cache, and your actual audience is on mid-range Android over patchy mobile data. Fix what the field data says.
The four things that are almost always the cause
Images
Still the number one cause, still the easiest fix. The pattern is a hero image exported at 4000px wide, served at full size to a 390px phone, in a format from 1996.
- Serve modern formats. AVIF or WebP will cut 40–70% off a JPEG at the same visual quality.
- Serve the size the device asks for, via
srcset— not one file for every screen. - Set explicit
widthandheightso the browser reserves the space. This is free and it removes most layout shift. - Lazy-load anything below the fold, and don't lazy-load your hero — that delays the one image the score is measured against.
Fonts
A custom font that blocks rendering is a blank screen with a good typeface.
Self-host rather than pulling from a third-party origin, preload the one or two weights that appear above the fold, and set font-display: swap so text renders immediately in a fallback. Then pick a fallback with similar metrics, so the swap doesn't shove the whole page around when the real font lands.
Third-party scripts
This is where slow sites go to become very slow sites. Analytics, chat widget, heatmap tool, two tag managers, a consent banner, a review widget, an ad pixel from a campaign that ended last year. Each is small. Together they're the majority of your main-thread time, and they run before your page can respond to a tap.
Open the network tab and list every third-party request. For each one, ask who looks at the data it produces. In our experience about a third of them have no owner at all. Delete those. Load the survivors after the page is interactive.
Doing work on the client that belongs on the server
A page that ships an empty shell and then fetches its content in the browser has made every visitor wait for two round trips instead of one. If the content is the same for everyone, render it on the server and cache it. If it changes hourly, cache it for an hour. Interactivity is what needs to run in the browser — content isn't.
The one nobody looks at
Time to First Byte. If your server takes 800ms to start responding, nothing you do to the front end can save you — every other metric starts late.
Common causes, in the order we check them: an uncached database query on a hot path, an N+1 query pattern behind a listing page, a synchronous call to a third-party API during page render, and rendering a page on every request that could have been rendered once. Almost always one of those four, and almost always fixable in a day.
What "fast" is worth
The business case is unglamorous and consistent: faster pages convert better, mobile visitors abandon slow sites at a rate that gets steep past about three seconds, and Core Web Vitals are a ranking input, so the same work pays twice.
But the honest framing is smaller than that. Most sites don't need a rebuild. They need someone to spend two days on the images, delete four scripts, cache one query, and preload one font. That's the whole intervention, and it's the one we recommend before anyone talks about changing platforms.
