クライアント側のフレームワークは素晴らしいです。 これらは、ユーザーが憧れるインタラクティブで高速なWebアプリケーションの構築を支援します。
残念ながら、この世界は完璧ではなく、いくつかの欠点があります。 主なものの1つは、起動速度です。
クライアントフレームワークは、アプリケーションをマウントするための単一のdivを含むスタイルといくつかのスクリプトファイルが含まれる非常に小さなHTMLファイルを取得します。 ただし、縮小されたコードも含むJavaScriptファイル（バンドル）は非常に大きく、数メガバイトに達することがあります。
ブラウザーはこれらのファイルを要求する必要があり、両方が配信されるまでページはユーザーに表示されません。 また、アプリケーション自体の初期データを取得するために、APIへのリクエストが必要になる場合があります。
一方、従来のWebサイトはすべてをサーバー上でレンダリングし、HTMLがクライアントマシンに配信されるとすぐに、ユーザーにページが表示されます。 さらに、ほとんどのWebサーバーは、ユーザーのマシンよりも速くページをレンダリングできます。 このすべての結果として、ページの初期読み込みは非常に高速です。
Rescue React
もちろん、両方のアプローチの利点が必要です。 高速起動および高速でインタラクティブなアプリケーション。
Reactはこれに役立ちます。
仕組みは次のとおりです。 Reactには、サーバー側のデータを含む任意のコンポーネントをレンダリングする機能があります。 つまり、サーバー側のReactはコンポーネントのツリーを構築し、それらをHTMLフレームワークに変換します。 これらすべてをindex.htmlに入れ、ユーザーに送信します。 このファイルには、クライアントでレンダリングするためのアプリケーションデータも格納されます。
HTMLがユーザーに配信されるとすぐに、ブラウザにページが表示されます。 現時点では、「重い」JavaScriptファイルはバックステージでロードされ、ロードされると、Reactはローカルレンダーに対して同じ計算を行います。 スマートReactアルゴリズムは、ローカルレンダリングの結果がページに既に表示されているものと一致することを理解します。 この比較の結果、Reactは変更を加えず、単に必要なイベントハンドラーを要素に追加します。
この場合、HTMLファイルはもちろん少し「重く」なりますが、JavaScriptを含むファイルのサイズとは比較されません。 その結果、HTMLファイルは非常に迅速に配信されます。
どれくらい速いですか？ 2つの場所でほぼ同じことをしませんか？ はい、しかしほとんどここにキーワードがあります。
まず、サーバーがブラウザーの要求に応答するとすぐに、ユーザーにはすぐにページが表示されます。
第二に、ReactはDOMへの変更が不要であると認識しているため、それに触れることはありませんが、これはレンダリングの最も遅い部分です。
さらに、データはサーバーでのレンダリングに既に参加しており、再度要求する必要がないため、1つの要求を保存します。
- ページの読み込みを開始します。
- HTMLファイルをロードし、スタイルとjsのロードを開始します。
- スタイルがロードされ、ユーザーにはすでに美しいページであるJSファイルが表示されていますが、その間、バックグラウンドでロードが続行されます（ページは死んでいます）。
- JSファイルがアップロードされ、reactがレンダリングを開始し、仮想DOMと表示されたDOMを比較します。
- Reactは違いがないことを理解し、イベントハンドラーを既存のマークアップに単に接続します。 ユーザーは全ページにアクセスできます。
JavaScriptの読み込み中にページが既に表示されているときに、イベントハンドラーがまだページにアタッチされていないため、ユーザーがJavaScriptを操作できない可能性はありますか？
理論的には、これはさらに可能です。 ただし、この手法を使用すると、コストのかかる操作（クエリ）がすべて回避されるため、初期ダウンロード速度が向上するだけでなく、イベントハンドラーの接続が非常に高速になります。
最終的に、アプリケーションは常に対話型であり、ユーザーの1人が問題に遭遇することはなく、ページの読み込み時間が非常に短くなり、ユーザーは無限に幸せになります！