リソースの読み込みを最適化する

前のモジュールでは、クリティカル レンダリング パスの背後にある理論について、 レンダリング ブロックとパーサー ブロックのリソースが 表示されます。ここまでの説明で、Google Cloud の これで、重要なビジネス チャネルを最適化して レンダリング パスを指定します。

ページが読み込まれると、その HTML 内で多くのリソースが参照され、 CSS によるデザインとレイアウトに加え 使用できます。このモジュールでは、Terraform ワークフローの各フェーズに ページの読み込み時間に与える影響について説明します

レンダリング ブロック

前のモジュールで説明したように、CSS はrender-blocking リソースですが、 ブラウザがコンテンツをレンダリングしないよう、CSS オブジェクト モデル モデル（CSS）オブジェクト モデル（CSS）が （CSSOM）が構築されます。ブラウザはレンダリングをブロックし、 スタイルなしコンテンツ（FOUC）: ユーザー エクスペリエンスの観点から望ましくない。

前の動画では、短い FOUC がありますが、これは何もしなくてもページを見ることができます あらゆるスタイルに利用できますその後、ページの CSS が定義されれば、すべてのスタイルが適用されます。 ネットワークからの読み込みが終了し、 すぐにスタイル付きのバージョンに置き換わります。

一般的に FOUC は目に見えないものですが ブラウザがレンダリングをブロックする理由を理解するために、 CSS がダウンロードされてページに適用されます。レンダリング ブロック 必ずしも望ましくないとは限りませんが、その状態が続く時間や CSS を最適化し続けることができます

パーサーのブロック

パーサー ブロック リソース（<script> など）が HTML パーサーを中断する async 属性または defer 属性のない要素です。パーサーがエラーを検出すると、 <script> 要素がある場合、ブラウザは事前にスクリプトを評価して実行する必要があります。 続けて残りの HTML を解析しますこれは意図的なものです。スクリプトによっては、 DOM がまだ構築中の段階で、DOM の変更や DOM へのアクセスが行われることはありません。

<!-- This is a parser-blocking script: -->
<script src="/script.js"></script>

外部の JavaScript ファイル（async または defer なし）を使用する場合、パーサーは ファイルが検出されてからダウンロード、解析、 実行されます。インライン JavaScript を使用する場合も、パーサーは、 インライン スクリプトが解析されて実行されます。

<ph type="x-smartling-placeholder">

プリロード スキャナ

プリロード スキャナは、セカンダリ HTML の形式でブラウザを最適化する機能です。 パーサーは、未加工の HTML レスポンスをスキャンし、 プライマリ HTML パーサーで検出される前に、リソースを宣言する必要があります。対象 たとえばプリロード スキャナを使うと、ブラウザは <img> 要素で指定されたリソース（HTML パーサーがブロックされていても） CSS や JavaScript などのリソースを取得して処理できます

プリロード スキャナを活用するには、重要なリソースを含める必要があります。 。次のリソース読み込みパターンは、 または、プリロード スキャナで検出できません。

  • background-image プロパティを使用して CSS によって読み込まれた画像。これらの画像は 参照は CSS 内にあり、プリロード スキャナで検出できません。
  • 挿入された <script> 要素のマークアップの形式で動的に読み込まれるスクリプト JavaScript または動的 import() を使用して読み込まれたモジュールを使用して DOM に挿入します。
  • JavaScript を使用してクライアント上でレンダリングされる HTML。このようなマークアップは、 JavaScript リソース内の文字列で、プリロードでは検出されない できます。
  • CSS @import 宣言。

これらのリソース読み込みパターンはすべて遅延検出のリソースであるため、 プリロード スキャナの恩恵は受けません。可能な限り避けてください。条件 このようなパターンを避けることはできませんが、 リソース検出の遅延を回避するための preload ヒント。

<ph type="x-smartling-placeholder">

CSS

CSS によって、ページの表示やレイアウトが決まります。前述のとおり、CSS は はレンダリングをブロックするリソースであるため、CSS の最適化にはかなりの負荷が 全体的なページ読み込み時間への影響が わかります

圧縮

CSS ファイルを圧縮すると、CSS リソースのファイルサイズが小さくなり、 高速にダウンロードできますこれは主に、スペースからコンテンツを削除することで、 スペースなどの非表示文字などの CSS ソース ファイルと、 新しく最適化されたファイルにコピーします。

/* Unminified CSS: */

/* Heading 1 */
h1 {
  font-size: 2em;
  color: #000000;
}

/* Heading 2 */
h2 {
  font-size: 1.5em;
  color: #000000;
}

