こんにちは、編集長の白石です。
今回は、Webパフォーマンスに関する特集の一環として、株式会社Spelldata CEO、html5j パフォーマンス部 部長などを歴任されている竹洞陽一郎さん（エキスパートNo.54）にお話を伺ってきました。
竹洞さんはWebパフォーマンスについて10年以上従事しており、現在でも年間200サイト以上を計測・分析・評価しているという、その道のエキスパート。テクノロジーの知識はもちろんのこと、アカデミックな話題から業界動向まで幅広く押さえていらっしゃる竹洞さんに、「竹洞さんにしか語れないパフォーマンスの話」を聞いてきました。
「ADN」や「パフォーマンス・バジェット」など、Webパフォーマンス業界の最新動向の話も盛りだくさん！めちゃくちゃ面白くて歯ごたえのあるインタビューに仕上がったと思います。
どうぞお楽しみください。
「Webパフォーマンス大事」ってわかってる人は2割しかいない
白石 改めて伺いたいんですが、Webパフォーマンスはなぜ重要なのでしょう？
竹洞 根本的な話から言うと、Webサイトがある、ってことは伝えたいメッセージがあるわけですよね。 そして、多くのサイトは複数のページにまたがっているわけですが、それは伝えたいメッセージが複数ある、もしくは複数に分けているということ。 Webサイトを高速に表示するということは、それらのメッセージを高速に伝えるということにつながるわけです。
ですが、UX業界で著名なロバート・ヤコブソンによると、1秒以上のインタラプトが入ると人間は思考を中断されてしまうといいます。このインタラプトは、可能な限り避けなくてはなりません。 それによって、ユーザーを「フロー状態」に導くことを作り手としては目標にすべきであり、それがパフォーマンスを重視する理由となります。
白石 そうしたフロー状態にユーザーを導くことが、営利企業にとってはビジネス上も大きなアドバンテージになるということですね。 ただ例えば、「パフォーマンスを向上させるとKPI達成につながりやすい」、もしくは端的に「儲かる」といったことを表すデータなどがあれば、多くの企業がパフォーマンスの優先順位を上げると思うのですが、そうしたデータはあるのでしょうか？
竹洞 GoogleやYahoo!が出しているデータはあるのですが、あらゆる業界をおしなべて平均化してしまっているので、正直それほど使えるデータだとは思っていません。 業界によって、業務上のKPIって全然違ってきますからね。
となると、業界や企業ごとの事例になってくるのですが、そういう点でまとまったデータは今のところ存在しません。モデルもできていない。 例えばAmazonだと0.1秒パフォーマンスを改善すると売上が1%上がる、といったデータが示されたこともありますが、これも「Amazonだから（特別なんだろう）」の一言で済まそうと思えば済まされてしまう。
私が担当している仕事でなら、具体例はいくらでも挙げられるんですけどね。あるメディアは、表示に6秒かかっていたところを3秒にしたことでPVが倍になったり、売上が3倍になった会社もあります。
白石 それはすごいですね。ちなみにパフォーマンスがそこまで重要である、という認識は、日本で今どれくらい浸透しているとお考えですか？
竹洞 うーん、エンジニア界隈にはそれなりに浸透しているとは思うのですが、全体でいうと2割くらいの浸透度じゃないですかね…。そして、「浸透していない」というのは、「パフォーマンスの重要性に確信が持てなくて投資に至らない」というレベルではありません。単純に「知らない」ということが多いです。パフォーマンスについて考えたこともない、という。
白石 なるほど…。もう少し「パフォーマンス大事」という認識を広めたいところではありますね。この記事が多少なりともそのお役に立つといいんですけど。
あなたが統計を学ぶべき理由
白石 では、パフォーマンスが大事だという前提に立って、パフォーマンスの問題を解決しようとしたら、まずは原因の調査からですよね。具体的に言えば測定という話になりますが、竹洞さんは統計に関する知識を学ぶべき、と普段からおっしゃってますよね。これはなぜですか？ツールが生成するグラフやアドバイスに従うだけではいけないんでしょうか？
竹洞 まずですね、パフォーマンスの原因を調べるにあたっては、「先入観を持たない」ことが重要なんです。私の経験から言うと、パフォーマンスの問題を抱えたお客様は、まず「データベースが原因だと思う」と必ずおっしゃいます。でも、ちゃんと調べてみると違ってみたりする。統計学を学ぶと、こういう「バイアス」との付き合い方も学びますので、先入観を持って事に当たることが少なくなります。
白石 なるほど。
竹洞 あと、統計を学ばずにデータに当たると、「データに騙されちゃう」ということが往々にしてあるんですね。「データは何も語らない。語るのは人間である。」という言葉があるんですが、データを解釈して行動に繋げるのは人間なのです。統計について学んでおくと、そこで誤った判断をする可能性を下げることができる。
また、そもそもデータが正しいのか、という問題もある。正しくないデータに基づいても、有意な判断は下せないわけです。ただここで一つ重要なのは、「真の値」を知ることなんてそもそもできないわけですよ。いろんなゆらぎもありますから、一意に定まるわけがない。絶対ズレている。だからその、神様しか知り得ない「真の値」から、得られたデータがどれだけズレているのかを推測し、それも含めて判断が必要になるわけです。
ちなみに、こういう「ズレの推測」も含めてデータを扱うことを「推測統計」、一方、得られたデータをただ（グラフなどに）記述して扱うことを「記述統計」と言います。
白石 推測統計まで行うことが望ましいってことですね。
竹洞 そうです。とはいえ、まずそもそものデータを信頼度高く取るに越したことはない。そのために、近代統計学の確立者で、実験計画法という手法を編み出したロナルド・フィッシャーは、「3つの原則」を打ち出しています。その原則とは、以下の3つです。
- 反復…長期間に渡り、繰り返し採取する。
- ランダム…単純無作為抽出を行い、計測を行った値同士が影響を及ぼさないようにする
- 層別…変数を局所化し、影響を見たい変数だけ可変にする
こういう知識があるのとないのとでは、データやグラフに対するスタンスが全然違ってきます。「バイアスを排除して、先入観を持たない」「正確性の高いデータに基づき、精度の高い判断を行う」といったスタンスを身につけるためにも、統計をきちんと学ぶことはお勧めしています。
なぜGoogle Analyticsでパフォーマンスを測ってはいけないか？
白石 竹洞さんは、Google Analyticsとかでは、パフォーマンスを正確に計測できない、と以前からおっしゃっていますね。その理由を教えていただけますか？
竹洞 まず、GAで「遅い」という問題に気付けたとしても、原因追求ができないんです。原因となりうる要因が多すぎるし、絞り込むこともできない。 もう一つは、欠損値が多いことです。遅いということはそもそもGAのスクリプトが読み込まれていないことも多い。そういうのが全てデータから抜けてしまうんですね。
白石 なるほど。遅いなーと思ってリロードしたり、途中で離脱したりしちゃうと、そもそもそれがデータから漏れてしまうんだ。
竹洞 そうです。その影響は実は大きくて、データにバイアスがかかってしまうんですよ。本来注目すべき「遅い」データが見えなくなってしまう。 その状態でデータを眺めると、問題が隠蔽されてしまう。こうなると、アメリカの鉄道と同じです。
白石 どういうことですか？
竹洞 アメリカの鉄道が廃れた理由って、遅延やサービスの低品質に利用客も慣れてしまい、不満が上がってこなかったことにあると言われているんです。 で、不満が上がってこないから、企業は「顧客は満足している」と判断し、更にコストカットなどを進めてしまう。その結果、鉄道が衰退してしまった。
白石 なるほど…。GAで欠損値が出るだろう、というのは想像できていたことではありますが、それが経営判断を誤る一因にまでなりうるということですね。 では、パフォーマンスを測定するにあたって、良いサービスはありますか？
竹洞 たくさんありますよ。例えばcatchpointやdynatraceとか。こういったサービスは、実際のユーザー群に近い環境を国ごとに構築していて、継続的にデータを収集してくれます。こうしたサービスで得たデータと、GAで得られるパフォーマンスデータって実際にかなり開きが出てくるので、面白いですよ。
Webページの遅延原因の80%を占めるのは…？
白石 では、もう少し具体的に、パフォーマンスボトルネックの原因や改善方法についてお話を伺っていきたいと思います。Webサービスのネットワーク遅延の原因は、フロントエンド、ネットワーク、バックエンドに分かれると思いますが、バックエンドの話は原因も多岐に渡りそうですし、時間もないので、今回はフロントエンドとネットワークに絞ってお話を聞かせてください。
まずはフロントエンドからいきましょうか。
竹洞 はい、ではまずは前回の座談会でもお話したとおり、Webページの遅延原因の80%はサードパーティから読み込むリソースにあります。
白石 それって、例えばCDN (Contents Delivery Network) からjQueryのJavaScriptファイルを読み込むとか、ソーシャルボタンとか、広告とかいろいろありますよね。
竹洞 はい。で、あえて言うならやはり広告とかですかね。広告のパフォーマンスを見てみると、サーバーのDBがボトルネックになってるんだろうなあ…とは推測しています。そうなると、こちらでは手が出しようがないんですよね。広告を配信している企業に直接改善を要求するしかない。
白石 なるほどー。じゃあ、パフォーマンスの観点から言うと、やはり広告はボトルネックになりやすいと。ほか、「いいね！」ボタンとかのソーシャルボタンや、CDNで配信されてる静的なリソースとかはどうなんでしょう？
竹洞 ソーシャルボタンも遅いですよ。ソーシャルボタンのスクリプトって、キャッシュの時間も15分くらいと短いものが多いので、ネットワークアクセスが増加する一因にもなりますしね。CDNについては…いろいろあるので、あとでじっくり語らせてください(笑)。
ちなみに、アメリカだとサードパーティのスクリプトと言えども、速いんですよ。遅いと（ユーザー企業に）呼び出されるから(笑)。
白石 そうなんですか！アメリカだとユーザー企業の意識も高いんですかねえ。逆に言うと、日本の企業はそこまでパフォーマンスに対する意識が高まってなくて、結局遅いサイトが多数を占めるようになってしまってる、ってことなんでしょうか。
竹洞 そういうことです。あとはフロントエンドで言うと、画像じゃなくてもいいものを画像にしてる、ってのがすごく多いです。ちょっと秘密の資料お見せしますけど、ほら。これ全部画像ですよ。誰でも知ってるような企業のサイトなんですが…。
白石 CSSとかでできそうなものばっかり…
竹洞 そうなんです。HTML5やCSS3のおかげで、Webのポテンシャルってすごく広がりましたけど、そもそもそのポテンシャルが全然理解されてないんです。残念ながら。
ミニファイは不要？目からウロコのパフォーマンス改善術あれこれ
白石 では次は、ネットワークのパフォーマンスについてのお話を聞かせていただければと思います。ネットワークのパフォーマンスって、転送量、転送速度、転送距離の話に分けられると思います。
まずは転送量の話からいきましょうか。ここは、例えばJavaScriptやCSSのミニファイや結合、画像の最適化など、すでに読者に馴染みのある話も多そうなので割愛してもいいでしょうか？
竹洞 あ、一つだけいいですか？実際のところ、実はスクリプトのミニファイとかって、あんまり必要ないんです。
白石 ええっ！そうなんですか？そこを頑張ってるエンジニアたち、ぼくも含めていっぱいいると思うんですけど。
竹洞 もちろんやらないよりはやったほうがいいですけど、パフォーマンス全体から言うと、あまり効果のある施策ではありません。そこに開発コストを投じるべきかどうかは疑問ですね。
それよりもやはりネットワークアクセスの回数、もっと厳密に言えばTCPの3ウェイハンドシェイクの回数の方が重要。で、そこを改善すべくHTTP/2などのプロトコルが登場したわけです（筆者注: HTTP/2は、1本のTCP接続内で複数のHTTPメッセージのやり取りを可能にする）。
ちなみに私としては、HTTP/1.1とHTTP/2は、Webサーバのリソース特性や配信対象地域などを分析した上で、適切に使い分けてほしいですね。
白石 え、そうなんですか？全部HTTP/2にすればいいのかと思ってました。
竹洞 近所のスーパーに車で行くか、自転車で行くかってなると、自転車のほうが速い場合も多いわけじゃないですか。それと同じで、条件によっては、実はHTTP/1.1の方が速い場合も存在します。
白石 具体的にはどんな条件でしょう？
竹洞 ネットワーク距離、リソース配信サーバ数、オブジェクト数、転送容量などですね。ネットワーク距離の観点では、HTTP/1.1は近いほど、HTTP/2は遠いほど有利です。リソース配信サーバ数の観点では、HTTP/1.1は多いほど、HTTP/2は少ないほど有利です。単純にオブジェクト数だけを考えると、HTTP1.1は少ないほど、HTTP/2は多いほど有利です。
白石 じゃあ、例えば先ほどから話に上がってるサードパーティのスクリプトなんかは、ドメインもバラバラだし、アクセスはほとんど1回こっきりだし、HTTP/1.1が活きてくる分野かもしれませんね。
CDNは遅い？？？？？？そして「ADN」ってなんだ？
白石 あと、先ほど「後で語る」とおっしゃっていた、CDN (Contents Delivery Network)についてもお話いただきましょうか。
竹洞 CDNについては、実際のところを知ると、皆さん驚かれると思いますよ。実は、CDNはもう速くないんです。
白石 えっ…！そうなんですか？ちょっと意味がよくわからない。
竹洞 ネットワークに対する投資額の規模を表した図としては、こういうものがよく使われます。上がファーストマイル、事業者に最も近い部分で、サーバーやクラウドに代表されるレイヤーです。一方一番下がラストマイル。ユーザーに最も近い部分ですね。
この図を見てわかる通り、ラストマイルとファーストマイルには多くの投資が行われてきました。エンドユーザーに近い部分のネットワークは、相当高速化されてきている。
以前はCDNは、ラストマイルを高速化するためのサービスとして有力でした。ただ、業界全体でラストマイルに多くの投資が行われた結果、CDNの有用性そのものが薄れてしまいました。なので、CDNに置くよりも自前で配信したほうが速いという状態が一般的になっているのです。
白石 そうなんですか。CDNが速くないなんて…。
竹洞 なので、CDNのベンダーは速度じゃなくてロバストネス、堅牢性をウリ文句に変えるところも出てきています。ただそれは、第一世代のCDNと言われていたサービスの話です。
Fastlyに代表される第2世代のCDNは、POPs (Points of Presense:CDNのサーバーを物理的に配置する位置)を最適化するというアプローチで、大きくこの分野を前進させました。
そして今、この分野は第三世代に入ろうとしています。Instart Logic社なんかはその代表で、私もエヴァンジェリストを務めていますが、自身を「Application Delivery Network」と呼んでいますね。
白石 それは、具体的にはどう違うんですか？
竹洞 ひとことで言うと、非常にインテリジェントなのです。まずサーバー側では、機械学習を用いて基地局ごとに最適な経路を割り出すので、非常に動的な最適化が行える。
また、クライアントとサーバーがコミュニケーションしながら、リソース取得の最適化を図ります。具体的には、クライアント側に「ナノバイザー」と呼ばれるJavaScriptのエージェントを走らせます。ブラウザ側の仮想マシンと言ってもいい。そのナノバイザーが、サーバーと様々な情報を常にやり取りしながら、リソースの最適な取得方法を探るわけです。
白石 なるほど。そういうことをするには、クライアントとサーバー間でステートフルなコネクションが必要になりそうですが、そこはどうしてるんですか？WebSocket？HTTP/2？
竹洞 HTTP/2です。HTTP/2をフル活用して、初めて実現するアーキテクチャですね。他にも、サーバ側でJavaScriptコードを分析して必要な関数のみをクライアントに送るといったアグレッシブな転送量削減や、サードパーティ製スクリプトを自分のドメインから配信してHTTP/2の恩恵を最大限受けることも可能です。
白石 それはすごい。
竹洞 モバイル向けのライブラリとかもあるのですが、本当に高速ですよ。速度のためにTCPの代わりにUDPを使用していて、そうなるとパケットのエラー検知と再送制御が必要になるわけですが、一定のパケット数ごとに誤り検知のためのチェックサムを付与して、ライブラリ内でエラー制御することで解決しています。
白石 機械学習やHTTP/2といった、基盤技術の進化をフル活用して、コンテンツの配信をこれまでにないレベルで最適化するというわけですね…。面白い。
「パフォーマンス・バジェット」というパラダイムシフト
竹洞 あと、パフォーマンス業界の最新動向という点でいくと、アメリカでは「パフォーマンス・バジェット」という考え方が浸透してきています。
白石 なんですかそれは？初めて聞く単語ですが。
竹洞 パフォーマンスの目標を立てると、使えるリソースの量は限られてくるわけです。例えば、前回の座談会でもお話した「モバイルで3秒以内に表示を開始するためには、リソースを200kb以内に抑えるべき」といったように。で、そのリソースをどう割り振るかをサイトの設計段階から計画しておくという考え方です。（筆者注: パフォーマンスバジェットについては、ミツエーリンクスさんのブログに詳しい紹介があります）
白石 その考え方は面白いですね！全然知りませんでした。そして、そういう概念が出てくるくらい、海外ではパフォーマンスの重要性が浸透しているということなんですねえ…。パフォーマンスを「リソースの量」という点で定量化することで、リソースのサイズやフェッチのタイミング、開発コストの投下量など、いろんなものをコントロールできるようになりそうです。
うちみたいなスタートアップ企業（TechFeedというサービスの運営企業）とかだと、機能実装が優先になっちゃって、パフォーマンスという項目がどうしても優先順位上がらないんですが、そういう状況の改善にも役立つかもしれませんね。
竹洞 そうですね、パフォーマンス・バジェットの考え方は、スタートアップにも有効だと思います。計測サービスにお金を払い続けるのが厳しい…という事業規模の企業にも有用かな、と。
白石 え、それどういうことでしょう？
竹洞 優秀な計測サービスって、やはりそれなりに高額なんですよね。規模の小さい企業だと、サービスを運営しながらずっと使っていくのは厳しい。 ただそれでもパフォーマンスを担保したいという場合、パフォーマンス・バジェットを見積もるために、最初だけ計測サービスを使用するということができるわけです。あとはそのバジェット内でリソースをやりくりするよう注意していけば、一定のパフォーマンスが担保された状態になります。
白石 なるほど。まずそもそも、パフォーマンス・バジェットを見積もるには、ある程度の計測と実績値が必要だと。そのために計測サービスに最初だけ課金するということですね。一旦見積もったバジェットを守りさえすれば、パフォーマンスが担保された状態になる、というのもロジカルでスッキリしますね。
品質保証（Quality Assurance）は今後重要なキャリアになる！
白石 では、お時間もかなりオーバーしてしまいましたが、最後に読者に向けて伝えたいこととかありますか？
竹洞 そうですねえ、私はパフォーマンスも含め、Webサイトの品質保証というところにずっと注力しているわけですが、今後このQA (Quality Assurance)という分野は非常に重要になると思っているのです。例えば、2019年に民法が改正されて、システム開発の受注側が品質保証の責任を負わなくちゃいけなくなります。現在の「瑕疵担保期間」という単語は条文から消えて、品質保証を行って納入しないと「重過失」という扱いになって、永遠に瑕疵責任を負うことになるんです。つまり、品質を満たすまで、タダ働きになるってことです。
白石 それはすごい変化ですね…。開発や制作を受託している企業にとっては大問題だ。
竹洞 こういうこともあるので、今後はQAのスキルが非常に求められてくるのは間違いありません。現在日本にはQAという職種がほとんどない状態ですが、だからこそQAを行えるエンジニアは非常に希少価値があると思います。それができるようになれば、今後のキャリアを考える上でも非常な強みになるのではないでしょうか。
白石 うーん、最後まで大変示唆に富む発言、感謝です。本日は大変勉強になりました。貴重なお時間を割いてインタビューに答えていただき、どうもありがとうございました！
