PageSpeed InsightsとLighthouse(続編)

パフォーマンス計測ツールの一つであるLighthouseの計測値は、実行環境に左右されます。

例えばPSIを経由すれば、クラウド上で実行することを意味しますし、Chromeを経由すれば、そのchrome上で計測します。この環境差を踏まえ、計測値を分析する必要があります。また、Lighthouseのバージョンにも留意しなければならないでしょう。ただ、ここまで注意しても、計測値同士の隔たりを上手く説明できないことがあります。最終的にどちらを信用するべきかは、今のところ解決していない問題です。

ところでPageSpeed Insightsの新バージョンが公開されました。このv5で入手できるデータは以下の通りです。新PSIのデータ、Chromeユーザーエクスペリエンスレポートのデータ、lighthouseカテゴリデータ(パフォーマンスやベストプラクティス、SEO等)・・。今回のバージョン更新により、API利用者は自身のツールも更新しなければなりません。また、今後はLighthouseが勢力を伸ばすと考え、相応の準備をする必要もありそうです。因みにChromeのLighthouseは英語で対処する他ありませんが、PSIのLighthouseに限っては日本語で提供されており、日本人には有難いサービスです。

最後に改めて、パフォーマンス改善のための基本をご説明します。

ウェブを構成する要素の中で、データ量の多い順に並べると、画像、JavaScript、フォントの順です。当然パフォーマンスバジェットの考察対象としても、これらは大きな位置を占めています。それにもかかわらず、例えば画像を最適化できていないサイトは、山のように存在します。このデータ量を激増させる3つについてよく学ぶことが、パフォーマンスを効率的に改善する前提であると心得て下さい。

PageSpeed InsightsとLighthouse

パフォーマンス計測ツールとしてはお馴染みのPageSpeed Insightsが、Lighthouseを利用する運びとなりました。Lighthouseは言わずと知れた計測ツールで、PageSpeed Insightsと同じくグーグルが提供しています。

両者は仕組みが根本的に異なり、指標も同じではありません。目的も製作者も同じツールのどちらが信用に足るのかをめぐり、業界でも長年困惑していました。そこでグーグルも重い腰を上げ、今回の統一に至ったのです。

端的に言えば、PSIの分析にLighthouseの仕組みを採用しました。これにより、PSIはコンテンツの初回表示速度、スピードインデックス、インタラクティブに要する時間、ミーニングフルなコンテンツの初回表示速度、CPUの初回アイドル、入力反応時間等を計測できるようになりました。分析エンジンそのものが別物に変わったため、過去のPSIと並べては、当然信用できる結果が揃いません。その点は注意する必要があります。この新PSIはパフォーマンス改善方法を提案してくれますが、その根拠もLighthouseによるものです。

新PSIは他にも様々な機能を有しています。

例えば、コンテンツの初回ペイントに関して、ページ同士の比較を実行してくれます。この機能はChromeユーザーエクスペリエンスレポートの活躍によるのですが、元データは実際のユーザーの動きであり、予測値よりもはるかに役立ちます。因みにフィールドデータにある「提供元の概要を表示」では、Chromeユーザーエクスペリエンスレポートと比べた全体速度をレポートしています。これは従来のPSIでいうところの「Origin: コマンド」に当たるので、同様に利用することができます。

ところで、Lighthouseの計測値はChrome経由でも得られますが、この値とPSI経由のそれとは異なります。Lighthouseの実行環境が異なれば、結果も変わってしまうのです。

Chrome Dev Summit(続編 その2)

ECサイトのパフォーマンスを改善するためには、計測に関する戦略を立てることが欠かせません。集客、エンゲージメント、コンバージョン、再エンゲージメントのそれぞれに目標を設定し、そのために必要な指標を定めることが肝要です。例えば、集客であればPVの増加が目標となるため、Speed Indexが指標です。

エンゲージメントであればセッション当たりのPV増加が目標ですから、指標はMeaningful Paintでしょう。コンバージョンについてはシームレスな購入プロセスを目標とすることが一般的です。従って、指標は購入完了までの時間以外に考えられません。再エンゲージメントの目標はパーソナライズです。3P TTFBを指標とすれば事足りるでしょう。もちろん指標の別を問わず、パフォーマンスバジェトへの影響も無視してはいけません。

