Webサイトのパフォーマンスと重要なレンダリングパスの最適化

公開: 2022-03-11

Webページのレンダリングパフォーマンスは今日の基準を満たしていますか？レンダリングとは、ユーザーがWebサイトにアクセスしたときに、サーバーの応答をブラウザーが「描画」する画像に変換するプロセスです。レンダリングパフォーマンスが悪いと、バウンス率が比較的高くなる可能性があります。

ページがレンダリングされるかどうかを決定するさまざまなサーバー応答があります。この記事では、HTMLの解析から始まるWebページの初期レンダリングに焦点を当てます（ブラウザーがサーバーの応答としてHTMLを正常に受信した場合）。レンダリング時間が長くなる可能性のあるものと、それらを修正する方法について説明します。

重要なレンダリングパス

重要なレンダリングパス（CRP）は、ブラウザがコードを画面上に表示可能なピクセルに変換するために実行するプロセスです。いくつかの段階があり、そのうちのいくつかは時間を節約するために並行して実行できますが、いくつかの部分は結果的に実行する必要があります。ここでそれが視覚化されます：

まず、ブラウザが応答を受け取ると、ブラウザはそれを解析し始めます。依存関係が発生すると、ダウンロードを試みます。

それがスタイルシートファイルである場合、ブラウザはページをレンダリングする前にそれを完全に解析する必要があります。そのため、 CSSはレンダリングブロッキングであると言われています。

スクリプトの場合、ブラウザは次のことを行う必要があります。解析を停止し、スクリプトをダウンロードして実行します。 JavaScriptプログラムはWebページのコンテンツ（特にHTML）を変更できるため、その後のみ解析を続行できます。そのため、 JSはパーサーブロッキングと呼ばれています。

すべての解析が完了すると、ブラウザーにはドキュメントオブジェクトモデル（DOM）とカスケードスタイルシートオブジェクトモデル（CSSOM）が構築されます。それらを組み合わせると、レンダーツリーが作成されます。ページの非表示部分は、ページの描画に必要なデータのみが含まれているため、レンダリングツリーには含まれません。

最後から2番目のステップは、レンダリングツリーをレイアウトに変換することです。この段階はリフローとも呼ばれます。ここで、すべてのレンダーツリーのノードのすべての位置とそのサイズが計算されます。

最後に、最後のステップはペイントです。これには、ブラウザが前の段階で計算したデータに従って、文字通りピクセルに色を付けることが含まれます。

最適化関連の結論

ご想像のとおり、Webサイトのパフォーマンスを最適化するプロセスには、以下を減らすWebサイトへの変更が含まれます。

転送する必要のあるデータの量
ブラウザがダウンロードする必要のあるリソースの数（特にブロックしているリソース）
CRPの長さ

さらに、それがどのように行われるかについて詳しく説明しますが、最初に、遵守すべき重要なルールがあります。

パフォーマンスを測定する方法

最適化の重要なルールは次のとおりです。最初に測定し、必要に応じて最適化します。ほとんどのブラウザの開発者ツールには、パフォーマンスと呼ばれるタブがあり、そこで測定が行われます。最速の初期（最初の）レンダリングを最適化する場合、注意すべき最も重要なことは、次のイベントの時間です。

ファーストペイント
最初の満足のいくペイント
最初の意味のあるペイント

ここで、「ペイント」とは、重要なレンダリングパスの最後の段階であるページのレンダリングが成功することを意味します。ブラウザはできるだけ早く何かを表示して後で更新しようとするため、いくつかのレンダリングが次々に発生する可能性があります。

レンダリング時間の他に、考慮すべき点が他にもあります。最も重要なのは、使用されているブロッキングリソースの数と、それらのダウンロードにかかる時間です。この情報は、測定が行われた後、[パフォーマンス]タブに表示されます。

パフォーマンス最適化戦略

上記で学んだことを考えると、Webサイトのパフォーマンスを最適化するための3つの主要な戦略があります。

有線で転送されるデータの量を最小限に抑え、
有線で転送されるリソースの総数を減らし、
重要なレンダリングパスを短縮する

1.転送するデータの量を最小限に抑えます

まず、JavaScriptで到達できない関数、どの要素とも一致しないセレクターを持つスタイル、CSSで永久に非表示になっているHTMLタグなど、未使用の部分をすべて削除します。次に、すべての重複を削除します。

次に、最小化の自動プロセスを導入することをお勧めします。たとえば、バックエンドが提供しているもの（ソースコードは除く）からすべてのコメントを削除し、追加情報を持たないすべての文字（JSの空白文字など）を削除する必要があります。

これが行われた後、私たちに残されているのはテキストとしてである可能性があります。これは、GZIP（ほとんどのブラウザが理解できる）などの圧縮アルゴリズムを安全に適用できることを意味します。

最後に、キャッシングがあります。ブラウザが最初にページをレンダリングするときは役に立ちませんが、その後のアクセスで大幅に節約できます。ただし、次の2つの点に注意することが重要です。

CDNを使用する場合は、キャッシュがサポートされ、適切に設定されていることを確認してください。
リソースの有効期限が来るのを待つのではなく、自分の側から早く更新する方法が必要になる場合があります。ローカルキャッシュを無効にできるように、ファイルの「フィンガープリント」をURLに埋め込みます。

