HTML-First 网站设计让用户量一夜翻倍 — 一个被遗忘的工程哲学

原文来源：Alistair Davidson — Building an HTML-first site doubled our users overnight — 工程师 Alistair Davidson 分享了如何用 HTML-First 的方法重构公用事业公司的申请表单网站，使完成申请的用户量一夜翻倍。

这个故事让人想起一个古老但常被遗忘的真理：有时候，最简单的方案就是最好的方案。

工程师 Alistair Davidson 接手了一个棘手的项目。他的客户是一家公用事业公司（垄断性公共服务机构），用户需要在线填写表单以申请服务。听起来简单？但实际情况是：

• 用户只能通过一个古老的 ASP 表单在线提交，或者走更昂贵的人工流程
• 之前有过两次失败（且花费高昂）的改造尝试
• 最近一次由外包团队用 React 构建的 SPA，上线仅 3 天就因为客户投诉被紧急撤下

在经历了两次昂贵失败后，Alistair 做了一个"非常大胆的决定"：用 Astro 构建一个 HTML-First 的网站。 JavaScript 确实存在，但以 Web Component 的形式渐进增强一个不需要 JS 也能完美运行的网站。

设计原则

Alistair 为自己的方案设定了清晰的设计约束：

1. 这是公共服务——应该能在任何设备上工作
2. 应该能在网络条件差时工作
3. 表单绝不能丢失已经输入的数据
4. 应该能在过时和糟糕的浏览器上完成操作
5. 需要满足 WCAG AA 级无障碍标准
6. JavaScript 和现代 CSS 应当用于增强体验，而非创造依赖

这些原则受到了 Terence Eden 一段往事的启发：

几年前，我在伦敦的一个住房福利办公室做政策研究。一个年轻女士坐在塑料椅子上，周围放着装满她全部家当的帆布袋。她手里紧握着一台 PSP（PlayStation Portable）。我以为是她在玩游戏消磨时间。

但走近一看，她连上了免费 WiFi，正在浏览 GOV.UK 的住房福利页面。她没有在切水果——她在武装自己的知识。

PSP 的浏览器非常可怜——速度慢、内存不足、只能同时打开 3 个标签页。但 GOV.UK 的页面用简单的 HTML 编写，设计得足够轻量，即使在垃圾浏览器上也能工作。这是为所有人服务的。

技术方案：经典模式的新生

整个表单被拆分为多步骤向导，每个步骤是一个独立页面。用户点击"下一步"时提交表单，API 验证数据后重定向到下一步。

这是一个历经时间考验的 Web 应用模式——表单提交和重定向。由于所有人都习惯了重度客户端应用，Alistair 花了不少时间向同事解释这个模式。但它的优点很明显：不需要 JavaScript 就能工作，每一步的数据都即时保存在后端，用户关闭页面也不会丢失进度。

然后他解决了自己最头疼的问题之一：表单验证。

Alistair 见过无数团队在 React 验证库上浪费数人月的时间。他的解决方案是一个自制的 HTML Web Component：

<validation-enhancer>
  <form>
    <label for="my-email">邮箱</label>
    <input type="email" name="my-email" aria-errormessage="my-email-error" required />
    <div id="my-email-error"></div>
    <button type="submit">提交</button>
  </form>
</validation-enhancer>

这个组件不到 1KB，没有 Shadow DOM，几乎不用 JavaScript 渲染 HTML。它包裹在现有 HTML 表单外部，拾取浏览器的原生 HTML 验证，让验证界面变得现代友好。如果增强失败，表单会回退到浏览器内置验证。如果还不行，后端 API 兜底。

"我在这个行业 20 多年了，这是我用过的最好的表单验证库。"

结果：用户量一夜翻倍

上线后，完成表单的用户量翻了一倍。分析团队甚至搞不清楚这些用户是从哪里冒出来的——当然，因为你的基于 JavaScript 的分析工具根本看不到那些因为 JS 失败而被你挡在门外的用户。

"这像洪水一样涌来。"

故事有一个令人唏嘘的尾声。作为合同工，Alistair 在项目结束后离开了。他向接替者解释了自己构建的内容——即使没有 JavaScript 也能完美工作。接替者非常震惊，说："但那样我们就要做更多的工作了。"

这句话暴露了一个普遍的行业病态思维。将用户排除在外的代价在财务报表上不可见，但它是真实存在的。 对于垄断性的公共服务来说，拒绝老旧浏览器、网络条件差的用户、使用辅助技术的用户，本身就是不可接受的。

独立开发者的启示

这个故事对独立开发者有几点启发：

第一，不要默认选择 SPA。 如果你的应用主要是表单和内容展示（而不是实时交互），传统的多页应用（MPA）方案可能更合适。Astro、Remix、Fresh 等框架正在让这个选择变得更容易。

第二，渐进增强不是倒退。 先构建一个完全没有 JavaScript 也能工作的版本，再用量少而精的 JavaScript 增强体验。这不仅扩大了受众面，也降低了维护复杂度。

第三，分析工具的数据会骗人。 如果你的分析代码依赖 JavaScript，你永远看不到那些被 JavaScript 挡在门外的用户。他们不是不存在，只是你看不见。

第四，不用因为"做起来更省事"而放弃更多用户。 独立开发者常常资源有限，所以更需要把有限资源用在刀刃上。但在这个案例里，"做起来更省事"的 React SPA 失败了两次，反而是"更费事"的 HTML-First 方案成功了。

这篇文章传递的核心信息很简单：为所有人构建网站，不是一种利他主义，而是一种工程智慧。