Why players leave before your game starts

Everything below was measured on 3 August 2026, in Chrome on Windows, against live pages on slowden.com. We are the portal in this article, which is the point: this is data a developer cannot normally get, because it belongs to the host, and it is easier to publish honestly when the embarrassing parts are your own.

Three games, none of them made by SlowDen:

• Hedgies — a Playgama partner game by RedSpell, embedded in a cross-origin frame.
• Snake 2048 — a Playgama partner game by TurtleGamesStudio, in the same container.
• The Cube — the open-source Rubik’s-cube project by Boris Šehovac, self-hosted with credit rather than embedded. It appears here as the counter-example.

Layout was measured by loading each live page into a same-origin frame set to an exact viewport size and reading the real bounding boxes, rather than by eyeballing a browser window. Timings come from the Navigation Timing and Resource Timing APIs on the live pages. Byte sizes were re-fetched with cache: 'no-store' and measured from the response body, because a cached resource reports zero bytes in Resource Timing and would have made the totals look far better than they are.

The container is one line of CSS: a full-width box with a fixed 16:10 aspect ratio. That means the height of your game is decided entirely by how wide the page happens to be. Here is the same game page at seven viewport sizes.

Two things fall out of that table, and neither is obvious.

On a phone your game is a postage stamp. 330 by 205 CSS pixels is about a quarter of the screen. If your first frame carries a logo, a tagline, a difficulty selector and a start button, none of it is legible. Developers routinely build a title screen in a 1280 by 720 canvas and never look at it at 330 by 205 — but that is the size a large share of players will meet it at.

The worst clipping is not on mobile, it is on a laptop. At 1536 by 695 — an extremely common real-world viewport once browser chrome is subtracted — the box is 658 pixels tall and sits 251 pixels down the page, so a third of your game is below the fold on arrival. The phone cases were not clipped at all, because the box was too small to be clipped.

Here is the load sequence for one game page, taken from Navigation and Resource Timing on the live site:

On a second game in the same container, the host page fired its load event at 726 ms while the game frame’s own resources were still landing at roughly 4.5 seconds.

So the host page is finished and painted in about a third of a second, and the game is not. What fills the gap is a black box. We reloaded both pages repeatedly and screenshotted: immediately after load, the game area was a solid black rectangle with no play control anywhere on the page, and the partner player’s own splash screen appeared only several seconds later.

This is the same failure we wrote about in the black-screen teardown, seen from the other side. There it was one game’s preload queue. Here it is structural: every embedded game has a window in which the page is done and the game is not, and by default that window is painted black.

You cannot remove that window. You can decide what is in it. A first frame that draws a background colour, the game’s name and a progress indicator within a few hundred milliseconds is doing something no host can do for you, because the host cannot see inside your frame.

You choose where the start control sits inside your frame. The host chooses where the frame sits on the page. Nobody reconciles those two decisions, and the result is measurable.

Two games, same container, same portal, same viewport of 1568 by 688:

• Snake 2048 renders Tap to start near the vertical centre of the frame. It landed around y=590, comfortably on screen. This one works.
• Hedgies renders its Let’s Play! button low in the frame. It landed at the very bottom edge of the viewport, clipped by the fold. A visitor who does not scroll never sees the control that starts the game.

Neither studio did anything wrong. Both start screens are perfectly sensible in isolation. The failure only exists in combination — and the combination is the only thing the player ever experiences.

On the page measured above, the host’s own HTML was 13,371 bytes. Its web fonts were 98 KB across five requests. Those fonts were fully downloaded at 323 ms; your game’s frame document did not finish until 1,260 ms.

You do not control that and you should not try to. But it is worth knowing, because it changes what your own budget is for. The player’s patience is being spent on the portal’s furniture before your first byte arrives, and whatever you were planning to spend on a splash animation is coming out of what is left.

The Cube is not embedded — it is self-hosted on the same domain — so it is not a like-for-like comparison, and it is included for one specific reason: it shows what a fast first frame is actually made of.

DOM complete at 292 ms, load event at 303 ms. What lands on screen is a finished, readable frame: the title, a rendered 3D cube, and the words Double tap to start. Four files, no loading bar, nothing to wait for — and note that 82 percent of those bytes are the 3D engine, not the game. The game itself is 102 KB.

The lesson is not “be under 800 KB”. It is that a first frame worth showing can be very cheap, and that shipping one is a decision rather than a budget.

