Webパフォーマンスの振り返り 2020
コロナ禍と「新しい日常」のWebへのインパクト
今年、最大のWebパフォーマンスへのインパクトは、コロナ禍でした。 外出の自粛、在宅勤務への移行などにより、インターネットのトラフィックが急増し、インフラに対する大きな負荷となりました。 ネットスーパーやマスク販売のサイトは、急激なトラフィックによって遅延したり、アクセスできなくなったりしました。
在宅勤務増加が齎したトラフィックの急増
各社がトラフィックの急増の要因を分析していますが、概ね、在宅勤務の増加によるSaaSの利用、オンライン会議の利用で見解は一致しているようです。
トラフィック急増で露呈したインフラが弱いサービス
トラフィックの急増＝Webサイトの遅延と、単純な因果関係とならない点に注意する必要があります。 トラフィックが急増しても、遅延したWebサイトと遅延しなかったWebサイトに分かれました。 遅延したWebサイトの共通点は、データセンターにありました。
特定のデータセンターのネットワーク機器で、トラフィックを捌き切れず、パケットロスを出しているところにWebサーバがあるサイトは遅延したのです。
データセンターの契約については、可用性だけではなく、性能のSLAをきちんと確認された方が良いでしょう。
以下の図は、実際に、弊社のお客様が利用していたデータセンターのネットワーク機器で発生していた遅延とパケットロスの散布図です。
改善について交渉したのですが、約款が、品質保証を形骸化させており、改善を求めてもやるかどうかはデータセンター次第な状態になっていました。これは、データセンターと契約したシステム部の人たちも唖然としていました。
法人は、自然人と異なり、消費者庁の保護を受けられません。 法人は、商取引を行う商人ですから、自分たちで検証・確認して、自分たちの身をきちんと守らないといけないのです。 それは、商法526条で明確に定められています。
「パケットロスや遅延が発生していても、稼働しているのだから、過失は無い。品質に問題は無い」と言われないように、データセンターやIaaSの契約時には、性能についての条項も定められているか、確認する必要があります。
露呈した弱いネットワークのISP
もちろん、遅延要因は、データセンターだけではありません。 ISPも、インフラの弱さが露呈しました。
NTTについては、以前より回線についての問題点が指摘されており、NTTドコモを合併して、有線・無線をまとめたネットワークの販売戦略を考える上で、NGN周りをどうするかは大きな課題です。
アルテリアネットワークスは、USENのネットワークの品質の良さを売りにしていましたが、実際はパケットロスがVECTANTのネットワークで多発しているので、丸紅側のネットワークの遅延をどうするかが課題となるでしょう。
Core Web Vitals
Googleが、5月5日に、新しい指標として、Core Web Vitalを発表しました。
この指標の判定の数値に注目して下さい。
FIDは、100ms、CLSは0.1がGoodと判定されますが、LCPは2.5秒です。 これは、いびつな判定基準です。
- LCPが2.5秒というのは遅すぎます。
- FIDが100msというのは、人間の反応速度を考えると過剰です。
- CLSが0.3であっても、人の目には判断ができません。
あれこれ新しい指標を出しても、結局は、表示開始と表示完了が大事な指標です。 Googleが新しい指標を出しても、右往左往しない方が良いでしょう。
Google PageSpeed Insightsの問題点
もしも、Core Web Vitalを気にされるのであれば、Google PageSpeed Insightsではなく、Chrome Developer ToolsでのLighthouseの数値を見ることをお勧めします。
それは、Google PageSpeed Insightsの計測マシンは性能が悪く、且つ、ネットワークも遅いからです。
性能
計測機器の性能は、https://www.speed-battle.com を閲覧することで確認できます。 このサイトは、通信速度は判定に入っておらず、あくまでも計算能力のみでスコアリングしています。
上記のように、Google PageSpeed Insightsのマシンは、非常にスコアが悪いです。 皆さんのスマートフォンや、PCでの数値と比較してみて下さい。
このサイトは、ブラウザの性能比較にも使えます。
ネットワーク
計測機器のネットワーク帯域は、https://speed.cloudflare.com を閲覧することで確認できます。 アクセス元のIPアドレスから、最寄りのCloudflareのデータセンターへとアクセスさせて、ネットワークの帯域を測定します。 ただ、CloudflareのEdgeのマッピングが適切でない場合もあり、全てのISPが最寄りのデータセンターになるわけではないので、その点を留意する必要があります。
上記のように、Google PageSpeed Insightsのマシンのネットワークは非常に低速です。
Chrome UX Report Community Connector for Data Studio
自社サイトのWebパフォーマンスの統計的推移を確認したいのであれば、Chrome UX Report Community Connector for Data Studioがお薦めです。
これは、Chromeに仕込まれているデータ収集機能により、統計データがGoogleに送られており、一定規模のアクセス数があるサイトについて、Webパフォーマンスに関するデータ集計・分析ができるものです。
Chromeのみのデータであることに注意して下さい。
こちらにアクセスして、自社のURLを入力します。 (デフォルトで、https://が付与されます。httpでサイトを運用している場合には、明示的に、http://をつけます)
KPIとなり得る指標を見極める事の重要性
Googleが新しい指標を出したからと言って、それに追随しても、事業において、実際のプラスを齎さなければ意味がありません。
Webパフォーマンスの指標をKPIの一部として取り入れている企業は少ないと思います。 しかし、顧客からの問い合わせに対する一次回答までの時間や、顧客にどのくらいのスピードで情報を提供できたか等を営業上のKPIとして計算式に入れている企業はそれなりにあると思います。
Webサイトは、多くの企業にとって営業ツールとして存在しているわけですから、営業のKPIと同じく、表示速度も入れない方がおかしいです。 表示速度は、コンバージョン率や直帰率などに大きな影響があります。 では、表示速度をKPIに組み入れる際に、Core Web Vitalがふさわしいのかどうかは、実際にデータ分析をしないと理解できないです。
私は、Core Web Vitalはあまり意味がなく、
- HTMLのレスポンス
- 表示開始(Render Start)
- 表示完了(Load ≒ Document Complete)
の3つで十分だと考えます。
4.5Gの普及
日本全国で、携帯の4.5Gのエリアが拡大しました。 4.5Gという名称は、馴染みが無い方も居るかもしれません。 現在、全国で展開普及しているのは、LTE Advanced、LTE Advanced Pro等の4.5Gです。
既に多くの場所で、下り100Mbpsを超えていて、200Mbpsを超えている箇所もあります。 しかし、全ての端末で、この速度を享受できるわけではなく、新しい端末であればあるほどに速度が出ます。 ダウンロードも、CPUの処理能力に左右されるからです。
Google PageSpeed Insightsがシミュレートしている、下り1.6Mbpsでの計測は、現在の日本では意味がないです。
上記のグラフは、OpenSignalの「モバイル・ネットワーク・ユーザー体験レポート Japan 2020年10月」からのものです。 このグラフが示すとおり、3キャリアにおいては、下りは40Mbpsを超えています。
この3年ほど、調査してきて、3キャリアの特長が分かってきました。
OpenSignalの評価も同様となっています。
帯域よりレイテンシの方が重要な、動画、ゲーム、音声アプリについては、SoftBankがWinnerになっています。
帯域とレイテンシは、道路に例えると車線数と時速です。 どんなに車線数が多くても、道路での車の流れ（時速）が遅ければ、目的地に全ての車が到着するのは遅れます。
SoftBankのレイテンシは、27ms前後で、40ms前後のauや、60ms前後のドコモより高速です。
Edge Computing
CDN各社がEdge Computingのサービスについてマーケティング活動を行い、徐々に認知され始めました。
以下に、CDNやクラウドで提供しているComputingのサービスの一部を挙げました。
| サポートしている言語 | Cold Start時間 | リソース制限 | |
|---|---|---|---|
| Cloudflare Workers | JavaScript、Rust、C、C++、Go | 5ms以下 | 128MB RAM、タイムアウト無し |
| AWS Lambda@Edge | JavaScript、Python | 50ms | 128MB RAM、5秒タイムアウト |
| Fastly Lucent | JavaScript、Rust、C、C++ | 5ms以下 | ？ |
| Google Cloud Functions | JavaScript、Python、Go、Java | 最大10秒 | 最大4096MB RAM、600秒タイムアウト |
| AWS Lambda | JavaScript、Go、Java、Python、Ruby、.NET | 最大10秒 | 3008MB RAM、5秒タイムアウト |
| Azure Functions | JavaScript、Java、Python、.NET | 最大10秒 | 1536MB RAM、600秒タイムアウト |
計算処理を一部、Edge側に移動させるのは、今後、高速化を図る上での一つの手法として確立するでしょう。
現在、Mobile Edge ComputingのAPI策定が行われており、再来年ぐらいからは、5GのMobile Edge Computingが本格的にマーケティング活動を始めそうです。
標準化されたPublic APIについては、こちらで確認することができます。
HTTP/3
HTTP/3の仕様化が最終ステージを迎えました。
HTTP/2の遅延の問題を解決するために策定されたHTTP/3ですが、理論と実際は必ず異なる結果となります。 HTTP/3が本当に高速になるかどうかは、単に速度だけではなく、安定しているかという品質の面でも確認する必要があります。 HTTP/2も高速になると謳われて登場しましたが、結果は、HTTP/1.1には及びませんでした。
実際の運用監視での評価が必要だと考えています。
ARMの台頭
Appleの新しいMacBook Air、Pro、Mac miniにARMのM1が搭載され、ARMのパワフルな性能が世を驚かせました。 AWSは、ARMベースのサーバを提供しており、そちらに移行することで、パフォーマンス向上とコスト削減を成し遂げた企業も出てきました。
ARMへの移行は、それほど急激には進まないと思っている方もいらっしゃるかとしれません。
パリ協定が大きな影響を及ぼす
2020年10月26日、菅義偉首相は、所信表明演説で、温室効果ガスの排出量と吸収量を2050年にプラスマイナスゼロとする目標を表明しました。
世界では、CO2排出量削減に熱心な企業の株価は上昇しているのですが、日本企業は政府が積極的に対応しなかったこともあり、積極的ではなく、国際的評価が低くなっています。
今後、SDGsと共に、どのようにCO2排出量削減に取り組むかは、多くの日本企業にとっても課題であり、従業員が使うPCやサーバなどを、TDP(Thermal Design Power: 熱設計電力)が低いARMのCPUへと変更することは、従業員数やサーバ台数が多い程に、大きな効果が得られます。
今後、IT技術者も、他の産業の技術者同様に、SDGsにどのように貢献していくのかを考えるのは課題です。 エネルギー消費量を考慮して、システム設計を行う事ができるようになれば、企業のCO2削減目標にも貢献できます。
Webパフォーマンス管理は、統計的品質管理へ
今年、更に幾つかの企業が、Webの高速化サービスを開始しました。 Webパフォーマンスに関する市場が形成され、競争が生まれるので良い傾向だと考えています。 競争が生まれると、当然ながら、優劣の判断や差別化が必要となり、いよいよ日本でもWebパフォーマンスについての統計的品質管理の必要性が認知されるのではないかと期待しています。
何故、統計的品質管理が差別化に繋がるのか、具体的な例で示します。
下のデータは、とあるところが高速化したWebサイトのデータです。 私が経営しているSpelldataでは、表示開始0.5秒、表示完了1秒以内を全体の98%で達成することを契約に明記して高速化を行っています。 そこで、他にも表示完了1秒以内を達成目標として高速化のサービスを提供する企業が出てきました。
それは結構な事なのですが、実際に期待通りの結果が出ているのでしょうか？
下記のデータは、表示完了1秒を目標に、Webパフォーマンスの高速化サービスを行っている会社に依頼して高速化してもらった、とあるWebサイトのものです。 このデータを見る限りでは、Render Startが499ms、Document Completeが718msですから、目標を達成して高速化できているように見えます。
しかし、24時間の散布図を見てみましょう。 すると、21～24時を中心として、ポツポツと遅延が発生していることが分かります。
これが1週間になると、以下のような散布図となります。 遅延は、定期的に21～24時に発生しているのが、パターンとして分かります。
これが1ヶ月になると、以下のような散布図になります。
この散布図を見て、皆さんは、「高速化が達成できた」と判断するでしょうか？
1ヶ月分のデータを累積分布関数で見ると、56パーセンタイルでDocument Completeは1秒を超えています。 つまり全体の44%は1秒を超えているのです。
この高速化に、皆さんは代金を支払いますか？
これこそが、統計的品質管理が重要になる点です。
データセンターや、CDN業者、サーバ業者、ISP等でも、統計的品質管理を行っておらず、何か問題が生じても、平気で2～3回行ったTracerouteやChrome Developer Toolsのデータを証拠として「問題ありません」と言います。
これは、データを構成する標本の大きさと分布の関係、データのばらつき、データの確からしさ等に関する知識がないから、そのようなデータのとり方で良いのだと思ってしまうのです。
1998年4月1日より前に生まれた人たちは、統計教育を受けていない「平均値」でしか分析ができない世代と言えます。 データ分析が、企業において重要となり、分析する力は、企業の競争力を担う一つとなりました。 それなのに、分析する手法が「平均値」では正しく分析はできないです。 つまり、データ分析能力は無いに等しいのです。
品質管理としてのWebパフォーマンスチューニングは、高速化する事に意義があるのではなく、遅い配信を限りなく無くす事に意義があるのです。 品質管理とは、世の中に品質の悪いものを出さないようにするために行います。 速い時は速くなったが、遅い時は以前として遅いままでは、高速化したとは言えません。
パフォーマンスチューニングと統計分析は、必ずセットです。 統計分析ができなければ、真に高速化できたかどうかを正しく評価はできません。 もちろん、ボトルネックの分析などでも、因果関係を理解しつつ統計分析ができるかどうかで、全く異なる結果となります。
製造業の技術者にとっては、統計学や品質管理は必須の知識です。 同様に、ITの技術者も、是非、統計学を学んで、統計分析をできるようになりたいものです。
