DEV Community: no momo

Third-Party Game iframe White Screen: How I Tracked Down the Root Cause with sandbox and postMessage Protocol

no momo — Wed, 14 Oct 2026 09:04:53 +0000

When integrating third-party HTML5 games, I ran into two seemingly unrelated problems: the game worked fine when opened locally, but went white when embedded in my site; and the game loaded, but scores sometimes got lost or mixed up when sent back.

The root causes were: the game server blocked iframe embedding via X-Frame-Options: DENY, and the postMessage protocol lacked origin validation and message type constraints. The first caused the white screen; the second caused the score mix-ups. Here's the full debugging and solution process.

Environment

Vue 3.4 + Vite 5.2
Test devices: Chrome 125, Safari 17.4
Game source: third-party HTML5 games deployed on a separate domain
Embedding method: <iframe> + postMessage

Problem 1: The Game Plays Locally but Goes White When Embedded

Symptoms

I got the game package from a third-party vendor. Opening index.html locally worked fine. But after embedding it in /play/:id, the iframe area was blank, with no JavaScript errors in the console.

How I Tracked It Down

My first thought was that the iframe's src path was wrong. After checking, the path was correct, and the game HTML request returned 200 in the Network panel.

But the Console panel had a line I hadn't noticed before:

Refused to display 'https://www.playfiddlebops.com/sprunki-mod/' in a frame because it set 'X-Frame-Options' to 'deny'.

Root cause: The game server set X-Frame-Options: DENY, explicitly forbidding the page from being embedded in any iframe.

The Fix

This requires the game vendor to change their configuration. If you can't modify the game server, you can set up a reverse proxy on your own server to proxy game assets under a same-origin path:

# nginx configuration
location /proxied-games/ {
    proxy_pass https://www.playfiddlebops.com/sprunki-mod/;
    proxy_set_header Host playfiddlebops.com;
    # Remove headers that block embedding
    proxy_hide_header X-Frame-Options;
    proxy_hide_header Content-Security-Policy;
}

But the reverse proxy has costs: all game requests go through your server, increasing bandwidth and latency. Also, if the game relies on cookies or localStorage under playfiddlebops.com, those contexts are lost after proxying.

My trade-off: Prioritize talking to the game vendor and ask them to deploy the game on a separate domain, using CSP frame-ancestors to allow only my domain to embed it. That's the cleanest solution, but it requires vendor cooperation.

Problem 2: The postMessage Protocol Lacked Constraints

Symptoms

After fixing the white screen, the game loaded correctly. But scores had two problems when sent back:

Scores occasionally got lost. The game showed "saved," but there was no record on the leaderboard.
When switching games quickly, game A's score appeared on game B's leaderboard.

How I Tracked It Down

The original protocol was very crude:

// Parent page receives
window.addEventListener('message', (event) => {
  if (event.data.type === 'END') {
    saveScore(event.data.score)
  }
})

// Game sends
window.parent.postMessage({ type: 'END', score: 123 }, '*')

There were three problems:

First, targetOrigin used '*'. The spec explicitly requires that messages containing any confidential information should not use the wildcard * as targetOrigin, because it can't guarantee the message is delivered only to the intended receiver.

Second, the receiver didn't validate event.origin. Any window can send postMessage. Without origin validation, a malicious page can forge score messages. OWASP recommends always checking the message's origin property and using a whitelist to ensure messages come from trusted domains.

Third, the receiver didn't validate event.source. When multiple iframes exist at the same time, event.source is what distinguishes which iframe the message came from. A security issue in a GameHub project on GitHub pointed out that when same-origin iframes lack the sandbox attribute, game scripts can directly read the parent window's localStorage and steal user credentials.

The Fix

Design a communication protocol with type constraints and origin validation:

// Protocol constants
const MSG_TYPE = {
  READY: 'game:ready',
  END: 'game:end',
  PAUSE: 'game:pause',
  RESUME: 'game:resume',
  FULLSCREEN: 'game:fullscreen',
  ERROR: 'game:error'
}

const ALLOWED_ORIGINS = [
  'https://www.playfiddlebops.com/'
]

// Parent page receives
const iframeRef = ref(null)
let activeSource = null

onMounted(() => {
  iframeRef.value?.addEventListener('load', () => {
    activeSource = iframeRef.value.contentWindow
  })
})

function onMessage(event) {
  // Three checks: origin, sender, message type
  if (!ALLOWED_ORIGINS.includes(event.origin)) return
  if (event.source !== activeSource) return
  if (!event.data?.type || !Object.values(MSG_TYPE).includes(event.data.type)) return

  switch (event.data.type) {
    case MSG_TYPE.END:
      if (typeof event.data.score !== 'number') return
      saveScore(event.data.score)
      break
    case MSG_TYPE.ERROR:
      reportError(event.data.message)
      break
  }
}

window.addEventListener('message', onMessage)

// Game sends
window.parent.postMessage(
  { type: 'game:end', score: 123 },
  window.location.origin  // Not '*'
)

There's a key constraint here: the event.source !== activeSource check breaks when the iframe redirects. The contentWindow reference points to a new Window object after iframe navigation, while event.source points to the Window object that sent the message. They're no longer equal. You need to re-capture contentWindow after each load event.

Problem 3: Item-by-Item sandbox Attribute Testing

Why sandbox Is Needed

Without the sandbox attribute, game scripts in a same-origin iframe can:

Read the parent window's localStorage and steal user credentials
Modify the parent page's DOM
Redirect the parent page to a phishing site

Google's HTML Service documentation explicitly states that IFRAME sandbox mode is based on the HTML5 iframe sandboxing feature, designed to protect users from malicious HTML or JavaScript.

Item-by-Item Test Results

I built a test page and enabled sandbox attributes one by one, observing the impact on game functionality:

sandbox attribute	Does the game run?	Side effects
Empty (maximum restriction)	No	Scripts completely disabled
`allow-scripts`	Yes	Game logic works, but can't submit forms
`allow-scripts allow-same-origin`	Yes	Can access localStorage, but has escape risk
`allow-scripts allow-same-origin allow-forms`	Yes	Forms work, no extra risk
`allow-scripts allow-same-origin allow-popups`	Yes	Popups work

Key Warning: The allow-scripts + allow-same-origin Combination

The spec explicitly states that when the embedded page is same-origin with the parent page, setting both allow-scripts and allow-same-origin allows the embedded page to simply remove the sandbox attribute and reload itself, effectively breaking out of the sandbox entirely.

This means: for third-party games you don't fully trust, never enable both attributes at the same time. The correct approach is to deploy games on a separate domain. Even with allow-same-origin enabled, game scripts can only access their own origin and can't read the parent page's data.

My final sandbox configuration:

<iframe
  ref="iframeRef"
  :src="game.entry"
  sandbox="allow-scripts allow-same-origin allow-forms allow-popups"
  allow="fullscreen; autoplay; gamepad; pointer-lock"
  referrerpolicy="no-referrer"
/>

The allow attribute grants the game the browser permissions it needs: fullscreen, autoplay, gamepad, and pointer lock. referrerpolicy="no-referrer" prevents the game server from getting the parent page's URL via the Referer header.

Problem 4: Load Timeouts and Error Handling

Symptoms

On a poor network, the iframe load could time out or fail completely, but the user just saw a blank area with no indication.

The Fix

Implement state management with timeout detection and a retry mechanism:

const states = ['idle', 'loading', 'ready', 'error']

const state = ref('idle')
const loadTimeout = ref(null)

function startGame() {
  state.value = 'loading'

  // 15-second timeout
  loadTimeout.value = setTimeout(() => {
    if (state.value === 'loading') {
      state.value = 'error'
      errorMessage.value = 'Game load timed out. Check your network and try again.'
    }
  }, 15000)
}

function onIframeLoad() {
  clearTimeout(loadTimeout.value)
  state.value = 'ready'
}

function retry() {
  state.value = 'idle'
  // Reset iframe src to force reload
  iframeKey.value++
}

This follows a pattern from the DEV community: manage repeat launches, resets, timeouts, and fullscreen toggles with a reducer. If the load event doesn't arrive within a reasonable time, show help and a retry option.