もちろん、キャッシュポリシーはリソースごとに定義する必要があります。変更されることはめったにないか、まったく変更されない場合があります。他のものはより速く変化しています。機密情報が含まれているものもあれば、公開されていると見なされるものもあります。「private」ディレクティブを使用して、CDNがプライベートデータをキャッシュしないようにします。

ウェブ画像の最適化も行うことができますが、画像リクエストは解析もレンダリングもブロックしません。

2.重要なリソースの総数を減らします

「クリティカル」とは、Webページが適切にレンダリングされるために必要なリソースのみを指します。したがって、プロセスに直接関係しないすべてのスタイルをスキップできます。そして、すべてのスクリプトも。

スタイルシート

特定のCSSファイルが不要であることをブラウザに通知するには、スタイルシートを参照するすべてのリンクにmedia属性を設定する必要があります。このアプローチでは、ブラウザは現在のmedia （デバイスタイプ、画面サイズ）に一致するリソースのみを必要に応じて処理し、他のすべてのスタイルシートの優先度を下げます（これらはとにかく処理されますが、重要なレンダリングの一部としては処理されません）道）。たとえば、ページを印刷するためのスタイルを参照するstyleタグにmedia="print"属性を追加すると、これらのスタイルは、メディアがprintされないとき（つまり、ブラウザのページ）。

プロセスをさらに改善するために、いくつかのスタイルをインライン化することもできます。これにより、スタイルシートを取得するために必要だったサーバーへのラウンドトリップが少なくとも1回節約されます。

スクリプト

上記のように、スクリプトはDOMとCSSOMを変更できるため、パーサーブロッキングです。したがって、それらを変更しないスクリプトはブロック解析であってはならず、したがって時間を節約できます。

これを実装するには、すべてのスクリプトタグに属性（ asyncまたはdefer ）をマークする必要があります。

asyncでマークされたスクリプトは、CSSOMがビルドされる前に実行できるため、DOM構築またはCSSOMをブロックしません。ただし、インラインスクリプトは、CSSの上に配置しない限り、とにかくCSSOMをブロックすることに注意してください。

対照的に、 deferでマークされたスクリプトは、ページの読み込みの最後に評価されます。したがって、ドキュメントに影響を与えないようにする必要があります（そうしないと、再レンダリングがトリガーされます）。

つまり、 deferを使用すると、ページの読み込みイベントが発生するまでスクリプトは実行されませんが、 asyncを使用すると、ドキュメントの解析中にスクリプトをバックグラウンドで実行できます。

3.クリティカルレンダリングパスの長さを短くします

最後に、CRPの長さを可能な限り短くする必要があります。部分的には、上記のアプローチがそれを行います。

スタイルタグの属性としてのメディアクエリは、ダウンロードする必要のあるリソースの総数を減らします。スクリプトタグ属性deferおよびasyncは、対応するスクリプトが解析をブロックするのを防ぎます。

GZIPを使用したリソースの縮小、圧縮、およびアーカイブにより、転送されるデータのサイズが削減されます（これにより、データ転送時間も短縮されます）。

一部のスタイルとスクリプトをインライン化すると、ブラウザーとサーバー間のラウンドトリップの数を減らすことができます。

まだ説明していないのは、ファイル間でコードを再配置するオプションです。最高のパフォーマンスに関する最新のアイデアによると、Webサイトが最初に最速で実行する必要があるのは、ATFコンテンツを表示することです。 ATFはフォールドの上を表します。これは、スクロールせずにすぐに表示される領域です。したがって、必要なスタイルとスクリプトが最初にロードされ、他のすべてが停止するように、レンダリングに関連するすべてを再配置するのが最善です-解析もレンダリングもしません。また、変更を加える前後に必ず測定することを忘れないでください。

結論：最適化はスタック全体を網羅します

要約すると、Webサイトのパフォーマンスの最適化には、キャッシュ、CDNの設定、リファクタリング、リソースの最適化など、サイトの応答のすべての側面が組み込まれていますが、これらはすべて段階的に実行できます。 Web開発者は、この記事を参照として使用する必要があります。また、実験の前後にパフォーマンスを測定することを常に忘れないでください。

ブラウザ開発者は、アクセスするすべてのページのWebサイトのパフォーマンスを最適化するために最善を尽くします。そのため、ブラウザは通常、いわゆる「プリローダー」を実装します。プログラムのこの部分は、一度に複数のリクエストを行い、それらを並行して実行するために、HTMLでリクエストしたリソースの前をスキャンします。これが、スクリプトタグだけでなく、HTML（行単位）でもスタイルタグを互いに近づける方がよい理由です。

さらに、DOMまたはCSSOMの変更だけでなく、デバイスの向きの変更やウィンドウのサイズ変更によってもトリガーされる複数のレイアウトイベントを回避するために、HTMLへの更新をバッチ処理してみてください。

有用なリソースと参考資料：

PageSpeed Insights
キャッシングチェックリスト
WebサイトでGZIPが有効になっているかどうかをテストする方法
高性能ブラウザネットワーキング：IlyaGrigorikによる本