ウェブサイトのパフォーマンスを最適化する方法

このガイドでは、ウェブページの読み込み時間を改善するための実践的な戦略と高度なテクニックを解説します。パフォーマンスを微調整し、あらゆるデバイスで高速かつ信頼性の高いユーザーエクスペリエンスを実現するための具体的な方法をご紹介します。既存のコードベースを扱う場合でも、ゼロから開発する場合でも、ウェブサイトの速度を最適化するための具体的な手順を以下に示します。

ウェブサイトのパフォーマンスを最適化する方法 ― ベストプラクティスの概要

テストページのパフォーマンス

どんな問題でも解決への第一歩は、何を解決すべきかを知ることである。 Google コア ウェブ バイタル これらは標準的なページパフォーマンス指標です。主な指標を以下に示します。

コアウェブの必須要素ではないが、 総ブロッキング時間（TBT）は、INPよりも前から存在するもう一つの重要な指標です。 また、ページ読み込み中にメインスレッドがブロックされる時間を測定するのに役立ちます。特に、INPを直接測定することが難しい実験室環境などでは、TBTは潜在的なINPの問題を示す有用な指標となる場合があります。 

しかし、TBTはラボにおけるINPの妥当な代替指標となり得るものの、それ自体がINPの代替となるものではないことを覚えておくことが重要です。TBTは実際にはユーザーに影響を与えない問題を指摘する可能性があり、特定のユーザー操作から生じる問題を見逃すこともあります。ウェブサイトの応答性を真に理解するには、実際のユーザーモニタリング（RUM）を用いて現場でINPを測定することが不可欠です。

上記の指標を最適化することで、SEOランキング全体を大幅に向上させることもできます。 Lighthouse (NAIST) と ウェブページテスト ウェブサイト開発中またはリアルタイムでパフォーマンスを測定するため。

Lighthouseは、メインスレッドの処理を最小限に抑える、JavaScriptの実行時間を短縮する、Largest Contentful Paint（LCP）スコアが高い場合の対処など、ウェブページのさまざまな側面を評価します。これらの分析結果は、ウェブサイトのパフォーマンスを効果的に最適化するための貴重な指針となり、第一歩となります。さらに詳しい推奨事項については、記事の後半で説明します。

画像を最適化

画像は今日のウェブサイトにおいて非常に重要な役割を果たしており、ユーザーエンゲージメントと視覚的な魅力を大幅に向上させています。しかし、画像はウェブページのサイズと帯域幅消費量に最も大きな影響を与える要因にもなり得、特にモバイルデバイスや低速なインターネット接続環境では、読み込み速度に悪影響を及ぼす可能性があります。

タグは長い間存在しており、その機能を活用することは、コア Web バイタルを最適化するために重要です。たとえば、

すべての画像タグに寸法が指定されていることを確認してください。

寸法を無視するとレイアウトがずれ、ブラウザが読み込み前にスペースを確保できなくなる可能性があります。これは大きな問題の最大の原因となる可能性があります。 累積レイアウトシフト

<img src="flower.jpg" alt="A beautiful flower." width="400" height="400">

デバイスタイプに合わせて最適化

設定するタグを使用して、遅延読み込みするか、デバイスのディスプレイに最適なレスポンシブ画像バージョンを提供します。レスポンシブ画像メソッドを使用すると、 srcsetデバイスのディスプレイに基づいてブラウザが最適な画像サイズを選択できるようにします。これにより、 最大のContentful Paint（LCP）

<img src="image.jpg"  srcset="image-480w.jpg 480w, image-800w.jpg 800w, image-1200w.jpg 1200w" sizes="(max-width: 600px) 480px, 800px" alt="Responsive image">

使用するタグ

また、画面サイズや解像度などの表示特性に基づいて適切な画像を選択するためのタグ。 

<picture>
    <source srcset="keyboard.avif" type="image/avif">
    <source srcset="keyboard.webp" type="image/webp">
    <source srcset="keyboard.jpg" type="image/jpeg">
    <img src="keyboard.jpg" alt="Omg a keyboard">
</picture>

画像を圧縮する

画像圧縮（例： シャープ, ImageOptim、または 画像CDN or イメージミン）は最新の画像フォーマットを使用して適用する必要があります。

