今、最もWebサイト運営に貢献できる指標、Webパフォーマンス(表示速度)

Webパフォーマンスとは

皆さんは、Webパフォーマンスという言葉をお聞きになった事がありますか？
昨今は、Webパフォーマンスより、Webの表示速度という言葉の方を耳にされる事が多いかもしれません。
しかし、グローバルでは、「Web Perfromance」と呼称されているので、是非、日本のWeb担当者の皆様も、「Webパフォーマンス」で呼び方を統一して頂けると幸いです。

Webパフォーマンスとは、2006年ぐらいまでは、Webページを構成するファイル群を全てダウンロードし切るまでの時間を指していました。
きっと、「4秒ルール」「3秒ルール」という言葉を聞いたことがあると思います。

これが、2010年ぐらいから、表示開始時間と表示完了時間へと変わりました。

表示開始時間

表示開始時間とは、Render Start(レンダリング開始)と同意義です。Webブラウザ上で最初の1ピクセルが表示された時間を指します。

表示完了時間

表示完了時間とは、Document Complete(ドキュメント完了)と同意義です。Webブラウザ上で表示に関する読込などの処理が終わった時間を指します。

現在は、指標値として、表示開始時間と表示完了時間が主に使われます。

その理由は、画像や動画など、多くのメディアファイルが多用されるようになるに従い、Webページを構成するページ容量が増大していく傾向にある一方、Webの表示速度を高速化する様々な技術手法が発達しており、ダウンロード容量＝ページの速度とみなすことが難しくなってきているからです。

また、W3Cで、MicrosoftやGoobleのメンバーが中心になって、Web Performance Working Groupが2010年に発足し、Webパフォーマンスに関する計測指標が制定されたことも大きな影響があります。

Webパフォーマンスの歴史

Webパフォーマンスについては、2006年にオライリーより発売された「ハイパフォーマンスWebサイト」や「続・ハイパフォーマンスWebサイト」を読んで知った方も多いでしょう。

しかし、Webパフォーマンス自体は、非常に歴史が長いです。

Webパフォーマンスは、1995年にアメリカのKeynote SystemsがWebパフォーマンス計測サービスを開始した事で、その歴史が始まります。

Webパフォーマンスは、システムパフォーマンスチューニングの一部であり、システムパフォーマンスチューニングは、更に歴史が古いです。

汎用機の時代から、パフォーマンスチューニングはビジネスとして存在していました。

Webパフォーマンス計測が、Webパフォーマンスの分野を拓いたという点に注目して下さい。

Keynote Systemsの計測システムは、製造業で普及している統計的品質管理の手法に則っていました。

パフォーマンスチューニングにおいて、統計的品質管理の考え方は欠かせないのです。

統計的品質管理としてのWebパフォーマンス

例えば、今、あなたが自社サイトのトップページを計測するとします。

計測する手法は、Chrome Developer Toolでもいいですし、WebPage Testでも、何でも結構です。

例えば、表示完了まで3秒かかったとしましょう。

その3秒は、どれだけ確かな値でしょうか？

• 24時間365日、3秒であると保証できますか？
• 日本全国、どこでも3秒であると保証できますか？
• どのISPでも、どの携帯網でも3秒であると保証できますか？
• どのブラウザでも、どの端末でも3秒であると保証できますか？

「そんな細かい事は知らない」と仰るかもしれません。

しかし、そこが重要な点なのです。

「24時間365日素早く手軽に利用できる」という点が、Webの強みです。

もしも、それが保証されない場合には何が起こるでしょう？

機会損失です。スーパーやコンビニエンスストアなどの小売業の方であれば、機会損失の恐ろしさは身に染みてご存じでしょう。

Webサイトは、アクセスがある都度、Webページを構成するファイル群をインターネットを経由して、相手のブラウザ上で組み立てる「製造工程」が発生します。

これが、従来のCD-ROMで配布されてインストールするソフトウェアとは大きな違いなのです。

だからこそ、24時間365日、定常的に計測して、この「製造工程」が許容範囲の時間内で行われているのかを調べなければ、保証はできません。

だから、統計的品質管理が必要なのです。

実験計画法とフィッシャー三原則

統計的品質管理を行うには、Webサイトの定常的なパフォーマンス計測が重要です。

