ページ内ジャンプ:

アレゲなニュースと雑談サイト

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で実装される可能性があるという。

関連ストーリー

表示オプション しきい値:
  • 麻呂のAA (スコア:3, おもしろおかしい)

    sillywalk (15002) : 2009年11月26日 18時52分 (#1678652) ホームページ 日記
    を即座に貼ろうかと思ったんですが、さすがに自粛w
    --
    And now for something completely different...
  • RFC2557 (スコア:3, すばらしい洞察)

    Anonymous Coward : 2009年11月26日 19時11分 (#1678671)

    MHTML を content-encoding: gzip で送るんじゃダメなの?
    なんで既存の仕様を使うんじゃなくてゼロから新しいものを作り直す必要があるの?

    • Re:RFC2557 (スコア:5, 参考になる)

      ruto (17678) : 2009年11月26日 22時16分 (#1678808) 日記

      短い答え:

      • MHTMLは対応していないブラウザでは開けない。
      • 動的に生成されることもあるHTMLはアーカイブから外したい。

      長い答え:

      この手法の概要は次のとおり。

      1. HTMLファイルのhead内に <link rel="resource-package" href="hoge.zip" /> と記述しておく。
      2. HTMLは普通に送信する。
      3. 画像やスクリプトは通常通り相対パスで指定してある。
      4. 対応ブラウザはZIPファイルをダウンロードし、相対パスをZIPファイル内のファイルのファイル名として解釈する。もちろんZIPファイル内に見付からない場合はネットワークから取得する。

      この手法では、HTMLファイルはそのまま非対応ブラウザでも見られます。サーバ側での特別な動作も必要ありません。ZIPファイルを作るのも、対象のディレクトリにcdして、zip -r hoge.zip *で済みます。

      また、動的に生成されることの多いHTMLファイルをアーカイブからはずせるため、ZIPファイルをキャッシュできます。

    • 5個のコメント が現在のしきい値以下です。
  • ef (25263) : 2009年11月27日 9時24分 (#1678991)

    .docx がファイルをもっていたら、拡張子を .zip に変えて開いてみてください。
    .jar も .xpi もZIPですね。
    zip の書庫ってかなりさまざまなファイルに使われていますね。

  • leiqunni (8779) : 2009年11月27日 14時37分 (#1679214)

    普及するかどうかは微妙。デザイナさん次第だと思います。

    エンジニアとしては余りまくってるCPUリソースを使うことで
    ネットワークがかるくなるんだよよよ!とウキウキですが、

    ヘッダを追加して、コンテンツをzipして別途アップロードするのはデザイナさんなので、
    面倒なのでやらないかもですね。んで、やらなくても見れてしまうし。
    更新し忘れでzipしたコンテンツが古いままとか。

    mhtmlなら複数のファイルがひとつになるのでデザイナさんにもメリットが目に見えるのですけど。

    phpのアクセラレータのように全自動でzipファイルの生成とキャッシングする仕組みを作ればいいですけど、
    だったらサーバサイドの変更がいらないっていう仕様の意味がなくなります。

    #検索エンジンのクローラはどっち見に行くのかしら。両方読んで内容比べて。
    #→帯域圧迫→マズー

  • Anonymous Coward : 2009年11月26日 19時08分 (#1678665)
    ただ、サーバサイドの管理ツールなどが対応していないと、ZIPに含まれるファイルと
    生で提供されるファイルの同期を取るのが厄介という問題が出てくるね。
    つまり、この機能を使うブラウザでは表示が古いというミスが起き易くなると。

    だから、運用面も考えればブラウザだけ対応すればいいとは言えません。

    #面白いし改変コストの低い方法だし有効性は高いから上手くやれば良い結果は得られそうだ。
    • 場合によっては文字列だけが更新されていて、重い画像はブラウザのキャッシュにあるからいりません、なんていう場合もありますよね。毎回ブラウザのニーズに合わせてzipファイルを生成していては負荷が高いでしょうし、キャッシュにあるデータまでzipされて送信されると却ってデータが大きくなりますし、バランスを取る必要が出てきそうですね。

      --
      人生は七転び八起き、一日は早寝早起き
      • WindVoice (14680) : 2009年11月26日 22時07分 (#1678800) ホームページ 日記

        Goal [limi.net]の内容とImprementationをざっと読んでみたんですが、Webページひとつひとつを全部zipにまとめることを意図したものではなさそうですね。たとえば/.-Jで言えば、各ページに共通のアイコンやスタイルシートなどをzipにしておいて、そのページ固有のHTML等はzipとは別に取得するというような雰囲気(href="/static/site-resources.zip"などと例にある)です。

        PNGの画像をzipにすると却ってサイズが増えるのでは? なんていうFAQもありますが、そこは確かにご想像のように無圧縮のzipが使われることもあるだろう、などと書かれています。

        --
        人生は七転び八起き、一日は早寝早起き
        • Re:裏技的手法ですね (スコア:5, すばらしい洞察)

          albireo (7374) : 2009年11月27日 4時50分 (#1678949) ホームページ 日記

          というかみんな圧縮にこだわりすぎ。
          これはどちらかというと複数ファイルをアーカイブすることによりHTTPリクエストの数を減らす方がメインの目的だと思うんだけど。
          データ圧縮は回線が十分高速になると体感上の効果は小さくなるけど、HTTPのリクエスト/レスポンスを減らすのは高速回線でもそれなりにメリットが期待できる。

          PNGのサイズが多少増えたとしても、数がたくさんあればリクエスト回数が減ることによるレスポンスの向上がそれを上回ることも多いでしょう。

          --
          うじゃうじゃ
      • 1個のコメント が現在のしきい値以下です。
    • 3個のコメント が現在のしきい値以下です。
  • Anonymous Coward : 2009年11月26日 20時47分 (#1678746)

    例を挙げると、こんなかんじかなぁ

    1.クライアントがサーバーにindex.htmlをくれという
    2.サーバーはindex.htmlを返しつつ、「うちはzipに対応してるよ」ということをヘッダで示す
    3.クライアントは、index.htmlからサーバーへの画像やCSSのリンクを抽出し、
        こんなファイルがほしいよ〜(zipで)とリストを送る
        (キャッシュにあるものはリストに含めない)
    4.サーバーは送り返すファイルをまとめzipで返す
        (zipにまとめられなかったものもリストで返す)
    5.クライアントはzipにないものを個別アクセス

    こうすれば、Webサーバーを対応させれば、その上で動くプログラムには影響がないかな

    • s02222 (20350) : 2009年11月26日 21時58分 (#1678796)
      リンク先をざっと読んでみたところ、サーバの対応は要らなさそうな。
      1. htmlのヘッダに<link rel="resource-package" type="application/zip" href="/static/site-resources.zip" />とかそういう記述があればzipファイルを取ってくる
      2. zipファイルには中に何が入っているかなどをを示すmanifest.txtが先頭に格納されている
      3. manifest.txtを参考にhtmlの残りをパーズ。zipファイルに含まれているリソースは改めては取りに行かず、zipから取り出して使う

      かな?

      あんまり動的なページをzipに含める事は考えていないように見えますね。 固定のスタイルシートやら飾りやらを送ろうと言うのがあくまで主体のような。 まあ、手法が一般化すると今度はファイルの更新に自動対応するapache用のモジュールも作られるであろう事は疑う余地がありませんが。

      だとすると、href="/static/site-resources.zip"の部分に飛んでもなくでかいファイルを指定してやるとか、無限にデータを投げ返してくるcgiやらを指定してやるとかすることで、Resource Packages対応のブラウザでは閲覧がめんどくさいページが簡単に作れちゃうような気がします。そんないたずらを仕込む前向きな理由は思いつきませんが。「Resource Packagesのダウンロードが完了していない段階でブラウザがやることが無くなったら、zipは見捨ててhttpでファイルを取りに行く」みたいな例外処理を入れておくのかな? それはそれで本末転倒のような。

  • duenmynoth (34577) : 2009年11月26日 19時09分 (#1678666)
    アナログモデムの頃は通信プロトコル自体にデータ圧縮があったと思うので、
    いろいろ違いがあるとはいえ、やっと追いついた感じ?

    #あ、JIGブラウザも似たような事をやってるんでしたっけ
  • rsync -z (スコア:1, すばらしい洞察)

    Anonymous Coward : 2009年11月26日 21時15分 (#1678762)
    ですね。わかります
  • 契約しているWEBサーバがなかったので、無料のWEBサービスのアカウントとって
    実験してたら、アカウントごと消されたっけ...

    私の場合は、html内に圧縮したデータをエンコードして組み込んでましたけどね。
    だから序文は普通にhtmlなメッセージが入っていて、非対応なブラウザにはそのメッセージだけ
    みえるという形。
    まあ、それ用のブラウザ構築するまでにはいたらず、飽きてしまったのだけど...

    みんな似たような事を考えるみたいですね。
  • kabuchan (37144) : 2009年11月27日 9時54分 (#1679006)
    • 意図しないファイルをアーカイブしちゃうかもしれないので宝探しゲームが流行る?
    • zipの中までアクセス制御とかrewriteとかかけられないのでうれしくないなぁ
    • そもそも取りに行くの多重化になってるんだから意味ないんじゃない?
  • ZIPの暗号化の強度については門外漢なのでわからないが、
    応用可能な技術だと思う。

    HTTPSとdeflateを絡めると、JavaScriptやCSSの読み込みに失敗したりとか
    はまった経験があるので、そのあたりも含めてぜひ議論して欲しい。
  • サーバー側がリアルタイムに圧縮するのでは?
    deflate のファイル複数版みたいな挙動を想像したのですが

  • やってみたら、スラドのコメントツリーを折りたたもうとしたらリロードされて折りたためなかったので却下。
    (Opera 10.01 Windows XP)

    --
    うじゃうじゃ
  • 13個のコメント が現在のしきい値以下です。