サミットでは、計測戦略の成功例が数多く取り上げられました。フランスのCdiscountのユーザーは、そのほとんどがモバイルユーザーであるにもかかわらず、売上が停滞していました。そこでマーケティングを徹底的に見直し、同時にベストプラクティスを共有することで、パフォーマンスの改善を目指しました。その過程でSpeedCurveとSlackを採用し、パフォーマンスバジェットが悪い時は、警告が自動的に発信されるように設定しました。その結果、モバイルのコンバージョンが跳ね上がり、ネイティブアプリを圧倒したのです。東南アジアのCarousellの例も驚くべきものでした。モバイルユーザーが3Gであることから、パフォーマンスの改善が急務だったのですが、デザイン、マーケティング、アナリティクスが一体となって取り組んだことにより、劇的な改善を達成しました。Carousellがパフォーマンスバジェットに設定した項目は、Critical-Path Resources、First Contentful Paint、time to Interactive、Lighthouseで、それらに注意した結果、サイトの表示に要する時間は65%減少し、オーガニック検索トラフィックは63%上昇したのです。

Chrome Dev Summit(続編 その1)

Chrome Dev Summitでは、ECサイトのパフォーマンス改善に成功した事例がいくつも紹介されていました。

航空券販売会社Justfly.comもその一つで、各部署が協働して、一つの目的のために尽力しました。まずPWAを承認してもらう必要があると考え、小さな実験を積み重ねてデータを蓄積し、結果を出しました。パフォーマンスの改善はコンバージョンを確実に高め、航空券予約件数は35%上昇したということです

パフォーマンス改善のためには、当然ながら相応の技術が求められます。しかし知識を蓄えているだけでは成功しません。長期にわたる戦略、短期の目標設定、及びそれらの符合が重要です。サミットでもWalmartの事例が紹介されました。

Walmartは長期戦略としてTTIの70%削減を、短期的目標としてJavaScriptの500kb削減、及びCSSの40kb削減を掲げました。その結果、短期の内にTTIが25%削減したのです。もちろんこれは長期戦略の一部にしか過ぎませんが、一定の成果として、戦略を評価する材料にはなり得たわけです。他にもeBayやairbnbの事例が挙げられ、ユーザーのクリック動向を予測し、Service WorkerやpostMessageを利用してナビゲーションを速めたケースや、クライアントサイドルーティングに移行した例が紹介されました。いずれも大変な成功を収めたということです。

部署同士が協力し、速度改善技術を担保することができても、今サイトに何が生じているのかを、正確に計測できなければ意味がありません。

そのためには、まず指標が共有できるものでなければなりません。指標の意味や取得手段が分からない部署が存在すると、連携は上手くいかないからです。また変化の全てを知るために、自動化ツールを採用することも必要です。さらに、ツールで得られたデータを有効活用できるよう、計測に関する戦略を練ることも忘れてはいけません。

Chrome Dev Summit

Chrome Dev SummitではECサイトのパフォーマンス改善について話し合われましたが、その中で事例として挙げられたのが、トラベルサイトExpediaのプラットフォーム刷新でした。

部分的にプラットフォームを新しくしても、古いプラットフォームが残っている限りユーザーはストレスを感じ、コンバージョンは上がらないという結論でしたが、ユーザージャーニーの一貫性が如何に大事であるのかを示した事例と言えます。古いものと新しいものとでパフォーマンスの速度が異なれば、ユーザーにサイト全体がちぐはぐであるとの印象を与えてしまい、そのユーザーは離れてしまうのです。

ユーザージャーニーの一貫性を損なわないためには、組織が協力し、構築技術を担保し、計測を怠らないことが重要です。

パフォーマンスを改善するためには相応のリソースを要するのはもちろんのこと、会社の一致団結も必要です。つまりエンジニア個々人に任せれば上手くいくものでもないのです。

実際部門間の足並みが揃わず、失敗している企業は多々あります。例えば、コンテンツを制作する部署が素晴らしいものを作り上げたとしても、画像の最適化に通じていなければ、ページの読み込みが遅くなってしまいます。

またマーケティング関連の部署が、広告を分析するためにJavaScriptを加えてしまっても、表示は遅くなります。表示の速度とは無縁と思われがちなデザイン関連の部署であっても、何かのきっかけで余計なプログラムを装備させる可能性があります。縦割りの弊害がパフォーマンスの悪化となって現れることが、お分かりになるでしょう。

サミットでは団結の成功事例として、フラワーショップ1-800-Flowersのそれが挙げられていました。完全なトップダウンで縦割りを崩し、マーケティングと技術とを統合して、パフォーマンス改善を目指したのです。