パスワードを忘れた? アカウント作成
1106415 story
インターネット

Webページの平均サイズ、1MBに近づく 33

ストーリー by hylom
肥大化 部門より
headless 曰く、

HTTP Archiveが人気サイトのWebページを調査した結果によると、現在のWebページの平均サイズは965KBであり、昨年の平均702KBから30%増加したという(HTTP Archive — TrendsExtremeTechの記事本家/.)。

Webページが大容量化しているにもかかわらず、Flashコンテンツの平均サイズは昨年と変わらず90KBなのだという。一方、JavaScriptの平均サイズは113KBから172KBに増加しており、HTMLやCSS、画像の平均サイズも大きく増加している。これはFlashからHTML5への移行を示すものといえるだろう。ただし、HTTP Archiveが調査を開始したのは2010年からなので、長期にわたるFlashの利用動向などを読み取ることはできないとのこと。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Limbodot (42869) on 2011年12月26日 11時37分 (#2071902) 日記

    Twitterやgoogleのように、コンテンツを続けて追う場合、どんどんページが動的に伸びるのが当たり前になりつつありますが、
    どこで1ページと切るか判断が難しくなっているような。

    • by Elbereth (17793) on 2011年12月27日 0時57分 (#2072423)
      最初にリクエストを出して、次に何か(Twitterなら画面スクロールとか)
      操作するなどして更なるリクエストが発生するまでに取得できるデータが
      「1ページ」分じゃないですかね。

      ただ、広告とかで何もしなくても延々と断続的にデータを取りに行って
      新しいデータを表示するみたいなものもあるので、区切りが難しい
      ことは確かですね。
      親コメント
      • by Anonymous Coward

        もっとヤなのは画像を遅延ロードしてる場合だよなぁ…
        画像の埋まった場所までスクロールしないと画像のローディングが始まらない。

  • by Anonymous Coward on 2011年12月26日 11時27分 (#2071901)

    1分くらいかかる計算になるわけか。そりゃ限られた用途でしか使いものにならんわ
    (圧縮プロキシを通すらしいからそこまでひどくはないかもしれないが)

    • by Anonymous Coward

      最初はそうなるが、次回からはキャッシュが効くから、通常とあまり変わらない。

    • by Anonymous Coward

      bモバイルの圧縮プロキシは超バカなので、全く違う画像を表示する事も多く、参考にならないと思う
      リンクの画像とか、代替テキストの方が分かりやすいレベル

  • by Anonymous Coward on 2011年12月26日 11時41分 (#2071905)

    起動してから引っ張ってくるデータの大きさは?

    • by Anonymous Coward

      一つ上(#2071902、Limbodot さんのコメント)のように、HTMLでもそうなのですが、
      後から動的に取得するデータ量というのが今後は重要になってくるのでは、と思います。
      Flashもバナー広告程度ならともかく、メインコンテンツに使う場合はたいてい動的取得ですし。

  • by Anonymous Coward on 2011年12月26日 12時18分 (#2071929)
    フレームソースが別ファイルだったりすると、少なく見積もられていそうな気がする。
    • by Anonymous Coward

      今どきフレームとか言ってる男の人って(ry

      • by Anonymous Coward on 2011年12月26日 16時10分 (#2072106)

        そういう言い方はフレームのもとだよ。

        親コメント
      • ダルシムはいつでも強くてかっこいいよ! (ホントか
        親コメント
      • by Anonymous Coward

        元のグラフを見るとHTML、JS、CSS、Image、Flash、Domainsといった細かく分類された
        グラフがあるので、別ドメイン経由で表示される部品についても集計した上できっちり
        転送量を見積もっているように見えます。

        今どきフレームとか言ってる男の人って(ry

        昔ながらのナビゲーション用にフレームで区切るようなページは減りましたが、
        iframeタグ(インラインフレーム)はTwitterやFacebookなどのソーシャル関係の
        部品の多くでJavaScript経由で動的に生成されるなど、現役でしぶとく生き残っています。

        また、将来的に普及が見込まれるHTML5でもiframeは廃止予定どころか定義し直されて
        新たな機能まで追加され、より便利に生まれ変わっています。
        (昔ながらのフレーム区切り用のタグ一式「frame」、「frameset」、「noframes」はセットで廃止)

        • by Anonymous Coward

          「今どきフレームとか」を「今どき(考慮して当然の)フレームとか」と読むか「今どき(時代遅れの)フレームとか」と読むかって問題ではありますが、元コメ(#2071944)と同じ事言ってません?

          「イマドキ」、フレームのような参照先が明示されたコンテンツすら含めないページサイズ調査なんて冗談にもなりゃしません。
          JavaScriptやFlashによる遅延ロード項目の評価方法に関しては議論の余地があるとは思いますが。

  • by Anonymous Coward on 2011年12月26日 12時56分 (#2071956)

    やたらJavascriptであれこれしようとして重くなったからねえ。

    ※コードを増やすのが愚かなプログラマ
    ※コードを減らすのが賢者のプログラマ

    • by Anonymous Coward

      はて、ページ遷移のたびに広告を読み込んだりしなくなって投稿処理のレスポンスは明らかに軽くなったのだが。どうして「JavaScript=重くなった」と思考停止する人が後を絶たないのだろう。
      # D2で連投制限を食らって結局D1を使っているのでAC

      • by Anonymous Coward on 2011年12月26日 21時58分 (#2072322)

        いやあ、JavaScriptはWebの重さに寄与してると思うなあ。
        動的な技術は、Webのインターフェースをより重厚なものに置きかえる意識を導いていて、
        Flash等の使用に一定の心理的ハードルがあるのに対して、JavaScriptは安易に、むしろ積極的に使われる傾向がある。

        JavaScriptをWebを軽くするために使えばそのように使えるけれど、
        実際には閲覧者に不要な色々な情報を読み込む目的で活用されていると思うなあ。

        親コメント
        • by Anonymous Coward on 2011年12月27日 12時22分 (#2072602)

          このところ、JavaScriptの復権だHTML5だWebアプリだとエンジニアサイドはやたら盛り上がってるけれど、一歩間違えたらまた昔のように忌避されてオフにされてしまう危険はあると思う。特に若いエンジニアなどは、JavaScriptが蛇蝎のように嫌われてた時代(2004年以前かな)のことを知らないんじゃないかと。

          正直、Flashやその他のプラグインのようにパッケージされたサンドボックスの中で動いて、選択的にオフにできるほうがユーザーには都合がいいと思うのだが……。

          この前、産経新聞だったかでマウスカーソルに画像がくっついてくるのを見た。あんなものとうの昔に絶滅したと思ってた。

          親コメント
          • by Anonymous Coward

            > 一歩間違えたらまた昔のように忌避されてオフにされてしまう危険はあると思う。

            ブラウザ標準インタフェイスで「ドメイン毎にオフ」出来るようにしてくれると、
            作り手側は自分とこでオフにされないために頑張るんじゃないかな?

            # Web標準化が叫ばれだした時点で、オフで見れないサイトは論外として、

      • by Anonymous Coward

        >はて、ページ遷移のたびに広告を読み込んだりしなくなって投稿処理のレスポンスは明らかに軽くなったのだが。
        そりゃページ遷移が前提のコンテンツならね。
        旧UIじゃあページ遷移なんて必要ないスレが圧倒的多数だったじゃない?

        此処の住人なら広告を弾いてたりAutoPager使ってたり静的コンテンツを自前で最適化してる人も
        多かったと思うからAJAX化が重いっていうのは決して間違いでないと思う。

        # そういう私は普段Javascriptを切っている派

        • by Anonymous Coward

          <オフトピ>

          旧UIじゃあページ遷移なんて必要ないスレが圧倒的多数だったじゃない?

          スレッド単位で見ればそりゃ大半はページ遷移なんて必要ないだろうよ
          #ストーリーのことを言いたいのはわかっていての揚げ足取りスマソ
          </オフトピ>

          単に重たいと言うだけではなく、旧UIだと1ページ目と2ページ目で重複してコメントが表示されてたのが不満でしたね。
          スレッドを切らずに表示するためだったのかなとは思うのですが

          旧UIを使えてなかっただけのような気もするのでAC

      • by Anonymous Coward

        サーバのレスポンスの重さと、トラフィック上のデータの重さと、ローカルでの処理の重さの区別が付かないんだろ。
        素人ではよくあることだ。そっとしておいてやれ。コードとかプログラマとか言ってみたいお年頃なんだよ。

    • by Anonymous Coward

      コードの量という意味では、こんな話もあったね。
      「jQueryは大きすぎる」との声に対応、jQueryをモジュラー化、小型化するプロジェクト「jquip」 [osdn.jp]」

  • by Anonymous Coward on 2011年12月26日 15時01分 (#2072056)

    1ページ30KB以下を心がけ軽快にネットサーフィンできるようにしよう
    と、雑誌のHTML指南記事に載っていたのを思い出した。
    時代は変わったものだな……。

    • by Anonymous Coward

      今でも気にしてます。楽になるためにJSライブラリの100KBくらいは目をつぶったけれど。
      JS以上に画像が最大の肥大化要因のようです...写真UPサイトに携帯のカメラ性能向上が直撃してる感じでしょうかね?

      • by Anonymous Coward

        写真UPサイトに携帯のカメラ性能向上が直撃してる感じでしょうかね?

        とある国際イベントのエントリWebサイトの仕事をしたんですが、IDカードに印刷する顔写真をアップロードするようにしてもらったら、来るわ来るわ。
        数センチ×数センチに印刷されることが分かっていながら、長辺2000ピクセルオーバー、メガバイトクラスの写真がガンガン来てびっくり。
        フロントエンドを作ってる人に、あわてて「デカイのは受付時にシュリンクしてください」と言って事なきを得たんですが、今度はフロントエンドのWebサーバーの負荷が…。

  • by Anonymous Coward on 2011年12月26日 17時16分 (#2072125)

    ネット喫茶に行ってブラウザから「Webページ・完全」でいろんなサイトを保存しまくってたことがあったのだが、
    その時の経験からしてメガバイト越えはもう当たり前だった(一年半くらい前のこと)。
    最初はxyzzyとかでタグとかJavascript部分とかをカットするマクロを書いてしのいでたけど
    さすがにバカらしくなって、特にブログエントリに大事なことを書いているところは
    テキストファイルにコピペだけで済ますように。
    あのときの理不尽さったらなかったな。

    w3c信者なんてのがいて、HTMLは文書の論理構造をうんぬんと騒いでたのを
    「理屈屋うぜー」で見てたもんだけど、今となっては彼らの言うことがどれだけ正しかったかよーわかる。
    Ajaxがもてはやされるようになって以降のことだと思うんだけど、
    回線が太くなったからいいじゃん、てのは作り手の都合以外の何者でもなくて、
    あれは九割九分作り手とスポンサーしか得をしない仕組みだわね。
    昔の、HTML直書きのサイトをたまに開くともう、びっくりするくらい軽いし、
    Webデザイナー(笑)さんたちにはわりーけどあっちのほうがずーーーーっと、見やすいわいな。

    • >昔の、HTML直書きのサイトをたまに開くともう、びっくりするくらい軽いし、
      >Webデザイナー(笑)さんたちにはわりーけどあっちのほうがずーーーーっと、見やすいわいな。

      エディタでHTML手書きが普通の頃に、デジカメが普及しだしてWEBトップページに重たい画像を置くのが主流になりつつも。
      トップページを100KB以下にしようっていう人たちがいたのを思い出した。
      (500KBか、1MB以下だったかもしれない)

      流行りの2chコピペブログなんかだと、コピペ文章以外のアフィリリンクと画像にフラッシュの分量が99%に見えてしまう。
      たまにアフィリエイトリンクしかないサイトもあるけど、ああいうのはどんだけ存在しているんだろう。
      ほんとエコ(笑)じゃないよなぁ(違

      親コメント
    • by Anonymous Coward

      Blogがガラパゴスブ日記と違うことの1つがAPIの標準化に成功したことだというのに、わざわざAPIを避けて手作業で取得するのが尊いという日本人的価値観を尊重し続けてたらそりゃ理不尽な思いもするでしょう。
      CMSは自動的に正しい文法のHTMLを生成するために極めて有用だし、HTMLの正しさと重さにはほとんど何の関係もないし、ちょっと何言ってるのか意味不明。

      • by Anonymous Coward

        揚げ足取りにしてもつまらん。ブログと上コメで挙げられてるAjaxがごっちゃになってる?

    • by Anonymous Coward

      W3Cの規格とJSの肥大化はあんまり関係ないような。
      HTMLがしっかりしてないとJSの利用もおかしくなるし、validなHTMLはJSの導入を助けるものだし、HTML5では積極的に動的コンテンツを作成するだけの規格を用意しているし。

      JSを使わないテキストコンテンツが軽いのは当たり前で、それはW3Cの規格と関係ない。

    • by Anonymous Coward

      Webページ・完全だと結構ファイルサイズが膨れるもんですよ。
      全体のMIMEヘッダにMultipart/relatedによるファイルごとのオーバーヘッドに加えて、バイナリファイルはBASE64で保存されるから…
      元の130%~150%くらいには膨れてるんじゃないかな。

      シンプルなHTMLが素晴らしいのは同意。
      ブログ向けに洗練されたXMLスタイルシートとか標準化されないものかねぇ…

typodupeerror

一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy

読み込み中...