Mobile speed: images, fonts and scripts

When a small business website is slow on a phone, it's almost always the same three culprits: a big image at the top, fonts loaded in too many variants, and scripts that hold up the page until they're done. Fix them in that order and most of the time you won't need anything else.

What Google measures, and why phones matter

Google tracks three speed and stability signals called Core Web Vitals. Two of them have clear targets: LCP (how long until the largest element on the first screen shows up, usually the hero image) should be under 2.5 seconds, and CLS (how much the page jumps around while loading) under 0.1. The third, FID, measures the response to the first tap. In May, Google announced that in March 2024 it will be replaced by INP, which looks at every interaction on the page, with "good" set at 200 milliseconds.

The numbers are read at the 75th percentile, separately for mobile and desktop. In practice, the site has to work well for three out of four visitors, on their phones and their connections. Your laptop on the office WiFi doesn't count.

Images: the top one decides

The big image on the first screen is usually the LCP element. A few rules:

• Don't lazy-load it. loading="lazy" delays images until they're close to the screen. Great for the gallery further down, but on the hero image it only slows things down. The web.dev guide is blunt: never lazy-load your LCP image.
• Tell the browser it matters. fetchpriority="high" on the hero image moves it to the front of the queue. Use it on one or two images, not all of them.
• Modern format, compressed. WebP or AVIF, compressed, at the size it's actually displayed. A 4,000-pixel-wide photo on a phone screen is wasted work.
• Several sizes. With srcset, phones get the small version and big monitors get the big one.
• Width and height in the code. With width and height on every image, the browser knows how much space to reserve, and the text doesn't jump when the image arrives. That keeps CLS low.

Fonts: fewer and lighter

Every weight and style of a font is a separate file. A site loading four families in five weights each pulls dozens of files before it shows a line of text.

What we do on small business sites:

1. Two families at most. One for headings, one for body text. Sometimes one is enough.
2. Only the weights you use. If the text is regular and bold, don't load light, medium and black.
3. WOFF2. Best compression, and it works in today's browsers.
4. Subset. Keep only the characters you need, including any accented letters your language uses. Check the font license first; not all of them allow it.
5. font-display. With swap, text shows right away in a system font and switches when yours arrives. With optional, the browser waits about 100 ms at most and, if the font is late, sticks with the system one, so nothing jumps.

Preloading fonts helps only for the main one; preload them all and they compete with the hero image.

Scripts: nothing synchronous in the head

A plain script in <head> stops the page from rendering until it downloads and runs. Google's guide says synchronous scripts there are almost never necessary. What to do:

• add defer to your own scripts so they run after the page is parsed;
• add async to independent ones, like analytics;
• remove what you no longer use: an old slider, an abandoned chat widget, two tracking codes for the same thing.

Heavy scripts also slow down the response to taps, which is exactly what INP will measure from March. A menu button that reacts after a second feels broken, even if the page loaded fast.

CSS: small and to the point

Stylesheets block rendering too. If yours is bigger than the hero image, it delays it. Strip unused rules (off-the-shelf themes ship with a lot of extra) and defer whatever isn't needed for the first screen.

How to check

Open PageSpeed Insights, enter the address and look at the mobile tab first. The top shows real visitor data (if the site gets enough traffic), the bottom a lab test with suggestions. Fix one thing at a time and measure again so you know what helped. We explained each signal in more detail in our article on Core Web Vitals.

If you want a site built with this kind of speed in mind from day one, see our web design services.