Remix 的设计旨在鼓励您利用分布式计算的性能特性,而不是像 SSG 那样规定具有所有约束的精确架构。
发送给用户最快的东西当然是靠近用户的 CDN 上的静态文档。直到最近,服务器几乎只在世界的某个区域运行,这使得其他地方的响应速度很慢。这也许是 SSG 如此受欢迎的原因之一,它允许开发人员将数据“缓存”到 HTML 文档中,然后在世界各地分发。它也带来许多权衡:构建时间、构建复杂性、翻译的重复网站、不能用于经过身份验证的用户体验、不能用于非常大型和动态的数据源(例如我们的项目 unpkg.com!)等。
(不,不是 U2 的那位。)
今天,分布式计算“在边缘”发生了很多令人兴奋的事情。“在边缘”计算通常意味着在靠近用户的服务器上运行代码,而不是只在一个地方(如美国东海岸)。我们不仅看到这种情况越来越多,而且还看到分布式数据库也在向边缘迁移。我们已经预料到这一切有一段时间了,这就是 Remix 设计成现在这样的原因。
随着分布式服务器和数据库在边缘运行,现在可以以与静态文件相当的速度提供动态内容。您可以使您的服务器速度很快,但您对用户的网络无能为力。剩下的唯一的事情就是将代码从浏览器捆绑包中取出并放到服务器上,减少通过网络发送的字节数,并提供无与伦比的 Web 性能。这就是 Remix 的设计目的。
本网站的首次字节时间难以匹敌。对于世界上大多数人来说,它都在 100 毫秒以下。我们可以在文档中修复一个错别字,在一两分钟内,该网站将在世界各地更新,无需重建、无需重新部署,也无需 HTTP 缓存。
我们通过分布式系统实现了这一点。该应用程序在世界各地的 Fly 上的多个区域运行,因此它靠近您。每个实例都有自己的 SQLite 数据库。当应用程序启动时,它从 GitHub 上的 Remix 源代码存储库中获取 tarball,将 markdown 文档处理为 HTML,然后将其插入到 SQLite 数据库中。
所涉及的代码实际上与 Gatsby 站点在构建时的 gatsby-node.js
或 Next.js 中的 getStaticProps
中所做的非常相似。其思想是将慢速部分(从 GitHub 获取文档,处理 markdown)缓存起来(SSG 缓存到 HTML 中,本网站缓存到服务器上的 SQLite 中)。
当用户请求页面时,应用程序会查询其本地 SQLite 数据库并发送页面。我们的服务器在几毫秒内完成这些请求。关于这种架构最有趣的是,我们不必为了新鲜度而牺牲速度。当我们在 GitHub 上编辑文档时,GitHub 操作会在最近的应用程序实例上调用一个 webhook,然后该请求将重播到世界各地的所有其他实例。然后,它们都会从 GitHub 中拉取新的 tarball,并像启动时一样同步其数据库与文档。文档会在一两分钟内在世界各地更新。
但这只是我们想要探索的一种方法。
Cloudflare 一直在推动边缘计算的边界,Remix 旨在充分利用它。您可以看到我们的演示的响应时间与提供静态文件相同,但它演示的功能绝对不是静态的!
Cloudflare 不仅在靠近用户的区域运行应用程序,他们还拥有持久存储系统,如 KV 和 Durable Objects,允许实现 SSG 级别的速度,而无需将数据耦合到部署和定制的、增量构建器后端。
我们计划很快支持其他类似的平台。
Remix 将元文件输出到服务器构建目录(默认情况下为 build/
),以便您可以分析捆绑包大小和组成。
metafile.css.json
:CSS 捆绑包的元文件metafile.js.json
:浏览器 JS 捆绑包的元文件metafile.server.json
:服务器 JS 捆绑包的元文件Remix 使用 esbuild 的元文件格式,因此您可以直接将这些文件上传到 https://esbuild.org.cn/analyze/ 以可视化您的捆绑包。
以下是一些其他技术,可帮助您加快服务器速度