为 Chrome 进行开发的原则。这些最佳实践的重点是确保功能尽可能高效地实现。
内容区域（标签页中的 UI）
在桌面平台上，位于内容区域的 UI 应使用 HTML 技术实现。（在 Android 和 iOS 上，内容区域的 UI 可以使用 Web 或原生技术实现。）这个 HTML 可以是 WebUI，也可以是与 Chrome 捆绑的普通 HTML 和 JS。它应能够在无网络连接和低质量连接的情况下工作。期望实现的内容不包含兼容其他浏览器的填充代码或使用复杂的 Web 开发技巧。
非内容区域（弹出窗口或 Chrome 自身的 UI）
内容区域外的 UI 应使用 Views（C++）在 Windows/Linux/ChromeOS 上实现。Mac 上的 UI 使用 Cocoa 实现，不过也在进行 Views 的移植工作。期望这种类型的 UI 限于小型、临时窗口，且 UI 复杂度较低。在 Clank（Chrome for Android）上，这种 UI 应使用 Android View 系统实现。
操作任意页面上的 DOM
某些功能需要检查或修改当前标签页的 DOM，这些页面可以是任意网站。Blink 的 Web* C++ API 刻意保持简单且有限，以引导你仅在实际需要时使用它。当 Blink 的 C++ API 不可行时，可以使用隔离世界脚本注入。注入的脚本应尽可能精简，不应包含处理其他浏览器的代码（例如 Closure）。
由于脚本注入会带来运行时和内存成本，因此预期它是由用户操作驱动的，并且用户对这项工作的期望是明确的。一个好的例子是“翻译”。如果需要检查用户可能打开的每个页面，则不推荐使用脚本注入。对于这种情况，请咨询 chrome-eng-review@ 以寻求合适的解决方案。例如，阅读模式将触发逻辑从脚本注入转换为原生实现。
原型设计和探索解决方案空间
可以通过扩展进行实验。非机密功能可以发布在 Chrome 网上应用店，并手动安装以进行早期测试。机密扩展可以仅为受信任的测试人员启用，从而对公众不可见。扩展可以使用内容脚本进行脚本注入，并可以使用页面操作和浏览器操作在内容区域外提供 UI。扩展还可以使用 NaCL，其拥有对 Pepper API 的完全访问权限。
组件扩展（即自动安装到 Chrome 中的扩展）也是原型设计的一个选项，但应仅在常规扩展无法完成某些任务时使用。扩展应尽量只在明确的用户操作下执行，而不应在启动时执行。应避免使用持久背景页。事件页应仅用于不频繁的项目，如推送消息、硬件事件、闹钟等……但不应用于常见事件，如导航。如果需要执行某些会带来持续负载或需要在每次导航时更新状态的操作，请咨询扩展团队；他们可能能够提供一个声明性 API 以低影响完成工作。如果没有可行的办法，请咨询 chrome-eng-review@ 如果你需要偏离这些指南。