Webブラウザの原理（わかりやすい）

1. ブラウザの理解についての話

ブラウザの主な機能は、ユーザーが選択した Web リソースを表示することであり、サーバーにリソースを要求してブラウザウィンドウに表示する必要があります。ブラウザは、シェルとカーネルの2 つの部分に分割できます。
シェルの種類は比較的多くありますが、カーネルの数は比較的少ないです。シェルとは、主にユーザーにインターフェイス操作を提供する、メニューやツールバーなどのブラウザのシェルを指します。カーネルを呼び出すことで様々な機能を実現します。
カーネルはブラウザの中核であり、カーネルはマークアップ言語に基づいてコンテンツを表示するプログラムおよびモジュールです。
簡単に言うと、カーネルはレンダリングエンジンと JS エンジンに分かれています。レンダリングエンジンの役割は、要求されたコンテンツをブラウザウィンドウにレンダリングして表示することです。デフォルトでは、html、xml ドキュメント、および画像をレンダリングでき、プラグインを使用して他のタイプのデータも表示できます。JS エンジンは、JavaScript を解析して実行し、Web ページの動的な効果を実現します。
当初、レンダリングエンジンと JS エンジンは明確に区別されていませんでしたが、その後、JS エンジンはますます独立し、カーネルはレンダリングエンジンのみを指す傾向にありました。

2. ブラウザのレンダリング原理

ブラウザレンダリングの原理については、そのようなプロセスだと思います。まず受信したドキュメントを解析し、ドキュメントに従って DOM ツリーを生成します。DOM ツリーは DOM 要素とその属性ノードで構成されます。次に、CSS ファイルを解析して CSSOM ルールツリーを生成し、DOM ツリーと CSSOM ルールツリーに基づいてレンダリングツリーを構築します。レンダリングツリーのノードはレンダリングオブジェクトと呼ばれ、レンダリングオブジェクトは DOM 要素ノードに対応します。ただし、1 対 1 の関係ではないため、非表示の DOM 要素はレンダーツリーに挿入されません。次に、レンダリングツリーに従ってレイアウトを作成します。これは、ページ上のレンダリングツリーの各ノードの正確な位置を決定し、レンダリングしてレンダリングツリーを走査し、レンダリングオブジェクトのペイントメソッドを呼び出してコンテンツを表示します。画面を表示し、UI基本コンポーネントを使用して描画します。もう 1 つのポイントは、より良いユーザーエクスペリエンスを確保するために、レイアウトとレンダリングはすべての HTML が解析されるまで待たず、コンテンツの一部は一部の解析後に表示され、同時に残りの部分も表示されます。コンテンツは引き続きネットワーク経由でダウンロードされる可能性があります。

3. ブラウザーの解析プロセスにおける async と defer の役割と違い

1. スクリプトに遅延または非同期がない場合、ブラウザは指定されたスクリプトをすぐにロードして実行します。つまり、後続のロードを待たずにドキュメント要素をロードして実行します。
2. defer 属性は、インポートされた JavaScript の実行の遅延を示します。つまり、この JavaScript がロードされても HTML の解析は停止せず、2 つのプロセスは並列です。ドキュメント全体が解析された後、DOMContentLoaded イベントがトリガーされる前に、スクリプトファイルを実行します。複数のスクリプトが順番に実行されます。
3. async 属性は、インポートされた JavaScript の非同期実行を示します。defer との違いは、JavaScript がロードされていれば実行を開始することです。つまり、その実行は依然としてドキュメントの解析をブロックしますが、ロードプロセスはブロックしません。。複数のスクリプトの実行順序は保証できません。

4. ブラウザ解析プロセスでのドキュメントの事前解析

JavaScript スクリプトの実行中に、別のスレッドがドキュメントの残りの部分を解析し、後でネットワーク経由でロードする必要があるリソースをロードします。このようにしてリソースを並行してロードできるため、全体的な速度が速くなります。事前解析では DOM ツリーは変更されず、この作業はメインの解析プロセスに委ねられ、外部スクリプト、スタイルシート、イメージなどの外部リソースへの参照のみが解析されることに注意してください。

