2月16日、Gwern Branwen氏が「Gwtar: a static efficient single-file HTML format · Gwern.net」と題した記事を公開した。この記事では、Webアーカイブにおける長年の難題を、JavaScriptとHTTP規格の裏をかくようなハックで解決した画期的な新フォーマット「Gwtar」について詳しく紹介されている。
以下に、その内容を紹介する。
Webアーカイブの「トリレンマ」
エンジニアがWebページを完全に保存しようとした際、常に以下の3つの特性のうち、どれか1つを諦める必要があった。これを「HTMLアーカイブのトリレンマ（3要素から成るジレンマ）」と呼ぶ。
- Static（静的・自己完結）: 外部サーバーや元のドメインに依存せず、そのファイルだけで完結している。
- Single File（単一ファイル）: ディスク管理や配布が容易な1つのファイルである。
- Efficient（効率的）: 表示に必要なデータだけを読み込み、不要な資産（動画など）をメモリや帯域にロードしない。
既存の代表的なツールである「SingleFile」は、1と2を満たすが、3が致命的であった。数GBのメディアを含むページを保存すると、そのHTMLを開くだけでブラウザが全データをメモリに展開しようとし、クラッシュやフリーズを引き起こすからだ。これを回避するためにファイルを分解すれば、今度は2（単一ファイル）を失うことになる。
Gwtarのアイデア：JavaScriptによる「自爆」と「自己再構築」
Gwtarが画期的なのは、ブラウザの標準機能を組み合わせることで、このトリレンマを力技で解消した点にある。その核となるアイデアは、「HTMLファイルを、自分自身の後ろにtarアーカイブを背負った自己解凍型バイナリのように扱う」ことだ。
1. 読み込みの強制停止（window.stop()）
ブラウザがHTMLを読み込む際、通常は末尾まで一気にダウンロードしようとする。Gwtarファイルは、冒頭のJavaScriptヘッダーで実行される window.stop() により、自身のダウンロードを意図的に「自爆」させて停止させる。これにより、末尾に結合された数GBのバイナリデータが不要に読み込まれるのを防ぐ。
2. HTTP Range Requestによるピンポイント抽出
ダウンロードを止めた後、JavaScriptは自分自身のURLに対して HTTP Range Request を発行する。ファイル末尾に結合されているtarアーカイブの中から、今表示に必要なHTMLや画像データだけを「バイト単位」で指定して取得するのだ。
単一ファイル内のどこに何のデータがあるかを特定するため、GwtarのヘッダーにはJSON形式のインデックス（マニフェスト）が含まれている。JavaScriptはこのインデックスを参照し、必要な資産のバイト範囲を特定して Range: bytes=start-end ヘッダーと共にリクエストを送るという仕組みだ。
3. Blob URLによるオンデマンド展開
取得したバイナリデータは、Base64エンコードによるオーバーヘッドを避けるため、Blob（Binary Large Object）として処理される。
- fetch で取得した ArrayBuffer を Blob に変換。
- URL.createObjectURL(blob) を用いて一時的なURLを発行。
- DOM内の
<img>や<video>のsrcをこのBlob URLに差し替える。
これにより、ブラウザは巨大なバイナリをテキストとしてパースすることなく、ネイティブな速度でレンダリング可能となる。
既存手法と比較した圧倒的な優位性
この「ハック」とも言える手法により、Webアーカイブの運用は劇的に改善される。
- 「開けない巨大ファイル」からの解放:
従来の手法では286MBのメディアを含むページを開くには286MBすべてのダウンロードが必要だったが、Gwtarでは初期ロードはわずか数KBで済み、再生されるメディアの断片だけが随時読み込まれる。 - サーバーサイドの複雑性ゼロ:
この仕組みはすべてクライアントサイドのJavaScriptで完結している。サーバー側には特別なAPIもデータベースも不要で、S3やGitHub Pagesのような静的ホスティングに「ただ置くだけ」で、オンデマンド配信機能を持つ高度なアーカイブとして機能する。 - 長期的なポータビリティ:
Gwtarは単なる「HTML + tar」の連結ファイルである。万が一、将来JavaScriptが動かなくなったとしても、標準的なtarコマンドで中の資産を取り出すことが可能であり、データの腐敗（Bitrot）に強い。
承知した。エンジニアが真っ先に抱くであろう疑問や懸念を、あらかじめ「既知の制限」としてフェアに提示しておくことで、記事の信頼性と議論の質をさらに高めることができる。
最終セクションを調整し、これらのポイントを追加した。
既知の制限とトレードオフ
ここで紹介されている手法は、エンジニアであれば即座にいくつかの懸念を抱くだろうが、Gwern氏もそれらを認識した上で、アーカイブとしての実用性を優先している。
- ローカル閲覧の制限（CORSの壁）:
この手法の最大の問題は、ローカルでの閲覧が容易でないことだ。せっかく単一のHTMLファイルが手に入ったとしても、ダブルクリックで即座に閲覧することはできない。その理由は、ブラウザのセキュリティポリシー（Same-origin policy）により、ローカルファイルとして開いたHTMLから自身に対してRange Requestを送ることは制限されるためである。ローカルで閲覧・編集する場合は、tarコマンドで資産を展開して通常のHTMLに戻す必要がある。 - CDNによるRangeヘッダーの剥離:
Cloudflare等のプロキシは、text/htmlのレスポンスからRangeヘッダーを削除する挙動がある。これを回避するため、GwtarはMIMEタイプをx-gwtarと定義してブラウザのコンテンツ・スニッフィングを利用するという、さらなるハックを要している。 - JavaScriptへの依存:
コア機能がJSに依存しているため、JS無効環境では動作しない。ただし、その場合はフォールバックとして「通常の巨大なHTML」として振る舞い、ファイル全体をダウンロードしようとするため、アーカイブとしてのデータ整合性は保たれる。
結論：エンジニアリングによる「保存」の再定義
Gwtarは、Webブラウザの古い標準仕様を巧みに組み合わせることで、複雑な専用サーバーを構築することなく「静的・単一・効率的」なアーカイブを実現した。これは、増大し続けるWebの資産を、いかに軽量かつ堅牢に次世代へ引き継ぐかという問いに対する、極めてエンジニアらしい回答であると言える。
詳細はGwtar: a static efficient single-file HTML format · Gwern.netを参照していただきたい。
