DEV Community: Liza Bhadana

Your og:image is probably the wrong shape: we measured 9 sites

Liza Bhadana — Wed, 12 Aug 2026 09:14:15 +0000

Every link we had ever shared rendered as a cropped slice of our own logo. The image was 1695 × 387 — a 4.38:1 strip — and the card type our pages declare renders at about 1.91:1. Nothing warned us, because nothing in that pipeline treats a wrongly shaped image as an error.

Before building a replacement we measured nine other browser-game portals to see what a correct one looks like in the wild. Six of the nine served a measurable image, and exactly one of those matched both the card type it declared and its own declared dimensions. Ours was the worst number in the table.

The short version. A social card has a fixed shape. Your image gets fitted into it and the remainder is discarded — silently, with no error and no console message. So the defect is invisible from inside your own site: the page validates, the tag is present, the image loads. You only ever see it on somebody else's platform, in a preview you are not looking at.

What shape is an og:image supposed to be?

It depends on one other tag, which is the part people miss. twitter:card chooses which of two layouts a platform uses:

summary_large_image — the big banner card. It renders at roughly 1.91:1, and 1200 × 630 is the conventional size to supply.
summary — the small card with a thumbnail beside the text. Roughly square.

Declaring one and supplying an image shaped for the other is the whole bug. And because the platform fits rather than rejects, both mistakes look completely fine on your end. The tag is there. The image resolves. Your validator is happy. Somewhere else, a person sees the middle third of your wordmark.

Worth saying plainly, since these tags have a reputation for being fiddly: the ratio is what matters, not the exact pixel count. A 2400 × 1260 image is the same shape as a 1200 × 630 one and previews identically.

What was our own site actually serving?

We read the number out of the PNG's own IHDR header rather than trusting the filename or the CSS, and by two independent routes — once off the file on disk, once by fetching the first 16 KB of the live URL. Both gave the same answer.

Measurement	Value
The file we were serving as `og:image`	the site wordmark, 36,527 bytes
Its real pixel size	1695 × 387
Its aspect ratio	4.380 : 1
What our declared card renders at	~1.905 : 1
Mismatch	2.30×
Pages affected	23 of 235
`og:image:width` / `og:image:height` declared	neither

At 2.3× too wide, more than half the width of the image is cut. What survives is a centre slice of a wordmark with the first and last letters gone — which is worse than no image at all in one specific way: it looks like a rendering bug on the platform, not a choice.

What do other browser-game portals serve?

This is the part we had not seen written down anywhere, so we measured it. One unauthenticated GET per homepage, the Open Graph tags read out of the served HTML, then a Range: bytes=0-16383 request against each image so we could read its real dimensions out of the file's own header without downloading the whole thing. Measured 12 August 2026.

Site	Card declared	og:image, real size	Ratio	Dimensions declared in the markup
Poki	`summary_large_image`	1200 × 630	1.905	1200 × 630 — matches
Playgama	`summary`	2400 × 1260	1.905	none
CrazyGames	`summary_large_image`	1200 × 600	2.000	1200 × 630 — does not match
Armor Games	`summary_large_image`	1200 × 825	1.455	none
Y8	`summary_large_image`	500 × 500	1.000	500 × 500 — matches the file
itch.io	`summary_large_image`	no og:image	—	—
Kongregate	none	no og:image	—	—
GameJolt	none	no og:image	—	—
Newgrounds	not measured — returned 403 to our request
Ours, before this	`summary_large_image`	1695 × 387	4.380	none

Reading it honestly, four things stand out:

One site got it exactly right. Poki declares the wide card, serves 1200 × 630, and declares dimensions that match the file. That is the whole specification, done.
Y8 has our bug, smaller. It declares the wide card and serves a square 500 × 500 logo. Same class of mismatch as ours, at 1.9× instead of 2.3×.
A declared dimension can drift from the file. CrazyGames' markup says the image is 630 tall; the file the CDN actually delivered to us is 600. The image URL itself even asks for height=630&fit=crop. Thirty pixels is cosmetically nothing — but it is a live example of a hardcoded number and a real file disagreeing, which is the argument for generating those tags rather than typing them.
Three of nine ship no og:image on the homepage at all, and itch.io declares summary_large_image while supplying nothing to put in it. A card with a hole in it.

What this table is not. It is not a ranking, and it is not a criticism of anyone. Every site in it is a larger platform than ours, and the worst number in the table is ours. It is also a single unauthenticated request per homepage on one day: a site can serve different markup to a logged-in visitor or to a specific crawler, inner pages often differ from the homepage, and Newgrounds returned 403 to us so it is recorded as unmeasured rather than guessed at. The point of the table is only this — if a defect this visible is this common among sites this large, checking yours is worth five minutes.

Why did measuring first cut the job by ninety per cent?

The instinct on finding a broken share image is to build a card and put it on every page. We have 235 pages, so that is 235 edits.

Counting first said otherwise. 212 of the 235 were never part of the defect. Those pages point og:image at the individual game's own thumbnail rather than at any site-level image. We sampled 25 of the 200 catalogue thumbnails at random by range request, and 25 of 25 came back 1920 × 1080; a full sweep of all 200 resolved 196 at that size and left 4 unresolved.

16:9 is 1.778:1. Into a 1.91:1 card that is a trivial crop — a few per cent off the top and bottom. Those pages were fine.

They were also better than fine. A preview showing the actual game tells a reader what they are about to click; a brand card tells them the domain, which the platform already prints underneath. Putting a generic card on 212 game pages would have been a downgrade dressed up as a fix — the kind you never detect afterwards, because everything you changed still validates.

So 23 pages needed the new card, not 235. The general rule we took from it:

Count how many things actually have the defect before you build the thing that repairs it. The audit is not preparation for the fix. It is the first draft of the fix, and it is the step that stops a repair doing damage of its own.

Why we did not declare width and height on every page

og:image:width and og:image:height let a platform lay out the preview before it has fetched the image. That is a genuine benefit and we do declare them — on the 23 pages using our own card.

We deliberately did not add them to the 212 pages whose images live on someone else's CDN. Of 200 thumbnails, 4 did not resolve: three whose dimensions were not inside the first 8 KB, and one that timed out. Writing 1920 × 1080 on all 200 would mean publishing a number we had not verified about a remote file that can change without telling us. Leaving the tags off costs nothing, because platforms measure the image once they fetch it.

Our own card's tags are safe for a different reason: the build reads them out of the PNG header at generation time, so the declared number cannot drift from the asset. Which is exactly the failure mode the CrazyGames row above is a live example of.

The underlying principle is the same one that governs every other number we publish: a dimension you have not measured is a claim, not a fact.

Why was it the hand-written pages again?

All 17 of our blog posts carried the wide wordmark. That is not a coincidence and it is not carelessness — it is the same structural hole that had just cost us three untagged pages, described in an earlier post about missing analytics tags.

The mechanism, in one sentence: a hand-authored page starts life as a copy of an older page's <head>, so it inherits whatever that head contained — and the generator deliberately never overwrites a file a human wrote, so the template can never reach in and correct it. Every hand-written page is a snapshot of your head element on the day it was created.

The repair is a build step rather than a checklist item, because a checklist still depends on somebody remembering on file number eighteen. It is deliberately narrow: it only touches a page whose og:image is one of our own logo files. Give a post a real cover image of its own and it is left completely alone.

A gap we found while writing this, and have not closed. All 17 posts now serve the new card as their og:image — but the BlogPosting structured data on those same 17 pages still names the 1695 × 387 wordmark as its image. Two tags on one page, disagreeing about what the page's image is. The repair covered the one we went looking at and not the one beside it. We are writing it down rather than quietly fixing it later, because the whole argument of this article is that the assumption is the expensive part: we assumed a fix aimed at og:image had covered the page's images. It had not. This post uses the card in both.

What is worse than a cropped preview?

A missing one. A cropped image looks like a glitch; a preview with no image at all looks like a dead link, and it is the exact failure you invite when you repoint every page at a brand-new file that has not shipped yet.

So the card is protected three separate ways, none of which trusts the others:

The build throws a fatal error if the card is missing from source, before it writes anything.
The generator copies the card into the output as part of the build rather than relying on someone to remember it.
The bundle assembler asserts that every same-host og:image resolves to a real file in the bundle before it can be shipped.

And each of those assertions was proved able to fail — run against a deliberately broken copy of the site to confirm it catches the break, then against the clean one to confirm it still passes. A check that has never failed is not a check; it is a line of code you feel good about.

How do you check yours in five minutes?

Read your own markup from outside. curl -s https://yoursite.com/ | grep -o 'og:image[^>]*' — and note your twitter:card value in the same pass, because the two only make sense together.
Measure the file, not the CSS. Fetch the first 16 KB and read the header. For a PNG that is four bytes at a known offset:

import urllib.request, struct
req = urllib.request.Request(IMG_URL, headers={"Range": "bytes=0-16383"})
b = urllib.request.urlopen(req).read()
w, h = struct.unpack('>II', b[16:24])      # PNG IHDR
print(w, h, round(w / h, 3))

Divide. Anything outside roughly 1.7 – 2.1 will visibly crop in a wide card. A wordmark will be somewhere around 4. A square logo will be 1.0.
Check the image resolves from outside your network, on a clean request. A 404 here is worse than a bad ratio.
If you declare width and height, confirm they match the file. They drift, as the table above shows.
Then do your second-most-shared page type, not just the homepage. This is the step that actually pays. Ours was fine on 212 pages and broken on 23 — and the 23 were the ones anybody shares.
Control your own probe. Point the same script at a URL you know is not an image and at one you know does not exist. If it returns a confident answer for both, it is not measuring anything.

That last one is not padding. The reason this defect lived on our site for as long as it did is that everything we had ever pointed at it reported success.

What we could not verify

Newgrounds is unmeasured. It returned 403 to our request. That is our access, not their markup, and we are not going to guess a row.
We measured homepages, once, on one day. Inner pages commonly differ, and a site may serve different markup to a logged-in visitor or a named crawler.
Whether any of this improves click-through is unknown, and we are not going to claim it. We have no before-baseline for share-card clicks, so the honest status is unmeasured rather than improved.
The fix is not live on our own site yet. It is complete and verified in our deploy bundle, but the machine that built it has no deploy path, so as of publishing this the live site still serves the 4.38:1 wordmark — we re-checked, and the new card returns 404 on live. Saying so is simpler than the alternative, and you can verify it yourself with the curl in step 1.

Written while rebuilding the share cards on SlowDen, a place to put a browser game where people can find it and play it — no download for the player, no store page for you. Games there come from creators, partners and third-party sources, and each one is credited to whoever made it. If you have something playable, you can submit it or take a Slow Cook prompt: selected entries have a chance to be featured and selected winners may receive a shoutout, which is the honest list and there is nothing guaranteed beyond it.

Why 3 of our 16 blog posts had no analytics tag

Liza Bhadana — Wed, 12 Aug 2026 05:41:04 +0000

Three of our sixteen blog posts were about to ship with no analytics tag at all. Not a broken tag, not a wrong measurement ID — the snippet was simply not in the file. The pages rendered correctly, validated, carried their canonical link and their structured data, and would have returned a perfectly ordinary 200.

The cause is one line of reasonable behaviour: our page generator refuses to overwrite a file a human wrote. That refusal is correct. Its side effect is that the one page type written by a human is the one page type the head template cannot reach.

Nobody found this by reading a page. It was found by a build check that had never existed before, and it had already happened three times.

The short version

215 of our 235 shipping pages get the analytics tag from a template function. The other 20 get it from a person remembering.
3 of those 20 did not have it. All three were hand-written blog posts.
The other 13 posts had it because someone remembered 13 times in a row. That is a streak, not a fix.
Nothing on the page looks wrong. The failure is an absence in a report, not a defect you can see.
The fix is a build step, not a checklist item: insert the tag into any hand-authored post that lacks it, and never touch one that has it.
Two probes lied to us during the repair. Both are reproducible in three lines, and both are near the end of this post.

Why did only the blog posts lose the tag?

Our site is static. A Node script reads a registry of games and writes every crawlable page: game pages, category pages, the submission page, the challenge page, the blog index. Every one of those goes through a single function that builds the <head> — title, description, canonical, Open Graph, favicon, fonts, and the analytics snippet.

Blog posts do not go through it. They are hand-written HTML, and the generator carries an explicit instruction not to touch them, sitting right above the list of posts:

// Posts are listed by hand here so the generator never overwrites
// the hand-authored post HTML.
const BLOG_POSTS = [ ... ]

That comment is not a mistake. Regenerating a hand-written article would destroy the article. But read it as a sentence about analytics and it says something else: the head template cannot reach these files. Anything the template guarantees — the tag, and anything else you later add to it — stops at the boundary.

So the tag arrived by hand, thirteen times, and then did not arrive three times. There was no moment of carelessness that anyone could point at. The mechanism simply had no floor under it.

Which pages does a template actually protect?

We counted, because the ratio turned out to be the whole story. Of 235 pages this site ships:

How the page is produced	Pages	Where the tag comes from
Built by the generator from the head template	215	The template. Cannot be forgotten.
Copied verbatim from a hand-maintained folder	3	A person, once, in the source file.
Mirrored from the hand-edited homepage	1	A person, once, in that file.
Hand-authored blog posts	16	A person, every single time.

The 215 are safe by construction. The 4 in the middle rows are safe in practice, because they are edited rarely and the tag is already sitting in them.

The 16 in the last row are the exposure, and it is not a coincidence that the failures were all there. It is the only row where the human step repeats. A rule that has to be re-obeyed on every new file will eventually not be, and the number of chances is the number of files you plan to write.

Worth naming the general shape, because almost every static site has all three: generated pages, copied pages, and hand-written pages. Whatever you believe is on every page of your site is only guaranteed on the first kind.

How do you find untracked pages on your own site?

The check is trivial. Search your built output for your measurement ID and list every file that does not contain it. Ours reported three:

3 page(s) missing the analytics tag:
    blog/the-same-url-served-two-different-images/index.html
    blog/the-star-rating-your-iframe-added/index.html
    blog/the-game-metadata-field-nobody-fills-in/index.html

Two things make the difference between that check being useful and it being theatre.

1. Audit what you ship, not what your build folder contains

Our output directory holds 347 HTML files. Only 235 of them ship. The other 112 are directories for retired pages the generator has never deleted, plus one snippet file that is not a page at all — it is a block of HTML meant to be pasted into another document.

Run the audit over the folder and 112 of your results describe files no visitor can reach. Worse, the noise runs both ways: a retired page that does carry the tag inflates your pass rate, and a snippet that legitimately has no <head> reports as a failure forever. Build the list of pages you actually ship, and audit that.

2. Break the check on purpose before you believe it

A check that has never failed is not a check — you have no evidence it can detect anything. So before trusting ours, we deleted the analytics snippet out of one post and re-ran the build:

md5 before strip : 187fbf210f520e496e97f082c41cf25b
tag occurrences  : 0          <- deliberately broken
build            : "inserted the analytics tag into
                    hand-authored /blog/the-star-rating-your-iframe-added/"
md5 after repair : 187fbf210f520e496e97f082c41cf25b   <- identical

