Web テクノロジーとブラウザの進化

こんにちは！ Web が正確にどのように機能するのか、そしてその謎のブラウザに URL を入力すると実際に何が起こるのか考えたことはありますか?心配しないでください。あなたは一人ではありません — 私たちのほとんどは、ウェブをある種のブラック ボックスとして扱います。しかし、このブログをクリックしたのですから、中を覗いてみたいと思うかもしれません。素晴らしいですね！好奇心は命を奪うかもしれませんが、開発者にとっては、それが秘密のソースです。

仕組みについて少しは知っていたとしても、なぜこのように進化したのか疑問に思うかもしれません。私は、「現在を理解し、未来を予測したり、未来に影響を与えるためには、過去を知る必要がある」と考えています。あるいは、何人かが示唆したように、ハム年表サマジュナ・チャヒエ！それでは、わかりやすくするために、Web テクノロジーとブラウザーの進化を 4 つの簡略化されたフェーズに分けて見ていきましょう。この旅が終わるまでに、ウェブ テクノロジーがどのように進化したかだけでなく、内部で何が起こっているのか、なぜこれらの変化が起こったのか、そしてそれがウェブの将来に何を意味するのかについても理解できるようになります。

注 : これらは正確なタイムラインではなく、理解を助けるために簡略化されたフェーズです。

第 0 フェーズ: 先史時代のウェブ

1980 年代より前の時代に巻き戻してみましょう

大勢の研究者が米国の大学を走り回り、データを転送または共有するためにコンピューター間に物理的な配線を敷設しているところを想像してみてください。これらの技術の先駆者は、ファイルを共有したり電子メールを送信したりするための FTP (ファイル転送プロトコル) や SMTP (簡易メール転送プロトコル) などのプロトコルを確立しました。そのほとんどは画期的な実験に関するもので、場合によっては社内のゴシップに関するものでした。以前は、リモート クライアントを介して接続し、記述されたコマンドを使用してディスクにファイルを保存またはフェッチできるサーバーがありました。

これは少量のデータの場合は問題ありませんでしたが、データがますます速く増加するにつれて、特定の情報を見つけるのが非常に困難になりました。データを取得するには、正確なパス、サーバー アドレスを知る必要があり、おそらくコンピューターの神をなだめるためにちょっとしたダンスをする必要がありました。貴重な情報はデジタル シャッフルで失われる危険があり、洗濯物の渦の中で靴下が消えるように、サーバーに分散してしまいます。

第 1 フェーズ: Web の誕生

1980 年代後半から 1990 年代前半に入る

サー・ティム・バーナーズ・リーという名の優秀な英国人もやって来た。彼は情報管理: 提案と呼ばれる提案を作成しました。その中で彼は、「ハイパーテキスト」として知られる非線形テキスト システムの使用について話しました。これは、巨大な蜘蛛の巣のように接続された関連情報へのリンクを含むテキストを意味します。そのため、関連データの移動と探索がより簡単になり、情報の損失が最小限に抑えられます。

この提案の中で、彼は相互接続されたコンピューターを「ウェブ」とも呼んでいました。そしてまさにそのようにして、World Wide Webが誕生しました。彼はそこで止まりませんでした。彼は続けて、ハイパーテキスト転送プロトコル (HTTP) を発明し、WorldwideWeb (後に Nexus にブランド変更) という魅力的な名前の最初のブラウザ、最初の HTTP Web サーバー、そして最初の Web サイトを開発しました。達成しすぎについて話しましょう!

• HTTP (HyperText Transfer Protocol): クライアント (Web ブラウザーなど) と Web サーバー ( Web サイトをホストするリモート コンピューター)。この名前が気になる場合は、当初は HTML ファイルの転送のみを目的としていたものです。しかし、ヘッダー、特に Content-Type ヘッダーの導入後、後のバージョンではあらゆる種類のデータの転送をサポートするように進化しました。
  
  

• HTTP Web サーバー : この HTTP プロトコルを理解できるコンピューター。この主な仕事は、リクエストを解析し、リクエストされたレスポンスを提供することです。現時点では、ほとんどが静的な HTML、CSS、JPG ファイルです。

