HTML in Canvas：Canvas高性能渲染与DOM原生能力兼得的新方案

前言：Web开发的性能与体验难题

长期以来，Web开发者在构建复杂界面时常常面临一个两难选择：是追求 Canvas 的高性能渲染，还是保留 DOM 带来的丰富原生能力？前者提供了 GPU 加速的流畅体验，后者则天然支持翻译、无障碍访问等用户真正需要的能力。

在这段来自全球最大在线巴士预订平台之一 Redbus 的工程师 Amit Kumar 的分享中，一个名为 HTML in Canvas 的技术方案被提出，它试图打破这一二元对立，成为「两全其美」的解决方案。

什么是 HTML in Canvas：Canvas与DOM的最佳结合

据 Redbus 工程师 Amit Kumar 的介绍，可以把 HTML in Canvas 理解为「两个世界的最佳结合」（the best of both worlds）。

它的核心价值在于：开发者可以构建高性能、GPU 加速的 Canvas 体验，同时不必牺牲原生 Web 所提供的任何能力。

用 Amit 的原话来说：

Canvas 为你带来渲染速度，而 DOM 则为你提供用户在 Web 上想要的一切。

这里的关键在于「不必二选一」。传统方案中，一旦选择 Canvas 渲染，就往往意味着放弃 DOM 层带来的诸多便利——比如浏览器自带的翻译功能、屏幕阅读器支持的无障碍访问等。

HTML in Canvas 让开发者不再需要在「高渲染速度」和「原生能力」之间做取舍，而是可以同时拥有两者。

Canvas渲染的核心痛点：脱离DOM生态

对于 Canvas 渲染而言，最大的痛点从来不是性能，而是它「脱离」了浏览器原生的 DOM 生态。

HTML5 Canvas 是一个通过 JavaScript 进行像素级绘图的 API，它绕过了浏览器的布局引擎（Layout Engine），直接在一块位图缓冲区上进行渲染。由于不需要经历 DOM 树构建、样式计算、布局回流（Reflow）和重绘（Repaint）等传统渲染管线步骤，Canvas 在处理大量图形元素时能获得显著的性能优势。现代浏览器还支持 Canvas 的 GPU 硬件加速，通过 WebGL 或 GPU 合成层将绘图操作卸载到显卡执行，进一步提升渲染帧率。这也是为什么游戏引擎、数据可视化库（如 ECharts、Konva）和地图应用普遍选择 Canvas 作为渲染后端。

然而，一旦内容画在 Canvas 上，浏览器就无法理解其中的语义结构：

• 无障碍访问：屏幕阅读器无法读取 Canvas 内容
• 翻译能力：浏览器的自动翻译无法作用于像素
• 文本选择、SEO、可访问性树等能力全部失效

浏览器的 DOM（Document Object Model）不仅是一个编程接口，更是整个 Web 语义生态的基石。浏览器会基于 DOM 构建一棵「可访问性树」（Accessibility Tree），它是屏幕阅读器（如 NVDA、VoiceOver、JAWS）理解页面内容的核心数据结构。同时，浏览器的内置翻译引擎（如 Google Translate、Edge Translator）也依赖 DOM 中的文本节点来识别和替换语言内容。当内容以像素形式绘制在 Canvas 上时，这些文本对浏览器来说只是一组颜色值，完全失去了语义信息，也就无法被翻译或被辅助技术读取。

HTML in Canvas 的意义正在于，它试图让 Canvas 内容重新获得这些原本属于 DOM 的能力，从而消除开发者长期以来的顾虑。

可能的技术实现机制

虽然分享中未详细披露具体实现细节，但从技术原理推测，HTML in Canvas 可能采用了一种「双层架构」：视觉层由 Canvas 负责高性能渲染，同时在其上方或下方维护一个隐藏的（或半透明的）DOM 层，用于承载语义信息。这种模式类似于 Google Docs 和 Figma 等应用采用的方案——Figma 使用 Canvas/WebGL 渲染设计画面，但同时通过 ARIA 属性和隐藏 DOM 元素为辅助技术提供信息。另一种可能的实现路径是利用 foreignObject 将 HTML 嵌入 SVG 再绘制到 Canvas，或者通过 OffscreenCanvas 结合 Web Worker 实现非阻塞渲染的同时保持主线程的 DOM 交互能力。

Redbus 的实际应用场景

Redbus 是全球最大的在线巴士预订平台之一，目前在 8 个国家运营，业务线覆盖巴士、渡轮、当地体验活动、铁路乃至酒店预订。这样的业务复杂度，对前端界面的性能和信息密度都提出了很高要求。

