「アカマイ遅いぞ冤罪事件」から読み解く、Webサイト計測における誤解と現状

ウェブサイト最適化101〜正しく測ろうあなたのサイト〜

山田泰資氏：今日はお越しいただきまして、ありがとうございます。今日の「Akamai Tech Conference 2018」はあまり固い技術の話ではなく、アカマイのエンジニアがもっと社外のエンジニアの皆様と交われるきっかけを作ろうということで、それぞれの部署の人が、日々どんなことをしているのか話すことを趣旨にしています。

今日のアジェンダはこのようになっています。

まずは早速、今日の三行まとめですね。会議や報告などで、「このような内容の話をした」と言えばだいたいOKかな、と。

ひと筋縄にはいかない「サイト計測」のゴール

まず、サイト計測です。みなさんの中でサイト計測をやっている方はいらっしゃいますか？

（会場挙手）

そもそもサイト計測のゴールというのは、例えば、オンラインショッピングをやっていたとすると、最初に「ちゃんと購入してもらえたのか測りたい」ということがあります。何人がどれだけ商品を買ったのか、という結果を知りたいということです。

しかし、結果を知るだけでは不十分です。結局のところ、サイトを作る側からすると、結果だけわかっても意味がなく、「このように改善した結果、ユーザーの行動がこのように変わって、このような結果が出てきた」というフローを知らなければいけません。

なので、入力としての「体験」と出力としての「結果」があるわけです。

なので、サイトの開発側からすると、こちらの（入力としての）体験を自分たちの努力で改善した結果、ユーザーの行動が変わって、最後の結果が出ます。

しかし、結果はコントロールできないので、計測しかできない。計測して直すことができるのはこちらの（入力としての）体験の部分になるわけです。

ここだけで話は終わりません。

こちらは本番サイトの話です。みなさんは当然、いきなり本番サイトを変更するかというと、まあしないですよね。

まず開発環境があって、そこで「うまく動くな」となったら本番に展開する。その後、実際に最後の結果が出てくるかたちになります。

なので、サイト計測といったときに、ぜんぜんわからない人は「1個計測すればいいんですよね？」と言うのですが、そうではありません。いろいろなところで、いろいろな粒度で計測しなければいけません。

開発工程まで含めると、まず開発環境で変更した結果、改善しているのかどうかを手元で、もっと細かな粒度で確認できないといけません。そのような細かな粒度の計測をやって、トータルで改善したあとで、最後の本番デプロイをします。

その後、「実際にユーザーの体験は改善しているのか」ということを、サイト全域にまたがるようなマクロなレベルで、それぞれのユーザーの体験内容を記録して計測します。

ビジネス的に知りたいのは、一番最後の結果なのですけれども、それをちゃんとやるためには、その手前のサイト上のユーザー体験を把握しなければいけません。

そして、サイト上のユーザー体験を改善するためには、もっと手前の開発環境や社内の評価環境で計測して、改善するプロセスを回していかないといけません。

ということで、実はいろいろな局面や箇所で、サイト全体のマクロなレベルから、開発者の手元のところで、特定のコードが速くなっているのか、特定のWebページのレンダリングが速くなっているのかというすごくミクロなレベルで計測しなければいけません。

そのような、いろいろなものが混ざったものが「Web計測」と呼ばれているわけです。

サイトを比較する3つの観点

さらに、計測だけでは意味がなくて、「何と比較するのか」という問題があります。

（ポイントは）大まかに分けて3つあると思います。

まずは「それまでの自分」。今までの自分のサイトよりも、よりよいサイトになっているかという観点です。

そうすると、過去の自分と比較しないといけないので、1回比較して終わりではなくて、例えば、1年前と比較してどうなのか、修正前と比較してどうなのか。

1年前というのは、サイトを変えたことによる影響のほかにユーザー環境が変わります。新しいデバイスやブラウザが出てきて、（ユーザーの）使い方が変わってきます。

