Remix 的設計理念是鼓勵您利用分散式運算的效能特性，而不是像 SSG 那樣規定一種精確的架構及其所有限制。
當然，傳送給使用者最快的方式是 CDN 上靠近使用者的靜態文件。直到最近，伺服器幾乎都只在全球的一個地區運作，這導致其他地方的回應速度很慢。這或許是 SSG 如此受歡迎的原因之一，它允許開發人員將其資料「快取」到 HTML 文件中，然後將其分發到世界各地。它也帶來了很多權衡：建置時間、建置複雜度、翻譯的重複網站、無法用於經過身份驗證的使用者體驗、無法用於非常龐大且動態的資料來源（例如我們的專案 unpkg.com！），僅舉幾例。
（不，不是 U2 的那個傢伙。）
今天，「邊緣」的分散式運算方面有很多令人興奮的事情正在發生。「邊緣運算」通常是指在靠近使用者的伺服器上執行程式碼，而不僅僅是在一個地方（例如美國東海岸）。我們不僅看到越來越多這種情況，而且也看到分散式資料庫正在轉向邊緣。我們已經預期這一切一段時間了，這就是為什麼 Remix 的設計方式如此。
隨著分散式伺服器和資料庫在邊緣運作，現在可以以與靜態文件相當的速度提供動態內容。您可以讓您的伺服器快速運作，但您對使用者的網路無能為力。唯一剩下的事情就是將程式碼從您的瀏覽器套件移到伺服器上，減少在網路上傳送的位元組，並提供無與倫比的網路效能。這就是 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.dev.org.tw/analyze/ 來視覺化您的套件。
以下是一些可以幫助加速伺服器的其他技術
