【ITニュース解説】Why Your Website Is Slow Even When Your Server Is Fast

ウェブサイトの表示速度は、サーバーの速さだけで決まるという考えは誤解であることが多い。たとえサーバーが最初のHTMLデータを迅速に返したとしても、ユーザーが実際に体感するページの速さや応答性は、サーバーからの応答以降、ブラウザがこなす多くの追加作業によって大きく左右されるためだ。ブラウザは、受け取ったHTMLを解析し、CSSを処理し、JavaScriptを実行し、画像をデコードし、最終的なページを構築して描画し、さらにユーザーの操作にリアルタイムで応答する必要がある。このように、ウェブサイトのパフォーマンスは、サーバーだけでなく、ネットワーク、ブラウザ、JavaScript、CSS、画像、外部から読み込むサードパーティスクリプト、そして実際の画面描画に至るまで、全てを考慮する「フルパイプライン」の問題として捉えるべきだ。Googleが提唱するCore Web Vitals（Largest Contentful Paint、Interaction to Next Paint、Cumulative Layout Shiftなど）も、この広範な視点からユーザー体験を評価する重要な指標となっている。

現代のウェブサイト速度を低下させる最大の原因の一つがJavaScriptである。単にファイルサイズが大きいだけでなく、ブラウザはJavaScriptのダウンロードに加えて、解析、コンパイル、実行、さらには画面の要素（DOM）を操作したり、ユーザー操作に応答する処理（イベントハンドラー）を実行したり、スタイルを再計算したりと、多くの処理を行う。特に重いJavaScript処理が実行されると、ブラウザのメインスレッドが長時間占有され、ユーザーのクリックやスクロールといった操作への反応が遅れる。これはInteraction to Next Paint（INP）という指標に悪影響を与える。この問題に対処するには、不要なJavaScript（例えば、使われていないライブラリ、重いUIコンポーネント、不要なアニメーションなど）を特定して削減することが重要だ。また、HTMLの解析を妨げないようJavaScriptの読み込み方を工夫したり、コードを細かく分割して必要な時にだけ読み込む「遅延読み込み」などの技術も効果的だ。目標は、JavaScriptのファイルサイズを小さくするだけでなく、ブラウザが実行する作業量を減らすことにある。

画像もウェブサイトのパフォーマンスを遅くする一般的な要因だ。開発者が高解像度の画像をそのままアップロードすると、ブラウザはその大きなファイルをダウンロードしなければならず、特にモバイルネットワークでは深刻な問題となる。対策としては、WebPやAVIFのようなモダンな画像フォーマットを使ってファイルサイズを小さくする。また、ブラウザで表示されるサイズよりもはるかに大きな画像をダウンロードしないよう、適切な寸法で画像を提供することが重要だ。レスポンシブイメージ機能（srcset, sizes属性）を使えば、デバイスに応じて最適なサイズの画像を自動で選択できる。さらに、画面の初期表示領域（スクロールしないと見えない部分）にある画像は、loading="lazy"属性を付けて遅延読み込みを適用することで、最初のページ読み込み時の負担を軽減できる。ただし、ページで最も重要な画像（Largest Contentful Paint要素）は、遅延させずに最優先で読み込むべきである。

CSSはJavaScriptに比べ軽量に見えるが、大量のスタイルシートや非効率な構造もページの描画を遅らせる原因となる。複数のCSSファイルがページの初期描画に必要な場合、ブラウザはそれらすべてを処理し終えるまで最終的なページを表示できないため、ユーザーは待つことになる。開発者は、使われていないCSS、大規模なCSSフレームワーク、過剰なセレクタ、重複するスタイル、不要なアニメーション、そしてページの描画をブロックするスタイルシートを見直す必要がある。初期表示に必要な「クリティカルなスタイル」を優先的に読み込み、それ以外のスタイルは後回しにするなど、工夫することでユーザーが最初に目にする画面を速く表示できる。

ウェブサイトの速度低下の原因として見落とされがちなのが、外部サービスから読み込むサードパーティスクリプトだ。アナリティクス、広告、チャットウィジェット、ソーシャルメディアのピクセルなど、これらを追加すると、自社のコードが最適化されていても、ブラウザは多くの追加リクエストと処理を強いられる。外部サーバーへの接続確立にも時間がかかるため、これも遅延の原因となる。対策としては、これらのスクリプトを定期的に見直し、その必要性を問い直すことが重要だ。もしすぐに必要でないなら、ページの初期読み込み後に遅延させて読み込んだり、非同期で読み込んだり、あるいは完全に削除したり、複数の機能を一つのツールにまとめたりすることを検討すべきである。チーム全体で、それぞれのサードパーティスクリプトがサイトのパフォーマンスに与える影響を認識し、導入を慎重に判断する必要がある。

個々のAPIリクエストが高速でも、その連携方法によってサイトが遅く感じることがある。例えば、APIが100ミリ秒で応答しても、フロントエンドが15個ものAPIリクエストを順次（一つ終わったら次、というように）実行する場合、前のリクエストが終わらないと次のリクエストが始まらないため、合計で非常に長い待ち時間が生まれてしまう。互いに依存しないリクエストはPromise.allなどの機能を使って並行して実行させるべきだ。また、重複するAPIリクエスト、並列で実行できるはずの順次リクエスト、必要以上のデータを取得する「過剰なフェッチ」、巨大なJSON応答、不要なポーリング、そしてキャッシュの利用漏れがないかを確認することも重要だ。問うべきは、「APIそのものがどれだけ速いか」だけでなく、「ユーザーがページを快適に使えるようになるまでに、ブラウザがAPIからどれだけのデータや処理を必要とするか」である。