そうすると、「サイトを変えていないからパフォーマンスは同じ」とは言えなくて、結局、周りの環境が変わるので、自分のサイトのパフォーマンスが変わってきます。それをちゃんと見れないといけません。

あとはターゲットサイト（競合サイト）です。ユーザー環境が変わって、自分のサイトも変わっています。

しかし、競合サイトがどんどん改善していくと、そちらのユーザー体験のほうがよくなり、ユーザーが流れていくので、結果として、結果が変わっていくということになってきます。なので、そこも意識しなければいけません。

あとは市場動向です。例えば、約10年前の話になりますけれども、デスクトップのWeb（サイト閲覧）からモバイルのWeb（サイト閲覧）が主流になりました。

今はモバイルのほうがユーザーは多いですし、そちらのほうでどんどん購買行動が出るようになっています。そうなると、市場動向としてはどうなっているのか。自分のサイトはデスクトップに最適だけれども、モバイルに最適とは言えないという事例がよくあります。

例えば、1つのページでモバイルとデスクトップ両対応のサイトを作ったとします。そうすると、1回開発すれば両方に対応できるので非常に効率がいい。ところが、両対応といっても見た目だけの対応で、中身まで真の意味で対応していない場合があります。

そういった場合、エンドユーザーからするとモバイルでアクセスしているのにコンテンツはデスクトップクラスで流れてきて、「見た目はモバイルだけど、重さはデスクトップ級」ということがあります。

モバイルにも（見た目だけは）最適化されているから、見た目はきれいです。ところが、ページの遅さでいうと、（重さが）デスクトップ級なので「なんだこのサイト？」という話になってしまいます。

というわけで、市場動向、ユーザー環境がどうなっているかということも意識する必要があるわけです。

世の中にある計測関連リソースの一例

世の中では、そのようなものを把握するために、無料のリソースやツールがいろいろあります。（今日は）私がよく使っているものをご紹介します。

「WebPageTest (WPT)」は使ったことのある方もけっこういると思うんですけど、この後のセッションで「WebPageTest」の細かい使い方についての話があるので、（その方は）そちらのセッションも受けていただくといいと思います。

こちらは非常にメジャーなツールです。計測したいサイトのURLを打ち込むと、そのURLを実際のブラウザでロードしたときに、どのようにロード過程が進んでいるのか、どのタイミングで画面が表示されるのか、それぞれのページの中に入っている画像やJavaScriptがどのようにロードされているのか、細かく計測をすることができます。

なので、業界ではスタンダードと言っていい、超定番の計測サイトです。ソース自体もオープンソースで公開されているので、自社内で計測用の基盤を立てることもできます。

こちらは弊社も支援しておりまして、サイトに行くと、支援している会社のロゴがあって、業界全体で盛り立てている計測プラットフォームになっています。あとは各社の努力として、例えば、「Google PageSpeed Insights」という取り組みがあります。

こちらも同様に、URLを打ち込んでsubmitすると、今度は詳細に計測というよりも、例えば「ここのサイトはJavaScriptのロードが多すぎてブロッキングしている」とか、マクロレベルのサイトの作りについて自動チェックをやってくれます。

自動チェックなので限界はありますが、人間が目でJavaScriptがどのようにロードしているかを全部追いきることはなかなか難しいので、非常に有用なツールです。

下の2つ（「HTTP Archive」と「Chrome User Experience Report」）は計測ではなく、計測結果のデータソースです。

Google Chromeをインストールされている方はかなり多いと思います。世の中的にも60パーセントぐらいのシェアがあります。

こちらはインストールしたときに、「Googleにフィードバックデータを送りますか？」という質問が出てきます。そこで「OK」とすると、例えば、アカマイのサイトにアクセスしたパフォーマンスデータをGoogleに送り返します。そのようなデータを集積して、その結果を無料で公開しているのがこちらの「Chrome User Experience Report」となります。

ただし、こちらは無料で公開しているといっても、ある意味SQLのようなものでアクセスするデータです。GoogleさんにはBigQueryという大規模データ集計をやるためのプラットフォームがあるのですが、そちらに「無料で公開しています。みなさん自分で好きにこねくり回してください」という感じでデータが生で入っています。

