パスワードを忘れた? アカウント作成
98774 story
インターネット

人気が出れば出るほど、Webブラウザは遅くなる 107

ストーリー by mtakahas
てことは遅くなればなるほど人気が出る……わけないですね 部門より

pinbou 曰く、

本家/.の記事(Slashdot | The More Popular the Browser, the Slower It Is)より。Webブラウザの速度ベンチマークPeacekeeperの集計結果によると、人気のあるブラウザはそうでないものに比べてパフォーマンスが劣るという結果が出た。

IEが遅いというのは予想の範囲内だろうが、FirefoxもSafariやGoogle Chromeと比べると相当遅い。そう遠くない未来、多くの人が「Firefoxは遅くて仕方がない」とぶうぶう文句を言ったり、あるいはJavaScriptを駆使したGoogleのWebアプリはChromeでないと実用的なスピードで動かない、なんていう日が来るのだろうか?

ここで取り上げられているPeacekeeperは、JavaScriptの処理に特化したベンチマークですね。ほかの指標だとまた違う傾向が出るのでしょうか。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 当然の帰結では? (スコア:5, すばらしい洞察)

    by auge (19016) on 2009年05月23日 23時48分 (#1571674)

    「人気が出る=最小公倍数の拡大」と捉えれば

    ・機能を拡大し単純に肥大化した
    ・速度(各レスポンス)より優先すべき事項が増えた

    帰結として遅くなるのは自明の理に感じます。
    つまり、この結果は逆説的に

    「多くの人にとって、速度より優先する機能がブラウザには存在する」

    という証明にもなっているのではないでしょうか。

    • それぞれのブラウザの成り立ちを考えると、その説は間違っていると思います。

      後発ブラウザほど速いのは、乗り換えてもらうための動機付けとして、速度性能が重視されて開発されていることが、この結果につながっているのではないでしょうか?

      http://srad.jp/it/comments.pl?sid=451376&cid=1571670 [srad.jp] のACさんがすでに指摘していますが、ミリ秒単位の速度なんて開発者の自己満足だと常々感じていました。「多くの人にとって、速度より優先する機能がブラウザには存在する」ということはまったくもって同意できるところです。

      速度性能だけを重視することは間違っていると思いますが、他の性能を向上させるよりもアピール可能な水準に達するまでの開発コストが安く済むことや、速度は数値で表せるので比較しやすいことも、速度偏重に陥っている理由と考えています。

      親コメント
    • by renja (12958) on 2009年05月24日 12時13分 (#1571904) 日記

      何処に付けようか迷ったけどここに。

      昔の「Phoenix」や「FireBird」が残っていたりしますが、
      起動時間は現行のFirefox(素のまま)に比べて凄く早く感じますね。
      普段使ってるFirefox(IEタブ+NoScript+Adblock+ScrapBook+中止ボタンがしいたけ)では比較するまでもないw

      レンダリング自体は差を感じられませんけども。

      色々変更された結果、便利になりつつも重くなっているのだなぁと実感出来ます。

      --

      ψアレゲな事を真面目にやることこそアレゲだと思う。
      親コメント
    • これは昔からあるセカンドシステム効果の典型例でしょう。
      シンプルで軽快なソフトウェアが登場し、人気がでる。
      でもって様々な要望が集まり、実装され、結果として複雑で重くなっていくと。

      親コメント
  • 盾と矛 (スコア:3, すばらしい洞察)

    by Anonymous Coward on 2009年05月24日 0時12分 (#1571695)

    自国の次期主力戦車の主砲は、仮想敵国の主力戦車の正面装甲を打ち抜ける
    ように作るもんじゃないでしょうか。

    Firefox3という主力戦車の正面装甲(スピード)を打ち抜けるような主砲を装備する
    ことは、Google Chromeに求められた要求仕様そのものだったのではないかなあと。
    そしてその仕様が十分に満たせなければ、失敗作として歴史の表舞台にたつ
    ことさえないまま、ひっそりと消えていくのです。

    つまり「人気のないブラウザは、人気のあるブラウザより『早い』などの分かり易い
    指標で勝ってなければならない」だから結果だけ見ると、「人気が出れば出るほど、
    Webブラウザは遅くなる」ということになるんではないかと。
    #もちろんサンプル数が少なすぎるというのもあるけど。

    • Re:盾と矛 (スコア:1, 興味深い)

      by Anonymous Coward on 2009年05月24日 2時11分 (#1571760)
      > 正面装甲を打ち抜けるように作る
      たしかにそれが望ましいが、必ずしもそうとは限らない。仮に相手の正面装甲を打ち抜くほどの巨砲を積むには自分の装甲を相手に打ち抜かれる程度まで減らさなければならないならば、そんなことはすべきではないから。何だって要はバランスだ。実際のところ、現代の大抵の国は自分の装甲を自分で打ち抜けない程度の主砲を積んでいる。
      親コメント
    • 今となっては撃ち抜く必要はないかも知れず。
      というのは撃ち抜けなくても衝撃で中の人が...という状況なので。
      # T90はそれ自身の主砲の至近射撃に耐えられるが、試験の時に衝撃で中の豚さんが...というのは有名な話。
      ## 人の重さ人形じゃダメなんだろうか。

      ブラウザの方は、互換性の高さとパフォーマンスがトレードオフになってるような気がしなくもない。
      あるいは人気が出ていろいろ付け加えられて重くなる...みたいな。

      親コメント
    • by Tatenon (20311) on 2009年05月24日 15時14分 (#1571977) 日記
      まぁ、より高機能かより高速かより安価でなければ、ヒトバシラー以外は使いませんわな。

      無料で配布されてるブラウザが多いので、もう安価はウリにならないし。

      そしたらもう機能と速度は殆どの場合トレードオフですよねぇ。

      # 硬い戦車は重くて遅い。軽い戦車は速いが弱い。
      ## 正面から撃ち合うか、回り込んで背後をつくか。戦局によっても要求される性能は違ってくるわな。
      # でもな、要求は大体『速くて硬くて軽くて強い戦車を作れ』なんだよ。
      親コメント
  • by anonemouse (20052) on 2009年05月25日 8時03分 (#1572150)

    あまり使われていないブラウザが早いと言うお触れで出回る。
    みんなが使い始める。
    みんなが使い始めるので、「これは早いブラウザ」が「これが普通」になる。
    ユーザが多いのでちょっとでも遅いと感じることがあると「遅い」と言い出す輩が増える。

  • ということは (スコア:1, おもしろおかしい)

    by Anonymous Coward on 2009年05月23日 23時43分 (#1571673)
    人気がなければ速くなる
    かというとそんなわけはなく,むしろ
    人気がなければ早くなくなる。
  • 結局 (スコア:1, 興味深い)

    by Anonymous Coward on 2009年05月23日 23時50分 (#1571676)

    人気が出るとユーザの求める機能を追加していくことによって遅くなっていくのかな?

    任期がないブラウザほど機能的には貧弱だけどその分速度的に有利になるとか・・・・

  • by Anonymous Coward on 2009年05月23日 23時58分 (#1571680)

    FirefoxはJavaScriptベンチマークではボロ負けだけどロードタイムは最速 [hatena.ne.jp]みたいですよ。
    これが筆者の言うとおり、単純に投機的解釈とやらのおかげなら、そう遠くない未来に他のブラウザにも実装されて、JSと同じようにボロ負け状態になるのは目に見えてますけどね。

  • ブラウザの改良のために会社が資金を提供するにせよ、どこかの才能あるプログラマが
    開発に貢献するにせよ、投資対象として的確かどうかがまず評価される。市場占有率が
    低く、しかも現在主流のブラウザに対して速くもないとすれば、そんなブラウザ技術は
    資金や人材の投資を得られずに野垂れ死んでしまう。
    いま生き残っているブラウザ技術は、シェアとスピードの合計得点でなんらかの基準を
    クリアしているから、継続的改善のための投資が回ってくるのだ、と考えることができる。
  • by Anonymous Coward on 2009年05月24日 3時12分 (#1571774)
    IE系タブブラウザからFirefoxに移行したものの、同等の機能を実現させるためにつっこんだ多数のプラグインその他や、
    同等のタブ数を同時に開くと、明らかに重くなったと感じる。あとメモリ消費も激しい。ディスクアクセスも多い。

    jsがIEより速いかどうかと言った話ではFirefoxのほうが素性がよいのだろうけど、タブが増えるとjsが極端に低速化するとか、
    膨大なメモリを要求して解放しないといった面まで考慮すると、以前言われていたほどのIEからの優位性はあるのか疑問だ。
    一部の誇張された風説に騙されてFirefoxに移行したユーザが居ないか気がかり。ブラウザの選択肢が増えたのだから、
    用途や環境を踏まえてどちらがお奨めかという話にした方がよいだろう。あらゆる面でIEより優れているので無い限り。

    つまるところ、IEのようにコンポーネント化されてパーツとして使える形状に重きを置いた方がユーザにとっては便利かも知れない。
    それだけ1つのブラウザの不具合から一時的に逃げられる可能性を高められる。
  • by waraji (36531) on 2009年05月25日 13時34分 (#1572364)

    Mac OS 9 時代ですが、ちょっぱやで一時流行った iCab [mac.com] というブラウザがあり
    ベータの段階からものすごい早さを叩きだしていたんですが
    人気が出たからか、正式版になりCSS対応になった途端に激重。
    ベータ版は期限付きで継続使用はできず、しぶしぶ最新版を使ってみたりはしてましたが
    それ以降早さを取り戻すことはなく今ではその名を知るものも少数になってしまいました。

    CSSなんかいらない、あたし早い人がいいの。と思ったあの日が懐かしいです。

    # ほんとに早かった、あのブラウザは本当に早かった。

  • by Anonymous Coward on 2009年05月23日 23時40分 (#1571670)

    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であるはずなのに、なぜそれが遅いことが容認されるのか。
          ハードウェア系のベンチマークなら明らかに速いと賞賛されるだけの差があるのにスルーされていくのがとても不思議です。

          同時に、タレコミ記事のようなベンチマークでは繰り返し回数を増やすなどしてより有意な差のつくベンチマーク手法でやってほしかったなとは思います。

          親コメント
    • Re:開発者の自己満足 (スコア:2, すばらしい洞察)

      by kuy (23721) on 2009年05月24日 1時07分 (#1571725) ホームページ
      ウェブアプリアはそんなミリ秒単位の処理の蓄積によって動いているんですがね。
      親コメント
      • by furari (35240) on 2009年05月24日 1時52分 (#1571751)

        ミリ秒単位で画面上のオブジェクトを動かしたりするときは多少差が出ますが、
        テキスト処理関連で困ることはだいぶ減ったように思います。
        ただし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>

        親コメント
        • by haratake (365) on 2009年05月24日 2時15分 (#1571762)

          > ボタンを連打しても反応がすごく遅い問題がずーっと直らないです。

          これは、「ボタンを連打する」と「ダブルクリック」になってしまうからでしょう。

          IEのボタンは、ダブルクリックに反応しない
          Firefoxのボタンは、ダブルクリックにも反応する

          ということで、反応が遅いわけではないと。

          親コメント
    • by kousokubus (37099) on 2009年05月25日 12時05分 (#1572254)

      おおよそ、30msが時間感覚の分解能だと聞いています。(時間順序判断分解能・こっちの方が早かったと判り始める速度)
      なので、1~2msの速度に血道を上げるのは開発者の自己満足ですが、30msを超える速度アップは我々にも恩恵があるかと。
      (1msの高速化x30を繰り返すことで、体感速度が上がっていく)

      # もちろん、フル・アニメーション(42ms)とリミテッド・アニメーション(125ms)の差が表現力の差でないことは、日本人であれば誰しも理解していることではありますが:p

      親コメント
  • by Anonymous Coward on 2009年05月23日 23時42分 (#1571671)
    みんなに使われるとへとへとになってしまうんでしょうかね
typodupeerror

計算機科学者とは、壊れていないものを修理する人々のことである

読み込み中...