計測サービスで異なる計算能力

表示速度は計算能力に左右される

ページ作成日 2020年3月11日
ページ更新日 2020年7月3日
著者: 竹洞 陽一郎

Webページの表示速度を計測する時、皆さんは、何を使っていますか?
簡単にボトルネック診断をしたい時はGoogle PageSpeed Insights、WebPage TestやGTmetrixでしょうか？

各種計測サービスにおける、計測結果の「1秒」は同じ「1秒」でしょうか？
例えば、Google PageSpeed Insightsでの「1秒」と、iPhone11の「1秒」、Androidの「1秒」は同じでしょうか？
WebPage Testの「1秒」は、GTMetrixの1秒と同じ「1秒」でしょうか？

Webパフォーマンス(表示速度)は、計算能力に左右されます。
その計測サービスの計算能力が低いと、同じページを計測しても、表示に必要な時間が長くなります。
それぞれの計測サービスの計算能力を知っておかないと、数値を見て判断するときに、誤った解釈をしてしまいます。

各計測サービスの計算能力を確認する

Free online browser speed test

Free online browser speed testというツールがあります。

• Calculate(計算)
• Store(データ格納)
• Render(レンダリング)

これら3つについて、JavaScriptで計算を行い、スコアを算出して合計して出します。
スコアは、数字が大きければ大きいほど、高性能であることを意味します。

このテストの良いところは、ネットワーク処理が変数として入っていない点です。
このテストを使って、各種計測サービスの計算能力を確認しました。

テスト結果

テストは数回行っていますが、ほぼ数値は変わらないです。
理由は、大きな変動要因が無いからです。
ネットワークが絡むと、変動要因として大きいですが、計算だけなら、CPUとメモリでほぼ決まります。

もちろんある程度、数値はバラツキます。
しかし、大きな変動は無いというのが大事な点で、この手のテストは繰り返しても、あまり意味がありません。

※5G対応AndroidモデルのLG V60とGalaxy S20を追加しました。(2020/7/3)
※GoogleのリファレンスモデルとなるPixel 4 XLを追加しました。(2020/7/4)
※GoogleのリファレンスモデルとなるPixel 5を追加しました。(2021/3/26)
※AppleのiPhone 12 Pro Maxを追加しました。(2021/3/26)

考察

この結果で注目して欲しいのは、GoogleのLighthouse、PageSpeed Insight、TestMySite、などの性能が非常に低いという点です。
そして、Galaxy A20のような安価なAndroid端末は、それらよりも性能が低いという点も注目して下さい。

さて、あなたは、どこに基準を置きますか？
iPhoneでしょうか?
それともAndroidでしょうか?

iPhoneユーザをターゲットにするなら、GoogleのLighthouse、PageSpeed Insight、TestMySiteなどのテストは、性能が低過ぎます。
Androidユーザをターゲットにするなら、逆に性能が良すぎるのです。

では、どこに基準を置いたら良いのでしょうか?
答えは、「できるだけ高い計算能力で計測する」です。
高い計算能力のあるマシンで遅延したら、確実に遅延であると判断できるからです。

性能の高いマシンで、性能の低いマシンの性能をシミュレーションすることは可能です。
例えば、Chrome Developer Toolsでも、CPUの性能をシミュレートできます。
しかし、性能が低いマシンで性能の高いマシンをシミュレートすることはできません。

性能改善におけるボトルネックの判定と、端末の計算能力に依存する性能の減衰は、分けて考える事が大事です。
Googleを含めて、「遅い性能の端末で計測することが大事」と主張する人が居ます。
では、計算能力が低い端末を基準にWebページを作成しても良いのでしょうか？

ECサイトや、B2Bの商品やサービスを紹介するサイトでは、高解像度の画像を使いたい、動画を掲載したいという希望を伺う事が多いです。
Webサービスや、メディアサイトでは、どうしても使用するJavaScriptの数が増えます。
Webページ上で、どこまでデータ量を増やして、魅力ある分かりやすいページにするために、どれ位の計算負荷に耐えられるかを、ユーザの使っている端末の統計データ解析によって分布を明らかにすることが求められます。

遅い性能の端末の対策は、パフォーマンスチューニングとは別に考えるべきものです。
例えば、アダプティブWebデザインというアプローチがあります。

アダプティブWebデザインとは