That single test proves three separate things at once: the check notices, the repair works, and the repair is byte-for-byte non-destructive. A hand-written article is exactly the kind of file where "it probably re-wrote it correctly" is not good enough.

What we changed, and why it is not a checklist item

The tempting fix is a note in the authoring instructions: remember to paste the snippet. That is what we effectively had, and it produced thirteen successes and three silent failures.

Instead, the generator now repairs the gap itself. After it writes the blog index, it walks the list of posts and, for any post whose file does not already contain the measurement ID, inserts the same snippet every generated page uses, immediately before the closing </head>. Four properties made it safe enough to run unattended on hand-written prose:

Insert-only. It never rewrites, reformats, re-indents or removes a byte of the article. It splits the file at one index and puts a string in the gap.
Idempotent. A post that already carries the tag is not opened for writing at all, so it is not restamped as "changed" in our sitemap date manifest and does not falsely claim to have been updated today.
Loud. Every repair prints a line naming the post. A silent self-healing step is just a slower version of the same problem, because nobody learns the authoring habit is drifting.
Fails hard on the case it cannot fix. If a post is listed but its file is missing, the build stops with an error instead of continuing. A listed-but-missing post would put a dead URL in the sitemap and a dead card on the blog index — a 404 shipped on purpose.

The same pattern already existed elsewhere in this generator, for a different hand-edited file that had gone stale nine times in five weeks. That is the tell: when the second instance of a class of bug appears, the fix is a step in the build, not a better memory.

Untracked is not the same as unpublished

An awkward detail, recorded because it is the reason this cost nothing. The same three posts were also the three not yet deployed — they return 404 on the live site right now, verified against a deliberate nonsense URL that returned an identical 404 body. So no real visit went unmeasured.

That overlap is luck. The two failures are unrelated and they behave in opposite ways:

	Unpublished page	Untracked page
What it returns	404	200
How it looks	Obviously broken	Perfect
How you find out	Immediately	Weeks later, in a report
What it looks like when you do	A missing page	A page nobody visited

That last cell is the expensive one. An untracked page does not report as an error, it reports as indifference — and a page that appears to have no audience is a page someone eventually decides not to write again.

Two probes that lied while we were fixing it

Both of these happened during the repair above, both are on Windows, and both are reproducible in three lines. They are here because each one is the same species of problem as the bug itself: a thing that quietly does not do what it appears to do.

A text-mode file read rewrote a file we only meant to inspect

Opening a file in Python's default text mode, reading it, and writing the identical string back is not a no-op on Windows. Line endings are translated on write. A three-line file with Unix endings, read and written unchanged, gained three bytes:

printf 'alpha\nbeta\ngamma\n' > lf-control.txt

python -c "d=open('lf-control.txt',encoding='utf-8').read();
           open('lf-control.txt','w',encoding='utf-8').write(d)"

carriage returns before : 0
carriage returns after  : 3

On our 253-line article that turned into 253 changed bytes across the whole file, which is why the byte-for-byte check above initially failed. It was not the repair that changed the file; it was the tool used to inspect it. Open in binary mode, or pass newline='', when the bytes are the thing you are checking.

The probe that said the file was clean returned zero either way

Worse, the obvious way to check for the damage said there was none. Searching the file for a carriage return reported 0 — on a file that provably contained three:

printf 'alpha\r\nbeta\r\ngamma\r\n' > crlf-control.txt

od -c crlf-control.txt | grep -o '\r' | wc -l   -> 3   (they are there)
grep -c $'\r'  crlf-control.txt                 -> 0   (says clean)
grep -c $'\r'  lf-control.txt                   -> 0   (also says clean)
grep -cU $'\r' crlf-control.txt                 -> 3   (correct)

Without -U, the file is treated as text and the carriage return is stripped before the pattern is applied, so the search can never match. Note the third line: the probe returns 0 on a file that has them and 0 on a file that does not. It is not inaccurate, it is inert — there is no input that would make it say anything else.

That is the general rule worth taking away, and it is the same rule that found the original bug. Run your checker against an input you know should fail. If it passes that too, the checker is not measuring anything, and every green result you have collected from it means nothing.

How to check yours, in about ten minutes

Write down your ship list — the pages a visitor can actually reach. Not your build folder, and not everything your generator has ever emitted.
Grep that list for your measurement ID and print the files that do not contain it. Expect the count to be greater than zero the first time.
Sort the misses by how the page was produced. If they cluster in one production path, you have found a structural gap, not three mistakes.
Delete the tag from one page and re-run. If the check still passes, fix the check before you trust a single result from it.
Move the guarantee into the build, and make it print a line when it repairs something.
Repeat with anything else your template promises — canonical links, viewport meta, structured data, consent scripts. They all stop at exactly the same boundary.

What we could not verify

Stated plainly, because a post that only reports its wins is not worth much:

How long the gap existed before it was found. The three posts were written on 7, 8 and 11 August 2026 and the check was added on 12 August, but we did not reconstruct the exact authoring history of the other thirteen, so "someone remembered thirteen times" is inferred from the files' contents rather than from a record of each edit.
Whether any traffic was lost. None of the three had been deployed, so the answer is almost certainly no — but "almost certainly" is the honest phrasing, not "none".
Whether the same class of gap exists elsewhere on this site. We audited the analytics tag specifically. The other things the head template guarantees have not been swept yet, and the point of this post is that they have exactly the same boundary.
The line-ending and grep behaviour on other platforms. Both were measured on Windows with the tooling in front of us. We did not test macOS or Linux, and are not claiming anything about them.

The same URL served me two different images

Liza Bhadana — Tue, 11 Aug 2026 05:59:51 +0000

I fetched one image URL twice, in the same browser, on the same page, about a second apart.

The first fetch returned 2,864,826 bytes of PNG at 1920×1080.
The second returned 115,500 bytes of AVIF at 512×288.

Same URL. Same machine. Same session. Nothing cached differently, nothing random.

The difference was one request header I never wrote, and would not have thought to look at.

The URL also carries ?width=512, which looks like it is asking for a small image. It is not. That parameter does nothing at all.

Everything below was measured on 2026-08-11 against a live CDN, with negative controls.

Part 1: the parameter that does nothing

Every game thumbnail in the catalogue I work on is stored on a partner CDN, and every URL ends the same way:

https://static.playgama.com/p-img/pg/hedgies/preview/fe27263…?width=512

?width=512. That reads like a resize instruction. So the first thing worth doing is the thing almost nobody does: change it and see if anything happens.

Query string	Status	Bytes returned
(no query at all)	206	2,864,826
`?width=512`	206	2,864,826
`?width=256`	206	2,864,826
`?width=64`	206	2,864,826
`?width=999999`	206	2,864,826
`?width=abc`	206	2,864,826
`?width=0`	206	2,864,826
`?wibble=512`	206	2,864,826

Byte-identical, every time. The parameter is decoration. ?width=abc and ?width=0 are not errors, they are simply ignored, and so is a parameter name that does not exist.

That last row matters more than it looks. If I had only tested ?width=512 against ?width=256 and seen no change, I could have told myself the CDN was clamping to some minimum. Adding a parameter the CDN has certainly never heard of proves the simpler thing: nothing in the query string is being read.

A checker that cannot fail is not a checker. So I also corrupted the path — same URL with /preview-NOT-REAL/ spliced in — and got a clean 404. Good. The probe can tell yes from no.

Takeaway for your own code: before you build a responsive image pipeline on top of somebody else's URL parameter, feed it nonsense. A parameter that returns identical bytes for 512, 0, abc and a made-up name is not a knob. It is a comment.

Part 2: the header that does everything

If the URL is not choosing the image, something else is. It turned out to be Accept — the header your browser sends to say which formats it can decode, and which you almost never set by hand.

Same URL, three requests, only the Accept header changed:

`Accept` sent	Format returned	Bytes	Pixels
`image/jpeg,image/png,/`	PNG	2,864,826	1920 × 1080
`image/webp,image/*`	WebP	189,832	512 × 288
`image/avif,image/webp,image/*`	AVIF	115,500	512 × 288

Two things are happening at once here, and it is worth separating them.

The first is the obvious one: format. AVIF beats WebP beats PNG, which is the whole point of content negotiation and is working exactly as designed.

The second is the one that surprised me: resolution. The modern variants are not just better-compressed versions of the same picture. They are a different, smaller picture — 512 × 288 against 1920 × 1080. The fallback is the full-size original; the negotiated variants are derivatives capped at 512 px wide.

(That the PNG is "the original upload" is my inference from its size and dimensions, not something the CDN told me. What is measured is the pixel count.)

So the byte gap is not 3× from better compression. It is 24.8×, because format and resolution moved together.

And critically: Accept: */* gets you the PNG. So does no Accept header at all. So does a browser-style HTML accept string. Wildcards do not opt you in. You have to name image/webp or image/avif explicitly, and only real image requests from real browsers do that.

Part 3: 200 images, not one

One image is an anecdote. So I ran the same three-header probe across every thumbnail in the catalogue — 200 URLs × 3 Accept headers = 600 requests.

The trick that makes this cheap: a Range: bytes=0-0 request downloads one byte, but the 206 response still carries Content-Range: bytes 0-0/<total> — and the CDN still performs content negotiation on it. So one byte per request buys you both the true size and the negotiated format. 600 bytes of transfer instead of roughly 600 MB.

`Accept` sent	Formats returned	Total	Mean per image	Over 1 MB
`image/jpeg,image/png,/`	188 PNG, 12 JPEG	418.9 MB	2,144.9 KB	162 / 200
`image/webp,image/*`	200 WebP	30.5 MB	156.1 KB	0
`image/avif,image/webp,image/*`	200 AVIF	19.5 MB	100.0 KB	0 / 200

200 of 200 negotiated successfully. Not one image failed to produce a modern variant.

The per-image ratio ranges from 2.4× to 48.3×, median 22.1×. Thirty-five thumbnails are over 3 MB in the fallback path; the largest is 4,017,308 bytes. The smallest is 154 KB — already small enough that negotiation barely helps it.

That spread is the useful part. There is no single multiplier you can assume. If you need the number, you have to measure the set.

Part 4: the demo that made it click

Everything above I measured from a terminal, which is exactly the position that produces wrong conclusions about browsers. So I did it from inside the page instead.

On the live page, in Chrome, I read the rendered thumbnails and then fetched one of the very same URLs from the same page:

// what the <img> actually got
document.querySelector('img.tfull').naturalWidth   // 512
document.querySelector('img.tfull').naturalHeight  // 288

// same URL, same page, one second later
const r = await fetch('https://static.playgama.com/p-img/pg/hedgies/preview/fe27263…?width=512');
(await r.blob()).size          // 2864826
r.headers.get('content-type')  // "image/png"

The <img> tag got a 115 KB AVIF. fetch() got a 2.8 MB PNG. One page, one browser, one URL, two completely different images.

Nothing is broken. <img> sends the browser's image Accept list. fetch() defaults to */*. They are two different clients that happen to live in the same tab.

Once you have seen that, a whole category of confusing bug reports resolves itself.

Part 5: why you cannot see this from your own page

The natural next move is to measure it with the Resource Timing API and put it on a dashboard. That does not work here, and the reason is worth knowing.

All 200 thumbnail entries came back with encodedBodySize = 0. Not "small". Zero. Every one.

That is not a bug either. Size fields on cross-origin resources are hidden unless the responding server sends Timing-Allow-Origin. This CDN does not, so the numbers are withheld from the page.

The headers the page can read are the CORS-safelisted four: content-type, content-length, cache-control, last-modified.

So: your own real-user monitoring cannot measure the weight of the third-party images on your own page. Third-party image weight is invisible from the inside by default. It has to be measured from outside, deliberately, which is why it tends not to be measured at all.

Part 6: where this actually bites

Your og:image. Every one of our 200 game pages sets og:image to one of these URLs. Anything that fetches it while sending */* receives the 1920 × 1080 PNG — up to 4 MB — where a visitor to the same page receives ~100 KB.

I want to be careful here, because it is easy to overclaim. What I measured is the header, not the crawler. I confirmed that a client sending */* gets the PNG. I could not verify what any particular social crawler actually sends, because I cannot make requests from their infrastructure. If your preview images matter to you, the honest move is to check your own logs, not to trust my guess or anyone else's.

Your CI budget. A page-weight check that fetches images with a plain HTTP client is measuring the fallback path. It can fail a build over 400 MB of images that no user will ever download — or, if you set the budget from that number, quietly pass everything forever.

