ウェブパフォーマンス

Web パフォーマンスとは、Web ページがダウンロードされてユーザーのWeb ブラウザに表示される速度を指します。Webパフォーマンス最適化 (WPO)またはWeb サイト最適化は、Web パフォーマンスの向上に関する知識分野です。

ウェブサイトのダウンロード速度が速いと、特にインターネット接続が遅いユーザーやモバイルデバイスを使用しているユーザーにおいて、訪問者の維持率と忠誠度^{[1] [2]}およびユーザー満足度が向上することが示されています。^[3]また、ウェブパフォーマンスが向上するとウェブ上を移動するデータも少なくなり、ウェブサイトの電力消費と環境への影響が軽減されます。^[4]ページの読み込み速度に影響を与える要素には、ブラウザ/サーバーキャッシュ、画像の最適化、暗号化（SSLなど）などがあり、ページのレンダリング時間に影響を与える可能性があります。 ウェブページのパフォーマンスは、多層キャッシュ、プレゼンテーション層コンポーネントの軽量設計、サーバー側コンポーネントとの非同期通信などの手法によって向上できます。

ウェブが登場して最初の10年ほどは、ウェブパフォーマンスの改善は主にウェブサイトのコードを最適化し、ハードウェアの限界を押し上げることに重点が置かれていました。2002年に出版されたPatrick Killeleaの著書『Web Performance Tuning』によると、初期の技術には、単純なサーブレットやCGIの使用、サーバーメモリの増強、パケット損失と再送信の調査などがありました。^[5]これらの原則は現在、インターネットアプリケーションの最適化された基盤の多くを構成していますが、ブラウザの表示速度を改善しようとする試みがはるかに少なかったという点で、現在の最適化理論とは異なります。

スティーブ・サウダーズは2004年に「ウェブパフォーマンス最適化」という用語を作り出した。^[6]当時サウダーズは、ウェブサイトがデフォルトで高速であること、統合、パフォーマンスのためのウェブ標準、最適化の環境への影響、差別化要因としての速度など、「新興産業」としてのWPOがウェブにもたらす影響についていくつかの予測を立てた。^[7]

2007 年にサウダーズが指摘した重要なポイントの 1 つは、Web サイトのダウンロードと表示にかかる時間の少なくとも 80% はフロントエンド構造によって制御されるということです。この遅延時間は、一般的なブラウザの動作とHTTP の仕組みを理解することで短縮できます。^[8]

Web パフォーマンスの最適化は、Web サイトを訪問する際のユーザー エクスペリエンス(UX) を向上させるため、 Web デザイナーやWeb 開発者に強く求められています。彼らは、Web 最適化タスクを効率化して Web ページの読み込み時間を短縮するいくつかの手法を採用しています。このプロセスは、フロント エンド最適化 (FEO) またはコンテンツ最適化と呼ばれます。FEO は、ファイル サイズの削減と「特定のページの読み込みに必要なリクエストの数を最小限に抑える」ことに重点を置いています。

以下に挙げた技術に加えて、コンテンツ配信ネットワーク(世界中のさまざまな場所に分散したプロキシ サーバーのグループ) を使用すると、ネットワークの近さに基づいて特定のユーザー用のサーバーを選択する効率的な配信システムになります。通常は、応答時間が最も速いサーバーが選択されます。

以下の手法は、Web 最適化タスクでよく使用され、Web 開発者によって広く使用されています。

Web ブラウザは、Web ページをダウンロードするときに送信されるハイパーテキスト転送プロトコル(HTTP) 要求ごとに個別の伝送制御プロトコル(TCP) 接続を開きます。これらの要求の合計は、ダウンロードに必要なページ要素の数になります。ただし、ブラウザは、単一のホストに対して一定数の同時接続しか開くことができません。ボトルネックを防ぐために、リソース統合を使用して個々のページ要素の数を減らします。リソース統合では、小さなファイル (画像など) を 1 つのファイルにまとめます。これにより、HTTP 要求と、Web ページの読み込みに必要な「往復」回数が減ります。

Web ページは、 JavaScriptやハイパーテキスト マークアップ言語(HTML)などのコード ファイルから構成されます。Web ページが複雑になるにつれて、コード ファイルも複雑になり、読み込み時間も長くなります。ファイル圧縮により、コード ファイルを最大 80 パーセント削減できるため、サイトの応答性が向上します。

Web キャッシュの最適化により、サーバーの負荷、帯域幅の使用、および待ち時間が削減されます。CDN は、専用の Web キャッシュソフトウェアを使用して、システムを通過するドキュメントのコピーを保存します。特定の条件が適用される場合、キャッシュからの後続の要求が満たされることがあります。Web キャッシュは、CDN のクライアント側 (前方位置) または Web サーバー側 (後方位置) のいずれかにあります。Web ブラウザーは、HTTP キャッシュまたはWeb キャッシュを介して再利用するためにコンテンツを保存することもできます。Web ブラウザーが行う要求は通常、HTTP キャッシュにルーティングされ、キャッシュされた応答が要求を満たすために使用できるかどうかが検証されます。一致すると、応答はキャッシュから満たされます。これは、ネットワークの待ち時間とデータ転送に関連するコストを削減するのに役立ちます。HTTP キャッシュは、要求ヘッダーと応答ヘッダーを使用して構成されます。

