やっぱり罰ゲームでしょ？ ― 2009/10/20 19:46
「これは新手の罰ゲーム？」を指して「レンダリング速くなったんだけど？」というのを見かけたのでちょっと解説。
問題の記事は
Firefox高速化テクニック8 | マイコミジャーナル
英語がチンプンカンプンの私でも辞書片手に調べようかって思うくらいの怪しい解説です。
参考にする情報は以下の3つくらいでいいでしょうか。
Content.notify.backoffcount - MozillaZine Knowledge Base
Content.notify.interval - MozillaZine Knowledge Base
Nglayout.initialpaint.delay - MozillaZine Knowledge Base
マイゴミｗは「content.notify.backoffcount」を「ページをダウンロードし終わる前にレンダリングを開始する指定」と書いてますけれど、これだけで間違いだと分かりますね。
ページをダウンロードしてる途中で定期的（0.12秒毎）にレンダリングしなおす回数の上限を設定する項目です。
そして「nglayout.initialpaint.delay」はレンダリングを開始するまでの待ち時間（ミリ秒）になります。
つまりマイコミの設定で速くなったと感じるのはレンダリングの開始が0.25秒（あるいはダウンロード終了）後から0秒になったからです（あくまで見た目の話でレンダリング終了は同じか、カスタマイズした方が体感できない程度に遅くなりますあとで受け取ったデータが解析済みのレイアウトに影響しないページなどはカスタマイズした方が早く終わりますね orz）。
ところでこのカスタマイズは適切なんでしょうか？
よく考えて欲しいのは、待ち時間0秒でレンダリングするべき情報があるのかという点です。
実際は二度目（0.12秒後）のレンダリングで表示されてるような気がしませんか？
例えば、Firefox高速化テクニック8 | マイコミジャーナルのhtmlソースを見ると
</head>まで 1,441バイト
html全文が 67,145 バイト
mod_base.cssが 24,080バイト
mod_contents.cssが 52,602バイト
……
私の通信環境はADSL 8Mでだいたい200～700KB/sくらいの速度です。 最初に受け取るであろうパケットではレンダリングするべき情報のない</head>までが精一杯に思えます。
仮に通信速度が300KB/sと仮定します。
大雑把に</head>を受け取るのが0.005秒後、htmlを読込終わるのが0.223秒後になります。
CSSもあるのでこれだけではダメですが、話を簡単にするためこれだけでレンダリングを考えると
1回目（0.00秒後）表示するものなし
2回目（0.12秒後）スクロール後の半ばまでほぼ表示可能
3回目（0.223秒後）読み込み終了後の表示
なるほどデフォルトでは0.223秒後からのレンダリングになりますから0.12秒後にある程度見えてると速くなった気がするというもの。
では「nglayout.initialpaint.delay」を「50」（0.05秒後）にしたらどうでしょう？
1回目（0.05秒後）先頭部分がほぼ表示される
2回目（0.17秒後）スクロール後の半ばまでほぼ表示可能
3回目（0.223秒後）読み込み終了後の表示
このように0.05秒後から見え始めるのでもっと速くなった気がしませんか？
速くするなら自分の環境に合わせて設定する必要があるのは当たり前ですが、少なくともマイコミの設定には1回目のペナルティがあると私は考えた訳です。
だから罰ゲームと表現してみたのですがどうでしょう？
もっと言えば、デフォルトなら1回のレンダリングですみますが、この例では3回もレンダリングしなおしています。まして0.48秒以内にダウンロードが終了しないと6回レンダリングしなおしになります。非力なパソコンには罰ゲームだと思いませんか？
次に「content.notify.backoffcount」が「5」の理由を考えてみます。
0秒から0.12秒毎にレンダリングを5回繰り返したら（0.48秒後）、ダウンロードが終わるまでレンダリングのやり直しはありません。
これを画面がちらつかなくていいと評価するなら、むしろ0.12秒後に1回だけレンダリングしてダウンロード完了を待つという設定の方がメリットがあるかもしれません。
どうにも「5」の根拠が分かりません。
逆にサーバが混雑していて通信速度が極端に低下している場合この設定は足枷になります。0.48秒以降ダウンロードがいつまでも完了しないため続きが見えないということが起こり得るわけです。こんな時デフォルトなら制限がないので少しずつでも見えることになります。
これも罰ゲームと表現した理由です。
デフォルトにはそれなりの理由があるのです。
ついでなので「TraceMonkey JavaScriptエンジンを有効にする」というのにも触れておきますと
Firefox 3.5では書いてある通り「javascript.options.jit.content」はデフォルトで「true」です。
「javascript.options.jit.chrome」はまだバグがあって、Firefoxがクラッシュしたりする可能性があるので「false」になってます。
これも各自の環境によりますが
Firefox3.5と3.5.1、SunSpiderでのJavaScriptベンチマーク
contentのみ有効 1000.2ms
chromeも有効 991.0ms
さて、この100分の1秒の違いのためにクラッシュするリスクを背負って速くなったと喜ぶかどうかは、あなた次第……
他にもいろいろ突っ込めるのですけれど、ご覧の通り環境によって変わるものを一々解説したのではたまったものではありませんので、これ以上書くことはないと思います。
最後に一言。
試してみて良かったらその設定を使えばいいじゃない。
何したところでプラシーボだもの。（通信先サーバに左右される的な意味で）
問題の記事は
Firefox高速化テクニック8 | マイコミジャーナル
ページレンダリング高速化
「content.notify.backoffcount」を整数で新規作成して「5」を設定、「nglayout.initialpaint.delay」を整数で新規作成して「0」を設定する。最初の設定はすべてのページをダウンロードし終わる前にレンダリングを開始する指定、後者はページレイアウト情報をすべてダウンロードする前にレンダリングを開始する指定となる。
英語がチンプンカンプンの私でも辞書片手に調べようかって思うくらいの怪しい解説です。
参考にする情報は以下の3つくらいでいいでしょうか。
Content.notify.backoffcount - MozillaZine Knowledge Base
-1
No limit on timer-based reflows (Default)
0
Don't do any timer-based reflows.
Any positive integer
The maximum number of timer-based reflows to perform.
Content.notify.interval - MozillaZine Knowledge Base
The minimum number of microseconds (1 second = 1,000,000 microseconds) between reflows. (Default: 120,000)
Nglayout.initialpaint.delay - MozillaZine Knowledge Base
The number of milliseconds to wait before first displaying the page. (Default: 250)
マイゴミｗは「content.notify.backoffcount」を「ページをダウンロードし終わる前にレンダリングを開始する指定」と書いてますけれど、これだけで間違いだと分かりますね。
ページをダウンロードしてる途中で定期的（0.12秒毎）にレンダリングしなおす回数の上限を設定する項目です。
そして「nglayout.initialpaint.delay」はレンダリングを開始するまでの待ち時間（ミリ秒）になります。
つまりマイコミの設定で速くなったと感じるのはレンダリングの開始が0.25秒（あるいはダウンロード終了）後から0秒になったからです（
ところでこのカスタマイズは適切なんでしょうか？
よく考えて欲しいのは、待ち時間0秒でレンダリングするべき情報があるのかという点です。
実際は二度目（0.12秒後）のレンダリングで表示されてるような気がしませんか？
例えば、Firefox高速化テクニック8 | マイコミジャーナルのhtmlソースを見ると
</head>まで 1,441バイト
html全文が 67,145 バイト
mod_base.cssが 24,080バイト
mod_contents.cssが 52,602バイト
……
私の通信環境はADSL 8Mでだいたい200～700KB/sくらいの速度です。 最初に受け取るであろうパケットではレンダリングするべき情報のない</head>までが精一杯に思えます。
仮に通信速度が300KB/sと仮定します。
大雑把に</head>を受け取るのが0.005秒後、htmlを読込終わるのが0.223秒後になります。
CSSもあるのでこれだけではダメですが、話を簡単にするためこれだけでレンダリングを考えると
1回目（0.00秒後）表示するものなし
2回目（0.12秒後）スクロール後の半ばまでほぼ表示可能
3回目（0.223秒後）読み込み終了後の表示
なるほどデフォルトでは0.223秒後からのレンダリングになりますから0.12秒後にある程度見えてると速くなった気がするというもの。
では「nglayout.initialpaint.delay」を「50」（0.05秒後）にしたらどうでしょう？
1回目（0.05秒後）先頭部分がほぼ表示される
2回目（0.17秒後）スクロール後の半ばまでほぼ表示可能
3回目（0.223秒後）読み込み終了後の表示
このように0.05秒後から見え始めるのでもっと速くなった気がしませんか？
速くするなら自分の環境に合わせて設定する必要があるのは当たり前ですが、少なくともマイコミの設定には1回目のペナルティがあると私は考えた訳です。
だから罰ゲームと表現してみたのですがどうでしょう？
もっと言えば、デフォルトなら1回のレンダリングですみますが、この例では3回もレンダリングしなおしています。まして0.48秒以内にダウンロードが終了しないと6回レンダリングしなおしになります。非力なパソコンには罰ゲームだと思いませんか？
次に「content.notify.backoffcount」が「5」の理由を考えてみます。
0秒から0.12秒毎にレンダリングを5回繰り返したら（0.48秒後）、ダウンロードが終わるまでレンダリングのやり直しはありません。
これを画面がちらつかなくていいと評価するなら、むしろ0.12秒後に1回だけレンダリングしてダウンロード完了を待つという設定の方がメリットがあるかもしれません。
どうにも「5」の根拠が分かりません。
逆にサーバが混雑していて通信速度が極端に低下している場合この設定は足枷になります。0.48秒以降ダウンロードがいつまでも完了しないため続きが見えないということが起こり得るわけです。こんな時デフォルトなら制限がないので少しずつでも見えることになります。
これも罰ゲームと表現した理由です。
デフォルトにはそれなりの理由があるのです。
ついでなので「TraceMonkey JavaScriptエンジンを有効にする」というのにも触れておきますと
Firefox 3.5では書いてある通り「javascript.options.jit.content」はデフォルトで「true」です。
「javascript.options.jit.chrome」はまだバグがあって、Firefoxがクラッシュしたりする可能性があるので「false」になってます。
これも各自の環境によりますが
Firefox3.5と3.5.1、SunSpiderでのJavaScriptベンチマーク
contentのみ有効 1000.2ms
chromeも有効 991.0ms
さて、この100分の1秒の違いのためにクラッシュするリスクを背負って速くなったと喜ぶかどうかは、あなた次第……
他にもいろいろ突っ込めるのですけれど、ご覧の通り環境によって変わるものを一々解説したのではたまったものではありませんので、これ以上書くことはないと思います。
最後に一言。
試してみて良かったらその設定を使えばいいじゃない。
何したところでプラシーボだもの。（通信先サーバに左右される的な意味で）
最近のコメント