Anything that proxies or re-hosts images. Image proxies, email pipelines, RSS-to-newsletter tools, thumbnail caches, LLM ingestion — they mostly send */*, and they will pull and store the heavy original.

Anything that re-encodes. If you pull the fallback and re-encode it to WebP yourself, you are doing a lot of work to arrive somewhere near where the CDN would have put you for free.

Part 7: the defect this found on my own site

Measuring this exposed something that had nothing to do with the CDN, and it was mine.

The homepage renders every game as a card across twelve category rails. Reading the DOM on the live site:

274 <img class="tfull"> elements
0 with a loading attribute
0 with decoding
0 with srcset
200 distinct thumbnail requests fired on a single first load

Every thumbnail in the catalogue, requested immediately, including rails several screens below the fold. At the measured AVIF mean that is roughly 19.5 MB of image on first paint.

(Computed, not directly observed — Timing-Allow-Origin is absent, so the browser would not tell me the sizes. It is the sum of the per-URL sizes I measured separately, for the exact 200 URLs the page requested.)

The irritating part: the generated pages had this right all along. The page generator has always emitted loading="lazy" past the first six cards. The homepage is the one file that is hand-edited rather than generated, and it never got the attribute.

The fix is three tokens — eager for the first six cards of the first rail, loading="lazy" and decoding="async" for the rest:

`<img class="tfull" src="${g.thumbnail}" alt="${alt}"` +
`${eager ? '' : ' loading="lazy"'} decoding="async" onerror="this.remove()">`

Measured in a browser, before and after, on the same build:

	Distinct thumbnail requests on first paint
Before	200
After	6

After scrolling 1000 px it had loaded 50 — which is the point. The images still arrive; they arrive when the reader is actually heading towards them.

No layout shift, either, and not by luck: .thumb already carries aspect-ratio: 16/10, so every card's box is reserved before its image exists. A lazy image drops into a slot that is already the right size. If your grid does not reserve the box, add loading="lazy" and you will trade page weight for layout shift — fix the box first.

Part 8: how to check yours, in about five minutes

Break the URL parameter on purpose. Request your image with ?width=64, ?width=abc, ?width=0 and a parameter name you invented. Identical bytes every time means the parameter does nothing.
Then corrupt the path, and confirm you get a 404. If that also returns 200, your probe is broken and every result above it is meaningless.
Send three Accept headers — */*, image/webp,image/*, image/avif,image/webp,image/* — and compare Content-Type and size.
Check the pixels, not just the bytes. naturalWidth in the browser, or the image header. Format and resolution can move together, and only looking at bytes hides that.
Use Range: bytes=0-0 to sweep a whole catalogue for a few hundred bytes of transfer.
Count your eager images. In the console: [...document.images].filter(i => !i.hasAttribute('loading')).length.

What I could not verify

Stated plainly, because a measurement piece that only reports its wins is not worth much:

What real social crawlers send. I tested Accept headers, not crawlers. Any claim about a specific platform's preview fetch would be a guess.
Whether the 1920 × 1080 PNG is genuinely the original upload. It is consistent with one. The CDN did not tell me.
Real-world impact on visitors. The 200 → 6 change is a measured reduction in requests on first paint. I have not yet measured what it does to load time for real people on real connections, and I am not going to claim a number I have not collected.

Related, from the same site

Measured while running SlowDen, a free browser-game site. The games come from partners and creators, each credited on its own page. If you have a playable browser game you can submit it, or take on a Slow Cook challenge — a creative prompt, a small game, and a chance to be featured.

The star rating your iframe added to your page

Liza Bhadana — Sat, 08 Aug 2026 16:44:22 +0000

Google's Rich Results Test says one of our game pages has four valid structured-data items. We wrote one of them.

The other three — an Organisation, a Review snippet and a Software App — are published by a document we do not control, do not host, and cannot read from our own page. It arrives in an <iframe>. It brings a star rating with it, and Google's own tool reports that rating as ours.

Nobody did anything wrong to make this happen. Our markup is clean and always has been. The partner's markup is exemplary — genuinely one of the better structured-data implementations you will read. Put the two together with a normal load-time iframe and you get a third thing that neither party wrote.

If you embed anything on your site — a game, a video, a map, a booking widget, a review carousel — this is a five-minute check you have probably never run.

The short version

Two pages, same template, same day, one difference. The page whose iframe points at a document with a JSON-LD graph: 4 valid items. The page whose iframe points at a document with none: 1 valid item. Same tool, five minutes apart.
The extra three item types are Organisation, Review snippets and Software apps. The detected Review snippet carries an @id on the provider's domain, not ours.
0 of 200 of our live game pages carry a rating in their own markup. 190 of 200 of the embed documents they load do.
The Software App item detected on our page is named after the platform, not the game — it is the provider's Android app listing.
It is not a games-industry quirk, and it is not universal either: of 11 public embed endpoints we could read, 4 serve parseable JSON-LD and 1 serves a rating.
A text search for the property name is not a test. On 4 of those embed documents, searching the HTML for aggregateRating returned true while the parsed structured data contained no such property.

What I measured, and what I am not claiming

Everything below is a count of published metadata and tool output, taken on 8 August 2026. Three honest limits, stated before the numbers rather than after them.

I am not claiming Google will show a star rating for our site. The Rich Results Test reports eligibility, and Google states plainly that it does not guarantee rich results even with correct markup. What the tool reports is that the item exists, is valid, and is attributed to our URL. Whether it ever reaches a search result is a different question I did not measure.

I am not claiming Google documents this behaviour as a rule. I looked. Google's structured-data documentation does not contain a statement of the form "markup inside an iframe is attributed to the parent". What it contains is an acknowledgement that the situation arises, which I quote further down. Treat the mechanism as measured on one date, on two URLs, with a control — not as a documented guarantee.

I could not check whether the rating is visible to a human inside the player. That frame is cross-origin, so the host document cannot read into it, and a screen capture of a cross-origin game canvas is not evidence of anything — it comes back solid black even while the game runs perfectly. So the honest statement is narrower than the tempting one: our page's own text shows no rating, and I verified that directly. What the player renders inside its own frame is unmeasured.

One method rule that changed a number in this article. Do not search the HTML for a property name; parse the JSON-LD and look for the property as a real key on a real node. Four of the embed documents I probed contain the string aggregateRating somewhere in their markup or scripts while publishing no such property. A substring test would have reported four ratings that do not exist. My harness was validated against a document that definitely has a parsed rating (detected) and one where the string appears only in an HTML comment and in body text (not detected, while the substring test said yes).

The controlled pair

This is the whole finding in one table. Both URLs are generated by the same script, from the same template, and their own JSON-LD is identical in shape: one block containing a BreadcrumbList and a VideoGame, with no rating and no review anywhere in it. I verified that by parsing both pages, not by reading them.

The only relevant difference between them is which document the static <iframe> loads. One loads a partner page that publishes a JSON-LD graph. The other loads a partner page that publishes none.

Google Rich Results Test, 8 Aug 2026	Page A — embed has a JSON-LD graph	Page B — embed has no JSON-LD (control)
Crawled at	21:40:29	21:45:13
Valid items detected	4	1
Breadcrumbs	1 valid item	1 valid item
Organisation	1 valid item	—
Review snippets	1 valid item	—
Software apps	1 valid item (1 non-critical issue)	—
Rating in the page's own JSON-LD	none	none
Rating in the embed document	`ratingValue 4.6`, `ratingCount 205`	none — 0 JSON-LD blocks

Page A is Mystery Squishy Dumpling Blind Box, a partner game credited on the provider's own page to Universe 25. Page B is Deadly Descent. Both are third-party games playable on SlowDen; neither is a SlowDen Original, and this article makes no claim about either game's quality.

Three of the four rich-result item types vanish when the embed changes. That is what a control is for: it rules out the explanation that our own template quietly grew a rating, and it rules out the tool inventing items.

The detail that settles provenance is inside the Review snippet item. Its @id is https://playgama.com/game/mystery-squishy-dumpling-blind-box#Game — a URL on the provider's domain, reported by Google as a valid item on a slowden.com URL.

What is actually inside the embed

I expected a rating. What the embed document publishes is an entire identity graph.

Parsed from the frame's own URL, its single JSON-LD block contains an Organization, a WebSite and an ItemPage, and nested inside the ItemPage is the game itself. The game node is co-typed:

"@type": ["VideoGame", "WebApplication"],
"name":  "Mystery Squishy Dumpling Blind Box",
"@id":   "https://playgama.com/game/mystery-squishy-dumpling-blind-box#Game",
"author":          { "@type": "Person", "name": "Universe 25" },
"offers":          { "@type": "Offer", "price": "0", "priceCurrency": "USD" },
"aggregateRating": { "@type": "AggregateRating",
                     "ratingValue": 4.6, "ratingCount": 205,
                     "bestRating": 5, "worstRating": 1 }

Look at those three properties together, because that combination is not decorative. Google's Software App rich result is valid on SoftwareApplication and its subtypes including WebApplication, and its required properties are name, offers.price, and aggregateRating or review. The embed document carries all three. It is a complete, qualifying rich-result item.

Which produces a result worth sitting with. There is no Google rich result for a game — neither VideoGame nor Game appears in Google's list of supported features. The only one a game page can earn is Software App, and it requires a rating. A site with no rating system of its own is therefore locked out of it by construction. Our pages are locked out of it — and Google's own tool says one of them qualifies anyway, on numbers we did not collect.

The enclosing graph goes further than the game. Alongside it the embed publishes the platform's own WebSite node, a MobileApplication node for the platform's Android app, and a publisher Organization carrying the company's legal name, its VAT and DUNS identifiers, a registered postal address, a support email, a named founder with job title, eight sameAs social profiles and a platform marketing description. I am describing the field types rather than reprinting the values, because none of it is mine to republish — but all of it is what Google reads on our URL.

That also explains the oddest line in the test result. The Software App item detected on our game page is not named after the game. It is named after the platform: it is the provider's Android app listing, surfacing as a Software App rich-result item on a page about a browser game.

One more thing worth noticing, and it closes a loop from last week's article about the game-metadata field nobody fills in. This graph is close to a model implementation — genre, device list, operating system, author, offer, publish date, platform list, a PlayAction. It contains zero schema.org accessibility properties. Not one. The field that tells a player whether their phone is enough is absent even here, in markup this careful. Google pays for the rating field. It pays nothing for the accessibility field. The incentive is visible in a single document.

How much of a catalogue this touches

Two pages prove a mechanism. The next question is scale, so I measured every page and every embed we ship. All figures are live, fetched from the public site and the public embed URLs on 8 August 2026, and both sides came back complete — 200 of 200, zero fetch errors.

Measured live, 8 Aug 2026	Result
Game pages returning HTTP 200	200 of 200
Game pages carrying a rating in their own parsed JSON-LD	0
Game pages shipping the partner iframe in static HTML	200
Embed documents returning HTTP 200	200 of 200
Embed documents serving a parsed `aggregateRating`	190
Embed documents serving none	10

The split between 190 and 10 is not random, and the reason is useful if you are auditing your own site. All 190 rated embeds are served from the platform's own domain. All 10 unrated ones are served from standalone game domains the platform routes to instead — a different, much smaller document, roughly 32 KB against 99 KB, with zero JSON-LD blocks in every single case. The same provider, two delivery paths, and only one of them hands you a graph.

So "my provider publishes structured data" is not a per-provider fact. It is a per-URL fact.

One number I am deliberately not publishing. I have the rating values for all 190 and it would be easy to average them. I am not going to, because an average would read as a quality claim about a catalogue whose ratings we did not collect and cannot stand behind. What is fair to report is the shape, because the shape is the point: the values run from 3.9 to 4.8, exactly one of the 190 sits below 4.0, and none sits below 3.5. An inherited rating is not a neutral signal. A page that inherits one inherits a flattering one.

For clarity about what is what: all 200 games in that catalogue are third-party partner games, credited to their studios. SlowDen's own game sits outside that registry. Nothing in this article is a claim about who made any of them.

Is this a game-portal thing?

That was my first assumption and it is wrong in both directions. I probed 14 public embed endpoints across six categories, parsing the JSON-LD of each. Eleven returned a document I could read.

Embed endpoint	Kind	Parsed JSON-LD	Rating?
Game portal (partner player)	game	`Organization`, `WebSite`, `ItemPage` → `VideoGame`+`WebApplication`	yes
Video player A	video	`VideoObject`	no
Live-video player	video	`Organization`	no
Archive player	video	`BreadcrumbList`, `ListItem`	no
Video player B	video	none	no
Music player A	audio	none	no
Music player B	audio	none	no
Map embed	map	none	no
Social post embed	social	none	no
Game widget (indie marketplace)	game	none	no
Game embed (HTML5 supplier), 2 games	game	none	no
Code sandbox embed	code	not measured — 403 to an automated request	unknown
Game portal (major)	game	not measured — 401, no public embed endpoint	unknown
Game embed (second HTML5 supplier)	game	not measured — no public endpoint found	unknown

Two things follow. Most embeds ship no structured data at all, so this is not a general emergency — and it is also not predictable from the category. Two video players in the same category differ from each other. Two game embeds in the same category differ from each other. The only way to know is to look at your own embed URL.

A note on the three unmeasured rows, because getting this wrong is how false findings get published: a 401 or a 403 is not a zero. One endpoint requires authentication and one blocks automated requests. Both may well serve structured data to a browser. They are recorded as unknown, not absent.

And the four grep false positives all came from this group: a substring search for aggregateRating returns true on two video players, a music player and one other — none of which publishes the property. If you audit with grep you will find ratings that are not there.

Nobody did anything wrong, and it still crosses a guideline

This is the part I want to be careful about, because the easy version of this story is an accusation and the true version is not one.

The provider wrote correct, thorough markup on its own page and made that page embeddable, which is the entire point of an embed. We embedded it the ordinary way. Neither of us wrote a rating onto a SlowDen URL. And yet, read against Google's published guidance, the resulting page sits on the wrong side of two lines.

From Google's general structured data guidelines:

"Don't mark up content that is not visible to readers of the page."

"Your structured data must be a true representation of the page content."

Our page's own text contains no rating: I checked, and there are zero occurrences of the rating value, the rating count, the words "rating", "rated" or "review", and zero star glyphs anywhere in the rendered text we serve.

From Google's review snippet guidelines:

"Don't aggregate reviews or ratings from other websites."

Which is precisely what a load-time embed does on your behalf, silently, at whatever scale you embed at.

And here is the closest thing to an acknowledgement in Google's own text that widget-delivered markup counts as being on the host page. It appears in the specific rule about businesses reviewing themselves, describing how such a review can arrive:

"…either directly in their structured data or through an embedded third-party widget…"

Read that precisely. The ineligibility rule it belongs to is about a local business or organisation hosting reviews of itself, which is not our situation and probably not yours. I am not claiming that rule applies here. What the sentence establishes is narrower and more useful: Google treats structured data arriving via an embedded third-party widget as structured data on the host page. That is the assumption my measurement rests on, and Google's documentation states it in passing rather than leaving it to inference.

Set the search engine aside for a moment, though, because the trust problem does not depend on it. If a visitor ever sees stars next to your domain in a result, they will read those stars as yours. Ours are not. We collect no ratings, we have never published one, and we are not in a position to defend a number a partner computed on a different site from a different audience. That is a reason to care about this even if Google never renders it.

Why we have not applied the obvious fix

There is a one-line fix and we are not using it, and saying why is more useful than pretending the problem is hard.

Our generator already has a flag that creates the game frame on click instead of at page load. Flip it and the frame does not exist when a crawler renders the page, which would very likely end the attribution.

It stays off for a reason that outranks a flattering rating: nobody has verified what the provider counts when the frame is created on click rather than at load. Every embed URL carries a partner parameter that credits the play, and that parameter is how the arrangement works at all. Reasoning about our own markup cannot answer a question about someone else's counting. A rating we did not ask for is a smaller harm than a play that does not register, so the flag stays where it is until the counting question is answered by the provider rather than by us guessing.

There was also a second, plainer reason it was turned off in the first place: a click-to-start poster in front of a player that already has its own start screen made it three clicks to reach a game.

If you are in the same position, the honest options are the same three. Ask the provider whether their markup is meant to travel with the embed — many providers would rather it did not. Create the frame after a click, once you know what that does to whatever the provider measures. Or accept it deliberately and write down the reason, which is what we have done, in a comment next to the iframe so the next person does not silently "fix" it.

Five minutes on your own site

This costs almost nothing and I would be surprised if most sites with embeds have run it.

Write down what you think your page publishes. Open your own template and list the structured-data types you wrote. Ours is two: a breadcrumb and a game.
Run the page through Google's Rich Results Test. Compare its list of detected items to your list. Anything extra did not come from you.
Expand each unexpected item and read its @id and url. A property pointing at a domain that is not yours tells you exactly where it came from.
Fetch your embed's URL on its own and parse its JSON-LD. Parse it — do not search the text for property names, or you will find four ratings that do not exist.
Test a page with a different embed as a control. This is the step that turns a suspicion into a finding. If you have only one embed provider, compare against any page on your site that has no embed at all.

If you ship an embeddable widget rather than host one, the same measurement points the other way and is worth ten minutes of your time: whatever your frame document publishes, your customers publish too. A rating, an offer, a company identity, a founder's name. Structured data on an embeddable page is not the same object as structured data on a normal page, and most embeddable pages appear to have been built by copying the normal one.

What we changed, and what we did not

Nothing about the site changed today as a result of this. That is deliberate, and it is the honest end of the story rather than a tidy one.

What did change is that the decision is now written down where it cannot be lost: our build refuses, as a fatal error, to emit any rating property in any structured-data block, tested by deliberately poisoning a scratch copy of the generator to confirm the guard actually fires. That protects against the version of this problem we can control — someone adding a rating because a rich result requires one. It does nothing about markup arriving in a frame, and pretending otherwise would be worse than the gap.

The gap that remains, stated plainly: 190 of our game pages are eligible, in Google's own tool, for rich results built from a rating we did not collect. One of them has already been recorded as a valid review-snippet item by Search Console. We know why, we know the one lever that would change it, and we are not pulling that lever on an unverified assumption about someone else's counting.

Questions

Can structured data inside an iframe really be attributed to the host page?
We measured a case where it was. Two pages from the same generator, built from the same template on the same day, differ only in which document their static iframe points at. Google's Rich Results Test reported 4 valid items on the page whose embed carries a JSON-LD graph and 1 valid item on the page whose embed carries none, and the detected review-snippet item carried an @id on the provider's domain. Google does not publish a rule stating that this happens, so treat it as a measured behaviour on one date rather than a documented guarantee.

How do I check what my own embeds publish on my behalf?
Run your page through Google's Rich Results Test and compare the detected items against the structured data you actually wrote. Anything extra came from somewhere else. Then fetch your embed's URL directly and parse its JSON-LD. Do not use a text search for the property name: on four of the embed documents we probed, searching the HTML for aggregateRating returned true while the parsed structured data contained no such property.

Is this a real problem or a curiosity?
Google's general structured data guidelines say not to mark up content that is not visible to readers of the page, and its review snippet guidelines say not to aggregate reviews or ratings from other websites. A host page can end up in both positions without writing a line of markup. Separately, and independently of any search engine, a rating a visitor reads as yours that you never collected is a trust problem you cannot defend.

Which kinds of embed carry structured data inside them?
Fewer than you would guess, and it is not predictable by category. Of 11 public embed endpoints we could read, 4 served parseable JSON-LD and only 1 served a rating. Two video players in the same category behaved differently from each other, and so did two game embeds. Two further endpoints refused an automated request, which is not the same as serving nothing, and are recorded as unknown.

Should I stop embedding third-party content?
No. The embed is usually the product. The point is to know what it publishes in your name and to check rather than assume. If your provider ships structured data you cannot stand behind, the options are to raise it with them, to create the frame after a click, or to accept it deliberately with the reason recorded. Creating the frame on click can affect whatever the provider counts, so verify that before changing it.

Does the embed's canonical tag affect the host page too?
We did not measure that and are not claiming it. The embed document does declare its own canonical, og:url and og:title pointing at the provider's domain, and anything fetching the frame's URL can see them. What we measured is structured-data attribution, not canonicalisation. The rest is unverified.

Why does a page with no rating system care about rich results at all?
Because the only Google rich result a game page can earn is Software App, and it requires an aggregateRating or a review. There is no rich result for a game as such. A site that collects no ratings is locked out by construction, and the only honest route in is to build a real rating system of its own. Copying a partner's number is not a shortcut, it is a false claim.

Written on SlowDen, a place to put a browser game where people can find it and play it — no download for the player, no store page for the developer. Games there come from creators, partners and third-party sources, each credited to whoever made it. Our creative challenge round, Slow Cook, closes on 31 August 2026: you get a prompt, you build something around it, you submit it for consideration. Selected entries have a chance to be featured and selected winners may receive a shoutout on SlowDen's social accounts — that is the honest list, and there is nothing guaranteed beyond it. Submit a browser game · See the Slow Cook challenges · More articles

200 game pages, 200 star ratings, 0 machine-readable controls

Liza Bhadana — Fri, 07 Aug 2026 10:29:29 +0000

A player lands on your game's page. Before they commit any attention to it they want one thing answered: do I have what this needs? A keyboard, a mouse, a thumb. On a phone that question is the entire decision.

Now look at what the page actually gives them. A star rating. A rating count. A genre list. A developer name. A publish date. A play button.

I went and counted. Across 200 game pages on four different browser-game portals, every single one publishes a star rating. Not one publishes the machine-readable field that says what you need in your hands.

That field is not missing from the standard. schema.org defines it, it is valid on every game page on the web without an extension, and it goes in the same JSON-LD block that already carries the star rating. It is missing from the practice, and the reason turns out to be worth a developer's time: nobody upstream is ever asked for it.

The short version

200 game pages, four portals. 0 carry any schema.org accessibility property. 200 carry aggregateRating.
schema.org's own usage stats: aggregateRating is on 1M–10M domains. accessibilityControl — the field for "what input fully drives this" — is on 1K–10K.
The data isn't hidden, it was never collected. 190 of 190 supplier pages have a "How to Play" section; only 107 name an input device anywhere in it. Of the 38 games where we hold no control text at all, 3 have an upstream section that names a device.
The supplier's device flag is not a substitute. 182 of 190 pages claim mobile support; for 118 of those, the supplier's own how-to-play text never mentions touch.
One platform gets this right, and it is the one that asks the developer directly. itch.io has 25 input methods in its taxonomy and 65,185 HTML5 games declaring a keyboard.
We shipped a fix into our own build: 96 of 200 game pages now emit accessibilityControl. The other 104 emit nothing, on purpose.

What I measured, and what these numbers are not

Every figure here is a count of published metadata — what a page says about a game. None of it is a count of behaviour. No game in this article is described as broken, or as working. Games here run inside a cross-origin frame drawing to a WebGL canvas the host page cannot see into; screen captures of that region come back solid black even while the game runs perfectly, and asking the host document how many canvases exist returns zero. That trap has cost us a full day before. "The page documents X" is the strongest claim this evidence supports, and it is the one I am making.

Three guards, because a measurement can be perfectly real and the conclusion still wrong.

The wrong-game guard. Our internal slug for a game is not the supplier's slug — for 38 of 200 entries they differ — and requesting the supplier's page with our slug returns HTTP 200 for a completely different game. Every upstream slug here is derived from the game's own embed URL, and every fetched page is rejected unless the name in its JSON-LD matches the registry title exactly. 190 of 190 passed; 0 were rejected. Fetching a real page under a deliberately wrong expected title was also tested, and the guard rejected it.

The detector-fires guard. A checker that never fires is not a checker. The property scanner was run against a document that definitely contains accessibilityControl (schema.org's own page for it — detected) and against one that definitely does not (example.com — not detected).

The negative control. Two of them, and one of them changed a number in this article. On itch.io, itch.io/games/zzz-fake-filter-xyzzy returns 404 — good. But itch.io/games/html5/zzz-not-real-xyzzy returns HTTP 200 with the full unfiltered game count. An unknown filter is silently ignored rather than rejected. So "the filter URL returns results" proves nothing there; only "the filter returns a count different from the unfiltered total" does. Every itch figure below passes that stricter test.

And one I got wrong and had to fix mid-run, recorded because the fix is the useful part. My first device detector looked for the literal strings wasd, arrow keys, keyboard and spacebar. It therefore scored these two control lists as naming no keyboard:

Hazmob FPS: Online Shooter  —  "W, A, S, D — move | Space — jump | Shift — run | C — crouch"
Driver Club: Highway Racing —  "W or up arrow — accelerate | S or down arrow — brake"

Both are obviously keyboard games. I found it by hand-reading the eight games the aggregate had flagged as odd, not by trusting the total. The corrected detector ships with a fixture set of 24 strings — 16 that must be detected and 8 that must not — and refuses to print numbers if any of them fails.

The field has existed the whole time

schema.org's accessibilityControl is defined as:

Identifies input methods that are sufficient to fully control the described resource.

It is a property of CreativeWork. VideoGame inherits from Game, which inherits from CreativeWork, so it is valid on every game page on the web with no extension, no vendor prefix and no negotiation.

The values come from a W3C community group vocabulary (current version dated 26 March 2026), and there are six:

Value	Meaning
`fullKeyboardControl`	Users can fully control the resource through keyboard input
`fullMouseControl`	…through mouse input
`fullTouchControl`	…through touch input
`fullSwitchControl`	…through switch input
`fullVoiceControl`	…through voice input
`fullVideoControl`	…through video input

Two of those six answer the question a player actually has. fullKeyboardControl means you will need a computer. fullTouchControl means your phone is enough.

Now compare how much the game vocabulary is used. These are schema.org's own published usage figures, from Google's web index, as printed on each term's page:

schema.org term	Domains using it
`aggregateRating`	1M – 10M
`genre`	100K – 1M
`VideoGame`	10K – 100K
`gamePlatform`	10K – 100K
`playMode`	10K – 100K
`numberOfPlayers`	10K – 100K
`accessibilityControl`	1K – 10K
`cheatCode`	< 1K
`gameTip`	< 1K
`quest`	< 1K

Ratings are published on somewhere between one hundred and one thousand times as many domains as the field for "can this person operate it". accessibilityControl sits one band above cheat codes.

200 pages, 200 ratings, 0 accessibility properties

I fetched every game page I could verify: 191 on Playgama (190 derived from our own catalogue's embed URLs, plus one more), 3 each on CrazyGames, Poki and Y8. Every page was confirmed to be a real game page before being counted, and every one was checked for all six accessibility properties plus accessMode and accessModeSufficient — searching the whole document, not just the JSON-LD, so microdata and RDFa would have been caught too.

Portal	Pages checked	With `aggregateRating`
Playgama	191	191
CrazyGames	3	3
Poki	3	3
Y8	3	3
Total	200	200

Three more portals returned unknown, not zero, and they are listed as unknown: Newgrounds would not respond to the fetch at all, and Armor Games and GameDistribution render their game links client-side so no game URL could be discovered from the homepage HTML. I would rather report three gaps than pad a round number.

The data isn't hidden. It was never collected.

The obvious next thought is that portals are dropping information the developer supplied. That is not what is happening, and this is the part that changes what a developer should do about it.

Every one of the 190 supplier pages has a How to Play section. All 190. That field is fully populated — somebody wrote prose for every single game.

Only 107 of those 190 sections name an input device anywhere in them. The other 83 describe the goal, the modes, the progression and the vibe, and never say what you press.

It gets sharper. Our catalogue holds no control text at all for 39 of 200 games. That has sat on our backlog as a data-entry job — go and fetch the missing controls. So I went and fetched them: 38 of those 39 have a live upstream page, all 38 have a How to Play section, and 3 of the 38 name an input device in it.

There is nothing to fetch. The gap is upstream, and no amount of effort on our side closes it. That reframes a backlog item as a supplier problem, which is a cheaper thing to know than to discover slowly.

The device flag is not a substitute, and it is only safe in one direction

Every supplier page carries availableOnDevice, and 182 of the 190 say Desktop, Mobile, Tablet. If that were trustworthy the whole problem would be solved.

It is not trustworthy in the affirmative. For 118 of those 182 games, the supplier's own How to Play section never mentions touch, tapping, swiping or an on-screen control. The same page asserts phone support and then explains the game entirely in keys. One of the two is wrong and the page gives you no way to tell which.

The negative direction held up perfectly, and that is genuinely useful:

`availableOnDevice` says	Pages	Documents touch	Has controls, names no touch	No control text at all
Desktop, Mobile, Tablet	182	71	74	37
Desktop only	8	0	7	1

Eight games are flagged desktop-only, and not one of them documents a touch control. Trust the "no". Never trust the "yes". That is the rule we use, and 190 pages is the largest sample we have tested it on.

Please also note what is not in this article: the star ratings. They are right there on every page, they would make the catalogue look busier, and copying a supplier's rating into your own markup is asserting that those reviews were left on your site. They were not.

Our own blind spot, which is worse in one specific way

None of the above lets us off. Here is our own catalogue, measured the same day:

200 entries. 161 have control text. 39 have none.
Of the 161, 39 more have control text that never names a device — flavour, objectives, scoring.
So 78 of 200 — 39% — tell a player nothing about what to hold, either way.
Where a device is named: keyboard 75, mouse 64, touch 74, gamepad 0.

And then the tags, which is the part I did not expect. The catalogue carries 182 distinct tags. Exactly two of them name an input device: mouse (19 games) and point and click (7 games). (A third, arrows, matched the detector and turned out to be about the puzzle pieces in Arrow Exit Puzzle. Hand-checked and discarded.)

There is no tag for a keyboard. There is no tag for touch. There is no tag for a gamepad.

Tags are what filters, related-game rails and internal search are built from. A vocabulary of 182 terms that can say beauty salon, backgammon and horde survival, and cannot say keyboard, is a vocabulary in which "show me games I can play on this phone" is not an expressible query. Not hard — impossible, until someone adds the word.

One platform does collect it, and the reason is not technical

itch.io asks developers to tick their game's input methods when they publish it. Not a free-text box: a list of 25 input methods, from Keyboard and Touchscreen down through Dance pad, Eye tracker, Gyroscope and Stylus. Every one is a browsable filter.

Measured today, browsable and countable by anyone:

itch.io, HTML5 games	Count
All HTML5 games	710,347
Declaring Keyboard	65,185
Declaring Mouse	54,464
Declaring Touchscreen	17,959
Declaring Gamepad (any)	8,680
Declaring Smartphone	6,491

Be honest about what that shows. 65,185 out of 710,347 is about 9%. Roughly nine in ten HTML5 games on itch.io still declare nothing about a keyboard, and touchscreen is declared on 2.5%. The field existing is not sufficient.

But 65,185 is not zero, and zero is what every other portal in this study returned. The difference is not technical — schema.org's field is free and universally valid, and itch's field is custom and non-standard. The difference is that one of them asks the person who knows. Nobody has to reverse-engineer the input method of a game whose developer ticked "Touchscreen" at upload time.

Three itch.io pages were sampled at random for this study alongside the other portals. None carried a schema.org accessibility property either — itch's input data lives in its own database and renders as a table row, not as markup a search engine can read. One of the three had an Inputs row filled in (Inputs: Keyboard). That is one more than the 200 pages on the other four portals managed between them, and it is also why the headline figure in this article says 200 rather than 203: I did not want a counter-example quietly padding a zero.

What we shipped today

Writing this without changing anything would have been cheap, so the generator that builds every SlowDen game page now emits accessibilityControl. 96 of 200 game pages carry it: 70 fullTouchControl and 26 fullKeyboardControl.

The other 104 emit nothing, and the rule for that is the interesting part.

The approved values assert that one input fully drives the game. A control list that names WASD and a mouse supports neither claim on its own, so those games get nothing. What we do emit:

fullKeyboardControl — the 26 games on a hand-verified list where every documented control is a keyboard key and no touch alternative appears anywhere in the text.
fullTouchControl — 70 games whose control list names a real touch input (tapping, swiping, dragging, an on-screen joystick) and which either names no keyboard at all, or also names a mobile device, which is the shape of a list documenting two complete schemes, one per device. All 26 borderline cases in that second group were read by hand before this shipped.

Mouse is deliberately not emitted, even for the games that look mouse-only. Keyboard false negatives are real — I produced two of them this morning — so "mouse only" is a verdict resting on the least reliable of the three detectors. Skipping it costs a handful of games and removes the one claim I could not defend.

A negation guard is in there too. It matches zero entries today. It exists because the next catalogue import might contain "not available on mobile", a sentence containing every word the accept rule looks for, and shipping fullTouchControl off the back of it would be a false accessibility claim — the one kind of error in that file that hurts a person rather than a ranking.

Why an incomplete answer is safe here, when an incomplete device flag is not. accessibilityControl is a positive claim. Saying a game is fully keyboard-controllable does not say it lacks touch. Missing data degrades to silence rather than to a lie. A boolean mobileReady has no such property — it is forced to answer, so it answers wrongly 118 times out of 182. That asymmetry is the whole reason a partial answer can be published at all.

We know this from experience, not theory. Our own entry for Basket Random (RHM Interactive) lists only keys — but the publisher's own public page documents Virtual Buttons: Jump and Throw (Mobile), a line our copy dropped. fullKeyboardControl on that game is still true. A mobileReady: false would have been false. We published a correction for that one two days ago and it is why the rule is shaped this way.

If you make browser games, five things

1. Name the device in the first line of your controls. Not "Move with WASD" — "Keyboard: move with WASD". Portals copy your prose verbatim into their How to Play field, and prose is the only channel that reliably survives the trip. 83 of 190 games in this study lost the information right here, at the source.

2. Put accessibilityControl on your own game page. Four lines, and yours becomes one of the few game pages on the web that answers the question in a form a machine can read:

{
  "@context": "https://schema.org",
  "@type": "VideoGame",
  "name": "Your Game",
  "accessibilityControl": ["fullKeyboardControl", "fullMouseControl"]
}

Only claim an input that genuinely drives the whole game. If a player needs both hands on two devices, say both — and if neither alone is enough, the honest move is the same one we made: say nothing.

3. Tick the boxes on the platforms that have them. itch.io's Inputs field takes about four seconds and puts your game into a filter that 90% of HTML5 games on the site are absent from. That is a discovery surface with almost no competition on it.

4. Write it into your submission text as well as your metadata form. Structured fields do not always propagate between platforms — the partner export our own catalogue is built from carries no developer field at all, which is why studio credits had to be read out of each game's public page one at a time. Prose propagates. Redundancy is the point.

5. Test it the way a stranger will. Unplug the keyboard and try to reach the main menu. Open it on a phone and see whether anything responds to a tap. Whatever you learn is more than any portal currently knows about your game.

Honest limits

Everything here counts documentation, not behaviour. No game was tested by playing it, and none is described as working or broken.
200 pages is a real sample, but three of the four portals contributed three pages each. Playgama at 191 pages is the deep result; CrazyGames, Poki, Y8 and itch.io are spot checks, and they are consistent with it rather than proof on their own.
Three portals — Newgrounds, Armor Games, GameDistribution — are unknown, not zero.
The itch.io counts are a live snapshot taken on 7 August 2026 and moved by six games while I was measuring them.
The 96 pages we now annotate are staged in our build, not yet live. slowden.com is deployed by hand and this ships on the next one. The claim "96 pages emit it" is verified against the generated files; the live site at the time of writing carries 0.
No keyword-demand tool is connected here, so nothing in this article says anything about search volume for any of it.

Where to go next

If you have a browser game finished, or nearly, submit it to SlowDen — it takes a form and a link, and a person reads every one. If you would rather have a constraint to build against, the current Slow Cook round closes on 31 August 2026: pick a challenge, build something small around it, and send it in. Selected entries may get a shoutout on SlowDen's social accounts and a chance to be featured. Nothing is guaranteed, and that is the honest version.

And when you write the page for it, tell people what to hold.

Two players, one keyboard: the multiplayer a phone cannot run

Liza Bhadana — Wed, 05 Aug 2026 15:43:34 +0000

Somewhere in your game there is a line that reads Player 1: WASD. Player 2: arrow keys.

It is the cheapest multiplayer anyone has ever shipped — no server, no netcode, no accounts, no matchmaking, no lobby that sits empty at 3am. One running copy of the game, one input device, two people.

It is also the only common game mode that a phone cannot run at all, because there is no keyboard to cut in half.

This article is about what that trade actually costs, measured across a real 200-game catalogue, and about a smaller, more annoying discovery: the part of your control text that explains the second player is the part most likely to never reach a player.

The short version: 13 of 200 games in our catalogue document two people on one device. 9 of those hand out two separate key sets with no touch alternative in our copy of the text. Exactly 1 of the 9 is filed under "2 Player". Nine control lists in the catalogue are cut off mid-sentence between 250 and 259 characters, and what the cut removes is the mobile section or the second player's keys. And when we checked one of the nine against its publisher's own public page, the mobile controls were there all along — our copy had dropped them. That last one is a correction to our own article from this morning.

What we measured, and what these numbers are not

Every number below is a count of documentation: the control text a developer or publisher wrote about their own game, as it sits in SlowDen's game registry, plus what the publisher's own public page says. It is not a count of behaviour.

No game in this article is described as broken, or as working. We cannot tell you that from where we are sitting, and it is worth saying why, because the reason is a trap other people will hit too. These games run inside a cross-origin frame, drawing to a WebGL canvas we cannot see into. Screen captures of that region come back solid black even when the game is running perfectly, and a script asking the host page how many canvases exist gets the answer zero, because the canvas is not in the host document. We learned that the expensive way. So when this article says a game "is documented as" something, that phrasing is doing real work, and it is the strongest claim the evidence supports.

Two other honest limits. The registry holds 200 games in our source, of which 120 are on the live site today — our deploys are a manual step and the source runs ahead. Every game named below is labelled live or staged. And this is one catalogue of partner games, not a survey of the web.

Finding 1: 13 games document two people on one device

Of the 200 entries, 155 carry a documented control list and 45 carry none at all. Reading all 155, sixteen entries describe a second player. They split three ways:

Group	Count	What the control text says
A. Two players, one keyboard	9	Two separate key sets, and no touch or mobile input mentioned anywhere in our copy of the text
B. Two players, touch documented	4	Two key sets and an on-screen or mobile path spelled out
C. A second player, no keys	3	"with a friend", "for one or two players" — and no input list at all

Group A is the interesting one. Here it is in full, with each game credited to its studio. All are Playgama partner titles; none was made by SlowDen.

Game	Studio	Category	On slowden.com
Basket Random	RHM Interactive	Sports	live
Soccer Random	RHM Interactive	Sports	live
Rolling Balls Sea Race	gameVgames	2 Player	live
Stickman Kombat 2D	Ernar (Tempo Play)	Funny	live
Kick Lucky Blocks Online	Cursora Labs	Block & Sandbox	live
Lucky Brainrot Blocks Online	Cursora Labs	Block & Sandbox	staged, not live
Escape School Duel	gameVgames	Block & Sandbox	staged, not live
Catch a Fish Obby	gameVgames	Block & Sandbox	staged, not live
GT Cars Mega Ramps	gameVgames	Racing	staged, not live

Five are live; the other four are in our source and not on the site yet, so they are named rather than linked to a page that would return a 404.

There is close to a standard here. Five of the nine document WASD for one player and the arrow keys for the other — a convention old enough to predate the browser as a games platform, and one that survives because it is the only way to give two people non-overlapping keys on a keyboard neither of them chose. Two more take the opposite route and reduce each player to a single key. That detail matters later.

Finding 2: local co-op is not in the "2 Player" category

If you were a player looking for something to play with the person next to you, you would open the 2 Player category. Here is what is actually in it.

On the live site the category holds 8 games, and 6 of the 8 are chess, checkers, backgammon or sudoku — turn-based board games, where "two player" means taking turns with one mouse or one finger, and where the second player is often the computer or an online opponent. 4 of the 8 carry no documented controls at all. Only Rolling Balls Sea Race is a simultaneous shared-keyboard game.

Meanwhile the nine games that genuinely need two people pressing keys at the same moment are scattered: 4 in block-and-sandbox, 2 in Sports, 1 in Racing, 1 in Funny, and 1 in 2 Player.

This is not anyone's mistake. A category describes what a game is about. Basket Random is about basketball; it is filed under Sports, correctly. The problem is that "how many people can play this, on what device" is a completely different axis from genre, and almost every browser-game portal — ours included — only has the genre one. A player who wants couch co-op has no way to ask for it, and a developer who built couch co-op has no way to say so.

Finding 3: the second player's keys are the first thing to get cut

While reading all 155 control lists, nine of them stopped mid-sentence with an ellipsis. Their lengths: 250, 253, 253, 254, 254, 256, 257, 258 and 259 characters. The longest control list in the catalogue that is not cut runs to 507 characters, so this is not a site-wide limit — it is something that happened to those nine entries on their way in.

What the cut removes is never random, because text has an order. Developers write the desktop keys first, then the second player, then the mobile section. So the truncation lands on exactly the two things this article is about:

What the ellipsis ate	Entries
The second player's key list	3
The mobile / touch section	6

Three concrete examples, quoted from our own registry exactly as they end:

stickman-kombat-2d   … Player 2: IJKL + : (colon) (attack), " (quote)…

gt-cars-mega-ramps   … Player2 Arrow keys = move  N = NOS  L = reset car position  U =…

animal-evolution-simulator
                     … Mouse wheel - zoom in/out of the camera  Smartphone controls: Left…

The third one is the clearest. A player on a phone reaches the words "Smartphone controls:" and then the sentence stops.

So we went and looked at where the text came from. The publisher's own public page for that game carries the whole thing, with no ellipsis anywhere: a Mobile section listing a left joystick to move, a jump button, an attack button, a swipe on the left side of the screen for the camera, and taps for buttons. The information was never missing. It exists, it is public, and our copy of it stops one word into the sentence that a phone player needs. The same is true of GT Cars Mega Ramps, whose publisher page carries a complete control description and a plain statement that its two-player mode is split-screen on one keyboard.

We have not seen the data payload in between, so we are not going to name a mechanism we did not observe. What is measured is this: the full text exists upstream, and the version we show is incomplete. That is our defect to fix, and the fix is on our list rather than in this paragraph pretending to be already done.

Finding 4: a correction to our own article from this morning

Earlier today we published an audit of touch support across this same catalogue, and it put these nine games in a group described as documenting no touch input. Tonight we checked that claim against a source we had not used: each game's own public page on the publisher's site.

One of the nine does document touch, and we were the ones losing it. Basket Random's publisher page lists three controls, not two:

W: Jump and Throw (Player 1)
Up Arrow: Jump and Throw (Player 2)
Virtual Buttons: Jump and Throw (Mobile)

Our registry entry for the same game carries the first two and not the third. Nothing was truncated here — the text is short and ends cleanly. It is simply a shorter rewrite that dropped the mobile line.

We checked the remaining eight the same way, reading the controls section of each publisher page by hand. Eight of the nine document no touch path upstream either, so the finding holds for those, and the one that does not has been corrected here and in the earlier article's record. Notably Soccer Random — the same studio, the same one-key-per-player design as Basket Random — carries no mobile line on its publisher page at all. We are not going to guess why two sibling games differ.

Why print this rather than quietly edit a number. The correction changes 9 to 8 on one row of one table. It is small. But a reader deciding whether to trust the rest of the measurements has no way to check them, and the only evidence we can offer is how we behave when we find one of our own numbers wrong within a day of publishing it. So: found, checked against a second source, corrected in public, cause named.

Finding 5: how much room two players would actually get

Say you decided to port a shared-keyboard game to touch. How much screen is there to work with? We measured the embed box on a live SlowDen game page — /games/basket-random/, one of the nine — at five viewport widths, using same-origin frames.

Viewport	Game box	Share of viewport area	Split side by side	Split top and bottom
360 × 740	301 × 188	21.2%	150 × 188 each	301 × 94 each
390 × 844	331 × 207	20.8%	166 × 207 each	331 × 104 each
412 × 915	353 × 221	20.6%	176 × 221 each	353 × 110 each
430 × 932	371 × 232	21.5%	186 × 232 each	371 × 116 each
768 × 1024	709 × 443	39.9%	354 × 443 each	709 × 222 each

The box holds at roughly a fifth of the screen's area across every phone width and roughly doubles on a tablet, which is what you would expect from a fixed aspect ratio inside a fixed page padding. We measured a different game page on a different run last time and got the same numbers to within a couple of pixels, which is how you know it is the template and not the game.

Now the useful part. WCAG 2.2 Success Criterion 2.5.8, Level AA, asks for pointer targets of at least 24 by 24 CSS pixels. A 166 by 207 half is nearly seven times that in each direction. So the question is never "is there room for a button". It is how many buttons each player needs:

One input per player — Basket Random and Soccer Random both give each player a single key that jumps, blocks and shoots. Each player's half becomes one enormous tap zone. This is a small change, not a rewrite.
Two or three inputs per player — still workable in a 166 by 207 half, if you are willing to design rather than decorate.
Move, jump, sprint, interact, camera, plus a shop and an inventory — which is what four of the nine actually document. Two of those side by side on a phone is not a layout problem you can solve with a smaller button.

The pattern worth noticing: the games that would be easiest to port are the ones already closest to it. A one-button-per-player design is not a limitation to apologise for. It is the thing that makes two people on one phone a real possibility instead of a joke.

And then there is what our own page says

Here is the live page for Basket Random today, quoted exactly. It opens with:

Play Basket Random free online on SlowDen — no download, no sign-up.
Press play and enjoy this Sports browser game instantly.

Then, under "How to play":

2. Click or tap inside the game window to start.
3. Follow the in-game prompts — controls are listed below.

Controls
• Player 1: W   Player 2: UP ARROW

So the page tells a visitor to tap, and then tells them the game needs two people at a keyboard. Across the five live pages in group A, the word "touch" and the words "swipe", "joystick" and "on-screen" appear zero times, on any of them. The word "instantly" appears four times in each page's HTML.

That is our template, on our site, and it is the least flattering paragraph in this article, which is the main reason it is here. The replacement is written and sitting in our source, unshipped, because our deploys are manual and the site is frozen this month. It reads:

⌨ Two players, one keyboard

Built for a keyboard — and for two people at one. Basket Random is
documented as two players sharing a single keyboard, so it is made for
a computer rather than one phone. No touch alternative is listed.
That is what its control list says, not a test result.

We are not claiming credit for a fix a visitor cannot see yet. As of the time this was published, the live page still reads the way it is quoted above.

Six things worth doing

In rough order of how much they return for the effort.

Write the device answer first in your controls text. Not last. Every downstream system that reformats, shortens or truncates your description cuts from the end, and we have nine measured examples where the end was the mobile section or the second player. A first line reading "Two players, one keyboard — desktop only" survives everything.
If your game has one action per player, ship touch. You are one pair of tap zones away. Split the canvas down the middle, treat a tap on either half as that player's key, and leave the keyboard bindings in place for desktop. It is the single cheapest way to turn a desktop-only game into one that works on the device half your visitors are holding.
Say when two-player is desktop-only, on the page, in words. One game in our catalogue does this and it is the best-documented entry we found: "On Mobile Devices: Only 1 Player mode is enabled on mobile devices. Tap left and right on the screen to move." (Snow Rush 3D, by gameVgames — in our source, not yet on the live site.) A player who reads that is never disappointed. Compare it to a page that just says "tap to start".
Make single-player complete on touch, and let co-op be the extra. This is the version of the trade that costs you nothing. The mistake is not building shared-keyboard co-op — it is building it as the only way in.
Document desktop and mobile as two separate lists, not one blended paragraph. The clearest entry in our whole catalogue does exactly that: Master Chess (CodeThisLab) lists click a piece / click a square for desktop and tap a piece / tap a square for mobile, as four separate lines. It takes thirty seconds to write and it answers the only question a phone player has.
Do not rely on a category to communicate your input model. Genre and device are different axes, and portals mostly only have the genre one. Put it in your own text, where it travels with the game.

Where the numbers came from, and what they cannot tell you

All figures measured on 5 August 2026, in Chrome on Windows.
The catalogue audit reads the game registry directly. 200 entries in source, 120 live; 155 with a control list, 45 without.
The regex used to find candidate entries produced one false positive, which is worth naming because it is the kind that looks like a finding: the pattern friend matched the ordinary phrase "user-friendly" and pulled in an entry that mentions no second player at all. Every one of the sixteen was read by hand before it was counted, and the hand count is what is published.
Publisher pages were read directly for the nine group-A games plus two of the truncated entries. Only the controls section of each was used.
Geometry was measured on a live page in same-origin frames at five viewport sizes. These are layout measurements at phone widths, not tests on phone hardware — the machine reports zero touch points, so no claim here is based on a real touch device.
The accessibility figure is from the W3C recommendation, read this run. No other platform guideline is quoted, because the two we tried to verify would not render their own text to a fetch, and an unverified number is worse than a missing one.
What this cannot tell you: whether any specific game plays well, or at all, with two people or one, on any device. Documentation is not behaviour. Nothing here is a review.

If you make browser games

SlowDen lists browser games and takes submissions from developers. If you have a playable web build you can send it to us — and if two people need to share a keyboard for it, say so, because we would rather put that on the page than let someone find out on a bus.

Slow Cook is our creative challenge for developers: pick a challenge, build a small game around it, and 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.

Why your browser game is unplayable on a phone

Liza Bhadana — Tue, 04 Aug 2026 19:00:50 +0000

There is a specific way a web game fails that almost never shows up in a bug report, because the person who hit it did not think of it as a bug. They opened your game on a phone, tapped where the page told them to tap, and then found that the thing they were holding could not send the inputs your game was waiting for. They did not complain. They left.

This article measures how often that happens across a real catalogue of 200 HTML5 games, and what the page around the game does to make it worse.

The short version

We audited the developer-written control list of every game in our catalogue. Of the 155 that have one, 68 never mention touch, tapping, swiping or a phone at all, and 26 name a keyboard key as the movement control with no touch alternative — nine of those expect two people sharing one keyboard.

Meanwhile the page around the game says the opposite. On all 14 live pages for those keyboard-driven games, the copy invites the player to tap, all 14 then list a keyboard key, and none of the 14 mentions touch anywhere. And the box any on-screen controls would have to fit into measured 331 by 207 CSS pixels.

What we measured, and what these numbers are not

Everything below was measured on 5 August 2026, in Chrome on Windows, against live pages on slowden.com and against our own game registry. We are the portal in this article. That is deliberate: the interesting data here belongs to whoever runs the host page, and it is easier to publish honestly when the unflattering findings are your own.

Two separate sources, measured two different ways.

The catalogue audit. Our registry holds 200 games, of which 120 are live on the site today. Each entry can carry a controls list, transcribed from that game's own public page on Playgama, the partner catalogue SlowDen lists through. 155 entries have one; 45 have none. These are the developers' and publisher's words, not ours.

The live page measurements. Geometry was measured by loading live pages into a same-origin frame of an exact viewport size and reading real bounding boxes. Computed styles, iframe attributes and page copy were read from the live documents.

The most important caveat, stated before the numbers rather than after them: the audit measures documentation, not games. A game may accept touch perfectly well and simply not say so. Another may say so and handle it badly. Nothing here is a claim about whether any specific game works on your phone. What it does measure is what a player can find out before they commit — and that is its own problem, because a player deciding whether to start has nothing to go on except the page.

We also corrected ourselves twice while doing this, and both corrections are worth knowing if you run the same audit. Our first keyword pass classified Smartphone controls: as having no phone mention, because a word-boundary match on "phone" does not match inside "Smartphone". It also counted the ordinary English word "space" — as in "free up space in the warehouse" — as the space bar. The load-bearing figure below is therefore a list of entries read by hand, not a regular expression's output, and five entries are excluded with a written reason each.

Finding 1: 68 of 155 control lists never mention touch

Here is the whole catalogue, split by what the developer wrote about input.

Group	Count	Share of the 155 with a list
Documents some touch or phone input path	87	56.1%
… of which names an on-screen or virtual control	23	—
… of which splits "Desktop:" from "Mobile:" explicitly	30	—
Mentions no touch input of any kind	68	43.9%
… of which names a keyboard key as the movement control (hand-verified)	26	16.8%
Has no control list at all	45	of 200 entries

The 87 in the first row are the good news, and the shape of the good news is worth copying. Thirty of them do the single most useful thing a control list can do: they write two labelled sections, one for desktop and one for phones. "Desktop: the snake turns with the cursor. Mobile: use the joystick to rotate the snake." That is Snake 2048 by TurtleGamesStudio, and it takes eleven extra words to tell a phone player that the game is for them.

The 45 entries with no list at all are a quieter version of the same problem. A player on a phone gets nothing: not a control scheme, not a warning, not a "works best on desktop". They find out by starting.

Finding 2: 26 games hand the player a keyboard, and nine hand out two

This is the group where the absence of a touch path is not a documentation gap but a wall. Twenty-six control lists name a keyboard key as the way you move, and mention no alternative. Fourteen of those games are live on the site today; twelve are in the catalogue but not yet published.

A phone has no W, no A, no S, no D. It has no shift key to sprint with, no space bar to jump with, and no separate left and right mouse buttons to shoot and aim with. If a game's only documented path through its first thirty seconds runs through those, then for a phone player there is no path.

The concentration by genre is not random.

Category	Keyboard-driven, no touch listed	Entries with a control list
Horror	7	16
Block & Sandbox	6	23
Racing	4	18
Sports	3	16
.io Games	2	10
Funny	1	21
Shooting	1	16
For Girls	1	12
2 Player	1	5
Puzzle	0	18

Puzzle games score zero, and that is the useful signal in the table rather than an accident. A puzzle is usually driven by pointing at a thing, and a tap is a point. First-person horror and 3D sandbox games are driven by simultaneous movement plus a look direction plus an action, which is four fingers' worth of intent on a surface that has room for two thumbs.

The nine that cannot be ported at all as designed

Nine of the 26 are two-players-on-one-keyboard games. Stickman Kombat 2D by Ernar (Tempo Play) gives Player 1 WASD plus F and G, and Player 2 IJKL plus a colon and a quote key. Escape School Duel and Catch a Fish Obby, both by gameVgames, split the board the same way. Soccer Random and Basket Random by RHM Interactive are the elegant extreme: one key each, W for Player 1 and the up arrow for Player 2.

These are not games that need touch controls added. The mode is two people at one keyboard, and a phone has one screen roughly the size of two hands. Same-device local multiplayer is genuinely one of the nicest things a browser game can do, and it is one of the few designs where "this one is for desktop" is a legitimate answer — provided somebody says so on the page. Nobody does.

Finding 3: the page says tap, then lists the keys

This is our fault, not a developer's, and it is the finding that made this article worth writing.

We fetched the live page for all 14 of those keyboard-driven games that are published today. All 14 returned HTTP 200. Then we read what each page tells a player.

What the live page does	Pages
Invites the player to tap	14 of 14
Carries a Controls section	14 of 14
Names a keyboard key in it	14 of 14
Mentions touch, swipe, joystick, mobile or phone anywhere	0 of 14

Take Moto X3M by MadPuffers, a Racing game and one of the 14. The page says: "Wait for Moto X3M to finish loading in the player above. Click or tap inside the game window to start. Follow the in-game prompts — controls are listed below." Below it, the controls are: WASD or arrows, up arrow to accelerate, left and right to balance, down arrow to brake.

So the page invites a tap, and then describes a game played with four keys. A player who followed the instruction exactly did the right thing and still ended up stuck. Nothing on that page is a lie in isolation; the combination is the defect. It is generated from one template, so it is the same defect 14 times.

If you list your game on any portal, this is worth knowing for a blunt reason: the host's page copy will be written by a template that has never read your control scheme. Whatever your game needs, assume the page will not say it. The only place a phone player can reliably be told is inside your game's own first frame.

Finding 4: the box your on-screen controls have to fit into

Suppose a developer does the right thing and adds touch controls. How much room do they get? We measured the same live game page at five widths by loading it into a same-origin frame at each exact size.

Viewport (CSS px)	Game box	Box area	Share of viewport area	Page above the box
360 × 740	301 × 188	56,550 px2	21.2%	283 px
390 × 844	331 × 207	68,558 px2	20.8%	283 px
412 × 915	353 × 221	77,792 px2	20.6%	259 px
430 × 932	371 × 232	86,118 px2	21.5%	259 px
768 × 1024	707 × 442	312,494 px2	39.7%	237 px

Across every phone width the answer is remarkably stable: the game gets about one fifth of the screen. The box is width-driven with a fixed aspect ratio, so it scales with the page rather than with the space available, and the share barely moves between a small Android phone and a large iPhone.

The starker number is the page rather than the screen. At 390 by 844, the full document is 4,086 CSS pixels tall — 4.8 screenfuls — with 283 pixels of page above the game and 3,596 pixels below it. Your game is 5.07% of the height of the page it lives on.

What that means for a virtual joystick

WCAG 2.2 Success Criterion 2.5.8, Target Size (Minimum), Level AA, requires that "the size of the target for pointer inputs is at least 24 by 24 CSS pixels". That is an accessibility floor for any tappable target, not a size anyone would choose for a control held down mid-action. Using it as a floor, and counting the distinct inputs each control list names by hand:

Game (studio)	Distinct inputs named	At the 24 × 24 floor	Share of a 331 × 207 box
Moto X3M (MadPuffers)	4	2,304 px2	3.4%
The Tall Man (Sleepless Games)	6	3,456 px2	5.0%
Escape from the Portal (Mirra Games)	12	6,912 px2	10.1%
Grand Shift Auto (oneru220)	15	8,640 px2	12.6%
Hazmob FPS: Online Shooter (Hazmob)	19	10,944 px2	16.0%

Read that table the pessimistic way round. Those percentages are the best possible case — controls shrunk to the smallest size an accessibility standard will tolerate, packed with no gaps, and every one of those pixels still sitting on top of the game the player is trying to see.

Width is the tighter constraint than area, and this next line is an illustration rather than a measurement, because we have no measured figure for a comfortable thumb zone: if you allow two 120-pixel zones for two thumbs, that is 240 of the box's 331 pixels of width and 120 of its 207 pixels of height. The controls stop being an overlay on the game and become most of it.

The conclusion we draw is not "draw smaller buttons". It is that a game with nineteen inputs does not become a touch game by growing nineteen buttons. The games that survive the move are redesigned down to one or two simultaneous inputs, which is a design decision made early and cheaply, or very late and expensively.

Finding 5: nothing on the page is protecting your gestures

Say the controls fit. There is one more thing between a swipe and your game, and it is the default behaviour of the browser.

MDN's reference for the CSS touch-action property puts it plainly: the initial value is auto, and "by default, panning (scrolling) and pinching gestures are handled exclusively by the browser". Setting touch-action: none is what hands those gestures to the page instead.

We read the computed touch-action of every element on a live game page. The count of elements restricting touch gestures in any way was zero. The root element, the body, the embed container and the frame itself are all auto. And directly below that container sits 3,596 pixels of scrollable page.

So a vertical drag that starts on the game and is not claimed by the game is a drag the browser is entitled to read as a scroll — and the page will happily oblige by moving the game off the screen.

This one you have to fix yourself, and that is not a complaint about hosts. A portal cannot reach inside a cross-origin frame to set touch-action on your canvas — the isolation that stops a host reading your game also stops it helping. So the responsibility genuinely is the developer's. Two lines:

/* in your game, on whatever surface receives play input */
canvas, .game-surface { touch-action: none; }

