ホームページ制作前に決める表示速度の予算｜画像・動画・外部タグの上限

ホームページの表示速度は、公開後にPageSpeed Insightsを見てから直すだけの問題ではありません。写真を何枚載せるか、動画を自動再生するか、何種類のフォントを使うか、計測や接客の外部ツールをいくつ入れるかという企画・デザイン上の判断で、ページの重さは早い段階から決まっていきます。

そこで制作前に用意したいのが「表示速度の予算」です。ここでいう予算は制作費ではなく、狙う表示体験を守るために、ページ全体や画像・動画・JavaScript・外部タグへ割り当てる上限を指します。最初から万能なKB数を決めるのではなく、対象端末と通信環境、主要ページ、確認指標、測定する時点、超過したときの戻し方までを一枚にまとめます。

この一枚があると、「画質を落とせばよい」「動画は全部だめ」といった乱暴な判断を避けられます。何を見せるための重さなのか、どの要素なら後から読み込めるのか、どこまでなら速さを損なわないかを、制作担当者・デザイナー・実装担当者の間で同じ条件から話せるようになります。

表示速度の予算は、見た目と速さの優先順位を公開前に決めるもの

パフォーマンスバジェット（性能予算）は、ページの容量やリクエスト数、表示時間などに上限を設け、制作途中の追加によって速度が悪化するのを防ぐ考え方です。ただし、容量だけを小さくすればよいわけではありません。軽いページでも、最初に見せたい画像の読み込みが遅ければ体感は悪くなります。反対に、ページ全体の容量がある程度大きくても、初期表示に不要な画像や動画を後から読み込めば、最初の操作を妨げずに済む場合があります。

実務では、予算を二つの層に分けると整理しやすくなります。一つは「何秒以内に主要内容を見せる」「操作したらどの程度で反応する」「読み込み中にレイアウトを動かさない」といった体験目標です。もう一つは、その目標を守るための画像容量、動画の読み込み方、フォント数、JavaScript転送量、外部サービス数などの資源上限です。

さらに、同じサイト内でもページの役割によって配分は変わります。ブランドの世界観を伝えるトップページはメイン画像へ多く割り当て、記事一覧は多数のサムネイルを軽くする。サービス詳細は事例写真を見せ、問い合わせページは入力操作を優先する、といった違いがあります。全ページを一つの上限へ押し込むより、代表的なページ種別ごとに予算を持つ方が、見た目と機能の理由を保ったまま管理できます。

表示速度の予算は、制作担当者だけが守る技術仕様でも、デザイナーへ一方的に課す制限でもありません。どの表現が成果に必要で、どの追加が予算を使うのかを見えるようにする合意資料です。追加を禁止するのではなく、追加するなら何を減らすか、読み込みを遅らせるか、目標を見直すかを判断できる状態にすることが目的です。

数値を決める前に、対象端末・回線・主要ページを固定する

表示速度は、測る端末や回線によって結果が変わります。社内の高速なパソコンと光回線だけで確認すると、一般的なスマートフォンや移動中の通信で起きる待ち時間を見逃しやすくなります。逆に、極端に遅い条件だけを前提にすると、本来必要な写真や機能まで削りすぎることがあります。先に「誰が、どの状況で見るサイトか」を決め、同じ条件で繰り返し測れるようにします。

最低限、予算表には次の条件を残します。

• 優先する端末区分と画面幅。スマートフォンを優先するのか、業務用パソコンの利用が中心なのか
• 使用する測定プロファイル。ブラウザー開発者ツールの端末名、通信制限、CPU制限などを再現できる形で記録する
• 初回訪問か再訪問か。キャッシュがない状態と、既存データが使える状態を分ける
• 対象地域や配信条件。国内中心か、海外閲覧や大容量データ通信の制約も考えるか
• 合否を見るページ。トップ、サービス詳細、記事、一覧、問い合わせなどから役割の異なるページを選ぶ

主要ページは、アクセス数が多いページだけでなく「重くなりやすいページ」と「失敗すると困るページ」を含めます。たとえば写真が多い事例ページ、動画を置く採用ページ、地図や予約ツールを埋め込む店舗ページは重くなりやすいページです。一方、広告の着地ページや問い合わせフォームは、読み込みや操作の遅れが次の行動を止めやすいページです。

