Mozilla/Galeon Rendering Speed Tweak Mini-Howto (Dan "OverrideX" McCombs さんの LinuxOrbit における post)
By default Mozilla has a 1200ms delay before it starts rendering. Why? This way it doesn't have to re-render things so many times, instead of having a delay of 0ms where it starts rendering right away, and has to re-render as the page downloads more and things change. In this way it makes the rendering technically faster and easier on your cpu since it doesn't have to do so many passes rendering. Of course this gives you a blank page and a wait during the delay and gives the illusion that things are slower since you have nothing to look at or read. This configuration change will remove the delay, allowing you to read the page as it begins to load, or on a fast connection with small pages, will really make a difference in load time.
確かに劇的に速くなります．もはや欠かせない，とも．
しかし同時に，「速ければそれでよし」という単純なものでないのも事実です．ことは若干複雑．
web ブラウザ上で「リンクをたどる」という一行為は，ユーザからコンピュータへの「命令」です．命令に対しては「返事」 (= この場合は，たどったページを表示する) 以外に，いわゆる「フィードバック 」も重要です．メカニカルな機構でないのに，押すと「ぴっ」と音が鳴るボタン．もはやシャッターはついていないのに「かしゃっ」と音を鳴らすデジカメ．どれもこれもフィードバック．
web ブラウズの場合のフィードバックとは何でしょう．
- リンクをクリックした際の (命令を受け取ったよ，という) フィードバック
- (現在読み込み & レンダリング中であるという状況と経過の表示)
- 表示が完了したという (命令の遂行が終了した，という) フィードバック
web ブラウジングの場合，リンクをクリックすると，多くのブラウザではウィンドウ右上に配置されているステータスアイコンの様なもの．Netscape だと「N」の字の周りを光がくるくる回ったり，Internet Explorer だと「e」の字と地球が回転したりという，あれです．これが 1番目のフィードバック (勿論 2番目も)．
ブラウザがかくかくなりながら必死にコンテンツをサーバから取得し，その都度レンダリングを行う．そして最終的にステータスバーなんかに「完了」と表示する．これが 3番目のフィードバック．
2番目のフィードバックももちろん重要で，「今あなたの命令を実行中ですよ」という意志表示と共に，「あとこれ位かかりますよ．もうすぐ終わりますからね．ちょっと待ってね」という，ユーザのいらいらを緩和させる為の情報提供です．プログレスバーなどで今どの程度まで進んでいるのか (以前から，横断舗道なんかでもよく見掛けますね)，あるいは 1番目のフィードバックもこれに該当する (今読み込み中であることを知らせている) わけですし，あるいはマウスカーソルが砂時計になるという単純なものでさえ，それに貢献します．
人間は過敏な生き物で (というのは言い過ぎですが)，自分が起こしたアクションに対する何らかの反応が 1〜2秒 以内に起こらなければ「なんかおかしい」と思ってしまいます (出典は失念)．これはある意味当り前の事で，例えば人に話しかけたとして，その人がこっちを向いてくれなかったり，「えーっと，それは...」と返事を返し始めるまでに 5秒も間があいてしまうとしたら，恐らく我々は (きっと聴こえなかったのだろうと思って) もう一度話しかけ直すことでしょう．
昔の (Classic) Mac OS Finder での，ファイル/フォルダコピー．大量のファイル/フォルダが含まれたフォルダをコピーするべく，フォルダを別の場所に Drag & Drop した際の動作を覚えておられるでしょうか．Drop 動作が完了した直後，1秒もたたないうちに，最初のプログレスダイアログが表示されていました．「コピーの準備中...」と表示され，コピーするファイル/フォルダ数をカウントするものでした．それが完了するとやっと実際のコピー状況のプログレスダイアログが表示されます．
たったこれだけのことなのに，とても安心してしまうわけです．もし，この最初のプログレスダイアログが表示されなかったとしたら - Drop が終わってから実際のコピーが始まるまでの間，単に数十秒待たされるだけだとしたら - ユーザはいったい何が何やら分からず考えてしまうことでしょう．
ちょっと話が脱線してきました．話を元に戻しましょう．
ともあれ，「待たせる場合も適切なフィードバックを」というのは重要で，そういう工夫や方法論はある程度確立されている (実際に実装されていないことも多いのが事実なのですが) ということです．
逆に，速過ぎる場合はどうでしょう? 余りにレスポンスが速過ぎて，本当に終わったのかどうかも分からない，というような類の．
ブラウザでリンクをたどる例ですと，明らかに表示レイアウトが変わる様なページへと飛ぶ場合は，見たらすぐにリンク先へ来たと分かります．ところが同一サイト内のページを行ったり来たりしている場合には，殆ど同じレイアウトで，ちょっと目を離している間にリンク先へ行っていて，ふと「あれ?」と考えてしまうこともたまにあります．特に，ページのタイトルも全く同じ場合など．
人間は待たされるのも嫌だけど，認識可能な速度を越えて瞬間的に動かれるのもかなわへん，と．
だからと言って，リンク先のページが表示されるまでの間に一瞬凍った様な，がつんと画面が止まった様な瞬間があるのは考えものです．というよりは，速過ぎる為に，ユーザに何らかのフィードバックを与える手段として，それを使うのは間違っている，と．
確かにタブ表示にしていれば，矢印がくるくると回るアニメーションがタブに表示されていますが，これもレンダリングの方に CPU を使いまくるせいか，一瞬止まった様に見えることが多い．
Mozilla の nglayout.initialpaint.delay の初期値が 1,200ms というのは，実はこれを (あえて) 狙っていたのではないか，とも思えて来ます．ぐっ，と画面が凍る様な瞬間を見せることで，「さあ，もう今すぐ目的のページが出てきまっせー」という (意図せざる) 副効果．
web ブラウザに限らず，ほとんどのアプリケーションは，こういった「ユーザにとって心地よい反応時間」とは無関係に，CPU 処理速度に比例した動作をする様に作られています．速いマシンであれば目にも止まらず，遅いマシンであればいらいらする．
フィードバックのタイミングや，フィードバックの種類を，こういうマシンの処理速度とは独立して制御する，という習慣がもっと広がると良いのですけどね．
なんか最後まで纒まりもなく，関係もないことをだらだらと書いてしまいました...
今回の Mozilla Speed Tweak はともあれ嬉しい情報な訳で．とはいえこれの値を 0 なんかにしようもんなら，ネットワークが遅いマシンだと何度も何度もリドローしまくりで CPU 食いまくりになって大変なことになるのでしょうが．
Subscribe to this blog's feed (