// and register listeners so preventDefault is actually allowed
el.addEventListener('touchstart', onTouch, { passive: false });
el.addEventListener('touchmove',  onMove,  { passive: false });

Chrome treats touchstart and touchmove listeners on the document as passive by default, which means preventDefault() inside them is ignored unless you opt out explicitly. A game that calls preventDefault() and still gets scrolled is usually hitting exactly this.

For completeness, the host side of this particular page is not doing anything hostile: the frame carries allowfullscreen and an allow attribute with four tokens including fullscreen, and there is no sandbox attribute. The one genuinely mobile-friendly control on the page is a Play full screen link measuring 170 by 44 CSS pixels, which comfortably clears the 24-pixel floor and does sit above the fold at 390 by 844. It opens the game in a new tab rather than calling the Fullscreen API — requestFullscreen appears nowhere in the page's source — but for a phone player the practical effect is the right one: the game gets the whole tab instead of a fifth of the screen. It is also, by some distance, the least prominent thing on the page.

The counter-example, and it is not one of ours either

The Cube is the open-source Rubik's-cube project by Boris Sehovac (bsehovac/the-cube, built with Three.js; no licence is stated in the repository, so we host it with credit and link the source). It is not a SlowDen game and we do not claim it. It is here because it gets everything in this article right by construction.