最も速いリクエストは、サーバーに一度も到達しないリクエストである。この原則に基づき、キャッシングはウェブサイトのパフォーマンス改善に不可欠な要素となる。キャッシングによって、不要なネットワーク通信やサーバーの処理負荷を大幅に削減できるからだ。キャッシュは、ユーザーのブラウザ内部、CDN（コンテンツ配信ネットワーク）、アプリケーション自身、そしてデータベースなど、様々なレベルで適用できる。CSS、JavaScript、ウェブフォント、画像といった静的ファイルは、一度ダウンロードされれば内容が頻繁に変わらないため、長期間キャッシュするのに非常に適している。ファイル名にコンテンツのハッシュ値を含めることで、ファイルが更新された場合にのみ新しいバージョンがダウンロードされ、古いキャッシュが使われ続ける問題を避けられる。

個々のデータベースクエリが高速でも、それが複数回、あるいは連続して実行されることで、アプリケーション全体の速度が遅くなることがある。例えば、ユーザー情報、権限、製品情報など、様々なデータを取得するために複数のクエリが必要な場合、それぞれのクエリが速くても合計の処理時間は増大する。この問題を解決するには、アプリケーションの動作を詳細に分析する「プロファイリング」が有効だ。N+1クエリ問題（一つのデータ取得にN個の追加クエリが発生する）、不要なテーブル結合、インデックス（検索を高速化する仕組み）の欠落、同じクエリの繰り返し実行、大量のデータベース応答、データ変換（シリアライズ）の非効率性、同期的な操作などがないかを確認する。重要なのは、個別のクエリだけでなく、アプリケーションがデータ取得から応答を生成するまでの一連の流れ全体を最適化することだ。

ウェブパフォーマンスを理解する上で、Largest Contentful Paint（LCP）とTime to First Byte（TTFB）の違いを把握することは非常に重要だ。TTFBは、ユーザーがページにアクセスしてから最初のデータがサーバーから届くまでの時間を指し、主にサーバーの応答速度を示す。しかし、TTFBがたとえ400ミリ秒と非常に速くても、ユーザーが実際にページの主要なコンテンツ（LCP）を目にするまでの時間は、それよりずっと長くなることがある。例えば、サーバーからのHTMLが届いた後、JavaScriptの実行、APIリクエスト、メイン画像のダウンロード・デコードを経て、初めて主要なコンテンツが画面に描画されるという一連の流れがあるためだ。この例からもわかるように、サーバーが高速であることと、ユーザーがページを速く体験できることは必ずしも一致しない。パフォーマンス最適化は、単なるサーバー速度の指標ではなく、ユーザーがコンテンツを視覚的に認識し、操作できるまでの体験全体に焦点を当てるべきだ。

開発者は通常、高性能なデスクトップ、安定したWi-Fi、既にキャッシュされた環境でウェブサイトをテストし、「サイトは速い」と判断しがちだ。しかし、実際のユーザーは古いスマートフォン、遅いモバイルネットワーク、初めて訪れるコールドキャッシュ、異なる地理的位置など、様々な環境で利用している。そのため、開発者のテスト環境での速度と実際のユーザーが体感する速度には大きな隔たりがあることが多い。この差を埋めるため、実際のユーザーから得られるデータ（フィールドデータ）を確認することが重要であり、ChromeのUser Experience Reportなどがその情報を提供する。LighthouseやChrome DevToolsのようなツールは開発環境での詳細な分析に役立つが、両方のデータを見て初めて全体像が掴める。 ウェブサイトのパフォーマンスを改善する際には、まずChrome DevToolsやPageSpeed Insightsなどのツールを使って現状を「測定」する。次に、TTFBやLCPが高い、JavaScriptが重い、画像が大きい、APIリクエストが多すぎる、サードパーティスクリプトが影響しているといった具体的な「ボトルネックを特定」する。そして、最も影響の大きいボトルネックから優先的に「修正」する。例えば、巨大な画像ファイルが問題なら、細かいCSSの調整よりも画像の最適化を先に行う。修正後は必ず「再度測定」し、改善が期待通りに達成されたかを確認する。この「測定 → 診断 → 最適化 → 再測定 → 比較」という反復的なプロセスが、効果的なパフォーマンス改善には不可欠である。

ウェブサイトのパフォーマンスは、フロントエンドとバックエンドのどちらか一方だけの問題ではなく、システム全体として捉えるべき課題だ。サーバーが速くても、その後のブラウザ側の処理、つまりJavaScriptの実行、CSSの描画、画像の読み込み、API応答の処理、サードパーティスクリプトの実行、そして画面更新といった一連の作業が多ければ、ユーザー体験は遅くなる。現代のパフォーマンス最適化は、「ブラウザにさせる作業を減らし、送信するデータ量を減らし、リクエスト数を少なくし、重要なコンテンツをできるだけ早く表示し、そして実際のユーザー体験を測定する」という考え方に基づいている。GoogleのCore Web Vitals（LCP 2.5秒以下、INP 200ミリ秒以下、CLS 0.1以下）は、良好なユーザー体験の具体的な目標値だ。これらの指標の改善は、検索エンジンのランキングだけでなく、何よりもユーザーにとって快適なウェブ体験を提供するために非常に重要である。 だから、「サーバーは速いのに、なぜウェブサイトはまだ遅いのか？」という疑問が出たら、安易にサーバーだけを見るのではなく、ブラウザの開発者ツールを開き、ネットワークの状況、メインスレッドの活動、LCP要素の状態、JavaScriptや画像の最適化状況、API呼び出しのパターン、そして実際のユーザーの利用データを総合的に分析することが、真のパフォーマンス改善への道となる。ウェブサイトの速度は、サーバーがどれだけ素早く応答するかだけでなく、ユーザーがどれだけ速くページを認識し、理解し、スムーズに操作できるかによって決定されるのだ。