Why we keep every game page under 100KB of our own code

Why we keep every game page under 100KB of our own code

A game portal with 56,000 pages has a performance problem that most sites never face. Every page must load fast, on hardware we do not control, over connections we cannot predict. Our answer is a rule that sounds almost too simple: our own code on every game page must stay under 100KB, measured before compression, and it must stay there no matter how many features anyone proposes.

The rule exists because of what our players actually use. A large share of our traffic arrives on low-end Android phones, shared family tablets, and school or library computers that are several years old. On those devices, a heavy page is not a minor annoyance. It is the difference between playing a game and closing the tab. A page that takes eight seconds to become usable has already lost the player, even if the game itself is excellent.

Keeping our code small forces a particular kind of discipline. Every script must justify itself. If a feature needs a library, we ask whether ten lines of plain JavaScript would do the same job. Very often, it would. We use no front-end framework on game pages, no icon font, and no tracking scripts beyond the bare minimum. The page is HTML, a small stylesheet, and a small script that loads the game and gets out of the way.

That simplicity also makes the pages easier to maintain. When something breaks, there is very little code to search through. When a browser changes behaviour, we can find the affected code quickly. A small codebase is a maintainable codebase, and for a one-person operation, maintainability is not a luxury. It is survival.

There is a second benefit that took longer to appreciate. Small pages are cheap to serve. Our hosting bill stays modest, our cache hit rate stays high, and traffic spikes, which happen whenever a game goes viral on social media, do not take the site down. A page that is mostly static HTML can be cached aggressively, served from the edge, and delivered thousands of times without touching our server at all.

We measure the rule continuously, not occasionally. Every build checks the size of our own code on a sample of pages, and a build that crosses the limit fails, the same way a build with a syntax error would. That sounds strict, and it is, but it is also the only way a rule like this survives contact with real feature requests. Without an automated check, every new feature would add a little weight, and a year later the pages would be twice as heavy and nobody would remember why.

The rule has costs, and it is honest to name them. Some features we would like, such as rich social sharing previews on every page, or elaborate recommendation widgets, are harder to build within the limit, and some we have simply not built. We accept that trade. A fast page with fewer features beats a slow page with more features, for our players, every time.

If you run a content site with many pages, try measuring your own code separately from third-party scripts. You may be surprised by how much of your page weight is yours, and how much performance you can win back by setting a limit and enforcing it automatically. Our players never see the 100KB rule, and they never need to. They just notice that the games load quickly, and they come back. That is the whole point.

You can see the result on GameZiko (https://gameziko.com), where every game page follows the same discipline: fast, light, and ready to play in seconds.