2025.09.29

パフォーマンスボトルネックの探し方

こんにちは。AITPのキムです。

現在参加しているプロジェクトではエンドユーザー向けのサービスを提供しており、少しでも多くのユーザー導入をするため、SEO向上につながるためのパフォーマンスチューニングを少しずつ実施しています。
対策と一言に言っても、「フロントとバックのどちらに」「どのような対策を入れるのか」と言った判断基準はたくさんあります。本記事では、その絞り込みの手助けになるツールや手段として、以下の3つを紹介します。

【１】PageSpeed Insights
【２】DevToolのネットワークタブのWaterfall
【３】DevToolのパフォーマンスタブ

【1】PageSpeed Insights / フロントエンドの総合的な計測に

まずはGoogleが提供する診断ツール、「PageSpeed Insight」です。

URLを入力し「分析」をクリックするだけでPCとスマホでの閲覧時のさまざまな要素の計測結果を出してくれます。（※今回は情報量が多い「www.yahoo.co.jp」を計測してみました。）

結果画面の「実際のユーザーの環境で評価する」の項目では、実際にChromeのユーザーがこのサイトを過去28日で閲覧した上での評価を確認できます。

「パフォーマンスの問題を診断する」 では、スコアを向上するための情報をカテゴリごとにピックアップしてくれます。

アドバイスの種類は、たとえば
「特定の画像をwebpにすることを推奨」
「このページからリクエストしている画像やJSファイルなどのデータのキャッシュ」
などかなり多岐にわたりますが、その手順は該当部分の「詳細」を見ると、具体的にどのようなことをすればいいかの情報を調べることができます。
基本的にはこれらの項目はGoogleの推奨基準なので、まずはこのツールで測定し、そのアドバイスに従うことが有効です。

※「Largest Contentful Paint (LCP)」やFirst Contentful Paint (FCP)など、聞きなれない単語が出てきますが、これもそれぞれのリンクをクリックすると、どのような判定要素なのかをGoogleの公式ドキュメントを確認することができます。

💡開発中の調整方法

なお、これらの対策を取るには、実際にサーバー上のサイトに反映させる必要があります。そのため、

修正点を改修し、サービスを更新する
↓
スコアの反映を確認する

という一連の手間をかけてもあまり変化がなかった・・・という結果に陥ることもあります。
さらにこのツールは実際のWeb上のURLを計測するため、ローカルのPCや、一般公開できない開発環境では計測ができません。

そこでChromeの拡張機能「ライトハウス」を使えば、開発中のローカル環境（http://localhost…ようなURL）でもDevToolでパフォーマンススコアの計測が可能です。
Chromeに拡張機能を追加すると、DevToolのElementsやNetworkと並んで「LightHouse」が表示されるので、そこからDesktop、Mobileのどちらかを選んで計測ボタンをクリックします。

PageSpeedInsightと同様の測定を行ってくれます。

この機能を使い、変更による効果が実際にどの程度あるのかを開発環境で試し、
「効果が特に大きなものを調べた上で改修、リリースをする」ようにすると、効率の良いスコア向上ができると思います。

【２】ネットワークタブのWaterfall / フロントとバックの切り分けに

次はChromeのDevToolのネットワークタブを紹介します。
このタブで、様々なリソースのリクエストから取得までにかかった時間を確認することができます。

💡情報の確認方法

ChromeのDevtoolのネットワークタブを開き、画像の赤括弧の部分を右クリックします。

Waterfallの項目にチェックを入れます。

ネットワークタブの右端にWaterfallが追加されるので、ページを再読み込みすると、
ページがサーバーにリクエストしているデータの順番などの流れを確認できます。

このページの場合、まずページそのものである「www.yahoo.co.jp」にリクエストがあり、その次に、このページから読み込んでいるファイル「bundle_20250916-053622.css」、続いてJSファイル・・・と順番にリクエストしていることがわかります。

また、Waterfallの青ゲージの部分をクリックすると、以下のような情報が確認できます。

ここでWaiting for server response（画面右中央側の緑のバー）に注目すると、文字通りリクエストを行ってからサーバーからのレスポンスが返却されるまでの時間が確認できます。
この時間が長いのであれば、「このページはバックエンドの処理に時間がかかっている」といえます。

たとえば今開発しているサービスでは、一部のリアルタイム性を求めるページを除いてCloudFrontでページをキャッシュしています。
左側の画像（キャッシュしているページ）に比べ、右側のキャッシュをしていないページはサーバーからのレスポンスに約1秒ほどさらに時間がかかっています。