We read its whole game file — js.js, 101,851 bytes, re-fetched with cache: 'no-store' — and counted its input handling.

Handler	Occurrences
`touchstart` / `touchmove` / `touchend`	4 / 4 / 2
`mousedown` / `mousemove` / `mouseup`	3 / 2 / 2
`keydown`	0
Reads `touches` and `changedTouches`	yes

Zero keyboard handlers. Both pointer paths bound, in parallel, with the touch path reading real touch lists rather than hoping a mouse event will be synthesised for it. Its opening prompt is Double tap to start — an instruction that is true on a phone and true on a laptop, which is a harder thing to write than it looks.

And because it is self-hosted rather than embedded, its page is the game: the canvas measured 1,536 by 695, the document height equals the viewport height exactly, the body has overflow: hidden, and the page is not scrollable. There is no page below it to scroll to. The same game inside a portal embed would have got about a fifth of the screen and 3,596 pixels of page underneath it.

That contrast is the whole argument in one comparison. Nothing about touch support requires a big screen. It requires that somebody decided which inputs the game has before deciding how many buttons to draw.

Eight things to change, roughly in order of payoff

Open your build on an actual phone and finish the first thirty seconds without a keyboard. Not a narrow desktop window — that still delivers key events and a mouse. If you cannot get through the first level, neither can a fifth of the people who find you.
Count your inputs, then cut. Write down every distinct action your first level needs. If the list is longer than two simultaneous inputs, the phone version is a redesign, not a control overlay. Deciding that in week one is cheap.
Set touch-action: none on your play surface and register touch listeners with { passive: false }. Otherwise the browser keeps the pan gesture and the host page scrolls out from under your player.
Handle pointer events, not mouse events. A single pointerdown / pointermove path covers mouse, touch and pen. If you prefer explicit touch handlers, bind both and read changedTouches rather than assuming a synthesised mouse event will arrive.
Design your first frame for 331 by 207 CSS pixels. Not as a stretch goal — as the default. Set your editor to that size once and look at your title screen in it. Most title screens do not survive the experience, and it is better to find that out yourself.
Say what the game needs, inside the game. One line on the title screen: "drag to steer, tap to jump", or honestly, "this one needs a keyboard". Do not rely on the host page — we have just shown ours saying the opposite 14 times.
Make every target at least 24 by 24 CSS pixels, and much larger for anything held down. The 24-pixel figure is WCAG 2.2's minimum, not a target.
If your game really is desktop-only, say so proudly rather than quietly. Two players sharing one keyboard is a genuinely good design. It just needs a label, so a phone player finds out before they start rather than after.

