Webフロントエンド

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

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

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

重要なレンダリングパス

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

c言語は何に使用されますか

重要なレンダリングパス

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

スタイルシート

特定のCSSファイルが不要であることをブラウザに通知するには、mediaを設定する必要があります。スタイルシートを参照するすべてのリンクの属性。このアプローチでは、ブラウザーは現在のmediaに一致するリソースのみを処理します。（デバイスタイプ、画面サイズ）必要に応じて、他のすべてのスタイルシートの優先度を下げます（とにかく処理されますが、重要なレンダリングパスの一部としては処理されません）。たとえば、media='print'を追加した場合styleの属性ページを印刷するためのスタイルを参照するタグ。これらのスタイルは、メディアが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サイトのパフォーマンスを最適化するために最善を尽くします。そのため、ブラウザは通常、いわゆる「プリローダー」を実装します。プログラムのこの部分は、一度に複数のリクエストを行い、それらを並行して実行するために、HTMLでリクエストしたリソースの前にスキャンします。これが、スクリプトタグだけでなく、HTMLでも（行ごとに）スタイルタグを互いに近づけておく方がよい理由です。

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

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

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

基本を理解する

ウェブサイトの最適化とは何ですか？

ウェブサイトの最適化は、ウェブサイトを分析し、ウェブサイトの読み込みを高速化し、パフォーマンスを向上させるための変更を導入するプロセスです。測定はそのプロセスの重要な部分であり、測定がなければ、特定の変更が状況を改善したか悪化させたかを判断する方法はありません。

ウェブサイトのパフォーマンスを確認するにはどうすればよいですか？

GoogleのPageSpeedInsightsなどのオンラインツールを使用してみてください。また、ブラウザを「プライベートブラウジング」モードで使用して、データをローカルにキャッシュせずにサイトをロードすることもできます。一部のブラウザでは、スロットリングを使用することもできます。これは、遅い接続速度をシミュレートするのに役立ちます。