パフォーマンス計測では、その値の正しさが重要です。

統計学では、「ゴミなデータからは、ゴミな結果しか出ない」と言われます。

どんなに計測データを取得しても、その値が正しいと保証されなければ、間違った方向へと結論を導かれてしまい、結果として、Webサイトの運営上、ビジネス的なダメージを受けます。

統計的品質管理においては、データの取得について、実験計画法というルールに基づいて、データ取得の設計が行われます。

現在の実験計画法は、組み合わせ論をベースに高度に発達しており、非常に難しいです。

ここでは、もっとも基本となる、実験計画法を生み出した現代統計学の父であるR・A・フィッシャーの「フィッシャー三原則」を取り上げます。

局所管理化

影響を調べる要因以外の全ての要因をできるだけ統一する。Webパフォーマンスであれば、計測機器の統一、回線帯域の統一など。また、層別といって、ISPや携帯網が違う場合は、データ分析において、きちんと分けるなど。

反復

この世界のどんなものであっても、値が1つに定まるという事はありません。かならずバラツキが生じます。値が1つに定まるのは、純粋数学ぐらいです。Webパフォーマンスの計測値も必ずバラツキが生じます。大事なのは、その分布を知る事です。分布の確からしさは、数回の計測では担保できません。できるだけ、多くの観測値を得る必要があります。（私の場合、実務では、1ISPあたり、15分に1回の頻度で計測し、一週間あたり約700の観測値、東京や大阪から計測して、2,100の観測値を使っています。）

ランダム化

観測値はバラツキが生じると書きましたが、そのバラツキが生じた原因は、何かしらの系統的な要因でしょうか？それとも偶然なのでしょうか？専門用語では、系統誤差と偶然誤差と言います。例えば、15分に1回の計測であれば、10:15、10:30、10:45というようにきっかり15分毎に計測するのではなく、多少時間をランダムにずらします。10:14、10:29、10:43という具合にです。これによって、系統誤差を偶然誤差に転化することが可能になります。

1995年にサービス提供を開始したKeynote Systemsは、このフィッシャー三原則に則って設計された計測システムであり、2014年にCEOによる売却で、もう一つの計測サービスで著名だったGomezと一緒になってDynatraceという会社になるまで、Webパフォーマンス計測のデファクトスタンダードとして君臨しました。

現在は、そのDNAは、Catchpoint Systemsに受け継がれており、CDN各社やVerizonなどのキャリア、GoogleやMicrosoftをはじめとする欧米やインドなどの大手企業のWebマスターが利用する、全世界に650箇所の計測拠点を持つ、世界最大のWebパフォーマンス計測サービスを提供しています。

Webパフォーマンス改善の効用に対する誤解

Webパフォーマンス改善でCV率が上がる?

世の中では、「Webパフォーマンスを改善してコンバージョン率が向上しました」と記事やプレスリリースが出たりします。

しかし、皆さん、因果を考えて下さい。

皆さんは、Webサイトの表示速度が速いから、その商品やサービスを買いますか？

商品やサービスがWebサイトで売れる、もしくは、記事やブログが読まれるのは、それらが魅力を持つからです。

決して、Webサイトの表示速度が速いからではないのです。

Webパフォーマンス改善は、機会損失を最小化する点にこそ意義があるのです。

よく「Webパフォーマンス改善をしたいけど、費用対効果が見えないと決済が下りません」と言われる事があります。

そうではなく、Webパフォーマンスを計測することで、皆さんが導入しているCDNや、各種Tag Manager、広告、効果測定の費用対効果を測るべきなのです。

Webパフォーマンス改善では、必ず計測を行います。

そうすると、本当の遅延要因が分かります。

自社のWebサーバから配信が遅延要因というのは、全体の20%ぐらいしかなく、殆どはWebサイトに導入したCDNであったり、他社サービスであることが殆どです。

お金を払っているのに、自社サイトを遅延させられている。

これほど馬鹿馬鹿しい事はありません。

計測をしていないと、そういうった事実を知ることができず、結果として、Webサイトに投じた資金が暗闇にばらまいたお金のようになってしまいます。

あなたがWebパフォーマンス計測で確認すべきは、そちらの費用対効果なのです。

Webパフォーマンス改善によって、効果を生んでいない、もしくは足を引っ張っている外部サービスを外す事によって、その分の費用が浮きます。