ただし、これをもとにいろいろな活用をしようとしているところもあります。

例えば、Google PageSpeed Insightsは、Chrome User Experience Reportのデータをもとに、「あなたのサイトは、少なくともこちらで測っている範囲では、このような体験が得られているようです」といったデータが出てきます。

Chrome User Experience Reportは、実際にChromeを利用した人の体験をデータとして吸い上げているわけなので、実ユーザーの環境を反映しているということです。

一方、「HTTP Archive」は、Chrome User Experience Reportで公開してるURLのリストなどをもとにWebPageTestを使って計測して、データを取ってきています。

何がいいかというと、Chrome User Experience Reportはデータの粒度が粗いです。「このページは何秒でロードしました。以上」といった具合で、それぞれのページのコンテンツがどのようにロードしたかという過程の情報は一切なしで、粗いデータしか取れていません。

一方、HTTP Archiveはもっと詳細なデータが取れています。とくに、WebPagetestはブラウザを使いますけれども、ブラウザ内での計測に加えて、ブラウザの外でブラウザの挙動を見ながら計測している部分もあるので、非常に詳細なデータが取れます。

この4つのツールにもそれぞれ役割分担がありまして、活用して、ほかのサイトはどのようなパフォーマンス出ているのかという細かい比較をするために、（4つのツールを）駆使して日々の業務でやっています。

mPulse：ユーザー体験と行動の複合解析基盤

ちょっとだけ宣伝させていただます。弊社では「mPulse」という、「ユーザーがサイトにアクセスしたときにどのような体験をしているのか」ということをデータで集めてくるようなプラットフォームを提供しております。

けっこう多機能なのですけれども、いわゆる「RUM (Real User Measurement)」と呼ばれるカテゴリのツールになります。計測というのは、大まかにRUMとSynthetic、Web Analyticsの3つに分類できます。

RUMというのは、実ユーザーがサイトにアクセスしたときに、計測用のJavaScriptをユーザーのブラウザに実行してもらうので、実ユーザーの環境で計測しているわけです。なので、Real User Measurementというわけです。車でいうと、本物の車の運転の体験をデータとして吸い上げているということです。

Syntheticは、先ほどのWebPagetestに相当するものです。こちらは、あるベンチマーク用のツールが動いているサーバやPCからサイトにアクセスして、そのときの状況を記録して詳細解析できるようにするツールなので、サイトにアクセスしている実際のユーザーの体験データではなく、実験環境から単発のアクセスしたときのサイトの応答状況を解析するツールになります。

この2つはユーザー体験の計測の一部なのですけれども、RUMは実際のユーザー体験で、ベンチマークはあくまでベンチマークツールという使い分けになります。

「実ユーザーのデータが得られるなら、なぜベンチマークツールがいるのか？」という話があるかもしれませんが、冒頭で説明したように、本番だけの計測では不十分です。開発環境で十分にうまくいく算定ができてから、はじめて実環境に投入する必要があります。

試験環境では実ユーザーがアクセスしてこないので、基本的にRUMではできませんので、そのようなときにベンチマークツールが登場してきます。

ベンチマークツールを使うと、同じ環境から自分が「実行しろ」といったタイミングで必ず計測が走るので、開発のサイクルと非常に合うわけです。

自分が何かコードを改修・改善して、ベンチマークツールにかけて、データが取れたというときに、このサイクルを必ず同じ環境から叩いているので、改善したかどうか判断するのにはベンチマークツールのほうが非常に都合がいいというわけで、この2つが共存しているわけです。

最後のWeb Analyticsはパフォーマンスではなく、ユーザーがサイトでどのように動いたかを計測するためのツールになります。

mPulseは基本的にはRUMなのですけれども、ユーザーがどのようなサイトでどのように動いたかというデータも収集できまして、いろいろなことができる複合ツールになっています。

mPulseではどんなことができるのか