ここで HTML (ハイパーテキスト マークアップ言語) が登場し、ハイパーテキストの概念と SGML (Standard Generalized Markup Language) が結合され、文書のフォーマットに使用されました。 HTML の最初のバージョンは非常に基本的なもので、見出し、段落、リスト、リンクをサポートしていました。派手なフォントや派手なアニメーションはありません — 必要なものだけを備えています。

最初の数年間、ウェブは研究者や学者のための特別なクラブのようなものでした。その後、何人かの賢い人たちが、画像を表示できる Mosaic というブラウザを開発しました。はい、画像です！これにより、Web が一般の人々にとってよりアクセスしやすくなりました。なぜなら、正直に言って、写真は 1,000 行に匹敵するからです (このブログには写真はありませんが?)!

ブラウザの内部

それでは、上記の機能を備えたこれらのブラウザ内で何が起こっているのか見てみましょう

ユーザー インターフェイス : どのブラウザにも上部にナビゲーション バーがあり、開いているすべてのタブ (当時はウィンドウ) が表示されていました。その下には、Web サイトのアドレスを入力するアドレス バーがありました。その下には、入力したWebサイトの内容が表示される場所（ビューポート）があります。覚えておいてください、これは検索エンジンが登場する前のことなので、正確な住所がわからなければ、運が悪かったということです — GPS や地図なしで場所を見つけようとするようなものです。

データの取得 : Web サイトのアドレスを入力すると、ブラウザのネットワーク モジュールが DNS 解決などのタスクを実行してデータを取得し、サーバーとの安全な接続を確立して通信を開始します。その後、ブラウザはサーバーから HTML 形式でデータを受信します。

