なぜ「重い動的HTML」はサーバー強化では直らないのか【プロの基準と再現プロンプト】

バブルや磨りガラス、流れるビーコンのような「動く演出」を増やすと、ページが重くなる不安が出てきます。このとき「サーバーを強くすれば解決するのでは」と考えがちですが、答えはノーです。実際にサイトの動的HTML(AIトレンドユニバースの星図演出)を最適化する過程で見えてきた、プロの基準を分解します。

1. 負荷の正体は「サイズ」ではなく「毎フレームの描画」

磨りガラス演出(backdrop-filter)を全カードに復元したとき、ファイルの増加量はわずか166バイトでした。読み込み時間への影響は事実上ゼロです。それでもこの1行は「重い」処理に分類されます。なぜなら、ブラウザはスクロールのたびに毎秒60回、ガラスの裏側をぼかし直しているからです。

これに対して、画像が大きい・ファイルが多いといった問題は「運ぶ量」の問題であり、性質がまったく違います。

原則：重さには2種類ある。「運ぶ重さ(ファイルサイズ)」と「動かす重さ(毎フレームの描画コスト)」を混同しない。前者は一度きり、後者は表示中ずっと続く。

2. サーバーは配達員、描画は閲覧者のブラウザの仕事

サーバーの仕事はHTMLや画像を「届ける」ところまでです。届いた後にバブルを飛ばし、ガラスをぼかし、ビーコンを光らせているのは、閲覧者の手元のブラウザ(GPU/CPU)です。

つまり月額10万円のサーバーに乗り換えても、閲覧者のスマホでのカクつきは1ミリも改善しません。逆に、配信が問題(画像が重い、応答が遅い)ならコードをいくら磨いても届くのは遅いままです。どちらの重さかを見極めてから対策を選ぶのが、失敗しない最初の分かれ道です。

原則：「表示されるまでが遅い」ならサーバー・配信側、「表示された後がカクつく」ならコード側。対策を打つ前に、どちらの症状かを必ず切り分ける。

3. 動く領域を「主役」だけに限定する

全画面を覆うCanvasに常時アニメーションを敷き詰めると、ブラウザは画面の全ピクセルを毎フレーム計算し続けます。今回の星図演出が優れていたのは、派手に見えて実は動いているのは細い線と数個の光点だけという設計だったからです。

これはデザイン原則の「発光は主役だけに絞る」と表裏一体です。見た目の絞り込みは、そのまま描画コストの絞り込みになります。

原則：アニメーションさせる領域と要素数を数えられる範囲に保つ。「なんとなく全面に敷く」が最も高くつく。

4. 見えていないものは止める

どれだけ演出を仕込んでも、画面の外にあるものを動かし続けるのは純粋な無駄です。要素が画面に入った瞬間だけ動かし、出たら止める(IntersectionObserver)。実際に動いているのは画面内にいる間だけ、という設計にすると負荷は大きく下がります。

高解像度ディスプレイへの対策も同じ発想です。Retina画面で愚直に全ピクセル描くと描画量は4倍になるため、描画解像度に上限を設けます(devicePixelRatioを2でキャップ)。見た目の差はほぼなく、コストだけが下がります。

原則：「画面外で止まっているか」「解像度に上限があるか」。この2つは動的HTML作品の検収項目に必ず入れる。

5. ブラウザが得意な動きだけを使う

同じ「動かす」でも、コストは桁違いです。transform(移動・拡大)とopacity(透明度)はGPUが直接処理できるため安く、width・height・topなどの変更はレイアウト計算からやり直しになるため高くつきます。backdrop-filterは例外的に高価なGPU処理なので、使う枚数を意識して数える対象です。

原則：アニメーションはtransformとopacityを第一選択にする。それ以外のプロパティを動かすときは「本当にそれでしか表現できないか」を一度疑う。

結論：プロの基準はコード側の最適化

ここまでの5つの原則には、サーバーのプランも料金も一度も登場しませんでした。166バイトの追加が「重い」ことも、全面アニメーションが高くつくことも、画面外で止めるべきことも、すべて解決の場所はコードの中にあります。

サーバーは届けるだけ。動きの品質は、書き方が決まります。

再現用プロンプト(保存用)

今後、バブル・パーティクル・発光などの動的HTML作品をAIに生成させる際、そのまま貼り付けて使えるプロンプトです。

以下のパフォーマンス基準を満たす形で動的HTMLを設計・実装してください。

【描画コストの設計】
アニメーションの負荷はファイルサイズではなく毎フレームの描画コストで
評価すること。実装後、「常時動いている要素の数」と「動いている領域の
面積」を報告し、それぞれが演出上必要な最小限であることを説明すること。

【停止条件】
すべてのアニメーションループ(requestAnimationFrame等)は、
IntersectionObserverで対象が画面内にあるときだけ実行すること。
タブが非表示のとき・要素が画面外のときにCPU/GPUを消費しない
ことを実装後に確認すること。

【解像度上限】
Canvasを使う場合、描画解像度はdevicePixelRatioを最大2で
キャップすること。

【プロパティ選択】
アニメーションはtransformとopacityを第一選択とする。
width/height/top/left等のレイアウトプロパティのアニメーションは
使用しない。backdrop-filterを使う場合は適用要素の枚数を宣言し、
スクロール時のフレームレートに顕著な劣化がないことを確認すること。

【検収】
実装後に必ず報告すること:
1. 常時アニメーション中の要素数と領域
2. 画面外で描画が停止していることの確認方法と結果
3. スクロール操作時の体感パフォーマンス

このプロンプトの核心は「実装後に数値と確認結果を報告させる」という部分です。AIは「軽量に実装しました」と自己申告しがちですが、実際に確認したかどうかは別問題です。要素数・停止確認・体感の3点をセットで報告させることで、「動いた=完成」ではなく「止まるべきときに止まる=完成」という基準をAIに強制できます。

AI × HUMAN FOUNDATION

AIに任せれば、できることは増える。 けれど、正しく選べるとは限らない。

AI時代に必要なのは、AIに丸投げする力ではなく、AIが出した結果を判断できる最低限の基礎です。

競合が提供

顧客が求める

自分にできる

あなたが
活躍できる場所

01

AI活用調査・生成・比較を速め、見える選択肢を広げる。

02

人間力HTML/CSS・マーケ・設計の基礎で、AIの答えを判断する。

AI活用と人間力が重なるほど、あなたにしか生み出せない価値の領域は広がっていきます。

AIトレンドロードマップを見る →

※ 別タブで開きます。読み終えたらこの記事に戻れます。