概要としては、実環境でのパフォーマンスを吸い上げてきて分析します。それだけではなくて、ユーザーがどこのページからどのように移動したのか、どこでサイトを離脱したのかといった情報もトラッキングしています。

さらに下のほうにいくと、例えば、最近のアプリケーションはJavaScriptで作ることが多いですよね。ただ静的なコンテンツが表示されるだけではなくて、JavaScriptで書かれた、クライアントで実行するコードがそのサイト自体の機能の一部になっています。

そうなると、環境によってはJavaScriptのエラーが発生するわけです。そのようなものを収集してきて、「この環境のユーザーだと、このようなコードエラーが起こっています」といったエラー解析の機能も持っています。

かなり使えるツールなので、セッションのあとにデモをやっていますので、よろしければ見ていただければと思います。

冤罪事件簿：アカマイ遅いぞ事件（1）

今日は製品案内の話ではないので、一般論はここまでです。この後は計測トラブルシュートの話、アカマイの冤罪事件簿について話させていただきます。

今日は2つ話がありまして、1つ目はこのようなあらすじになっています。

まず最初は（お客様が）「うちのサイトは遅いみたいだ」と。この場合、お客様はまだアカマイ化していなかったので、「アカマイ化とlonをお願いします」ときたので「了解いたしました！」ということで実施しました。

導入したら当然、速くなっているかどうかを確認するわけです。確認すると、Before→Afterということで、見ての通り高速化されました。

ところが、しばらくしたところで「こないだの、再度測ったら実は遅いんだけど……」というご相談がありました。しかも「アカマイが遅いんじゃないのか」という疑いがかかりました。

我々としては速くなったと思っていたところに「アカマイ遅い」というつっこみが後から来て、正直「どういうことなんだろう？」と騒然となりました。

お客様からは、ほかのCDNと比較を行ったら、アカマイが倍ぐらい遅いというかなり衝撃的な申告がきました。

しかもこのお客様からは、計測した結果を言うだけではなく、ちゃんとデータが送られてきました。

結果として、平たく言うと、対抗CDNは約640msに対して、アカマイは1953msかかっていると。

ちなみに、これはあくまで冤罪事件ですから、本当にこうなっているわけではありません。アカマイが遅いという誤解があると大変責任を感じてしまうので、そこだけご留意ください。

結局、このようなデータまで来てしまって「倍遅い」と言われると、かなり真面目に検討しなければいけないというわけで、私のところに話がやってきました。

この時、担当者の気持ちとして、「真実はいつもひとつ！　頭でも丸めるか」みたいな話から「こんなはずは……何がなんだかわからない」みたいな、いろいろな気持ちがあるのですが、そんなことは言わなくても、「とにかく心臓に悪い」というのが正直なところです。

速くしたと思っているのに遅い。しかも「倍ぐらい遅い」といきなり言われて、「なんとかするんだ！」と。さらに、営業担当者やSEもどんどん「どういうことだ？」と来るわけですよ。それだけでとにかく心臓に悪いと。

実際に何が起こっていたのか　①集計マジックの影響

では、何が起こっているのかという謎解きに入ります。

こちらの3つの影響が考えられます。

まず1つ目は集計マジックの影響。2つ目は測定自体のマジックの影響。3つ目は構成のマジックの影響です。

まずは集計マジックの影響です。そもそも、平均値で話していいのかという話です。

こちらは平均値だけで出したのではなくて、どのようなロードタイムの分布だったのかということを、お客様から来たデータを改めてまとめ直したものです。

これでやると、最初の「アカマイが2倍ぐらい遅い」というのはどこまで状況を正しく反映しているか、という話になります。

いろいろな議論をしていると「平均ではこうなってる」という数字が一発だけ出てきて、議論が進行してしまうみたいなことをみなさんも体験したことがあると思いますが、それはかなり危険な話です。

とくに複雑な事象に対して、平均値を一発適用して「こっちのほうが速い」とか、ものさしがあって「こちらが10センチでこちらが5センチなので、5センチのほうが短い」みたいなストレートな……確かに5センチは10センチより短いですけれども、その数字を持ち出してくることがそもそも大丈夫なのかというところがあります。