Run this on your own listing

Paste this into the console on any portal page that embeds your game. It reports the geometry your game actually gets and whether anything on the page is reserving touch gestures for it.

(() => {
  const f = document.querySelector('iframe');
  if (!f) return console.log('no iframe on this page');
  const r  = f.getBoundingClientRect();
  const vw = innerWidth, vh = innerHeight;
  const doc = document.documentElement.scrollHeight;
  const restricted = [...document.querySelectorAll('*')]
    .filter(e => getComputedStyle(e).touchAction !== 'auto').length;
  console.table({
    'viewport':                 vw + ' x ' + vh,
    'your frame':               Math.round(r.width) + ' x ' + Math.round(r.height),
    'frame area':               Math.round(r.width * r.height) + ' px2',
    '% of viewport area':       ((r.width * r.height) / (vw * vh) * 100).toFixed(1) + '%',
    'page above the frame':     Math.round(r.top) + ' px',
    'page below the frame':     Math.round(doc - r.bottom) + ' px',
    'frame as % of page':       ((r.height / doc) * 100).toFixed(2) + '%',
    'elements reserving touch': restricted,
    'allowfullscreen':          f.hasAttribute('allowfullscreen'),
    'sandboxed':                f.hasAttribute('sandbox')
  });
})();

If elements reserving touch comes back as 0 and page below the frame is in the thousands, then a swipe your game does not claim will scroll your game off the screen. That is the host's layout and your touch-action, together.

