ブラウザ全画面アニメーションにおける最適な制作手法とパフォーマンスの検証記録
概要
Webサイトの世界観を演出する手段の一つとして、ページ全体に何かしら(雪や桜がよくある)を降らせて雰囲気を出す、というアニメーションを求められることがたまにあります。
どの手法で作ると制作時間の短縮ができ、実行時の負荷が低くなるか試しました。
サンプルで制作するアニメーション
画面全体を10個ほどの雪の結晶がゆっくりと回転して左右に振れながら落下するアニメーション
CSSアニメーション
◼️制作時
メリット
- CSSとHTMLのみで実装できるため、制作スピードが速い
- アニメーションの調整(速度・位置・透明度など)がCSS変数やセレクタで直感的にできる
- デザイナーでも扱いやすく、コーディングスキルが高くなくても調整可能
デメリット
- 要素を大量に扱いたい場合はJavaScriptで制御しないと手間がかかる
- 動きのバリエーションを増やすために数種類のkeyframesを作る必要がある場合も
◼️実行時
メリット
- 少数の要素ならブラウザの最適化が効き、滑らかに表示できる
- GPUアクセラレーションが効くプロパティ(transform, opacity)を使えばパフォーマンスが良い
デメリット
- 要素数が多いとDOM管理・再描画負荷が高くなり、パフォーマンスが低下
- 画像サイズや数によってはメモリ消費が増加
◼️補足
要素の配置・アニメーションのプロパティ指定はカスタムプロパティで設定すると調整がし易いです。
三角関数やrandom関数(まだ未実装ですが…)などを使うとさらに表現の幅が広がりそうです。
致し方ないですが、装飾のためだけの要素を並べてHTMLに記載するのが少し気持ち悪くもあります。
Canvas要素を使ってJavaScriptで描画
◼️制作時
メリット
- JavaScriptで大量・複雑なアニメーションを一括制御できる
- 雪の数や動きのバリエーションを変数で簡単に調整可能
- 画像や動きのロジックを細かくカスタマイズできる
デメリット
- JavaScriptの知識が必要で、調整が難しい場合がある
- 制作スピードは慣れないと遅くなることも
- デバッグや調整に手間がかかる場合がある
◼️実行時
メリット
- 1枚のcanvasで大量のオブジェクトを効率的に描画できる
- DOMの再描画負荷が低く、パフォーマンスが高い
デメリット
- 再描画コストが高くなる場合がある(複雑・高解像度・大量描画時)
- GPU支援が弱い環境ではカクつくことがある
◼️補足
JavaScriptは概ねGithub Copilot(GPT-4.1 / Agentモード)に制作してもらいました。
AIとやり取りできれば昔ほどハードルが高くないですが、調整が必要になった時、コードを読んで書き換えられるスキル、もしくは変更点を的確に伝えられる言語力が必要になりそうです。
そういえばパーティクルを簡単に扱えるライブラリがあったな…ということを思い出しましたが、10年ぐらい前で更新が止まっているようです。
Video要素を使って動画を再生
◼️制作時
メリット
- 一度動画を作成すれば、Web上で簡単に再利用できる
- 制作ツール(AfterEffects等)で高品質な表現が可能
- 制作スキルが高い場合、複雑な演出も実現しやすい
デメリット
- 動画制作に専用ツールやスキルが必要
- 動画の修正・調整は都度レンダリングが必要で、時間がかかることも
◼️実行時
メリット
- 再生負荷が低く、パフォーマンスが安定しやすい
- どの環境でも同じ品質で表示できる
- 高品質な映像表現が可能
デメリット
- ファイルサイズが大きくなりやすい(通信量・ロード時間増加)
- インタラクティブな動きや動的な調整ができない((HTMLMediaElement API が用意するもののみ)
◼️補足
AfterEffects等の動画を作るツールが扱えないので、Canvasで描画した内容を約10秒間の動画としてWebMに出力しました。(出力ツールはCopilotに作ってもらいました)
ループをうまくつなげる対応はしていないので、10秒たったら最初にカクっと戻ります。
CSSのblend-mode:screenで黒を透過のように扱って背景を見せていますが、画像の色によってはうまくいかない場合があります。今回は白前景/黒背景だったため、たまたま意図通りになっただけです。
透過動画を作ることができれば解決するかもしれません。
その他の制作手法
SVGアニメーションやアニメーション画像(WebP・APNGなど)という手法もありますが、今回のアニメーション表現には合わなかったので対象としませんでした。
理由は下記の通りです。
SVGアニメーション
- 複雑なパスの図形や埋め込み画像はHTMLの記述量が増大になる
- 雪の結晶をパス表現にできないこともないがパスの量がそれなりに多い
- ピクセル画像を埋め込み画像にするとさらに記述量が増える
- ちなみにFigmaでは配置画像をSVG形式で書き出すと、base64形式で画像埋め込みとなる
- 外部画像はひとつひとつパスの指定が必要
- Adobe Illustratorはxlink:hrefで画像を外に配置できるが、画像のパスがSVGを書き出した画像と同階層になり、ファイル名も変更されているの再指定が必要
- SVGアニメーションは記載方法が独特で慣れないと戸惑う
- SVGとCSSで座標やスケールの扱い違うため、サイズや配置調整に時間がかかる場合がある
今回は見送りましたが、下記の場合は試してみてもよいかもしれません
- 比較的簡単なパスの図形を、DOMの要素の代わりにSVGの要素として配置してアニメーションさせる(CSSアニメーションと併用してもよい)
アニメーション画像(WebP・APNGなど)
- 画面全体の大きさの画像を用意する場合、ファイルサイズが大きくなりすぎる、また描画の負荷も高くなる
- アニメーション画像の元となる動画を作るなら、そのまま動画として配置した方が効率的
まとめ
サンプルで試した限りではパフォーマンスはどれもそれほど変わらない(FPS60を概ねキープ)ため、実装をどうするかで手法を変えるのが良いと思われます。
今回の表現であればCSSアニメーションが最も手軽で調整も簡単です。
この表現よりもっとアニメーションする対象が増えたり複雑な動きを制御したいならCanvasアニメーションもしくは動画が良いと思われます。
デザイナー自身が微調整して表現をこだわりたい場合は動画がよいかと思いますが、AIを使ってCanvasアニメーションで使用するコードを生成した方が、より求める表現に近いものが作れる可能性はあります。
なお、ここまで制作と実行時のパフォーマンスの観点でのみ解説してきましたが、今回サンプルで作成したような「画面全体で常に動くものがある」という状態はアクセシビリティの観点からはあまり良くない影響があります。(気が散る、画面酔い等)
ユーザの環境によっては最初からアニメーションさせない、アニメーションを停止できるボタンを付けるなどの配慮をしておくと、より多くの人に良い体験をもたらすことができると思います。
Discussion