ただ、毎回分布まで検討してやると、議論が入り組んでしまってなかなか進まないというフラストレーションがあります。

なので、バランスの問題なんですけれども、「平均値でOKなら必ずそれでいいんだ」という話で進んでいってしまうのはけっこうリスキーな話だということが第1の認識になります。

平均値では足りないから、このような「図で見る」「分布を見る」といったいろいろな可視化技法があるわけです。特定の平均値ではなくて、こちらのグループとこちらグループはどのような感じなのかということを比較するための技法が可視化技法なわけです。

数字1個ではあまりにも乱暴なので、可視化した上で見ると、よりバランスの取れた、より的確な見方ができます。

なので（スライド）右にある、「平均では」という言葉が出てきたら、みなさん「分布ではどうなってるの？」と思ってください。逆に「件数ではこれだけ出ています」と言われた場合、「比率ではどれぐらいよくなっているのか？」という比率で考えないといけません。

逆に比率を強調してきた場合、「実数ではどうなっているのか？」と言わないといけません。例えば、10万件中1件と10万件中10件では「10倍の増加です」と言えるわけですけれども、「9しか増えていないよね」という突っ込みをしなければいけません。

あとは「集計では」と言って、すごい精緻な集計をやってきた場合、「集計外はどうなってるの？」という突っ込みをしなければいけません。

このようなことを言っていたら、すごくあまのじゃくな人だと思われてしまうんですけれども、このようにいろいろな角度から見ていって、計測結果が本当に真の状態を表しているかを見ていくことが大事なポイントになります。

実際に何が起こっていたのか　①測定マジックの影響

次は測定マジックの影響のお話になります。

我々はWebPagetestで先ほどのレポートを出しました。お客様はJMeterで同じサイトを計測しました。これは本当に同じものを計測しているのでしょうか？

答えはNOです。JMeterは、そのURLのオブジェクトしか取ってきません。WebPagetestは、ページのURLを伝えると、ページだけではなくて、そこに入っているJavaScript、スタイルシート、画像を全部取ってきて、その過程を結果としてレポートしてくるわけです。

なので、どのツール使っているかによって、何を計測しているかというのはぜんぜん違う話になります。

我々が最初に出したレポートに戻ります。

結局、アカマイ化してどこが速くなっているのかというと、最初のところのconnection setup timeが200msぐらいあったところが、10msほどしかかかっていません。スタイルシートやJavaScript、画像のロードは軒並み10msを切るぐらいになったわけです。

では、どこがJMeterで計測されていたのかというと、こちらです。

ちょうど正面衝突するかのように、我々が「速くなったよ」と言っても「ぜんぜん速くなっていない」と。つまり、アカマイ化したといってもキャッシュヒットさせないで、必ずオリジンに行くような、特定部分だけを測るような測り方になっていたわけです。

これは意図してというより、JMeterを使っていた時は、おそらくオリジン上のロジックがどれぐらいキックされると、どのぐらいのパフォーマンスで戻るかを測りたかったのかなと。そのようなときはこれでいいんです。

ところがサイト全体でどれぐらい速くなっているかを見る時にJMeterを使ってしまうと、サイトとしての速度とはまた違うものを測っていることになってしまうので、そのような測り方では比較することができないわけです。

ですので、JMeterが何を測っていたかというと、アカマイのエッジサーバに来ました。インターネットを超えてオリジンサーバまで行って、オリジンサーバのロジックが叩かれて、そこの裏でいろいろなデータベースアクセスやいろいろなことが走って、またインターネットまで戻らせて、JMeterまで戻らせて測っていたわけです。

しかし今回、お客様はもともとCDN間の比較をしたかったわけなのに、こちらをやってしまった。

こちらが計測の構成の影響です。自分の測り方だとどこの構成が計測されることになるのかを意識しないで、単に「計測ツールがある。サイトのURLがある。よし計測ゴー」とやってしまうと、このようなトラブルにハマりやすくなります。