Two ways this measurement tried to fool us

Both worth knowing if you automate any of this, because both produced a confident wrong answer.

A hidden element that every DOM check called visible. We tried to test whether The Cube starts from touch input by watching its Double tap to start prompt disappear. After a real double-click the prompt was plainly gone from the screen — and every programmatic check still reported it present. Its computed display was block, its visibility was visible, checkVisibility() returned true, and innerText still contained the string. The element was faded to opacity: 0.000107. Only the rendered pixels told the truth. If you are asserting on game state from the DOM, assert on something the game sets, never on whether text looks gone.

Synthetic events did not drive the game, and the control proved it. Our dispatched TouchEvent pairs did nothing. That looks like evidence the game ignores touch — until you run the control, which we did: synthetic MouseEvent pairs did nothing either, on the canvas and on the document, while a real trusted double-click started the game immediately. So the failure was our dispatch method, not the game's input handling. The touch test is therefore inconclusive and we are reporting it as inconclusive. The reliable evidence for The Cube's touch support is the handler count read out of its source, above — not our test.

A negative result from an automated harness is worth roughly nothing without a positive control run the same way.

Where these numbers came from, and their limits

Documentation, not games. Said once more because it bounds everything: the 87 / 68 / 26 split describes what developers wrote about their controls. It is not a test of any game, and no game named here is being called broken.
The 26 is a hand-read list, and its judgement calls are written down. Five entries were deliberately excluded, each with a reason — one control list is actually an FAQ that names no input at all; one says "click on the arrows", where the arrows are objects in the puzzle rather than keys; three are click-driven with a key as a secondary extra, so a tap substitutes.
Phone rows are layout measurements, not device tests. A same-origin frame at 390 by 844 gives real CSS-pixel geometry, but no mobile user agent, no device pixel ratio, no collapsing address bar and no real finger. Treat them as the layout a phone would get, not as a device report.
Source versus live, labelled. The registry holds 200 entries; 120 are live on the site today. Of the 26 keyboard-driven games, 14 are live and 12 are not yet published. The 14-of-14 page-copy finding was measured against live pages only.
One browser. Chrome on Windows. Safari in particular handles touch defaults and viewport units differently; do not assume these figures transfer without testing.
The 120-pixel thumb zone is an illustration, not a measurement, and is labelled as such where it appears. The 24-by-24 figure is not an illustration — it is quoted from WCAG 2.2 SC 2.5.8.
Credits. Every game named is credited to its studio as recorded on its own public listing. All of them are partner titles listed on SlowDen through Playgama; none was made by SlowDen. The Cube is by Boris Sehovac, open source, self-hosted with credit and a link to the repository. Playgama, Chrome, Three.js, W3C and MDN are named for accuracy only; no affiliation or endorsement is implied.

If you make browser games

SlowDen lists browser games and takes submissions from developers. If you have a playable web build, you can send it to us — and if it needs a keyboard, tell us, because we would rather write that on the page than let a player find out.

Why players leave before your game starts

Liza Bhadana — Mon, 03 Aug 2026 10:33:56 +0000

Your game is listed on a portal. The page gets visits. The play count does not move.

It is tempting to read that as a verdict on the game — but nobody who left ever played it. Whatever they rejected, they rejected before the game started.

This article measures that window on a live portal, in numbers.

The short version. On a portal, the first ten seconds of your game are not yours. The host's CSS decides how large your game is. The host's page decides how much of it is on screen. Your own first frame decides whether either of those mattered. I measured all three on a live site — ours — and found a game box 330 by 205 pixels on a phone, several seconds of black rectangle before anything was drawn, and a start button that landed at the bottom edge of a laptop viewport.

What I measured, and on what

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 rather 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.

Finding 1: the box is much smaller than you are designing for

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.

Viewport (CSS px)	Game box	Box height vs viewport	Visible without scrolling	Page above the game
360 × 740	299 × 186	25%	100%	284 px
390 × 844	330 × 205	24%	100%	260 px
412 × 915	351 × 219	24%	100%	260 px
768 × 1024	707 × 441	43%	100%	238 px
1366 × 768	1054 × 658	86%	79%	251 px
1536 × 695	1054 × 658	95%	67%	251 px
1920 × 1080	1054 × 658	61%	100%	251 px

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.

The design rule this implies. Your first frame has to work in a landscape box roughly 300 pixels wide, and it has to put anything important in the upper middle, because the bottom third may not be on screen. That is a much tighter brief than the one most title screens are designed to.

Finding 2: for the first several seconds the player sees a black rectangle

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

Moment	Time from navigation start
Host page HTML finished arriving (13,371 bytes decoded)	154 ms
Web fonts finished (5 requests, 98 KB)	323 ms
Host page DOM complete	323 ms
Game frame's document finished arriving	1,260 ms
Host page load event	1,264 ms

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. I 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.

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.

Finding 3: your start button is not where you think it is

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.

What we changed on our side. Publishing this without saying what we did with it would be cheap. Our game pages now paint their own thumbnail and a real play button immediately, and create the game frame only when someone clicks it, so the page can never again show a black box with no control on it. That change is in our source and is not deployed as of this article's publication date — the pages measured above are still live in the state described. I am not going to pretend otherwise.

Finding 4: the page around your game spends the budget first

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; the 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.

A counter-example, on the same site

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.

File	Bytes (decoded, re-fetched with no-store)
index.html	7,144
style.css	35,932
js.js (the whole game)	101,851
three.min.js (from a CDN)	646,271
Total	791,198 ≈ 773 KB

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.

Seven things to do about it

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.
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.
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.
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.
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.
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.
Re-test after every portal listing. The container is the host's and it can change without telling you.

Test your own game in ten minutes

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.

Where these numbers came from

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. I 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 me. The game frame is cross-origin, so I 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 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.

If you make browser games

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.

Related, if this was useful: Why your browser game loads to a black screen takes the same failure apart from inside one game, with a 203 MB preload queue. And Which browser-game portals actually have players on them covers where to list once the first ten seconds work.

Written for the SlowDen blog: https://slowden.com/blog/

Why your browser game loads to a black screen

Liza Bhadana — Fri, 31 Jul 2026 13:50:10 +0000

Here is a failure that almost nobody catches before shipping, because it does not look like a failure from the inside. Your game works perfectly on your machine. Every file returns 200. There is not a single error in the console. And a player who opens the link sits in front of a black rectangle for the better part of a minute, decides the site is broken, and closes the tab.

The short version. A blank canvas with no errors is almost never a crash. It is a game that is still loading, in a framework that draws nothing until loading finishes. We took apart one of our own games to show exactly how a project ends up there — 203 MB of art queued in front of 38 KB of game — and what to measure in your own build to make sure it hasn't happened to you.

Why we're using our own game as the example

It would be easy to write this article about somebody else's game. It would also be worthless, because you would have no way of checking any of it.

So the example here is Pastanation, a pixel-art pasta-cooking game built by SlowDen in Phaser. It is one of our own projects, it is live at slowden.com/games/pastanation/, and it currently has exactly the problem this article is about. If you open it, expect a long wait on a blank screen before anything appears — that is the bug, not a surprise. Every number below came from measuring that live page and the files it serves, on 31 July 2026, and you can re-measure all of them yourself.

Writing this up is more useful than quietly fixing it, because the shape of the mistake is extremely common and almost invisible while you are making it.

What "no errors" actually tells you

Here is the state of that page when a player loads it:

Every asset request returns HTTP 200. Nothing is missing, nothing is 404ing, nothing is blocked.
The console contains zero errors — just Phaser's own version banner.
A 1920×1280 canvas is created and attached to the page exactly as intended.
The player sees black.

This is the trap. Every diagnostic that a developer instinctively reaches for — the console, the error log, the network panel's red rows — reports that everything is fine. A green network tab is not evidence that your game works. It is only evidence that your files exist.

What none of those tools shout at you is the number that actually matters: how many bytes must arrive before the first frame renders?

The measurement: 203 MB of art in front of a 38 KB game

Pastanation is 162 files and 203.7 MB in total. Broken down by what those bytes are:

What it is	Size	Share of total
The game's own code — every scene, every interaction, the whole design	38 KB	0.02%
The Phaser engine bundle	1.13 MB	0.6%
Sound effects and music	9.1 MB	4.5%
Art (PNG backgrounds, sprite sheets, props)	~193 MB	~95%

Read the first row again. The entire game — every scene, every drag interaction, every line of logic — is 38 KB. The art in front of it is roughly five thousand times larger. That ratio is the whole story, and it is not unusual. It is what happens when art is exported at source resolution and dropped straight into an assets folder, which is the default behaviour of every art pipeline unless someone deliberately intervenes.

The individual files show where it went:

File	Dimensions	Size	The problem
`grandma.png`	3375×3375 RGBA	6.92 MB	A 9-frame sprite sheet at 1125×1125 per frame
`grandma-blinking.png`	3375×3375 RGBA	6.15 MB	A second sheet of the same character
`bg.png`	2688×1792 RGB	6.18 MB	A photographic background stored losslessly
`level-1-bg.png`	2688×1792 RGB	5.33 MB	Same again
`bgm.mp3`	—	4.91 MB	Full-length music loaded up front

Two things are worth pulling out of that table.

The backgrounds are bigger than the screen they are drawn on. They are 2688×1792. The game canvas is 1920×1280, and on a normal desktop browser window it is displayed at around 1094×730. So roughly five times more pixels are being downloaded than are ever shown. Nobody decided this; it is just the size the file came out of the art tool.

PNG is the wrong format for most of this. PNG is lossless, which is exactly right for crisp pixel art at its native size and exactly wrong for a 2688×1792 painted background. Those two backgrounds have no transparency at all — they are stored as RGB — so nothing is gained by keeping them lossless.

The bit that actually causes the black screen

203 MB is bad, but on its own it would not produce a blank screen, because a well-built game only loads what the current scene needs. The black screen comes from where the bytes sit.

Pastanation's preloader queues eleven things before it hands over to the menu. Nine of them are small. Three are not:

Queued in the preloader	Size
`grandma.png` sprite sheet	6.92 MB
`grandma-blinking.png` sprite sheet	6.15 MB
`bgm.mp3` background music	4.91 MB
Eight other sounds and icons	~4 MB
Total before the first frame	20.9 MB

That 20.9 MB has to arrive in full before the loader's completion callback runs and the first scene draws anything. On a 25 Mbps connection that is about 7 seconds; on a 10 Mbps connection, about 18 seconds; on a mid-range mobile connection, considerably longer. (That's just arithmetic on the byte count — real-world times are worse once you add decode and decompression.)

And here is the part that turns a slow load into a lost player. The preloader contains no progress handler at all — nothing hooked to the loader's progress event, no bar, no spinner, no percentage, not even a "Loading…" label. There is nothing to draw the loading UI with, because the assets that would draw it are stuck in the same queue as everything else.

So the player gets the worst possible combination: a long wait, and no evidence that anything is happening.

The general rule. Your loading screen must be built from assets that are already loaded. If your progress bar is waiting in the same queue it is meant to be reporting on, you do not have a progress bar — you have a black screen with good intentions.

The one that catches people on mobile: texture memory

File size is the number everyone looks at. It is not the number that crashes phones.

Once an image is decoded and uploaded to the GPU, an uncompressed RGBA texture occupies width × height × 4 bytes of video memory, no matter how well it compressed on disk. So:

3375 × 3375 × 4 bytes = 45,562,500 bytes ≈ 43 MB

That 6.92 MB PNG becomes roughly 43 MB of texture memory. The second sprite sheet is another 43 MB. Before the menu has drawn a single pixel, the game is asking for something in the region of 86 MB of GPU memory for two pictures of the same character.

On a desktop this is merely wasteful. On a budget phone it is how you get a silent tab crash that never appears in anyone's error log, because the browser kills the page rather than reporting an exception.

How to check your own game in ten minutes

None of this needs special tooling. Six steps, in order of how much they'll tell you:

Measure the folder. Before anything clever, just look at the total size of your build directory. du -sh build/ on macOS or Linux; right-click → Properties on Windows. If that number surprises you, stop and read it properly. Ours did.
Sort your assets by size, largest first. Almost always, a handful of files are most of the problem. find . -type f -printf "%s\t%p\n" | sort -nr | head -20 is enough.
Throttle your network and watch it like a stranger. Open DevTools → Network, set throttling to "Fast 3G", hard-reload, and do not touch anything. Watch the clock. Whatever you see in the first ten seconds is what a real player's first impression is.
Find the number that matters: total transferred before your first frame renders. That is the only load figure worth optimising against.
Check your preloader draws something immediately. Does a bar appear in the first second? If not, that is your highest-value fix, and it is usually an hour's work.
Open it on a real phone, on mobile data, not on your desk wifi. This is the step everyone skips and the one that finds the most.

What actually fixes it

In rough order of effort-to-payoff:

1. Show a loading bar, built from already-loaded assets

Cheapest fix, biggest perceived improvement. Have a tiny first scene that loads one small logo, draws the loading UI, and only then queues the real assets while hooking the loader's progress event. Every major framework exposes this — in Phaser it's this.load.on('progress', ...). A moving bar buys you an enormous amount of patience.

2. Resize art to the size it is actually displayed at

Free, and often the single biggest win. If your canvas is 1920×1280, a 2688×1792 background is pure waste. Export at the size you draw it, allowing a sensible margin for high-DPI screens — not five times over.

3. Stop shipping painted artwork as PNG

Keep PNG for crisp pixel art at native resolution. For painted or photographic backgrounds, WebP or AVIF will typically be a fraction of the size at a quality difference nobody can see in a moving game. Keep transparency where you genuinely need it — RGBA costs a third more memory than RGB, and plenty of "transparent" assets don't have a transparent pixel in them.

