Remix vs Next.js メモ

DonTacos

翻訳メモ
https://remix.run/blog/remix-vs-next

  • RemixはNext.jsと同等以上の速度で静的コンテンツを提供できる

  • RemixはNext.jsよりも動的コンテンツの配信が速い

  • 低速ネットワークでも高速なユーザーエクスペリエンスを実現するRemix

  • Remixはエラー、割り込み、レースコンディションを自動的に処理するが、Next.jsは処理しない

  • Next.jsは動的なコンテンツを提供するためにクライアントサイドのJavaScriptを推奨しているが、Remixはそうではない。

  • Next.jsはデータ変異のためにクライアント側のJavaScriptが必要だが、Remixは必要ない

  • Next.jsのビルド時間はデータに応じて直線的に増加しますが、Remixのビルド時間はデータから切り離され、ほぼ一瞬です。

  • Next.jsでは、アプリケーションのアーキテクチャを変更する必要があり、データのスケーリング時にパフォーマンスを犠牲にしなければならない

  • Remixの抽象化は、より良いアプリケーションコードにつながると考えています。



Self-Descriptions

Next.js describes itself as:

プロダクション向けReactフレームワーク。Next.js は、静的とサーバーのハイブリッドレンダリング、TypeScript のサポート、スマートバンドル、ルートのプリフェッチなど、プロダクションに必要なすべての機能で最高の開発者体験を提供します。設定は不要です。

Vercelは、静的サイトとフロントエンドフレームワークのためのプラットフォームで、ヘッドレスコンテンツ、コマース、データベースと統合するために構築されています。

We describe Remix as:

Remixは、モダンで高速、かつ弾力性のあるユーザー体験を構築するための、エッジネイティブなフルスタックJavaScriptフレームワークです。クライアントとサーバーをウェブの基礎と統合することで、コードのことを考えず、製品について考えることができます。


Home Page, Visually Complete

Is Remix as fast as Next.js?

どれも同じように速く、同じような印象

https://remix.run/blog-images/posts/remix-vs-next/wpt-virginia-homepage-cable-slow.gif

Why The Apps Are Fast

Next.jsが速い理由。ホームページは、getStaticPropsによるSSG（Static Site Generation）を採用しています。ビルド時にNext.jsはShopifyからデータを取得し、ページをHTMLファイルにレンダリングして、publicディレクトリに置きます。サイトがデプロイされると、静的ファイルは単一の場所にあるオリジンサーバーを叩くのではなく、エッジで（VercelのCDNから）提供されるようになります。リクエストが来ると、CDN は単にファイルを提供します。データの読み込みとレンダリングはすでに先行して行われているので、訪問者はダウンロードとレンダリングのコストを支払う必要はない。また、CDNはユーザーの近く（これが「エッジ」）にグローバルに分散されているので、静的に生成されたドキュメントへのリクエストは、単一のオリジンサーバーまで移動する必要がない。


Remixのポートが速い理由。RemixはSSGをサポートしていないので、HTTP stale-while-revalidate caching directive（SWR、Vercelのswr client fetching packageと混同しないでください）を使用しました。最終結果は同じです：エッジで静的なドキュメント（同じCDN、Vercelのものであっても）。違いは、ドキュメントがそこに到達する方法です。

stale-while-revalidate応答指示は、キャッシュに再検証している間、キャッシュが古くなった応答を再利用できることを示す。

ビルド/デプロイ時にすべてのデータを取得してページを静的ドキュメントにレンダリングするのではなく、トラフィックがあるときにキャッシュを呼び出すのである。ドキュメントはキャッシュから提供され、次の訪問者のためにバックグラウンドで再バリデーションされます。SSGのように、トラフィックがあるときは、ダウンロードとレンダリングのコストを訪問者が負担することはありません。キャッシュミスが気になる方は、後ほど説明します。

SWRはSSGに代わる素晴らしい製品です。もう一つ、Vercelへのデプロイが素晴らしいのは、彼らのCDNがそれをサポートしていることです。

なぜRemixの移植はNext.jsほど高速でないのかと思われるかもしれません。Remixには画像の最適化が（まだ）組み込まれていないので、Next.jsのアプリに画像を向けるだけです。ブラウザは両方のドメインへの接続を開く必要があり、これにより画像の読み込みが0.3秒遅れます（これはネットワークのウォーターフォールで確認できます）。もし画像がセルフホスティングであれば、0.7秒程度で他の2つと同程度になるでしょう。

Remixの書き換えが速い理由。SSGやSWRでエッジにドキュメントをキャッシュするのではなく、Redisでエッジにデータをキャッシュするようにしました。実際、Fly.ioを使ってアプリケーションもエッジで動作させています。最後に、永続的なボリュームに書き込む画像最適化Resource Routeを搭載しています。これは基本的に独自のCDNです。

数年前までは難しかったかもしれませんが、この数年でサーバーの状況は大きく変化し、さらに良くなっています。


Bottom Line

Remixの偽りのないシンプルな<Form> + アクション + ローダーAPIと、可能な限りサーバに負荷をかけない設計に、その力を見逃すことは容易です。それはゲームを変えます。これらのAPIはRemixの高速なページロード、高速なトランジション、変異（中断、競合状態、エラー）に対する優れたUX、そして開発者にとってよりシンプルなコードの源となっています。

Remixアプリは、バックエンドインフラとプリフェッチから速度を得ています。Next.jsはSSGから速度を得ています。SSGは使用例が限られているため、特に機能やデータの規模が大きくなると、そのスピードは失われます。

SSGやJamstackは、遅いバックエンド・サービスに対する素晴らしい回避策でした。最新世代のプラットフォームやデータベースは高速で、さらに速くなっています。これらのアプリを支えているShopifyのAPIでさえ、世界中のどこからでも200msでクエリに対するレスポンスを送信することができるのです

もし、あなたが遅いバックエンドAPIを持っているなら、バックエンドを速くするために時間を投資してください。もしあなたがそれをコントロールできないのであれば、あなた自身のサーバーをデプロイし、そこにキャッシュを置くことで、すべてのユーザーに対してどんなページでも高速化することができます。

バックエンドに投資することで、SSGと同じパフォーマンス結果が得られますが、どんな種類のページにも対応できるように拡張できます。SSGよりも初期作業が必要ですが、ユーザーとコードのために長期的には価値があると考えています。

データのロードも半分だけです。Remixでは、データの抽象化により、データの変異をカプセル化することもできます。すべてのコードはサーバに残り、より良いアプリケーションコードとブラウザの小さなバンドルにつながります。


この記事が気に入ったらサポートをしてみませんか？