この話は「JMeterよりWebPagetestがいい」という話ではありません。JMeterでも十分な計測になることもあります。例えば、測定対象をCDNでキャッシュして、CDNで配信するようなオブジェクトをJMeterで計測するのでも、CDNの比較としてはけっこういけると思います。

ただ、さらにいうと、それだと今度はCDN部分の影響が強く出ます。CDNにキャッシュされているものばかり計測してしまうと、ページ全体の速度を測ったらどれぐらいかという観点ではなくて、CDNを測ると10msぐらいで転送が終わるという結果になって、超高速になるというレポートが社内に出回ってしまいます。

これはこれでアンバランスなので、やはり個別のツールで詳細にミクロな計測をやるほかに、ページ単位、サイト単位というようにマクロの計測を併用する必要があるということが今回の教訓です。

というわけで、ミクロからマクロまで正しく測りましょう。あとは自分が測るものの構成を理解した上で、自分の用意したツールはその構成のどこの部分を測るものなのかをちゃんと考えていく必要があります。

ちなみに、ツールでダイレクトに測れなくても、間接的に測る方法もあります。

JMeterというのは2つの所要時間を計測しているので、その2つを引き算すると、実際にバイトを転送している間の時間を測ることができます。

実際の転送所要時間に着目してデータを持ってくると「アカマイのほうが短い傾向がある」と言えるわけです。しかし、今これで「おお、そうか」と思った方はダメなんです（笑）。

今度はグラフの見方の話になってきます。グラフで見ると説得力が出てしまうんですけど、これは外れ値の部分しか見えていなくて、箱ひげ図の比較の場合、ここのメインのボディの部分をちゃんと照合しないといけません。

こちらが集団の統計的な分布を可視化している部分です。（スライド図の）黒い丸は単に外れ値なので、全体傾向を見るためのデータとしては適切ではない訳です。

とりあえず意味はあるかもしれませんが、別の部分なので、このような分布結果が出てしまって、「おお、そうか」と棒グラフみたいな感覚でいるといけないわけです。そんなわけで測り方だけではなく、データの読み方も重要になってきます。

さらに、今度はこのデータを読むときどうするかというと、着目すべきは（スライド図の）根っこのところです。

転送時間が0って何かおかしいと思いませんか？　ちゃんとデータを転送してレスポンスは取れているのに、転送時間が0ということが非常に多い。

この箱ひげ図のメインの部分は、どう見ても0のところに乗っかっています。これはおかしいと思わないといけません。

どういうことだろう？と考えてみると、同じパケット内やウインドウ内で転送完結する場合は、転送時間はほぼ0みたいになってしまうのでは？　となるわけです。

なので、このデータで分析する場合、もう少しまともに転送しているケースで測ったほうがいいという話になってきます。

というわけで、最初は本当にシンプルな話だったところが、掘っていくといろいろと（課題が）出てくるわけです。このようなことを日々やっています。

冤罪事件簿：アカマイ遅いぞ事件（2）

次の「アカマイ遅いぞ事件簿2」に入らせていただきます。

まずはあらすじからです。こちらは先ほどのような単純な話ではありません。最初はアカマイ化されたお客様から「なんだかアカマイが遅い」というお話をいただきました。

今回は「キャッシュ対象コンテンツでも遅いですか？」と確認したら、「キャッシュヒットしていても遅い。画像でも遅い」と。「いつ頃から発生しているのかよくわからないけど、最近遅い気がする。データは取ってないけど調べてくれ」と言われて、正直困ってしまいました（笑）。

単に測定ミスではなくて、本当にキャッシュされているものでお客様に確認した上で「遅い」と言われているので、これはまずいなと。

調べてみると、本当に遅いんです。こちらで見ると、数KB程度のファイルにcontent download timeが軒並み600ms程度かかっています。たしかにこちらでも発生し、しかも再現するものですから、一時は「これは謝らないといけないかもしれない何かがある？」みたいになりました。

