万回ページロードを試行したらしい。ここまでキチンと行われているので、結果の信頼性は高いだろうとのこと。ドメインをまたいだ通信を多重化できないので、複数のドメインからリソースを取得するサイトでは、効果が減る。関係ないボトルネックを持つものが多い。レンダリングのブロックとか。あると分析しています。これに対する補足記事として、数日後に以下の記事があがりました。記事の価値(ベンチの信頼性)を評価した上で、こう付け加えています。ページロードしかテストできてない。目の理由の方に着目しています。メリットが得られにくいと指摘しています。効果がより大きく出るはずだというもの。読もうと思えば読めるはずだけど、上記理由からそうなってないリソース」が結構多いことを指摘している。いったまとめをしています。よって高速化のための手段は増えたものの、ただ使うだけではだめで、相応の最適化も必要であるということ。単純に置き換えただけで、なんでもうまくいくというものでもないだろうということです。記事は示唆しているととれるのではないでしょうか。新たな、強力な選択肢が増えることになります。ついては、かなり用途というか、考えるべきレイヤが違うものだと思っています。ついて書きたいと思います。「自分たちで作って、自分たちで使い始めた」プロトコルというような感じで始まりました。書かれたリソースを取得する。この時、それぞれのリクエストは前のレスポンスが返らないと投げられない。(*2)必要なリソースを、同一のコネクション上で多重化し一気にやり取りできる。ヘッダは圧縮されたバイナリなので、生テキストよりはサイズが小さい。効率の良い(*3)通信を実現することを目的としています。セッションを複数張って並行にダウンロードしたりする。読む時点で、必要なリソースも読める。一方で、暗号化のコストや、中間キャッシュが効かないなどはある。可能だと言う点が、話をもう一つややこしくしているのかもしれません。似ているようですが、若干用途が違います。「リクエストが想定されているリソースを、先にレスポンスしておく」といった感じの挙動ができます。(これはあくまでも、ひとつの使い方だと思いますが。)しかし、これで従来できなかったような高速化ができるようになる可能性があります。読み込んで、ブラウザがそれを解析し始めたとき、以下の様な外部リソースの埋め込みがあったとします。無い限り)、これらを順番に取得していきます。取得の際は、単一のセッションではレスポンスが返るまで、リクエストが投げられません。平行にリソースの取得を行うなどしていました。これはサーバやネットワークに大きな負荷になります。単一のセッションでリクエストを多重化することができるため、それだけでも、大量の画像の読み込みなどでは、セッションの面で見る通信の効率は良くなります。外部リソースを配信することができます。これは、見方を変えれば「キャッシュの送りつけ」という感じです。必要だということがわかり、そこで初めてリクエストを投げてリソースを取得します。「送りつけてしまう」のです。読んでいる間にキャッシュに入り、ブラウザがリクエストを発行する段階ではキャッシュヒットしてすぐにリソースが使用出来るという寸法です。読んでリクエストを発行しようとしたら、そのリソースは既に"キャッシュの中に入ってた"。断じてねぇもっと恐ろしいものの片鱗を味わったぜ。やるのは、そこまで難しくないです。同じインタフェースでサーバを立てるだけです。ついては、req.issdyres.push()を用います。主要部分はこんな感じ。});});上記の全体は、こちら。読まれていることがわかります。