制作前で実ページがまだない場合は、ページ種別ごとの部品表をつくります。「メイン画像一枚、事例写真六枚、地図、フォーム、アクセス解析、チャット」のように、載せる予定の要素を並べれば、重さの原因を実装前から見通せます。ワイヤーフレームやデザイン案に資源名を紐づけておくと、後で要素が増えたときも、どの判断で予算が変わったか追えます。

ここで大切なのは、測定条件を毎回変えないことです。デザイン案Aは高速な端末、案Bは低速な端末で測っても比較になりません。端末・回線・キャッシュ・ページ状態を固定し、その条件を予算表の先頭に書くことで、制作途中の数値を同じ物差しで比べられます。

Core Web Vitalsとページ重量は、同じ表で別々に管理する

表示速度の確認では、Core Web Vitalsとページの転送量を混同しないようにします。Core Web Vitalsは、主要内容が見えるまでの時間、操作への反応、表示の安定性をユーザー体験の側から確認する指標です。Googleが示す「良好」の目安は、LCPが2.5秒以内、INPが200ミリ秒以内、CLSが0.1以下で、実利用データではモバイルとパソコンを分け、75パーセンタイルで評価します。

一方、画像が何KBあるか、初期表示でJavaScriptを何KB送るか、外部ドメインへ何回通信するかは、制作中に直接管理しやすい資源指標です。Core Web Vitalsだけを目標にすると、完成するまで原因が見えにくくなります。資源上限だけを見ると、同じ容量でも読み込み順や処理時間によって体験が変わる点を見落とします。両方を同じ予算表に置き、役割を分けます。

制作中は実際の利用者データがまだないため、Lighthouseなどのラボ計測で同じ条件を再現します。公開後はPageSpeed InsightsやSearch Console等で実利用データを確認し、制作時の想定とずれていないかを見ます。ラボ計測は変更前後を比べやすく、実利用データは端末や通信環境のばらつきを含んだ結果を確認しやすいという違いがあります。

Lighthouseの総合スコアだけを契約上の合否にすると、測定条件やツールの更新で数値が揺れたときに判断しづらくなります。スコアは診断の入口にし、LCP・INPに関係するラボ指標、転送量、リクエスト数、JavaScriptの処理時間など、原因を追える値を併記します。数回測って中央値を見る、ブラウザー拡張を切る、同じ端末条件を使うといった測定ルールも合わせて残すと、偶然の一回で設計を戻さずに済みます。

画像・動画・フォント・JavaScript・外部タグの上限をどう決めるか

資源上限は、「初期表示で必要な分」と「スクロールや操作後を含むページ全体」を分けて決めます。ページ全体が軽くても、最初に大量の動画やタグを読み込めば待ち時間は長くなります。逆に、初期表示を絞り、下部の画像や動画を必要な時点で読み込めば、内容量を保ちながら最初の体験を守れます。

画像は、枚数よりも表示寸法・形式・読み込み位置を一緒に見ます。スマートフォンで幅400px程度にしか表示しない画像へ、数千pxの原寸を送らないよう、端末に応じた画像を用意します。ファーストビュー外は遅延読み込みの対象にできますが、LCP候補となるメイン画像まで遅延させると、最も見せたい内容が遅れることがあります。メイン画像は個別の上限を持ち、その他の初期表示画像と、ページ全体の画像合計を分けると管理しやすくなります。

動画は、ファイル容量だけでなく「いつ通信を始めるか」を仕様にします。再生される可能性が低い説明動画なら、ポスター画像だけを先に表示し、クリック後に動画データを読み込む方法があります。背景動画を自動再生する場合は、スマートフォンで停止するか、短い軽量版へ切り替えるか、静止画を代替にするかまで決めます。外部動画サービスの埋め込みも、ページ表示時にプレーヤー一式を読むのか、サムネイルを押してから読むのかで初期負荷が変わります。

