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/ 来可视化你的捆绑包。
以下是帮助加快服务器速度的其他一些技术
