Skip to content

Web & Digital Experience

Web performance: a budget, measured on your customers' phones

Most sites are fast on the office wifi and slow on a mid-range phone in a basement, which is where a customer with no heat is standing. Speed isn't fixed once at launch; it's lost a widget and a photo at a time. We set a budget for each page, measure it on the phones customers actually use and check it before every release.
Discuss your site's speedSee what makes pages slow ↓
booking page · mid-range phone · slow 4G0 s1 s2 s3 s4 s5 s6 sbudget · content visible by 2.5 scontent visible · 5.1 s · over budgetcontent visible · 2.1 s · within budgetpagehero photoresized for phones · 180 KBweb fonts2 files instead of 4chat widgetloads when tappedbooking form

What makes pages slow

Five causes cover most slow pages we see. The first two are usually most of it.

  1. 01

    Images

    Sized for the screen they're shown on

    A 2.4 MB photo sent to a phone that shows it 390 pixels wide is the most common slow page.

  2. 02

    Other companies' scripts

    Chat, tracking and review widgets

    Each one is someone else's code on your page. Load it when it's needed, or not at all.

  3. 03

    Fonts

    Fewer files, text shown at once

    Two files instead of four, with text visible while they load.

  4. 04

    Layout shift

    Nothing jumps

    Space is kept for images and banners, so a visitor doesn't tap the wrong button.

  5. 05

    Server response

    The wait before anything arrives

    Pages built ahead of time or served from near the visitor, so the server isn't the wait.

A budget for every page

Budgets are choices, written down, so a slower page is a decision someone has to make.
Booking pagecontent visible by 2.5 s; nothing jumpsa mid-range phone on slow 4G
Service pagescontent visible by 2.5 sthe same phone
Customer portaleach screen usable within 1 s of a tapa mid-range phone on 4G
Every pageno image over 200 KB at phone widthevery release

A slow change, caught before release

The budget check runs on every change, the same way tests do.

Change · new hero photo on the booking page

  1. Change proposed

    a new spring photo

    done

  2. Built and measured

    on the test phone profile

    done

  3. Budget check

    content visible at 3.4 s; budget 2.5 s

    failed

  4. Photo resized

    the same photo, sized for phones

    done

  5. Measured again

    within budget

    done

  6. Released

    done

The slow version never reached a customer.

Fast for whom

Fast on the office wifi

  1. 01Tested on a new laptop on the office connection
  2. 02One score, checked once, at launch
  3. 03New widgets added without a check
  4. 04Slow pages found when a customer complains

The site is fast for the people who built it.

Fast on your customers' phones

  1. 01Measured on a mid-range phone on a slow connection
  2. 02A budget per page, checked on every release
  3. 03Every new script measured before it ships
  4. 04Real visitors' load times watched over time

The site stays fast for the people who use it.

What performance work hands off

In

Pages
and everything they load
Budgets
per page
Real visits
load times from the field
Performance
measure, budget, fix

Out

Releases
checked against the budget
Fixes
images, scripts, fonts
Reports
load times over time

Worth doing when most visitors arrive on phones

Good fit

  • Most visitors use phones, often on mobile data.
  • The site has collected widgets, scripts and big photos.
  • Nobody checks speed when something changes.

Not the right fit

  • A simple site that's already fast on a mid-range phone.
  • Speed isn't the problem; visitors can't find what they need. That's information architecture.

Where this capability is used

Next to web performance

Questions about web performance

What's a good load time?

It depends on the page and the visitor's phone. We set a budget per page, measured on a mid-range phone on a slow connection, and keep to it.

Do speed-test scores matter?

They're a useful check. How fast real visitors' pages load matters more, and that's measured too.

Will removing the chat widget lose us leads?

It doesn't have to go. It loads when someone taps it, so it's still there for people who want it.

Can you speed up our current site without rebuilding it?

Often, yes. Images, scripts and fonts are usually the biggest wins, and they can be fixed on the current site.