「TOMOMI SHIBAKUSA」の裏側に迫る #03
Web版「WHAT’S ON +」は、気になるデジタルコンテンツの制作の裏側を制作者ご本人に解説してもらう企画です。Webサイト公開記念となる初回は、2024年6月18日に発売された『Web Designing』8月号の「WHAT’S ON +」でも取り上げた「TOMOMI SHIBAKUSA」のWebサイトを制作したtote inc.の山口国博さんに、本Webサイトの技術的な側面を解説していただきました。
話してくれた人
山口 国博さん
インタラクティブなWebサイトの企画・デザイン・開発を得意とするデザインスタジオ、tote（トート）フロントエンジニア。音楽業界で多数のアーティスト特設サイトやオフィシャルサイトなどの制作実績多数。デザイン性を重視した演出系のサイトづくりに取り組んでいます。レトロゲーム好き。
目次
サイトの重さという壁：毎回ぶつかる悩みと自分なりの解決策
「TOMOMI SHIBAKUSA」
デザイナーが作成したビジュアルをそのままWebサイトに実装するのは、なかなか大変です。今回はいろんなサイズと圧縮率のパターンを試しました。Webサイトの目的やターゲットのデバイスによって最適な解決策は異なるので、まるで複雑なパズルを解くような作業でした。
試した画像パターン（画像の大きさと画質を上げるとキレイになるが、容量が増えてしまう問題）
3840px – 画質100%
3840px – 画質75%
3840px – 画質50%
1920px – 画質100%
1920px – 画質75% ←採用したのはこれになります
1920px – 画質50%
960px – 画質100%
960px – 画質75%
960px – 画質50%
試した音パターン（周波数を下げるとサイズは減るが、音質も下がってしまう問題）
44kHz – ステレオ – 長いBGM
44kHz – ステレオ – 短いBGM
44kHz – モノラル – 長いBGM
44kHz – モノラル – 短いBGM
22kHz – ステレオ – 長いBGM
22kHz – ステレオ – 短いBGM
22kHz – モノラル – 長いBGM
22kHz – モノラル – 短いBGM ←採用したのはこれになります
動画は、静止画像では表現しきれない動きを活用することで、Webサイト全体の雰囲気をぐっと底上げしてくれます。After Effectsを使って動画を加工し、Webサイトに設置しました。背景動画のスピードを変えることで、雰囲気を調整できましたがエンジニアにはその良し悪しを判断するのは難しいです。そこで、制作した動画の異なるスピードバージョンをいくつか用意し、デザイナーに最適な速度を選んでもらいました。
試した動画パターン（動画の長さを長くするとスピードがゆっくりになるが、容量が増えてしまう問題）
24秒 – 画質：低 – 1280px
24秒 – 画質：低 – 640px
24秒 – 画質：高 – 1280px
24秒 – 画質：高 – 640px
48秒 – 画質：低 – 1280px
48秒 – 画質：低 – 640px
48秒 – 画質：高 – 1280px
48秒 – 画質：高 – 640px
72秒 – 画質：低 – 1280px
72秒 – 画質：低 – 640px
72秒 – 画質：高 – 1280px
72秒 – 画質：高 – 640px
96秒 – 画質：低 – 1280px
96秒 – 画質：低 – 640px
96秒 – 画質：高 – 1280px ←採用したのはこれになります
96秒 – 画質：高 – 640px
高速化とデザインを両立する難しさ
Webサイトの高速表示は重要ですが、美しいデザインと高速表示を両立させるのは容易ではありません。処理を効率的にセクション化し、CPUとGPUの使用率を綿密に監視してボトルネックを特定し改善に努め細部まで丁寧にチェック作業を重ねました。
今回のプロジェクトはビジュアル重視の要望に対応したポートフォリオサイトのため画像を多めに使用しています。もっさり感をできるだけ抑えるため、複数のPCでサイトを動作させ、動作速度をチェックする作業も続きました。低性能PCでの動きを実現するには多少コツが必要で、これまでの経験値を活かしました。
最初はスマホの動作が重すぎて絶望しました。何もかもがもたつき、まともにテストすらできない状態です。原因を探ると、予想通り大量の画像ファイルが犯人でした。加えて、スマホの画面はPCと比べて狭いので、画像容量だけでなく、アニメーション表現にも工夫が必要でした。PCでは中心に向かって全方位から立体感を表現しましたが、スマホではやや斜めの遷移ベクトルを用いることで、描画負荷を抑えつつ立体感を演出しました。
スマホとPCは異なるデバイスですが、ユーザーへの配慮と動作の軽快さを両立するため、PC開発においてもスマホでの展開を視野に入れ、共通のロジックに基づいた設計を意識しました。初期段階では開発効率が低下しますが、最終的には効率化につながりました。
LOADINGページの高速表示を実現するため、画像を一枚ずつ圧縮するよりも、画像枚数を減らす方が効果的であると判断しました。また、通常はLOADINGに動画は使用しませんが、見栄えが段違いだったので後読みという形を取り、最初の読み込み処理の軽減を図りました。デザインのこだわりも守れたと思います。
イントロ画面ですが、当初は画面全体を動かしたいと要望がありました。しかし、要素数が多くアニメーション処理が現実的に困難だったため、各要素を個別に調整し、中央部分のみマスクアニメーションで表現する方法に変更しました。画面全体を動かすことはできませんでしたが、外側から迫るようなアニメーションで視線を中央に集める工夫を施しました。
「書」の表示アニメーションはこだわりを持った演出です。しかし、エンジニアリング的にはちょっとした問題でもありました。パフォーマンス低下の懸念から、板ポリゴンに画像を貼り付ける軽量な方法を採用しました。表の漢字を激しく動かすことはユーザーにとって煩わしく感じられる可能性があるため、微妙な動作加減の調整が特に難しかったです。
「書」のアニメーション（表示切り替え）（抜粋・省略・整形）
let loader = new THREE.TextureLoader();
let textures = loader.load('assets/img/texture/diff.png');
let shaderMaterial = new THREE.ShaderMaterial({
transparent: true,
uniforms:{
tDiffuse1: { value: null },
tDiffuse2: { value: null },
mixRatio: { value: 0.0 },
threshold: { value: 0.1 },
useTexture: { value: 1 },
tMixTexture: { value: textures }
},
vertexShader:[省略].join("\n"),
fragmentShader: [省略].join("\n")
});
this.objs.shaderMaterial.uniforms.tDiffuse1.value = diff2.texture;
this.objs.shaderMaterial.uniforms.tDiffuse2.value = diff1.texture;
this.call = (args) => {
if(args.type == 'show') gsap.to(shaderMaterial.uniforms.mixRatio, { value: 1.0, duration: 1.5, ease: 'none' });
if(args.type == 'hide') gsap.to(shaderMaterial.uniforms.mixRatio, { value: 0.0, duration: 0.5, ease: 'none' });
};
メイン画面の四隅に配置された漢字は、書体の一部を切り替えるという日本語特有の演出です。軽量化を徹底的に進めたものの、やはり重さには勝てず、漢字オブジェクトは景気よく回転していましたが、処理落ちには抗えず、おしとやかな演出に変更されました。
場面が切り替わる瞬間、一瞬だけ動画の速度を変化させることで、あたかもワープしたかのような感覚を演出しています。また、画面全体のアニメーションによるもたつき感も解消するため、「現れるときはゆっくり、消えるときは早く」というパターンを採用しました。このパターンにより、ユーザーは画面変化をスムーズに認識でき、操作性を向上させるために役立ってると思います。
メインの写真については、より細部まで表現できるよう写真を分割して使用することを検討しましたが、処理速度の低下を懸念し断念しました。各要素はそれぞれが重要な役割を担っていたため、細かく演出したかったのですが、最終的に処理速度と表現力のバランスを考慮し、現状のオブジェクト数に落ち着きました。
〈次回へ続く〉7月3日水曜日更新予定