アダプティブWebデザインとは、レスポンシブWebデザインのように単一ファイルで、全ての端末や画面領域に対応するようにWebページを作成・生成するのではなく、端末や画面サイズ、またユーザの需要に応じて、個別にWebページを生成する技法です。
そのアイディアは2010年ぐらいから広まり、私がKeynote Systemsで働いていた頃、2013年の会社のKickoff Meetingで米国の大手メディア企業の方が講演でアダプティブWebデザインを実際に運用していると仰っていました。
モバイルのキャリアによって、また時間帯によって、通信状態や速度が異なるため、端末情報やキャリア情報、時刻によって、動的にコンテンツを組み立てて配信する量をコントロールしているという事例でした。

Wikipediaで以下のように説明されています。

Adaptive web design (AWD) promotes the creation of multiple versions of a web page to better fit the user's device, as opposed to a single static page which loads (and looks) the same on all devices or a single page which reorders and resizes content responsively based on the device/screen size/browser of the user.
This most often describes the use of a mobile and a desktop version of a page (or in most cases, the entire site), either of which is retrieved based on the user-agent defined in the HTTP GET request.
Adaptive web design was one of the first strategies for optimizing a site for mobile readability, the most common practice involved using a completely separate website for mobile and desktop, with mobile devices often redirected to the mobile version of the site served on a subdomain (often the third level subdomain, denoted "m"; e.g. http://m.website.com/).
Today the use of two separate static sites for mobile and desktop viewing is being largely phased out, with server side scripting instead utilized to serve dynamically generated pages or to dynamically decide which version of a static page to serve, although the use of independent sites for mobile and desktop can still be frequently observed.
While many websites employ either responsive or adaptive web design techniques, the two are not mutually exclusive, and best practices for the most universally readable designed content employ a combination of the two techniques to support a complete spectrum of hardware and software.

アダプティブWebデザイン(AWD)は、全てのデバイスに同じ(見た目も)ページを読み込む単一の静的ページや、ユーザのデバイス/画面サイズ/ブラウザに基づいてコンテンツの並べ替えやサイズ変更を行う単一のページとは対照的に、ユーザのデバイスにより適合するようにWebページの複数のバージョンの作成を推進します。
これは殆どの場合、(または殆どの場合、サイト全体で)モバイルおよびデスクトップ向けバージョンのページの使用を表し、どちらの場合も、HTTP GETリクエストで定義されたユーザー・エージェントに基づいて取得されます。
アダプティブWebデザインは、モバイルでの読みやすさを目的としたサイトを最適化するための最初の戦略のひとつで、モバイルとデスクトップでまったく別のWebサイトを使用し、モバイル・デバイスがサブドメイン「m」で提供されるサイトのモバイル・バージョンにリダイレクトされることがよくあります。(例:http://m.website.com/)。
現在では、モバイルとデスクトップの表示に2つの独立した静的サイトを使用することはほとんど廃止されており、動的に生成されたページを表示したり、静的ページのどのバージョンを表示するかを動的に決定したりするために、サーバー側のスクリプトが使用されています。とは言え、未だにモバイルとデスクトップに独立したサイトを使用することが依然として頻繁に観察されています。
多くのWebサイトでは、レスポンシブWebデザインかアダプティブWebデザインのどちらかを採用していますが、この2つは相互に排他的なものではなく、最も普遍的に読み取り可能なデザインのコンテンツのベストプラクティスでは、この2つの技法を組み合わせて使用し、ハードウェアとソフトウェアの全領域をサポートしています。

アダプティブWebデザインは、日本ではあまり知られていませんし、海外でも下火になりました。
しかし、5Gの目玉の一つである、MEC(Mobile/Multi-access EdgeComputing)がスタートすれば、まずはAPIでの端末の性能や通信状態のデータ取得が可能になるので、また注目されるでしょう。
基地局に近い側でのコンピューティングによって、高速に、ユーザの端末や通信状態、またユーザの嗜好に合わせた画面生成を動的に行って配信できるようになるのです。

まとめ

• 様々な無料・有料のWebパフォーマンス(表示速度)の計測ツールがありますが、それぞれに基本性能が違うという事に注意しましょう。
• 品質管理としてのWebパフォーマンス計測を行う場合は、できるだけ性能の良いマシン・計測ツールを使う事が大事です。性能のボトルネックが明確に分かるからです。
• 遅い端末や遅い計測ツールを使うと、ボトルネックに見えている部分の因果関係が明確にできなくなります。
• シミュレートで端末の性能を遅くすることはできても、速くすることはできないです。
• 遅い端末の対策などを考えるのは、パフォーマンスチューニングとは別で、端末性能減衰対策となります。端末性能減衰対策は、パフォーマンスチューニングとは切り離して施策を考える必要があります。
• 端末性能減衰対策としては、アダプティブWebデザインという技法があります。今までは実現するのが難しかったのですが、MEC(Mobile/Multi-access EdgeComputing)の到来と共に、再度注目されるようになるでしょう。