# Why your site feels slow on a mid-range phone — and what to fix first

> A site that flies on a laptop can crawl on the phone most of your visitors carry. Where the time goes, how to measure it, and the order to fix things in.

By Odd Birds Studio · 27 Oct 2026 · Performance · 3 min read

Most websites are built and reviewed on fast laptops with fast connections. Most visitors arrive on a phone, often an affordable one, often on mobile data. The gap between those two experiences is where slow websites hide.

## Where the time actually goes

When someone opens a page, a lot happens before they see anything useful: the connection is set up, the HTML arrives, then the stylesheets, fonts, scripts and images it asks for. On a mid-range phone the processor also has to parse and run every script, and that step is often slower than the download itself.

That is why page size is only part of the story. Two pages of the same weight can feel completely different, depending on how much work the phone has to do before the page responds.

## Measure what visitors feel

Google’s Core Web Vitals are a practical starting point because they describe what a person feels, not what a server does. These are the thresholds Google treats as “good”, measured at the 75th percentile of real visits:

- **≤ 2.5 s** Largest Contentful Paint: How long until the main content is visible.
- **≤ 200 ms** Interaction to Next Paint: How quickly the page responds to a tap.
- **≤ 0.1** Cumulative Layout Shift: How much the layout jumps while loading.

PageSpeed Insights shows these for your own site. Look at the mobile tab first, and at the field data from real visitors when it is available — lab scores are a hint, not the verdict.

## The order to fix things in

### 1. Images

Images are usually the heaviest thing on a page. Resize them to the size they are actually shown, serve WebP or AVIF, give them fixed dimensions so the layout does not jump, and lazy-load anything below the first screen.

### 2. Third-party scripts

Chat widgets, trackers, embedded feeds and heatmaps each add code the phone has to download and run. List every one, ask who still uses it, and remove the rest. Load the survivors after the page is usable.

### 3. Fonts

Every family and weight is another download. Two families with a few weights is plenty for most brands. Self-host them and let text show immediately in a fallback while they load.

### 4. JavaScript

On a mid-range phone, running JavaScript often costs more than downloading it. Ship less of it, split it by page, and keep heavy features — maps, 3D, carousels — from loading until they are needed.

### 5. Caching and hosting

Serve static files from a CDN close to your visitors and let browsers cache them for a long time. A returning visitor should never download the same logo, font or script twice.

## What not to do

- Do not judge speed by your own repeat visits — your browser has already cached everything.
- Do not chase a perfect lab score at the expense of what real visitors experience.
- Do not hide a slow page behind a loading spinner; make the page itself faster.

> Test on the phone your customers carry, not the one your designer carries.

## Keeping it fast

Speed decays quietly: a new tracking tag here, an uncompressed banner there. Agree a simple budget — a maximum page weight, a target LCP — and check it whenever something new is added. It is much easier to keep a site fast than to rescue a slow one.

> **A ten-minute test**
>
> Open your site in Chrome, press F12, open the Network tab, set throttling to a slow mobile connection, and reload with the cache disabled. Watch how long the page stays blank. That is what many of your visitors see.