Web games compete with a back button. The tolerance for a slow load is roughly one second on desktop and maybe two on a phone — and that budget includes the network, the parse, the first paint and the first frame of input.
Everything below is a consequence of taking that budget seriously.
Three loads, not one
A game portal has three distinct loading problems, and treating them as one is the classic mistake.
- The shell. Framework, styles, fonts. Paid once, cached forever after.
- The metadata. Titles, thumbnails, categories — everything needed to render a list of a hundred games.
- The game itself. Code, and whatever assets it needs.
Mixing these means a player browsing the library pays for game code they will never run, and a player who wants one specific game pays for the whole library.
The split that works: shell and metadata load everywhere; game code loads only when a game is opened. One extra round trip on the play page, and a library page that stays small.
The thumbnail trap
Thumbnails are the single heaviest thing on a game portal, and the easiest to get wrong. A hundred games at 40 KB each is four megabytes of JPEG for a grid that shows twelve items at a time.
The fix is boring and effective: generate a WebP version at the display size, ship both, and lazy-load anything below the fold. In practice this turns a four-megabyte page into a two-hundred-kilobyte page with no visible difference.
If the image is smaller than the screen, it is too big. The only exception is when it is also the social preview.
The cost of a framework
Frameworks are not slow. Rendering a hundred DOM nodes is not slow. What is slow is doing either of those things on every keystroke, or shipping a router that re-renders a tree on every route change.
The patterns that cost the most in practice:
- Re-rendering a list on scroll, when it only changed on route change.
- Loading a font with a fallback mismatch so the layout shifts when it arrives.
- Adding an animation library for one transition.
None of these are framework problems; they are "I did not measure" problems. A page's cost is the sum of the things nobody profiled.
Pre-rendering is a performance feature
Static, pre-rendered pages are usually discussed as an SEO feature, and they are — but they also remove the most expensive moment in a web app: the first render after the JavaScript arrives.
If the HTML already contains the content, the browser can paint before the script finishes parsing. That is why this site generates a real page for every route: not only so search engines see content, but so the first paint does not wait for the app to boot.
Perceived speed
Some of the budget is psychology:
- A skeleton beats a spinner. A spinner says "wait"; a skeleton says "here is what is coming".
- Never move content after paint. Layout shift is perceived as a bug, not as slowness.
- Start the clock, not the level. Games that can show a title or a first frame immediately feel instant even if assets continue loading.
What to measure
Four numbers cover almost everything:
- Time to first byte.
- First contentful paint.
- Total bytes on the heaviest page.
- Input latency on the first interaction.
If those four are good, the game feels fast. If any of them is bad, no amount of art direction will hide it — because the player never got far enough to see the art.