/* Images can be consistently optimized by integrating Imagemin into the workflow, ensuring they load quickly and efficiently */
import imagemin from 'imagemin';
import imageminJpegtran from 'imagemin-jpegtran';
import imageminPngquant from 'imagemin-pngquant';

const files = await imagemin(['images/*.{jpg,png}'], {
	destination: 'build/images',
	plugins: [
		imageminJpegtran(),
		imageminPngquant({
			quality: [0.6, 0.8]
		})
	]
});

console.log(files);
//=> [{data: <Uint8Array 89 50 4e ...>, destinationPath: 'build/images/foo.jpg'}, ...]

WebPやAVIFなどの最新の画像フォーマットは、ブラウザがデバイスの画面に最適な画像サイズを選択するのに役立ち、圧縮率と品質が向上します。JPEGからAVIFへの変換により、ファイルサイズを驚異的な84%削減できます。Googleの スクワッシュ このツールは、画像をこれらの最新フォーマットに変換するための手軽な方法を提供します。

ソースコードを最適化

最適化された画像を使用しても、コードが大きかったり非効率的だったりすると、コンテンツが画面に表示される速度が遅くなり、インタラクティブ性が損なわれる可能性があります。ソースコードの観点からWebパフォーマンスを最適化する方法をいくつかご紹介します。

DOMの深さを避ける

DOMの深さとは、HTML構造内のネストされた要素の数を指します。ネストが深すぎるとレンダリング時間が長くなり、応答性にも悪影響を及ぼします。

/* Example too nested DOM Structure */
<div class="container">
 <div class="header-wrapper">
   <div class="header">
     <h1>Welcome to Our Website</h1>
     <div class="header-content">
       <p>Your go-to platform for everything tech!</p>
     </div>
   </div>
 </div>
 <div class="main-content">
   <div class="content-wrapper">
     <section>
       <article>
         <div class="post">
           <h2>Latest Post</h2>
           <div class="post-content">
             <p>Stay updated with the latest in tech.</p>
           </div>
         </div>
       </article>
     </section>
   </div>
 </div>
</div>

 <!-- Optimized, shallow DOM structure -->
<div class="container">
<header>
   <h1>Welcome to Our Website</h1>
   <p>Your go-to platform for everything tech!</p>
 </header>
 <main>
   <section>
     <article>
       <h2>Latest Post</h2>
       <p>Stay updated with the latest in tech.</p>
     </article>
   </section>
 </main></div>

content-visibility CSSプロパティを使用する

Setting コンテンツの可視性 要素がビューポートに入るまでレンダリングを自動的に遅延させます。これにより、特に非表示コンテンツやスクロールしないと見えないコンテンツが多いページの場合、初期読み込み時間を短縮できます。contain-intrinsic-size プロパティとコンテンツの可視性を組み合わせることで、推定高さを取得してレイアウトのずれを回避できます。この組み合わせにより、レンダリングを遅延させながらレイアウトの安定性を維持することで、パフォーマンスが最適化されます。

/* Applying content-visibility to a section */
.lazy-section {
  content-visibility: auto;
  contain-intrinsic-size: 1000px; /* Placeholder size to prevent layout shifts */
}

CSSの複雑さを制限する

深くネストされたセレクタや過剰なアニメーションを含む複雑なCSSルールは、レンダリング時間を増加させ、DOMの肥大化につながります。CSSセレクタの深さを制限し、複雑な擬似クラスの使用を減らしましょう。よりシンプルで直接的なセレクタを使用することで、CSSの効率を向上させることができます。

/* Complex and inefficient */
section div.article p span {
  color: #333;
}

/* Simplified, efficient */
.article-text {
  color: #333;
}

非同期操作を使用して最適化する

非同期操作など 非同期/待機, setTimeout, 約束 ウェブの速度と全体的なパフォーマンスを向上させます。タスクをメインの実行スレッドをブロックすることなく実行できるため、データの取得やリソースの読み込みなど、時間のかかる処理に特に効果的です。

ソースコードをバンドルする

