アカウント名:
パスワード:
JavaScriptでミリ秒単位の実行速度なんて開発者の自己満足だろ・・・。
決して開発者の自己満足ではないと思います。自分の考えでは、今までが遅すぎたのであって、今の速度競争は決して速度偏重に陥っているとは思いません。自分も過去のブラウザ乗り換え履歴を思い返してきたのですが、ネスケ4に機能不足を感じつつも使っていたのはIE4の起動が遅すぎたからでしたし、逆にIE5で起動が高速化されてからはネスケを起動することはなくなりました。Operaも「世界一高速」を謳っていたころに一時期使っていましたし、今から思えば、DountLに乗り換えた時も最初の頃はタブブラウザよりも起動の軽さに魅力を感じていました。同じことはFireFoxでもいえることで、最初は遅くなるのが怖くてプラグインは入れなくなりましたし、ばりばり使うようになってもプラグインの自動更新は常々じゃまだと思っているところにChromeが登場。で、今はChromeを使っていて、FireFoxはプラグインが必要な時をのぞき滅多に起動しなくなりました。ちなみにSafariもかなり高速で一時常用していましたが、やはりレンダリング速度はChromeが最速に感じます。
ミリ秒単位の速度差が無意味だとおっしゃる人は多くいますが、そもそも全てのWebページ、全てのPCでミリ秒の差しかないわけじゃありません。測定環境の半分の性能のPCなら2倍遅いですし、測定ベンチの10倍重いページなら10倍の差が出るわけです。で、JavaScriptはともかくレンダリングが重いページはいくらでもあります。さらに自分の用に、毎日タブでまとめて開くブックマークが18個ある(スラド含)場合、速度差が積み重なるので18個開ききるまでの差は相当のものになります。Chromeが当然のごとく18個をスムーズに開いていくのをみていると正直FireFoxやIEを常用する気にはなれません。(あくまで自分個人の感想です)
言うまでもないことですが、なら毎日開くお気に入りを減らせ、という意見はPC性能(今回はブラウザ性能)が不足しているから妥協する、ということに過ぎませんよ?(ちなみにRSSは登録サイトが増えるとウザすぎるので使わなくなりました)
で、速度が速くなるとキーワードを検索し直すのも画像を見るためだけにタブを同時に30個開くのも苦にならないわけで、必然的にプラグインの必要性も低くなります。今までFireFoxでやたらプラグインを導入してたのも速度が遅いのをカバーするためだったような気さえしています。
Vistaが(実際に使っているとそれほどでもないにもかかわらず)世間でやたら遅いと酷評されているのも、IE7が遅すぎたからじゃないかという説もあるほどです。(実際IE6よりも7はページレンダリング速度とスクロール速度がかなり落ちているように自分は感じていました)「OS==ブラウザ」である人たちにとってみれば「 if ( IE7.速度 == 遅い ) ブログ.Write( "Vista遅い" ); 」になってしまう可能性は十分あるかと。その反省かIE8はIE7に比べれば明らかに高速化されていると思います。記事はJavaScriptベンチですがレンダリングならFireFoxとの差はかなり薄まっている印象です。
同時に、ブラウザ開発者でなくWebページ開発者にとってみれば、ミリ秒も差があるというのは相当な違いになることもあるかと思います。ミリ秒の差といっても絶対値ではなく比率であることを忘れてはなりません。記事の例に限って述べるのであれば、おおざっぱに言ってマイナーブラウザは人気ブラウザの5倍程度の速度を実現していることになると思われますが、表示に5秒かかるから実装は見送りになってしまったが、もし1秒だったら実装できた、というサイト機能があってもおかしくありませんし、記事では Core2 E6400 を使っていますが、もしこれが Atom なら上記の数倍の速度差がある、ということも忘れてはなりません。
長文失礼しました。ブラウザ速度至上主義者(ある程度以上のレンダリング互換性があるならば)の1人としてこれだけはいわせて頂かなくてはなりませんでした。絶滅間近の種族であるブラウザ速度至上主義者の生き残りの遠吠えに過ぎませんので皆様あまり気になされずに。
なんか盛り上がっちゃってますが...
「JavaScriptでミリ秒単位の実行速度」があなたの気にしている「起動」だの「レンダリング」だのの体感速度にどのくらいの影響があるのでしょうか?
性能向上ってのは計測に基づき問題視されている部分に対して支配的な部分に手当てするのがセオリーであって、ほとんど影響を及ぼさないところにこだわってコストかけるのは正に「開発者の自己満足」と揶揄されても仕方ないでしょ。
そのあたりを明確にせずに長いコメント書いてもねぇ。
「絶対値ではなく比率だ」とぶち上げてますが、その前に問題区間に対しての割合を明らかにするべきでしょう。
例えば最初の描画完了までにかかるCPU処理時間が10ms短縮されたとして、それと並行して走っているNICからのデータ取り込み処理や、GPUでの描画処理、データ転送のDMAなどが律速要因であれば、まったく効果が無いわけですが。
また、5倍遅いPCでそれが50msになったとしても、数秒の中で一度だけ走る処理であればその差は体感影響にはつながらないですし。
もちろん、数百倍遅いPCであればその差は体感できると思いますが、それだけ遅いPCでは今回俎板にあがっている今時のブラウザでそもそも実用速度が出る気がしないのですが...
というわけで、「ブラウザ速度至上主義者」という割には「速度」に対して見識があるように見えず、元の指摘に対して的外れなコメントに見えます。実用評価に目もくれず、カタログスペックの○×に一喜一憂しているマニアさんのようですね :-)
はい。すくなくとも現在においてほとんどのWebサイトではその通りの結果になると思います。ボトルネックはHTMLとCSS処理です。サーバーが十分高速な場合はネットワーク速度の影響はあまり関係ないです。
ちなみに同じネットワーク速度でもWindowsMobileやゲーム機など非PC系の環境ではかなり遅く、レンダリング処理速度の重要性がわかりますが、まあ、自分のWindowsMobileの性能は Pentium 300MHz 程度という結果でさすがにPC環境とは差がありすぎるので別のお話です。
ちなみに純粋な描画処理による影響は(計測したことはありませんが)ほとんど無視できるレベルだと思っています。こちらは計測したわけではないので正確な根拠はありませんが、描画アクセラレーションがほぼ消えるVirtualPC上でブラウザを使っていても速度差を全く感じないので。VirtualPCではゲームなどは古いゲームでもあからさまに遅さを感じますから、純粋な描画処理の負担は数年前のゲーム以下であり問題ではないのだと思います。
もし描画処理でネックがあるとしたらむしろフォントレンダリングの速度ではないでしょうか。Wikipediaって意外と重いように思うので。
で、JavaScriptの実行速度はレンダリング速度にも影響を与えるわけですが、この処理が与える影響はブラウザゲームでもない限り、レンダリング完了までの体感速度に与える影響は、HTMLやCSSの処理速度に比べて小さく、まさにご指摘の通りです。はっきり言って現在のほとんどのWebサイトでは、HTMLやCSSの処理速度の方がよほど重要であると思います。
たとえば Yahoo トップを HTML のみで読み込んだ場合、自分の環境では通信を含めても200ミリ秒程度で処理が終わります。HTMLのみをRAMドライブにおいて読み込むと180ミリ秒程度で、ネットワークによる遅さは20ミリ秒程度であることがわかります。YahooにPINGしても10ミリ秒以下で返ってくるのでまあそれほど不思議な値じゃないと思います。逆に言えばほとんどの時間はHTMLレンダリングにとられていることがわかると思います。
同様にして画像やCSSやJavaScriptを調査していくと、処理時間の大きさは、HTMLの解析、次にJavaScript、次にCSSの処理です。CSSが70ミリ秒、JavaScriptが100ミリ秒かかっており、JavaScriptの影響は想像以上です。しかもコレはスクリプト処理が高速な Safari での結果で、スクリプト処理が遅いブラウザの場合にはさらに影響が大きくなります。一見それほどJavaScriptを使っているように見えないYahooでもこれだけの影響があります。実際にJavaScriptをオフにしてみると、アイコンやその他部分部分で差が出る程度で、その程度にしかJavaScriptは使われてないにもかかわらずです。
と、ここまで言っておいて逆説的ですが、現状では実際にはCSSの影響の方が大きいのが事実です。というのも、HTMLとCSSの解釈が終わらなければ画面表示が十分に始まらないからです。むしろHTMLとCSSの解釈が終わってしまうと、以後のスクリプト処理+画像ロード+その他の描画(フラッシュ等)、などはある程度平行して行えてしまうので、体感速度という意味ではHTMLとCSSの処理速度の方がよほど重要である、というのが間違いのない事実です。
ミリ秒単位でデータがダウンロードされてくることからもわかるように、通常のWebページであればネットワーク速度はもはやボトルネックとしては優先度が低くなっています。サーバー側の性能が不足している場合などはその限りではありませんが、ネットワークが遅いからブラウザを高速化しても無意味だという指摘は当たりません。光回線で得られる速度はもはや昔のディスクに匹敵するレベルにきています。(レイテンシとか安定性とかはともかくデータ転送だけなら)
ちなみに高速ブラウザではHTMLやCSSの処理もかなり高速化されており、決してJavaScriptだけが速いわけではありません。
自分が不満に思うのはJavaScriptベンチマークのたびに発言される「JavaScriptなんか速くなったって意味なくない?」という発言で、なぜJavaScriptが高速に処理できることを歓迎したり、それによってもたらされる新たな可能性を見いだせないのかという点です。ブラウザを単なる文書ビューアー以上にたらしめている最たる技術がJavaScriptであるはずなのに、なぜそれが遅いことが容認されるのか。ハードウェア系のベンチマークなら明らかに速いと賞賛されるだけの差があるのにスルーされていくのがとても不思議です。
同時に、タレコミ記事のようなベンチマークでは繰り返し回数を増やすなどしてより有意な差のつくベンチマーク手法でやってほしかったなとは思います。
と、ここまで言っておいて逆説的ですが、現状では実際にはCSSの影響の方が大きいのが事実です。 というのも、HTMLとCSSの解釈が終わらなければ画面表示が十分に始まらないからです。 むしろHTMLとCSSの解釈が終わってしまうと、以後のスクリプト処理+画像ロード+その他の描画(フラッシュ等)、などはある程度平行して行えてしまうので、 体感速度という意味ではHTMLとCSSの処理速度の方がよほど重要である、というのが間違いのない事実です。
そこで投機的解釈 [srad.jp]ですよ。
起動時間なんて、起動時の一回だけの話なのに・・・ブラウザって、そんなに繰り返し再起動するようなもんなの?一回起動してしまえば、そのまま常駐させない?
Macだと通常はウィンドウ全部閉じてもアプリ本体は残るから気にならないだけなのかな。
IEしか動かないサイトのために時々IEを立ち上げるんだけど起動遅くてイライラするなぁ。ブラウザはほぼ毎日開くものなのでOSの起動時間と同じくらい早さは重要に思います
少なくともブラウザによって体感レベルの差は出ます。あとFireFoxって1つのタブで読み込みが遅くなるとそれ以降のタブまで止まるんですよ。なのでFireFoxをメインにしていた頃はブックマ-クの並び順を変えて、軽いペ-ジから順番に開くようにしていました。
>それは本当にレンダリングの問題なのかな。
どこまで並列処理出来てるかって話だと思う。
IEは知らんけどFirefoxの場合、例えばクソ重いフラッシュがあると他のタブの処理が止まったりするし。ニコ動のプレイヤーとか。これが多分プロセスで動いていると、他のタブ(他のプロセス)を止めるような事はないと思う。
止まらないなら、ディスクI/O、ネットワークI/Oなどに無駄な空きができる事も少なくなるだろう。
わたしも速さを重視したのですが、Google Chrome はしばらく使って Firefox に戻りました。広告サーバってしょぼいのが多くて、そこがボトルネックになっちゃうページの多いこと多いこと。Adblock で主要な広告サーバはじくのに慣れてると Chrome なんて遅くて使い物になりません ;-p
# Adblock の是非や広告収入に頼ったビジネスモデルについてはまた別の問題。
決して開発者の自己満足ではないと思います。自分の考えでは、今までが遅すぎたのであって、今の速度競争は決して速度偏重に陥っているとは思いません。
何回もDBクエリを叩いても1秒もせず重量級CMSの出力を返してくるPHPのようなLLと比較した場合、ブラウザ上で実行されるJSは遅く感じますよね。(stdoutに出すサーバーサイド言語と、場合によってはGUIをグリグリ動かすJSでは比較対象として適当かどうかわかりませんが)しかしそれ(LL)を目にして、PHPを書くようになった今も、名だたるJSライブラリのでかさには一瞬、これどのくらい実行にかかるだろうかと思って躊躇し、「汎用性はいいから自分で書こうっと」と思ってしまう...
ミリ秒単位で画面上のオブジェクトを動かしたりするときは多少差が出ますが、 テキスト処理関連で困ることはだいぶ減ったように思います。 ただしIEはこんな感じのコードでボタンを連打しても反応がすごく遅い問題がずーっと直らないです。
<html><head><script type="text/javascript">var count = 1;var countUp = function() { document.getElementById('output').firstChild.nodeValue = count; count += 1;};</script></head><body><input type="button" value="count" onclick="javascript:countUp();" /><div id="output">0</div></body></html>
> ボタンを連打しても反応がすごく遅い問題がずーっと直らないです。
これは、「ボタンを連打する」と「ダブルクリック」になってしまうからでしょう。
IEのボタンは、ダブルクリックに反応しないFirefoxのボタンは、ダブルクリックにも反応する
ということで、反応が遅いわけではないと。
<input type="button" value="count" onclick="javascript:countUp();" />
に
ondblclick="javascript:countUp();"
を追加すれば良いってだけの話でしたな
IEに関してはそれで問題を回避できますね。 でもそれだけだとIE以外のブラウザがダメなので、 IEとそれ以外でコードを分岐する必要があります。 とりあえずこんな感じでしょうか。 addEventListnerとAttachEventの有無でブラウザ判定しています。
<html><head><script type="text/javascript">var count = 1; var countUp = function() { document.getElementById('output').firstChild.nodeValue = count; count += 1;}; var setButtonAction = function() { var btn = document.getElementById('myBtn'); // mozilla, webkit, opera if (window.addEventListener) { btn.addEventListener('click', countUp, false); } // ie else if (window.attachEvent) { btn.attachEvent('onclick', countUp); btn.attachEvent('ondblclick', countUp); }}; if (window.addEventListener) { window.addEventListener('load', setButtonAction, false);}else if (window.attachEvent) { window.attachEvent('onload', setButtonAction);}</script></head><body><input id="myBtn" type="button" value="count" /><div id="output">0</div></body></html>
技術の無い奴が悪評を流布するからですね
この件は、ブラウザの仕様(バグ?)であって、 直接的な処理速度の話ではないですね。 でも、JavaScriptが速ければ無駄な処理が増えても遅延が顕在化しない、 ということはあると思います。
せっかくなので私なりの意見を書いておくと、 JavaScriptの高速化のおかげで、 ミリ秒単位のコーディングがしやすくなりました。 これは開発者の自己満足ではなくて、 JavaScriptの可能性が大きくなっているのだと思います。 FlashでやっていたようなエフェクトがJavaScriptでもなめらかに動かせるし、 JavaScriptは速ければ速いほどいいです。 でも、JavaScriptの処理速度がブラウザの謳い文句になるほど、 エンドユーザに対して訴求力のある話ではないかもしれません。 あくまでも縁の下の進化というか。
なるほど、そういう理由でしたか。
一応付け加えさせていただくと、 Firefoxだけではなく、Mozilla系とWebkit系とOpera (つまりIE以外のほとんどのブラウザ)は連打できます。 IEはonmousedownなども連打もできません。
おおよそ、30msが時間感覚の分解能だと聞いています。(時間順序判断分解能・こっちの方が早かったと判り始める速度)なので、1~2msの速度に血道を上げるのは開発者の自己満足ですが、30msを超える速度アップは我々にも恩恵があるかと。(1msの高速化x30を繰り返すことで、体感速度が上がっていく)
# もちろん、フル・アニメーション(42ms)とリミテッド・アニメーション(125ms)の差が表現力の差でないことは、日本人であれば誰しも理解していることではありますが:p
ブラウザと不可分な形で開発するのはいろいろとデメリットがある気がするんですが。JavaScriptに「俺仕様」が多かったのもそのあたりに起因しているのでは。
プラグイン式にして、早いエンジンとか機能拡張したエンジンとか選べるようにするとかどうですかね。
# WebKitが紹介されているのでIEもそうなってますよ。JavaScript(JScript)のほかにVBScriptが用意されていて、interfaceも公開されてます。ActivePerlを使っている人は知ってると思うけど、ActivePerlをインストールするとPerlScript [activestate.com]も書けますよ。IE8でもまだ遅いと言われますが、script interfaceとDOM interfaceの両方を維持しながらよくやった方なのでは。
Firefoxの詳しい事情は知りませんが、JavaScriptエンジンを切り替える話が出ているところから推測するに切り離し可能なのでは。
ミリ秒単位って、実はものすごく大きいんだよね。
ゲームを思い出してみると分かりやすいと思う。秒間60コマだとスムーズに見えるけど、秒間30コマだと動きがガタついて見えると思う。でもこれって、時間でいえば約17ミリ秒の差なんだよね。
10ミリ秒以上も違えば人間にとって十分に認識できる体感差となって表れるレベル。こんなデカい数字を小さいと思ってたら、スムーズな描画や動作は追求できないよ。
回線速度やサーバーの込み具合でどーとでも変わってしまうから大した問題でもないんだよねでもあえてゲーム的に言うならば実速度ではなく体感速度が上ならば快適に感じるだろうね
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
開発者の自己満足 (スコア:0)
JavaScriptでミリ秒単位の実行速度なんて開発者の自己満足だろ・・・。
ブラウザに求めることは1が正確なレンダリングで2が速度、34がなくて5がオマケ機能。 (スコア:3, 興味深い)
決して開発者の自己満足ではないと思います。自分の考えでは、今までが遅すぎたのであって、今の速度競争は決して速度偏重に陥っているとは思いません。
自分も過去のブラウザ乗り換え履歴を思い返してきたのですが、ネスケ4に機能不足を感じつつも使っていたのはIE4の起動が遅すぎたからでしたし、
逆にIE5で起動が高速化されてからはネスケを起動することはなくなりました。Operaも「世界一高速」を謳っていたころに一時期使っていましたし、
今から思えば、DountLに乗り換えた時も最初の頃はタブブラウザよりも起動の軽さに魅力を感じていました。
同じことはFireFoxでもいえることで、最初は遅くなるのが怖くてプラグインは入れなくなりましたし、ばりばり使うようになってもプラグインの自動更新は常々じゃまだと思っているところにChromeが登場。
で、今はChromeを使っていて、FireFoxはプラグインが必要な時をのぞき滅多に起動しなくなりました。
ちなみにSafariもかなり高速で一時常用していましたが、やはりレンダリング速度はChromeが最速に感じます。
ミリ秒単位の速度差が無意味だとおっしゃる人は多くいますが、そもそも全てのWebページ、全てのPCでミリ秒の差しかないわけじゃありません。
測定環境の半分の性能のPCなら2倍遅いですし、測定ベンチの10倍重いページなら10倍の差が出るわけです。で、JavaScriptはともかくレンダリングが重いページはいくらでもあります。
さらに自分の用に、毎日タブでまとめて開くブックマークが18個ある(スラド含)場合、速度差が積み重なるので18個開ききるまでの差は相当のものになります。
Chromeが当然のごとく18個をスムーズに開いていくのをみていると正直FireFoxやIEを常用する気にはなれません。(あくまで自分個人の感想です)
言うまでもないことですが、なら毎日開くお気に入りを減らせ、という意見はPC性能(今回はブラウザ性能)が不足しているから妥協する、ということに過ぎませんよ?
(ちなみにRSSは登録サイトが増えるとウザすぎるので使わなくなりました)
で、速度が速くなるとキーワードを検索し直すのも画像を見るためだけにタブを同時に30個開くのも苦にならないわけで、必然的にプラグインの必要性も低くなります。
今までFireFoxでやたらプラグインを導入してたのも速度が遅いのをカバーするためだったような気さえしています。
Vistaが(実際に使っているとそれほどでもないにもかかわらず)世間でやたら遅いと酷評されているのも、IE7が遅すぎたからじゃないかという説もあるほどです。
(実際IE6よりも7はページレンダリング速度とスクロール速度がかなり落ちているように自分は感じていました)
「OS==ブラウザ」である人たちにとってみれば「 if ( IE7.速度 == 遅い ) ブログ.Write( "Vista遅い" ); 」になってしまう可能性は十分あるかと。
その反省かIE8はIE7に比べれば明らかに高速化されていると思います。記事はJavaScriptベンチですがレンダリングならFireFoxとの差はかなり薄まっている印象です。
同時に、ブラウザ開発者でなくWebページ開発者にとってみれば、ミリ秒も差があるというのは相当な違いになることもあるかと思います。ミリ秒の差といっても絶対値ではなく比率であることを忘れてはなりません。
記事の例に限って述べるのであれば、おおざっぱに言ってマイナーブラウザは人気ブラウザの5倍程度の速度を実現していることになると思われますが、
表示に5秒かかるから実装は見送りになってしまったが、もし1秒だったら実装できた、というサイト機能があってもおかしくありませんし、
記事では Core2 E6400 を使っていますが、もしこれが Atom なら上記の数倍の速度差がある、ということも忘れてはなりません。
長文失礼しました。
ブラウザ速度至上主義者(ある程度以上のレンダリング互換性があるならば)の1人としてこれだけはいわせて頂かなくてはなりませんでした。
絶滅間近の種族であるブラウザ速度至上主義者の生き残りの遠吠えに過ぎませんので皆様あまり気になされずに。
Re:ブラウザに求めることは1が正確なレンダリングで2が速度、34がなくて5がオマケ機能。 (スコア:1, 興味深い)
なんか盛り上がっちゃってますが...
「JavaScriptでミリ秒単位の実行速度」があなたの気にしている
「起動」だの「レンダリング」だのの体感速度に
どのくらいの影響があるのでしょうか?
性能向上ってのは計測に基づき問題視されている部分に対して
支配的な部分に手当てするのがセオリーであって、
ほとんど影響を及ぼさないところにこだわってコストかけるのは
正に「開発者の自己満足」と揶揄されても仕方ないでしょ。
そのあたりを明確にせずに長いコメント書いてもねぇ。
「絶対値ではなく比率だ」とぶち上げてますが、その前に
問題区間に対しての割合を明らかにするべきでしょう。
例えば最初の描画完了までにかかるCPU処理時間が10ms短縮されたとして、
それと並行して走っているNICからのデータ取り込み処理や、
GPUでの描画処理、データ転送のDMAなどが律速要因であれば、
まったく効果が無いわけですが。
また、5倍遅いPCでそれが50msになったとしても、
数秒の中で一度だけ走る処理であればその差は体感影響にはつながらないですし。
もちろん、数百倍遅いPCであればその差は体感できると思いますが、
それだけ遅いPCでは今回俎板にあがっている今時のブラウザで
そもそも実用速度が出る気がしないのですが...
というわけで、「ブラウザ速度至上主義者」という割には「速度」に対して
見識があるように見えず、元の指摘に対して的外れなコメントに見えます。
実用評価に目もくれず、カタログスペックの○×に一喜一憂している
マニアさんのようですね :-)
Re:ブラウザに求めることは1が正確なレンダリングで2が速度、34がなくて5がオマケ機能。 (スコア:2)
はい。すくなくとも現在においてほとんどのWebサイトではその通りの結果になると思います。ボトルネックはHTMLとCSS処理です。
サーバーが十分高速な場合はネットワーク速度の影響はあまり関係ないです。
ちなみに同じネットワーク速度でもWindowsMobileやゲーム機など非PC系の環境ではかなり遅く、レンダリング処理速度の重要性がわかりますが、
まあ、自分のWindowsMobileの性能は Pentium 300MHz 程度という結果でさすがにPC環境とは差がありすぎるので別のお話です。
ちなみに純粋な描画処理による影響は(計測したことはありませんが)ほとんど無視できるレベルだと思っています。
こちらは計測したわけではないので正確な根拠はありませんが、描画アクセラレーションがほぼ消えるVirtualPC上でブラウザを使っていても速度差を全く感じないので。
VirtualPCではゲームなどは古いゲームでもあからさまに遅さを感じますから、純粋な描画処理の負担は数年前のゲーム以下であり問題ではないのだと思います。
もし描画処理でネックがあるとしたらむしろフォントレンダリングの速度ではないでしょうか。Wikipediaって意外と重いように思うので。
で、JavaScriptの実行速度はレンダリング速度にも影響を与えるわけですが、この処理が与える影響はブラウザゲームでもない限り、
レンダリング完了までの体感速度に与える影響は、HTMLやCSSの処理速度に比べて小さく、まさにご指摘の通りです。
はっきり言って現在のほとんどのWebサイトでは、HTMLやCSSの処理速度の方がよほど重要であると思います。
たとえば Yahoo トップを HTML のみで読み込んだ場合、自分の環境では通信を含めても200ミリ秒程度で処理が終わります。
HTMLのみをRAMドライブにおいて読み込むと180ミリ秒程度で、ネットワークによる遅さは20ミリ秒程度であることがわかります。
YahooにPINGしても10ミリ秒以下で返ってくるのでまあそれほど不思議な値じゃないと思います。
逆に言えばほとんどの時間はHTMLレンダリングにとられていることがわかると思います。
同様にして画像やCSSやJavaScriptを調査していくと、処理時間の大きさは、HTMLの解析、次にJavaScript、次にCSSの処理です。
CSSが70ミリ秒、JavaScriptが100ミリ秒かかっており、JavaScriptの影響は想像以上です。
しかもコレはスクリプト処理が高速な Safari での結果で、スクリプト処理が遅いブラウザの場合にはさらに影響が大きくなります。
一見それほどJavaScriptを使っているように見えないYahooでもこれだけの影響があります。
実際にJavaScriptをオフにしてみると、アイコンやその他部分部分で差が出る程度で、その程度にしかJavaScriptは使われてないにもかかわらずです。
と、ここまで言っておいて逆説的ですが、現状では実際にはCSSの影響の方が大きいのが事実です。
というのも、HTMLとCSSの解釈が終わらなければ画面表示が十分に始まらないからです。
むしろHTMLとCSSの解釈が終わってしまうと、以後のスクリプト処理+画像ロード+その他の描画(フラッシュ等)、などはある程度平行して行えてしまうので、
体感速度という意味ではHTMLとCSSの処理速度の方がよほど重要である、というのが間違いのない事実です。
ミリ秒単位でデータがダウンロードされてくることからもわかるように、通常のWebページであればネットワーク速度はもはやボトルネックとしては優先度が低くなっています。
サーバー側の性能が不足している場合などはその限りではありませんが、ネットワークが遅いからブラウザを高速化しても無意味だという指摘は当たりません。
光回線で得られる速度はもはや昔のディスクに匹敵するレベルにきています。(レイテンシとか安定性とかはともかくデータ転送だけなら)
ちなみに高速ブラウザではHTMLやCSSの処理もかなり高速化されており、決してJavaScriptだけが速いわけではありません。
自分が不満に思うのはJavaScriptベンチマークのたびに発言される「JavaScriptなんか速くなったって意味なくない?」という発言で、
なぜJavaScriptが高速に処理できることを歓迎したり、それによってもたらされる新たな可能性を見いだせないのかという点です。
ブラウザを単なる文書ビューアー以上にたらしめている最たる技術がJavaScriptであるはずなのに、なぜそれが遅いことが容認されるのか。
ハードウェア系のベンチマークなら明らかに速いと賞賛されるだけの差があるのにスルーされていくのがとても不思議です。
同時に、タレコミ記事のようなベンチマークでは繰り返し回数を増やすなどしてより有意な差のつくベンチマーク手法でやってほしかったなとは思います。
Re: (スコア:0)
遅さを感じるのはブラウザよりもWebサイトの構成。
糞重たいFLASH広告を表示してからやっと本文を読み込むようなサイト。
未だにPHSの通信カードを使う場合がありますが、本文が表示されるまではイライラしますね。
Re: (スコア:0)
そこで投機的解釈 [srad.jp]ですよ。
Re: (スコア:0)
起動時間なんて、起動時の一回だけの話なのに・・・
ブラウザって、そんなに繰り返し再起動するようなもんなの?
一回起動してしまえば、そのまま常駐させない?
Macだと通常はウィンドウ全部閉じてもアプリ本体は残るから気にならないだけなのかな。
Re:ブラウザに求めることは1が正確なレンダリングで2が速度、34がなくて5がオマケ機能。 (スコア:1)
IEしか動かないサイトのために時々IEを立ち上げるんだけど起動遅くてイライラするなぁ。
ブラウザはほぼ毎日開くものなのでOSの起動時間と同じくらい早さは重要に思います
Re: (スコア:0)
> Chromeが当然のごとく18個をスムーズに開いていくのをみていると正直FireFoxやIEを常用する気にはなれません。(あくまで自分個人の感想です)
それは本当にレンダリングの問題なのかな。
サーバやネットワークへの負荷を考慮して、TCPコネクションの数を少なく自制していて、それで待たされているんじゃない?
Re:ブラウザに求めることは1が正確なレンダリングで2が速度、34がなくて5がオマケ機能。 (スコア:1)
少なくともブラウザによって体感レベルの差は出ます。あとFireFoxって1つのタブで読み込みが遅くなるとそれ以降のタブまで止まるんですよ。
なのでFireFoxをメインにしていた頃はブックマ-クの並び順を変えて、軽いペ-ジから順番に開くようにしていました。
Re: (スコア:0)
>それは本当にレンダリングの問題なのかな。
どこまで並列処理出来てるかって話だと思う。
IEは知らんけどFirefoxの場合、例えばクソ重いフラッシュがあると他のタブの処理が止まったりするし。ニコ動のプレイヤーとか。これが多分プロセスで動いていると、他のタブ(他のプロセス)を止めるような事はないと思う。
止まらないなら、ディスクI/O、ネットワークI/Oなどに無駄な空きができる事も少なくなるだろう。
Re: (スコア:0)
わたしも速さを重視したのですが、Google Chrome はしばらく使って Firefox に戻りました。
広告サーバってしょぼいのが多くて、そこがボトルネックになっちゃうページの多いこと多いこと。
Adblock で主要な広告サーバはじくのに慣れてると Chrome なんて遅くて使い物になりません ;-p
# Adblock の是非や広告収入に頼ったビジネスモデルについてはまた別の問題。
Re: (スコア:0)
決して開発者の自己満足ではないと思います。自分の考えでは、今までが遅すぎたのであって、今の速度競争は決して速度偏重に陥っているとは思いません。
何回もDBクエリを叩いても1秒もせず重量級CMSの出力を返してくるPHPのようなLLと比較した場合、ブラウザ上で実行されるJSは遅く感じますよね。(stdoutに出すサーバーサイド言語と、場合によってはGUIをグリグリ動かすJSでは比較対象として適当かどうかわかりませんが)
しかしそれ(LL)を目にして、PHPを書くようになった今も、名だたるJSライブラリのでかさには一瞬、これどのくらい実行にかかるだろうかと思って躊躇し、「汎用性はいいから自分で書こうっと」と思ってしまう...
Re:開発者の自己満足 (スコア:2, すばらしい洞察)
Re:開発者の自己満足 (スコア:1)
ミリ秒単位で画面上のオブジェクトを動かしたりするときは多少差が出ますが、
テキスト処理関連で困ることはだいぶ減ったように思います。
ただしIEはこんな感じのコードでボタンを連打しても反応がすごく遅い問題がずーっと直らないです。
Re:開発者の自己満足 (スコア:3, 参考になる)
> ボタンを連打しても反応がすごく遅い問題がずーっと直らないです。
これは、「ボタンを連打する」と「ダブルクリック」になってしまうからでしょう。
IEのボタンは、ダブルクリックに反応しない
Firefoxのボタンは、ダブルクリックにも反応する
ということで、反応が遅いわけではないと。
Re: (スコア:0)
に
を追加すれば良いってだけの話でしたな
Re:開発者の自己満足 (スコア:1)
IEに関してはそれで問題を回避できますね。
でもそれだけだとIE以外のブラウザがダメなので、
IEとそれ以外でコードを分岐する必要があります。
とりあえずこんな感じでしょうか。
addEventListnerとAttachEventの有無でブラウザ判定しています。
Re: (スコア:0)
javascriptのコードがなんで重くなって、
ms レベルでの速度改善を求められる理由が、
よくわかる話ですね。
Re: (スコア:0)
技術の無い奴が悪評を流布するからですね
Re:開発者の自己満足 (スコア:2, 興味深い)
この件は、ブラウザの仕様(バグ?)であって、
直接的な処理速度の話ではないですね。
でも、JavaScriptが速ければ無駄な処理が増えても遅延が顕在化しない、
ということはあると思います。
せっかくなので私なりの意見を書いておくと、
JavaScriptの高速化のおかげで、
ミリ秒単位のコーディングがしやすくなりました。
これは開発者の自己満足ではなくて、
JavaScriptの可能性が大きくなっているのだと思います。
FlashでやっていたようなエフェクトがJavaScriptでもなめらかに動かせるし、
JavaScriptは速ければ速いほどいいです。
でも、JavaScriptの処理速度がブラウザの謳い文句になるほど、
エンドユーザに対して訴求力のある話ではないかもしれません。
あくまでも縁の下の進化というか。
Re: (スコア:0)
なるほど、そういう理由でしたか。
一応付け加えさせていただくと、
Firefoxだけではなく、Mozilla系とWebkit系とOpera
(つまりIE以外のほとんどのブラウザ)は連打できます。
IEはonmousedownなども連打もできません。
Re:開発者の自己満足 (スコア:1)
おおよそ、30msが時間感覚の分解能だと聞いています。(時間順序判断分解能・こっちの方が早かったと判り始める速度)
なので、1~2msの速度に血道を上げるのは開発者の自己満足ですが、30msを超える速度アップは我々にも恩恵があるかと。
(1msの高速化x30を繰り返すことで、体感速度が上がっていく)
# もちろん、フル・アニメーション(42ms)とリミテッド・アニメーション(125ms)の差が表現力の差でないことは、日本人であれば誰しも理解していることではありますが:p
JavaScriptの部分だけ別にできないの? (スコア:0)
ブラウザと不可分な形で開発するのはいろいろとデメリットがある気がするんですが。
JavaScriptに「俺仕様」が多かったのもそのあたりに起因しているのでは。
プラグイン式にして、早いエンジンとか機能拡張したエンジンとか選べるようにするとかどうですかね。
Re:JavaScriptの部分だけ別にできないの? (スコア:2, 興味深い)
ブラウザ実行中に自由に切り替えたいということでしたら、それは実現できていませんけど。
Re:JavaScriptの部分だけ別にできないの? (スコア:1, 参考になる)
IEでは、ブラウザとスクリプトは分離されています。
フレームワークの名称がActive scriptingで、スクリプト言語のホスト(実行環境)として、
WebブラウザやWebサーバやWindows OSを選択できます。
スクリプト言語として、VBScriptやJScript(JavaScript)、PerlやPythonなどが選択できます。
http://ja.wikipedia.org/wiki/ActiveX_Scripting
JScriptのエンジンを(MSのものとV8とみたいに)2つインストールして、両者を選択できるのかは知りません。
Re:JavaScriptの部分だけ別にできないの? (スコア:1)
# WebKitが紹介されているので
IEもそうなってますよ。JavaScript(JScript)のほかにVBScriptが用意されていて、interfaceも公開されてます。
ActivePerlを使っている人は知ってると思うけど、ActivePerlをインストールするとPerlScript [activestate.com]も書けますよ。
IE8でもまだ遅いと言われますが、script interfaceとDOM interfaceの両方を維持しながらよくやった方なのでは。
Firefoxの詳しい事情は知りませんが、JavaScriptエンジンを切り替える話が出ているところから推測するに切り離し可能なのでは。
Re: (スコア:0)
ミリ秒単位って、実はものすごく大きいんだよね。
ゲームを思い出してみると分かりやすいと思う。
秒間60コマだとスムーズに見えるけど、秒間30コマだと動きがガタついて見えると思う。
でもこれって、時間でいえば約17ミリ秒の差なんだよね。
10ミリ秒以上も違えば人間にとって十分に認識できる体感差となって表れるレベル。
こんなデカい数字を小さいと思ってたら、スムーズな描画や動作は追求できないよ。
Re:開発者の自己満足 (スコア:2)
全体の処理が秒単位のときに 100ms 違っても問題になりにくい気はします
あと今の液晶ディスプレイだとそれこそフレーム単位で遅延が入りますが
気にしてるのは一部のアクションゲーマーだけのような
Re: (スコア:0)
回線速度やサーバーの込み具合でどーとでも変わってしまうから
大した問題でもないんだよね
でもあえてゲーム的に言うならば
実速度ではなく体感速度が上ならば快適に感じるだろうね