4. Load per scene, not all at once

The menu does not need the level's artwork. Load what the current scene needs, and fetch the next scene's assets while the player is reading the menu. This alone can take a first-load figure from tens of megabytes to a couple.

5. Pack sprites into an atlas

A grid sprite sheet exported at source resolution wastes both bytes and texture memory on empty space. A proper texture atlas packs frames tightly and ships a small JSON map alongside.

6. Stream long audio, don't preload it

A five-megabyte music loop does not need to be fully downloaded before the title screen appears. Load the short effects up front and stream the music.

The other way a game looks fine and isn't

Since we're being straight about our own site: there is a second failure on SlowDen right now, and it has the same shape — everything returns 200 and nothing works.

Most of the games listed on SlowDen are third-party titles embedded from an external provider. As of 31 July 2026 those embeds are being refused at the provider's end because slowden.com isn't registered with them as a publisher domain, so the embed returns a block-and-redirect page instead of a game. Every URL involved still answers 200. A link checker sees a healthy site. A player sees a message saying the game is not available here.

We're working on it, and we're saying so here rather than letting the blog imply a catalogue that plays. The reason it belongs in this article is the lesson it repeats: the only test that counts is loading the live page yourself, on the real domain, and pressing play. Not a status code. Not a link checker. Not your local build.

Common questions

My browser game shows a black screen but there are no console errors. What is wrong?

A black screen with no errors almost always means the game is still loading, not that it crashed. Most web game frameworks render nothing until their preload queue finishes, so if that queue is large the player sits in front of a blank canvas. Check the Network tab for the total transferred size before the first frame appears. If it is tens of megabytes, you have a payload problem, not a code problem.

How big should a browser game be?

There is no official limit, but the practical target most web developers work to is that something meaningful should be on screen within a few seconds on an average connection. That usually means getting your first-render payload into the low single-digit megabytes and streaming the rest afterwards. The exact number matters far less than the principle: never make the player wait in front of nothing.

Why is my PNG so large?

PNG is lossless, so it stores every pixel exactly. A 3375×3375 RGBA sprite sheet is over 11 million pixels at four bytes each before compression, and photographic or painterly artwork compresses poorly in PNG. Backgrounds with no transparency are usually far smaller as WebP or AVIF, and sprite sheets with transparency are usually far smaller as WebP.

Does a large texture use more memory than its file size?

Yes, and this catches people out. Once decoded and uploaded to the GPU, an uncompressed RGBA texture occupies width × height × 4 bytes regardless of how well the file compressed on disk. A 3375×3375 sheet is about 43 MB of texture memory even if the PNG on disk is 7 MB. This is a common cause of crashes on phones.

Should I show a loading bar?

Yes, and it should appear before the heavy assets are queued, not after. Load one tiny image in a first scene, draw your loading UI from it, then start the real queue and hook your loader's progress event. A player who can see a bar moving will wait. A player looking at a black rectangle assumes the game is broken and leaves.

Where these numbers came from

So you can check them rather than take our word for it. All measured on 31 July 2026:

Total size and per-file sizes were measured on the deployed copy of the game and confirmed against the live server with HTTP range requests — for example grandma.png reports Content-Range: bytes 0-0/7259947, i.e. 7,259,947 bytes.
Image dimensions were read from each PNG's IHDR header, which also gives the colour type used to distinguish RGB from RGBA.
The preload contents were read from the game's own compiled source: eleven queued assets totalling 21,960,586 bytes, with no progress handler present.
The console and network state were observed by loading the live page in a real browser. The estimated wait times are arithmetic on the byte count at the stated connection speeds, not measured timings — treat them as a floor, not a prediction.
Pastanation is a SlowDen Original — a game built by SlowDen. Most games listed elsewhere on SlowDen are third-party or partner titles and are not SlowDen's work.

If you have a browser game sitting in a folder

Measure it before you show it to anyone. Ten minutes with the Network tab will tell you more about whether strangers will play your game than another week of features will.

And when it loads the way you want it to, it deserves to exist somewhere other than your hard drive.

Originally published on the SlowDen blog: Why your browser game loads to a black screen. All measurements were taken on 31 July 2026 and describe the game as it stood on that date; we intend to fix what is described here, so re-measure before relying on any figure. Phaser is a third-party open-source framework and is named for accuracy only, implying no affiliation or endorsement.

I'm 11 Years Old. Last Week I Launched My First SaaS. Here's What Actually Happened.

Liza Bhadana — Tue, 26 May 2026 08:06:42 +0000

Try Aries AI: https://aries-a.netlify.app (currently desktop browser only)

A week ago I clicked "Publish" on a project called Aries AI — a free AI abacus tutor I'd been building solo from my home in India. I'm in middle school. I taught myself to code. I am eleven years old.

This is what happened next, what I learned, and what I'm doing now. No filter, no startup-bro vibes. Just what really happened.

What Aries AI actually is

For anyone new here: Aries AI is a browser-based AI tutor that teaches kids (and adults) mental arithmetic through the abacus method. It has four modes:

An interactive visual abacus you click and drag
Oral practice where the app speaks number sequences out loud and you keep the running total in your head
Formula lessons covering the three families I learned in my own abacus classes: Big Friends formulas, Small Friends formulas, and Combination formulas
A conversational AI tutor (powered by OpenAI) that re-explains anything if it doesn't click the first time

The whole thing runs on OpenAI + Supabase + Render + Razorpay + Netlify. Built solo.

How the launch actually went

I posted across about ten platforms in two days — Medium, Dev.to, Hashnode, LinkedIn, Substack, Tumblr, Pinterest, Bluesky, X, and Reddit. I also got the app listed on AlternativeTo and set up a Product Hunt page.

Here's what I learned:

Cross-posting to ten platforms at once is real work. It took me about six hours total, including editing platform-specific versions. People who say "just post everywhere" don't realize how different the platforms are. Dev.to wants the build story. Pinterest wants a visual pin. Reddit will silently ban you if you sound too promotional.

The most engagement came from places I didn't expect. Bluesky and Tumblr — the platforms I almost skipped — got more genuine replies than X or LinkedIn in the first 24 hours. People on the smaller platforms are more likely to actually try your thing.

I shipped a real bug into production. I told everyone the app was "browser-based, no install needed" without realizing how much of my audience would try it on mobile. The app isn't mobile-ready yet. I spent the next day going back to every single post and adding a "desktop browser only" note. Lesson learned: always test on your audience's device, not just your own.

My abacus teacher is going to review it. That feedback is going to be more valuable than anything 1000 random users could tell me. If you're shipping something that requires expertise, getting one expert to look at it is worth a hundred casual testers.

What I actually built (in plain language)

The boring stack story:

OpenAI powers the AI tutor. The hard part wasn't the model — it was pinning my actual lesson plans into the system prompt so the tutor doesn't drift to generic abacus answers from its training data.
Supabase handles users, login, and the database. Row-level security took me an evening to figure out, but once it was set, I stopped worrying about auth completely.
Render runs the backend. Not glamorous. It just works.
Razorpay for payments because I live in India and UPI is how most users want to pay.
Netlify for the frontend. Zero-config deploys are a gift.

The non-boring story: every piece of this stack has a generous free tier. I spent under ₹1000 in actual infrastructure costs across multiple months. The hard part wasn't the money. The hard part was sitting alone in front of bugs at 11pm and refusing to give up.

Things I wish someone told me before launch day

Reply to every single comment in the first 48 hours. Reddit's algorithm decides whether your post lives or dies based on early comment activity. I went from a ranked launch post to a buried one because I missed the first few hours.
Your launch is not your launch. The day you click "publish" is the start of a week-long process of replying, fixing, replying again. Block out the time.
People love founders, not products, at this stage. When I added "I'm 11 years old, building from India" to my posts, engagement easily tripled. Not because the product changed — because the story did.
Friends who say they'll share won't. Strangers who say nothing will. It's fine.
Save every kind word someone says. Three days in, I screenshot every nice comment and put them in a folder called proof. When I'm staring at a bug at midnight, that folder is the thing that keeps me going.

What I'm working on this week

Mobile support. The single most common feedback was "I tried it on my phone and nothing happened." Building a mobile-friendly version is the top priority.
Better onboarding for the formula lessons. A few people got lost between Big Friends and Small Friends. I'm rewriting the intro.
Getting feedback from my actual abacus teacher. Easily the highest-leverage thing I can do.
Launching my personal site at the kimstudio brand — a portfolio with my projects, games I built, and other things I'm working on.

If you're a kid reading this

If you're 9, 10, 11, 12, 13 — and you're thinking about building something:

Start the day you have the idea, even if you don't know how.
The first thing you ship will be embarrassing. Ship it anyway.
The internet will be kinder than you expect, and crueler in specific ways. Both will happen the first week.
The "real" developers are not gatekeeping. They were once where you are. Ask them things directly.
Your age is your superpower, not a weakness. Lead with it.

If you're an adult reading this

Try Aries AI. If you have kids learning the abacus, send them. If you're learning mental math yourself, try the oral practice mode for 15 minutes — it's the closest thing to having a real teacher read numbers to you.

If you teach abacus, mental math, or any math-adjacent subject — please tell me what's wrong with the formula sequencing. I want to learn.

If you've shipped something solo — what did you wish someone told you in week one?

Thanks for reading. Sending this from India.

— Liza, 11

✨ Live app: https://aries-a.netlify.app

Building Aries AI: A Solo-Built AI Abacus Tutor on OpenAI + Supabase + Render + Razorpay

Liza Bhadana — Sun, 24 May 2026 17:08:19 +0000

Live: https://aries-a.netlify.app

⚠️ Heads up: Aries AI currently runs only in a desktop or laptop browser. Mobile/phone support is not yet available.

This is a short build-in-public post about Aries AI, an AI abacus tutor I shipped solo. Stack notes, what worked, what didn't, and a link if you want to poke at it.

The product, in one paragraph

Aries AI teaches mental arithmetic through the abacus method. It has four modes: an interactive visual abacus, oral drills (TTS reads a sequence of numbers, user types the running total), structured formula lessons (three families of abacus shortcuts — Big Friends, Small Friends, and Combination formulas), and a conversational AI tutor that re-explains and generates custom practice. Free tier + paid plans.

The stack

Frontend  -> Netlify (static deploy, free tier)
AI model  -> OpenAI API
Backend   -> Render
Database  -> Supabase (Postgres + Auth + RLS)
Payments  -> Razorpay

Honest take on each piece:

Netlify for the frontend was the obvious call. Free tier is generous, CI from git, instant rollbacks. Deploy times under a minute. The only friction I hit was function cold starts when I briefly tried to use Netlify Functions for one endpoint — moved that to Render instead.

OpenAI powers the tutor. The interesting work here was not the model — it was the prompt scaffolding to keep the tutor consistent with the in-app curriculum. The Big/Small/Combination formula explanations had to be pinned in the system prompt so the model would not drift to generic abacus explanations from its training data, which often contradict the specific mnemonics I teach with.

Render for the backend was a quality-of-life upgrade over trying to glue serverless functions together. One service, one deploy, sane logs. Free tier sleeps after inactivity, which is a known tax but fine for the current traffic.

Supabase carried more weight than anything else in the stack. Postgres + auth + row-level security + a usable dashboard, all in one place, with a generous free tier. The RLS policies took a couple of hours to get right but once they were in place, I stopped worrying about auth almost entirely.

Razorpay for payments — non-negotiable if you are targeting Indian users, because UPI is how most people actually want to pay. International cards work too, so I get global users without having to plug in a second payment provider.

What I'd do differently

Build oral practice earlier. It is the feature users come back for, and I almost cut it from v1 to ship faster. Mistake.
Pin the AI tutor's curriculum harder from day one. Early users got generic abacus explanations from the model that contradicted my lessons. Took two iterations of the system prompt to fix.
Set up an analytics event for "user finishes a formula lesson" from day one, not week three. Without it I had no idea which formula was the drop-off point.

What's working

Netlify + Supabase + Render is a genuinely cheap stack to run a small EdTech product on. Monthly infrastructure cost is still essentially zero at current usage.
A single, focused AI tutor inside a structured curriculum performs much better than dropping users into an open-ended chat. The structure does most of the teaching; the AI handles the long tail of "wait, I don't get this part."
Razorpay's checkout works on the first try, which is rare for payment integrations.

Try it

aries-a.netlify.app — happy to take feedback, especially from anyone who has shipped EdTech before, or anyone with strong opinions about OpenAI prompt design for tutoring.

DEV Community: Liza Bhadana

Your og:image is probably the wrong shape: we measured 9 sites

What shape is an og:image supposed to be?

What was our own site actually serving?

What do other browser-game portals serve?

Why did measuring first cut the job by ninety per cent?

Why we did not declare width and height on every page

Why was it the hand-written pages again?

What is worse than a cropped preview?

How do you check yours in five minutes?

What we could not verify

Why 3 of our 16 blog posts had no analytics tag

Why did only the blog posts lose the tag?

Which pages does a template actually protect?

How do you find untracked pages on your own site?

1. Audit what you ship, not what your build folder contains

2. Break the check on purpose before you believe it

What we changed, and why it is not a checklist item

Untracked is not the same as unpublished

Two probes that lied while we were fixing it

A text-mode file read rewrote a file we only meant to inspect

The probe that said the file was clean returned zero either way

How to check yours, in about ten minutes

What we could not verify

Related reading

The same URL served me two different images

Part 1: the parameter that does nothing

Part 2: the header that does everything

Part 3: 200 images, not one

Part 4: the demo that made it click

Part 5: why you cannot see this from your own page

Part 6: where this actually bites

Part 7: the defect this found on my own site

Part 8: how to check yours, in about five minutes

What I could not verify

Related, from the same site

The star rating your iframe added to your page

What I measured, and what I am not claiming

The controlled pair

What is actually inside the embed

How much of a catalogue this touches

Is this a game-portal thing?

Nobody did anything wrong, and it still crosses a guideline

Why we have not applied the obvious fix

Five minutes on your own site

What we changed, and what we did not

Questions

200 game pages, 200 star ratings, 0 machine-readable controls

The short version

What I measured, and what these numbers are not

The field has existed the whole time

200 pages, 200 ratings, 0 accessibility properties

The data isn't hidden. It was never collected.

The device flag is not a substitute, and it is only safe in one direction

Our own blind spot, which is worse in one specific way

One platform does collect it, and the reason is not technical

What we shipped today

If you make browser games, five things

Honest limits

Where to go next

Related reading

Two players, one keyboard: the multiplayer a phone cannot run

What we measured, and what these numbers are not

Finding 1: 13 games document two people on one device

Finding 2: local co-op is not in the "2 Player" category

Finding 3: the second player's keys are the first thing to get cut

Finding 4: a correction to our own article from this morning

Finding 5: how much room two players would actually get

And then there is what our own page says

Six things worth doing

Where the numbers came from, and what they cannot tell you

If you make browser games

Related reading

Why your browser game is unplayable on a phone

The short version

What we measured, and what these numbers are not

Finding 1: 68 of 155 control lists never mention touch

Finding 2: 26 games hand the player a keyboard, and nine hand out two

The nine that cannot be ported at all as designed

Finding 3: the page says tap, then lists the keys