ここでクイズをお出しします。最終的にこちらの画面から原因を特定したのですけれども、「どこが原因だろう？」と想像できる方はいらっしゃいますか？

ちなみにヒントは「HTTP/1.1」というところになります。

まず、Google Chromeには同時接続数ルールがあります。同一ホストに対しては同時に6コネクションまでしか入りません。

いろいろなサードパーティなどに接続すると思いますが、全体でも同時に10コネクションまでしか入りません。

かつHTTP/1.1の接続の場合、多重転送やパイプライン処理はしません。規格上、一部定義はされているんですけど、実装としてはまあない訳です。

最近、HTTP/2という改訂版が出てきて、そのようなことができるようになったのですが、お客様はHTTP/1.1でやっています。

このGoogle Chromeの同時接続数ルールに照らしてもう一度見てみると、「妙だな……」と。Chromeは同時に6本までの接続しか張らないはずなのに、こちらでは同時に19本の転送をしています。

しかも、Google Chromeが6本か10本のコネクションを張っているときに、同じコネクションIDで同時にコンテンツをダウンロードしています。HTTP/1.1でそんなことができるはずがないので「なんだこれは？」ということになりました。

結論は、Chromeのバグでした。こちらは今もバグっているので、みなさんGoogleのDevToolsなどで測っている場合は、おそらく間違ったデータを見ていることになります。

Chrome（のベースになるChromium）はオープンソースのブラウザなので、開発ログを見ることができるんですけれども、昨年の年末ぐらいにこのバグが導入されていまは修正されたのですが公開されているChromeにはまだ入っていません。というわけで、Google ChromeやDevToolsを使っている方に教えてあげると喜ばれるかなと思います。

Google Chromeにおけるバグの概要

何が起こっているのかといると、今度はブラウザの中に入っていかないといけません。ChromeにはタブごとにRendererプロセスがあって、そちらが画面の描画を担っています。

そして、それぞれのタブの管理やネットワークの転送などの裏側の仕事をやるためにBrowserプロセスがあります。

なので、みなさんが見ている画面は基本的にRendererプロセスが管理していて、BrowserプロセスにIPC経由でリクエストを出して、Browserプロセスが実際にネットワーク通信をやって、最終的にRendererプロセスに戻っていくという構造になっています。

それぞれのプロセスでは、レンダリング・コンテンツ実行を担うスレッドとそれをサポートするためのIOスレッドが並走しています。

実際にはIOするわけではなくて、Browserプロセスにリクエストを出して、Browserプロセスの中のIO threadがネットワークにアクセスするのですけれども、何が起こっているのかというと……。

ところで、Webページの高速化をやるときに、クリティカルレンダリングパスという話を聞くと思います。

どういうことかというと、こちらの画面を作るために、RendererプロセスのRenderer threadがすごくがんばるわけです。Renderer threadがHTMLをパースして、JavaScriptもパースして実行します。実際にレンダリングもします。画面も実際のレイアウト配置において、ここに画像を置くとか、ここをレンダリングするとか、そのようなところも全部一括してやります。

ここが止まると、ブラウザの描画も止まります。ユーザーのレスポンスというか、体感として非常に悪くなるので、いかにRenderer threadを止めないようなコンテンツを作るかということが非常に重要なポイントになります。そこが、今回のバグのポイントになりました。

こちらが半年前の構造です。ネットワーク越しにコンテンツを取ってきたあと、そのコンテンツを受けて、完了時間を記録する役目は、Renderer threadではなくて、 rendererのmain/IO threadで記録していました。

こちらはレンダリングの処理で重くなっていても、関係なく別スレッドで動いていて、的確な時間が計測されていました。

こちらはバグった後です。正確にいうと、プロセス間通信の改良をやって、効率よく実行するようになった結果なのですけれども、取得時間を記録する役目がRenderer threadの中に入ってしまいました。

例えば、レンダリングの処理が重たいと時間を記録するタイミングが遅れてしまって、その結果、content download timeが見かけ上、非常に長くなります。こちらがバグの主因でした。

