为什么 15KB 就够

2026 年,一个普通网页大约重 2.5 MB。一个 Hage Game 游戏页大约重 15 KB,其中约 8 KB 是共享样式表和 JavaScript。游戏本身 —— 它的逻辑、渲染、音频、本地存储接口 —— 放在 7 KB 或更少里。这不是意外或美学选择。这是在不添加任何网页平台本身没有提供的东西的情况下,基于网页平台构建的自然结果。

现代浏览器已经给你什么

现代浏览器 API 已经足够全面,一个小的、自足的游戏几乎不需要任何外部东西。Canvas API 以任意分辨率处理带硬件加速的 2D 渲染。Web Audio API 实时合成声音 —— 振荡器、滤波器、包络 —— 不需要任何音频文件。pointer events API 在统一的接口下统一鼠标、触摸和触控笔输入。localStorage 无需服务器在会话间持久化数据。requestAnimationFrame 提供一个 60Hz 游戏循环,在标签页隐藏时暂停。这些都不需要 import。

这一期的游戏恰好用了这五个 API。每款游戏是一个带内联样式和内联 JavaScript 的单一 HTML 文件。包括标记、样式和游戏代码在内的完整 HTML 通常在 12 到 20 KB 之间。共享样式表加 8 KB,加载一次,在会话中缓存。这就是完整的技术栈。

这对加载时间意味着什么

在 4G 移动连接(实际约 10 Mbps)上,一个 15 KB 的页面不到 15 毫秒就能加载,不算 DNS 和连接开销。算上那些开销,第一次加载大约 200 到 400 毫秒。回访时,共享样式表已缓存,通常不到 100 毫秒。相比之下,一个典型的手机游戏在你能玩任何东西之前需要下载 200 MB。摩擦上的差异不是线性的;它是"我来试试"和"我把这个收藏起来等会儿再来" —— 而"等会儿再来"几乎永远不会发生。

15 KB 做不到什么

诚实说明约束是值得的。15 KB 存不下复杂的游戏状态 —— 我们的游戏保存一个最佳分数或最佳时间,仅此而已。它无法提供复杂的配对系统、持续进度、社交排行榜或应用内购买。它无法播放音频文件。它无法加载纹理。它无法显示照片。Hage Game 游戏里用到的每一个资产要么是程序化计算的(Canvas 绘制调用),要么是实时合成的(Web Audio 振荡器)。依赖丰富媒体的游戏 —— 带手绘精灵的平台游戏、带录制对白的叙事游戏、带授权音轨的音乐游戏 —— 无法在这个规模下构建。

我们认为这个约束几乎完全是一个优点。它迫使我们围绕机制而不是资产来设计游戏。一款玩家无法分辨音频是合成的还是录制的游戏(听音配对在非正式测试里表现不错),是比用精心的视听制作掩盖一个薄弱机制的游戏更好的游戏。机制要么能抓住注意力,要么不能。15 KB 让这种诚实成为必须。

无依赖的选择

让我们的页面保持小体积的最大单一因素,是选择不使用任何 JavaScript 框架、打包工具或游戏引擎。一个最小的 React 应用在你写一行游戏逻辑之前就加了大约 40 KB 的框架代码。一个最小的 Phaser.js 场景加了大约 1 MB。我们都不用。Hage Game 每个页面里的每一行 JavaScript 都是为那个页面写的,做恰好那个页面需要的事。代价是开发时间 —— 从头写一个碰撞检测程序比调用一个库函数慢 —— 但结果是我们完全理解的代码,可以在浏览器的开发者工具里在单个标签页调试,无需构建步骤,无需服务器。

这在某种意义上是回到了框架成为默认之前网页的构建方式。我们不认为框架不好 —— 对大型应用它们是必需的 —— 但对于一个需要在任何设备上一秒内加载的小型自足游戏来说,无依赖的路径显然是正确的。

发布 · 2026 年 5 月 14 日 · 撰写并署名:Bill