2026-03-12

DRACO圧縮で3Dポートフォリオをさらに軽量化

KTX2でテクスチャ最適化した3D ROOMに対して、DRACOメッシュ圧縮を導入し、GLBサイズを3.08MBまで削減した記録。

DRACO圧縮で3Dポートフォリオをさらに軽量化

DRACO圧縮で3Dポートフォリオをさらに軽量化

以前、ポートフォリオ内の3D ROOMに対して、

  • テクスチャ整理
  • Cycles Bake
  • KTX2圧縮
  • 描画構造の見直し

を行い、Web向けの負荷に調整しました。

ただ、その後にROOMモデルを更新したことで、
3Dモデル本体の転送量が再び増えている状態になっていました。

今回はその続きとして、ROOM.glb に Draco 圧縮を適用し、モデルデータ自体をさらに軽くしました。

今回の目的

目的はシンプルで、見た目や操作性を変えずに 3D モデル本体のサイズを削ることです。

すでにテクスチャ側はKTX2で最適化できていたため、
次に効くポイントはメッシュデータの圧縮でした。

そこで、glTF / GLB で広く使われている Draco圧縮 を追加しました。

DRACO圧縮とは

Draco圧縮は、3Dモデルの

  • 頂点情報
  • 法線
  • インデックス

などのジオメトリデータを圧縮する仕組みです。

画像でいうWebPやAVIFのように、
見た目を大きく変えずに転送サイズを落とすための手段として扱えます。

今回のROOMでは、テクスチャ圧縮だけでは削れない
メッシュ由来のサイズを小さくする目的で導入しました。

計測結果

ROOM.glb にDraco圧縮を適用した結果、ファイルサイズは次のように変化しました。

対象ファイル圧縮前圧縮後
ROOM.glb12.36 MB3.08 MB

約 75% 前後の削減 になっています。

Network計測での転送量比較

ブラウザのNetwork計測でも、Draco導入前後でページ全体の転送量に変化が確認できました。

項目Draco前Draco後
ROOM.glb6.82 MB2.96 MB
ページ全体転送量7.9 MB4.6 MB

この結果から、

  • GLBサイズは約56%削減
  • ページ全体転送量は約42%削減

となっています。

特にDraco導入前は、ページ全体転送量の約86%が3Dモデルでした。

Draco圧縮後はこの割合が約64%まで下がり、3Dモデルがページ負荷の大半を占める状況が緩和されています。

つまり今回の最適化は、単なるファイルサイズ削減ではなく、実際のページ読み込み負荷にも直接影響する改善になっています。

以下は、Draco導入前後の比較画像です。1枚目は導入前の状態、2枚目は導入後のNetwork計測ログです。

Pre-Draco optimization comparison

Draco optimization network log

※ 1枚目で導入前の転送量を確認し、2枚目で ROOM.glb とページ全体の転送量が実際に下がっていることを計測ログで確認しています。

この削減は、ROOMページ全体の体感にも効きます。
とくに初回アクセス時は、3Dモデル本体の取得コストが下がるため、

  • 読み込み待ち時間
  • モバイル回線での負担
  • 初回表示時の転送量

の改善につながります。

実施内容

今回行った対応は大きく2つです。

1. ROOM.glb を Draco圧縮

gltf-transform を使い、既存の ROOM.glb に対してDraco圧縮を適用しました。

npx gltf-transform draco public/room/ROOM.glb public/room/ROOM.draco.glb

圧縮後は、KHR_draco_mesh_compression が付いたGLBとして出力されます。

実際に確認すると、最終ファイルは以下の状態でした。

  • generator: glTF-Transform v4.3.0
  • extensionsUsed: KHR_draco_mesh_compression
  • extensionsRequired: KHR_draco_mesh_compression

2. 読み込み側はそのまま利用

フロント側ではもともと DRACOLoader を組み込んでいたため、
今回の差し替えで大きな実装変更は不要でした。

RoomModel.tsx 側では引き続き DRACOLoader を使って ROOM.glb を読み込んでいます。

そのため、対応の中心は

  • 新しい ROOM.glb の再圧縮
  • 差し替え
  • 型エラーの解消

でした。

KTX2とDRACOの役割の違い

今回の対応は、以前の KTX2 最適化と競合するものではありません。

役割は次のように分かれています。

技術主に圧縮するもの今回の効果
KTX2テクスチャ画像転送量とGPUメモリ負荷の削減
DracoジオメトリGLB内のメッシュデータ量の削減

つまり、
KTX2で画像を軽くし、Dracoで形状データを軽くする という関係です。

3Dコンテンツを Web に載せるなら、どちらか一方ではなく、両方を分けて使う方が効果が出やすいと分かりました。

実運用で感じたこと

Draco圧縮は効果が大きい一方で、

  • すべての重さを解決するわけではない
  • 読み込み時にはデコード処理が入る
  • モデル構造や当たり判定設計が雑だと別のボトルネックが残る

という点には注意が必要です。

今回も、単に圧縮するだけではなく、

  • hover対象のraycast範囲
  • object階層の扱い
  • Room内のインタラクション設計

まで見直して、はじめて体感が安定しました。

Web の 3D 最適化は、圧縮だけで終わりません。描画、当たり判定、データ構造をまとめて見ないと体感までは改善しづらいです。

まとめ

今回の追加対応により、ROOM用の ROOM.glb は

  • 12.36 MB → 3.08 MB
  • KHR_draco_mesh_compression 付きGLBへ変換
  • 既存のDRACOLoader構成でそのまま運用可能

という状態まで整理できました。

すでに行っていたKTX2最適化に対して、
Draco圧縮を重ねることで、3Dポートフォリオ全体の初回負荷をさらに下げることができた 形です。

3DをWebに載せる場合は、

  • テクスチャ圧縮
  • ジオメトリ圧縮
  • 描画負荷の整理
  • インタラクション設計

を別々ではなく、まとめて考えることが重要でした。

記事一覧に戻る