こちらのメカニズムが特定できたことで、この問題が何を意味していたのかわかります。つまり、Renderer threadがビジーだと取得時間を記録するタイミングが遅れます。

逆にいうと、先ほどの取得完了タイミングが非常に遅いという影響が出ている場合は「JavaScriptの実行で忙しいサイト」ということになります。

メカニズムがわかると、このようなことがわかるのですが、わかっていない段階ではChromeが適当な数字を出しているだけにしか見えません。ただ、このように下までどんどん掘っていくと、いろいろな情報が取れるわけです。

結局、Chromeのバグではあったのですけれども、意外に情報量があるわけです。最新のChromeでは直されていくと思いますが、過去のChromeで計測してこの問題が再現すると、JavaScriptの影響で遅いんじゃないのと言えたりするわけですね。

修正した結果、もっと上のBrowser process側で記録する時間を使って、Resource TimingやChrome DevToolsの所要時間を表示することになりました。

ただし、まだ直っていないので色々な問題があります。たとえばChromeを使っている方のアクセスを先ほど言ったRUM、つまりエンドユーザーの環境で計測するとどうなるか。

今、Chromeは世界的に50～60パーセントぐらいのシェアがありますので、入ってくるデータの50～60パーセントはこの問題がヒットするわけです。

そうすると、そのデータをもとに分析しても正しいかどうかはよくわかりません。必ず発生するわけではなく、サイトのJavaScriptの扱い方と重さに依存しているので、完全なゴミデータではないけれども、本来のネットワーク転送時間とは違うものが混入しています。これがベンチマークツールとRUMの違い、実ユーザー環境の計測の怖いところです。

ベンチマークツールであれば、ツールがバグっていると思ったら、自分が新しいバージョンに修正して計測し直せばいいわけです。エンドユーザー環境にバグが入っていると、自分で除去したり修正することができません。

この場合、Chromeを除去してデータ集計することになりますが、世の中の50～60パーセントぐらいを排除した分析になってしまうので、それはそれで問題があるわけです。

派生タスク：Browser-level vs HTTP/TCP-level

ここまででブラウザ上でこの問題が起きることまでは言えたのですが、「本当にアカマイが遅延しているわけではない」ということを言わなければいけないとなると、通信レベルで言える必要もあります。

パケットキャプチャをして、「確かに届いています」と言ってあげたいのですけれども、サイトがHTTPSで動いているとすると、SSLコネクションが働く中でHTTPの転送をやっているので、観測しようと思ってもできないという問題があります。

とくに最近はほとんどのサイトでHTTPSにしていこうという流れがあるので、こちらはやはり問題なわけです。

どう解決するかというと、HTTPSのサイトというのは要するに、「SSLで適切に保護されていれば盗聴（解析）できません」という話なので、逆にいうと、適切に保護しないで実験すれば、盗聴して解析できるわけです。

なので、適切に保護しない構成をあえて作って、データを取るということをやらなければいけません。

幸いなことにChromeとFirefoxは特殊な設定をすると、適切な保護をしないモードで動かすことができます。

それがこちらです。「SSLKEYLOGFILE」とGoogle検索をしていただけると詳細なやり方が出てきます。

実際のネットワークのキャプチャデータはSSL上で暗号化されているので、そのままでは読めません。

しかし、ChromeやFirefoxにSSLKEYLOGFILEをダンプしておいて合成すると、複号されて、平文でそれぞれのHTTPの転送がどうなったかを解析することができます。

こちらはWiresharkのアウトプットですけれども、こちらをもとに普通のWebPagetestでやるようなウォーターフォールを再現するツールも存在します。実のところ、これがWebPageTestがウォーターフォールを生成している方法でもあったりします（登壇者注：個人的にはこういう背景からWPTへの信頼度が高く、ツール間比較でWPTとChromeが違うという結果が出た時点でChromeはほぼクロ扱いの心証になった。が、それでも「ツール間で違う」だけでは周囲への論拠として弱いため、パケットレベルで現認するという手順を取った）。