レンダリングスペクトル

ウェブサイトのレンダリングは、主に3つのカテゴリに分かれています。

• クライアント側のレンダリング：<div></div>クライアントに送信し、JavaScriptテンプレートによってレンダリングされます。
• 静的レンダリング：プレレンダーHTML。
• サーバー側のレンダリング：サーバーは要求を処理し、HTML応答を生成します。

これらの3つのカテゴリは相互に排他的ではなく、混合物で使用できます。例えば：

• ウェブサイトは、ページの75％（ブログ投稿など）の静的なレンダーを事前にレンダリングできますが、残りの25％のページはサーバー（フォーラムなど）によって応答されます。
• ウェブサイトはすべてのページを静的に事前にレンダリングできますが、空のページがいくつか含まれています。<div> 、これら<code><div>クライアントレンダリングされたコンテンツが含まれています（たとえば、ログインしたユーザーに基づいて動的に生成されたメニュー）。<li>ウェブサイトは主にサーバー側のレンダリングを使用していますが、その前にキャッシュがあり、静的レンダリングのように動作します。</li> <li>ウェブサイトは静的にレンダリングされ、完全にクライアント側のレンダリングされたWebサイトに「水分補給」することができます。</li> <li>ウェブサイトはサーバー側と静的レンダリングを混合できますが、クライアント側のレンダリングに似た動的な部分を備えていますが、実際にはエッジ関数で発生するため、サーバー側のレンダリングに似ています。</li> <p> next.jsのユニークな点は、これら3つのレンダリング方法を同時に実装できることです。最近のインタビューで言及されたティム・ニュートケンス：</p> <blockquote> <p> next.jsを使用すると、ページを事前にレンダリングできます。静的サイト生成（SSG）を使用して、ビルド時にサーバーにHTMLを作成するか、サーバー側のレンダリング（SSR）を使用します。 next.jsを使用すると、両方の方法を使用できます。他のほとんどのフレームワークとは異なり、完全に静的に生成されたアプリケーションに限定されません。一部のページをサーバー側にレンダリングすることができ、他のページは静的に生成されます。</p> <p>新しいバージョンでは、アプリケーション全体を再構築することなく、これらの静的に生成されたページを更新できます。</p> </blockquote> <p>この柔軟性は素晴らしいです！多くのWebサイトでは、ディスク全体で単一のレンダリング方法を使用することは実用的ではありません。</p> <p>クライアントのレンダリングは最も柔軟ですが、パフォーマンスの低下、信頼性の低い、重機の負担、非友好的なSEOなど、不利な点も明らかです。静的レンダリングに基づいたエッジ関数はいくつかのドアを開き始めましたが、サーバー側のレンダリングは古典的に柔軟性と速度の両方を考慮し、長い間支配してきました。</p> <p>クライアントレンダリングは、「シングルページアプリケーション（SPA）」エクスペリエンスももたらします。このページレスリフレッシュの感覚により、Webサイトが高速になり、ページの移行が促進されます。 Gatsbyは、JavaScriptのダウンロード後にSPAのレンダリング前のレンダリングの利点を組み合わせて、「水分補給」を促進することで知られています。</p> <p>理想的には、SPAを構築せずに優れたユーザーエクスペリエンスが必要です。これは、フレームワークが多くのJavaScriptを単独で管理せずにスパの感情を提供する場合、特に注意に値しますが、それを管理する<em>メカニズム</em>がまだあります。</p> <p> Tom MacWrightは、この問題を記事「スパではない場合、それは何ですか？」既存の選択肢には次のものがあります。</p> <blockquote><p> Turbolinks…<em>スパエクスペリエンスを得るためにアプリケーションマッチングに頼らずに行う必要があることは何ですか？</em></p></blockquote> <p> Turbolinksも同様に動作します。リンクをクリックし、クリックイベントのインターセプト、Ajaxリクエストの新しいページのリクエスト、JavaScriptはページコンテンツを新しいコンテンツに置き換えます。実装するのは非常に簡単ですが、それでもJavaScriptに依存しており、データ転送を減らすほど賢くありません。</p> <blockquote><p> barba.jsとinstant.pageは、同様の問題を解決する他の方法です。</p></blockquote> <p> Barbaは、ページの移行効果に焦点を当てています。 Instant.Pageは主にクリックする前にページをプリロード/プリレンダリングするため、ページが更新されていても、目立たないように感じます（特に図面を保持する場合）。どちらもクールですが、スパの完全な代替品ではありません。 （ページを描画し、事前にレンダリングし、軽量に保持していても、エクスペリエンスはまだスパほどスムーズではないと思います。たとえば、ページがスピナーを読み込んでいることがわかります。）</p> <p>それで、他の方法はありますか？いくつかあるかもしれません。例えば<code><portal></portal>。単純化しすぎているかもしれませんが、基本的なアイデアは次のとおりです。ポータルはIFRAMEに似ています。それらは、iframeのように視覚的に表示することさえできます。これは、ポータルでのURLのレンダリングが完了したことを意味します。その後、ポータルをアクティブページに「昇格」し、これを行うときにポータル自体をアニメーション化することさえできます。

  これは不可能ではないと思います。ポータルに基づいてTurbolinksのようなライブラリを構築し、「使いやすく」し、Webサイトをスパのようにする人がいると想像できます。

  ただし、指定された位置への長方形をアニメーション化することは、通常、ページアニメーションの遷移にとって理想的な効果ではありません。 Sarahの記事「Web上のネイティブアニメーションと同様のページトランジション」を参照してください。それが人々が望んでいることです（少なくともその可能性）。だからこそ、ジェレミーは最近、「ほとんどのシングルページアプリは巨大なカルーセルだ」と言ったときに冗談を言ったのです。彼はまた、数年前にジェイクによって提案されたナビゲーション移行提案にも言及しました。

  私はこの提案が好きです。ユーザーのニーズに焦点を当てています。また、ブラウザが提供する機能を使用する代わりに、人々がJavaScriptフレームワークを選択する理由も尋ねます。ブラウザは特定の機能を提供しないため、JavaScriptフレームワークを選択します。タブやアコーディオンなどのコンポーネント。 DOMの違い;複雑なフォーム要素のスタイルを制御します。ナビゲーションの移行。 JavaScriptフレームワークが今日解決している問題は、明日のWeb標準のR＆D部門と見なされるべきです。 （代わりに、私は、優れたJavaScriptフレームワークの目標は、それ自体を冗長にすることであるべきだと固く信じています。）

  では、最良のレンダリング方法は何ですか？あなたに合ったものは最適ですが、次の階層には一般的な意味があるかもしれません。

  1. できるだけ多くの静的HTMLを使用します
  2. 静的HTMLベースのエッジ関数を使用して、動的なコンテンツを処理します
  3. 次に、サーバーによって生成されたHTMLを使用します
  4. クライアントレンダリングは、絶対に必要な場合にのみ実行されます