性能
On this page

性能

¥Performance

本文档尚处于草稿阶段,我们将很快添加更多实用信息,但我们希望尽早沟通我们的方法。

Remix 的设计初衷是鼓励你充分利用分布式计算的性能特性,而不是像 SSG 那样规定一个包含所有约束的精确架构。

¥Instead of prescribing a precise architecture with all of its constraints like SSG, Remix is designed to encourage you to leverage the performance characteristics of distributed computing.

当然,发送给用户最快的方式是 CDN 上靠近用户的静态文档。直到最近,服务器几乎只在世界的一个地区运行,这导致其他地方的响应速度很慢。这或许是 SSG 如此受欢迎的原因之一,它允许开发者将数据 "cache" 转换为 HTML 文档,然后分发到世界各地。它也有很多缺点:构建时间、构建复杂性、为翻译而重复网站、无法将其用于经过身份验证的用户体验、无法将其用于非常大且动态的数据源(例如我们的项目 unpkg.com!)等等。

¥The fastest thing to send to a user is, of course, a static document on a CDN that's close to the user. Until recently, servers pretty much only ran in one region of the world, which made for slow responses everywhere else. This is perhaps one reason SSG gained so much popularity, it allowed developers to essentially "cache" their data into HTML documents and then distribute them across the world. It comes with a lot of tradeoffs too: build times, build complexity, duplicate websites for translations, can't use it for authenticated user experiences, can't use it for very large and dynamic data sources (like our project unpkg.com!) to name a few.

边缘

¥The Edge

(不,不是 U2 的家伙。)

¥(No, not the U2 guy.)

如今,分布式计算 "在边缘" 正在发生许多激动人心的事情。计算 "在边缘" 通常意味着在靠近用户的服务器上运行代码,而不是只在一个地方(例如美国东海岸)。我们也看到分布式数据库正在走向边缘。我们期待这一切已经有一段时间了,这就是 Remix 如此设计的原因。

¥Today there are a lot of exciting things happening with distributed computing "at the edge". Computing "at the edge" generally means running code on servers close to users instead of just one place (like the US East Coast). We're not only seeing more of this, but we're seeing distributed databases moving to the edge as well. We've been anticipating all of this for a while, that's why Remix is designed the way it is.

由于分布式服务器和数据库在边缘运行,现在可以以与静态文件相当的速度提供动态内容。你可以提高服务器速度,但无法对用户的网络进行任何操作。剩下唯一要做的就是将代码从浏览器包中取出并上传到服务器,从而减少网络字节数,并提供无与伦比的 Web 性能。这就是 Remix 的设计目的。

¥With distributed servers and databases running at the edge, it's now possible to serve dynamic content at speeds comparable to static files. You can make your server fast, but you can't do anything about the user's network. The only thing left to do is to get code out of your browser bundles and onto the server, sending fewer bytes over the network, and provide unparalleled web performance. That's what Remix is designed to do.

本网站 + Fly.io

¥This Website + Fly.io

这个网站的首字节时间(time-to-first-byte)非常难对付。对于世界上大多数人来说,这个时间都在 100 毫秒以下。我们可以修复文档中的拼写错误,并在一两分钟内在全球范围内更新网站,无需重建、无需重新部署,也无需 HTTP 缓存。

¥This very website has a time-to-first-byte that's hard to beat. For most people in the world it's under 100 ms. We can fix a typo in the docs, and within a minute or two the site is updated across the world without a rebuild, without redeploying, and without HTTP caching.

我们通过分布式系统实现了这一点。该应用在 Fly 的全球多个区域运行,因此它离你很近。每个实例都有自己的 SQLite 数据库。应用启动时,它会从 GitHub 上的 Remix 源码库获取 tarball,将 Markdown 文档处理成 HTML,然后将其插入 SQLite 数据库。

¥We accomplished this with distributed systems. The app runs in several regions on Fly around the world so it's close to you. Each instance has its own SQLite database. When the app boots, it fetches tarballs from the Remix source repository on GitHub, processes the Markdown docs into HTML, and then inserts them into the SQLite database.