Verification Data

Tested 10 times each on Chrome 125 and Safari 17.4:

Test	Before	After
Third-party game white screen rate	100% (blocked by X-Frame-Options)	0% (after reverse proxy)
Score loss rate	3/10	0/10
Score cross-contamination	2/10	0/10
Load timeout with no prompt	Yes	No, retry button shown

Test conditions: Wi-Fi, Chrome DevTools without throttling.

Trade-offs and Limitations

The reverse proxy adds bandwidth and latency. Game assets go through my server, increasing first-load time by about 80ms. If game traffic is high, CDN caching needs to be considered.

sandbox restricts some game functionality. One game relied on allow-modals to show native dialogs. After being blocked by sandbox, it was changed to an HTML overlay. This is a conscious trade-off: security > convenience.

Origin validation adds protocol complexity. Every new game vendor requires adding its domain to the ALLOWED_ORIGINS whitelist. If a vendor changes domains, the configuration needs manual updating.

Unresolved

iOS Safari WebGL memory issues: One WebGL game crashes to a white screen after about 5 minutes on iPhone. WebKit's bug tracker shows iOS Safari has an iframe WebGL memory leak issue — repeatedly switching WebGL pages causes memory to grow until it crashes. Currently falls back to limiting game session length and prompting the user to refresh.
Dynamic script injection alternative: For higher-trust partners, consider replacing iframe with dynamic script injection, but that requires solving script isolation and global namespace pollution. Not enough time to validate this yet.
Cross-origin storage solution: If a game needs to persist user data (like game progress), there's currently no cross-origin storage solution. localStorage is isolated by sandbox, and cookies are restricted by third-party cookie limits.

References

WHATWG HTML spec on the iframe sandbox attribute, especially the security warning about combining allow-scripts and allow-same-origin
OWASP HTML5 Security Cheat Sheet on postMessage origin validation
Google HTML Service documentation on IFRAME sandbox mode
Kongregate's iframe game embedding troubleshooting guide, covering X-Frame-Options, CSP frame-ancestors, and CORS
DEV community articles on click-to-load iframes and timeout recovery

Game Site Takes 1.8 Seconds to Start After Click: How I Brought INP Down from 480ms to 120ms

no momo — Wed, 23 Sep 2026 07:03:09 +0000

The root cause wasn't slow iframe loading. It was too many tasks fighting over the main thread during page load.

React hydration, ad initialization, analytics scripts, thumbnail processing, game iframe initialization, WebGL startup — none of them looked slow on their own. But they all ran inside the same time window, and the combined cost was a 1.8-second white screen after the user clicked "Start."

The fix was priority scheduling + yielding the main thread. INP dropped from 480ms to 120ms, at the cost of about 18KB more first-load JS. Here's the full debugging process.

Environment

Vue 3.4 + Vite 5.2
Test devices: Moto G Power (Android 13 Chrome 125), iPhone 12 (iOS 17.4 Safari)
Network: 4G, Chrome DevTools throttling (20ms RTT)
Tools: Chrome DevTools Performance panel, Lighthouse 12

Symptoms

After users clicked the "Start Game" button on the game detail page, nothing happened for about 1.8 seconds. Then the game appeared. During that time, the button had no hover feedback and no click ripple.

I recorded the Performance panel in DevTools and found that after the click event fired, the main thread was occupied by a series of long tasks. INP measured 480ms, well above the "good" threshold (under 200ms).

First Misdiagnosis: I Thought the iframe Was Slow

My initial assumption was that <iframe src="game-entry.html"> took too long to load game assets when mounting.

So I made two changes:

Added loading="lazy" to the iframe
Delayed setting the src until after the click

Result: it got slower after the click. Because the game assets could have been loaded earlier, and I pushed that to after the click, the user had to wait through a full load cycle.

First attempt failed. The root cause wasn't the iframe's load timing.

How I Tracked It Down

Step 2: Recording the Full Timeline in the Performance Panel

I recorded a full "page load → click start → game appears" timeline again, and found the key information.

Within the 1.8 seconds after the click event fired, the main thread ran these tasks in sequence:

React hydration cleanup: ~42ms
Ad SDK initialization: ~38ms
Analytics script execution: ~21ms
Thumbnail processing (createImageBitmap): ~47ms
Game SDK initialization: ~55ms
WebGL context creation and shader compilation: ~63ms

None of these tasks looked catastrophic on its own, but they ran almost back-to-back on the timeline. The total was around 266ms, plus the browser's own rendering, style calculation, and layout overhead, which showed up as 480ms INP.

This matches what the OzoGames developer summarized from practice: performance problems usually aren't caused by one obviously bad script. They come from too many reasonable tasks trying to run at the same time. The browser doesn't care whether each individual task has a reason to exist. If enough work arrives on the main thread at once, players still feel a slow page.

Step 3: Understanding the Shared Nature of the Main Thread

There was a key shift in perspective here.

JavaScript execution, layout, style calculation, event handling, and many rendering tasks all depend on the browser's main thread. Imagine the page loading while doing all of these at once: React hydration, analytics initialization, ad initialization, consent management, recommendation rendering, thumbnail processing, game iframe initialization, game SDK initialization, WebGL startup.

On their own, none of these tasks may be catastrophic. The problem is that the browser receives all of them in the same short window, causing contention.

The way to think about browser performance shouldn't just be "how expensive is this script" — it should be "what else is happening when this script runs." Timing matters almost as much as size.

The Fix

Priority Model

Based on the diagnosis, I designed a five-level priority model:

Priority 1: Critical rendering and interaction (page shell, button response)
Priority 2: Business-critical initialization (user auth, core state)
Priority 3: Visible secondary UI (thumbnails, recommendation areas)
Priority 4: Non-critical analytics and enhancements (analytics scripts, consent management)
Priority 5: Heavy features triggered by user intent (game runtime)

For a game page, the game runtime itself belongs to Priority 5 until the player presses Play.

Splitting Long Tasks with yield

The fix wasn't "delete tasks" — it was "move tasks," changing when they run.

The core technique is yield: periodically give the main thread back to the browser inside a long task, so higher-priority work like user input can run.

setTimeout can also yield, but it has a problem: the continuation after the yield goes to the end of the task queue. Any other task scheduled in the meantime — a third-party analytics callback, another component's task, another setTimeout — runs before you regain control. Your loop can get stuck behind work you don't care about, and a task that should finish in 100ms can stretch unpredictably.

scheduler.yield() solves this. It returns a Promise, execution pauses at the await, and the main thread is handed back. The key difference: the continuation goes into a priority queue. When the browser comes back, your function resumes before other similar waiting tasks, not after them.

In Chrome's framework, the continuation of scheduler.yield() has higher priority than same-level scheduler.postTask() tasks, which prevents your loop from starving.

The rewritten loop barely changes:

async function processThumbnails(thumbnails) {
  for (const [i, thumb] of thumbnails.entries()) {
    await createImageBitmap(thumb)
    if (i % 10 === 0) {
      await scheduler.yield()  // yield every 10 thumbnails
    }
  }
}

Concrete Scheduling Changes

Defer ad and analytics scripts until after the page is interactive.

<head>
  <script src="/app.js"></script>
</head>
<body>
  <script>
    const loadThirdParty = () => {
      const scripts = [
        'https://analytics.example.com/tracker.js',
        'https://ads.example.com/loader.js',
      ]
      scripts.forEach(src => {
        const s = document.createElement('script')
        s.src = src
        s.async = true
        document.body.appendChild(s)
      })
    }
    ['click', 'scroll', 'keydown'].forEach(evt =>
      addEventListener(evt, loadThirdParty, { once: true })
    )
    setTimeout(loadThirdParty, 3000)
  </script>
</body>

Process thumbnails in chunks. Instead of processing all thumbnails at once, yield every 10.

Delay game iframe initialization until after the user clicks. This was already implemented with the facade pattern in the previous article. The key point: game runtime initialization (WebGL context creation, shader compilation) is moved to Priority 5 and only triggered after the user clicks.

Safari Compatibility

scheduler.yield() is stable in Chrome and Edge (129+, September 2024), covering about 70% of global traffic, but Safari and Firefox don't support it yet. A feature detection and fallback is needed:

function yieldToMain() {
  if (globalThis.scheduler?.yield) {
    return scheduler.yield()
  }
  return new Promise((resolve) => setTimeout(resolve, 0))
}

The fallback uses setTimeout(0). The continuation still goes to the end of the queue, but at least it doesn't throw.

Verification Data

Metric	Before	After
INP (click start)	480ms	120ms
First Contentful Paint (FCP)	1.4s	1.4s (unchanged)
Largest Contentful Paint (LCP)	2.1s	2.1s (unchanged)
First-load JS (gzip)	85KB	103KB
Main thread long tasks (2s after click)	6	2

Test conditions: Moto G Power, Chrome 125, 4G throttling (20ms RTT), 10 runs each, median.

Note: FCP and LCP didn't change, because those metrics measure when page content first appears, and the post-click performance problem doesn't affect them. INP is the correct metric for interaction responsiveness.

Trade-offs

First-load JS grew by about 18KB. Because of the scheduler.yield() compatibility code and task scheduling logic. This is a conscious trade-off: 18KB for INP dropping from 480ms to 120ms.

Task scheduling complexity increased. Tasks that used to run synchronously now need to be split and queued, reducing code readability. Every task that needs to yield has to consider "where to yield" and "whether the continuation after yielding is safe."

Safari isn't fully optimized. The fallback uses setTimeout(0), and the continuation goes to the end of the task queue. The improvement on Safari is smaller than on Chrome. Measured Safari INP is about 220ms, worse than Chrome's 120ms, but much better than 480ms before the optimization.

Unresolved

Occasional white screen on iOS Safari: On low-end iPhones, game iframe initialization still occasionally produces a white screen. Currently falls back to retrying up to 3 times after the click.
Precompiling WebGL shaders: If there were a way to precompile shaders before the user clicks without creating a rendering context, the post-click delay could be reduced further. No reliable cross-browser solution found yet.
Third-party script main thread usage can't be fully controlled: The initialization timing of analytics scripts and ad SDKs can be deferred, but their main thread usage during execution can't be split, because it's third-party code.

References

Chrome for Developers' scheduler.yield() documentation explains the mechanism and continuation priority in detail
DEV community articles on INP optimization show the problems with setTimeout yielding and the improvements in scheduler.yield()
The OzoGames developer's practical summary provides the "main thread is a shared resource" and five-level priority model framework

Next.js 14 or Vue 3 + Vite? I Built the Same Game Site MVP Both Ways and Compared Them for 3 Days

no momo — Tue, 22 Sep 2026 06:51:03 +0000

TL;DR

I ended up choosing a hybrid: Next.js 14 for static content pages + a separately lazy-loaded client shell for the game runtime page.

But that wasn't a snap decision. I spent 3 days building the same MVP twice, hit the Next.js static export dynamic route 404 trap, and dealt with Vue's SEO plugin problem. If you're making a similar decision, the process is probably more useful than the conclusion.

Environment

Node 20.11 / npm 10.5
Next.js 14.2.3 (App Router + output: 'export')
Vue 3.4 + Vite 5.2 + vue-router 4
Test devices: MacBook Pro M1 (build tests), iPhone 12 (Lighthouse mobile tests)
Deployment target: Vercel static hosting (zero server)

What Were My Constraints?

Before writing any code, I listed three hard constraints:

SEO had to work: Most traffic for a game site comes from search engines. Game detail pages must be crawlable.
First load had to be fast: LCP under 2.5s on mobile 4G.
The game iframe couldn't block the main thread: While browsing the list page, no game runtime code should load.

These three constraints ended up driving the entire decision.

Day 1: Next.js Version — Static Export Taught Me a Lesson

What I Built

Next.js 14 App Router with this route structure:

/ homepage (SSG)
/games/[category] category page (SSG)
/play/[id] game runtime page (client-side rendered)

I used output: 'export' for pure static export and deployed to Vercel.

Trap 1: Dynamic Routes 404

After next build, the homepage and category pages generated HTML correctly. But /play/[id] all returned 404.

After digging in: App Router with output: 'export' doesn't support dynamic routes by default unless you explicitly define generateStaticParams. This is heavily discussed in the community; developers on V2EX have reported that "the latest Next.js App Router doesn't support dynamic routes with static generation."

Worse, even after defining generateStaticParams, all game IDs have to be pre-generated at build time. If the game count grows to hundreds, every new game triggers a full rebuild, and CI time grows exponentially.

Solutions I Tried

I tried @falsefoundation/next-dynamic-exports, which supports dynamic routes by generating fallback pages, but it requires web server rewrite rules (Nginx try_files), adding deployment complexity.

Another approach was to turn the game runtime page from a dynamic route into a client-rendered static shell — the /play page reads the game ID via useSearchParams after loading. This bypasses the generateStaticParams limitation, but the game runtime page is no longer prerendered, so SEO suffers. My trade-off: the game runtime page has low SEO value anyway (users arrive from the detail page), so it's acceptable.

Next.js Version Data

Homepage LCP: 1.2s (mobile 4G throttling)
First-load JS (gzip): ~85KB
Build time: 12s (including 6 pre-generated game pages)

Day 2: Vue 3 + Vite Version — Genuinely Lightweight

What I Built

Vue 3.4 + Vite 5.2 + vue-router 4, same route structure as the Next.js version.

The Advantages Were Obvious

Vite's dev experience is excellent. Cold start under 1 second, hot updates nearly imperceptible. Build time was only 6 seconds, half of Next.js.

First-load JS (gzip) was about 50KB, nearly 40% less than Next.js. Vue 3's runtime is lightweight by itself, and Vite's tree-shaking leaves nothing extra.

But SEO Became a Problem

Vue + Vite defaults to SPA. The homepage and category pages only contain <div id="app"></div> in the HTML — crawlers see no content.

The solution was to install vite-plugin-seo-prerender, which prerenders the SPA into static HTML files at build time. Configuration is simple:

// vite.config.ts
import seoPrerender from 'vite-plugin-seo-prerender'

export default defineConfig({
  plugins: [
    seoPrerender({
      routes: ['/', '/games/puzzle', '/games/sports']
    })
  ]
})

But the plugin has a limitation: it's only suitable for generating static HTML for a small number of pages. If the game count grows to hundreds, every game detail page needs prerendering, and build time becomes uncontrollable.

Another option is Nuxt 3, Vue's meta-framework with built-in SSG. But that introduces another framework, contradicting the "lightweight" goal.

Vue Version Data

Homepage LCP: 1.5s (mobile 4G throttling, after prerendering)
First-load JS (gzip): ~50KB
Build time: 6s

Day 3: The Key Finding — It's Not the Framework, It's the iframe Initialization Timing

After both versions were running, I did one thing: recorded the full timeline from homepage to clicking "Start Game" using Chrome DevTools Performance panel on both.

Something counterintuitive came up: the performance difference between the two versions was far smaller than I expected.

The Next.js version had 35KB more first-load JS, but on 4G that's about 200ms of download time. The real time sink while browsing the list page wasn't the framework's JS size — it was the game iframe initialization.

In the default implementation, the iframe was initialized when the game detail page mounted. Even if the iframe src pointed to an empty placeholder page, creating the contentWindow and initializing the sandbox environment still consumed main thread time. On a Moto G Power, that single operation took about 400ms.

The correct approach is the facade pattern: render only a lightweight static placeholder (thumbnail + play button) before the iframe mounts, and inject the actual iframe only when the user clicks "Start." This matches Lighthouse's recommendation for deferring third-party resources.

There's a Next.js static wiki case in the DEV community that uses the facade pattern to move a YouTube iframe from hydration-time mount to click-time load, bringing mobile TBT down from destructive levels to acceptable.

This means: the framework choice's impact on first-load performance is far smaller than the iframe initialization strategy's impact. I wrote this down because it directly changed my selection criteria.

Final Choice: Hybrid Architecture

Based on the three-day comparison, I made these decisions:

Static content pages (homepage, category pages, detail pages) use Next.js SSG. Because:

SEO works out of the box, no extra plugins
Dynamic routes have limitations, but the game detail page ID count is manageable (only 6 games initially)
If the game count grows to 200+, a Headless CMS with ISR can be introduced, but that requires a server and breaks the zero-backend constraint

The game runtime page uses an independent client-rendered shell. Because:

The game runtime page has low SEO value and doesn't need prerendering
Use next/dynamic with ssr: false to lazy-load the game iframe component
Facade pattern: initialize the iframe only after the user clicks "Start"

The Vue version wasn't maintained. It builds faster and has a smaller bundle, but SEO needs extra plugins, and if the game count grows, the prerendering solution's scalability is worse than Next.js's SSG system.

Here's the concrete implementation:

// components/GameLauncher.tsx
'use client'
import { useState } from 'react'
import dynamic from 'next/dynamic'

const GameIframe = dynamic(() => import('./GameIframe'), {
  ssr: false,
  loading: () => <div className="h-full bg-zinc-900 animate-pulse" />
})

export default function GameLauncher({ game }) {
  const [started, setStarted] = useState(false)

  if (!started) {
    return (
      <button
        onClick={() => setStarted(true)}
        className="relative w-full aspect-video rounded-lg overflow-hidden"
      >
        <img src={game.thumbnail} alt={game.title} className="w-full h-full object-cover" />
        <div className="absolute inset-0 flex items-center justify-center">
          <svg width="64" height="64" viewBox="0 0 64 64">
            <circle cx="32" cy="32" r="30" fill="rgba(0,0,0,0.6)" />
            <polygon points="26,20 26,44 46,32" fill="white" />
          </svg>
        </div>
      </button>
    )
  }

  return <GameIframe src={game.entry} gameId={game.id} />
}

ssr: false ensures the iframe component isn't bundled into the HTML during server rendering, and only loads from the client after the user clicks. This matches Next.js's official lazy-loading advice: for heavy components that don't participate in SSR, use next/dynamic with ssr: false to reduce the initial bundle.

Data Comparison

Metric	Next.js 14	Vue 3 + Vite
First-load JS (gzip)	~85KB	~50KB
Homepage LCP (4G)	1.2s	1.5s (after prerendering)
Build time	12s	6s
Dynamic route support	Needs generateStaticParams	Built-in
SEO	Out of the box	Needs extra plugins
Game runtime lazy load	next/dynamic native support	Manual implementation

Test conditions: MacBook Pro M1 build, iPhone 12 + Chrome DevTools 4G throttling, 10 runs each, median.

Note: Vue's LCP was actually slower than Next.js after prerendering. The reason is that vite-plugin-seo-prerender still includes the full Vue runtime in the generated HTML, while Next.js SSG outputs cleaner HTML with lower hydration cost.

Trade-offs

Next.js build time is longer: 12s vs 6s. Every new game requires a rebuild. If the game count reaches 50, build time could exceed 30 seconds.
The Vue version was abandoned: It has better dev experience and a smaller bundle, but needs extra work on SEO and scalability. If your game site doesn't need SEO — an internal tool or pure entertainment site — Vue + Vite is the better choice.
The hybrid architecture adds complexity: Static pages and the runtime page use different rendering strategies, requiring understanding of two sets of logic.

Unresolved

If the game count exceeds 100, generateStaticParams full pre-generation becomes a bottleneck, requiring ISR or a Headless CMS — but that's no longer zero-backend.
I didn't dig deep into Vue's prerendering solution. vite-plugin-prerender-static supports multi-route generation and SEO meta tags, which might be enough if the game count is small.
Astro is another direction worth watching. A developer built a 50+ game site with Astro + vanilla JS, keeping the JS bundle under 100KB gzip and emphasizing "each game only loads the JavaScript it actually needs."

Repo

Both MVP versions are organized, including Next.js and Vue comparison branches. The test data comes from a local environment. If you get different results on real hardware, I'd love to hear about it.

I Built a Game Site MVP with games.json and iframe postMessage, but Scores Kept Disappearing

no momo — Mon, 21 Sep 2026 08:10:18 +0000

TL;DR

The score loss came from two separate issues: postMessage had no targetOrigin or receiver-side validation, so messages from multiple iframes contaminated each other. The second issue was iOS Safari private mode throwing QuotaExceededError on localStorage, which needed its own fallback.

Fixing both took about 4 hours of debugging. Here's the full process.

Environment

Vue 3.4 + Vite 5.2 + vue-router 4
Test devices: iPhone 12 (iOS 17.4 Safari), Moto G Power (Android 13 Chrome 125)
Deployment: Vercel static hosting
Games: local HTML5 games under public/games/, one directory per game

Goal and Architecture

The goal was a zero-backend MVP with this route structure:

/ homepage, grid of games
/game/:id game detail page
/play/:id game runtime page
/leaderboard/:id leaderboard

Game metadata lived in public/data/games.json:

[
  {
    "id": "typing-hero",
    "title": "Typing Hero",
    "description": "Type words quickly to score points.",
    "thumbnail": "/img/typing-hero-thumb.png",
    "entry": "/games/typing-hero/index.html",
    "category": "puzzle"
  },
  {
    "id": "mini-football",
    "title": "Mini Football",
    "description": "Score goals in 60 seconds.",
    "thumbnail": "/img/mini-football-thumb.png",
    "entry": "/games/mini-football/index.html",
    "category": "sports"
  }
]

This structure was based on an open-source Vue 3 MVP spec. The fields stayed minimal, and adding tags, ratings, or play counts later would be straightforward.

The game runtime page loaded the game entry in an iframe, listened for postMessage, and wrote scores to localStorage.

The initial implementation looked like this:

// GameShell.vue — the broken version
window.addEventListener('message', (event) => {
  if (event.data.type === 'END') {
    const scores = JSON.parse(localStorage.getItem(`scores-${gameId}`) || '[]')
    scores.push({ score: event.data.score, time: Date.now() })
    localStorage.setItem(`scores-${gameId}`, JSON.stringify(scores))
  }
})

The game side sent:

window.parent.postMessage({ type: 'END', score: 123 }, '*')

Looks fine. But in practice, problems showed up one after another.

Problem 1: Scores Were Getting Cross-Contaminated

Symptoms

After playing mini-football, scores from typing-hero appeared in the leaderboard. The two games' scores were mixed together.

Even stranger, sometimes after finishing a round, the score wasn't saved at all.

First Misdiagnosis

I thought it was a listener cleanup issue caused by route changes. When switching games on /play/:id, the old listener wasn't removed, and a new one was added on top.

After adding onUnmounted cleanup, the problem persisted.

How I Tracked It Down

I opened DevTools Console and added a log line inside the message listener:

window.addEventListener('message', (event) => {
  console.log('Received message:', {
    origin: event.origin,
    type: event.data?.type,
    score: event.data?.score,
    source: event.source === window ? 'self' : 'unknown'
  })
  // ...
})

Two things stood out.

First, origin wasn't '*' — it was actually the current page's origin, because the game and the page were deployed on the same Vercel domain. So the problem wasn't there.

Second, event.source sometimes wasn't the currently active iframe. When I switched routes quickly between two games, the old iframe hadn't been fully destroyed yet, and its postMessage events were still being captured by the new page's listener.

Root cause: targetOrigin was '*', so messages were broadcast to all possible receivers; the receiving end also didn't validate whether event.source was actually the currently active iframe window.

The Fix

The sender must use an explicit targetOrigin instead of '*'. The receiver must validate event.origin, event.data.type, and the data shape together.

// Fixed GameShell.vue
const iframeRef = ref(null)
let activeSource = null

onMounted(() => {
  // Capture the iframe's contentWindow after it loads
  iframeRef.value?.addEventListener('load', () => {
    activeSource = iframeRef.value.contentWindow
  })
})

window.addEventListener('message', (event) => {
  // Three checks
  if (event.source !== activeSource) return
  if (event.origin !== window.location.origin) return
  if (event.data?.type !== 'END') return
  if (typeof event.data.score !== 'number') return

  const scores = JSON.parse(
    localStorage.getItem(`scores-${gameId}`) || '[]'
  )
  scores.push({ score: event.data.score, time: Date.now() })
  localStorage.setItem(`scores-${gameId}`, JSON.stringify(scores))
})

