Skip to main content

Faster on a phone

5 minute read

A chart of the time the largest element of the home page takes to appear on a phone, before and after: marcomastroddi.com from 3.8 to 1.4 seconds, beebeep.net from 3.3 to 2.1, lauragalliarchitetto.com from 3.1 to 1.9; all three now below the 2.5 seconds Google calls good

On my computer the page appeared before I had finished clicking. Less than a second, every time. So when the audit of lauragalliarchitetto.com arrived, on the very day the site went online, I read the line about phones twice. More than three seconds before you could see anything.

Three seconds is a long time. Long enough for someone to think the link is broken, put the phone back in their pocket and forget about you. And that site is built with WebMastro, like this one and like beebeep.net. If it was slow, all three were. The problem was not hers. It was mine.

The usual suspects

I started where everyone starts: with the server. Shared hosting, the obvious culprit. It was innocent: it answered in a tenth of a second, a quarter at most.

Then JavaScript, the usual defendant of slow pages. I made the processor four times slower and the page did not care. Innocent too.

The photos? They were already sent in lighter copies, cut to the size of the screen. Nothing there either.

So I did what I should have done first: I stopped looking at the page from my desk and looked at it the way a phone sees it. Google's PageSpeed Insights does exactly that: an ordinary Moto G, on a slow 4G connection, timing two moments. When you first see something, and when the largest thing on the screen, a photo, a paragraph, is finally drawn. And there, frame by frame, the page was simply waiting.

The fast road that was not

A page cannot be drawn until its stylesheets arrive, and the slowest of them was always the same: Bootstrap's.

It came from jsDelivr, a public CDN, exactly as everyone recommends. A fast network, close to you, built for this. And it is fast. But it is another server, and before asking it for a single byte the phone has to find it, knock on its door and agree on a secret language for the encryption. Three trips there and back. From my desk, a trip costs a few thousandths of a second and you never notice. On a phone with two bars of signal it can cost hundreds.

The other promise of the CDN had quietly expired years ago: since 2020 every browser keeps a separate cache for each site, so nobody ever arrived with Bootstrap already in their pocket.

The answer was almost embarrassing in its simplicity. The site now serves Bootstrap itself, on the connection it has already opened for the page. The very same files, byte for byte, and a test that checks it against the fingerprints the Bootstrap team publishes.

A whole alphabet for three letters

The second discovery made me smile. The icons on those pages, the WhatsApp logo, an arrow, an envelope, came from a font. A font is a whole alphabet: 131 KB of drawings, plus its stylesheet, from the same distant server. To show three of them.

Now each icon is drawn right inside the page, a few hundred bytes of SVG, with no request at all. It takes the color and the size of the words around it, as the font did. And if I ever misspell the name of one, the framework tells me at once, where the font used to show an empty square and say nothing.

The day this went online, beebeep.net stopped asking anything of any other server. Every byte now comes from home.

The guest nobody had invited yet

On the home page of this site there is a video. Until now the YouTube player arrived with the page, uninvited: half a megabyte of JavaScript and a call to Google, for everyone who passed by, even though almost nobody presses play. And it kept the processor busy at the very moment the page was trying to appear.

Now the page shows a picture of the video with a play button. The player arrives only when you call it. The page is lighter, and it is also more polite: until you decide to watch, your browser does not speak to Google at all.

The page that would not keep still

By then the pages were fast. But PageSpeed had one more thing to say, and it was not about speed: the page moved. Google calls it CLS, and here it was 0.24, more than twice what is considered acceptable.

I watched it happen, slowed down. The text appeared, then the fonts arrived a moment too late and everything was redrawn with slightly different measures. The cookie banner shrank by 21 pixels, the paragraphs slid up a little. A small earthquake, right as you start to read.

The cure was to ask for the fonts together with the stylesheets, so they are there for the very first paint. Then I found a second tremor, an invisible one: the round buttons in the corner, still hidden, jumped up when the cookie banner appeared, and the browser counted that too. Now they move in a way that leaves the page untouched.

One second

I measured again, on the same phones, on the same slow connection.

This site, which used to show its first words after 3.6 seconds, now shows them after 1.1, and its largest element after 1.4 instead of 3.8: PageSpeed gives it 100. beebeep.net went from 3.3 to 2.1 seconds. And lauragalliarchitetto.com, where the story began, from 3.1 to 1.9, with a score that rose from 90 to 99.

What stays with me is not the numbers. It is that on my computer everything looked perfect, and I could have stopped there. The slowness was not in the heaviest file, but in the extra trips: a second server, a font found too late, a guest loaded for nobody. None of them was a mistake when I wrote it. Each one was a habit, a piece of good advice that had grown old without telling anyone.

Now, when you open one of these sites on your phone, the page is there before you have time to wonder whether it will come. That was the whole point.