Article · Engineering
How we took our landing page from 4.2 MB to 1.9 MB
We more than halved what our landing page downloads on first load. What we held back, what we compressed, and how we showed the picture didn't change.
In this post
In short
- The landing page used to download 4197 K on first load. It now downloads 1948 K.
- Most of the gain came from leaving unseen data until it's needed. Compression did the rest.
- We compared the old and new pages pixel by pixel. The difference we measured was the comparison's own noise.
What we measured
Our landing page is a three-dimensional scene that moves as you scroll. Its points and objects live in separate data files. In the first measurement, before a single scroll, the whole page sent 42 requests and downloaded 4197 K. Of that, 3062 K was data files.
Most of that data was for sections the visitor hadn't reached. So the problem was timing as much as size.
We staged the data
On first load we now keep only the opening's six data files. Each gallery tile's point data arrives as the scroll gets close to that tile.
That could have had a cost: someone scrolling fast might see an empty scene. So we tried the hard cases one by one: slow scrolling, fast scrolling, jumping to the middle with the scrollbar, arriving by a link to one section, and reloading halfway down. All ten runs finished with no console errors and no empty scene.
We compressed the files ourselves
Some hosts, including Vercel, only compress the file types on their list. Our binary data files aren't on it, so they would have gone out as they were.
So every build writes a compressed .gz copy beside each .bin file. The browser downloads that copy and unpacks it itself. Older browsers that can't do this fall back to the plain file. In today's build, 23 files go from 5300 K to 3859 K, a 27 percent saving.
What we didn't do
We could have saved about 300 K more by storing the data at lower precision. But that risked visible stepping on the scene's ridge lines. 300 K wasn't worth risking the picture, so we stopped there.
How we showed the picture didn't change
A speed gain doesn't count if it damages the picture. So we compared seven frames from the opening and the gallery between the old and new versions. Three had no difference at all. The other four differed by at most 97 colour channels, under a tenth of a percent, and that difference was comparison noise already present in the earlier version.
The result
| Measure | Before | After |
|---|---|---|
| Whole page, data transferred | 4197 K | 1948 K |
| Whole page, requests | 42 | 26 |
| Data files, data transferred | 3062 K | 1163 K |
| Data files, count | 14 | 6 |
| Longest frame while scrolling | 166.6 ms | 41.6 ms |
| Scene reveal on a slow connection | 13.4 s | 11.0 s |
Data transferred was measured for a host that compresses text but not .bin files.
It's still the same page. The only difference is that visitors no longer wait for what they can't see yet.