The game side changed to:

// No more '*'
window.parent.postMessage(
  { type: 'END', score: 123 },
  window.location.origin
)

One trade-off: the event.source !== activeSource check can break when the iframe redirects, because the contentWindow reference changes. If the game navigates internally, you need to re-capture it on the load event. I haven't hit that scenario yet, so I left it as is.

Problem 2: Scores Wouldn't Save in iOS Safari Private Mode

Symptoms

After fixing the origin validation, I tested in Safari private mode on an iPhone 12. The console showed:

Uncaught QuotaExceededError: Failed to execute 'setItem' on 'Storage': Setting the value of 'scores-typing-hero' exceeded the quota.

The score data was only a few hundred bytes, far below the 5MB quota.

Root Cause

In iOS Safari private browsing, storage APIs are severely restricted or completely disabled. Even tiny amounts of data throw QuotaExceededError. This is especially bad in older Safari versions.

Fallback

I implemented a storage layer with an in-memory fallback. When localStorage is unavailable, it falls back to memory storage so data isn't lost within the current session.

// storage.js
function createStorage() {
  // First, probe whether localStorage actually works
  try {
    const testKey = '__storage_test__'
    localStorage.setItem(testKey, '1')
    localStorage.removeItem(testKey)
    return localStorage
  } catch {
    // Fall back to in-memory storage
    const memory = new Map()
    return {
      getItem: (key) => memory.get(key) ?? null,
      setItem: (key, value) => memory.set(key, value),
      removeItem: (key) => memory.delete(key)
    }
  }
}

const storage = createStorage()

This is a stop-gap: in-memory storage doesn't persist across page loads, so scores disappear after a refresh. But for private-mode users, it's better than crashing. A second fallback could use cookies, but cookies have a 4KB limit and aren't enough for leaderboard data.

Problem 3: Scroll Bleed-Through on Mobile

Symptoms

On iOS Safari, when a finger scrolled on the iframe, the background page scrolled too. The game itself was a full-screen canvas with no scroll needs, but the parent page moved.

Cause

Safari doesn't propagate scroll events from inside an iframe back to the parent page, but when the iframe reaches a scroll boundary, touch events bleed through to the parent.

Fix

The game runtime page container had a fixed height, and the parent page disabled scrolling while on the game page:

// play route's onMounted
document.body.style.overflow = 'hidden'
document.body.style.position = 'fixed'
document.body.style.width = '100%'

// onUnmounted restore
document.body.style.overflow = ''
document.body.style.position = ''
document.body.style.width = ''

If the game iframe itself needs to scroll, add -webkit-overflow-scrolling: touch to the iframe container and listen to the iframe's load event to adjust the container height dynamically.

Verification Data

After the fixes, I tested 10 times each on an iPhone 12 (iOS 17.4 Safari) and a Moto G Power (Android 13 Chrome 125):

Test	Before	After
Score write success (normal mode)	7/10	10/10
Score write success (private mode)	0/10 (threw error)	10/10 (memory fallback)
Score cross-contamination	3/10	0/10
Background scroll bleed-through	Yes	No

Test conditions: Wi-Fi, Chrome DevTools without throttling, iOS tested directly in Safari.

Trade-offs and Limitations

The in-memory fallback isn't persistent: private-mode users lose scores after a refresh. That's an acceptable trade-off — at least it doesn't crash.
Origin validation adds coupling: activeSource needs to be re-assigned after the iframe load event. If the game navigates cross-origin internally, that needs extra handling.
No backend: leaderboards are local-only and don't sync across devices. That's an expected MVP limitation.

Unresolved

Cross-device leaderboard sync needs a backend. That's the next article.
The game iframe has no load timeout or retry mechanism yet. On a bad network, there's no fallback for a white screen.

Repo

A minimal reproduction demo(eg:playfiddlebops.net) is available, containing both the broken version and the fixed version. The local test data comes from my personal testing and doesn't represent all devices. If you see different behavior on real hardware, I'd love to hear about it.

Top 10 Addictive Browser Games to Play When You’re Bored (No Download Required)

no momo — Tue, 18 Aug 2026 10:01:58 +0000

Let’s be honest—whether you’re taking a quick break at work, enduring a long gap between classes, or simply trying to kill some time, browser games are the ultimate lifesavers.

Thanks to the evolution of HTML5 and WebGL technologies, you no longer need a high-end gaming PC or gigabytes of storage to enjoy high-quality games. Today’s web games run smoothly directly in your browser, completely free, and require absolutely zero downloads.

As a web developer and avid gamer, I’ve tested hundreds of browser-based games. Here is my curated list of the top 10 most addictive HTML5 browser games and hidden gem platforms you need to try in 2024.

1. Skribbl

Genre: Multiplayer Drawing / Party
Why it’s great: If you love Pictionary, this is the digital version. You are given a word to draw, and other players in the lobby must guess what it is in real-time. The hilarious (and often terrible) drawings make this an absolute blast to play with friends or strangers.

2. The "Pizza Edition" Collection (Best for Restricted Networks)

Genre: Arcade / Unblocked Game Hub
Why it’s great: We all know the pain of trying to play a quick game only to find out the school or office network has blocked the site. This is where Pizza Edition comes to the rescue. It acts as an incredible hub for classic and modern HTML5 games that somehow always manages to fly under the radar of strict firewalls. From retro arcade hits to fast-paced platformers, it’s a goldmine for finding games that are genuinely fun and accessible anywhere.

3. Krunker

Genre: First-Person Shooter (FPS)
Why it’s great: It’s hard to believe a game this smooth runs in a browser. Krunker is a fast-paced, blocky multiplayer FPS that feels like a mix between Minecraft and Call of Duty. The movement mechanics are incredibly fluid, and games load in literal seconds.

4. Play FiddleBops (The Best Musical Hidden Gem)

Genre: Rhythm / Casual Music Generator
Why it’s great: If you are a fan of casual music-making games (think Incredibox), you will easily lose hours here. FiddleBops is a wonderfully quirky HTML5 rhythm and music game where you mix and match different characters, each representing a unique sound or beat, to create your own catchy tunes. It’s stress-relieving, visually charming, and runs flawlessly on both desktop and mobile browsers. Highly recommended for a creative break.

5. 2048

Genre: Puzzle
Why it’s great: The ultimate brain-teaser. The goal is simple: slide numbered tiles on a grid to combine them and create a tile with the number 2048. It sounds easy, but it requires deep strategic thinking. It’s the perfect game to keep your brain active during a boring conference call.

6. GeoGuessr

Genre: Geography / Exploration
Why it’s great: GeoGuessr drops you somewhere random in the world using Google Street View, and you have to figure out where you are by looking at road signs, architecture, and landscapes. It’s educational, incredibly addictive, and makes you feel like a virtual detective.

7. Slither

Genre: Multiplayer Arcade
Why it’s great: A modern, multiplayer take on the classic Nokia "Snake" game. You start as a small worm and eat glowing orbs to grow longer. The catch? If your head touches another player's body, you explode, and they can eat your remains. It’s competitive and highly satisfying.

8. Cookie Clicker

Genre: Idle / Incremental
Why it’s great: Be warned: this game will consume your life. You start by clicking a giant cookie to earn cookies. You then use those cookies to buy upgrades (like cursors, grandmas, and cookie farms) that bake cookies for you automatically. It’s the undisputed king of idle games.

9. Friday Night Funkin'

Genre: Rhythm
Why it’s great: This open-source rhythm game took the internet by storm. You play as "Boyfriend," engaging in rap battles against various characters to impress your girlfriend. The soundtrack is fantastic, and the HTML5 web version runs flawlessly without requiring any heavy installations.

10. Run 3

Genre: Endless Runner / Platformer
Why it’s great: A nostalgia trip for many. You control a little alien running through a series of endless tunnels floating in space. You can run on the walls and ceiling to avoid falling into the void. It’s simple, physics-defying, and perfect for testing your reflexes.

The beauty of modern browser gaming is accessibility. You don’t need an expensive setup; just open a new tab and start playing. Whether you are creating beats on FiddleBops, bypassing firewalls with Pizza Edition, or clicking your way to a cookie empire, there’s something for everyone.