レンダリング エンジン : レンダリング エンジンは HTML の解析を開始します。画像 () やスタイル (

次に、HTML からドキュメント オブジェクト モデル (DOM) ツリーを構築し、各タグがツリー内のノードになります。 CSS を取得して解析した後、CSS オブジェクト モデル (CSSOM) を構築します。これら 2 つのモデルを組み合わせて Render Tree を作成しました。これは、何を表示するか、どのように表示するかを決定するために使用されます。

• レイアウトとペイント : 次にレイアウト フェーズが始まり、レンダリング エンジンがページ上の各要素のサイズと位置を計算します。ビューポート (Web ページの表示領域) に関連するタグから開始して、レンダー ツリーを通過します。最後に、描画フェーズでは、レンダリング エンジンがそれぞれのオペレーティング システムのレンダリング API と通信して、画面上にすべてを描画します。

制限とともに生きる

このフェーズの終わりまでに、ユーザーは静的な Web サイトを表示し、ページ間を移動できるようになりました。フォームでは、テキストの入力やボタンのクリックなどの基本的なユーザー操作が可能で、このフォーム データは通常、電子メールを通じて開発者に転送されました。ただし、ここに問題があります。ユーザーの操作に基づいてコンテンツを動的に変更する方法がありませんでした。ユーザーは、提供されたリンクをクリックして移動することしかできませんでした。

何かを更新する必要がありますか?新しい HTML 全体をサーバーから再度フェッチします。ユーザーごとに異なるコンテンツを表示したいですか?申し訳ありませんが、起こっていません。プログラミング ロジックを散りばめることはできません。ループも条件も何もありません。複数のページにナビゲーション メニューが必要な場合は、同じコードをコピーしてどこにでも貼り付ける必要があります。

第 2 フェーズ: サーバーサイド スクリプティングの台頭

ここで、1990 年代半ばから後半まで早送りしてみましょう

開発者は、「プログラミング言語と HTML を組み合わせて、ロジックを追加して作業を楽にできたらどうだろう?」と考え始めました。これがサーバーサイドスクリプトの出現につながりました。 Java、PHP、Python などの言語が HTML に埋め込まれているため、開発者はデータを処理し、意思決定を行い、HTML を動的に生成できるコードを作成できます。静的な HTML ファイルを提供する代わりに、サーバーはユーザーごとにコンテンツを調整できるようになりました。

これにより状況はどう変わりましたか?

ブラウザの観点から : ブラウザは引き続き HTML を取得してレンダリングしましたが、受信したコンテンツはより動的でした。フォームがより強力になり、POST リクエストを使用してサーバー エンドポイントにデータを送信できるようになりました。

• キャッシュと Cookie : ブラウザーでのキャッシュがより高度になりました。画像やスタイルシートなどのリソースをローカルに保存し、繰り返しフェッチする必要性を減らしました。 Cookie は、ステートレス HTTP プロトコル上で状態を維持するために導入されました。これらにより、サーバーはクライアント側に小さなデータを保存し、後続のリクエストとともに送り返されるようになりました。これは、セッションの維持、ユーザー設定、ユーザーのログイン状態の維持などにとって非常に重要でした。したがって、まばたきするたびにパスワードを入力する必要がなくなります。

サーバー側 : サーバーが混雑しました。これまでは、静的ファイルを提供する Web サーバーしかありませんでした。しかしこの時点で、アプリケーション サーバー、データベース サーバー (ユーザー データ製品カタログなどを保存できる) など、さらにいくつかのものが導入されました。これらは、ユーザー入力を処理し、データベースと対話し、カスタマイズされた HTML を生成できるスクリプトを処理するようになりました。 。電子商取引が隆盛を極めた時代です。 Amazon や eBay などの企業は、ユーザーの検索、好み、行動に基づいて商品を動的に表示できます。

• アプリケーション サーバー : Web サーバーは本質的にスクリプトを実行できないため、この作業を行うためにアプリケーション サーバーが導入されました。基本的に、アプリケーション サーバーは Web サーバーの背後にあるようなものです。リクエストが届くたびに、Web サーバーは設定に基づいてアプリケーション サーバーに送信する必要があるかどうかを確認し、リクエストをアプリケーション サーバーに送信します。次に、アプリケーション サーバーはリクエストを処理し、スクリプトを実行して HTML ファイルを生成し、そのファイルが Web サーバーに転送されてクライアントにサービスを提供します。したがって、Web サーバーはアプリケーション サーバーに対するリバース プロキシのように機能します。

JSP (JavaServer Pages) を使用した例

学生時代、古い JSP プロジェクトをいじっていたのを覚えています。これらのスクリプトは通常、共通の構造に従います。スクリプトは HTML で構成され、ロジックを追加する必要がある場合は、 などの特別な識別子を使用して埋め込まれます。 (閉じる) JSPの場合。簡単な例を次に示します:

greet.jsp

    <title>Greeting Page</title>


    <h1 id="Greeting">Greeting:</h1>
    <p>
        Hello, !
    </p>

この例では、ユーザーが名前を送信すると、サーバーはフォーム データを含む HTTP リクエストを受信し、情報を処理して、ユーザー向けにパーソナライズされた挨拶を動的に生成します。一般的な「Hello, World!」はもう必要ありません。今は「こんにちは、[あなたの名前]」です！ — 自我を瞬時に高めます。

動的コンテンツ生成 : リストやコンテンツをハードコーディングする代わりに、データベースからデータを取得してループ処理したり、それを使用して HTML 要素を生成したりできます。たとえば、果物のリストを表示する場合:

これはデータベースからフルーツを取得するように簡単に拡張でき、コンテンツをよりダイナミックで新鮮なものにすることができます!

新たな挑戦

サーバーサイドのスクリプトは変革をもたらしましたが、課題がないわけではありません。

全ページ更新 : フォームの送信やリンクのクリックなど、サーバーと対話するたびに、ページ全体を再読み込みする必要がありました。これは、ロジックはアプリケーション サーバー上でのみ実行できるため、新しいHTML。ユーザーは、アクションの結果を確認する前に、サーバーが応答するまで待つ必要がありました。これにより、ユーザー エクスペリエンスはあまり良くありませんでした。

サーバー負荷 : サーバーは、スクリプトの実行からデータベースのクエリまで、すべての処理を処理する必要がありました。 Web サイトの人気が高まるにつれて、サーバーは負荷の増加に苦戦し、その結果、ユーザーの読み込み時間と遅延が増加しました。忍耐が美徳であることはわかっていますが、ユーザーがそれを十分に備えているわけではありません。ブラウザーとクライアント側コンピューターの機能がますます向上するにつれて、パフォーマンスと応答性を向上させるためにワークロードの一部を引き受けることができないのはなぜだろうかという疑問が生じました。

第 3 フェーズ: クライアント側の革命

開発者がページ全体のリロードにうんざりし始めた時代に入りました。変化の時が来ました。その変化はクライアントサイド スクリプティングまたはクライアントサイド レンダリング (CSR) の形で実現しました。

JavaScript は 1995 年に Netscape によってひそかに導入されましたが、今では注目を集め始めています。これにより、開発者はユーザーのブラウザでコードを直接実行できるようになり、すべての対話にサーバーが関与する必要がなくなりました。これにより、よりスムーズで応答性の高い Web エクスペリエンスが実現しました。この革命にはいくつかの主な要因が関係していました:

ブラウザの機能の向上: 時間が経つにつれて、ユーザーのデバイスはますます強力になり、ブラウザも同様に強力になりました。そのため、一部の作業をサーバーからブラウザーにオフロードすることが明らかになり、ユーザー エクスペリエンスが大幅に向上しました。ブラウザはもはや単なる受動的なドキュメント ビューアではありません。これらは、複雑なアプリケーションを実行できるプラットフォームに進化しました。

Web API: この新たに発見された能力を利用するために、ブラウザは Web API — JavaScript がブラウザの機能と対話できるようにする一連の関数の提供を開始しました。 JavaScript の進化に貢献した主な Web API は次のとおりです。

• DOM API は、ブラウザーで Web ページの構造とコンテンツを動的に操作し、対話する方法を提供しました。また、クリックやマウスムーブなどのイベント リスナーを任意の要素に追加できるため、開発者はユーザー インタラクションに即座に応答できます。ユーザーがボタンをクリックしたときに新しい段落を追加したいですか? HTML 全体を再度生成しないでください。面倒です。

    <title>Greeting Page</title>


    <h1 id="Greeting">Greeting:</h1>
    <p>
        Hello, !
    </p>

• XMLHttpRequest はゲームチェンジャーでした。これにより、開発者はブラウザで実行されているコードから直接ノンブロッキングの非同期 HTTP リクエストを作成し、サーバーからデータをフェッチできるようになりました。当時、データは通常 XML 形式で転送されていました。この名前が付けられました。しかし、冗長性が低く扱いやすいため、後に JSON が引き継がれました。最終的に、高度な機能とよりクリーンな構文を提供するフェッチ API が登場しました。

AJAX (非同期 JavaScript および XML): AJAX は、この革命の背後にある極めて重要なテクノロジーの 1 つでした。ページ全体をリロードすることなく、Web ページがバックグラウンドでサーバーと通信して必要なデータを取得し、DOM API と XMLHttpRequest の両方を使用してブラウザで直接コンテンツを更新する方法について説明しました。突然、ウェブが… インタラクティブに感じられ始めました。この名前も、データ転送に使用される XML に由来しています。

これにより状況はどう変わりましたか?

ブラウザの観点から: 新しい タグが HTML に導入され、開発者が JavaScript コードを HTML に直接追加できるようになりました。ブラウザのレンダリング エンジンが HTML を解析し、<script>タグを使用すると、スクリプトをフェッチして実行し (順序は非同期と遅延プロパティに依存します)、動的なコンテンツとインタラクティブな機能が可能になります。</script>

• JavaScript エンジン: これらのスクリプトを評価するために、JavaScript エンジンがブラウザに導入されました。初期のエンジンは比較的シンプルで低速でしたが、Google の V8 や Mozilla の SpiderMonkey などの最新のエンジンは大幅に進化し、より複雑なクライアント側ロジックが可能になりました。
  
  

• イベント ループ: JavaScript は、言語をシンプルかつ軽量に保つためにシングルスレッドのスクリプト言語として設計されました。この設計の選択は、限られたコンピューティング リソースや、DOM (Document Object Model) をスレッドセーフに保ち、DOM 操作時の競合状態を防ぐなどの要因にも影響を受けました。
  
  

  すべてのスクリプトの実行とレンダリングのタスクが単一のスレッドを共有するため、JavaScript にはメインスレッドをブロックせずに非同期操作を処理する方法が必要でした。これを実現するために、JavaScript は イベント ループ の概念に依存します。
  
  

  内部でどのように動作するかを見てみましょう:
  
  

  レンダリング エンジンが HTML を解析し、<script> を検出したとき。タグを使用すると、スクリプトがフェッチされ、JavaScript エンジンに渡されます。 JavaScript エンジンは、実行コンテキストを呼び出しスタックにプッシュすることにより、スクリプトの実行を開始します。 <br><br> </script>

  JavaScript は、ブラウザによって提供される Web API に依存して、メインスレッドをブロックせずに非同期タスクを処理します。これらには、タイマー (setTimeout、setInterval)、HTTP リクエスト (fetch、XMLHttpRequest)、DOM イベントなどの API が含まれます。非同期操作が呼び出されると、JavaScript エンジンはそれをコールバック関数とともに Web API に渡し、残りのコードの実行を続けます。この非同期タスクが完了すると、ブラウザはコールバックをそれぞれのタスク キュー (マイクロタスク キューまたはマクロタスク キュー) にプッシュします。
  
  

  イベント ループが
  
  

  のレンダリングとともにこのキューを管理する方法を次に示します。

  1. Microtask Queue: Promise、MutationObserver コールバックなどがここに入ります。このキューの優先度が最も高くなります。コール スタックが空になった後、イベント ループはマイクロタスク キューをチェックします。キュー内のすべて のマイクロタスクを、実行のために呼び出しスタックにプッシュすることで、次々に処理します。マイクロタスクがキューに新しいマイクロタスクを追加する場合、それらも処理されてから次に進みます。
  
  

  2.レンダリング: マイクロタスク キューが空になると、レンダリング エンジンがメイン スレッドを引き継ぎ、必要に応じてレンダリングを実行することがあります。これには、スクリプトの実行およびマイクロタスクの処理中に行われた DOM の変更を反映するための UI の更新が含まれます。これは、パフォーマンスを最適化するために、デバイスのフレーム レートに基づいてフレームごとに 1 回実行されます。
  
  

  3 . Macrotask Queue: setTimeout、setInterval、DOM イベント、I/O イベントなどからのコールバックがここに入ります。このキューは優先度が最も低くなります。イベント ループは、このキューから 1 つのタスクを取得して実行します。このタスクを実行すると、次のマクロタスクをプルする前に、すべてのマイクロタスクとレンダリングが処理されます。
  
  

  [スタックを空にする] → [すべてのマイクロタスクを処理] → [必要に応じてレンダリング] → [1 つのマクロタスクを実行] → 繰り返し

サーバー側: クライアント側でより多くのユーザー インターフェイスとユーザー インタラクションを処理するようになり、サーバーは焦点を移し始めました。サーバーは API を通じてデータとビジネス ロジックを提供し始めました。これらは、静的な HTML ファイルの提供から、リクエストを処理し、データベースと対話し、データを提供するための複雑な計算を実行する強力なエンジンへと進化しました。ブラウザ向けにサービスを提供するだけでなく、幅広いクライアント (モバイルまたはデスクトップ アプリケーション、その他のサーバーなど) にサービスを提供し始めました。

REST: REST の概念が普及しました。 REST (Representational State Transfer) は、Web サービスを設計するための一連のガイドラインと制約を提供するアーキテクチャ スタイルです。要約すると、各リソースは URL によって一意に識別され、ステートレスなクライアント/サーバー対話でこれらのリソースを操作するには、GET、POST、PUT、DELETE などの標準 HTTP メソッドが使用されます。これにより、サーバーはシンプルでスケーラブルで効率的になります。

アプリケーションの人気が高まるにつれて、サーバーはより多くのデータ処理とビジネス ロジックを処理する必要がありました。データを非常に効率的に処理するために必要なアプリケーション サーバーとデータベース サーバー。サーバーは、この重い負荷に対処するために、サーバー側のキャッシュ、負荷分散とスケーラビリティ、マイクロサービス アーキテクチャなど、いくつかの新しい技術を実装する必要がありました。

JavaScript EveryWhere: NodeJS (JavaScript ランタイム環境) の導入により、JavaScript をブラウザーの外部で実行できるようになり、「JavaScript EveryWhere」(クライアント側とサーバー側) の概念が導入されました。 ）。これに伴い、開発者が JavaScript コードを簡単に共有できるようにする npm (ノード パッケージ マネージャー) が導入されました。これらにより、JS エコシステムは急速に成長し、プロジェクトに必要なすべてのツール (フレームワーク、バンドラー、コンパイラー、トランスパイラーなど) を提供しました。

シングル ページ アプリケーション: JavaScript がクライアント側で DOM の作成と操作を行うようになったため、複雑なアプリケーションをより効率的に構築するためのフレームワークが必要になりました。 Angular、React などのフレームワークを導入します。これはクライアント側スクリプトの頂点です。基本的に、SPA では、サーバーから取得される小さな HTML ファイルは 1 つだけです。このファイルは、1 つの <script> にバンドルされたアプリケーション全体の Javascript で構成されます。タグ。そして、このスクリプトは、最初のレンダリングを含むすべてのユーザー操作と UI 更新を単独で処理します。</script>

まだまだ課題はある

このフェーズでは前のフェーズの課題は解決されましたが、次のような新たな課題が生じました。

• 初期ロード時間の延長: SPA は多くの場合、初期 JavaScript バンドルが大規模であることを意味し、特に低速なネットワークやデバイスでは初期ロード時間が遅くなる可能性があります。ユーザーがその一部だけを必要としている場合でも、予告編を見るためだけに映画全体をダウンロードするのと同じように、スクリプト全体を入手する必要があります。開発者はこれを最適化するために、コード分割、遅延読み込み、ツリーシェイク、縮小化などの手法を採用する必要がありました。
  
  

• SEO の懸念: コンテンツのほとんどは動的に生成されるため、検索エンジンはこれらの Web サイトをインデックスに登録するのに苦労しています。 Google のクローラーがサイトを認識できないと、気づくのは困難です。サーバーサイド レンダリング (SSR) やプリレンダリングなどの技術により、これらの問題に対処できます。
  
  

• JavaScript 疲労: 新しいフレームワーク、ツール、ライブラリが毎日登場する中、開発者は追いつくことに疲れてきました。最新のトレンドを追い続けることは、終わりのないトレッドミルで走っているようなものです。また、選択肢が多すぎて適切なスタックを選択するのが非常に難しくなりました。
  
  

• より速く、しかしより遅い: サーバー側とクライアント側の両方のパフォーマンスは向上していますが、開発者がユーザーに感動を与えたいほどではありません。また、ブラウザは高速で機能的ですが、ネイティブ アプリケーションほど高速でも機能でもありません。たとえば、ゲームやビデオエディタなどの複雑なアプリケーションを構築することはできません。
  
  

第 4 フェーズ: 現代の Web とその先へ

Web 開発の現代へようこそ — Web がかつてないほどダイナミックで、強力で、ユーザー中心になっている時代です。前のフェーズの課題を解決できる可能性がある、現在起こっているいくつかの既存の事柄について説明しましょう。

単一の完璧なレンダリング ソリューションは存在しない

前のフェーズの後、すべての人にとって完璧なレンダリング戦略は存在しないことがわかりました。要件と制約に基づいて、正しい、場合によってはハイブリッドのレンダリング戦略を選択する必要があります。ここでは、そのようなレンダリング戦略をいくつか紹介します

1. 静的サイト生成 (SSG): JavaScript がユーザーのブラウザーで HTML を作成するクライアントサイド レンダリング (CSR) とは異なり、SSG はビルド時に HTML ファイル全体を生成し、これらの事前生成された静的サイトを提供します。リクエストに応じて、HTML、CSS、JS ファイルをユーザーに提供します。 CDN を使用して応答を迅速化することもできます。

   初期読み込み時間の延長や SEO の問題などの問題を解決します。また、非常に高速な First Contentful Paint も備えています。静的ファイルは CDN 経由で簡単に提供できるため、スケーリングの問題についてあまり心配する必要はありません。 Web サイト内のコンテンツのほとんどが静的である場合は、この戦略を選択できます。ただし、コンテンツがより動的でユーザー固有の場合、これはうまく機能しません。このような場合、以下で説明するように、SSG と CSR とハイドレーションを使用したハイブリッド アプローチを選択できます。また、サーバーレス API およびエッジ機能での SSG の使用について詳しく説明している JAMStack もチェックしてください。

2. サーバーサイド レンダリング (SSR): これは 2 番目のフェーズと少し似ていますが、ここではビジネス ロジックがクライアント側のスクリプトから分離されています。基本的に、ブラウザがスクリプトを実行して HTML を生成するのではなく、サーバー上でスクリプトを実行して HTML を生成し、ユーザーのリクエストごとにそれをブラウザに提供します。

   繰り返しますが、初期読み込み時間の延長や SEO の問題などの問題は解決されますが、サーバーの負荷は増加します。また、ほとんどの人は、ユーザーが操作するたびにページがリロードされることを望まないため、ハイドレーションを伴う CSR を含むハイブリッド アプローチを採用する必要があります。

水分補給: 基本的に、最初に静的 HTML ファイルを提供してレンダリングし、最初のレンダリング後に JavaScript を実行することでユーザーの対話機能を追加します。静的 Web ページを動的 Web ページに変換するこのプロセスは、ハイドレーション と呼ばれます。ハイドレーション後、アプリケーションは CSR アプリケーションと同様に動作します。

ハイドレーションにはいくつかの問題があり、ユーザーはコンテンツを見てすぐに操作できません。このスクリプトがダウンロードされて実行されるまで待つ必要があり、これによっても CSR と同様のオーバーヘッド時間が追加されます。これを軽減するために、段階的水分補給や部分的水分補給などの新しい水分補給アプローチがありますが、これらは実装が困難です。

Next.js、Nuxt.js、Gatsby、React などの最新のフレームワークは、増分静的再生成やストリーミング SSR などの新しい技術とともに、これらのさまざまなレンダリング戦略を提供します。

---

かなり疲れますよね！はい、わかっていますが、ほぼ完了です。追加または提案された既存の Web API も多数あります。すべてをカバーすることはできませんが、Web Workers、IndexedDB、Shared Storage などのいくつかの注目すべき API をチェックしてください。

しかし、ここでは私たちが注目できる 2 つの主要な Web テクノロジーを紹介します

WebAssembly (Wasm)

最新の JavaScript エンジンは JS の高速化に取り組んでいますが、主なボトルネックは、JS が動的に型指定され、コンパイルされない言語であるという事実にあります。これは、本当にパフォーマンスを重視する計算を JS に依存できないことを意味します。ここで WebAssembly が介入します。WebAssembly は、C、C、Rust などの言語で書かれたコードによって生成されるバイナリ命令形式であり、プラグインなしで最新のすべてのブラウザ上でネイティブに近い速度で実行できます。

Wasm は JavaScript と並行して動作し、JavaScript 間で関数を呼び出すことができます。 DOM の直接操作や他の Web API の使用はまだサポートされていませんが、進行中の開発では、この機能を間もなく追加することを目指しています。 Wasm は、ゲーム、画像処理、ビデオ編集など、パフォーマンスを重視するあらゆる Web アプリケーションに使用できます。

プログレッシブ ウェブ アプリ (PWA)

これほど広範な Web エコシステムがあるのに、なぜネイティブのような Web アプリケーションを構築できないのでしょうか?プログレッシブ Web アプリは、ブラウザーから直接インストールでき、ネイティブ アプリと同様に動作し、オフライン サポートやプッシュ通知などを提供する Web アプリケーションです。また、1 つのコードベースでプラットフォーム全体に高速で魅力的で信頼性の高いエクスペリエンスを提供します。

PWA の主要なコンポーネントは Service Worker で、ブラウザのメイン スレッドとは別にバックグラウンド スクリプトを実行します。 Web アプリ、ブラウザー、サーバー間のプロキシとして機能します。 Service Worker は、リクエストの処理方法を制御し、ユーザーの接続が安定するまで特定のアクションを遅らせることができます。これにより、Cache API を使用してリソースをキャッシュできるため、デバイスがオフラインまたは低速ネットワーク上にある場合でもコンテンツを提供でき、オンラインに戻ったらサーバーと同期できます。

ただし、すべての機能がブラウザ間で均一にサポートされているわけではありません。また、PWA を構築するには、キャッシュ戦略とオフライン動作を慎重に計画する必要があります。また、PWA はネイティブ アプリと比較して、まだすべてのデバイス機能にアクセスできるわけではありませんが、これは拡大しつつあります。

---

Web はまだ完璧ではありませんが、将来に目を向けると、Web、ネイティブ、デスクトップ アプリケーション間の境界線は曖昧になり続けています。非常に多くの新興テクノロジーにより、可能性は無限です。

これで私たちのブログは終わりになります。何か間違っている場合、または何か見逃している場合はお知らせください。探索を続け、学び続けてください。さようなら!

以上がWeb テクノロジーとブラウザの進化の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。