ページウェイト増加が問題視される背景
SEOにおける「ファイルサイズ」というテーマが、ここにきて改めて注目を集めています。きっかけのひとつが、Google検索チームのMartin Splitt氏とGary Illyes氏が公式ポッドキャスト「Search Off the Record」で交わした、ページウェイト（ページの総容量）の増加に関する議論です。両氏はGooglebotがクロール時にどのようにファイルを扱っているのか、そしてWeb全体でページが年々重くなっている現状について、開発者・SEO担当者が見落としがちなポイントを率直に語っています（出典：Google Search Central）。
議論の中で印象的なのは、「Googlebotには各ファイルに対するサイズ制限はあるが、それを下回っていればすべて問題ない、というわけではない」という指摘です。SEO担当者の間では、Googleが公表しているクロール上限（HTMLなら検索用2MB、リソースなら15MBなど）が一人歩きしがちで、「制限内に収まっていればOK」という誤解が広がっています。しかし両氏が強調したのは、クロール可否とユーザー体験は別軸であり、ページ全体としての重さがSEOにもUXにも影響を及ぼし続けているという事実でした。
背景には、Web全体のページウェイトが10年単位で大きく増加しているという構造的な変化があります。高解像度の画像、動画、サードパーティスクリプト、トラッキングタグ、フレームワーク由来のJavaScriptなどが積み重なり、モバイル端末で開く1ページの平均容量は2015年と比較して数倍規模に膨らみました。こうしたなかで、ページの読み込み速度やコアウェブバイタルの悪化が検索順位に跳ね返るケースは少なくありません。
本記事では、このSearch Off the Recordでの議論を出発点に、「SEO ファイルサイズ」というテーマを2つの軸で整理していきます。1つはGooglebotがファイル単位で適用しているクロール上限の正しい理解、もう1つはユーザー体験を左右するページ全体の合計サイズの最適化です。両者を切り分けて捉えることが、検索性能とUXの双方を守るうえでの出発点になります。
10年でモバイルページ容量は約2.7倍に — Web Almanacのデータ
SEOにおけるファイルサイズの議論を語るうえで欠かせないのが、Web Almanacが毎年公開しているWebの統計データです。HTTP Archiveのクロール結果をベースにまとめられたこのレポートによれば、モバイルサイトのトップページの平均転送量は2015年時点で約845KB程度だったのに対し、2025年7月時点では約2.3MBにまで膨らんでいます。およそ10年で2.7倍という増加幅は、SEO担当者がファイルサイズ問題を「過去の話」として片付けられない理由を端的に示しています。（出典：Web Almanac by HTTP Archive）
増加の主な要因は、高解像度の画像・動画、サードパーティ製のタグやチャットツール、リッチなJavaScriptフレームワーク、Webフォントなど多岐にわたります。とりわけ画像とJavaScriptがページ容量に占める割合は依然として大きく、見た目を整える施策やマーケティングタグの追加を重ねるたびに、ページは静かに肥大化していきます。
| 時点 | モバイルホームページの平均サイズ | 2015年比 |
|---|---|---|
| 2015年 | 約845KB | — |
| 2025年7月 | 約2.3MB | 約2.7倍 |
モバイル回線の高速化やデバイス性能の向上にともない、開発側の「これくらいなら問題ない」という感覚が緩みやすくなっているのも事実です。しかしSEOの観点で「ファイルサイズ」を捉え直すと、回線速度の改善ペース以上にページが重くなれば、結局は表示速度・コアウェブバイタル・直帰率といった指標にしわ寄せが及びます。ページの読み込み速度がSEOに与える影響を踏まえると、ページウェイトの増加トレンドは無視できない経営課題と言えます。
さらに注意したいのは、この2.3MBはあくまで「平均値」だという点です。リッチなLPや動画を多用するECサイト、CMSのテンプレートに重いプラグインを積み増しているコーポレートサイトなどでは、5MB〜10MBクラスのページも珍しくありません。自社サイトの数値が平均より上か下かを把握すること自体が、SEO実務の第一歩になります。
Googlebotのファイルサイズ制限を正しく理解する
SEOでファイルサイズを議論するうえで、まず押さえておきたいのがGooglebotが扱える上限値です。Googleは公式ドキュメントで、クローラーがダウンロードできるファイルサイズには種類ごとに異なる上限があると明記しています。「2MBを超えるとインデックスされない」と単純化されがちですが、実際にはHTMLなどの検索用クロールと、画像・CSS・JSなどの一般リソース、そしてPDFで取り扱いが異なります。
ファイル種別ごとに異なる3つの上限
Googlebotには大きく分けて、検索用にHTMLをクロールするGooglebotと、画像・動画・スタイルシート・スクリプトなどを取得するための一般リソース用クローラー、そしてPDFを処理する仕組みがあります。それぞれの上限は次の通りです。HTMLは最初の数MBまでしか解析対象とならず、それ以降に書かれたコンテンツやリンクは無視される可能性があります（出典：Google検索セントラル「Googlebot」）。
| ファイル種別 | Googlebotのサイズ上限 | 主な対象 |
|---|---|---|
| 検索用HTML | 最初の約2MBまで処理 | ページ本体のHTMLソース |
| 一般リソース | 1ファイルあたり約15MBまで | 画像・動画・CSS・JavaScript など |
| 最大約65MBまで | PDFドキュメント |
HTMLの2MB上限が意味するもの
もっとも誤解されやすいのが、検索用HTMLの「最初の数MBまで」という仕様です。Googleは2022年に、Googlebotが処理するHTMLのサイズ上限を従来の数百KBから引き上げ、現在は最初の数MB（おおむね2MB前後）までを対象としているとアナウンスしています（出典：Google Search Central Blog）。これを超える部分に重要な本文や内部リンクが配置されていると、検索エンジンに認識されないリスクが残ります。SEO ファイルサイズの議論では、HTMLが肥大化していないか、特に上部にコンテンツが集約されているかが最初のチェックポイントになります。
画像・CSS・JS・PDFはまた別の上限
一方、画像やCSS、JavaScriptといった一般リソースは1ファイルあたり数十MB規模まで取得対象になります（公式ヘルプでは大型ファイルも扱えるとされています）。PDFについてはさらに大きく、おおよそ100MB近い文書もインデックス対象として処理されるケースがあります。とはいえ「上限内なら何でもOK」というわけではなく、巨大なリソースはクロールバジェットを圧迫し、ページ全体の読み込み速度を悪化させます。Googleのクローラーの仕組みとクロールバジェットと合わせて、ファイル単位の上限と総量の両方を意識することが、技術的SEOの基本になります。
誤解されがちな「ファイル単位」という考え方
SEOでファイルサイズを語るとき、最も多い誤解が「ページ全体の合計が制限値を超えたらクロールされない」という思い込みです。しかし、Googlebotの上限はページ単位ではなく、あくまで個々のファイル単位で適用されます。HTMLは取得した先頭から一定量までを解析対象とし、CSSやJavaScript、画像といったリソースもそれぞれ独立して取得・評価されます。（出典：Google検索セントラル「Googlebot」）
つまり、1ページの総ダウンロード量が10MBや20MBに達していても、構成する各ファイルがそれぞれの上限内に収まっていれば、Googlebotはそのページを問題なくクロールできます。逆に言えば、HTML単体が肥大化して上限を超えた場合は、超過分のコンテンツや末尾にあるリンクがインデックス処理に渡らない可能性があるということです。SEOにおけるファイルサイズの議論は、この「単位」の認識を間違えると的外れな対策につながります。
1ページは「複数ファイルの集合体」
現代のWebページは、HTML本体に加えて複数のCSS・JavaScript・画像・フォント・動画などが組み合わさって表示されます。Googlebotはそれぞれを別々のリクエストで取得し、ファイル種別ごとの制限を個別に当てはめます。下図のように、各ファイルにそれぞれの上限が適用されるイメージを持つと整理しやすくなります。
特に注意すべきは「HTML本体の肥大化」
ファイル単位で考えたときに最もリスクが高いのが、HTMLそのものの肥大化です。インラインで大量のJavaScriptやBase64エンコード画像を埋め込んでいるサイト、サーバーサイドレンダリングでデータをHTML内に直接書き出しているサイトでは、HTMLが数MB規模に膨らむケースがあります。15MBの上限に達することは稀でも、上限を超えた部分はGooglebotが処理しないため、ページ末尾に置かれた重要なコンテンツや内部リンクがインデックスに反映されない事態になり得ます。
一方、画像やJavaScriptなどの外部リソースは、仮に1ファイルが極端に大きくても、それ単体の取得が止まるだけで、ページ全体のインデックスが拒否されるわけではありません。とはいえ巨大な画像やJSファイルは表示速度やページの読み込み速度に直結するため、SEOの観点では別の問題として最適化が必要になります。
「合計サイズ」はGooglebotではなくユーザーのための指標
整理すると、Googlebotのクロール可否を左右するのは「各ファイルが上限内に収まっているか」、ユーザー体験やコアウェブバイタルに影響するのは「ページ全体の合計サイズ」です。両者は別軸の指標であり、対策の出発点も異なります。SEOにおけるファイルサイズを正しく扱うには、この2つを混同せず、それぞれに対して適切な打ち手を設計することが重要です。次章では、合計サイズがユーザー体験に与える影響と、実務でのチェック観点を掘り下げます。
クロール制限はクリアでもUXは別問題：合計サイズ最適化の重要性
前章で見たとおり、Googlebotのファイルサイズ制限は「ファイル単位」で適用されます。つまり、HTMLが2MBを下回り、個々の画像やCSS・JSが15MBを超えていなければ、クロールやインデックスの観点では大きな問題は起きにくいということになります。しかし、SEOにおけるファイルサイズの議論は、ここで終わってはいけません。Martin SplittとGary Illyesがポッドキャストでわざわざページウェイトの増加に言及したのは、クロール可否ではなく「ユーザー体験」という別の評価軸が存在するからです。
合計サイズはコアウェブバイタルに直結する
1ページに10〜15MB分のリソースが詰め込まれていれば、たとえ1ファイル単位ではGooglebotの上限に収まっていても、モバイル回線では読み込みに数秒〜十数秒かかる可能性があります。特にLCP（Largest Contentful Paint）はメインビジュアルや大きなテキストブロックの描画完了時間を測る指標であり、画像や Web フォント、レンダリングブロッキングなCSS・JSの肥大化が直接スコアを悪化させます。コアウェブバイタルは検索順位を決定づける単独要因ではないものの、ページエクスペリエンスの一部としてランキングシステムが参照することをGoogleは明言しています（出典：Google Search Central）。
また、表示速度の遅さは直帰率や離脱率にも跳ね返ります。クロールできても、ユーザーがコンテンツを見る前に離脱してしまえば、SEOの成果としては実質ゼロです。ファイル単位の制限という「最低ライン」をクリアした上で、合計サイズと描画パフォーマンスをどう抑えるかが、検索性能を最大化する次のステージになります。詳しい考え方はページエクスペリエンス アップデートやページの読み込み速度改善の効果の解説も参考にしてください。
合計ページサイズを抑える実践チェックリスト
SEOの観点でファイルサイズを最適化するなら、個別ファイルの上限ではなく「ページ全体の重量」を継続的に削るアプローチが有効です。以下は、現場で効果が出やすい代表的な施策です。
- 画像の圧縮と次世代フォーマット化：JPEG/PNGをWebPやAVIFに切り替え、適切な解像度にリサイズする。多くの場合、ページ重量の半分以上は画像が占めます。
- 遅延読み込み（lazy-loading）の徹底：ファーストビュー外の画像・iframeに
loading="lazy"を付与し、初期描画に必要なバイト数を減らす。 - CSS/JSのミニファイと結合：空白やコメントを削除し、未使用CSSを除去。レンダリングをブロックするJSは
deferやasyncを活用する。 - サードパーティスクリプトの棚卸し：解析・広告・チャットなどのタグが積み重なって肥大化していないか確認し、使っていないものは削除する。
- HTTP圧縮（Gzip / Brotli）の有効化：テキスト系リソース（HTML/CSS/JS）の転送量を大幅に削減できる。
- Web フォントの最小化：使用するウェイトと文字セットを絞り、
font-display: swapでレンダリングを止めない。 - CDNとキャッシュ戦略の設計：静的リソースをエッジ配信し、再訪問時の体感速度を改善する。
これらは個別に見れば地味な改善ですが、積み重ねるとページ重量を数MB単位で削れることも珍しくありません。Googlebotのクロール上限と異なり、合計サイズには「ここまで下げれば安全」という明確なしきい値はありません。だからこそ、定期的に計測し、悪化していないかを監視する運用が重要になります。
自社サイトのファイルサイズと技術的SEOを点検する方法
ここまで述べてきたように、SEOにおけるファイルサイズはGooglebotのクロール上限とユーザー体験という2つの観点で捉える必要があります。とはいえ、自社サイトが実際にどの程度のページウェイトを抱えており、どのリソースが肥大化の原因になっているのかは、目視ではなかなか把握できません。そこで重要になるのが、技術的SEOの監査を定期的に行い、ファイルサイズや読み込み速度を継続的に点検する仕組みです。
まず最初に着手したいのは、Googleが公式に提供している計測ツールでの現状把握です。PagePeed InsightsはCore Web Vitalsの実測値とLab値をURL単位で取得でき、LCPやCLS、INPの状況とともに、ページ全体のリソースサイズや圧縮不足のCSS/JSなどの改善提案も提示してくれます（出典：PageSpeed Insights）。Search Consoleの「ウェブに関する主な指標」レポートでは、サイト全体のURL群がどの程度「良好」「改善が必要」「不良」に分類されているかを確認できます（出典：Search Console ヘルプ）。
SEO ファイルサイズ監査でチェックすべき項目
SEO観点でのファイルサイズ監査では、単にページ全体の重さを見るだけでなく、リソース種別ごとの状態とインデックスへの影響を併せて確認することが大切です。最低限、以下の項目は定期的に点検しておきましょう。
- ページ全体の合計転送量（モバイルで2MB以下を一つの目安に）と、Web Almanacの平均値との比較
- HTMLソースのサイズが検索用Googlebotの2MB上限に収まっているか（重要コンテンツが上限の後ろに置かれていないか）
- CSS/JavaScriptが圧縮（minify）され、gzip / Brotli で配信されているか
- 画像が次世代フォーマット（WebP / AVIF）で配信され、適切にリサイズされているか
- 外部リソース（広告タグ、計測タグ、埋め込みウィジェット）のHTTPステータスと総容量
- リダイレクトチェーンや4XX/5XXを返すリソースが残っていないか
- Core Web Vitals（LCP・CLS・INP）の実測値が「良好」域に収まっているか
- XMLサイトマップに含まれるURLが正しくインデックス対象として扱われているか
継続的なクロールで「悪化の兆し」を早期に検知する
ページウェイトはリリースのたびに少しずつ増えていく傾向があります。新しいタグマネージャーのコンテナ、追加された埋め込み動画、リサイズ忘れの画像など、一つひとつは小さな変更でも積み重なれば数百KB単位で膨らみ、いつの間にかコアウェブバイタルを悪化させてしまいます。ページの読み込み速度改善の効果でも触れたように、表示速度は検索順位とコンバージョンの両方に影響するため、リリース後にスポットで計測するのではなく、スケジュール化されたクロールで継続的に変化を追う体制が望ましいといえます。
SE Rankingのサイト検査ツールのような技術的SEO監査ツールを使えば、115以上の指標でサイト全体を自動クロールし、圧縮されていないCSS、4XX/5XXを返すJavaScript、リダイレクトチェーン、ページの読み込み速度、Core Web Vitalsなどを一括でチェックできます。検査結果は過去のスコアと比較できるため、ページウェイトが徐々に増えているのか、どのテンプレートが原因なのかも特定しやすくなります。Googleのクローラーの仕組みとクロールバジェットを意識しながら、まずは現状の健全性スコアを把握するところから始めてみてください。
よくある質問（FAQ）
- Q. GooglebotのファイルサイズはSEOにどのくらい影響しますか？
- A. Googlebotにはファイル種別ごとにクロール上限があり、これを超えた部分は読み込まれない可能性があります。ただしページ全体の合計サイズが直接ランキングに影響するわけではなく、表示速度やコアウェブバイタルを通じて間接的にSEOに影響します。そのため、クロール制限への対応とユーザー体験の最適化を分けて考えることが大切です。
- Q. GoogleがクロールできるHTMLファイルの上限は何MBですか？
- A. Googleの検索向けクローラーがHTMLファイルとして処理する上限は2MBとされています。一般的なGooglebotのリソース取得では15MB、PDFについては最大65MBまでが目安です。これらはあくまでファイル単位の上限で、ページに含まれる全リソースの合計値ではありません。
- Q. ページ全体の合計サイズが大きくてもSEO上は問題ないのですか？
- A. Googlebotのクロール制限はファイル単位なので、合計サイズだけで即ペナルティになることはありません。しかしページ全体が重くなれば表示速度が低下し、LCPやINPなどのコアウェブバイタル指標が悪化します。結果として検索順位やユーザー離脱率に悪影響を与えるため、合計サイズの最適化も欠かせません。
- Q. Web Almanacが示すモバイルページの容量はどのくらい増えていますか？
- A. Web Almanacの調査によると、モバイルページの中央値は2015年の約845KBから2025年7月時点で約2.3MBへと、10年で約2.7倍に増加しています。画像や動画、JavaScriptの肥大化が主な要因です。SEO担当者にとってファイルサイズの最適化は年々重要性を増しているといえます。
- Q. 自社サイトのファイルサイズはどうやって確認すればよいですか？
- A. Chrome DevToolsのNetworkタブやPageSpeed Insights、Lighthouse、Search Consoleなどを組み合わせて、ファイルごとのサイズや読み込み時間を確認できます。画像のWebP化、JavaScriptやCSSの圧縮、不要なリソースの削除といった具体的な改善箇所を洗い出せます。継続的な監査を仕組み化することがSEOの安定運用につながります。
- Q. PDFファイルもSEO上のファイルサイズ制限の対象になりますか？
- A. はい、PDFもGooglebotのクロール対象でファイルサイズの上限が適用され、目安は最大65MBとされています。これを超えるPDFは全文がインデックスされない可能性があるため、画像の圧縮や不要ページの削除でサイズを抑えることが重要です。検索流入を狙うPDFほどファイルサイズの最適化が効いてきます。
