この動画は、React Server Components(RSC)の実際のパフォーマンスを、Client Side Rendering(CSR)やServer Side Rendering(SSR)と詳細に比較した技術解説である。開発者Nadiaによる綿密なベンチマーク結果を基に、各レンダリング手法がLCP(Largest Contentful Paint)、インタラクティブ性、データフェッチングのタイミングにどう影響するかを分析している。結論として、RSC単体では劇的な改善は見られないが、サーバーサイドでのデータフェッチングとストリーミング、Suspense境界を適切に組み合わせることで、初期ロードとインタラクティブ性のバランスが最適化されることが明らかになった。ただし、この恩恵を受けるには、アプリ全体のアーキテクチャを再設計する必要があり、開発者にとっては大きな労力を要する。
React Server Componentsへの懐疑から理解へ
最初にServer Componentsのプレビューを見たときのことを今でも覚えています。私はすごく懐疑的でした。その中ではawaitすら呼べませんでした。すべてに独自の魔法のような構文がありました。どのコンポーネントがサーバーでどれがクライアントかを示すために、ファイルに異なる名前を付ける必要がありました。
そして、私が求めていた変更が加えられて、この動作をすべて可能にする新しい魔法のようなuse serverとuse clientディレクティブを見たとき、私は本当に怖くなりました。これが自分に合うとは思えませんでした。そして、皆さんの多くがこの時点でおそらくご存知のように、私は間違っていて、結局Server Componentsを本当に本当に気に入るようになり、その主な擁護者になるほどでした。
それでも今、私が構築して本番環境にデプロイするアプリのほとんどでは、Server Componentsをあまり頻繁に使っていないことに気づきます。アプリのより良いシェルを作るようなことには使おうとしています。でも、T3 Chatのようなものは基本的にそれらをまったく使っていません。単にReact Routerをそこに入れているだけです。だから、このブログ投稿が出てきたのを見たとき、ちょっと怖かったけど、同時にワクワクもしました。
パフォーマンスの疑問
Server Componentsは実際にパフォーマンスを改善しているのでしょうか。理論的には、そうあるべきです。Server Componentsは、動的である必要のないコードがクライアントに全く送られない、魔法のような完璧なソリューションであるべきです。HTMLだけを送って、残りはすべてサーバー側で処理します。
Server Componentsを開発者とユーザーの両方にとって素晴らしい体験にするはずのものがたくさんあります。でも、パフォーマンスの数字が出ていなければ、結局のところこれらは何の意味もありません。そして、私はデータを指し示すことができるときは、できる限り客観的であろうとしています。そして歴史的に、私が本当に頼りにできるほどのデータはありませんでした。
だから、Nadiaがここに書いたものに飛び込んで、Server Componentsの実際のパフォーマンスがどのようなものか、そしてこれがすべて価値があったのか、それとも完全に間違った方向に進んだのかを議論できることに、本当にワクワクしています。Server Componentsへの愛にもかかわらず、私は実際にはReactチームにもVercelにも報酬をもらっていません。だから、今日のスポンサーのために少し休憩が必要です。
片手でコーディングするよりも難しいことを知っていますか。開発者として良いコーディングリソースを見つけることです。ウェブ上のすべてのAIのゴミで、今では実際に信じられないほど難しくなっています。実際に経験豊富な実在の開発者からの良いリソースがあればいいのにと思います。YouTubeで安っぽいチュートリアルを量産している人たちだけでなく。
ありがたいことに、今日のスポンサーであるFrontend Mastersがまさにそのためにここにいます。コーディングの仕方を教えるだけでなく、より上級でより才能ある全体的なエンジニアになるためにスキルをレベルアップするのに役立つチュートリアルです。そして、彼らのコースを特別なものにしているのは、それを作っている人々です。これらはフルタイムのコンテンツクリエイターや開発インフルエンサーによって作られたものではありません。実際の会社で働いている経験豊富なエンジニアによって作られています。
TerminalのPrimeのような人々、まあ、Primeは実際にはあまりカウントされないと思いますが、databricksのBrian Holtやzed.devのRichardのような人々です。Zedほどコンパイラを理解している人はほとんどいません、控えめに言っても。またはMicrosoftとXstateのDavidのような人で、ステート管理の仕事に関しては最も才能あるエンジニアの一人です。Netflixのスコットなど、他にもたくさんいます。
私は定期的に、さまざまなコースのリストを見て、誰がそれらを作ったのかを見て驚いています。実際、9月17日のJavaScript Hard Partsストリームをとても楽しみにしています。興味があればチェックしてみてください。きっとすごく楽しいと思います。でも、ここで得られる価値は狂っています。250以上のコースが安い月額サブスクリプションで利用できます。
そして、あなたの会社が支払ってくれるかもしれません。すでに安いですが、私のリンクを使えば25%オフになります。これらすべてのリソースへのアクセスにとって、それは信じられないほどの取引です。最高から学びたいですか。今日soyv.link/mastersでチェックしてみてください。
Nadiaの実験について
これについて実際のデータがあることにとてもワクワクしています。私自身でこのようなものを構築すべきでしたが、控えめに言っても忙しいのです。Server Componentsについて聞いたことがありますか。おそらくあるでしょう。ここ数年のReactコミュニティで誰もが話していることのすべてです。それはまた最も誤解されている概念でもあります。完全に正直に言うと、私もしばらくの間その意味を理解していませんでした。私の実践的な頭脳にとっては、あまりにも概念的すぎます。
それは確かに、私たちが通常生きているコンポーネントの内部の細部を考えると、かなり概念的で高レベルです。Server Componentsがルートから始まらなければならないという事実だけでも、最初に把握するのは比較的直感的ではありません。Server Componentsが導入されるずっと前に、Next.jsとget serverside propsのようなAPIでサーバー上のデータをフェッチすることができました。
では、違いは何でしょうか。まあ、serverside propsは今まで定義された中で最悪のAPIのようなものです。本当に面白いです。人々は現在のAPIについて怒っていますが、まるでserverside propsに触れたことがないかのようです。それは文字通りあらゆる意味で最悪でした。現在Server Componentsで持っているものと比較して、測定可能なあらゆる形式でダウングレードです。
でも、この会話をするにはserverside propsが存在しないふりをしなければなりません。なぜなら、そうでなければ私はただ怒っているだけになってしまうからです。なぜなら、私はそのAPIがものすごく嫌いだったからです。ああ、get serverside propsを忘れていました。私のNext 12プロジェクトで毎日それを使わなければなりません。ええ。面白い事実ですが、私のブログは元々、AirPods Maxがどれだけ嫌いかをネタにしたくて始めました。
でも、YouTubeに出る前に少しまた投稿し始めた理由は、4年前のNext.jsでの型安全性のストーリーがどれほどひどかったかについて文句を言いたかったからです。時間が経つのは本当に早いですね。でも、これはすべてget serverside propsの悲惨さについての私の不満でした。
ここでget serverside propsの例を持っていて、このコンポーネントにデータを取得していましたが、userが存在するかどうかわかりません。なぜなら、コンポーネントで返されるものがわからないからです。なぜなら、それは渡される魔法のようなものだからです。手動で型付けすることはできます。だから、userをPrisma clientのuserとして定義できます。でも、userからIDだけをselectしたり、異なるサブセットをselectしたらどうなるでしょう。
正しいデータを渡している保証はありません。なぜなら、これはページに定義されている2つの魔法のようなものだからです。デフォルトのページ関数があり、これはコンポーネントで、そしてget serverside関数があります。そして、これらの間には関係がありません。私は人生の中で、なぜこれがRemixでコピーされた部分なのか理解できません。なぜなら、ここでは悪かったです。
Remixではもっとひどかったです。とにかく、でも、私は4年間意味をなさなかったAPIについて不平を言い続けたくありません。Nadiaはここでかなりの比較をしました。彼女は実装の観点からだけでなく、異なるレンダリング技術とそれぞれのさまざまなバリエーションにおけるパフォーマンスへの影響の両方で、パターンがどのように異なるかを比較しました。これにより、すべてがついに彼女にとって腑に落ちたようです。
だから、うまくいけば、Server Componentsがクリックしていない時点にいる場合、この記事を読み通すことで私たち全員がそこに到達できるでしょう。これはまさに記事が行っていることです。Client Side Rendering、Server Side Rendering、そしてServer Componentsがすべてどのように実装されているかを調べます。それぞれについてJSとデータがネットワークを通じてどのように移動するか、そしてClient Side RenderingからServer Side Rendering、そしてServer Componentsへの移行のパフォーマンスへの影響について調べます。なぜなら、これらはすべて異なるからです。
人々はSSRとRSCが同じものだと思っているようです。これらはReactのためのserverという言葉が入った3文字です。でもRSCは、クライアントでレンダリングするコンポーネントをサーバーでもレンダリングするだけです。Server Componentsはサーバー上でのみ実行されるコンポーネントです。大きな違いです。これをすべて測定するために、セミリアルなマルチページアプリを作りました。だから楽しいでしょう。実験を自分で再現したい場合のために、GitHubで利用可能です。
初期ロード、Client Side Rendering、Server Side Rendering、Chromeのパフォーマンスタブ、そしてそれを読む方法について少なくとも聞いたことがあると想定しています。復習が必要ですか。ここにいくつかの記事があります。そして繰り返しますが、記事と著者は常にディスクリプションにリンクされています。Nadiaはこれで素晴らしい仕事をしたので、まだフォローしていない場合は、ぜひフォローしてください。
これは非常に良い投稿であり、このように良いものを書く著者は注目に値します。彼女はまた、ウェブパフォーマンスの基礎に関する本を持っていて、本当に本当に良さそうです。そして、これまで見たものから判断すると、おそらく価値ある購入だと思います。CJは私のコミュニティで最も信頼されている人の一人で、Nadiaが書いた上級React本も本当に良いと言っています。そして、私は自分の言葉よりも彼の言葉を信じます。きっと素晴らしいでしょう。
これらはすべてディスクリプションにリンクされています。プロジェクトの紹介です。インタラクティブで美しいウェブサイトを測定するために。ページの1つはこのように見えます。受信トレイがあります。ページ上のいくつかのデータは動的で、RESTエンドポイント経由でフェッチされます。つまり、左側のサイドバーのアイテムは/api/sidebar経由でフェッチされ、右側のメッセージは/api/messages経由でフェッチされます。
サイドバーエンドポイントはかなり速く、実行に100ミリ秒かかります。メッセージエンドポイントは最大1秒かかります。誰かがバックエンドの最適化を忘れました。全く現実的ではありません。見てみたい場合は、プロジェクト全体がGitHubで利用可能です。では、測定しているものを定義しましょう。パフォーマンスに関しては、測定できるものが百万と一つあります。
パフォーマンスによってこのウェブサイトが良いか悪いかを言うことは、パフォーマンス、良い、悪いによって正確に何を意味するかを定義せずには不可能です。ああ、これはもう大好きです。これは非常に良い記事です。この特定の実験では、Server Componentsを含む異なるレンダリングとデータフェッチング技術の間のロードパフォーマンスの違いを見たいと思います。それらすべてを理解し、Server Componentsはパフォーマンスの観点から価値があるのかという質問に答えるために。
測定にはDevToolsのパフォーマンスタブを使用し、CPUは6倍のスローダウン、ネットワークはslow 4Gです。Chrome DevToolsを使用して、ブラウザ、コンピュータ、特にネットワークを任意に遅くすることができますが、6倍のスローダウンは異なるコンピュータで異なることを意味します。だから、必ずしも最良の方法ではありません。そして、CPUを遅くする方法は、必ずしも遅いデバイスの最良の表現ではありません。
あなたのものが遅いデバイスで動作することを確認したい場合は、遅いデバイスを購入してそれでテストしてください。それが知る唯一の方法です。しかし、これらはすべて非常に役立ちます。私はこれらのタイプのテストを少なくとも行うことをお勧めします。彼女はLCPを測定します。これはLargest Contentful Paintです。
スケルトンだけであっても、主要なコンテンツ、つまりコアコンテンツがレンダリングされるまでにどれくらい時間がかかるか、サイドバーのアイテムが表示されるのはいつか、つまりサイドバー上のものがいつ表示されるか、メッセージが表示されるのはいつか、つまりメッセージがいつ表示されるか、そしてページがインタラクティブになるのはいつか、つまり実際に物事をクリックして行動し、それらが機能することを期待できるのはいつかを測定します。
これらはLCPとして示されます。ページのスケルトンは存在するが、サイドバーと受信トレイがまだロードされていない場所です。次に、サイドバーがロードされているが、受信トレイがまだロードする必要がある状態です。次に、メッセージが入った受信トレイがロードされています。次に、ライトモードとダークモードを切り替えるボタンがインタラクティブになります。なぜなら、JSがロードされ、現在アクティブだからです。
これは重要な部分です。なぜなら、それが起こるタイミングは途中で変わる可能性さえあるからです。ああ、これは楽しい指摘です。開発環境ではすべてがHTTP1サーバーを使用しているため、HTTP1で並行して実行できるものの数の制限は6です。だから、本番環境では一度にロードできる数が限られているため、バッチ処理されていたであろうものが出てきます。
彼女は、実際のCDNで本番環境でどのように動作するかを確実にコピーしたかったのです。だから、caddyをリバースプロキシとして使用してCDNの動作を模倣することで、ローカルにそれを持っています。では、Client Side Renderingのパフォーマンスから始めましょう。CSRは、クライアント上で全体のスクリプトをロードし、その後スクリプトがデータをフェッチしに行くことを意味します。
ここでscriptとlinkがあります。これはCSSとJSがどこから来るかです。だから、HTMLをロードします。ブラウザはこれらを取得しに行きます。今、それらはブラウザのコンテキスト内に存在します。今、JSは実行でき、必要なことを行うことができます。そして、それまでは何も表示されません。この空のdivを美しいページに変換します。ブラウザはJSファイルをダウンロードして実行する必要があります。
ファイルには、ReactDevとして書くすべてのものが含まれます。だから、ここにReactコンポーネントがあります。レイアウト、サイドバー、メインコンテンツがあり、それから実際にルート要素にマウントするものがあります。そして、それまでは空のページです。React自体がエントリーポイントのappコンポーネントをDOMノードに変換します。次に、そのIDで空のdivを見つけて、それに応じて注入します。
だから、ここでパフォーマンスタブを見ると、HTML、JavaScript、JSが実行されるまで空の画面、次にペイント、次にフェッチコールを行い、データが入ってきたら残りのデータをレンダリングします。でも、ここで注目してください。重要なのは、HTMLがロードされても何も表示されないということです。JSがロードされても、まだ何も表示されません。JSが実行されて、今あなたは物事を見ることができます。
HTMLのロードとJSのロードだけでは、物事を見るのに十分ではありません。彼女が言うように、実際には、これははるかに混乱するでしょう。なぜなら、複数のJSファイルがあり、時には連鎖したCSSファイルがあり、メインセクションで他のたくさんのことが起こっているからです。プロジェクトの実際のプロファイルを記録すると、これが表示されます。
index.js、vendor.js、Radix Editor、date functions、そしてCSSがすべてありがたいことに並行してロードされていますが、コンテンツを見始める前に完了しなければならないすべてのものです。サイドバーメッセージのデータフェッチはJavaScript自体でトリガーされます。メッセージがフェッチされてから保存されるuse effectがあります。
この場合、ここではTanstack Queryを使用しています。Tanstack Query、いいですね。どんなデータフェッチフレームワークでも構いません。ここで重要なのは、データフェッチプロセスをトリガーするために、まずJSをダウンロード、コンパイル、実行する必要があることです。だから、それらすべてが最初に起こるまで、データは全くフェッチされていません。それがSPAで理解すべき重要なことです。
ページがロードされて、JavaScriptのロードをトリガーする必要があります。JavaScriptがロードされて実行され、次にフェッチする必要があるデータを把握し、そのすべてが完了した後、ようやくデータのフェッチを開始します。だから、JavaScriptがキャッシュされていないとき、この偽の遅いデバイスと遅い接続でJavaScriptを取得するのに非常に時間がかかるため、最初のペイントを得るのに最大4.1秒かかる可能性があります。
だから、画面上で何かを見るために4.1秒待っています。これが人々がClient Side Renderingを好まない理由です。それは本当に悪いです。それは誰かがあなたのウェブサイトが壊れていると思うのに十分な時間です。素晴らしい開発体験や学習曲線に関連するすべてのものを除いて、これらはそれ自体が大きな問題ですが、従来のウェブサイトと比較してSPAには2つの主な利点があります。なぜなら、明らかにこれは悪いからです。
では、なぜ私たちはこれをするのでしょうか。開発体験、学習曲線、その他いくつかの理由のためです。最初のものはパフォーマンスです。すべてがクライアント上にあり、サーバーとのやり取りがない場合、ページ間の遷移は信じられないほど速くなる可能性があります。これが、T3 Chatでシングルページアプリにした理由です。なぜなら、クリックする際にできるだけ速くしたかったからです。他のプロジェクトをクリックすると、今クリックしています。
今クリックしています。クリックするとすぐに、他のチャットが表示されます。なぜなら、すべてのデータをプリロードしているからです。そして、クリックすると、JavaScriptでレンダリングされるデータを変更しているだけです。ナビゲートするときは何もロードされていません。ええ。彼女の例では、ページ間のナビゲートには80ミリ秒しかかかりません。
それは可能な限りインスタントに近いです。もう1つの重要な点は、それが安いということです。ばかばかしいほど安いです。本当に複雑で、非常にインタラクティブで、リッチな体験を実装できます。Cloudflare CDNのようなものにアップロードします。月間数百万のユーザーがいても、無料プランに留まることができます。趣味のプロジェクト、学生プロジェクト、お金が重要な要素である大規模な潜在的なオーディエンスを持つものに最適です。
呼び出されているAPIが何であるかによります。公平に言うと、コストがサーバーサイドレンダリングが重要である本当の理由だという議論は、まだ思いません。私は自分のブログにこれについての記事を持っています。SSRがそれほど高価ではないということについては決して話しません。実際にはそうではありません。
これは私がTwitterで文句を言っていたことから始まりました。なぜなら、人々がこの誤解を持っていることにとてもイライラしていたからです。でも、SSRはそれほど高価ではありません。もしあなたがそれを本当に遅いレンダリングにゲーム化すれば。無料ではないかもしれませんが、事実上無料です。本当に安いです。SPAでは、サーバーも、メンテナンスも、CPUやメモリの監視も、スケーラビリティの問題もありません。では、何が気に入らないのでしょうか。
サーバーからのデータが必要な場合、これらのものは依然として必要です。単にそのサーバー上でReactをレンダリングしていないだけです。そして、それらの4秒のロード時間は見た目ほど悪くありません。これはユーザーが最初に訪問したときだけ起こりますが、新しいコードをプッシュアップするたびにも起こります。確かに、ランディングページには受け入れられませんが、ユーザーが頻繁にウェブサイトを訪れることを期待するSaaSプロジェクトの場合、4秒はデプロイごとに一度だけ起こります。
次に、JSがダウンロードされ、ブラウザによってキャッシュされます。JSがブラウザのキャッシュに入ると、LCPまでわずか800ミリ秒です。今日私が興味を持っている最後の数字は、トグルがいつインタラクティブになるかです。この場合、JSが実行されたときにのみすべてが表示されるため、LCP時間と一致します。
だから、コンテンツを見るとすぐに、コンテンツをクリックできます。重要な区別です。ブラウザがこのUIを表示しているのと同じ時間に、UIは機能しています。なぜなら、UIを表示するコードは、UIが行うことと同じコードだからです。では、Server Side Renderingと比較しましょう。データフェッチなしで。
Server Side Renderingの登場
長い間空白のページを見つめなければならないという事実が人々をイライラさせ始めました。最初だけであったとしても。さらに、SEOの目的では、最良のソリューションではありませんでした。これは、ページを説明するheadタグに物事を置くことや、Googleなどによってスクレイピングされているページ上のコンテンツによってSEOを行うためです。
しかし、JavaScriptをロード、実行してページを埋めるまでコンテンツがそこにない場合、スクレイパーはそれを見つけることができません。JavaScriptを実行してページを埋める完全な仮想ブラウザを実行していない限り。これはほとんどの検索エンジンが手間をかけない、またはそれを必要とするページにはより少ない努力を払うほどの作業量です。
人々は、SPAがどれほど遅いかという問題の解決策を考え出すために頭を悩ませ始めました。同時に、理想的にはReact内に留まろうとしました。なぜなら、それはあまりにも便利だからです。誰もそれをあきらめたくありません。Reactアプリ全体が最終的にはこのようなものに見えることを知っています。レンダリングされたDOM要素のDOMアプリです。
でも、代わりに文字列にレンダリングして、このHTML文字列を持つことができたらどうでしょうか。サーバーはブラウザに送信できます。空のdivの代わりに、ルートIDがappである1つの空のdivの代わりに。ええ。今、適切なコンテンツを渡すだけです。だから、アプリを文字列にレンダリングして、それを送り、HTMLにJSタグがあるので、その直後にクライアント上で引き継ぐことができる非常にシンプルなClient Side Renderingを行うことができます。
ただ1つの追加ステップが必要です。HTML変数内の文字列を検索して置換します。サーバーレスポンスHTMLにSSRで注入します。ルートをこのHTML文字列で置き換えて、それを送ります。これは基本的に機能するサーバーレンダリングのものです。面白いことに、最近Cloudflareのベンチマークを行っていたときに、非常に似たコードを書きました。
今、JSを待つことなく、最初からUI全体が表示されます。そして、これはServer Side Renderingであり、Static Site Generationでもあります。なぜなら、render to stringはReactでサポートされている実際の本物のAPIだからです。それはほとんどのSSRおよびSSGフレームワークの背後にあるコアの表記法であり、私のベンチマークでもあります。多くの人がこれを知りません。
Reactには、コンポーネントをrender stringで呼び出すことができるAPIがあり、レンダリングしたであろうもののHTMLで応答します。彼女の既存のクライアントレンダリングされたプロジェクトに対してこれを行うと、サーバーサイドレンダリングされたプロジェクトになります。パフォーマンスはわずかにシフトします。
全体のHTMLが最初のサーバーレスポンスで送信され、すべてがすぐに表示されるため、LCP番号はHTMLとCSSがダウンロードされた直後に左に移動します。だから、これが鍵です。HTMLが送られます。CSSがまだロードされていないため、正しく見えないかもしれませんが、すべてのJSがロードされるのを待つ必要はありません。CSSがロードされるのを待つだけです。
そして、必要に応じて、HTML内でCSSをインライン化できます。Next.jsのいくつかの楽しいプラグインを介してバンドルすることもできます。そして、HTML全体がロードされると、すべてが表示されます。まだ何も機能しませんが、すべて表示されます。だから、まず、ページのスケルトンが表示されるLCP番号が大幅に改善されるはずです。
しかし、ページはインタラクティブであることが想定されているため、まったく同じ方法でJSをダウンロード、コンパイル、実行する必要があります。だから、繰り返しますが、同じJSをすべてロードする必要があります。ただ、より良いHTMLを得ているだけです。プロジェクトに対してSSRをオンにするだけの場合、SSRとCSRの唯一の違いは、JSがレンダリングする初期状態が何であれ、デフォルトで送られるということです。
だから、HTMLは空のLCP状態で送られ、次にJSが起動して、それ以外の場合と同じすべての作業を行い、次にすべてのコンテンツが入ってきます。だから、LCPを下に移動しているだけです。他には何も変更しません。そして、そのすべてを待っている間、ページは表示されます。
ページが表示されてからJSがロードされてインタラクティブになるまでの間のギャップは、ページが壊れているように見える時間です。ほとんどのフレームワークは今、イベントをキャッシュします。何かをクリックしても、JSがロードされていない場合、あなたがしたことをキャッシュし、JSがロードされたら、それらのイベントをリプレイする本当に小さなインラインのJSがあります。
だから、通常、これを感じることはないでしょう。とはいえ、見ることができるが、まだ使用できないUIがあるこの非同期状態への憎しみを中心に構築された他のフレームワークがあります。これはQuickの全体的なことでした。もし慣れていない場合は。もし慣れていないなら、この時点で慣れる必要はありません。
これが、インタラクティブになるまでの時間がとても興味深い理由です。なぜなら、この時間の間、トグルとヘッダーは機能しないからです。キューシステムを構築していない、またはこれがすでに機能しているフレームワークを使用していない方法でサーバーサイドレンダリングを実装する場合、その壊れたウィンドウは最悪です。なぜなら、それらは事実上消えるクリックだからです。なぜなら、それらを保持するものが何もないからです。
しかし、ほとんどの最新のフレームワークはこの問題を解決しており、また、LCPマークだけが移動しました。なぜなら、JSLがロード、実行されてからフェッチを開始する必要があるからです。このパターンでは、データフェッチはそれ以上早く起こりません。だから、サーバーサイドレンダリングバージョンは、表示可能なページの時間を2倍以上減らすことに成功しましたが、他のすべての数字は事実上まったく同じです。
サーバーサイドでのデータフェッチ
では、サーバーサイドでもデータフェッチを行ったらどうなるでしょうか。なぜなら、データはロードされていないことを覚えておいてください。それは後で起こります。サーバー上でデータフェッチを行いたい場合はできます。だから、ここでサイドバーのプロミスデータをフェッチし、メッセージのプロミスデータを取得し、それらを渡してそのデータがすでにロードされた状態でアプリをレンダリングします。だから、もうReact Queryを呼び出す必要はありません。そして、文字列にレンダリングしました。
ここからロードしたメッセージとサイドバーコンテンツを渡しました。繰り返しますが、彼女はNextのようなフレームワークを使用していません。これをExpressに入れることができるサーブ関数として行っています。これは本当にクールです。なぜなら、概念をより深く示しているからです。レイアウト、サイドバー、メインコンテンツがすべてここから渡されます。
しかし、ハイドレーションも機能する必要があります。だから、これらのコンポーネントもクライアント上でJavaScriptがロードされたときにデータを持つ必要があります。だから、そこでの解決策は、それらに再フェッチさせるか、最も簡単なことは、それをwindowデータとしてHTML内にインライン化し、クライアント側でwindowが定義されているかをチェックすることです。
もしそうでなければ、渡されたappを使用し、もしそうであれば、割り当てたwindow上の値を使用します。これはハックのように見え、serverside propsについて再び話すのは嫌ですが、それがその働き方でした。奇妙なグローバルをwindowにバインドしているだけです。それほど安っぽく見えないか、そうですが、私たち全員がそうしていた方法です。そして今、ページ構造は再び変わります。
HTMLがあり、JSがロードされ、次にJSが実行され、ページがインタラクティブになります。しかし、ページがロードされたとき、すべてのコンテンツはすでにそこにあります。しかし、それは新しい問題を追加します。だから、ここでページがLCPを得るのに2.1秒かかることがわかりますが、それがヒットするまでにサイドバーとメッセージはすでにすべて機能しています。
だから、ほぼ即座に準備ができたフルページコンテンツがありますが、実際にはコンテンツがインタラクティブになるのに時間がかかります。なぜなら、データをフェッチするのを待っている時間に、HTMLがないからです。サーバーがそれらのデータフェッチを行っている場合、ここにあるものは、事実上、これら2つのフェッチコールを取ってHTMLがロードされる前に置きました。だから、HTMLはまだロードを完了していません。
だから、ブラウザがまだJavaScriptのフェッチを開始する方法はありません。だから、今、JavaScriptをAPIコールでブロックしています。これは、インタラクトできるようになるまでの時間が悪化したことを意味します。そして、より長い空白のページを見つめています。なぜなら、それがすべて入ってくるのを待っているからです。
これの利点は、ロード状態がないことです。ブラウザの空白ページのロードからコンテンツがすでにそこにあることへと移行するだけです。しかし、これはユーザーがクリックできるようになるまでの時間を遅らせているというコストが伴います。なぜなら、これらのAPIコールをHTMLの前にプッシュしたからです。
データフェッチでレスポンスをブロックしているため、LCPは以前のソリューションと比較して悪化しました。では、Next.jsのページ実装はどのように機能するのでしょうか。これは古いget serverside propソリューションです。get serverside propsです。このデータをフェッチします。それを返します。彼女が行ったこととほぼ同じことをしています。だから、それほど違わないはずです。
ええ。Client Side Data Fetchingは、彼女が行ったServer Side RenderingのDIYソリューションとほぼ同じです。Nextは確かにそれに対してより良いことをいくつか行っているため、インタラクティブになるまでの時間は短くなります。そして、サーバーサイドのデータフェッチは依然としてLCPまでの時間を悪化させますが、他のすべてはそこからかなりフラットなままです。
インタラクション時間は3.5秒で、それでもNon-Nextソリューションよりは良いです。人々がフレームワークを使用すると言うとき、これが彼らの意味することです。Nextのパフォーマンスについて好きなだけ文句を言うことができますが、実際のシナリオでは、それでもバニラソリューションよりも大幅に優れたパフォーマンスを発揮しています。
だから、Next.jsとバニラReactの生のスループットを比較する私のベンチマークを見ると、Next.jsはひどい選択に見えます。しかし、これが実際のクライアント側の動作にどのように影響するかを見ると、Next.jsが存在する理由がわかります。ユーザーにとってパフォーマンスをより良くするために、多くの他のことを行っています。
ええ。カスタム実装のLCPはわずかに悪くなっています。一方、サイドバーメッセージはこの場合1秒早く表示されます。コード分割が異なる方法で実行されたときに何が起こるかの非常に目に見える使用例です。
Nextはカスタムソリューションよりも多くのチャンクにJSを分割するので、それらはすべて並行してロードできます。これは複数のものを一度にフェッチするのに大いに役立ちます。しかし、それらの並行ファイルはCSSから帯域幅の一部を盗みます。だから、CSSのダウンロードはそうでなかった場合よりも時間がかかります。
興味深い点ですが、それらをすべて並行させることで、JS全体をより速くし、インタラクティビティのギャップに役立ちます。理にかなっています。そして今、私たち全員がここにいる理由、Server Componentsについてです。
Server Componentsの実際のパフォーマンス
この部分がどのように機能するかを見るのが非常に楽しみです。なぜなら、理想的には、LCPを行うのに十分なデータを持つHTMLファイルがあり、JavaScriptのフェッチを開始しながら、同時にAPIからデータをフェッチするという両方の最良のものであるべきだからです。
SSRの最大の問題は、ページがすでに表示されているがJSがまだダウンロードおよび初期化されているときのインタラクティビティなしのギャップです。それは最大の問題ではありません。SSRの最大の問題は、並行して物事を行うことができないことです。事実上、3つのオプションの中から選択しています。
さて、私たちがしなければならない3つのことがあります。クライアントにHTMLを送信する必要があります。JSをロードする必要があります。そして、データをフェッチする必要があります。CSRとSSRでは、これらのものはすべて互いにブロックします。事実上、物事が起こる順序を変更しています。
Client Side Renderingでは、まず空のクライアントにHTMLを送信します。だから、JavaScriptをフェッチするheadタグ以外には何もありません。ハードコードされたスケルトンがあるかもしれませんが、基本的なCSRのために、空のdivとフェッチするデータへのリンクの束を送信しています。
次に、HTMLのヘッダーまたはheadタグで示されているJSをロードします。同じ違いです。次に、JSがロードされたら、JSは解析して実行する必要があります。そして、ようやくデータのフェッチを開始できます。そして、重要なのは、ここまではUIが表示されないということです。その時点まで何も表示されません。だから、それまで空のページを見ているだけです。ハードコードした場合はスケルトンですが。
しかし、それまで何も見ていません。そして、これらのそれぞれは、1、2、3、4と起こらなければなりません。それらはすべて互いにブロックします。データなしのサーバーサイドレンダリングで。だから、サーバーサイドでデータフェッチを行っていません。最初にHTMLを生成するか、キャッシュされたバージョンを提供します。だから、スケルトンを含むHTMLが送信されます。
理想的には、これをキャッシュから取得していますが、そうでないかもしれません。だから、それがキャッシュから来ていると仮定しましょう。今、コンテンツを見ることができますが、他のすべてはそこから同じです。JSをロードし、JSを解析してからデータのフェッチを開始する必要があります。ここで行ったことは、期待どおりにページが見え始めるタイミングを変更しましたが、すべてはまだブロックされています。
しかし、データを使用したサーバーサイドレンダリングでは、物事はより異なり始めます。だから、サーバーがデータをフェッチしてクライアントに送信されたHTMLにします。今、あなたは見ることができますが、データフェッチが数秒かかることを考えると、今、それが完了するまで何も見えません。だから、実際には何かを見るまでの最も長い時間です。
しかし、ロード状態はありません。すぐにすべてが表示されますが、まだインタラクティブではありません。JSはまだロードする必要があります。そして、JSを解析してページをインタラクティブにします。だから、今、より良いコンテンツを見ています。だから、私はこれを完全な行にしたいとも思います。なぜなら、完全なコンテンツを見ているからです。ただまだインタラクトできないだけです。
ここでの問題は、これらのことを並行して行うことができないことです。理想的な世界では、ユーザーにHTMLを送信しているのと同時にデータをフェッチでき、彼らはまだデータをフェッチしている間にJSをロードします。これが1、2、3、4ではなくなることを望みません。これをブロックにすると、HTMLがあり、loadjsがあり、runjsがあり、少し小さく、次にデータフェッチがあります。これが最も長い部分です。
だから、私たちがこれまでずっとやってきたことは、標準のSSRで物事が起こる順序を変更することだけです。単に降りてくるHTMLの品質を改善しているだけです。HTMLが降りてくるのにかかる時間を増やすかもしれませんが、ただより良いHTMLを得ているだけです。それがデフォルトでCSR対SSRのすべてです。
データフェッチを伴うSSRは物事を少し並べ替えています。だから、CSR、SSR、次にデータを伴うSSRです。ここでの違いは、データフェッチが上に移動することです。だから、今、より早く完全なページを得ますが、それがどのように見えるかという点で、すべてが起こるのにかかる時間を有意義に減らしているわけではありません。ただ、何がどこにあるかをシフトしているだけです。
RSCが約束しているものであれば、それがすべきことはこれです。では、結果がどのように出るか見てみましょう。RSCの導入です。前のセクションの要約です。サーバー上でのフェッチと事前レンダリングは、初期ロードパフォーマンス番号にとって本当に良いことですが、問題があります。
彼女はここでインタラクティビティなしのことを引用しています。それが私がちょうど分岐した理由です。それは問題ですが、私の意見では、問題は何も並列化していないことです。ああ、見てください。2番目の問題はデータフェッチです。サーバー上でメッセージを事前フェッチしたいので、メッセージが表示されるまで待つ時間を短縮します。初期ロードに悪影響を及ぼし、サイドバーアイテムが表示される時間にも影響します。
なぜなら、ここで起こっていることは、サーバー上のデータフェッチまでJSのロードを待っているため、以前よりも早くJSをロードしていないため、クリックできるまでに時間がかかるからです。だから、これは結局、ページがインタラクティブになるまでの時間が長くなり、それは最悪です。
まずデータを待ち、次にデータをrender to stringに渡し、次に結果をクライアントに送信します。もし私たちのサーバーがもっとスマートだったらどうでしょうか。それらのフェッチリクエストはプロミスです。非同期関数です。何かをし始めるためにそれらを待つ必要はありません。もしそれらのフェッチをトリガーでき、すぐにReactのものをレンダリングし始め、サイドバーのプロミスが解決してデータが利用可能になったときにクライアントに何かを送り、サイドバー部分をレンダリングし、それをサーバーページに注入し、それをクライアントに送り、メッセージに対しても同じことを行い、以前にClient Side Renderingで持っていたデータフェッチのまったく同じ構造を複製できたらどうでしょうか。しかし、サーバー上で。
理論的には、これが可能であれば、非常に速い可能性があります。最もシンプルなSSRの速度でプレースホルダーを含む初期レンダリングされたページを提供でき、それでも任意のJSがダウンロードおよび実行されるずっと前にサイドバーとメッセージアイテムを見ることができます。だから、これを行うには、Server Componentsを理解する必要があります。
典型的なReactコンポーネントは、ここのサイドバーコンポーネントのように、ページ上にHTMLタグをレイアウトすることが非常に多いです。たくさんのdivsとlinksがあります。それはすべてまだJSです。正確に。このコードは、インタラクティビティなしのギャップに寄与するすべてのJSファイルに含まれています。
しかし、ここにはインタラクティビティはありません。それはただのHTMLです。このをJSとして送信する必要はありません。変化しないものであれば、理想的にはより少ないJavaScriptを送信できます。この良い例は、利用規約やTerms and Conditionsページのようなものです。なぜなら、それらは単なるテキストの束だからです。divをクリックできる必要はありません。それをJSとして送信する必要はありません。
このコードがJSバンドルに含まれている唯一の理由は、Reactがバーチャルドームを構築するためにそれを必要としているからです。なぜなら、Reactはページ上のすべての場所を知る必要があるからです。それを変更するために。しかし、理想的には、これをJSとして送信する必要はありません。
現在のSSR実装では、Next pageであろうと彼女のカスタムのハッキーソリューションであろうと、Reactコンポーネントのツリーを抽出するプロセスは2回行われます。最初はサーバー上で事前レンダリングを行うときで、2回目はクライアント側でゼロから行われます。なぜなら、サーバーサイドレンダリングを行う場合、クライアントとサーバーの両方が同じJavaScriptコードを実行し、同じHTMLに到達する必要があるため、すべてをリンクして期待する体験を提供できるからです。
そして、それが好奇心があるならハイドレーションです。サーバー上で生成したツリーを保存して、クライアントに送信するだけだったらどうでしょうか。だから、Reactは全体を再作成する必要がなく、クライアント側の部分だけを再作成します。より少ない.jsを送信でき、バンドルのサイズを削減できます。ツリー全体を作成するためにそれらすべてのものを反復的に呼び出す必要はありません。
では、このデータをどのように送信するのでしょうか。windowにハックします。そして、これは実際にほとんどのRSC実装で起こることです。彼女はApp Routerに移行し、確かに、これが彼女が見たものです。このツリーのすべてのデータのU next_f.push。これは変更されているが認識可能な、ページ上でレンダリングされるべきものを表すオブジェクトのツリーです。
これはまた、データを2回送信していることを意味します。HTMLとして送信し、この埋め込まれたJavaScriptタグで送信しています。そして、人々がServer Componentsにサーバーは必要ないと言うとき、これが彼らの意味することです。ビルド時に、動的でないHTMLを生成し、このがページのscriptタグに埋め込まれた異なるHTMLページの束を持つことができます。だから、使用されていないJavaScriptをロードする必要はありません。
使用されないReactプロジェクトでクライアントのみのJavaScriptを持つことができます。ビルド時に異なるルートの異なるHTMLを生成し、サーバー上で実行する必要はありません。それらのコンポーネントを実行していないだけです。Server Componentという名前が悪いと思う理由の一部です。ロールアウトが悪かった理由の一部です。Server Componentsは本当に良いはずです。
そうでない多くの理由があります。人々がこの概念を理解していないことはその一部です。Server Componentでは、クライアントに送信しているのはHTMLと、たった今示した奇妙な構造だけです。Server Componentsと一緒に宣伝されている利点の1つは、バンドルサイズの削減です。
理論的には、すべてのコードとライブラリがサーバー上に留まり、最終的な構造だけがクライアントに送信される場合、ダウンロードされるJSの量は顕著に減少するはずです。JSが多すぎることの影響を知っています。これは良いアイデアのように聞こえます。どのように機能するか見てみましょう。また、非同期コンポーネントもあります。Server Componentsのクールな部分の1つです。
データをフェッチするコンポーネントを持つことができ、上でサスペンドできます。これによりストリーミングが可能になります。通常のSSR実装では、サーバーはHTML全体を生成し、準備ができたら一度にすべて送信します。ストリーミングでは、最初にノードストリームを作成し、パイプ可能なストリームデータを送信できます。
だから、準備ができたらチャンクごとに送信します。それが行うことは、ページの大部分を送信し、終了したら、それらを正しい場所に移動させるscriptタグを使用して新しい要素を最後に追加することです。実際にどのように機能するかは本当にクールです。詳細を知る必要はありません。知る必要があるのは、コンポーネントが準備ができたら、同じサーバーコールから事実上ポップインできるということです。
ちなみに、このプロセスのチャンク境界はReactコンポーネントのレーシングコンポーネントではありません。Suspenseでラップされたコンポーネントです。これを覚えておいてください。これは重要です。測定を開始すると、重大な変化が見られます。彼女のようなマルチページアプリの実用的な実装は狂っています。ドキュメントはそれをうまくカバーしていません。
私はそれを機能させようとするのに恥ずかしいほどの時間を費やしましたが、最終結果は複数の本当に複雑なファイルになり、それでも半分壊れていました。通常のSSRのような単純なrender to stringではありません。ええ。これをDIYで行い、フレームワーク経由で行わないのは最悪です。なぜなら、サーバーとクライアント間の割り込みは些細なことではなく、それを可能にするために発見されたハックのいくつかには、実行可能なServer Componentフレームワークが2つしかない理由があります。実装するのは簡単ではありません。
しかし、App Routerを使用すると、はるかに簡単になります。そして、彼女がここで言うように、Next.jsのApp Routerは現時点ではServer Componentsとストリーミングの事実上の同義語です。ええ。これがケースでなければいいのにと本当に思います。でもそうです。使うのは本当に難しいです。Server Componentsは現在、React Routerで実験的にサポートされています。これはクールですが、Nextは依然としてそれを使用する方法です。ほぼ常に。
では、リフトアンドシフトマイグレーション後のApp Routerを測定しましょう。彼女は、Next.jsには他にもたくさんのもの、最適化、キャッシング仮定、変換があり、これを実行可能なテストにしないという事実を指摘しています。だから、彼女はそれを書き換えるだけです。Next.jsの利点とServer Componentの利点を区別する方法がないため、公正な比較にはなりません。
しかし、最初にpagesに移行すると、serverside renderingを行っているpagesバージョンとRSCのことを行っているApp Routerバージョンとの間で比較することが可能になります。彼女はすでにpagesとClient Side Data Fetchingを使用した既存のバージョンを持っています。これはこれまでで最小のLCPを持つアプリで、表の2行目です。
完全に新しいメンタルモデル、完全に新しいデータフェッチ方法を持つ新しいフレームワークにそれを移行します。見てみましょう。できるだけリフトアンドシフトします。アプリが機能し、何も壊れていないことを確認します。この実験のコンテキストでは、ルーティングを少し再実装し、すべてのエントリファイルでclientを使用することを意味します。これにより、App Routerをどこでもclient componentsに強制します。
だから、新しいフレームワークの効果を分離します。ここでのすべての利点または劣化はフレームワークのためであり、Server Componentsやストリーミングのためではありません。だから、これはServer Componentsなしで、すべてをApp Routerに移動するだけです。彼女はpages実装から有意義な改善を見ました。1.76秒から1.28秒へ。
ただし、サイドバーのロードに時間がかかったように見えます。3.7から4.4、4.2から4.9です。メインコンテンツのために。LCPがはるかに良くなったことは興味深いです。他のすべては悪化しました。ええ。LCPは500ミリ秒良くなり、他のすべては700ミリ秒悪くなりました。非常に興味深いです。
どうやら、App RouterはCSSがロードされた後まですべてのjsを遅延させます。pagesバージョンはそれを行わず、並行してロードします。その結果、JavaScriptのロードが少しの帯域幅を盗み、CSSはpagesでより遅くロードされていたため、LCPを遅延させていました。それは実際に私が知らなかった本当にクールな詳細です。
レイアウトシフトが起こる奇妙なエッジケースを防ぐために彼らがそれを行う理由は理解できます。それは非常に興味深いです。また、App Routerはメインスレッド上で非常に忙しいです。少なくとも100ミリ秒分のタスクがpagesよりも多いです。なぜなら、App Routerはクライアント側でより多くのことを行うからです。ええ。
合計で、効果は少し微妙だと言えます。おそらくさらなるリファクタリングでより良くなるでしょう。Tailwindをとにかく使用しているので、CSSをインライン化すること以外に彼女の側でできることはあまりありません。それのためのフラグがあり、CSSがブロックするのを防ぐことができ、ここで助けになる可能性があります。
ええ。CJでさえこれを知りませんでした。ええ。それが私たちが深いところにいることがわかる方法です。Reactチームがこれらすべてのことを実装した理由のすべての歴史を必ずしも知らないが、プロファイリングの方法を本当によく知っている人々を見るのは実際に本当に素晴らしいです。なぜなら、彼女は私が見つけないであろうものを見つけているからです。
なぜなら、私はこれらすべてがどのように実装されたかの細部にあまりにも深く入り込んでいて、このレベルのことを考えられないからです。これにはXKCDがあります。シリケート化学は私たち地球化学者にとって第二の性質です。だから、平均的な人々がおそらくオリビンの式と1つまたは2つのフェルドスパーとクォーツだけを知っているということを忘れがちです。もちろん。
ええ。私は人々がこの世界で何を知らないかを知りません。なぜなら、私はあまりにも深いからです。でも、彼女がこのインラインCSSを知らないので、これは良いことのように見えます。この機能は、彼女は私が見つけなかったであろうものを見つけています。
しかし、今、私たちは特定の場所でclientを削除し始めるときに、Server Component実装と比較できます。JSは削減されました。さあ。一部のページではほんの少しだけでした。だから、ホームページは2%しか減りませんでしたが、他のページは大幅に。
ログインページはキロバイト値からバイトへ、ほぼゼロになりました。共有チャンクのほとんどはまったく変更されず、受信トレイページで彼女にとって重要なすべてのメトリクスへのパフォーマンスへの影響は正確にゼロでした。だから、私のアプリで書き直されたデータフェッチなしのServer Components自体は、パフォーマンスへの影響がありませんでした。
そして、私は、ほとんどの実際の混乱したアプリで、use clientがあまり深く考えずにランダムにあちこちに貼り付けられ、最終的にほとんどのページの非常にルートまでバブルアップする場合、同じことになると思います。ええ。それは公平だと思います。データフェッチを少し変更したら何が起こるでしょうか。
クライアント上でデータをuse effectingする代わりに、データを待ち、それを解析してから、それに応じてレンダリングする非同期サイドバーコンポーネントがあります。ここでの複雑な部分は、これを行うと、サイドバーコンポーネントはそれをマウントするclient componentの親を持つことができないということです。サイドバーはclient componentから呼び出すことはできません。
ルートはServer Componentsでなければなりません。そして、これがレンダリングされるまで、そうでなければなりません。間にclient componentsがある場合、それらをレンダリングできますが、サイドバーをそれらにpropとして渡すか、それらの他のものにchildとして渡す必要があります。それを行ったら、結果を見てみましょう。
ああ、LCPは1.78秒です。それが悪化したのは少し怖いです。理論的にはそうすべきではありませんが、1.78でここにすべてのコンテンツを表示することに留まります。彼女はこれにSuspenseをしませんでしたか。ああ、していませんでした。ええ。やったと思いました。
だから、ここで何が起こったかというと、彼女はデータをフェッチしていて、それがページのロードをブロックしているので、データがフェッチされるまで何もクライアントに到達しません。しかし、Suspenseでコンポーネントをラップしてロード状態を表示できます。これが私が気にするものです。さあ。
LCPは1.28秒、サイドバーは1.28秒です。なぜなら、サイドバーは十分に速くロードされるからです。ほぼ即座にストリーミングされます。待って、なぜメッセージも1.28なのでしょうか。それは起こるべきではありませんでした。彼女のLCP測定についてはよくわかりません。自分で実行する必要があるかもしれません。興味深いです。
非常に速いので、すべての数字が再びマージします。どこかで何らかの形のバッチ処理を行うと思いますが、それら3つは同じチャンクに入りました。しかし、彼女が行ったことは、サイドバーのロード時間を3秒、メッセージのロード時間を5秒に増やしたことです。だから、全体がかかる時間が増え、利点がここではるかに見えるようになります。
CSSとJSをはるかに早くロードし始めることができましたが、準備ができたらHTMLはデータを送信し続けますが、従来のSSRでは、ページがロードされるのを待ってから、これらすべてが起こる必要がありますが、HTMLはこれ以上何も送信していません。
だから、ここのTLDDRは、Client Side Renderingは予想通り初期ロードの観点から最悪ですが、ページがインタラクティブになると、表示されるとすぐにインタラクティブになり、ページ間の遷移は速いです。
Server Side Renderingは大幅にロード番号を改善できますが、インタラクティビティなしのギャップと、スケルトンがより困難な問題になるというコストが伴います。ブラウザのロード状態をはるかに待たなければならなくなります。だから、ほとんどの場合、スケルトンを使用したクライアント側が従来のSSRよりも理想的だと思います。
サーバー上でデータをフェッチすると、初期ロードが遅くなりますが、フルページの体験をはるかに早く表示できるようになります。従来のSSRからストリーミングを伴うServer Components、つまりPages RouterからApp Routerへの優先順位は、注意しないとパフォーマンスを悪化させる可能性があります。サーバーからのデータフェッチを書き直す必要があります。
そして、改善を見るためにはSuspense境界を忘れないでください。これは大きな開発努力であり、アプリ全体のアーキテクチャの再設計を必要とする可能性があります。Pages RouterからApp Routerへの移行は、遅延したJSダウンロードのためにインタラクティビティなしのギャップを悪化させる可能性がありますが、それはブラウザに依存する可能性があり、また、CSSを事前ロードすることもできます。
アプリがclientとServer Componentsの混合である場合、Server Components単独ではパフォーマンスを改善しません。それらは測定可能なパフォーマンスへの影響を持つのに十分なバンドルサイズを削減しません。ストリーミングとSuspenseが重要です。
主なパフォーマンスの利点は、データフェッチを完全に書き直してServer Components最優先にすることから来ます。ええ。現実的に言えば、ルーティングの動作方法に満足していて、サーバーへのデータフェッチの移行に興味や計画がない場合、おそらくまだ移行すべきではありません。
Server Componentsが本当にクールになるのは、どのコンポーネントがサーバーで、どのコンポーネントがクライアントで、どのコンポーネントが準備ができたときにストリーミングされるかについて、いくらかの努力を考え抜いているときです。
チャットは彼女が部分的プリレンダリングについて全く言及していないと指摘しています。ええ。彼女がテストしていた方法ではPPRは実際には重要ではありません。部分的プリレンダリングとは何かというと、サーバー上でこのステップ中にHTMLを生成するとき、PPRはその結果をキャッシュしてCDNに置くので、サーバーがレスポンスを送信するのを待つ必要がないということです。
しかし、彼女はとにかくほぼ即座に応答する偽のローカルリバースプロキシを行っているので、そのチャンクを取ってCDNに置くことの利点はほぼゼロです。だから、ここに部分的プリレンダリングを持っていないことは、彼女がベンチマークしている方法には関係ありません。だから、みんながそれを言っている理由がわかりません。まあ。
Next 16もキャッシュされたビットをプリロードし、ネットワークホップコストを削除します。よくわかりません。ああ、だからサーバー側でそれはツリーのキャッシュされた部分を持っているのでステップをスキップします。よくフォローできません。ああ、これはナビゲーション用です。だから、これらの測定のどれもナビゲーションではなかったと思います。だから、Nanが言ったことは実際に本当にクールな利点です。
基本的に部分的プリレンダリングは、最初のawaitまで、またはヘッダーをチェックするようなユーザー固有のものを呼び出す最初の時までレンダリングします。だから、awaitにヒットするまでReactツリーを下り、それまでのすべてをキャッシュしてCDNに投げ込み、今、サーバーをロードせずにそれをロードできます。
しかし、より重要なのは、ページに現在利用可能なすべてのリンクのためにそれを事前フェッチできることです。だから、クリックすると、その部分的プリレンダリングのそのピースをすぐに準備でき、サーバーが起動して接続し、そのデータを送信すると、残りのデータがストリーミングされ始めます。これはクールですが、ここでテストされていたものではありません。
それは本当にクールな利点であり、先ほど説明されたClient Sideで記述されたのと同じ感覚を与えます。何かをクリックすると、すぐに変わります。何を言っていますか、Wendro。pages routerとclient side fetchingが全体的に最高のパフォーマンスを持っていると言います。いいえ、そうではありません。同じ数字を得ます。client data fetchingを伴うpages routerは最高の数字を持っていません。
メッセージを見る前に4.22秒かかります。また、キャッシュされると、これらの時間がどれほど短くなるか見えますか。App Routerでサーバーサイドのもので無料になります。データフェッチなしでキャッシュなしの最高のtime to interactiveを持っています。コンテンツの多くがまだ欠けているという事実を無視すれば。
しかし、JSがキャッシュされている可能性があることを考慮し、まだ表示されなければならないコンテンツと対話していることを考慮するとすぐに、time to interactiveが悪化します。私はただ、正しく実装されたとき、pages routerがapp routerよりも良い世界は存在しないと思います。それはただそうではありません。
だから、まだ待っているコンテンツがapp routerバージョンでロードされているであろう間に、本当に本当に速く、ミリ秒でトグルをクリックできますか。たぶん。でも、それは純粋にCSSがロードされている方法のためであり、それは実際の問題ではありません。
不要なページをフェッチするための帯域幅を失いますよね。はい。でも、ほとんどなく、他のすべてがロードされるまでそれを行いません。それは問題ありません。最新のフレームワークがものを事前フェッチして、クリックしたときにより速く感じられるようにすることは素晴らしいと思います。ナビゲートをより良く感じさせる別の500キロバイトのHTMLをロードしたからといって、誰も請求されていません。
より重要な他のデータフェッチがブロックされていない限り、それは問題ないと思います。全体として、これは本当に本当に良いです。これを書いてくれたNadiaに再び感謝します。これは素晴らしい書き上げです。第一原理の最高のものの1つで、概念を理解し、正しいものをテストし、それを通して重要な部分をテストするためのデューデリジェンスを行っています。
これらの異なる方法の内訳と実際のパフォーマンスがどのように見えるかを見せながら、読者にこれらのものがどのように異なるかについて教育している人を見たことがありません。これ全体が素晴らしく、唯一の欠けている詳細は実際にそれを非常に良くするものの一部です。なぜなら、それらすべては私のように気にしすぎる場合にのみ重要な細部のただのものだからです。
それでも、彼女は私にそれについてもっと話す素晴らしい機会を与えてくれました。もう一度、彼女の作品を強くお勧めします。これらのことについてもっと学びたい場合、上級React、ウェブパフォーマンスの基礎など、彼女の作品をチェックしてください。すべては理由があってディスクリプションにリンクされています。彼女は自分がしていることが得意です。いつものように皆さんに感謝します。何かを学んだことを願っています。そして、次回まで、レンダリングを続けてください。
コメント