アカウント名:
パスワード:
昔はGoogleのページのデータ量（転送バイト数）も今よりずっと少なかったはず。それ自身がどれだけ「軽さ」に寄与していたかは分からないけど、少なくともその（軽さを追求するという）姿勢が、初期のGoogleが支持された理由のひとつだったと思います。それが、いつのまにやら、どんどん肥大化してしまいました。
今はネットインフラも整備が進んでるので昔ほどバイト数に神経質になる必要はないとは思うけど、ページがどんどん肥大化してるのに、いまさらロゴのデータ量が少ないと言ってもね。
データ転送量Googleに限った話じゃないでしょ。無圧縮データが飛び交う現代に、ロゴが305Byteだとか、完全にドヤりたいだけじゃん。
だよね。データ量は少なくなっても、それを描画側でプログラム的に表示してるっわけだから単純なガチ画像データを表示するよりは負荷は増加する。データ量を取るか、CPU負荷などを取るか、って話だよね。まぁトラフィックは他にも影響するが、描画不可はそれを表示したクライアント単体の話なので当然描画負荷をとるのは当然の流れではあるんだけど。
データ量も少ないし負荷も少ない。これができたらドヤ顔してくれていい。
データ量なんて気にしている分けない。トップページはテキストデータだけで70KBほどありますから。やるんなら先にそっちを減らすでしょう。
少なくともWeb検索に関してはデータ量はあまり重要視はしてなさそうですね．どちらかと言うと，有り余るラストワンマイル回線の帯域をいかに効率よく使って高速に表示させるかがキーとのなるのでしょう．
ただ，YouTubeではトラフィックの減がコストの減に直接結びつくのでVP8/9を導入してデータ量を削減してますけどね．
時代の変化とともにこの辺の価値観が変わってくるのでしょうね．
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
Googleのページのバイト数 (スコア:2, 興味深い)
昔はGoogleのページのデータ量（転送バイト数）も今よりずっと少なかったはず。
それ自身がどれだけ「軽さ」に寄与していたかは分からないけど、少なくともその
（軽さを追求するという）姿勢が、初期のGoogleが支持された理由のひとつだったと思います。
それが、いつのまにやら、どんどん肥大化してしまいました。
今はネットインフラも整備が進んでるので昔ほどバイト数に神経質になる必要はないとは思うけど、
ページがどんどん肥大化してるのに、いまさらロゴのデータ量が少ないと言ってもね。
s/Google/Web/ (スコア:0)
データ転送量Googleに限った話じゃないでしょ。
無圧縮データが飛び交う現代に、ロゴが305Byteだとか、完全にドヤりたいだけじゃん。
Re: (スコア:0)
だよね。
データ量は少なくなっても、それを描画側でプログラム的に表示してるっわけだから
単純なガチ画像データを表示するよりは負荷は増加する。
データ量を取るか、CPU負荷などを取るか、って話だよね。
まぁトラフィックは他にも影響するが、描画不可はそれを表示したクライアント単体の話なので
当然描画負荷をとるのは当然の流れではあるんだけど。
データ量も少ないし負荷も少ない。
これができたらドヤ顔してくれていい。
Re: (スコア:0)
データ量なんて気にしている分けない。
トップページはテキストデータだけで70KBほどありますから。
やるんなら先にそっちを減らすでしょう。
Re:s/Google/Web/ (スコア:1)
少なくともWeb検索に関してはデータ量はあまり重要視はしてなさそうですね．
どちらかと言うと，有り余るラストワンマイル回線の帯域をいかに効率よく使って高速に表示させるかがキーとのなるのでしょう．
ただ，YouTubeではトラフィックの減がコストの減に直接結びつくのでVP8/9を導入してデータ量を削減してますけどね．
時代の変化とともにこの辺の価値観が変わってくるのでしょうね．