そして、あなたのWebサイト本来のビジネスパフォーマンスが引き出されたのを確認してから、Webパフォーマンス改善の費用対効果は計算できるのです。

Webパフォーマンス改善でSEOに効く?

7月にGoogleのSpeed Updateが適用され、Webパフォーマンスが検索順位に反映されるようになりました。

「SEOに効くから、Webパフォーマンス改善をやろう！」という企業も多いでしょう。

しかし、それは本当でしょうか？

基本的な検索理論やGoogleの出している論文を読んで学ばれると分かりますが、必ず分析にはモデルが存在します。

2016年までは、統計学の頻度主義のAmit Singhal氏がGoogleの検索部門の責任者でした。

2016年からは、統計学のベイズ統計のJohn Giannandrea氏が責任者として率いています。

頻度主義にしても、ベイズ統計にしても、その根っこの部分は同じです。

モデルを作り上げて、それに従って、推測や評価を行います。

よく、中学時代に描いたグラフ上に斜め右上に引いた一次関数の線を思い浮かべてみて下さい。極端に言うと、あれです。

さて、問題は、そのモデルに基づいて推測や評価を行った際に、コンテンツとして同価値であるけれど、完全にモデルの線上に乗っていないコンテンツがあった複数あった場合です。

その場合に、どのように順位を決定するでしょうか？

これは、統計分析で「残差」と言います。

この残差の処理で、Webパフォーマンスは使われます。

Googleのアルゴリズムの変更は、もちろん、Knowledge Vaultのようなモデルの変更もありますが、殆どは残差処理に関するものです。

ですから、Googleが常々、「コンテンツの品質が重要」と言っているように、まずは、ユーザが求めている検索意図に合致するかどうか（これを専門用語でAboutnessと言います）が、まず最初に計算処理されるところで、Webパフォーマンスについては、評価上、同価値のコンテンツである場合に使用される残差処理のパラメータであるという事はご理解頂きたいです。

ですから、SEOに対する効用としては、「あなたのWebサイトのコンテンツが、ユーザの検索意図に合致した価値あるもので、あなたのWebサイトと同価値のコンテンツを持つWebサイトがある場合に、高速化すれば効果がある」というのが正しい表現となります。

ちなみに、コンテンツ(情報)の価値については、定量的には情報理論、定性的には情報品質という学問分野がございます。

Googleの人達も、これらの学会に参画して論文を寄稿しています。

Webパフォーマンス改善手法に対する誤解

画像の軽量化で速くなる？

結論から申し上げますと、画像の軽量化が高速化に貢献できる割合は、非常に小さいです。

デスクトップサイトについては、サーバさえしっかりしたものを利用していれば、CDNを使わなくても大抵は高速です。

逆に遅いCDNを入れることで、遅延しているケースがあります。

モバイルサイトについても、日々、携帯網は変更が加えられており、下り50Mbpsの帯域を叩き出す基地局も増えました。

先日、大手町で計測をしたら、KDDIの4Gで下り70Mbpsでした。

弊社は、日本で唯一、3キャリアの4G回線でのモバイルサイトを24時間365日計測するサービスを提供していますが、そちらを計測結果を見ても、非常に高速になってきているのが分かります。

こういう情報も、フィッシャー三原則に基づいた定常計測を行っていればこそ、分かる事です。

現在は、画像の軽量化は、高速化のためではなく、MVNOの回線を使っているユーザ対策で行う事が多いです。

月末25日の給料日あたりに、使用容量が契約容量を超えて、回線帯域の使用制限が入ってしまうので、購買に影響するためです。

JSやCSS、HTMLのminify処理や圧縮で高速化する？

これは高速化しません。

Before/Afterの計測結果を見れば明らかです。

画像と同様に、それほど容量は速度を左右する変数ではなくなりつつあります。

HTTP/2で高速化する?

これも高速化しません。

Before/Afterの計測結果を見れば明らかです。

自社でも実証実験をしましたし、数々のお客様のWebサイトを計測してきましたが、HTTP/２で高速化したサイトは今までに一つもありません。

WordPressのプラグインやテーマを変えれば高速化する？

これも高速化しません。

大抵は、サーバのリソース不足や、サードパーティコンテンツに起因します。