Did I miss your favorite browser game? Let me know in the comments below!

When I Used AI to Write an HTML Game but Was Forced to Learn WebGPU Compute Shaders

no momo — Mon, 20 Jul 2026 07:47:58 +0000

Here’s the thing.

Last week I wanted to build a simple particle firework effect – the kind where you click the screen and hundreds of colorful particles explode, fall, and fade away. I’d written something similar with Canvas 2D before, so I knew the drill. But this time I decided to be lazy: I dumped the requirements into Claude and asked it to generate a complete HTML file on the spot.

The AI gave me working code in maybe fifteen seconds. Clean, well‑commented, even with gradient‑colored particles. I opened it in the browser, clicked a couple of times – 200 particles, smooth as butter. Then I bumped the count to 2,000 – the frame rate tanked to ~35 fps. At 5,000 particles, it became a slideshow at 12 fps.

That’s when it hit me: AI can write code that runs, but it won’t help you when it runs like crap.

So I went down a frustrating but incredibly rewarding debugging rabbit hole. And the thing that finally saved me wasn’t a smarter AI – it was WebGPU’s compute shaders.

Step 1: Finding the Real Bottleneck

The AI‑generated code looked like this (simplified):

const particles = [];

function init(count) {
  for (let i = 0; i < count; i++) {
    particles.push({
      x: canvas.width/2,
      y: canvas.height/2,
      vx: (Math.random() - 0.5) * 10,
      vy: (Math.random() - 0.5) * 10 - 5,
      life: 1.0,
      color: `hsl(${Math.random() * 60 + 20}, 100%, 60%)`
    });
  }
}

function update() {
  for (let p of particles) {
    p.x += p.vx;
    p.y += p.vy;
    p.vy += 0.08; // gravity
    p.life -= 0.01;
  }
}

function draw() {
  ctx.clearRect(0, 0, canvas.width, canvas.height);
  for (let p of particles) {
    ctx.globalAlpha = p.life;
    ctx.fillStyle = p.color;
    ctx.beginPath();
    ctx.arc(p.x, p.y, 4 * p.life, 0, Math.PI * 2);
    ctx.fill();
  }
}

The logic is straightforward: update loops over 5,000 particles on the CPU, recalculating positions and velocities; draw loops over them again, calling Canvas 2D APIs to draw circles.

So where’s the problem? 5,000 calls to beginPath + arc + fill is simply too heavy for Canvas 2D. Chrome’s Performance panel showed that the draw function consumed 78% of the frame time, most of it inside fill itself.

I tried all the usual optimizations:

Batch drawing? Not possible – every particle has its own color and alpha.
Use ImageData and manipulate pixels directly? Too much hassle, and I’d lose anti‑aliasing.
Reduce particle count? Then the firework wouldn’t look impressive enough. I needed a way to offload both the computation and the heavy drawing from the CPU to the GPU.

Step 2: What the Heck Is a WebGPU Compute Shader? (In Human Language)

WebGPU has two main use cases:

Rendering (Render Pass) – drawing triangles, textures, etc. – the WebGL replacement.
Computation (Compute Pass) – running massive parallel math on the GPU and reading the results back. A compute shader is basically a “mini‑program that runs on your graphics card.” It doesn’t care about drawing – it only crunches numbers. And its superpower is that it can perform the exact same operation on thousands of data elements simultaneously, with each element completely independent.

My 5,000 particles all follow the exact same update logic: position += velocity, velocity += gravity, life -= 0.01. That’s a perfect fit for parallelism.

So I rewrote the update function as a WebGPU compute shader, submitting it once per frame to let the GPU calculate all 5,000 new particle states in one go, then either reading the results back to the CPU (or directly piping them into the render pipeline).

Here’s the core part.

Step 3: A Minimal Working WebGPU Compute Shader

First, I defined a particle data structure (in WGSL, WebGPU’s shading language):

1.// Each particle occupies 16 bytes (16‑byte aligned)
2.struct Particle {
3.    pos: vec2<f32>,
4.    vel: vec2<f32>,
5.    life: f32,
6.    pad: f32,  // alignment padding
7.};

Then the compute shader entry point:

1.@group(0) @binding(0) var<storage, read_write> particles: array<Particle>;
2.
3.@compute @workgroup_size(64)
4.fn main(@builtin(global_invocation_id) id: vec3<u32>) {
5.    let index = id.x;
6.    if (index >= arrayLength(&particles)) { return; }
7.
8.    var p = particles[index];
9.
10.    // Physics update (identical to the JS version)
11.    p.pos = p.pos + p.vel;
12.    p.vel = p.vel + vec2<f32>(0.0, 0.08);
13.    p.life = p.life - 0.01;
14.
15.    // Bounce off walls (simple)
16.    if (p.pos.x < 0.0 || p.pos.x > 1.0) { p.vel.x = -p.vel.x; }
17.    if (p.pos.y < 0.0 || p.pos.y > 1.0) { p.vel.y = -p.vel.y; }
18.
19.    particles[index] = p;
20.}

This shader gets compiled, and each frame I submit it to the GPU – one submission updates all particles. @workgroup_size(64) means each workgroup processes 64 particles; the GPU automatically schedules a huge number of threads in parallel.

In JavaScript, the invocation looks like this:

const computePass = encoder.beginComputePass();
computePass.setPipeline(computePipeline);
computePass.setBindGroup(0, bindGroup);
computePass.dispatchWorkgroups(Math.ceil(particleCount / 64));
computePass.end();

And that’s it. The GPU does the heavy lifting in the background, and the CPU no longer has to loop over 5,000 items.

Step 4: The Real Pain Wasn’t Writing the Code

At this point you might think everything went smoothly – but the hardest part of the whole process wasn’t writing the WGSL. It was debugging.

WebGPU compute shaders have almost no debugging tools. You can’t console.log a particle’s position, and you can’t set breakpoints inside the shader. You’re left with:

Reading the result buffer back to the CPU and logging it with JavaScript – which kills performance.
Guessing by visual output – for example, if particles fly off‑screen, you suspect coordinate normalization issues or buffer alignment mistakes.
I spent a solid two hours stuck on one stupid problem: WGSL’s vec2 has 8‑byte alignment, and JavaScript’s Float32Array stores data sequentially – but I forgot to set the correct stride when creating the buffer. The particles’ positions were completely scrambled, as if they’d been randomly thrown outside the canvas.

The fix came from a brutally primitive approach: I wrote a small utility to copy the GPU buffer data back to the CPU, printed the first 10 particle positions, compared them with the JavaScript version, and that’s when I spotted the misalignment.

This experience taught me a hard lesson: WebGPU is powerful, but it’s incredibly unforgiving for beginners. AI won’t help you debug, and search engines won’t find your exact error – you just have to grit your teeth and read the spec.

Step 5: The Final Result (No Made‑Up Numbers, Just My Honest Impression)

On my MacBook Pro (M1 Pro):

5,000 particles with Canvas 2D – about 12–15 fps, and the page felt sluggish.
After switching to WebGPU compute shaders + only passing the final positions back to Canvas 2D for drawing – rock‑solid 60 fps, and CPU usage dropped from ~70% to ~8%. Note that I didn’t move the drawing to the GPU (that would require a full render pipeline) – I only moved the computation to the GPU and kept using Canvas 2D’s fillRect or arc for rendering. Even so, the improvement was night and day.

If I had also moved the rendering to WebGPU (using drawIndexed to draw thousands of triangles), it could theoretically reach thousands of frames per second – but the monitor only refreshes at 60 Hz, so there’s no point.

So How Much Did AI Actually Help?

Generating the initial code – yes, it was fast, but that was the “just works” version.
Writing the WGSL syntax – I asked it to produce a compute shader template, and it did – but once something broke, the AI had zero understanding of WebGPU’s binding‑group layout errors, because it lacks runtime context.
Solving the actual problem – I had to read the WebGPU spec three times and dig through Chrome’s about://gpu error logs myself. AI is a great junior dev – but when you hit low‑level API pitfalls, it’s as blind as you are.

What This Story Taught Me

