Street 05 › Devlog › Keeping a site with 116 games under 90 KB
Keeping a site with 116 games under 90 KB
street05.uk has 116 browser games, a 3D racing game built on three.js, a learning platform and a studio site. The first page anyone sees still downloads about 81 KB of code and styles (compressed). Here's how we keep it there.
A budget the build enforces
The first load is everything a visitor's browser must download before the home page works: the main script, the shared libraries and the main stylesheet. We gave it a hard limit of 90 KB, compressed, and wrote a small script that runs on every build. If the first load goes over, the build fails and nothing ships.
A number that breaks the build changes how you work. A new feature isn't "done" until it fits.
Everything else waits until it's needed
Each of the 109 short games is its own file, downloaded only when someone opens it. The arcade also guesses: when a finger, mouse pointer or keyboard focus reaches a game's card, that game starts downloading, so it's usually ready by the time the tap lands.
The 3D engine is the extreme case. three.js alone is about 131 KB compressed, more than the whole first load, and only the 3D games need it, so it downloads when one of them opens and never on the home page.
The stylesheet was the hidden cost
In October the first load had crept up to 89.8 KB. Almost all the slack was in one place: the main stylesheet carried the styles for every page, including the arcade, the Skill Lab and seven full games, which most visitors to the home page never open.
We moved those into their own stylesheets, loaded with the components that use them. The first load dropped to 79.2 KB, and the main stylesheet from 14.8 KB to 4.2 KB. To be sure nothing lost its styling, we took screenshots of 11 pages at phone and desktop width before and after and compared them pixel by pixel.
A layout jump we'd never noticed
While building a "welcome back" view for returning players, we measured layout shift: how much the page jumps while it loads. Google counts under 0.1 as good. Our home page on desktop scored 0.22.
The cause was the web font. The page first paints in a fallback font; a moment later Plus Jakarta Sans arrives with different letter widths, and the whole hero reflows. The fix is a fallback that takes the same space: local Arial, stretched to the real font's measured widths and line heights, with separate settings for regular and bold weights. With the font delayed by 600 ms in testing, the home page now shifts 0.000.
What we'd tell another team
- Put the number in the build, not in a document.
- Measure what's actually in the first load; ours was mostly styles, not scripts.
- Check layout shift with a slow font, not on a fast machine where the font is cached.