/* Minified CSS: */
h1,h2{color:#000}h1{font-size:2em}h2{font-size:1.5em}
<ph type="x-smartling-placeholder">

CSS の圧縮は最も基本的な形式として効果的な最適化で、 ウェブサイトの FCP、場合によっては LCP を 改善できます次のようなツール バンドラを使用すると、この最適化を本番環境で自動的に実行できます。 説明します。

使用していない CSS を削除する

ブラウザは、コンテンツをレンダリングする前に、すべてのコンテンツを あります。解析の完了までにかかった時間には、 使用されていないことを示します。すべての CSS をバンドルするバンドラを使用している場合 1 つのファイルにまとめると、ユーザーがダウンロードした CSS が 表示する必要があります

現在のページで使用されていない CSS を見つけるには、Chrome のカバレッジ ツールを使用します DevTools。

<ph type="x-smartling-placeholder">
</ph> Chrome DevTools のカバレッジ ツールのスクリーンショット。下部ペインで CSS ファイルが選択されており、現在のページ レイアウトで使用されていないかなりの量の CSS が表示されています。 <ph type="x-smartling-placeholder">
</ph> Chrome DevTools のカバレッジ ツールは、CSS（および JavaScript など）によって使用されます。CSS ファイルの分割に使用できる 複数のリソースに分割し 別々のページで読み込みます 大きな CSS バンドルを配信すると、ページのレンダリングが遅れる可能性があります。

使用していない CSS を削除すると、ダウンロードが減少することに加え、2 つの影響があります。 レンダリング ツリーの構築を最適化します。これは、ブラウザが 処理する CSS ルールの数が減る場合があります。

<ph type="x-smartling-placeholder">

CSS @import 宣言を避ける

便利そうに思えるかもしれませんが、CSS では @import 宣言は避けるべきです。

/* Don't do this: */
@import url('style.css');

HTML での <link> 要素の動作と同様に、@import 宣言は、 を使用すると、スタイルシートから外部の CSS リソースをインポートできます。「 2 つのアプローチの主な違いは、HTML の <link> 要素 HTML レスポンスの一部であるため、CSS よりもはるかに早く検出される @import 宣言によってダウンロードされるファイル。

これは、@import の宣言を その属性を含む CSS ファイルをダウンロードする必要があります。この その結果として「リクエスト チェーン」と呼ばれる状態が発生し、 最初の表示に要する時間ですもう一つのデメリットは @import 宣言を使用して読み込まれたスタイルシートが、 Scanner をプリロードしないため、遅れて検出されるレンダリング ブロック リソースになります。

<!-- Do this instead: -->
<link rel="stylesheet" href="style.css">

ほとんどの場合、次のコマンドを使用して @import を置き換えることができます。 <link rel="stylesheet"> 要素。<link> 要素を使用すると、スタイルシートを作成できます。 同時にダウンロードされ、全体的な読み込み時間が短縮されます（@import の場合との比較） 宣言。これにより、スタイルシートが連続してダウンロードされます。

<ph type="x-smartling-placeholder">

クリティカルな CSS をインライン化する

CSS ファイルのダウンロードに時間がかかると、ページの FCP が増加することがあります。インライン化 ドキュメント <head> 内のクリティカル スタイルにより、 正しく設定されていれば、CSS リソースが原因で初期読み込みが ユーザーのブラウザ キャッシュが準備されていません。残りの CSS も読み込むことができます。 非同期でアップロードするか、<body> 要素の末尾に追加します。

<ph type="x-smartling-placeholder"> 
<head>
  <title>Page Title</title>
  <!-- ... -->
  <style>h1,h2{color:#000}h1{font-size:2em}h2{font-size:1.5em}</style>
</head>
<body>
  <!-- Other page markup... -->
  <link rel="stylesheet" href="non-critical.css">
</body>
<ph type="x-smartling-placeholder">

この方法の欠点は、大量の CSS をインライン化すると初期部分のバイト数が増えるというデメリットです。 HTML レスポンス。HTML リソースは、たいてい長期間（または特定の時点）でキャッシュ all — これはインライン CSS がキャッシュされず、後続の 外部スタイルシートで同じ CSS を使用します。ページの そのトレードオフが労力に見合うものに なるようにします

CSS のデモ

JavaScript

JavaScript はウェブのインタラクティビティの大半を占めますが、その代償が伴います。 送信する JavaScript が多すぎると、ページ再生中にウェブページの応答が遅くなる可能性がある 応答性の問題を引き起こし、やり取りの速度を低下させる ユーザーにとってフラストレーションがたまります

レンダリングをブロックする JavaScript

defer 属性または async 属性を指定せずに <script> 要素を読み込むと、 ブラウザは、スクリプトのダウンロード、解析、ダウンロードが完了するまで、解析とレンダリングをブロックします。 実行されます。同様に、インライン スクリプトは、スクリプトが解析されるまでパーサーをブロックします。 実行されます。

async 対 defer

async と defer により、HTML をブロックせずに外部スクリプトを読み込むことができる type="module" を含むスクリプト（インライン スクリプトを含む）は 自動的に延期される。ただし、async と defer にはいくつかの違いがあります。 理解することが重要です。

<ph type="x-smartling-placeholder">
</ph> さまざまなスクリプト読み込みメカニズムの図。async、defer、type=&#39;module&#39; などのさまざまな属性に基づくパーサー、フェッチ、実行のロールが詳しく説明されています。3 つの組み合わせになります <ph type="x-smartling-placeholder">
</ph> 出典: https://html.spec.whatwg.org/multipage/scripting.html

async で読み込まれたスクリプトは、ダウンロード後すぐに解析されて実行されます。 一方、defer で読み込まれたスクリプトは、HTML ドキュメントの解析結果が 終了 - これはブラウザの DOMContentLoaded イベントと同時に発生します。 また、async スクリプトは順不同で実行され、defer スクリプトは実行されることがあります。 マークアップに出現する順序で実行されます。

<ph type="x-smartling-placeholder">

クライアントサイド レンダリング

一般的に、クリティカルなコンテンツやコンテンツのレンダリングに JavaScript を使用することは ページの LCP 要素をご覧ください。これはクライアントサイド レンダリングと呼ばれ、 シングルページ アプリケーション（SPA）で広く使用されています。

JavaScript によってレンダリングされるマークアップは、リソースとしてプリロード スキャナを回避するため、 クライアントがレンダリングするマークアップに含まれていることを検出することはできません。この LCP イメージなどの重要なリソースのダウンロードが遅れる可能性があります。ブラウザ LCP イメージのダウンロードは、スクリプトの実行後にのみ開始され、 DOM に送りますつまり、スクリプトを実行できるのは、次のタスクが完了してからで ダウンロード、解析されます。これはクリティカル リクエストと呼ばれ、 回避する必要があります。

また、JavaScript を使用してマークアップをレンダリングすると、 時間のかかるタスク: ナビゲーションの応答としてサーバーからダウンロードされるマークアップよりも リクエストできます。HTML のクライアントサイド レンダリングを多用すると、 インタラクションのレイテンシ。これは特に、ページの DOM が 非常に大規模: JavaScript によって変更が行われた場合に、大量のレンダリング処理がトリガーされます。 説明します。

圧縮

CSS と同様に、JavaScript を圧縮すると、スクリプト リソースのファイルサイズが縮小されます。 これによりダウンロードが速くなり、ブラウザを JavaScript の解析とコンパイルを高速化するプロセスです。

さらに、JavaScript の圧縮は、JavaScript の 他のアセット（CSS など）ですJavaScript を圧縮すると、コード自体が削除されるだけでなく、 スペース、タブ、コメントなどは除外されますが、ソース内の記号は JavaScript は短縮されています。このプロセスは、uglification とも呼ばれます。宛先 次の JavaScript ソースコードを渡して、違いを確認してください。

// Unuglified JavaScript source code:
export function injectScript () {
  const scriptElement = document.createElement('script');
  scriptElement.src = '/js/scripts.js';
  scriptElement.type = 'module';

  document.body.appendChild(scriptElement);
}

上記の JavaScript ソースコードが省略されていると、結果は次のようになります。 次のコード スニペットのようになります。

// Uglified JavaScript production code:
export function injectScript(){const t=document.createElement("script");t.src="/js/scripts.js",t.type="module",document.body.appendChild(t)}

上記のスニペットでは、人間が判読できる変数が ソース内の scriptElement は t に短縮されます。大きなスペース全体に適用すると、 大幅に削減できた場合、 ウェブサイトの本番用 JavaScript が提供する機能。

バンドラを使用してウェブサイトのソースコードを処理している場合は、 本番環境のビルドでは多くの場合、自動的に行われます。拡大鏡（Terser など） 高度な構成も可能です。 費用を最大限に削減するための積極的な拡張が必要です。 ただし、通常は、あらゆる表現ツールのデフォルト設定で十分です。 出力サイズと機能保持の適切なバランスを取る必要があります。

JavaScript のデモ

理解度テスト

ブラウザで複数の CSS ファイルを読み込む最善の方法は何ですか。

CSS の @import 宣言。
もう一度お試しください。
複数の <link> 要素。
正解です。

ブラウザのプリロード スキャナには、どのような機能がありますか。

未加工のマークアップを調べて内容を発見する二次的な HTML パーサー リソースを事前に追加しておくことで、より早く検出できます。
正解です。
<link rel="preload"> 要素を検出します。 使用できます。
もう一度お試しください。

ブラウザの設定で、デフォルトで HTML の解析が一時的にブロックされるのはなぜですか？ ダウンロードしますか？

スタイルが設定されていないコンテンツ（FOUC）のフラッシュを防止するため。
もう一度お試しください。
JavaScript の評価は CPU 使用率が非常に高いタスクであるため、 HTML 解析では、スクリプトの読み込みを完了するためにより多くの帯域幅を CPU に与えることができます。
もう一度お試しください。
スクリプトは DOM の変更や DOM へのアクセスが可能なため。
正解です。

次のステップ: リソースヒントによるブラウザのサポート

これで、<head> 要素に読み込まれたリソースがどのように処理されるかを把握できたので、 影響があることを確認したら 次に進みます次の リソースヒントについて見ていきます。また、リソースヒントがリソースのヒントとして ブラウザがリソースの読み込みを開始し、クロスオリジンへの接続が開かれます。 ブラウザなしで取得できるからです