アカウント名:
パスワード:
8ビットパソコン時代には、わりと一般的なことだったんですけどね。 googleは、古くなって省みられなくなったテクニックが、じつは 現代にも有効であることを示してくれました。
しかし、ソースよりも画像のほうが圧倒的に大きいですので、 これ以上に転送量を減らすには、画像をいじらないといけなく なりますね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stay hungry, Stay foolish. -- Steven Paul Jobs
転送量 (スコア:3, 興味深い)
結果は見てのとおり Google の圧勝。8倍も差があるとは思わなかった。
Google はソース内の空白や改行も極限まで減らしてる上に、 JavaScript はメソッド名や変数名も短縮してるという変態的な徹底ぶり。
goo も頑張れ。
Re:転送量 (スコア:3, 参考になる)
>http://search.goo.ne.jp/ 合計: 82.99 KB (84,984 バイト)
>http://www.google.co.jp/ 合計: 10.2 KB (10,446 バイト)
アクセス頻度の高いページ(トップページ等は特に)は、極力 サイズを削減すべきです。
数KBの違いでも数万、数十万というオーダでアクセスがあれば、大変な転送量になります。
Webサーバ側で考えると、サーバリソースやネットワーク帯域を浪費する事になり、レスポンスも悪くなるわけです。
>結果は見てのとおり Google の圧勝。8倍も差があるとは思わなかった。
>Google はソース内の空白や改行も極限まで減らしてる上に、 JavaScript はメソッド名や変数名も短縮してるという変態的な徹底ぶり。
Googleはそれだけ多くのアクセスが来る事を想定し、それを受け入れる用意をしているということでしょう。
心構えが違いますね。
goo も頑張れ。
#実際に、4,5年前に某企業内のWebサーバの性能が出なかった時に
#トップページのファイルの行頭、行末のブランクを一律削除し、トップページで表示しているイメージファイルのサイズを縮小することで、性能問題を改善した事があります。
Re:転送量 (スコア:1)
徹底的な変態ぶり じゃなくて
変態的な徹底ぶり なところがミソですな。
==========================================
投稿処理前プレビュー確認後書込処理検証処理前反映可否確認処理後……
Re:転送量 (スコア:0)
8ビットパソコン時代には、わりと一般的なことだったんですけどね。
googleは、古くなって省みられなくなったテクニックが、じつは
現代にも有効であることを示してくれました。
しかし、ソースよりも画像のほうが圧倒的に大きいですので、
これ以上に転送量を減らすには、画像をいじらないといけなく
なりますね。
Re:転送量 (スコア:1)
まあ、トップページもそれだけならキャッシュされるのでついででしょうか。
検索結果のページだと、偏執狂的なコンパクト化も効いてくると思います。
Re:転送量 (スコア:0)
昔のテクニックをメモリ云々ではなくて「転送量」を削減する
目的で今も実践しているよい例としてよく紹介されています。
携帯端末からパケットプランで見る人には、HTMLのサイズは
かなり死活問題ですし。
# 富豪的プログラミングが主流になってきたけど、
# 情報系の先生達は今でもメモリをケチりたがるんですよね。