フォントは、ブランド表現に必要な書体とウェイトを絞ります。同じ書体でも、標準・中太・太字をすべて別ファイルで読むと転送量が増えます。日本語フォントは文字数が多いため、ファイル数、配信形式、必要文字の絞り込み、読み込み中の代替表示を設計対象にします。見出しだけ独自書体、本文は端末の標準書体とする配分も選択肢です。

JavaScriptは転送量だけでなく、解析・実行に使うCPU時間も確認します。圧縮後のファイルが小さくても、低性能端末で長く処理すれば操作が遅れます。スライダー、アニメーション、絞り込み、チャットなど、どのページで何のために動くかを棚卸しし、全ページへ共通読み込みする必要があるかを確認します。

外部タグは、分析、広告、ヒートマップ、チャット、予約、地図、SNS、同意管理など、担当部署が違うと増えやすい領域です。サービス数、初期リクエスト数、読み込み開始条件、管理者、削除条件を記録します。第三者のサーバー状況やコード変更は自社だけで制御できないため、容量の上限だけでは足りません。「同意後に読み込む」「対象ページだけで動かす」「一定期間使われなければ外す」といった運用条件を持たせます。

上限値には、すべてのサイトへ通用する一つの正解はありません。コンテンツ、利用者、サーバー、実装方式で結果が変わるためです。最初は仮の配分を置き、デザイン試作と実装で測りながら調整します。次は、トップページをモバイル優先で試作するときの架空の記入例です。業界標準や推奨値ではなく、合意表の粒度を示すための例として見てください。

この表の各上限は独立した足し算ではありません。たとえば画像500KBとJavaScript250KBは、初期表示の総転送量1.3MBの中に含まれます。試作でLCPが目標を外れたら、総容量だけでなく、メイン画像の発見が遅い、CSSが描画を止めている、外部タグが先にCPUを使っているなど、読み込み順と処理を調べます。画質を下げる前に配信寸法や形式を直す、動画を削る前にクリック後読み込みへ変える、といった順序で判断します。

測定はデザイン案・実装途中・公開直前の三回に分ける

予算は、公開直前に一度だけ測っても効果が薄くなります。その時点で大きな動画や複数の外部ツールが前提になっていると、構成や表現を戻すコストが高いからです。少なくともデザイン案、実装途中、公開直前の三回に分け、各段階で変えられるものを確認します。

デザイン段階では、完成したコードがなくても確認できます。画像を書き出して容量を見る、動画の長さと解像度を仮決めする、利用予定の外部サービスを一覧にする、フォントファイルを数えるだけでも、予算を大きく使う要素が分かります。ここで「動画は背景演出のため必須」「地図はアクセスページだけ」「チャットは問い合わせの多いページだけ」と役割を明確にします。

実装途中では、仮画像やダミータグのまま測らないことが重要です。公開時に近い画像、フォント、計測タグを入れた代表ページで、ネットワークの転送量と処理を確認します。変更前の値を残し、一つの変更ごとに再測定すると、どの修正が効いたか分かります。複数の最適化を同時に入れて結果だけ比べると、将来の更新時に再現できません。

公開直前は、同意管理、広告計測、フォームのスパム対策、地図、チャットなど、後から追加されがちな外部要素を含めます。テスト環境では動かないタグがある場合は、その差を記録し、本番で追加した直後に再計測する手順を組みます。キャッシュがない初回表示と、再訪問の両方を確認し、主要ページのスクリーンショットや計測結果を予算表へ添えます。

公開後は、制作中のラボ計測から実利用データへ視点を広げます。アクセスが少ないページは十分な実利用データが集まらない場合があるため、ラボ計測も継続します。キャンペーンタグや新しい埋め込みを追加するたびに予算表を更新し、制作時の上限を運用ルールへ引き継ぐことで、公開後の少しずつの肥大化を防げます。

予算を超えたら、見た目を一律に削らず役割から戻す

予算超過が分かったとき、最初にメイン画像を荒くしたり、すべての動きを止めたりすると、伝えたい内容まで弱くなります。先に、利用目的が不明なもの、初期表示でなくてもよいもの、同じ役割が重複するものから見直します。削る順序を制作前に決めておけば、公開直前の感覚的な交渉を減らせます。

基本の確認順は次のように考えられます。

