※この記事にはプロモーションが含まれています
iPhoneでページが落ちました。
自分で作った3Dホームページを実機で開いたときのことです。パソコンでは何の問題もなく動いていた。それがスマートフォンでは、スクロールの途中でブラウザごと落ちる。
原因を調べたら、画面いっぱいの画像を6枚抱えただけでメモリが200MBを超えていました。
この記事では、3Dサイトをスマートフォンで動かすときに何が起きるかを、実測値つきで書きます。デメリットの話が中心です。作る前に知っておくと、そもそも3Dを選ぶかどうかの判断が変わると思います。
目次
デメリット1：メモリで落ちる
一番深刻なのがこれです。
3Dの画面に文字を表示するとき、文字をそのまま置くのではなく、いったん画像に変換してから3D空間に貼り付けます。この画像が重い。
画面サイズの画像を高精細で作ると、1枚あたり約33MBになります。文章が6つあれば6枚。それだけで200MBです。
スマートフォンのブラウザが1ページに使えるメモリは、パソコンよりずっと少ない。だから文章を6つ並べただけで、iPhoneは落ちます。
対処法
僕が実装で入れているのは2つです。
1つめは前後1つぶんだけを持ち、離れたら捨てる。読んでいる箇所の前後だけをメモリに置き、通り過ぎたものは明示的に破棄します。これで常時3枚程度に収まります。
2つめは画像の解像度に上限をかける。端末が高精細でも、一定以上には上げない。見た目の差はわずかですが、メモリは半分以下になります。
この2つを外すと、文章を追加した瞬間にまた落ちます。節を増やすときは必ず一緒に見直してください。
デメリット2：端末が熱くなる
見落としやすいのがこれです。
3Dは1秒間に何十回も画面を描き直しています。この処理はスマートフォンにとって重い。
問題は、3Dの部分が画面の外に出ても、描き続けてしまうことです。ユーザーがページの下のほうを読んでいる間も、上にある3Dが動き続ける。
結果、端末が熱くなり、バッテリーが減ります。長く読ませたいページほど、この影響が出ます。
対処法
画面内にあるかどうかを判定して、外に出たら描画そのものを止める。これだけです。
実装は難しくありませんが、やっていないサイトは実際に多いです。作っているときはページの上のほうしか見ないので、気づかないまま公開されます。
自分のサイトで確かめるなら、スマートフォンでページの一番下まで行き、そこで1分ほど止まってみてください。本体が温かくなるようなら、この処理が入っていません。
デメリット3：文字が読めない大きさになる
縦長の画面で起きます。
文字の大きさを決めるとき、画面の幅と高さの両方を見て「小さいほうに合わせる」という計算をします。パソコンでは問題ありません。
ところが縦長のスマートフォンでは、高さが大きいぶん幅が効いてしまい、文字が18pxまで小さくなりました。本文としては読めますが、3Dの演出の中で見せる大きな文字としては小さすぎます。
対処法
画面幅が一定より狭いときは、計算式そのものを切り替える。高さ基準をやめて幅基準に寄せます。
これは実際に自分の型で踏んで、あとから分岐を足しました。パソコンで作っている限り、絶対に気づきません。
デメリット4：スクロールでガタつく
スマートフォン特有の現象です。
スマートフォンのブラウザには、スクロールすると上のアドレスバーが隠れる動きがあります。このとき画面の高さが変わります。
画面いっぱいの3Dを「画面の高さぴったり」で作っていると、アドレスバーが動くたびに高さが計算し直され、スクロールを始めた瞬間に画面がガクッとずれます。
対処法
高さの指定を、アドレスバーの伸縮に影響されない単位に変える。具体的には 100vh ではなく 100svh を使います。
1文字違うだけですが、体感はまったく違います。既存のコードを触るときに、うっかり vh に戻さないよう注意してください。
デメリット5：動画が再生されない
3Dの演出に動画を使うことがあります。ここでも罠がありました。
iPhoneでは、音声トラックが残っている動画は自動再生されません。「音を消す」設定を付けていても、ファイル自体に音声のデータが入っていると止まる端末があります。
見た目には「動画の部分だけ真っ黒」という形で現れます。
対処法
書き出すときに音声トラックそのものを削除する。音を消すのではなく、データごと無くします。
ffmpeg -i 元動画.mp4 -an -c:v libx264 -crf 24 -pix_fmt yuv420p -movflags +faststart 出力.mp4-an が音声を削る指定です。
デメリット6：そもそも重い
最後に、根本的な話です。
3Dを動かすライブラリだけで687KBあります。ページ全体では919KB。スマートフォンの回線では、この重さがそのまま待ち時間になります。
読み込む順番を工夫すれば、本文を先に表示させることはできます。ただし総転送量は変わりません。減るのは待たされる時間であって、通信量ではない。
通信量を気にする人が多い相手なら、そもそも3Dは向いていない可能性があります。
それでも動かなかったときの逃げ道を作る
ここまで対処法を書きましたが、それでも動かない環境はあります。古い端末、通信が不安定、設定で機能を切っている場合。
だから僕は、3Dが起動しなかったときに自動で普通のページに切り替わる仕組みを入れています。
具体的には、読み込み画面が出たまま4秒経っても3Dが始まらなければ、読み込み画面を消して静止した状態で表示する。12秒経ったら強制的に切り替える。
これで何が起きても「真っ暗なまま何も読めない」状態にはなりません。
3Dが動かないこと自体は、そこまで問題ではないと思っています。問題なのは、動かなかったときに何も残らないことです。
作る前に決めておくこと
ここまで読んで「面倒だな」と思われたなら、その感覚は正しいです。
スマートフォン対応は、3D制作の中でかなりの割合を占めます。パソコンで動くものを作るのは難しくない。スマートフォンで落ちないようにするほうが手間がかかります。
だから作る前に、この3つを決めてください。
- スマートフォンからの訪問がどれくらいあるか。半分以上なら、対応の手間を見込んで予算を組む
- スマートフォンでは演出を簡略化するか。同じ表現を無理に再現せず、軽い版を用意する選択もある
- 実機で確認する端末を決めておく。最低でもiPhoneの実機1台は必要
3つめが特に大事です。パソコンのブラウザで画面を狭めるだけでは、メモリ不足も発熱も再現できません。
まとめ
この記事の核心は3点です。
- スマートフォンでの最大の問題はメモリ。画像1枚33MB、6枚で200MB、iPhoneはこれで落ちる
- 見落としやすいのが画面外での描画。止めないと端末が熱くなり続ける
- 対処はすべて実装で可能。ただし手間がかかるので、作る前に予算と方針を決めておく
正直に書くと、ここに挙げたデメリットは全部、僕が実際に踏んだものです。特にメモリで落ちたときは、原因にたどり着くまで時間がかかりました。パソコンでは一度も落ちないので、コードを疑う場所が分からない。
そしてスマートフォンで落ちるサイトは、落ちたことに気づかれません。訪問した人は黙って閉じるだけです。エラーの報告も来ない。だから公開後も気づかないまま放置されることがあります。
3Dのホームページは、演出としては強い。ただしスマートフォンを主戦場にする事業なら、その手間を払う価値があるかを先に考えたほうがいいと思います。演出で選ばれる商売なのか、それとも別の理由で選ばれているのか。そこ次第です。
自分のサイトが今どう見えているのか、まず確かめたい方へ。URLを入れるだけで、AI検索への対応度を8つの軸で採点するツールを配っています。公式LINEに登録して「AIO」と送ってください。
https://online.zoroya.co.jp/line/open/0RvI2YIDwo6D?mtid=215Go3drIXpK
出典
- メモリ使用量・文字サイズ・転送量の実測値は、すべて自社の3Dホームページ生成ツールの出力を計測したもの
- iOSの動画自動再生の挙動：実機検証で確認
100svhの仕様：MDN Web Docs