コードの縮小は、Web 開発者が記述したコードとネットワーク要素がコードを解釈する方法との間の矛盾を区別します。縮小は、コメントと余分なスペースを削除し、変数名を圧縮してコードを最小化し、ファイル サイズを最大 60% 削減します。キャッシュと圧縮に加えて、非可逆圧縮技術 (オーディオ ファイルで使用されるものと同様) は、不要なヘッダー情報を削除し、多くの高解像度画像で元の画像品質を低下させます。ピクセルの複雑さや色のグラデーションなどのこれらの変更は、エンド ユーザーには透過的であり、画像の認識に顕著な影響を与えません。別の手法は、ラスター グラフィックスを解像度に依存しないベクター グラフィックスに置き換えることです。ベクター置換は、単純な幾何学的画像に最適です。^{[引用が必要]}

画像や動画の遅延読み込みは、ページの初期読み込み時間、ページの初期重量、システムリソースの使用を削減し、ウェブサイトのパフォーマンスにプラスの影響を与えます。^[9]これは、オブジェクトの初期化を、必要な時点まで延期するために使用されます。ブラウザは、ユーザーがページを下にスクロールしたときなど、必要なときにページまたは投稿内の画像を読み込みます。すべての画像を一度に読み込むのはデフォルトの動作であり、当然時間がかかります。

Web ブラウザは並列ユーザー リクエストに複数の TCP 接続を使用するため、輻輳やブラウザによるネットワーク リソースの独占が発生する可能性があります。HTTP/1 リクエストには関連するオーバーヘッドが伴うため、帯域幅の制限と使用量の増加により Web パフォーマンスが影響を受けます。

HTTP/1と比較すると、HTTP/2

• テキストではなくバイナリです
• 順序付けされてブロックされるのではなく、完全に多重化されている
• したがって、並列処理には1つの接続を使用できる
• ヘッダー圧縮を使用してオーバーヘッドを削減します
• サーバーが積極的にクライアントのキャッシュに応答を「プッシュ」できるようにする^[10]

CDNは通常、ウェブサイトのホスティングサーバーの代わりに、エンドユーザーに近い場所にあるため、画像、JavaScriptファイル、カスケーディングスタイルシート（CSS）ファイルなどのウェブリソースをエンドユーザーに適切に提供するために、HTTP/2と連携して使用されます。^[11]

近年、開発者がウェブサイトのパフォーマンスのさまざまな側面を測定するのに役立つ指標がいくつか導入されています。2019 年に Google は、Time to First Byte (TTFB)、First Contentful Paint (FCP)、First Paint (FP)、First Input Delay (FID)、Cumulative Layout Shift (CLS)、Largest Contentful Paint (LCP) などの指標を導入しました。これにより、ウェブサイトの所有者は、ウェブサイトのパフォーマンスを低下させ、ユーザーにウェブサイトが遅く感じられてしまう可能性のある問題について洞察を得ることができます。その他の指標には、リクエスト数（ページを読み込むために必要なリクエスト数）^[12] 、 DOMContentLoaded（CSSスタイルシート、画像などを除いたHTML文書が完全に読み込まれ解析されるまでの時間）^[13] 、スクロールせずに見えるコンテンツ^{[14]、[14]、}ラウンドトリップ時間^[14] 、レンダリングをブロックするリソースの数（スクリプト、スタイルシートなど）^[15]、オンロード時間、接続時間、合計ページサイズなどがあり、ネットワークレベルで発生しているレイテンシやスローダウンを正確に把握して、サイトの速度を低下させる可能性があります。^{[16] [17] [18]}

TTFB、FCP、LCP、FPなどの指標を測定するモジュールは、React ^[19] 、NuxtJS ^[20]、Vue ^[21]などの主要なフロントエンドJavaScriptライブラリで提供されています。Googleは、フロントエンドアプリケーションでこれらの指標を簡単に測定できるcore-web-vitalsライブラリを公開しています。これに加えて、GoogleはChrome開発ツールコンポーネントであるLighthouseと、開発者がウェブサイトのパフォーマンスを測定し、Googleが推奨する最小値と最大値と比較できるサイトであるPageSpeed Insightも提供しています。^[22]

これに加えて、Mozilla Firefoxのネットワークモニターなどのツールは、データ転送中に発生する可能性のあるネットワークレベルの速度低下についての洞察を提供するのに役立ちます。^[16]