5. ブラウザレンダリングの不具合現象

FOUC (スタイルのないコンテンツのちらつき): 主にスタイルのちらつきの問題を指します。ブラウザのレンダリングメカニズム (Firefox など) により、CSS が読み込まれる前に HTML がレンダリングされるため、スタイルのないコンテンツが表示され、その後スタイルが表示されます。突然現れる現象。この問題の主な理由は、CSS がドキュメントの下部に配置されているか、インポートによってインポートされているため、CSS の読み込み時間が長すぎることです。
解決策: 代わりに、LINK タグを使用してドキュメントの HEAD にスタイルシートを配置し、CSS スタイルを導入し、タグ内で CSS を参照します。
白い画面: 一部のブラウザーのレンダリング機構 (Chrome など) では、最初に DOM ツリーと CSSOM ツリーを構築し、構築が完了してからレンダリングする必要があります。CSS 部分が HTML の最後に配置されている場合、ブラウザーはレンダリングされていませんCSS が読み込まれていないため、CSS が読み込まれていないため、白い画面が表示される可能性があります。また、JS ファイルがヘッダーに配置され、スクリプトの読み込みによって後続のドキュメントの内容の分析がブロックされる可能性もあります。ページが長時間レンダリングされず、白い画面の問題が発生します。
解決策:
1. DOM ツリーのレンダリング時間を短縮します (HTML レベルは深すぎてはならず、タグはセマンティックでなければなりません...)
2. HTTP リクエストの数とリクエストのサイズを削減します
3. CSS を配置しますブロッキングを避けるために、Head と body の最後に js を追加します。
4. ssr レンダリングとプリレンダリングを使用します。

クライアント側レンダリング: ユーザーが URL にアクセスし、HTML ファイルをリクエストすると、フロントエンドがルートに従ってページコンテンツを動的にレンダリングします。キーリンクは長く、一定量の白い画面時間があります。

サーバーサイドレンダリング (ssr): ユーザーが URL にアクセスすると、サーバーはアクセスパスに従って必要なデータを要求し、それを HTML 文字列に連結してフロントエンドに返します。フロントエンドが HTML を受信すると、コンテンツの一部がすでに存在します。

プリレンダリング: ビルドフェーズでは、プリレンダリングパスに一致する HTML ファイルが生成されます (注: プリレンダリングが必要な各ルートには、対応する HTML があります)。構築された HTML ファイルには、すでにいくつかのコンテンツが含まれています。

6. ブラウザ描画の再描画とリフロー

再描画
: レンダリングツリー内の一部の要素が属性を更新する必要があり、これらの属性が要素の外観とスタイルにのみ影響し、背景色などのレイアウト操作には影響しない場合、そのような操作を再描画と呼びます。
リフロー: 要素のサイズ、レイアウト、非表示の変更により、レンダリングツリーの一部 (またはすべて) を再構築する必要がある場合、レイアウトの操作に影響します。このような操作をリフローと呼びます
。
リフローは必ず再描画を引き起こしますが、再描画は必ずしもリフローを引き起こすとは限りません。リフローのコストは再描画のコストよりもはるかに高く、親ノード内の子ノードを変更すると、親ノードの一連のリフローが発生する可能性があります。
逆流を減らす方法:
1. CSS 属性の省略形を使用してみてください。たとえば、boder-width、boder-style、boder-color の代わりに boder を使用します。

2.要素スタイルelem.classNameを一括変更

3. テーブルレイアウトの使用を避けるようにしてください (テーブル要素がリフローをトリガーすると、テーブル内の他のすべての要素がリフローされます)。

4. 複数の DOM ノードを作成する必要がある場合は、DocumentFragment を使用して作成します。

理由: ページが作成されるたびにリフローが発生するため、バッチ作成には DocumentFragment が使用されます。

5. CSS 式は記述しないようにしてください。値は呼び出しごとに再計算されるため（ページのロードを含む）