Webパフォーマンスについて

Webパフォーマンスについて記事を書いています。パフォーマンス管理は、品質管理です。ですから計測データを元に記事を書いてます。

Webパフォーマンスの振り返り 2017

2017年も、残り一か月となりまして、WebパフォーマンスのAdventカレンダーがスタートしましたので、今年のWebパフォーマンスの動向を振り返ってみます。

Googleさん大活躍

今年は、Webパフォーマンス(表示速度)の認知が浸透した一年でした。 その大きな要因は、やっぱり、Googleさんの活動ですね。 昨年のQ4に、Googleの大口顧客向けに、パフォーマンスの重要性を、役員クラスに直接会って説くと共に、今年は更に裾野を広げて、パフォーマンスの重要性を説いて回って、かなり認知が広がったと思います。

Googleさんが顧客に配布している資料を拝見したのですが、三つの事が書かれています。

  • Webパフォーマンス(表示速度)は収益に大きな影響を及ぼす
  • Webパフォーマンスを高速化しないと、オンライン広告の成果を最大化できない
  • Webパフォーマンスは、オーガニック検索に影響がある

その上で、Googleさんとしては、AMP (Accelerated Mobile Pages)やPWA(Progressive Web Apps)の普及を推進しています。 私個人の見解としては、今から数年先までを考えるのであれば、取り入れるべき技術だと考えます。 しかし、携帯網で5Gがリリースされれば、廃れる技術じゃないかなと考えています。

「5G」の鼓動

5Gネットワークは、3GPPで仕様策定が進められています。

5Gネットワークは、大きな特徴が三つあります。

  • ネットワークスライス … 必要とされる通信特性(レイテンシ重視、広域性重視、帯域重視)を鑑みたSDN技術を取り入れた用途別仮想ネットワークによる分割
  • ビームフォーミング … 電波が傘のように広域に「*吹く/飛ばす」のではなく、指向性のものが実装される
  • Mobile Edge Computing … 携帯網でのコンピューティングの開放

(*) 電波を「飛ばす」という表現を使ったりしますが、通信関係の方は電波を「吹く」という表現を使います。面白いですね。

5Gの実証実験もスタートしており、最近ですと、NTTドコモさんによる、Perfumeの東京・ロンドン・ニューヨークの三ヶ所に離れて同時にパフォーマンスする映像を5Gを使って中継し、リアルタイム合成するというライブが11月8日にありました。

Netscapeを開発したマーク・アンドリーセン氏が、「ソフトウェアが世界を飲み込む理由」 (Why Software Is Eating The World) に書いたように、どんな企業であっても、どんな産業であってもソフトウェアとは無縁でいられず、積極的に取り入れることで、「創造的破壊」を齎し、ビジネスをこれまでとは違う方法で成長させることが可能となるでしょう。

しかし、一方で、ソフトウェアは、ハードウェアの枠を超えることは出来ないという事も私達は認識しておくべきです。 ハードウェアの開発は、巨額の費用が掛かりますから、ハードウェアに手を出せる企業は少ないです。 しかし、ソフトウェアであれば、個人でも、ソフトウェアの力で世界を変える事ができます。

ソフトウェアの可能性は素晴らしいのですが、一方で、パフォーマンスの観点では、ハードウェア以上の性能を引き出すことは物理的にできないのです。

Webパフォーマンスにおいては、通信網も大きな影響を及ぼすため、フロントエンド技術だけではなく、ハードウェアや通信網の技術も定常的にウォッチして、学ぶことは非常に大事だと私は考えます。

Webパフォーマンス改善のニュース

日経新聞のWebサイトがパフォーマンス改善によって、大幅に向上した事は、Web関係者に大きな衝撃を齎しました。 その後、dev.toや、俳優の阿部寛さんのサイトの表示速度が話題になったりしました。

Webパフォーマンス関係の書籍

今年は、Webパフォーマンス関係の書籍が二冊、発売されました。

Webフロントエンド ハイパフォーマンス チューニング

Webフロントエンド ハイパフォーマンス チューニング

超速!  Webページ速度改善ガイド ── 使いやすさは「速さ」から始まる (WEB+DB PRESS plus)

超速! Webページ速度改善ガイド ── 使いやすさは「速さ」から始まる (WEB+DB PRESS plus)

二冊とも、"Don't guess, measure"の名言を引用されて、計測することの重要性を書かれていて、素晴らしいと思います。 Google PageSpeed Insightsは、ベストプラクティスの適用チェックでしかなく、実際の表示速度を計測しているわけではないというのは、是非、皆さんにもご協力頂いて、広く日本で認知されて欲しいです。