1. 所有者や利用目的が分からない外部タグ、重複する計測、使われていないプラグインを外す
2. ファーストビュー外の画像、地図、SNS、動画プレーヤーをスクロール後・操作後の読み込みへ移す
3. 自動再生動画や装飾アニメーションを静止画、短い軽量版、対象端末限定へ変える
4. 読んでいないフォントウェイト、全ページ共通の不要JavaScript、重複ライブラリを減らす
5. 画像の表示寸法、形式、圧縮品質、切り抜きを調整し、見える大きさに合うファイルへする
6. それでも目標に届かない場合に、機能や表現そのものの優先度、または目標条件を関係者で再判断する

この順序は絶対ではありません。たとえばブランドの認識に欠かせない書体、予約に必要な外部サービス、法令対応や同意管理に必要な仕組みは、単純に外せないことがあります。その場合は対象ページを限定する、読み込み開始を遅らせる、より軽い実装方法を選ぶなど、役割を保つ代替策を探します。アクセシビリティや入力の使いやすさを犠牲にしてスコアだけを上げないことも重要です。

超過を例外として認める場合は、理由を一文で残します。「トップページの製品動画を優先するため、ページ全体の上限を増やす。その代わり、初期表示ではポスターだけを読み、動画は操作後に開始する」のように、何を増やし、何で相殺し、誰が承認したかを記録します。予算を守れなかった事実を隠すのではなく、意図した例外と無計画な肥大化を区別します。

また、追加要望が出たときは「容量が何KB増えるか」だけで判断しません。外部ドメインが増える、CPU処理が増える、同意前の通信が増える、レイアウトが動くといった影響もあります。追加内容、対象ページ、初期読み込みの有無、LCP・操作・安定性への影響、代わりに減らすものを一組で提示すると、担当者が見た目と速さを同じ場で判断できます。

制作会社と共有する一枚の予算表に残す項目

最終的な予算表は、技術者だけが読める監査レポートではなく、制作の判断に使える一枚にします。最低限、ページ種別、対象端末・回線、体験目標、資源上限、測定時点、超過時の対応、担当者を並べます。数値の横に「なぜその配分が必要か」を短く書くと、後から担当者が変わっても目的を失いません。

一枚へまとめる項目は、次の形が使いやすいでしょう。

• 対象ページ種別と代表URLまたは画面名
• 優先端末、画面幅、通信・CPU制限、キャッシュ条件
• LCP・INP・CLSの目標と、制作中に代用して確認するラボ指標
• 初期表示とページ全体の総転送量、総リクエスト数
• LCP画像、初期表示画像、ページ全体画像の上限
• 動画の再生条件、ポスター上限、自動再生時の端末別代替
• フォントの書体数、ウェイト数、ファイル数、転送量
• 初期JavaScriptの転送量と処理時間、ページ別読み込みの方針
• 外部サービス名、目的、管理者、対象ページ、読み込み開始、停止条件
• デザイン案・実装途中・公開直前の測定日と結果
• 超過時の削減順序、例外の承認者、公開後の確認担当

制作の初期にすべての数値を確定できない場合も、空欄のままにせず「試作後に決める」「外部サービス選定後に測る」と決定時点を書きます。未決定項目が見えるだけでも、公開直前の追加を減らせます。画像や動画が増えたときは予算表の該当欄を更新し、デザインだけ変更して速度条件を置き去りにしないようにします。

本稿が扱うのは、制作前に上限と測定の約束をつくる段階です。すでに公開しているサイトで、サーバー、キャッシュ、CDN、改修費用や運用負荷を含めて改善方法を検討している場合は、サイト表示速度改善の費用：運用負荷とコストを最適化するポイントの方が近い内容です。二つを分けることで、制作前の予防と公開後の改善を混同せずに判断できます。

表示速度の予算で最も重要なのは、数字を厳しくすることではありません。対象端末・回線・主要ページを固定し、体験目標と資源上限を結び、デザイン案・実装途中・公開直前で同じ条件から測ることです。超過時に何を戻すかまで合意できていれば、画像や動画を活かしながら、公開後に初めて「重すぎた」と気づく事態を減らせます。