Dr. Teitelbaum's Site Went From 57 to 100 on Mobile. What Actually Moved It.

The Bus Can't Slow Down. The Website Couldn't Speed Up.

In Speed, the 1994 movie, Keanu Reeves is stuck on a city bus wired with a bomb that goes off if the bus drops below 50 miles an hour. He can't stop it, he can't get everyone off, and he has to fix the problem while the thing is moving.

Google's speed test for websites works the other way around. Nothing explodes. If your page is slow on a phone, people just get off the bus. And in July, Dr. Teitelbaum's homepage was reading 57.

This is part two. Part one is the case study: a Jupiter psychiatry practice that wanted a website worthy of the care it gives, not more patients. I'm not retelling that. This is what happened to the speed score afterward, and what actually moved it, which isn't quite the story I would've told you in July.

The Radar Gun and the Stopwatch

Two measurements run through this post, and here's the difference up front.

The radar gun is Google's check, run by a script on the homepage, on a simulated phone, once per run, and filed. The first two runs came a day apart in mid-July while we were setting the script up; from July 20 it has run every Monday. That's the number that went from 57 on July 14 to 100 on September 21.

The stopwatch is what we ran ourselves right after the big fix: the same test, three times, keeping the middle number. The "after" figures below are stopwatch numbers. The "before" figures are single runs, and I'll say so each time, because that difference is most of this story.

Google agrees. Its own documentation on the score says most of the variability comes from conditions underneath the tool, and that it's more useful to think of your site's performance as a distribution of scores than as a single number.

So here's the radar gun, all twelve readings in order: 57, 76, 89, 91, 99, 99, 97, 89, 100, 100, 96, 100. The last four are 100, 100, 96, 100. That 89 in late August is why you don't quote one number.

The Gauge Was Jumping Before We Touched Anything

Here's the part the first draft of this post got wrong, and it's the most useful thing in here.

The radar gun read 57 on July 14. It read 76 on July 15. A study the next morning, July 16, read 66. Nothing on the site changed between those three readings. Three single runs of the same unchanged homepage came back 57, 76 and 66, and the first draft of this post credited the jump from 57 to 76 to a repair that hadn't happened yet.

That's the radar-gun lesson in its purest form. The bus was never going the speed the gauge said. The needle was bouncing.

The first thing that actually changed came that Thursday afternoon, July 16: fonts. All 12 of the site's font files moved onto the site's own server instead of being pulled from an outside font service, and the text was set to show right away instead of waiting for the fonts to arrive. In bus terms, the bus stopped waiting for a delivery before pulling away from the curb.

So no single change gets credit for 57 to 100. Four did, and they started later than the chart makes it look.

Defusing the Bomb

Under the bus was 162 KB of code that someone else had wired in: Google Analytics. Not a villain, a vendor. But a heavy one, and on a phone every kilobyte of script is time spent unpacking instead of responding.

Google's test has a number for that: how long the page sits frozen, unable to respond to a tap, while it works through scripts. In Google's current scoring that number carries more weight than any other single part of the score. After the fix, the stopwatch said zero frozen time, three runs out of three. The before figure is shakier: a single run said 460 milliseconds, and the study that morning had it at 200. So I won't tell you how much frozen time we removed, only that it went to zero and stayed there. The bomb came out and the bus got 162 KB lighter.

We swapped the analytics for a small cookieless counter and checked that it actually recorded a visit before calling it done, because "we installed it" and "it works" are different sentences. We'd done the same on our own site a day earlier, and that's its own post.

The Destination Sign Was Covered

Later that day, second change. The headline on the homepage had been hidden until a little scroll animation finished running. On a phone that meant the biggest thing on the page waited for a script before it would show up. A bus with the destination sign covered until the driver finishes his introduction.

The animation came off the top of the page and stayed everywhere else. The stopwatch said the biggest element on the page now appeared at 3.2 seconds, against a single before-run of 4.6. All in, the stopwatch score after was 91, the middle of three runs, against a single before-run of 72, so treat that gap as roughly right rather than exact. The page's layout shift, the thing where text jumps around as stuff loads, stayed where it was, near zero.

The next day, July 17, one more fix. The homepage photo was a single file for every screen, sized for a desktop. Phones got their own smaller version, 45 KB instead of 80 KB, sized from the page's own layout rules, because shrinking the one file would have blurred it on desktop. The About page got the same fix.

The Gap in the Highway

In the movie there's a gap in an unfinished freeway, and the bus has to jump it. The gap is real. Ours wasn't.

Google's test told us to "preload the main image." We read that as a to-do. It was the title of a check the page had already passed. We'd read the name of the test as the result. We caught it before anyone built anything, and it's in the record as withdrawn.

Second one. Right after the fix, one number, the time to first paint, looked worse. The "before" figure was a single run, and nothing we'd changed could have slowed it. We flagged it instead of burying it, which is why I trust the rest of these numbers.

The Bus Kept Speeding Up After We Got Off

From late July the radar gun read 91, then 99, 99 and 97, dipped to 89 on August 24, and hit 100 on August 31. We didn't change anything in that stretch that explains it, and I'm not going to invent a reason. Google's own documentation says a perfect 100 is extremely challenging and not expected, and that the last point, from 99 to 100, takes about as much improvement as going from 90 to 94. So I'll take the 100, and I'm not billing for it.

I'm not going to tell you this brought in more patients, calls or rankings, because there's no record that says so, and the case study's whole point is that he wasn't chasing patients. The people who already found him get a page that answers when they tap it, and that's the whole point.

Pop Quiz

The ten-minute version for your own homepage:

Open Google's free speed test, PageSpeed Insights, put in your homepage, and pick the mobile tab. Run it three times. Take the middle number. Run it again next week, and the week after, and now you've got a radar gun.

On his site, the four things that moved the number were fonts loaded from somewhere else, someone else's script wired in underneath, a headline hidden behind an animation, and a photo sized for a billboard. Look for those first, and find out who owns each one when it breaks. None of them needed a rebuild to fix.

And when the score jumps, before you take credit, check whether anything actually changed.

We've written before about a backup check that passed on a different definition than the one that mattered. This is the same lesson with a speedometer.

What's wired under your website that somebody else installed, and do you know what it weighs?