PHPを7.xにして、最新のLinuxのカーネルのディストリビューションを使い、ハードウェアリソースがしっかり確保されていれば、デフォルトの状態で高速になります。

それ以外に高速化のための施策を行っても、殆どは誤差の範疇です。

CDNを導入すれば高速化する？

第三者機関による検証を導入前に行われる事をお勧めします。

CDNが必ず高速化できるわけではありません。

昨今の遅延要因の殆どは、サードパーティ（他社）のサービスによるもので、CDNが高速化できるのは、御社のWebサイトから配信されるオブジェクトだけです。

弊社でも、CDN導入前検証サービスを提供していますが、せいぜい20～30万円です。

年間1000万円以上を無駄にするより、はるかに有効だと思うのですが…

今こそ、日本のWebに科学を

私が、この記事を通して、皆さんに訴えたいのは、今こそ、科学的方法をWebサイト運営に取り入れましょう！という事なのです。

よく「科学的」と言われますが、科学的方法の定義をご存じでしょうか？

Wikipeidaでは、このように記載されています。

科学的方法（かがくてきほうほう、英語：scientific method）、科学的手法、科学的検証などと呼ばれているものについて解説する。科学のための方法である。科学的方法は、問題の発見、仮説の設定、それを測る手段、材料、実験による観察・データなどの結果、分析、結論からなる。アメリカ科学振興協会による1989年の『すべてのアメリカ人のための科学』によれば、科学的方法の特徴として論証と調査の過程があり、科学的学問の共通事項として証拠に立脚して仮説と理論を用いており、用いられる論理も似通っているが、相違点には実験対象だけでなく歴史データを用いるか実験を用いるか、また取り組む姿勢や、それぞれがどの仮説を重視しているかといった部分がある。適切な証拠から適切な推論を経て明確な結論に至る。

対象を実験によって測定するには、適切な測定手段が必要である。検出装置であったり、定量化の仕方であったり、統計的な設計であったり正しく測定できることが必要である。その結果が再現できること再現性も必要とされてきたが、現代では統計学が援用され再現できる程度を導き出すようになり、統計的な有意差があるかを判定することも目的となりうる。

科学的手法とは、統計的検証と密接な関係があるのです。

皆さん、今こそ、真に科学的な手法で、Webサイトの改善に取り組みませんか?

世界においては、Webパフォーマンス改善は、品質管理なのです。

「これをやれば速くなる」というような、お手軽な非科学的なものではないのです。

Webサイトはひとつひとつ違います。

だから、遅延する要因も違います。

計測して、統計的分析で、真の原因が見えてきます。

Webサイトの遅延原因は、今まで数多くのWebサイトを診断して改善してきましたが、サードパーティーコンテンツ以外は同一なものはありませんでした。

いつも予想外な原因ばかりです。

それを発見する度に驚かされるのです。

2016年の時点で、Webパフォーマンス計測のフィッシャー三原則に基づいた計測であるSynthetic Monitoring（合成監視）のマーケットは約1102億円市場でした。

これが年18.1%で伸びており、2021年には約2362億円市場となります。

Synthetic Monitoring Market worth 2,109.7 Million USD by 2021

また、日本においてはIT予算の5%ぐらいしか品質保証に使われていませんが、世界では約40%に達しています。

Proportion of budget allocated to quality assurance and testing as a percentage of IT spend from 2012 to 2019

品質管理は、決して、「コスト」ではありません。

品質管理は、利益の源、「プロフィットセンター」なのです。

私は、もう10年以上、Webパフォーマンスに携わっていますが、海外に進出した日本のWeb関係の企業がWebパフォーマンスの遅延で敗退しているのを見てきましたし、日本においても、海外から進出してきた企業にWebパフォーマンスの遅延で敗退しているのを見てきました。

皆さん、基礎強化より強いものはありません。

基礎をきっちりとやればこそ、その上に築くものが活用できます。

土台がグラグラしていては、どんなにその上に投資をしても、隙間から零れ落ちていくのです。

日本のWebについて、Webパフォーマンスの捉え方や考え方がガラパゴス化してきている現状を憂い、皆さんに提言としてこの記事を書きました。

私どものお客様のように品質管理としてのWebパフォーマンスに目覚めて、ご賛同いただき、真に効果のある改善を目指される方が増える事を祈っています。