1. Open your own title screen at 330 by 205 and look at it. Not a mock-up — the real build, at that size. This takes two minutes and is the single highest-value item on this list.
2. Draw something in the first frame. A background colour and the game’s name beats black. If you have a preload step, draw before you preload, not after.
3. Put the start control in the upper middle of your frame. The bottom third can be below the host’s fold; the top is always on screen.
4. Show progress if loading exceeds about a second. A bar that moves converts waiting into waiting-for-something. A static black box converts it into leaving.
5. Do not gate the first frame on audio. Audio starts suspended until the player interacts, so anything waiting on an audio context will wait forever on load.
6. Size your canvas after layout, not before. A canvas measured before the frame has its final box gets zero or a stale size, and then renders into the wrong dimensions.
7. Re-test after every portal listing. The container is the host’s and it can change without telling you.

Open the portal page that hosts your game, open the console, and paste this. It measures the page rather than guessing at it.

// Paste into the console on the page that EMBEDS your game.
const f = document.querySelector('iframe');
const r = f.getBoundingClientRect();
const nav = performance.getEntriesByType('navigation')[0];

console.table({
  'viewport'          : innerWidth + ' x ' + innerHeight,
  'your game box'     : Math.round(r.width) + ' x ' + Math.round(r.height),
  'page above game'   : Math.round(r.top) + ' px',
  'visible on arrival': Math.round(100 * Math.max(0,
      Math.min(r.bottom, innerHeight) - Math.max(r.top, 0)) / r.height) + '%',
  'scroll to see all' : Math.max(0, Math.round(r.bottom - innerHeight)) + ' px',
  'host DOM done'     : Math.round(nav.domContentLoadedEventEnd) + ' ms',
  'host load event'   : Math.round(nav.loadEventEnd) + ' ms',
  'lazy loaded'       : f.getAttribute('loading') || 'no'
});

// When did YOUR frame's document actually arrive?
performance.getEntriesByType('resource')
  .filter(x => x.name.includes(new URL(f.src).host))
  .forEach(x => console.log(Math.round(x.responseEnd) + ' ms', x.name.split('?')[0]));

Run it at a few widths — drag the window narrow, then wide — because the layout changes and the clipping is worst at sizes you would not think to check. If visible on arrival is under 100%, work out what is in the missing part.

• When and where: 3 August 2026, Chrome on Windows, against live pages on slowden.com. Every figure above is a reading, not an estimate.
• Viewport table: produced by loading each live page into a same-origin frame of the stated size and reading real bounding boxes. This measures CSS layout faithfully, but it is not a phone: there is no mobile user-agent, no device pixel ratio, and no collapsing address bar. Treat the mobile rows as the layout a phone-width viewport produces, not as a device test.
• Timings: Navigation Timing and Resource Timing on the live pages. We could not measure first paint: the automated tab loads in the background, and Chrome does not record paint timing for a page that was never visible. Every timing quoted is therefore a network or DOM milestone, and none is presented as a paint time.
• Inside the frame is invisible to us. The game frame is cross-origin, so we can see when its document arrived but not what it drew. The claims about black rectangles and start-button positions come from screenshots of the rendered page, not from reading the frame.
• Byte sizes: re-fetched with cache: 'no-store' and measured from the response body, so they are decoded sizes. On the wire they are compressed and smaller.
• One browser. Chrome only. Do not assume Safari or Firefox behave identically without testing.
• Credits: Hedgies is by RedSpell and Snake 2048 by TurtleGamesStudio, both listed on SlowDen through Playgama. The Cube is by Boris Šehovac, open source, hosted here with credit. Most games listed on SlowDen are partner or third-party titles rather than SlowDen’s own work. Playgama, Chrome and Three.js are named for accuracy only; no affiliation or endorsement is implied.

SlowDen lists browser games and takes submissions from developers. If you have a playable web build, you can send it to us.

Slow Cook is our creative challenge for developers: pick a challenge, build a small game around it, submit it before the round closes on 31 August 2026. Selected entries may receive a shoutout on SlowDen’s social accounts and a chance to be featured — nothing is guaranteed, and every entry is read by a person.

Submit your game See the Slow Cook round

• Why your browser game loads to a black screen — the same failure from inside one game, with a 203 MB preload queue taken apart.
• Which browser-game portals actually have players on them — where to list once the first ten seconds work.
• Where to publish an HTML5 browser game for free.
• How to submit your browser game to SlowDen.