サービス内のいくつかのページをチェックし、
server responseが長いページについてはフロントエンドの対策をするよりも、バックエンド側での対策を検討する・・・などの方針検討ができます。

【3】パフォーマンスタブ / 総合的な処理の流れを俯瞰する

最後に、同じDevToolのパフォーマンスタブです。
パフォーマンスタブは「データ読み込みのタイムライン」や、「ボトルネック情報の提示」など、ここまでのツールで紹介した情報を、より総合的に俯瞰して確認できるツールです。

今回は（yahooサイトだと情報量がかなり多くなるため）検証サイトとして以下のような、JQueryやCSSをCDNから取得し、大きな画像、中くらいの画像だけを読み込むシンプルなテストサイトを作成しました。

<!doctype html>
<html lang="ja">
<head>
  <meta charset="utf-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1" />
  <title>シンプルデモ</title>
  <script src="https://code.jquery.com/jquery-3.7.1.min.js" integrity="sha256-/JqT3SQfawRcv/BIHPThkBvs0OEvtFFmqPF/lYI/Cxo=" crossorigin="anonymous"></script>
  <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/normalize/8.0.1/normalize.min.css" integrity="sha512-NhSC1YmyruXifcj/KFRWoC561YpHpc5Jtzgvbuzx5VozKpWvQ+4nXhPdFgmx8xqexRcpAglTj9sIBWINXa8x5w==" crossorigin="anonymous" referrerpolicy="no-referrer" />
  <style>
    body { font-family: sans-serif; margin: 0; padding: 20px; }
    h1 { margin-bottom: 20px; }
    img { max-width: 100%; height: auto; display: block; margin: 20px auto; }
    p { max-width: 700px; }
  </style>
</head>
<body>
  <h1>確認サイト</h1>
  <p>大きな画像</p>
  <img src="https://picsum.photos/id/1015/4000/2600.jpg" alt="大きなデモ画像"/>

  <p>中くらいの画像</p>
  <img src="https://picsum.photos/id/1015/800/520.jpg" alt="中くらいの画像">
</body>
</html>

💡ツールの表示方法

計測するサイトを開いた状態で、ChromeのDevtoolのパフォーマンスタブを開き、下記画像の【１】をクリックすると再読み込みが始まります。しばらく待つと、計測した結果が2~5に表示されます。

【２】左サイドバー/Insight では、サイトの読み込みをしていく中での改善点となりうる場所をピックアップしてくれます。
【３】タイムラインでは、実際のサイトの描写までの流れを、ページの画像とともに表示しています。表示範囲を伸縮することもできます。
【４】タイムラインで選択した範囲のデータの読み込み情報などが表示されます。
【５】4で選択中の情報のさらなる詳細情報を確認できます。

💡使い方例

【２】の中の「LCP request discovery」をクリックすると、最初のファーストビューの画像は優先的に読み込むべし（fetchpriority =”high”）という指摘があり、【４】のエリアで該当箇所がハイライトされます。
その画像読み込みはページの読み込みの流れの中でどのあたりのタイミングなのか？も確認できます。

次に「Render blocking requests」をクリックすると、JQueryやCSSファイルを読み込んでいる時間がどのくらいなのか、またその間画面描写を一定時間ブロックしているということがサイトの読み込み状況（タイムライン）と見比べながら確認できます。

このサイトの場合はシンプルな作りですが、通常のwebサイトは多くのリソースを読み込み、多くの要素があるので 「どの読み込みや処理が、どのタイミングでボトルネックになっているか」
を俯瞰的に調査しやすくなると思います。

この機能はパッと見の情報量も多く初見ではわかりづらく感じますが、細かく読み込むとボトルネックを洗い出す助けになると感じました。

最後に

色々なパフォーマンスチューニング関連の情報を調べていく中で「推測するな、計測せよ」という言葉を知りました。
チューニング関連の作業に限りませんが、「やったほうがbetterなこと」でも、その効果も曖昧な状態で全て対応していると、「かけた工数に対してのリターンが期待ほどみられない」・・・といったことが起きてしまいがちです。推測するだけではなく、今回紹介したような計測ツールを使いどの程度効果があるのかを判断していけるよう意識したいと改めて感じました。

以上です。気になったツールがあればぜひ活用していただけますと幸いです！

参考情報

https://developer.chrome.com/docs/devtools/performance/reference?hl=ja
https://amzn.asia/d/91jBCKr

All Blog