Webページの平均サイズ、1MBに近づく 33
ストーリー by hylom
肥大化 部門より
肥大化 部門より
headless 曰く、
HTTP Archiveが人気サイトのWebページを調査した結果によると、現在のWebページの平均サイズは965KBであり、昨年の平均702KBから30%増加したという（HTTP Archive — Trends、ExtremeTechの記事、本家/.）。
Webページが大容量化しているにもかかわらず、Flashコンテンツの平均サイズは昨年と変わらず90KBなのだという。一方、JavaScriptの平均サイズは113KBから172KBに増加しており、HTMLやCSS、画像の平均サイズも大きく増加している。これはFlashからHTML5への移行を示すものといえるだろう。ただし、HTTP Archiveが調査を開始したのは2010年からなので、長期にわたるFlashの利用動向などを読み取ることはできないとのこと。
むしろ (スコア:2)
Twitterやgoogleのように、コンテンツを続けて追う場合、どんどんページが動的に伸びるのが当たり前になりつつありますが、
どこで1ページと切るか判断が難しくなっているような。
Re:むしろ (スコア:1)
操作するなどして更なるリクエストが発生するまでに取得できるデータが
「1ページ」分じゃないですかね。
ただ、広告とかで何もしなくても延々と断続的にデータを取りに行って
新しいデータを表示するみたいなものもあるので、区切りが難しい
ことは確かですね。
Re: (スコア:0)
もっとヤなのは画像を遅延ロードしてる場合だよなぁ…
画像の埋まった場所までスクロールしないと画像のローディングが始まらない。
イオンSIMだと (スコア:0)
1分くらいかかる計算になるわけか。そりゃ限られた用途でしか使いものにならんわ
(圧縮プロキシを通すらしいからそこまでひどくはないかもしれないが)
Re: (スコア:0)
最初はそうなるが、次回からはキャッシュが効くから、通常とあまり変わらない。
Re: (スコア:0)
bモバイルの圧縮プロキシは超バカなので、全く違う画像を表示する事も多く、参考にならないと思う
リンクの画像とか、代替テキストの方が分かりやすいレベル
Flashコンテンツのサイズ (スコア:0)
起動してから引っ張ってくるデータの大きさは？
Re: (スコア:0)
一つ上（#2071902、Limbodot さんのコメント）のように、HTMLでもそうなのですが、
後から動的に取得するデータ量というのが今後は重要になってくるのでは、と思います。
Flashもバナー広告程度ならともかく、メインコンテンツに使う場合はたいてい動的取得ですし。
フレームの中身も含まれているのかな (スコア:0)
Re: (スコア:0)
今どきフレームとか言ってる男の人って(ry
Re:フレームの中身も含まれているのかな (スコア:2, おもしろおかしい)
そういう言い方はフレームのもとだよ。
Re:フレームの中身も含まれているのかな (スコア:1)
Re: (スコア:0)
元のグラフを見るとHTML、JS、CSS、Image、Flash、Domainsといった細かく分類された
グラフがあるので、別ドメイン経由で表示される部品についても集計した上できっちり
転送量を見積もっているように見えます。
今どきフレームとか言ってる男の人って(ry
昔ながらのナビゲーション用にフレームで区切るようなページは減りましたが、
iframeタグ（インラインフレーム）はTwitterやFacebookなどのソーシャル関係の
部品の多くでJavaScript経由で動的に生成されるなど、現役でしぶとく生き残っています。
また、将来的に普及が見込まれるHTML5でもiframeは廃止予定どころか定義し直されて
新たな機能まで追加され、より便利に生まれ変わっています。
（昔ながらのフレーム区切り用のタグ一式「frame」、「frameset」、「noframes」はセットで廃止）
Re: (スコア:0)
「今どきフレームとか」を「今どき(考慮して当然の)フレームとか」と読むか「今どき(時代遅れの)フレームとか」と読むかって問題ではありますが、元コメ(#2071944)と同じ事言ってません？
「イマドキ」、フレームのような参照先が明示されたコンテンツすら含めないページサイズ調査なんて冗談にもなりゃしません。
JavaScriptやFlashによる遅延ロード項目の評価方法に関しては議論の余地があるとは思いますが。
ここのサイトを見ればわかる (スコア:0)
やたらJavascriptであれこれしようとして重くなったからねえ。
※コードを増やすのが愚かなプログラマ
※コードを減らすのが賢者のプログラマ
Re: (スコア:0)
はて、ページ遷移のたびに広告を読み込んだりしなくなって投稿処理のレスポンスは明らかに軽くなったのだが。どうして「JavaScript=重くなった」と思考停止する人が後を絶たないのだろう。
# D2で連投制限を食らって結局D1を使っているのでAC
Re:ここのサイトを見ればわかる (スコア:1)
いやあ、JavaScriptはWebの重さに寄与してると思うなあ。
動的な技術は、Webのインターフェースをより重厚なものに置きかえる意識を導いていて、
Flash等の使用に一定の心理的ハードルがあるのに対して、JavaScriptは安易に、むしろ積極的に使われる傾向がある。
JavaScriptをWebを軽くするために使えばそのように使えるけれど、
実際には閲覧者に不要な色々な情報を読み込む目的で活用されていると思うなあ。
Re:ここのサイトを見ればわかる (スコア:1)
このところ、JavaScriptの復権だHTML5だWebアプリだとエンジニアサイドはやたら盛り上がってるけれど、一歩間違えたらまた昔のように忌避されてオフにされてしまう危険はあると思う。特に若いエンジニアなどは、JavaScriptが蛇蝎のように嫌われてた時代（2004年以前かな）のことを知らないんじゃないかと。
正直、Flashやその他のプラグインのようにパッケージされたサンドボックスの中で動いて、選択的にオフにできるほうがユーザーには都合がいいと思うのだが……。
この前、産経新聞だったかでマウスカーソルに画像がくっついてくるのを見た。あんなものとうの昔に絶滅したと思ってた。
Re: (スコア:0)
> 一歩間違えたらまた昔のように忌避されてオフにされてしまう危険はあると思う。
ブラウザ標準インタフェイスで「ドメイン毎にオフ」出来るようにしてくれると、
作り手側は自分とこでオフにされないために頑張るんじゃないかな？
# Web標準化が叫ばれだした時点で、オフで見れないサイトは論外として、
Re: (スコア:0)
>はて、ページ遷移のたびに広告を読み込んだりしなくなって投稿処理のレスポンスは明らかに軽くなったのだが。
そりゃページ遷移が前提のコンテンツならね。
旧UIじゃあページ遷移なんて必要ないスレが圧倒的多数だったじゃない？
此処の住人なら広告を弾いてたりAutoPager使ってたり静的コンテンツを自前で最適化してる人も
多かったと思うからAJAX化が重いっていうのは決して間違いでないと思う。
# そういう私は普段Javascriptを切っている派
Re: (スコア:0)
＜オフトピ＞
旧UIじゃあページ遷移なんて必要ないスレが圧倒的多数だったじゃない？
スレッド単位で見ればそりゃ大半はページ遷移なんて必要ないだろうよ
#ストーリーのことを言いたいのはわかっていての揚げ足取りスマソ
＜／オフトピ＞
単に重たいと言うだけではなく、旧UIだと1ページ目と2ページ目で重複してコメントが表示されてたのが不満でしたね。
スレッドを切らずに表示するためだったのかなとは思うのですが
旧UIを使えてなかっただけのような気もするのでAC
フレームの元 (スコア:0)
サーバのレスポンスの重さと、トラフィック上のデータの重さと、ローカルでの処理の重さの区別が付かないんだろ。
素人ではよくあることだ。そっとしておいてやれ。コードとかプログラマとか言ってみたいお年頃なんだよ。
Re: (スコア:0)
コードの量という意味では、こんな話もあったね。
「「jQueryは大きすぎる」との声に対応、jQueryをモジュラー化、小型化するプロジェクト「jquip」 [osdn.jp]」
Re:ここのサイトを見ればわかる (スコア:1)
もう、JQueryコアくらい成熟したものはブラウザのJSエンジンに統合して標準組み込み機能として使えると良いと思うんだけどな。
DHTMLがもてはやされていた頃は (スコア:0)
1ページ30KB以下を心がけ軽快にネットサーフィンできるようにしよう
と、雑誌のHTML指南記事に載っていたのを思い出した。
時代は変わったものだな……。
Re: (スコア:0)
今でも気にしてます。楽になるためにJSライブラリの100KBくらいは目をつぶったけれど。
JS以上に画像が最大の肥大化要因のようです...写真UPサイトに携帯のカメラ性能向上が直撃してる感じでしょうかね？
Re: (スコア:0)
とある国際イベントのエントリWebサイトの仕事をしたんですが、IDカードに印刷する顔写真をアップロードするようにしてもらったら、来るわ来るわ。
数センチ×数センチに印刷されることが分かっていながら、長辺2000ピクセルオーバー、メガバイトクラスの写真がガンガン来てびっくり。
フロントエンドを作ってる人に、あわてて「デカイのは受付時にシュリンクしてください」と言って事なきを得たんですが、今度はフロントエンドのWebサーバーの負荷が…。
家にネット環境が一時的になかった頃 (スコア:0)
ネット喫茶に行ってブラウザから「Webページ・完全」でいろんなサイトを保存しまくってたことがあったのだが、
その時の経験からしてメガバイト越えはもう当たり前だった(一年半くらい前のこと)。
最初はxyzzyとかでタグとかJavascript部分とかをカットするマクロを書いてしのいでたけど
さすがにバカらしくなって、特にブログエントリに大事なことを書いているところは
テキストファイルにコピペだけで済ますように。
あのときの理不尽さったらなかったな。
w3c信者なんてのがいて、HTMLは文書の論理構造をうんぬんと騒いでたのを
「理屈屋うぜー」で見てたもんだけど、今となっては彼らの言うことがどれだけ正しかったかよーわかる。
Ajaxがもてはやされるようになって以降のことだと思うんだけど、
回線が太くなったからいいじゃん、てのは作り手の都合以外の何者でもなくて、
あれは九割九分作り手とスポンサーしか得をしない仕組みだわね。
昔の、HTML直書きのサイトをたまに開くともう、びっくりするくらい軽いし、
Webデザイナー(笑)さんたちにはわりーけどあっちのほうがずーーーーっと、見やすいわいな。
Re:家にネット環境が一時的になかった頃 (スコア:1)
>昔の、HTML直書きのサイトをたまに開くともう、びっくりするくらい軽いし、
>Webデザイナー(笑)さんたちにはわりーけどあっちのほうがずーーーーっと、見やすいわいな。
エディタでHTML手書きが普通の頃に、デジカメが普及しだしてWEBトップページに重たい画像を置くのが主流になりつつも。
トップページを100KB以下にしようっていう人たちがいたのを思い出した。
(500KBか、1MB以下だったかもしれない)
流行りの2chコピペブログなんかだと、コピペ文章以外のアフィリリンクと画像にフラッシュの分量が99%に見えてしまう。
たまにアフィリエイトリンクしかないサイトもあるけど、ああいうのはどんだけ存在しているんだろう。
ほんとエコ(笑)じゃないよなぁ(違
Re: (スコア:0)
Blogがガラパゴスブ日記と違うことの1つがAPIの標準化に成功したことだというのに、わざわざAPIを避けて手作業で取得するのが尊いという日本人的価値観を尊重し続けてたらそりゃ理不尽な思いもするでしょう。
CMSは自動的に正しい文法のHTMLを生成するために極めて有用だし、HTMLの正しさと重さにはほとんど何の関係もないし、ちょっと何言ってるのか意味不明。
Re: (スコア:0)
揚げ足取りにしてもつまらん。ブログと上コメで挙げられてるAjaxがごっちゃになってる？
Re: (スコア:0)
W3Cの規格とJSの肥大化はあんまり関係ないような。
HTMLがしっかりしてないとJSの利用もおかしくなるし、validなHTMLはJSの導入を助けるものだし、HTML5では積極的に動的コンテンツを作成するだけの規格を用意しているし。
JSを使わないテキストコンテンツが軽いのは当たり前で、それはW3Cの規格と関係ない。
Re: (スコア:0)
Webページ・完全だと結構ファイルサイズが膨れるもんですよ。
全体のMIMEヘッダにMultipart/relatedによるファイルごとのオーバーヘッドに加えて、バイナリファイルはBASE64で保存されるから…
元の130%～150%くらいには膨れてるんじゃないかな。
シンプルなHTMLが素晴らしいのは同意。
ブログ向けに洗練されたXMLスタイルシートとか標準化されないものかねぇ…