network.http.pipelining.maxrequests の値として32を推奨したことを批判され、反省したという記事。
私はナローバンドユーザだから、そもそもこの手のブラウザ高速化云々という情報には関心がない。小手先の努力より回線の品質を高める方がずっと重要だということは、会社でブロードバンド環境を使ってみると、よくわかる。
それはともかく、サーバへ同時にリクエストする情報の数を最大32は多過ぎる、というのが批判の趣旨のようだけれども、本当にそんなことが重要なのかどうか、私には疑問。大昔からこういう話はあって、同時リクエスト数を増やすというテクニックが繰り返し批判されている。素人には、どうも理解しがたい。
だってさ、サーバの性能は10倍どころじゃなくなっているわけでしょ。何でいつまで経っても最大8なのだろう。実際問題として、32でも不都合ないんじゃないの。ある瞬間のリクエスト数が4倍になったとしても、人がページを読む速度には限界があるわけで、トータルのリクエスト数は変化がないはず。
レンタルサーバにデータを置いている私のような素人が気にするのって、転送量くらい。コンマ何秒という瞬間においてリクエストが多いとか少ないとかでアカウントを停止されることなんてない。
以前、毎日毎日サイト全体をダウンロードする閲覧者がいて、たった一人で全転送量の4割近くを計上するというビックリがあった。当時、閲覧者は全部で1万人くらいいたのだから、かなりとんでもないことだとわかると思う。読みもしないデータをダウンロードする行為は脅威だ。
転送量の上限にはまだまだ遠かったけれど、10人くらいが同じことをはじめたら、耐えられなかったろう。1万人中、たった10人でアカウント停止だから、けっこう怖い。同様にリンク先の自動読み込みもやめてほしいと思う。読まないデータの自動取得は、転送量を驚異的に増大させてしまう。
こうした「本当の危機」と比較して、同時リクエスト数がどれだけの意味を持っているのか。
過去に何度も書いてきたことだけど、また書くよ。読み込み時間がどうしても気になる人は、タブブラウザを使って、次に読みたいページをバックグラウンドの新しいタブに読み込んでおくこと。たいていの人はそれほど文字を読むの速くないから。ナローバンドでも1ページ読む間に4～5ページくらいは読み込める。
ブロードバンドなら1ページ読む間に20ページでも30ページでも落とせるわけで、about:config がどうのこうのと考える必要は全くないのではないか。
ケーススタディ。タイトルに「前編」とあるのだから、当然、後編があるものと考えてよい。したがって、私のようなナローバンドユーザは、まず後編のリンクを探す。しかし見つからず、前編自体が2ページ構成になっていることを知る。そこで2ページ目を新しいタブに開き、それから前編1ページ目を読み始める。
読み終わる頃には2ページ目の表示が完了している。1ページ目のタブを閉じて2ページ目のタブを開く。2ページ目を読み始める前に、後編のリンクを探す。あった。これを新しいタブで開く。2ページ目を読む。
面倒くさい? そうかもね。でも私の場合はもう考える前に手が動くので、不都合もストレスもない。それに、常に「次に何を読むか」を気にしながら行動することになるから、ちょっとした思考トレーニングにもなるのではないかなあ。