When we rebuilt GameZiko, a free browser games portal with 56,000+ playable HTML5 titles, the first thing we killed was the CMS. This is the story of why, and what replaced it.
A database-backed CMS sounds fine until you do the math. Fifty-six thousand game pages, each with a title, description, tags, thumbnail, iframe embed and related-games block. On WordPress, every one of those pages is a database row, and every page view is a query. At our traffic levels the database became the bottleneck: slow queries, cache stampedes when a game went viral on social media, and a plugin stack that needed constant babysitting.
We replaced the whole thing with a build pipeline. Game metadata lives in flat files, validated by a small schema. A generator renders each page to static HTML once, at build time. The site is served from a CDN edge, so a page view never touches a database. Time to first byte dropped from ~600ms on the old stack to under 100ms on the new one, and the traffic spikes that used to page us now barely register.
Thumbnails were the second problem. Fifty-six thousand images, each needing several sizes for cards, listings and social previews. We stopped pre-rendering all of them. Instead, a thumbnail service generates sizes on demand and caches the result at the edge. The first request pays the cost; everyone after gets the cached version. Storage dropped by an order of magnitude.
Search is the third piece. Nobody browses 56,000 games by pagination. We built a lightweight client-side search index, shipped as a compact JSON bundle, with game titles, tags and categories. It loads lazily and searches instantly without a server round trip. Players find what they want in a keystroke or two, which matters when your whole pitch is no downloads, no sign-ups, play instantly.
There are tradeoffs, and I will not pretend otherwise. Publishing a new batch of games means running the build, which takes minutes, not seconds. Editorial workflows are git-based, which is great for developers and opaque for non-technical contributors. And if the build breaks, nothing new goes live until it is fixed. We accepted all of that for a simple reason: our pages are read-heavy and write-light. A CMS optimizes for the opposite.
The lesson generalizes. If your content changes rarely but gets read constantly, a database per request is paying for flexibility you do not use. Static generation plus edge caching is boring technology, and boring technology is exactly what you want when the alternative is a 3 a.m. database incident.
We are a one-person operation, so every hour of maintenance is an hour not spent improving the product. The static pipeline needs almost no maintenance. The old CMS needed weekly attention. That alone justified the migration.
If you run a content-heavy site and your CMS is the thing you think about most, it might be time to ask what it is actually buying you.
Top comments (0)