Most of our players aren't on gaming rigs. They're on school Chromebooks, five-year-old Android phones, and library computers. When you run a free browser-games portal with 56,000+ HTML5 games (Gameziko), performance isn't a nice-to-have — it's the product. Here's what actually moved the needle for us.
1. Never load the game before the click
The biggest win was also the simplest: the game iframe doesn't exist until the player presses play. The game page loads a lightweight thumbnail, title, and description first — usually under 100KB. Only on the play click do we inject the iframe. This cut our median page weight by ~80% and made game pages feel instant even on 3G.
2. Thumbnails are the hidden budget killer
56,000 games means 56,000 thumbnails. We serve them as WebP with JPEG fallbacks, lazy-load everything below the fold with loading="lazy", and cap thumbnail dimensions at the largest size we ever render (no 1200px images squeezed into 200px cards). Total image bytes per listing page dropped by two-thirds.
3. One shared game shell, not 56,000 snowflakes
Every game page uses the same shell: same header, same player chrome, same ad slots. That means the shell's CSS and JS are cached after the first pageview, and subsequent game pages are mostly just JSON. Consistency also means one place to fix bugs instead of thousands.
4. Kill third-party scripts ruthlessly
We audited every third-party script on game pages and cut the list to the bone. Each script gets a simple test: does it earn its kilobytes in revenue or functionality? Anything that failed is gone. Ad scripts are the worst offenders — we load them async and never let them block the game iframe.
5. Measure on the worst device you can find
Our performance budget is tested on a 2019 Chromebook, not a MacBook Pro. If a game page hits interactive in under 3 seconds there, it ships. Real-user metrics confirmed what lab tests suggested: bounce rate on game pages tracks almost linearly with time-to-play-button.
The boring truth
There's no magic here — no service worker wizardry, no edge computing. It's lazy loading, small images, cached shells, and fewer scripts. The unglamorous fundamentals, applied 56,000 times over.
If you're building anything that serves a lot of lightweight pages to a lot of underpowered devices, start with the click-to-load pattern. It's the highest-leverage change we made, and it took an afternoon.
I run Gameziko, a free portal with 56,000+ HTML5 games that need no download or signup. Happy to answer questions about running game portals at scale.
Top comments (0)