フロントエンドのパフォーマンス最適化を学ぶ準備として、HTMLページのレンダリングプロセスを理解する

現在、フロントエンドのパフォーマンス最適化について学んでいます。適切な解決策を見つけ、パフォーマンスのボトルネックを特定するには、ページレンダリングプロセスを理解する必要があります。私が見たもののいくつかを皆さんと共有します。
参考: レンダラーを理解する
ページのレンダリングには次の特徴があります。
• シングルスレッドイベントループ
• 明確に定義された、継続的かつ秩序ある操作（HTML5）
• トークン化とDOMツリーの構築
• リソースをリクエストしてプリロードする
• レンダリングツリーを構築し、ページを描画する
具体的には：
ネットワークから HTML の対応するバイトを取得すると、DOM ツリーの構築が開始されます。 UI の更新はブラウザのスレッドが担当します。以下の状況が発生すると、DOM ツリーの構築がブロックされます。
• HTML応答ストリームがネットワーク上でブロックされている
• ロードされていないスクリプトがあります
• スクリプトノードが検出されましたが、まだロードされていないスタイルファイルが存在します。レンダリングツリーは DOM ツリーから構築され、スタイルファイルによってブロックされます。
シングルスレッドのイベントループに基づいているため、スクリプトやスタイルのブロックがない場合でも、これらのスクリプトやスタイルが解析、実行、適用されると、ページのレンダリングがブロックされます。
ページのレンダリングがブロックされない状況:
•defer属性とasync属性の定義
• メディアタイプに一致するスタイルファイルがありません
• パーサーによってスクリプトノードやスタイルノードは挿入されません
以下に、例（完全なコード）でこれを説明しましょう。

コードをコピー

コードは次のとおりです。

<html>
<本文>
<link rel="スタイルシート" href="example.css">
<div>こんにちは！</div>
<スクリプト>
document.write('<script src="other.js"></scr' + 'ipt>');
</スクリプト>
<div>またこんにちは！</div>
<script src="last.js"></script>
</本文>
</html>

コードも分かりやすく、ブラウザで開くとすぐに目的のページが表示されます。次に、スローモーション再生を使用して、どのようにレンダリングされるかを確認してみましょう。

コードをコピー

コードは次のとおりです。

<html>
<本文>
<link rel="スタイルシート" href="example.css">
<div>こんにちは！</div>
<スクリプト>...

まず、パーサーは example.css を検出し、ネットワークからダウンロードします。スタイルシートをダウンロードするプロセスは時間がかかりますが、パーサーはブロックされずに解析を続行します。次に、パーサーはスクリプトタグに遭遇しますが、スタイルファイルがロードされていないため、スクリプトの実行はブロックされます。パーサーがブロックされており、解析を続行できません。

レンダリングツリーもスタイルファイルによってブロックされるため、この時点ではどのブラウザーもページをレンダリングしません。つまり、example.css ファイルをダウンロードできない場合、Hi there! は表示されません。
次に、続けます。。。

コードをコピー

コードは次のとおりです。

<html>
<本文>
<link rel="スタイルシート" href="example.css">
<div>こんにちは！</div>
<スクリプト>
document.write('<script src="other.js"></scr' + 'ipt>');
</スクリプト>

example.css ファイルが読み込まれると、レンダリングツリーが構築されます。
インラインスクリプトが実行されると、パーサーは other.js によってすぐにブロックされます。パーサーがブロックされると、ブラウザはペイント要求を受信し、ページに「Hi there!」が表示されます。
other.js がロードされると、パーサーは下方向に解析を続けます。。。

コードをコピー

コードは次のとおりです。

パーサーは last.js に遭遇するとブロックされ、その後ブラウザは別のレンダリング要求を受信し、ページに「Hi again!」と表示されます。最後に、last.js が読み込まれ、実行されます。
ただし、レンダリングのブロックを軽減するために、最新のブラウザでは投機的読み込みが使用されます。

上記の場合、スクリプトとスタイルファイルによってページのレンダリングが著しくブロックされます。プリロードの目的は、このブロック時間を短縮することだと思います。レンダリングがブロックされると、次の処理が実行されます。
• 軽量のHTML（またはCSS）スキャナがドキュメント内のスキャンを継続します
• 将来使用される可能性のあるリソースファイルのURLを見つける
• レンダラーが使用する前にダウンロードします。ただし、推測によるプリロードでは、JavaScript (例: document.write()) 経由で読み込まれたリソースファイルを検出できません。

注: すべての「最新」ブラウザはこの方法をサポートしています。
上記の例をもう一度見て、プリロードがどのように機能するかを推測してみましょう。

コードをコピー

コードは次のとおりです。

<html>
<本文>
<link rel="スタイルシート" href="example.css">
<div>こんにちは！</div>
<スクリプト>...

パーサーは example.css を返し、ネットワークから取得します。パーサーはブロックされず、解析を続行します。インラインスクリプトノードに遭遇すると、ブロックされます。スタイルファイルが読み込まれていないため、スクリプトの実行がブロックされます。レンダリングツリーもスタイルシートによってブロックされるため、ブラウザーはレンダリング要求を受信できず、何も表示されません。ここまでは、先ほど述べたのと同じアプローチです。しかしその後、状況は変わりました。

投機的ローダーはドキュメントの「読み取り」を継続し、last.js を見つけてロードしようとします。次：

コードをコピー

コードは次のとおりです。

<html>
<本文>
<link rel="スタイルシート" href="example.css">
<div>こんにちは！</div>
<スクリプト>
document.write('<script src="other.js"></scr' + 'ipt>');
</スクリプト>

example.css が読み込まれると、レンダリングツリーが構築され、インラインスクリプトを実行できるようになり、その後、パーサーは other.js によって再びブロックされます。パーサーがブロックされた後、ブラウザは最初のレンダリング要求を受信し、ページに「Hi there!」が表示されます。この手順は前の手順と同じです。それから：

コードをコピー

コードは次のとおりです。

パーサーは last.js を見つけますが、プリローダーがそれをロードしてブラウザキャッシュに配置したばかりなので、last.js はすぐに実行されます。その後、ブラウザはレンダリング要求を受信し、ページに「Hi again」と表示されます。
2 つの状況を比較することで、ページレンダリングについてある程度理解し、的を絞った最適化を行えるようになることを願っています。こんばんは！（終わり）^_^

<<: このポイントのJavaScriptの基本

>>: IE8 と Chrome でテーブルの幅を修正する方法