Open Chrome DevTools, run Lighthouse on your site, and watch the number come back red. A performance score under 50 feels like a verdict — like the whole site is broken and needs to start over. It almost never does.
A low Lighthouse score is a symptom, not a diagnosis. The same handful of problems drag down most slow sites, and they’re fixable in a predictable order. Here are the four steps we work through, in the order that gets the most points back for the least effort.
First, understand what the number means
Lighthouse runs your page on a simulated mid-range phone over a throttled connection, then scores it against a set of metrics — how fast the largest element paints, how long the page is blocked from responding, how much the layout shifts as it loads. The mobile score is usually the one that’s red, because phones are slower than the laptop you built the site on.
That’s the right thing to measure. Most of your visitors are on a phone, on cellular, in a parking lot. If the site is fast there, it’s fast everywhere. So we always fix for the mobile profile, not the desktop one.
Step 1: Fix the images first
This is the single biggest win on most sites, and it’s where we always start. A page that scores in the 30s is usually carrying a few megabytes of images that were dropped straight from a phone or a stock library at full resolution.
Three changes do almost all the work:
- Right-size them. An image displayed at 600 pixels wide does not need to be 4,000 pixels wide. Resize each one to the size it’s actually shown at.
- Serve modern formats. WebP and AVIF are a fraction of the size of the same JPEG or PNG at the same quality. Convert them.
- Load them lazily. Images below the fold shouldn’t block the top of the page from painting. Defer them until they’re needed.
It’s common to cut total page weight in half with this step alone, and to watch the largest-paint metric — the one Lighthouse weights most heavily — drop by seconds.
Step 2: Cut the JavaScript you don’t need
After images, JavaScript is the next-heaviest thing on the page, and the most expensive, because the phone has to download it, parse it, and run it before the page can respond.
Most slow sites are running scripts they don’t use: a heavy framework powering a page that’s mostly static text, a carousel library for a carousel nobody scrolls to, four separate analytics and chat widgets, a font loader pulling in eight weights when the design uses two.
We audit what’s actually running, remove what isn’t earning its place, and defer the rest so it loads after the page is usable instead of before. Less JavaScript is the fastest JavaScript. It’s the whole reason we build on a light stack — a site that ships almost no script to the browser starts the race a long way ahead.
Step 3: Serve it fast — caching and the edge
Once the page itself is lean, the question is how quickly the server hands it over. Two things matter here.
Caching means a returning visitor — and the browser itself — doesn’t re-download what hasn’t changed. Static assets get long cache lifetimes, the page gets sensible rules, and repeat visits get noticeably faster.
The edge means your site is served from a location near the visitor instead of one server far away. A content delivery network keeps copies close to people, so the first byte arrives in milliseconds instead of half a second. For a site whose visitors are spread across a state or a country, this is a real, measurable gain — and it’s mostly a configuration change, not a rebuild.
Step 4: Measure the right thing, then stop guessing
With the first three steps done, run Lighthouse again — but read the report, don’t just check the number. The score is an average of several metrics, and you want to know which one is still costing you points.
If it’s the largest paint, you have an image or a font loading too late. If it’s layout shift, something is loading without reserved space and shoving the page around. If it’s total blocking time, a script is still doing too much on the main thread. Each of those has a specific fix, and chasing the score without reading the breakdown is how teams spend a week and gain three points.
Test on a real phone too, not only the simulator. The simulator is a good proxy, but a real device on real cellular is the truth.
When a fix isn’t enough
Sometimes the foundation is the problem. A site built on a bloated theme, stacked with plugins that each load on every page, on bargain shared hosting, can be tuned only so far before the architecture itself is the ceiling. When we hit that ceiling, we say so plainly, and we rebuild on a modern stack: fast by default, served from the edge, light on the code that bogs phones down. Under a second, works on every device, no monthly rescue.
But that’s the exception. Far more often, a red score is four boring fixes away from green — and your customers feel the difference long before they ever see the number.
If your site is scoring in the red and you want a straight answer on why, send us the URL for a free audit. We’ll run it, read the report, and tell you exactly what’s slowing it down — which fixes you can do yourself, and which ones we’d handle. Built right, kept running.