Amit 从两个维度阐述了 HTML in Canvas 的应用价值。

场景一：信息密集型页面的Canvas渲染优化

第一类是在现有应用中信息高度密集的页面，典型代表是巴士详情页（bus details）和座位选择（seat selection）模块。

这些页面需要向用户展示大量关于巴士的信息，同时座位布局的交互又要求流畅的渲染表现。

在线旅行预订（OTA）行业的「预订漏斗」（Booking Funnel）指用户从搜索、浏览、选择到最终支付的完整转化路径。每一层漏斗的页面都承载着大量结构化信息——以巴士预订为例，一个座位选择页面可能需要同时渲染 40-60 个座位的实时状态（可选、已售、不同价格等级）、车辆布局图、票价信息、设施标签等数百个可交互元素。传统 DOM 渲染在这种密度下容易触发频繁的布局回流，尤其在低端移动设备上会导致明显的卡顿。而 Redbus 服务的许多市场（如印度、印尼）用户使用的恰恰是中低端 Android 设备，这使得渲染性能优化具有直接的商业价值——更流畅的交互体验往往直接关联更高的转化率。

这正是 Canvas 高性能渲染的用武之地——而 HTML in Canvas 让这些页面在保持流畅的同时，依然能够被翻译、被无障碍工具识别。

场景二：AI 驱动的动态 UI 渲染

第二类应用场景更具前瞻性。Amit 认为，在 AI 驱动、UI 动态变化的场景中，HTML in Canvas 能够扮演非常重要的角色。

随着生成式 AI 的普及，越来越多的界面开始由 AI 实时生成和调整。AI 驱动的动态 UI 是指界面布局和内容不再由预设模板决定，而是根据用户意图、上下文信息和模型推理结果实时生成。例如，一个对话式预订界面可能根据用户的自然语言输入，动态生成包含座位推荐、价格比较和路线可视化的复合组件。这种模式对渲染引擎的要求远超传统 SPA（单页应用）——它需要在毫秒级时间内完成从数据到视觉的转换，同时保持界面的响应性。像 Vercel 的 AI SDK 中的 generative UI、以及各种 Agent 驱动的界面框架都在探索这个方向。

Canvas 的即时绘制特性天然适合这种高频更新场景，而 HTML in Canvas 则确保这些动态生成的内容不会成为可访问性的黑洞。它既能承载高频变化的复杂界面，又能保留 Web 的语义能力，理论上是 AI 时代前端渲染的理想载体。

落地进展：多个 POC 正在验证

说个细节，Redbus 目前仍处于概念验证（Proof of Concept）阶段。据 Amit 透露，团队正在预订漏斗（booking funnel）中的多个环节测试这项技术，重点集中在巴士详情和座位布局这两个信息展示最密集的模块。

这种谨慎而聚焦的落地策略颇具参考价值：先在信息密度高、性能敏感的核心页面验证效果，而非盲目全面铺开。对于任何考虑引入新渲染范式的团队而言，这都是一种务实的做法。

技术分析与未来展望

HTML in Canvas 的出现，反映了 Web 平台在渲染层面的一次重要探索方向。它试图解决的是一个长期存在的结构性矛盾：性能与语义能力的对立。

从技术演进的角度看，这一方案至少带来了几点启示：

• 降低了 Canvas 的使用门槛：过去采用 Canvas 意味着要放弃可访问性和翻译等能力，如今这一代价被大幅削减。
• 为 AI 时代的动态界面提供基础设施：当 UI 越来越多地由模型实时生成，一个既高性能又保留语义的渲染方案将变得愈发关键。
• 来自真实业务的验证：Redbus 这样体量的平台在真实预订流程中测试，本身就为该技术的实用性提供了背书。

值得注意的是，HTML in Canvas 并非唯一在探索这一方向的方案。业界已有先例可循：Google Docs 在 2021 年将其渲染引擎迁移至基于 Canvas 的方案以获得更精确的排版控制；Figma 从一开始就采用 Canvas/WebGL 渲染加隐藏 DOM 语义层的架构。这些实践证明了「Canvas 渲染 + DOM 语义」双层架构的可行性，而 HTML in Canvas 可能是将这种模式进一步标准化和通用化的尝试。

当然，作为一项仍在 POC 阶段的技术，它的成熟度、浏览器兼容性以及大规模落地表现仍有待观察。但方向本身无疑令人振奋——正如 Amit 所说，团队「非常期待看到它最终的效果」。

对于关注 Web 前端性能与体验平衡的开发者而言，HTML in Canvas 值得持续跟进。

核心要点