よく、表示速度についてのTweetやブログを拝見しますが、「Google PageSpeed Insightsで○○点」と書かれていて、残念さが満開です。

Webパフォーマンス(表示速度)の単位は、「点」ではなく「秒」ですよ、みなさん。 どんなに点数が高くても、実際の表示速度が遅ければ、無意味です。

Twitterを見ていると、「Webパフォーマンス」と書かれる方と、「表示速度」と書かれる方で、Webパフォーマンスに関する理解度が大きく異なるように思います。

Webパフォーマンス管理とプロファイリングは別

今まで、Webパフォーマンスが認知されてこなかった日本ですが、ようやく認知されてきたので、少しだけ厳格なお話を。

Webパフォーマンス管理と、プロファイリングは別です。

Wikipediaでは、プロファイリングを以下のように説明しています。

In software engineering, profiling ("program profiling", "software profiling") is a form of dynamic program analysis that measures, for example, the space (memory) or time complexity of a program, the usage of particular instructions, or the frequency and duration of function calls. Most commonly, profiling information serves to aid program optimization. Profiling is achieved by instrumenting either the program source code or its binary executable form using a tool called a profiler (or code profiler). Profilers may use a number of different techniques, such as event-based, statistical, instrumented, and simulation methods.

ソフトウェアエンジニアリングにおいて、プロファイリング(「プログラミング・プロファイリング」、「ソフトウェア・プロファイリング」)とは、動的プログラム解析の一種で、例えばプログラムの空間(メモリ)とか計算時間、特定の命令の使用、関数呼び出しの頻度と時間経過を計測する。通常、プロファイリングの情報は、プログラムの最適化の助けとなるために提供される。プロファイリングは、プログラムのソースコードや実行可能バイナリのどちらかをプロファイラー(もしくはコードプロファイラー)と呼ばれるツールで計測することで成される。プロファイラーは、イベントベース、統計的、計測、シミュレーション手法など、多数の異なるテクニックが使われる。

私が皆さんにお伝えしたいのは、ChromeFirefoxIE/EdgeなどのDeveloper Toolは、プロファイラーであって、パフォーマンス計測ツールではないという事です。

「え?何を言ってるの?」と思われる方もいらっしゃると思います。 そこで、自動車の例で説明します。

皆さん、自動車を買うのは、いつがベストかご存知ですか? 自動車メーカーの方に訊いたら、「モデルチェンジの直前」と教えて頂きました。

どういう事かというと、自動車は、大きく分けて、三つの過程から成り立ちます。

  1. 開発
  2. 生産技術
  3. 生産

詳しくは、トヨタ自動車「クルマができるまで」をご覧下さい。

この2番目の「生産技術」に注目して下さい。

生産技術には3つのステップがあります。

  1. 生産性検討
  2. 工程計画→設備検討→設備調達
  3. 設備トライ→品質確認→量産化

生産技術の箇所で、このように説明が書かれています。

高い品質のクルマづくりを実現するためには、ハイレベルな生産技術が必要となります。デザイン部がイメージした美しいスタイリングを生みだすためのプレス型や、ボデーの骨格を精密に造りだす組付治具、溶接・塗装ロボットを生産ラインに投入することで、高品質、低コスト、多品種少量生産、作業者に優しい生産ラインが実現できるのです。日々、クルマとともに進化する生産ラインを生みだす生産技術力。完成度の高い車の生産をトータルで考える私たちは効率の良い生産ラインを構築するための設備計画やライン編成計画も手がけています。

設計できたからといって、そのとおりに作れるか?、また設計どおりに作って高品質になるか?というのは、作って検証してみないと分かりません。

皆さんがWebサイトを構築して、リリース前にChrome Developer Toolなどでパフォーマンスをチェックするのは、この生産技術の中の「(3)設備トライ→品質確認→量産化」に該当するのです。

自動車生産における品質管理は、一般には、「3. 生産」の検査の工程として有名です。 最近、ニュースで、ここの検査を資格を持っていない人がやっていたという不祥事がありますけど、Webパフォーマンスに関しては、検査すらしていないところが多いわけでして…

ところが、実は、自動車メーカーの品質管理は、生産における検査だけではないのです。 生産で発見した設計上の不具合がフィードバックされるだけではないのです。

メーカーから直接、新車で自動車を購入すると、メーカーにもよりますが、法定検査の1年だけではなく、購入してから1か月、6か月に無料定期検査があります。 この無料の定期検査で、実際に走行してみた結果、発見したことを、また設計や生産技術へとこまめに反映するのです。 もちろん、修理に持ち込まれた自動車からも、そういった発見したことなどがフィードバックされます。