What WebGPU truly changes isn’t “graphics quality” – it’s “computational capacity.” Even for 2D games, moving physics/particle logic to the GPU can boost performance several‑fold.
In 2026, HTML game development is no longer about “knowing Canvas” – it’s about “knowing how to program the GPU.” Game engines will eventually abstract this, but if you want to squeeze every last drop of performance, you have to understand compute shaders.
AI writes code impressively, but it won’t step into the pit for you. The real value of a developer lies precisely in being able to crawl out after falling in.

Finally, I Won’t Talk About WebXR

Because I know if I started rambling about how “WebXR brings the metaverse into the browser,” I’d be back in empty‑rhetoric territory.

So I’ll just leave you with one question:

Have you ever run into a “CPU can’t keep up” wall while building an HTML game? If so, what did you do about it?
If you’re also considering WebGPU, I can put together a small repository with the complete runnable code (WGSL + JS bindings) from this article and share it with you. Now that would be real meat. 😊

How PWA (Progressive Web Apps) are Changing the Mobile Gaming Landscape

no momo — Wed, 15 Jul 2026 03:12:52 +0000

For over a decade, mobile game distribution has been held in a tight duopoly. If you wanted to get your mobile game in front of users, you had to play by the rules of the Apple App Store or Google Play Store. This meant giving up a 30% cut of your revenue, navigating opaque and tedious review processes, and forcing users to undergo the high-friction process of searching, downloading, and installing massive binary packages.

However, a quiet revolution is taking place under the hood of modern mobile browsers. Progressive Web Apps (PWAs) are bridging the gap between web convenience and native app capabilities.

In this article, we’ll explore how PWAs are changing the mobile gaming landscape, the core APIs making it possible, and why the future of casual mobile gaming might live entirely outside the traditional App Store.

What is a PWA in the Context of Gaming?

At its core, a PWA is a website that uses modern web capabilities to deliver an app-like experience. For a game, this means it can be installed on a user’s home screen, run in full-screen mode without the browser UI, and—most importantly—work offline.

To turn a standard HTML5 game into a PWA, developers rely on three main pillars:

HTTPS: Secure delivery of assets.
Web App Manifest: A JSON file that defines how the game looks on the home screen (icons, orientation, display mode).
Service Workers: Scripts running in the background that handle asset caching and network requests.

The Core Tech: Service Workers & Offline Caching

The biggest historical knock against browser games was that they required a persistent internet connection. If a user entered a subway tunnel or lost cellular signal, the game would crash or fail to load.

Service Workers solve this by acting as a network proxy. They intercept requests and can serve cached assets instantly, enabling true offline gameplay.

Here is a simplified example of how a game’s Service Worker pre-caches assets during the installation phase, ensuring the game loads instantly even when offline:

// sw.js - Game Asset Service Worker
const CACHE_NAME = 'pixel-runner-v1';
const CRITICAL_ASSETS = [
    '/',
    '/index.html',
    '/css/game.css',
    '/js/game.js',
    '/assets/spritesheet.png',
    '/assets/jump_sound.mp3'
];

// Perform installation and cache critical assets
self.addEventListener('install', (event) => {
    event.waitUntil(
        caches.open(CACHE_NAME).then((cache) => {
            console.log('Opened cache, storing game assets...');
            return cache.addAll(CRITICAL_ASSETS);
        })
    );
});

// Intercept fetch requests and serve from cache if available
self.addEventListener('fetch', (event) => {
    event.respondWith(
        caches.match(event.request).then((response) => {
            // Cache hit - return response, otherwise fall back to network
            return response || fetch(event.request);
        })
    );
});

Combined with a Web App Manifest, your HTML5 game can be installed directly from Safari or Chrome onto the user’s home screen, hiding the URL bar and browser navigation buttons to provide a truly immersive, native feel.

Disruption of the App Store Monopolies

Beyond technical features, the rise of PWAs is a major strategic shift for indie game developers.

Bypassing the “App Store Tax”

Both Apple and Google charge developers up to 30% for in-app purchases (IAP) and subscriptions. By distributing your game as a PWA, you handle payments directly through web standards (like Stripe or PayPal), keeping 95% to 98% of your revenue.

Frictionless User Acquisition

With native apps, every step in the funnel loses users:
Clicking an Ad -> Loading App Store -> Clicking Install -> Waiting for Download -> Opening App.

With a PWA, the funnel is practically non-existent:
Clicking an Ad -> Game Loads Instantly.

Once the user is playing and enjoying the game, a subtle in-game banner can prompt them to “Add to Home Screen” to install it.

4. Hardware Integration: Closing the Gap

Modern browsers have granted the web platform access to device hardware that was once exclusive to native apps. Today, PWA games can leverage:

Pointer Lock & Gamepad APIs: Full keyboard/mouse lock and native game controller support (Xbox, PlayStation controllers) are supported natively in the browser.
Vibration API: Standard haptic feedback can be triggered on mobile devices to enhance gameplay feel during explosions or impacts.
Web Audio API: High-fidelity, low-latency audio synthesis and spatial audio can be processed directly inside the web browser.

The Challenges: What’s Still Missing?

While PWAs are revolutionary, they are not a silver bullet. iOS, in particular, has historically been slower to adopt progressive web standards compared to Android, occasionally limiting background push notifications or local storage limits for web applications.

Additionally, discoverability is a double-edged sword. While you are free from App Store gatekeepers, you also lose the organic search traffic that comes from being featured on the App Store front page. Developers must rely on SEO, social media, and word-of-mouth virality to drive users to their URLs.

Conclusion

Progressive Web Apps are democratizing game distribution. By transforming the web browser into an incredibly powerful runtime environment, PWAs allow indie developers to build highly optimized, instant-play, and offline-capable games that run globally on any device.

As app store models continue to face legal scrutiny and user fatigue grows, the web is reclaiming its place as the ultimate open gaming platform.

What do you think?

Have you tried packing your web games as PWAs? How do you handle local storage or asset updates? Let’s share some insights in the comments!

WebGL vs. Canvas 2D: Which One Should You Choose for Your Next Browser Game?

no momo — Tue, 14 Jul 2026 08:11:27 +0000

When you start building a new browser game, one of the very first technical decisions you must make is choosing your rendering context. Under the hood of the HTML5 element lies a fork in the road: do you call canvas.getContext('2d') or canvas.getContext('webgl')?

While it is tempting to think “newer and faster is always better,” the reality of game development is governed by constraints—time, complexity, bundle size, and target audience.

In this article, we’ll break down the architectural differences between Canvas 2D and WebGL, compare their performance, and help you decide which rendering path to take for your next web game project.

Canvas 2D: The Reliable, CPU-Bound Workhorse

The Canvas 2D API has been around for over a decade. It provides a simple, immediate-mode rendering interface where you draw shapes, text, and images directly using JavaScript.

// Quick Canvas 2D Setup
const canvas = document.getElementById('gameCanvas');
const ctx = canvas.getContext('2d');

// Drawing a simple player sprite
ctx.drawImage(playerSprite, x, y, width, height);

The Pros:

Low Barrier to Entry: The API is incredibly intuitive. If you want to draw a rectangle, write some text, or rotate an image, you can do it in one or two lines of code.
Built-in Text Rendering: Canvas 2D handles native system fonts and text layout gracefully, which is notoriously difficult to do in pure WebGL.
Tiny Footprint: You don’t need heavy libraries or boilerplate to get started. It’s perfect for vanilla JavaScript prototypes.
The Cons:

CPU Bottleneck: While modern browsers hardware-accelerate Canvas 2D where possible, it remains heavily dependent on CPU calculations and single-threaded JavaScript execution.
The Sprite Limit: If your game requires rendering more than a few hundred moving sprites, particle effects, or complex screen-wide filters simultaneously, you will likely see your frame rate drop below 60fps.

WebGL: The Hardware-Accelerated Beast

WebGL (Web Graphics Library) is a JavaScript API that interfaces directly with the user’s GPU (Graphics Processing Unit). It is a low-level API based on OpenGL ES, meaning it gives you immense control over the hardware but comes with extreme complexity.

// WebGL Initialization is significantly more verbose
const canvas = document.getElementById('gameCanvas');
const gl = canvas.getContext('webgl') || canvas.getContext('experimental-webgl');

