hylomによる
2009年11月26日 15時31分の掲載
さらに速く部門より。
さらに速く部門より。
あるAnonymous Coward 曰く、
画像やスクリプトファイルといったWebページの構成ファイルをZIPでまとめて一括転送することで、Webページのロードを高速化する技術がFirefoxの開発者によって提案されている(マイコミジャーナルの記事)。
この仕組みは「Resource Packages」と呼ばれており、非対応ブラウザとの互換性を保ちつつ、高速にWebページの構成ファイルを転送することを目的としている。現在のWebページではスタイルシートや装飾画像、そしてさまざまなスクリプトなど、非常に多数の要素が含まれており、それらに対していちいちHTTPリクエストを送るのではなく、それらを1つのZIPファイル(Resource Package)にまとめて1回のリクエストで一括ダウンロードすることでページの読み込みを高速化する、という仕組みだ。Resource PackageはHTMLのヘッダ部分で指定し、非対応ブラウザでもページが正しく表示されるという。
この提案はFirefox開発者のなかでも好意的に検討されているとのことで、Firefox 3.7で実装される可能性があるという。
関連ストーリー
Firefox、5 周年を迎える 45 コメント
Firehose:構成ファイルをZIPでまとめて一括転送する技術、Firefox 3.7に向けて検討中 by Anonymous Coward
麻呂のAA (スコア:3, おもしろおかしい)
And now for something completely different...
コメントを書く
RFC2557 (スコア:3, すばらしい洞察)
MHTML を content-encoding: gzip で送るんじゃダメなの?
なんで既存の仕様を使うんじゃなくてゼロから新しいものを作り直す必要があるの?
コメントを書く
Re:RFC2557 (スコア:5, 参考になる)
短い答え:
長い答え:
この手法の概要は次のとおり。
この手法では、HTMLファイルはそのまま非対応ブラウザでも見られます。サーバ側での特別な動作も必要ありません。ZIPファイルを作るのも、対象のディレクトリにcdして、zip -r hoge.zip *で済みます。
また、動的に生成されることの多いHTMLファイルをアーカイブからはずせるため、ZIPファイルをキャッシュできます。
コメントを書く
親コメント
それってなんて .docx ? (スコア:3, 参考になる)
.docx がファイルをもっていたら、拡張子を .zip に変えて開いてみてください。
.jar も .xpi もZIPですね。
zip の書庫ってかなりさまざまなファイルに使われていますね。
コメントを書く
デザイナさんにお願いアハハーン (スコア:3, 興味深い)
普及するかどうかは微妙。デザイナさん次第だと思います。
エンジニアとしては余りまくってるCPUリソースを使うことで
ネットワークがかるくなるんだよよよ!とウキウキですが、
ヘッダを追加して、コンテンツをzipして別途アップロードするのはデザイナさんなので、
面倒なのでやらないかもですね。んで、やらなくても見れてしまうし。
更新し忘れでzipしたコンテンツが古いままとか。
mhtmlなら複数のファイルがひとつになるのでデザイナさんにもメリットが目に見えるのですけど。
phpのアクセラレータのように全自動でzipファイルの生成とキャッシングする仕組みを作ればいいですけど、
だったらサーバサイドの変更がいらないっていう仕様の意味がなくなります。
#検索エンジンのクローラはどっち見に行くのかしら。両方読んで内容比べて。
#→帯域圧迫→マズー
コメントを書く
裏技的手法ですね (スコア:2, 興味深い)
生で提供されるファイルの同期を取るのが厄介という問題が出てくるね。
つまり、この機能を使うブラウザでは表示が古いというミスが起き易くなると。
だから、運用面も考えればブラウザだけ対応すればいいとは言えません。
#面白いし改変コストの低い方法だし有効性は高いから上手くやれば良い結果は得られそうだ。
コメントを書く
Re:裏技的手法ですね (スコア:2)
場合によっては文字列だけが更新されていて、重い画像はブラウザのキャッシュにあるからいりません、なんていう場合もありますよね。毎回ブラウザのニーズに合わせてzipファイルを生成していては負荷が高いでしょうし、キャッシュにあるデータまでzipされて送信されると却ってデータが大きくなりますし、バランスを取る必要が出てきそうですね。
人生は七転び八起き、一日は早寝早起き
コメントを書く
親コメント
Re:裏技的手法ですね (スコア:3, 参考になる)
Goal [limi.net]の内容とImprementationをざっと読んでみたんですが、Webページひとつひとつを全部zipにまとめることを意図したものではなさそうですね。たとえば/.-Jで言えば、各ページに共通のアイコンやスタイルシートなどをzipにしておいて、そのページ固有のHTML等はzipとは別に取得するというような雰囲気(href="/static/site-resources.zip"などと例にある)です。
PNGの画像をzipにすると却ってサイズが増えるのでは? なんていうFAQもありますが、そこは確かにご想像のように無圧縮のzipが使われることもあるだろう、などと書かれています。
人生は七転び八起き、一日は早寝早起き
コメントを書く
親コメント
Re:裏技的手法ですね (スコア:5, すばらしい洞察)
というかみんな圧縮にこだわりすぎ。
これはどちらかというと複数ファイルをアーカイブすることによりHTTPリクエストの数を減らす方がメインの目的だと思うんだけど。
データ圧縮は回線が十分高速になると体感上の効果は小さくなるけど、HTTPのリクエスト/レスポンスを減らすのは高速回線でもそれなりにメリットが期待できる。
PNGのサイズが多少増えたとしても、数がたくさんあればリクエスト回数が減ることによるレスポンスの向上がそれを上回ることも多いでしょう。
うじゃうじゃ
コメントを書く
親コメント
やりとりのイメージ (スコア:2, 興味深い)
例を挙げると、こんなかんじかなぁ
1.クライアントがサーバーにindex.htmlをくれという
2.サーバーはindex.htmlを返しつつ、「うちはzipに対応してるよ」ということをヘッダで示す
3.クライアントは、index.htmlからサーバーへの画像やCSSのリンクを抽出し、
こんなファイルがほしいよ〜(zipで)とリストを送る
(キャッシュにあるものはリストに含めない)
4.サーバーは送り返すファイルをまとめzipで返す
(zipにまとめられなかったものもリストで返す)
5.クライアントはzipにないものを個別アクセス
こうすれば、Webサーバーを対応させれば、その上で動くプログラムには影響がないかな
コメントを書く
Re:やりとりのイメージ (スコア:2, 興味深い)
かな?
あんまり動的なページをzipに含める事は考えていないように見えますね。 固定のスタイルシートやら飾りやらを送ろうと言うのがあくまで主体のような。 まあ、手法が一般化すると今度はファイルの更新に自動対応するapache用のモジュールも作られるであろう事は疑う余地がありませんが。
だとすると、href="/static/site-resources.zip"の部分に飛んでもなくでかいファイルを指定してやるとか、無限にデータを投げ返してくるcgiやらを指定してやるとかすることで、Resource Packages対応のブラウザでは閲覧がめんどくさいページが簡単に作れちゃうような気がします。そんないたずらを仕込む前向きな理由は思いつきませんが。「Resource Packagesのダウンロードが完了していない段階でブラウザがやることが無くなったら、zipは見捨ててhttpでファイルを取りに行く」みたいな例外処理を入れておくのかな? それはそれで本末転倒のような。
コメントを書く
親コメント
Re:やりとりのイメージ (スコア:2)
このファイルはZIPファイルの最初のファイルでなければなりません。
ZIPファイルは全てを読み込まなくても中身が読めるので、とりあえず読めた部分まではZIPファイルの中身を利用できます。
コメントを書く
親コメント
まだ発展途上? (スコア:1)
いろいろ違いがあるとはいえ、やっと追いついた感じ?
#あ、JIGブラウザも似たような事をやってるんでしたっけ
コメントを書く
rsync -z (スコア:1, すばらしい洞察)
コメントを書く
昔、私も実験しました。 (スコア:1)
実験してたら、アカウントごと消されたっけ...
私の場合は、html内に圧縮したデータをエンコードして組み込んでましたけどね。
だから序文は普通にhtmlなメッセージが入っていて、非対応なブラウザにはそのメッセージだけ
みえるという形。
まあ、それ用のブラウザ構築するまでにはいたらず、飽きてしまったのだけど...
みんな似たような事を考えるみたいですね。
コメントを書く
ないです (スコア:1)
コメントを書く
暗号化もからめた議論にしてほしい (スコア:1)
応用可能な技術だと思う。
HTTPSとdeflateを絡めると、JavaScriptやCSSの読み込みに失敗したりとか
はまった経験があるので、そのあたりも含めてぜひ議論して欲しい。
コメントを書く
Re:ありがちなパターン (スコア:1)
サーバー側がリアルタイムに圧縮するのでは?
deflate のファイル複数版みたいな挙動を想像したのですが
コメントを書く
親コメント
Re:それよりいい方法がある (スコア:1)
やってみたら、スラドのコメントツリーを折りたたもうとしたらリロードされて折りたためなかったので却下。
(Opera 10.01 Windows XP)
うじゃうじゃ
コメントを書く
親コメント