ですから、自動車は、同じモデルであっても、製造時期によって、細かに修正が加わっていくのです。 それで、モデルチェンジ直前が、ソフトウェアでいうところの「枯れた状態」、つまり最も良い状態というわけなのです。

これは、自動車に限らず、製造業では広く行われているプロセスです。

プロファイリングとWebパフォーマンス管理の違いは、上記を踏まえて、以下の図をご覧頂くとご理解頂けると思います。

f:id:takehora:20171201152437p:plain

この図を見れば、DevOpsでWebパフォーマンス計測・管理が入っている理由が分かるかと思います。

Webパフォーマンス管理は、実験計画法に基づいて、ユーザの分布に応じて、ISPを選出し、計測環境を統一して、24時間365日定常的に計測して行われるべきものです。 それを、合成計測/監視(Synthetic Monitoring)と言います。

何故、合成と言うかというと、Synthetic dataというものがありまして、ある状況下において、こちらから能動的に対象に働きかけて得るデータを指します。

Webパフォーマンスにおける「真の値」

これを理解するには、統計学における「真の値」の概念を理解する必要があります。 私達が計測によって得ている表示速度に関する値は、様々なノイズが入った値です。 これを見てグラフにしたりするのは、「記述統計」と言います。

しかし、分析して改善するとなると、記述統計ではなくて、推測統計、つまり真の値を得るためのモデリングが必要になります。 ですから、できるだけノイズの影響を排除して、真の値に近づくようにするのが、実験計画法のブロック化です。

そうはいっても、真の値自体が揺らいで、単一のサーバやリクエストであれば、正規分布のような分布を描き、複数のサーバやThird-partyを利用している場合は、それぞれの分散が合成されて、右に裾を引く分布になるわけです。 私達は、計測データから、「真の値」の分布へと確率的に近づいていくわけです。

さて、そこで問題になるのが、「Webパフォーマンスにおける真の値とは何か?」という定義です。

サーバから、エンドユーザのブラウザ上まで、ネットワークの距離に従って変化する表示速度の、どの箇所を計測することが「真の値」として扱うに相応しいのでしょうか?

ユーザサイドから見れば、「私が体験した速度こそが、真の値でしょう?」とおっしゃるかと思います。 しかし、そのように定義づけると、ユーザのアクセスが無ければ、Webパフォーマンスの値は存在しないという事になります。 そう、Webサーバはあるけれど、アクセスが無ければ、Webパフォーマンスの値は存在しないというのは奇妙ではないですか? だから、合成計測なのです。こちらから定常的に能動的にアクセスをして、値を生成させるわけです。

もう一つ、品質管理においては、コントロールできる範囲とコントロールできない範囲を定めて行います。 ISPまでは、Webサイト側で、お金があれば、CDNを導入したり、トランジット回線を引いたりと、何とかコントロールできる範囲です。 しかし、エンドユーザについては、遅いからといって、光回線を引いてあげたり、より高速なPCやスマートフォンを買ってあげるわけにはいきません。 ですから、管理できる範囲の一番ユーザに近い箇所である、ISPで実験計画法に基づいて計測する、これが合成計測なのです。

このようなデータをActionable Data(実行可能データ)と呼びます。 実行可能データとは、実際に「使える」、つまり、そこから知見を得られて、次の行動へと繋げられるデータです。 RUM (Real User Monitoring)で得られたデータは、確かに、実ユーザが実際に体験した表示速度を教えてはくれるものの、そこから具体的な分析ができません。 何故なら、ノイズが数多く含まれており、それが分解できないからです。

しかし、Synthetic Monitoringのデータは、実験計画法に基づいて計測されており、それも、管理できる範疇のISPでの計測データであるため、分析することによって、改善に際して具体的な行動へと移せるのです。

民法債権法改正が国会を通過

民法の債権法が5月に国会を通過し、正式に施行されます。 これによって、請負によるWebサイトの制作や、インターネット上で提供される各種サービスも、品質検査、品質担保が義務付けられます。

その際に、「Chrome Developer Toolでパフォーマンスの品質はチェックしてあります」なんて事は言わないようにしましょう。 理由は、上述したとおり、それは品質管理ではないからです。

来年は、プロファイリングとWebパフォーマンス管理の違いが、より広く認知される年にしたいです。

品質管理にご興味のある企業の方は、是非、日科技連の賛助会員としてご参加ください。