if (!gl) {
    console.error('WebGL not supported by your browser');
}

The Pros:

GPU Acceleration: Calculations are offloaded to the GPU, which is parallel-processed. It can handle tens of thousands of sprites, complex shaders, and real-time lighting without breaking a sweat.
True 3D Capabilities: While Canvas 2D is strictly flat, WebGL allows you to build fully immersive 3D worlds, complete with depth buffers and camera matrices.
Custom Shaders: You can write GLSL (OpenGL Shading Language) programs to create stunning visual effects, such as water ripples, heat distortion, and dynamic shadows.
The Cons:

Extreme Complexity: Writing raw WebGL is notoriously difficult. Creating a simple colored triangle requires dozens of lines of boilerplate code to set up shaders, buffers, and program states.
Asset/Engine Overhead: To make WebGL manageable, most developers rely on third-party frameworks. While powerful, these engines add to your game’s initial bundle size and load times.

Performance & Architecture Comparison

To understand the difference, imagine drawing a forest of 5,000 trees:

The Modern Solution: Hybrid Engines

Thankfully, in 2026, web game developers rarely have to write raw WebGL. The modern ecosystem has given us powerful abstraction layers that offer the best of both worlds.

For 2D Games: Use PixiJS

If you are building a 2D game but want WebGL performance, PixiJS is the industry standard. It is a super-fast 2D WebGL renderer. Under the hood, it uses WebGL for blazing-fast performance but automatically falls back to Canvas 2D if WebGL is disabled or unsupported on the user’s older device.

For 3D Games: Use Three.js or Babylon.js

If you are taking the plunge into 3D, libraries like Three.js act as excellent wrappers, giving you access to lighting, materials, and cameras without requiring a degree in matrix mathematics.

Which One Should You Choose?

Choose Canvas 2D if:

You are building a casual game: Card games, board games, word puzzles (like Wordle), or turn-based strategy games do not require GPU power.
You want to minimize bundle size: If you are targeting instant-play platforms with strict file size limits (like Telegram or WeChat mini-programs), Canvas 2D’s lack of external dependencies is a massive advantage.
You are a beginner: If you are still learning game loops and physics, start here to avoid getting overwhelmed by graphics pipelines.
Choose WebGL if:

Your game is visually intensive: Fast-paced action platformers, bullet-hell shooters, or games with heavy particle systems (explosions, smoke, rain).
You are building a 3D game: From simple low-poly runners to complex shooters, 3D requires the GPU.
You want to use custom post-processing: If your game’s aesthetic relies on retro CRT screen shaders, bloom, or dynamic lighting.
What’s your stack?

Are you a raw Canvas purist, or do you always default to a WebGL framework? Let’s talk about your rendering choices and performance optimizations in the comments!

Why Browser Games Are Making a Comeback in 2026

no momo — Thu, 09 Jul 2026 07:29:17 +0000

If you were around during the golden era of the web, you probably remember Flash. It was the undisputed king of browser gaming, powering legendary portals like Newgrounds and Kongregate. When Flash met its official demise in 2020, many predicted that browser-based gaming would fade into obscurity, replaced entirely by native mobile apps and console ecosystems.

For a few years, that prediction seemed accurate. Early HTML5 Canvas games often suffered from performance bottlenecks, awkward mobile controls, and limited rendering capabilities.

However, fast forward to 2026, and we are witnessing a massive, quiet renaissance. Browser games are not just returning; they are thriving. But what changed under the hood, and why is HTML5 Canvas suddenly the darling of modern web developers again?

Beyond the 2D Context: The Technical Leap

In the early 2010s, developers trying to build complex games using the HTML5 Canvas API quickly hit a wall. Rendering thousands of sprites simultaneously on a 2D context resulted in severe frame drops, especially on mobile browsers.

Today, the technical landscape is entirely different. The evolution of the Canvas element isn’t just about the 2D rendering context; it is about how Canvas acts as the gateway to hardware-accelerated graphics.

WebAssembly (Wasm) + WebGL/WebGPU

The modern browser game stack rarely relies on pure JavaScript for heavy calculations. Instead, developers are using C++, Rust, or Go, compiling the game logic into WebAssembly, and rendering it through the Canvas using WebGL or the newly matured WebGPU standard.

By bypassing the JavaScript garbage collector and running close to native speed, browser games can now handle complex physics, real-time lighting, and 3D environments that were unimaginable a decade ago.

Here is a look at how modern web engines optimize the rendering loop using requestAnimationFrame to ensure smooth 60fps performance without draining the user’s battery:

const canvas = document.getElementById('gameCanvas');
const ctx = canvas.getContext('2d'); // or 'webgl' / 'webgpu'

let lastTime = 0;

function gameLoop(timestamp) {
    // Calculate delta time for frame-rate independent physics
    const deltaTime = timestamp - lastTime;
    lastTime = timestamp;

    updatePhysics(deltaTime);
    renderGraphics();

    // Request the next frame only when the browser is ready
    requestAnimationFrame(gameLoop);
}

// Start the loop
requestAnimationFrame(gameLoop);

The Battle Against “App Fatigue”

While technology paved the way, user behavior drove the comeback. In 2026, mobile users are suffering from what industry analysts call “App Fatigue.”

Downloading a new casual game today is a high-friction experience:

You must visit an App Store.
You must download 200MB+ of assets over mobile data.
You have to grant various privacy permissions.
Your device storage is constantly full.
Browser-based HTML5 games eliminate this entire pipeline. They offer instant play. You click a link on social media or in a chat app, and within three seconds, you are playing the game. No downloads, no installations, no storage warnings. For casual and mid-core gaming, convenience has triumphed over native performance.

The Rise of “Instant-Social” Ecosystems

Another major driver of the 2026 browser game comeback is the integration of web games into existing communication platforms.

Ecosystems like Discord Activities, Telegram Mini-Apps, and WeChat Games have built-in web views that rely entirely on HTML5 Canvas. Instead of leaving the chat app to play a game with friends, users can launch a fully functional multiplayer game inside their group chats.

For developers, this is a massive win. You don’t need to build a user acquisition funnel from scratch; you just deploy your game to the web, and the social platforms handle the virality. High-level frameworks like Phaser and PlayCanvas have adapted to this trend, offering lightweight, modular builds specifically optimized for these instant-play environments.

The Future: A Golden Age for Indie Web Devs

The democratization of web standards has made browser game development more accessible than ever. With modern build tools, hot module reloading, and robust deployment platforms, indie developers can build, test, and launch a web game globally in a matter of days.

We are no longer limited to basic puzzle games. The Canvas has evolved into a highly optimized viewport capable of delivering immersive, multiplayer, and cross-platform experiences directly to anyone with a web browser.

If you haven’t touched game development yet, there has never been a better time to open up an editor, grab a Canvas context, and start building. The web is ready.

What are your thoughts?

Are you currently developing web-based games, or do you still prefer native platforms? What frameworks are you using in 2026? Let’s discuss in the comments below!

Optimize Your Routine: The Practical Value of a planetary hours Calculator

no momo — Wed, 23 Apr 2025 08:38:27 +0000

Have you ever felt that certain times of the day seem better suited for specific activities? Ancient wisdom suggests this isn't mere coincidence. Welcome to the fascinating world of "planetary hours" – a system that divides the day (sunrise to sunset) and the night (sunset to sunrise) each into 12 segments, ruled sequentially by the seven classical planets (Sun, Moon, Mercury, Venus, Mars, Jupiter, Saturn).
Imagine handling communications and writing during a "Mercury Hour," engaging in social or artistic pursuits during a "Venus Hour," or tackling tasks requiring energy during a "Mars Hour." Sound complicated? Don't worry! If you're interested in this ancient timing wisdom, you should definitely try our planetary hours Calculator. It automatically calculates the precise start and end times for each planetary hours based on your location and the current date. No manual calculations needed – with just a click, you can discover which planetary energy is currently dominant, helping you better synchronize with the natural rhythms of the cosmos. Use our planetary hours Calculator now and start aligning your day with cosmic energies! Read also: https://planetaryhours.org