所涉及的代码实际上与 Gatsby 网站在 Next.js 中构建 gatsby-node.jsgetStaticProps 时可能执行的操作非常相似。其想法是将运行缓慢的部分(从 GitHub 获取文档、处理 Markdown)缓存起来(SSG 缓存到 HTML 中,本网站缓存到服务器上的 SQLite 中)。

¥The code involved is actually really similar to what a Gatsby site might do at build time in gatsby-node.js or getStaticProps in Next.js. The idea is to take the slow parts (fetching docs from GitHub, processing Markdown) and cache it (SSG caches into HTML, this website caches into SQLite on the server).

当用户请求页面时,应用会查询其本地 SQLite 数据库并发送该页面。我们的服务器在几毫秒内完成这些请求的处理。这种架构最有趣的地方在于,我们不必为了保持新鲜度而牺牲速度。当我们在 GitHub 上编辑文档时,GitHub 操作会调用最近的应用实例上的 webhook,该实例随后会将该请求重放至全球所有其他实例。然后,它们都会从 GitHub 拉取新的 tarball,并将其数据库与文档同步,就像它们启动时一样。文档会在一两分钟内在全球范围内更新。

¥When users request a page, the app queries its local SQLite database and sends the page. Our server is done with these requests in a few milliseconds. What's most interesting about this architecture is that we don't have to sacrifice speed for freshness. When we edit a doc on GitHub, a GitHub action calls a webhook on the nearest app instance, which then replays that request to all the other instances across the world. Then they all pull the new tarball from GitHub and sync their database with the docs just like they did when they booted. The docs are updated within a minute or two across the world.

但这只是我们想要探索的一种方法。

¥But this is just one approach that we wanted to explore.

Cloudflare Workers

Remix Cloudflare Workers 演示

¥Remix Cloudflare Workers Demo

Cloudflare 一直在突破边缘计算的界限,而 Remix 则致力于充分利用它。你可以看到我们演示的响应时间与提供静态文件相同,但它演示的功能绝对不是静态的!

¥Cloudflare has been pushing the boundaries of edge computing for a while now, and Remix is positioned to take full advantage of it. You can see our demo's response times are the same as serving static files, but the features it demonstrates are definitely not static!

Cloudflare 不仅在靠近用户的地方运行应用;他们还拥有像 KV持久对象 这样的持久存储系统,以实现 SSG 级别的速度,而无需将数据与部署和定制的增量构建器后端耦合。

¥Not only does Cloudflare run the app close to the user; they also have persistent storage systems like KV and Durable Objects to allow SSG-level speed without the handcuffs of coupling data to deploys and bespoke, incremental-builder backends.

我们计划很快支持其他类似的平台。

¥There are other similar platforms that we've got plans to support soon.

Bundle 分析

¥Bundle analysis

本文档仅在使用 Classic Remix 编译器 时适用。

Remix 将元文件输出到服务器构建目录(默认为 build/),以便你分析包的大小和组成。

¥Remix outputs metafiles to the server build directory (build/ by default) so you can analyze your bundle size and composition.

  • metafile.css.json:CSS 包的元文件

    ¥metafile.css.json : Metafile for the CSS bundle

  • metafile.js.json:浏览器 JS 包的元文件

    ¥metafile.js.json : Metafile for the browser JS bundle

  • metafile.server.json:服务 JS 包的元文件

    ¥metafile.server.json : Metafile for the serve JS bundle

Remix 使用 esbuild 的元文件格式,因此你可以将这些文件直接上传到 [https://esbuild.github.io/analyze/]https-esbuild-github-io-analyze 以可视化你的 bundle。

¥Remix uses esbuild's metafile format, so you can directly upload those files to https://esbuild.github.io/analyze/ to visualize your bundle.

其他技术

¥Other Technologies

以下是一些有助于提升服务器速度的其他技术:

¥Here are some other technologies to help speed up your servers:

  • FaunaDB — 一个靠近用户运行的分布式数据库。

    ¥FaunaDB — A distributed database that runs close to your users

  • LRU 缓存 — 一个内存缓存,空间已满时会自动清理。

    ¥LRU Cache — An in-memory cache that automatically clears out more space when it gets full

  • Redis — 一个久经考验的服务器端缓存

    ¥Redis — A tried and true server-side cache

Remix v2.17 中文网 - 粤ICP备13048890号