バンドルは、JavaScript や CSS などの複数のファイルを 1 つのファイルに結合して、ブラウザのリクエストを削減します。これにより、レイテンシが最小限に抑えられ、読み込み時間が短縮され、全体的なパフォーマンスが向上します。バンドルは、利用可能なオープンソースライブラリのいずれかを使用して実行できます (Webpack, Browserify）そして、ビルドプロセスに統合できます。 

遅延読み込みを実装する

遅延読み込みは、画像や動画など、すぐに必要とされない要素の読み込みを遅らせます。この方法により、ページの初期読み込み時間が短縮されます。最新のブラウザは遅延読み込みをサポートしています。 遅延読み込み HTMLのloading属性を介して。 

<img src="image.jpg" loading="lazy" alt="Description">
<iframe loading="lazy" src="video-player.html" title="..."></iframe>

ロードイベントは、事前にロードされたすべてのコンテンツの読み込みが完了したときに発生します。
ただし、古いブラウザをサポートしたい場合は、 交差オブザーバーAPItype=”module” を含むスクリプト タグは自動的に JavaScriptモジュール そして、デフォルトでは延期されます。

コンソールエラーを追跡し、リダイレクト呼び出しを削除します。

JavaScriptのエラーは機能に支障をきたし、ユーザーの不満につながる可能性があります。これらのエラーを解決することで、スムーズな操作性、読み込み時間の短縮、そしてブラウザ間の互換性の向上を実現できます。

しかし、ウェブページ上のリアルタイムのエラーはより複雑になる可能性があります。包括的なエラー追跡ソリューションを導入することは有益です。次のようなツール アービット ウェブアプリケーション内で発生するエラーに関するリアルタイムの洞察を提供し、スタックトレースやユーザーコンテキストを含む詳細なレポートを提供します。 

一時的なリダイレクト（302）は意図せず発生することがあり、余分なHTTPリクエストサイクルが必要となるため、パフォーマンスが低下する可能性があります。サーバー設定を確認し最適化することは、サーバー上で不要な302リダイレクトを減らすために不可欠です。

コードを圧縮・最小化しましょう。

ファイルサイズが大きいとダウンロードやレンダリングが遅延し、ユーザーエクスペリエンスやエンゲージメントに悪影響を及ぼします。JavaScriptとCSSのバンドルサイズを最小限に抑えるためのツールをいくつかご紹介します。

より簡潔に

より簡潔に JavaScriptファイルを圧縮し、不要な文字を削除したり、変数名を短縮したりします。圧縮後、大きなスクリプトでも最大80%のサイズ削減が可能になり、ダウンロードとレンダリングが大幅に高速化されます。
webpack と統合するには、 terser-webpack-plugin そして、以下のコードをwebpack.config.jsの一部として含めてください。

const TerserPlugin = require("terser-webpack-plugin");

module.exports = {
  optimization: {
    minimize: true,
    minimizer: [new TerserPlugin()],
  },
};

CSSナノ

CSSナノ 空白文字、コメント、不要なプロパティを削除することで、CSSファイルのサイズを最小限に抑えます。大規模なコードベースの場合、CSSファイルのサイズを20%以上削減できます。

BrotliとGzip

ブロトリ (NAIST) と Gzip HTML、CSS、JavaScriptなどのテキストベースのアセットのサイズを縮小する圧縮アルゴリズムです。バンドルに圧縮を追加するには、 圧縮ウェブパックプラグイン そして、webpack.config.js に以下を追加してください。Brotli は、Gzip と比較して、JavaScript ファイルのサイズを 14%、HTML ファイルのサイズを 21%、CSS ファイルのサイズを 17% 小さくします。

module.exports = {
  plugins: [
    new CompressionPlugin({
      algorithm: "gzip",
    }),
  ],
};

複数のデバイス向けに最適化

レスポンシブデザインに注力し、複数のプラットフォームでテストを行い、モバイルユーザビリティに関するベストプラクティスを採用することで、速度とユーザー満足度の両方を向上させることができます。

CSSメディアクエリ

CSSメディアクエリは、レスポンシブデザインを実現するための手段です。以下の例では、クエリによってウェブサイトが最大768ピクセルの画面サイズに対応するように設定されています。

@media (max-width: 768px) {
    .container {
        display: flex;
        flex-direction: column;
    }
}

しかし、すべての部品を変更するには時間がかかる場合があります。 

Tailwind CSSまたはBootstrap

使用することもできます テールウィンドCSS or ブートストラップ ウェブサイト向けにレスポンシブなコンポーネントを設計するには、Tailwind が最適です。Tailwind は実用性を重視したアプローチを採用しており、sm:、md:、lg:、xl: などのレスポンシブクラスを使用して、さまざまな画面サイズに合わせてスタイルを調整できます。クラス名を通してレスポンシブデザインを直接制御できます。Bootstrap はグリッドシステムとさまざまな画面サイズに対応するクラス名を提供しています。これにより、カスタム CSS メディアクエリを回避できます。 

テスト

ウェブサイトが複数のデバイスで適切に表示されるかどうかを判断する最良の方法は、テストを実施することです。ユーザー層を把握している場合は、スマートフォンでのインタラクティビティを確認したり、組み込みの開発者ツールを使用して応答性をテストしたりできます。クロスブラウザ監視をサポートするリアルユーザーモニタリング（RUM）ツールや合成モニタリングツールを使用することで、さまざまなユーザー環境において一貫したパフォーマンスと速度を確保できます。この方法により、ユーザーエクスペリエンスを詳細に把握できるため、速度に関する問題の検出と解決が容易になります。

キャッシング

コンテンツは、変更頻度に応じて、ブラウザ、CDN、またはAPIゲートウェイにキャッシュすることができます。 

• ブラウザーのキャッシュ これは、特にネットワーク要求と遅延を削減したい場合に、静的性の高いアセットやユーザー固有のアセットに最適です。
• CDN キャッシュ パーソナライズを必要としない、頻繁にアクセスされる共有コンテンツに最適です。グローバルアクセスを最適化し、サーバー負荷を軽減します。
• バックエンドのキャッシュ バックエンドで頻繁にアクセスされる動的なデータには、この方法が推奨されます。

HTTPキャッシュ

ブラウザ、またはHTTPキャッシュは、リクエストに関連付けられたレスポンスを保存し、その保存されたレスポンスを今後のリクエストに使用します。これには2種類あります。 

• プライベートキャッシング – ユーザー固有のキャッシュ
• 共有キャッシュ – ユーザー間で共有できるキャッシュ

HTTP キャッシングを実装するには、Cache-Control ヘッダーを使用してリクエストとレスポンスの両方のキャッシングを設定します。Cache-Control ヘッダーには、ブラウザまたは共有キャッシュ (プロキシ、CDN) でのキャッシングに関する値を持つディレクティブ (指示) が含まれています。ディレクティブは、カンマで区切られた 1 つ以上含めることができます。

Cache-Control: directive1, directive2, ...

具体的な例を挙げますと、以下の通りです。

Max-age = N ディレクティブは、応答がN秒まで新鮮であることを示します。

Cache-Control: max-age=604800

MDNドキュメント一覧 リクエストとレスポンスをキャッシュするために使用できるすべてのディレクティブ。 

バックエンドのキャッシュ

動的コンテンツは、その性質上、リアルタイムでの生成が必要となり、リソースを大量に消費する可能性があります。バックエンドキャッシュを利用することで、このオーバーヘッドを回避し、コンテンツをより効率的に配信できます。ユーザーが同じコンテンツ（または類似のコンテンツ）をリクエストした場合、サーバーは処理全体を繰り返すことなく、キャッシュから迅速にコンテンツを取得できます。 

キャッシュを使用しない場合、動的コンテンツの処理が遅くなる理由をよりよく理解するために、次の一連のイベントを考えてみましょう。 

1. ユーザーリクエスト: ユーザーが動的なコンテンツを必要とする方法でウェブサイトを操作する場合（例：商品の閲覧、検索結果のフィルタリング、パーソナライズされたダッシュボードの表示）。
   
2. サーバー側処理:
   
   1. サーバーはリクエストを受信し、適切なコンテンツを生成するためのコードを実行する必要があります。
   2. これには多くの場合、データベースからのデータ取得、計算の実行、ビジネスロジックの適用、および出力のフォーマットが含まれます。
      
3. 時間コスト： これらの処理には時間がかかり、特に以下のような場合には、ユーザーにとって目立った遅延につながる可能性があります。
   
   1. データベースクエリは複雑です。
   2. データセットは大規模である。
   3. サーバー側のロジックは計算負荷が高い。
      
4. ユーザーエクスペリエンスへの影響： 読み込み速度が遅いと、ユーザーエクスペリエンスの低下、離脱率の上昇、コンバージョン率の低下につながる可能性があります。

ただし、頻繁に変更されるデータはキャッシュに適さない場合があることに注意することが重要です。むしろ、計算コストの高い結果や頻繁にアクセスされるデータはキャッシュに最適です。 

バックエンドのキャッシュには様々な種類があります。

• データベースのキャッシュ データベース自体を最適化し、頻繁にアクセスされるデータをメモリに保存することで、より高速なデータ取得を実現する。
• サーバー側キャッシュ RedisやMemcachedなどのツールを使用して、アプリケーションとデータベースの間に専用のキャッシュ層を作成します。生成されたコンテンツをキャッシュに保存することで、サーバーは毎回コードを実行する手順を省略し、事前に生成されたコンテンツを直接配信できます。
• API キャッシュ APIからの応答を自動化することで、外部へのリクエストを繰り返す必要性が軽減されます。また、外部APIが一時的に利用できない場合でも、データを迅速に提供できます。

CDN キャッシュ

コンテンツ配信ネットワーク（CDN）は、基本的にウェブサイトの画像、スタイルシート、スクリプトなどのアセットのコピーを保存するための巨大な分散型キャッシュであり、ウェブコンテンツをより高速に配信するために使用されます。CDNは、動的コンテンツやパーソナライズされたコンテンツよりも、トラフィックが多くグローバルなリーチを持つ静的で不変のアセットのキャッシュに最適です。 

ユーザーがウェブサイトからコンテンツをリクエストすると、CDNがそのリクエストを傍受し、ユーザーに最も近いエッジサーバーからコンテンツを配信します。PoP（Points of Presence）を介してユーザーとサーバー間の距離を最小限に抑えることで、ユーザーとの距離が縮まり、レイテンシが低減され、パフォーマンスと信頼性が向上します。

CDNは特に次のような場合に役立ちます 

• 画像の最適化
• レイジーローディング 
• 静的アセットの提供 
• レイテンシーを最小限に抑えることで、LCPやINPといったパフォーマンス指標を向上させる。
• 事前レンダリング 
• 動的コンテンツのキャッシュ

ネットワークリクエストを制限および最適化する

HTTPリクエスト数を減らすことで、読み込み時間が短縮され、全体的な応答性が向上します。非同期読み込みにより、スクリプトを独立して読み込むことができ、ウェブページの他の部分のレンダリングを妨げることがありません。非同期スクリプトのダウンロード中に、ブラウザは他のドキュメント要素の処理を継続できるため、ページの読み込み速度が向上します。

HTTP/1.x 

HTTP/1.x を複数の TCP 接続で使用する場合、ヘッドオブラインブロッキングにより、各リソースが単一の接続上で順次取得されるため、リクエストを並列化する必要が生じることがよくあります。これは、特に多数の小さなアセットを扱う場合に、リソースの取得効率を低下させます。 

HTTP/1.xでは、連結やドメインシャーディングといった技術によってネットワークリクエストが制限されます。しかし、複数のドメインを使用するデメリットは、DNSルックアップの回数が増えることで、初期ページ読み込み速度に悪影響を与える可能性があることです。

ドメインシャーディングは、リクエストを複数のサブドメインに分散させることで、ホスト名ごとのブラウザの接続制限を回避し、ページの読み込み時間を短縮します。

HTTP/2.x

HTTP/2.xへのアップグレードには、重要なメリットがあります。多重化機能により、単一の接続上で複数のリクエストを同時に実行できるため、ヘッドオブラインブロッキングの問題を解決できます。さらに、HTTP/2はバイナリフレーミングを採用することで、解析性能の向上とオーバーヘッドの低減を実現しています。WebサーバーでHTTP/2を有効にすることで、既存のコードを変更することなく、Webサイトやアプリのダウンロード速度を向上させることができます。

APIを最適化する

APIの最適化は、応答時間の短縮、トラフィックの効率的な管理、リソース消費量の削減に不可欠です。特に、パフォーマンスの低下がスケーラビリティに影響を与えたり、P99レイテンシ（99パーセンタイルレイテンシ）が高くなったり、ユーザーエクスペリエンスやコンバージョン率に影響を及ぼしたりする場合には、最適化が重要となります。また、処理速度の遅いサードパーティサービスに依存するAPI、タイムアウトが発生するAPI、長時間実行されるリクエストを処理するAPIにとっても、最適化は不可欠です。

P99レイテンシ、つまり最も応答速度の遅い上位1%のユーザーの応答時間に注目することは、あらゆるユーザーインタラクションにおいて信頼性の高い応答性の高いサービスを提供するために不可欠です。この指標を最適化することで、APIのパフォーマンスがより安定し、低速な接続環境やトラフィック量の多い状況でも使いやすさが向上します。

ウェブページ/リソースの事前レンダリング

プリレンダリング（一般的に静的サイト生成（SSG）と呼ばれる）とは、ビルドプロセス中にページを静的HTMLファイルとしてレンダリングする手法です。サーバーサイドレンダリング（SSR）と同等のパフォーマンスを維持しながら、最初のバイトまでの時間を短縮します。SSGは、eコマースカタログやイベントウェブサイトなど、頻繁に変更されないコンテンツに最適です。

静的サイトジェネレーターは、テンプレート、コンポーネント、コンテンツソースをウェブサイトに必要なHTML、CSS、JavaScriptファイルに変換するアプリケーションです。いくつかのフレームワークもSSGをサポートしており、以下はその例です。

• Next.js：動的コンテンツと静的コンテンツの両方に対してサーバーサイドレンダリングとSSGを提供するReactフレームワーク。
• Gatsby：豊富なプラグインを備えた静的サイト構築に特化した、Reactベースのフレームワーク。
• Nuxt.js：SSGとサーバーサイドレンダリングをサポートするVue.jsフレームワーク。
• Hugo：Go言語で書かれたHugoは、高速な静的サイト生成ツールであり、特に大規模サイトに効果的です。
• Jekyll：RubyベースのSSG（シングルサインオン）であり、シンプルさと容易なデプロイのためにGitHub Pagesと組み合わせて使用​​されることが多い。
• Vite：主に高速ビルドツールであり、Vikeなどのプラグインを介してSSG機能も備えている。

これらのフレームワークは、開発者がさまざまなカスタマイズオプションを備えた、効率的で読み込み速度の速い静的ウェブサイトを作成するのに役立ちます。 

自動スケーリング、レート制限、および仮想待合室の使用を有効にする

アプリケーションが主に静的なコンテンツで構成されている場合、CDNにデプロイするのが一般的に最良の選択肢です。CDNは、HTML、CSS、JavaScriptなどの静的ファイルをユーザーに近い場所から配信することで、速度と信頼性を向上させ、効率的に配信します。

ただし、アプリでサーバー側とのやり取りが必要な場合は、バックエンドサービスの前にロードバランサーを配置するのが理想的です。ロードバランサーは、ラウンドロビン方式でリクエストを処理するように設定するか、必要に応じて、ユーザーまたはアプリケーションロジックに基づいてリクエストをルーティングするカスタムアルゴリズムを設定します。オートスケーリングは、トラフィックの変動に応じてサーバー容量を自動的に調整することで、さらに役立ちますが、オートスケーリングには限界があることに注意してください。

リソース利用を最適化し、ダウンタイムを防止するためには、特にトラフィックが集中する時間帯において、レート制限が不可欠です。レート制限は、セッショントークン、IPアドレス、地域、またはカスタムビジネスロジックに基づいて適用できます。トラフィック量の多いキャンペーンを実施する際には、レート制限を優先的に実施すべきです。

自動スケーリングとレート制限は、不要なダウンタイムを回避するのに役立ちますが、ピーク時のユーザーエクスペリエンスを向上させるには、仮想待合室を実装することも検討してください。これは、訪問者を一時的に待機させ、容量に余裕ができ次第サイトにアクセスできるようにするものです。待合室があれば、サイトが過負荷になることなく、ユーザーが秩序正しくサイトにアクセスできるようになります。この機能は、Redis を使用するか、クラウドベースのソリューションを使用してキューを管理することで実装できます。

インターネットスタックを監視する

その インターネットスタック インターネットスタックは、ユーザーがリモートからウェブサイトにアクセスできるようにする一連のサービスです。これには、インターネットサービスプロバイダ（ISP）が提供するDNS、CDN、ネットワークサービスに加え、ウェブサイトが必要なデータを含むウェブページを表示するためにアクセスするサードパーティAPIが含まれます。インターネットスタックのすべてのコンポーネントから測定データを収集することで、エンドツーエンドのトランザクションパスとエンドユーザーエクスペリエンスを低下させる要因を包括的に把握できます。 

ネットワークパフォーマンスは、エンドユーザーのパフォーマンスに大きく影響します。tracerouteコマンドを使用すると、ネットワークセグメントごとのウェブページの全体的な遅延を分析し、トランザクションパス上のどのホップが最も時間がかかっているかを特定できます。

ネットワーク上のデバイス間を移動する各「ホップ」を示すトレースルート

しかし、従来のtracerouteには、ロードバランサーやファイアウォールを介したネットワークパフォーマンスを測定できないなどの制限があります。Webサイトがロードバランサーを使用している場合やファイアウォールが前面にある場合、測定に盲点が生じます。このような制限を克服するには、LogicMonitorの セッション中 tracerouteを使用すると、ユーザーとWebサーバー間のネットワーク構成をより広範囲に把握できます。

統合プラットフォームを使用してインターネットスタック全体にわたって測定を収集すると、サードパーティのインターネットサービスプロバイダに依存するボトルネックを特定して解決するために必要な可視性が得られます。測定は、実際のユーザー トランザクションを使用して、次の測定を収集することによって取得できます。 エンドユーザー向けブラウザ （別名：リアルユーザーモニタリング、またはRUM）または トランザクションのエミュレーション （別名：合成監視）世界中の何千もの地点から、あらゆる地域（例：東京対ロンドン）およびサービスプロバイダーのネットワーク（例：Verizon対Comcast）からの到達可能性とパフォーマンスを確保します。

インターネットスタックのパフォーマンス問題の例 

以下に、エンドユーザーとウェブサイト間のトランザクション経路を構成するインターネットスタックの一部であるサードパーティサービスで発生する可能性のある問題の例をいくつか示します。このリストは網羅的なものではありませんが、検出可能な潜在的な問題の例を示し、これらの測定値を収集することでどのように対処できるかを説明します。 

DNSの問題

ドメイン解決の遅延が大きい場合やDNSタイムアウトが発生する場合は、設定ミスまたは一時的なDNS障害を示している可能性があります。これに対処するには、以下を参照してください。

• プライマリDNSサービスが故障した場合に、シームレスに代替できるセカンダリDNSサービスを用意しておいてください。
• 使用 DNS監視 プロバイダーがリアルタイムの測定値を収集し、ユーザーが長期間影響を受ける前にDNSの問題を通知します。

CDNの問題

If CDN 監視 キャッシュ取得の遅延が大きい、キャッシュヒット率が低い、またはキャッシュが非効率的であることを示している場合は、次のことができます。

• CDNの地理的なカバー範囲を拡大し、頻繁にアクセスされるコンテンツをユーザーに近い場所にキャッシュするように設定してください。 
• コンテンツの種類とユーザーの行動に基づいて有効期限を微調整し、キャッシュの鮮度とヒット率のバランスを取りましょう。

セッションタイムアウトエラー

実際のユーザーモニタリングでセッションのタイムアウトが確認された場合、セッションの切断やサーバーインフラストラクチャの不足が原因である可能性があります。

需要の高い地域でサーバー数を増やすことで、トラフィックをより均等に分散させ、負荷を軽減し、タイムアウトの発生確率を下げることができます。タイムアウトエラーが頻繁に発生する場合は、サーバーが過負荷状態になっている可能性があります。ロードバランサーはリクエストを複数のサーバーに分散させることで、単一のサーバーに過負荷がかかるのを防ぎます。

ネットワークのボトルネック

If ネットワーク監視 エンドユーザーとサーバー間の遅延が過剰に発生している場合は、インターネットサービスプロバイダ（ISP）を見直してください。定期的にtracerouteを実行して、特定のISPネットワーク内の遅延を確認し、別のサービスプロバイダへの切り替えを検討してください。一部の低価格ISPは、バックボーンのコストを削減するためにネットワークトラフィックを過剰に割り当てているため、ピーク時にレイテンシが高くなることがあります。 

最後の考え

まず、コアウェブバイタルを測定して、ウェブサイトのパフォーマンスを向上させるために対処すべき問題点を把握します。問題点に対処した後、インターネットパフォーマンスモニタリング（IPM）を使用して、ユーザーとウェブサイト間のトランザクションパスに関わるすべての要素を含めたエンドユーザーエクスペリエンスを測定します。

よくあるご質問