[ チュートリアル ]
Webサイトはなぜ遅いのか。本当の原因と直し方
サイトを実際に遅くしているものを、よくある順に整理し、当て推量に頼らず一つずつ直していく実践ガイド。
目次
ほとんどの人が陥る落とし穴があります。自分のノートパソコンでサイトを開くと一瞬で表示され、「問題なし」と判断してしまうのです。その一方で、訪問者のかなりの割合は、3年前のスマートフォンで電波2本という環境で、真っ白な画面を4秒間見つめ、あきらめて離脱しています。
あなたにとって速く感じるサイトが、実際に訪れる人の半数にとっては苦痛なほど遅いということは起こり得ます。違いを生むのは、何を計測するか、そして誰の体験で計測するかです。この記事では、遅いWebサイトの本当の原因をよくある順に取り上げ、それぞれに具体的な対処法を示します。そして最後に、当て推量をやめ、実際の訪問者が体感している速度を見る方法を紹介します。
結論から：よくある原因をランキングで
遅いWebサイトの大半は、同じ数種類の原因で遅くなっています。あなたのサイトの原因も、たいてい下のリストの中に見つかるはずです。最も効果が大きいのは、ほぼ例外なく、サイズが大きすぎる画像と、追加したことを忘れている外部スクリプトです。まずそこから始めて、上から順に取り組んでください。自分のマシンで一度だけ速度テストをしても誤った判断につながるので、最後にして最も重要なステップは、実際の訪問者がそれぞれのスマートフォンやネットワークで体感している速度を計測することです。
- 重い画像とメディア。 圧縮されていない写真や巨大なファイルは、読み込みが遅くなる原因の第一位です。圧縮し、リサイズし、最新のフォーマットを使いましょう。
- 外部スクリプトの入れすぎ。 チャットウィジェット、広告ピクセル、A/Bテストツール、重い解析ツールは、それぞれが負担を加えます。積み重なるとあっという間です。
- レンダリングを妨げるCSSとJavaScript。 ブラウザは、何かを描画する前に読み込まなければならないリソースで止まってしまいます。最初に不要なものは後回しにしましょう。
- 遅いホスティングと、キャッシュやCDNの不在。 安価な共有ホスティングやキャッシュの欠如は、すべての訪問者が遅いオリジンサーバーを待たされることを意味します。
- Core Web Vitalsの基準未達。 「速い」サイトでも、コンテンツが飛び跳ねたりボタンが反応しなかったりすると、ぎこちなく感じられます。これらはGoogleとユーザーの双方が気づく指標です。
- 間違ったものを計測している。 1台の速いマシンで出したラボのスコアは、実際の訪問者が得る速度ではありません。実ユーザーを監視して、本当にあなたの損失になっている遅い経路を見つけましょう。
重い画像とメディア
サイトが遅いなら、まず最初に見るべきは画像です。スマートフォンやデザインツールからそのまま書き出した1枚のヒーロー写真が、3〜4メガバイトになることもあります。そんな画像を1ページに数枚並べれば、どれだけコードがきれいでも、モバイルでは這うように遅いサイトのできあがりです。
対処法は3つの要素からなります。1つ目は、画像を実際に表示されるサイズにリサイズすること。横600ピクセルで表示される写真に、横4000ピクセルは要りません。2つ目は圧縮すること。ツールやビルドパイプラインを使えば、ほとんどの画像は見た目の劣化なしに半分以下にまで縮められます。3つ目は、WebPやAVIFといった最新のフォーマットを使うこと。これらは同じ画質でも、古いJPEGやPNGより桁違いに小さくなります。
さらに、手軽に効く施策が2つあります。ファーストビューより下にある画像を遅延読み込み（lazy-load）にして、訪問者がその近くまでスクロールしたときだけブラウザが取得するようにすること。そして、画像には必ず明示的に幅と高さを指定して、読み込み中にページが飛び跳ねないようにすることです。最後の点は、聞こえる以上に重要で、Core Web Vitalsの話のところで改めて触れます。
動画も同じ話で、しかも事態はもっと深刻です。どうしても使うなら、ストリーミング向けに作られたプラットフォームでホストし、誰かが操作したときだけプレーヤーを読み込むようにしましょう。
外部スクリプトの入れすぎ（隠れた負担）
これは、はっきり見えているのに見落とされがちな原因です。1年もすれば、サイトには知らないうちにチャットウィジェット、ヒートマップツール、A/Bテストのスニペット、広告ピクセル2つ、Cookieバナー、フォントローダー、そして解析タグが3つほど積み重なっています。追加したときは、どれも害がなさそうに思えたはずです。ところがまとめて見ると、それらはページの中で最も重く、最も遅い存在であることが少なくありません。あなたが管理していないサーバーに問い合わせに行くからです。
外部スクリプトが負担になる理由は2つあります。ダウンロードして解析するバイトが増えること、そして、それ自体が遅いかもしれない別ドメインへのネットワーク往復が増えることです。たった1つの鈍いマーケティングタグが、ページの残りがインタラクティブになるのを妨げることもあります。そうした外部サーバーを速くすることはたいていできないので、唯一の手段は、そのスクリプトを削除するか後回しにすることです。
今あるものを棚卸ししましょう。ブラウザのネットワークパネルを開き、ページを読み込んで、ドメイン順に並べ替えます。忘れていたサービスや、数か月前に使うのをやめたサービスへのリクエストが、ほぼ間違いなく見つかります。積極的に必要としていないものはすべて削除しましょう。残りは非同期で読み込むか、ページがインタラクティブになった後に読み込み、より軽い代替手段がないか検討します。最も重い犯人は、たいてい予想とは違うものです。
良い習慣として、新しいスクリプトはすべて「無料の追加機能」ではなく「コスト」として扱いましょう。スニペットをサイトに貼り付ける前に、その重さに見合う価値があるかを問うのです。新しいプロジェクトを立ち上げるところなら、Webサイト公開チェックリストにさっと目を通しておくと、後で引きはがすことになる5つのツールを最初から抱え込まずに済みます。
レンダリングを妨げるCSSとJavaScript
画像が軽くスクリプトが少なくても、ブラウザの処理する順番のせいでページが遅く感じられることがあります。ページの<head>内にあるスタイルシートやスクリプトに到達すると、ブラウザは多くの場合いったん止まり、そのファイルをダウンロードして処理し終えるまで、画面に何も描画できません。この停止こそが、訪問者が真っ白なページとして体感するものです。
目指すべきは、ブラウザにできるだけ早く意味のあるものを表示させることです。最初に見える部分（ファーストビューのコンテンツ）を描画するのに必要なわずかなCSSはインライン化し、残りは後から読み込みます。JavaScriptには defer や async 属性を使い、スクリプトが最初の描画を妨げないようにし、大きなバンドルは分割して、そのページに実際に必要なコードだけをブラウザがダウンロードするようにします。
最新のフレームワークやサイトビルダーはこの多くを肩代わりしてくれますが、すべてではありません。フォントはよくある原因です。テキストの表示を妨げるカスタムWebフォントは、訪問者に何もない画面を見つめさせるか、テキストが差し替わるときにちらつきを起こします。フォントの読み込み中は、すぐに代替テキストを表示するようブラウザに指示しましょう。小さな変更ですが、確かな違いを生みます。
ホスティング、キャッシュ、そしてCDN
ページ自体は問題なくても、その裏にあるサーバーが原因のこともあります。格安の共有ホスティングでは、あなたのサイトは何百もの他サイトと同じマシンに同居していて、そのうちの1つが混み合うと全員が遅くなります。ほかの処理が始まる前の段階で、ページの最初の1バイトが届くまでに1秒以上かかることもあります。最初の1バイトまでの時間（TTFB）が常に遅いなら、どれだけ画像を圧縮しても救われません。
ここで最も効果の大きい対処法はキャッシュです。キャッシュは、できあがったページのコピーを保存しておき、サーバーがリクエストのたびにゼロから作り直さずに済むようにします。コンテンツサイトやブログなら、ページ全体のキャッシュによって、鈍かったオリジンがほぼ瞬時に応答するようになります。ほとんどのプラットフォームやコンテンツ管理システムには、キャッシュ機能が組み込まれているか、プラグインを入れればすぐ使えます。
コンテンツ配信ネットワーク（CDN）は、もう1つの大きな手段です。CDNは、静的ファイル（画像、CSS、JavaScript）のコピーを世界各地のサーバーに保持します。そのため、シドニーの訪問者は、フランクフルトにあるあなたのオリジンから海を越えてバイトが届くのを待つのではなく、近くの都市から読み込めます。世界中に読者がいるなら、これだけで読み込み時間を目に見えて短縮できます。ホスティングにCDNが含まれていなくても、無料で始められるものはいくらでもあります。
そして、これらが問題になる以前に、そもそもサーバーが稼働していなければなりません。ダウンしているサイトは無限に遅く、しかも障害は最悪のタイミングで起こり、誰にも気づかれないまま何時間も続きがちです。自分のホスティングが実際に何を保証しているか考えたことがないなら、Webサイトの稼働率についての解説が役に立ちます。小さな障害の積み重ねが、多くの所有者が思っている以上に、ひそかに大きな損失時間につながる理由を説明しています。オリジンが沈黙した瞬間、あるいは応答が遅くなり始めた瞬間を知ることは、ここで挙げた他のすべての土台となります。
やさしい言葉で説くCore Web Vitals
Googleは、Core Web Vitalsと呼ばれる一連の指標でサイトの速度を測っており、これらは検索やChromeのユーザー体験レポートに表れます。理解しておく価値があるのは、これらが単なるダウンロード時間ではなく、実際の訪問者が体感するものに近く対応しているからです。指標は3つあり、その基準値はweb.devで公開されています。
Largest Contentful Paint（LCP）は、最も大きな見える要素（たいていはヒーロー画像や見出し）の読み込みが完了するまでの時間を測ります。目標は2.5秒未満です。Interaction to Next Paint（INP）は、誰かがタップやクリックをしたときにページがどれだけ速く反応するかを測り、目標は200ミリ秒未満です。Cumulative Layout Shift（CLS）は、読み込み中にページがどれだけ飛び跳ねるかを測り、0.1未満が望ましい値です。正式な定義はCore Web Vitalsのページで読めます。
平たく言えば、LCPは「ページがどれだけ速く現れたか」、INPは「触れたときどれだけ速く反応するか」、CLSは「レイアウトが動かずにいたか、それともタップしようとした瞬間にボタンが動いたか」です。このCLSは、寸法指定のない画像や遅れて読み込まれる広告に直結します。画像に幅と高さを設定することがこれほど重要なのは、そのためです。ここに出てきた用語が初耳なら、用語集によく使われるものをまとめて定義してあります。
3つのうち2つは、単なるダウンロード速度ではなく、反応の良さと安定性に関するものです。ここはまさに、ノートパソコンでLighthouseを1回走らせただけでは見えにくい部分であり、それが次の最も重要なセクションへとつながります。
ラボのデータは嘘をつく：実ユーザーを監視しよう
ここに、速度改善の取り組みの大半を台無しにする落とし穴があります。Lighthouseのようなツールを走らせて輝かしいスコアが出たとしても、それはラボのテストです。1つのページ、1台の速いマシン、1本の安定した接続で、1回だけ実行したもの。あなたの実際の訪問者は、それとはまったく違います。中位機種のスマートフォンで、ホテルのWi-Fiで、電車の中で、バックグラウンドにタブを十数個開いた状態です。彼らが得る速度は、あなたのノートパソコンが報告する速度とは大きく異なることがあり、あなたには問題なく読み込めるスクリプトが、ほかの全員の足を引っ張っている張本人かもしれません。
だからこそ、たとえどれだけ緑色でも、1つのスコアだけでは足りないのです。人々が実際に体感している速度を知る唯一の方法は、彼らの側から、彼らの端末とネットワークで、継続的に計測することです。実ユーザーが得ている速度を見られるようになると、ほかの誰も目にしない数字のために最適化することをやめ、訪問者を失わせている遅い経路を直せるようになります。あなたのマシンでは速いのにスマートフォンでは止まるページ、光回線では問題ないのにモバイル回線ではすべてを妨げるスクリプト、といったものです。
始めるのに最もシンプルなのは、最も基本的な問いです。サイトは今この瞬間ちゃんと応答しているのか、そしてどれだけ速いのか。耳に入ってこない遅延は直しようがなく、障害や遅い応答は何時間も気づかれないままになりがちです。あなたのオリジンを定期的にチェックする稼働率モニタリングを少し入れておけば、最初の1バイトまでの時間がじわじわ延びたときや、サーバーが沈黙したときに知らせてくれます。これは、この記事のほかのあらゆる対処法の土台となるものです。
実ユーザーを見るようになると、仕事のやり方が変わります。完璧なラボのスコアを追いかける代わりに、速度が落ちるページや端末を見張り、それらを直し、その修正が実際の人々に対して効いたことを確認するのです。何を、なぜ追うべきかという、より広い枠組みについては、Web解析のベストプラクティスのガイドで、速度と行動のデータを意味のある成果に結びつける方法を解説しています。
よくある質問
なぜモバイルでは遅いのに、デスクトップでは遅くないのですか？
スマートフォンは、デスクトップに比べてプロセッサが遅く、ネットワークもはるかに不安定です。そのため、重い画像、大きなJavaScriptバンドル、外部スクリプトはモバイルでずっと深刻に響きます。速いWi-Fiにつながったデスクトップは、それらをすべて覆い隠してしまいます。対処法は、実際の中位機種のスマートフォンでテストすること（あるいはブラウザを「4G、中位端末」に絞ること）。さらに良いのは、自分のマシンを信用するのではなく、実際のモバイル訪問者が得ている速度を見ることです。
良いページ読み込み時間とはどのくらいですか？
よく使われる目安として、主要なコンテンツはおよそ2〜3秒以内に現れるべきで、できればもっと速いほうが望ましいとされます。GoogleのCore Web Vitalsは、より正確な目標を示しています。Largest Contentful Paintが2.5秒未満なら良好とされます。ただし、どんな単一の数字よりも重要なのは、自分のノートパソコンでの速い結果だけでなく、実際の端末とネットワークをまたいだ一貫性です。
解析スクリプトはサイトを遅くしますか？
重い解析スクリプトは遅くしますが、軽いものはそうではありません。コストはひとえに、そのスクリプトがどれだけダウンロードし、ページ上でどれだけの処理をするかにかかっています。人気のツールの中には大きなバンドルを送り込み、多くのネットワークリクエストを行うものもあります。一方、軽くしっかり作られた解析ツールが加える重さはごくわずかです。ブラウザのネットワークパネルで自分のものを確認し、重いようなら、より軽い代替手段を探しましょう。
Core Web Vitalsとは何ですか？
Core Web Vitalsは、Googleが実環境でのページ体験を測るために使う3つの指標です。Largest Contentful Paint（読み込み、2.5秒未満で良好）、Interaction to Next Paint（反応の良さ、200ミリ秒未満で良好）、Cumulative Layout Shift（視覚的な安定性、0.1未満で良好）です。正式な定義はCore Web Vitalsのページにあります。
