Performance
表现
Remix 的设计目的是为了鼓励您利用分布式计算的性能特征，而不是像 SSG 那样规定一个具有所有约束的精确架构。
当然，发送给用户最快的东西是靠近用户的 CDN 上的静态文档。直到最近，服务器几乎只在世界的一个地区运行，这导致其他地方的响应速度很慢。这也许是 SSG 如此受欢迎的原因之一，它允许开发人员将他们的数据缓存到 HTML 文档中，然后将它们分发到世界各地。它也有很多权衡：构建时间、构建复杂性、重复网站进行翻译、不能将其用于经过身份验证的用户体验、不能将其用于非常大且动态的数据源（例如我们的项目 unpkg.com！）等等。
边缘
（不，不是 U2 歌手。）
如今，分布式计算边缘领域发生了许多令人兴奋的事情。边缘计算通常意味着在靠近用户的服务器上运行代码，而不仅仅是在一个地方（如美国东海岸）。我们不仅看到了更多这样的情况，而且我们还看到分布式数据库正在向边缘移动。我们期待这一切已经有一段时间了，这就是 Remix 如此设计的原因。
借助在边缘运行的分布式服务器和数据库，现在可以以与静态文件相当的速度提供动态内容。您可以让服务器运行得更快，但无法对用户网络做任何事情。剩下要做的唯一事情就是将代码从浏览器包中取出并放到服务器上，通过网络发送更少的字节，并提供无与伦比的 Web 性能。这就是 Remix 的设计目标。
本网站 + Fly.io
该网站的首字节响应时间无可匹敌。对于世界上大多数人来说，响应时间不到 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 工作者
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.github.io/analyze/ 来可视化您的包。
其他技术
以下是一些可帮助加快服务器速度的其他技术：