Google Core Web Vitalsとページ速度のパラドックス――速度は本当にユーザー体験を語るのか

最近、Googleが来年から検索ランキングの算出方法を調整するという趣旨の記事をいくつか読みました。現在のアルゴリズムには「Core Web Vitals」と呼ばれるユーザーインタラクティブ性の指標が組み込まれており、そこにページパフォーマンス(表示速度)も加わる予定です。正直に言えば、「これは良くない考えだ」というのが第一印象でした。

「古い世代の偏見だろう」と思われたかもしれません。私自身も最初はそう感じたので、実際に確かめてみることにしました。GoogleにはGoogle Search Console(旧ウェブマスターツール)やPageSpeed Insightsなど、サイトのパフォーマンスをチェックできるサービスがいくつかあります。そこで自分の運営するサイトDedoimedoを実際に計測し、この記事をまとめました。

なぜページ速度は無意味なのか

このテーマについては、モバイルブームが始まるずっと前から何度も書いてきましたが、主張は今も変わりません。それどころか、ページ速度はユーザー体験を示す指標にはなり得ません。せいぜい、そのページを配信しているソフトウェアスタックの状態を反映する程度であり、言い換えれば「技術的な裕福さ」の指標にすぎません。

まず単純な数学の話から。100行のテキストと10枚の画像からなるページは、1,000行のテキストと100枚の画像があるページより小さくなります。他の条件が同一なら、データ量の多いページほど読み込みに時間がかかるのは当然です。しかし、それがコンテンツの中身について何かを語るでしょうか?何も語りません。

つまり、他の要素を排除すれば「コンテンツが少ない=速い」という図式になります。そして偶然か必然か、これは2014年頃から支配的になった現代ウェブの「低俗化」パターンとぴったり重なります。ちょうどモバイルインターネット(要するにスマートフォン)が爆発的に普及した頃です。

その結果生まれたのが、短い注意力と安易な消費主義です。正確で有用なメッセージを届ける努力の代わりに、できるだけ少ない文字数で済ませること。テキストではなく動画や画像で済ませること。もちろん、長く複雑な話題に向き合おうとしない大衆を飽きさせないためには、それが一番手っ取り早いのです。愚かな人々はビジネスにとって好都合です。無駄なものにお金を使いやすく、トレンドに流されやすく、操られやすい。こんにちは、利益さん!

第二に、ページの読み込み時間はページの性質について何も教えてくれません。フォームに入力するページと、ノルマン征服の歴史を解説するページでは事情がまったく違います。前者では純粋な速度よりも応答性が重要かもしれませんが、後者では速度はほぼ無意味な数値です。これは決して軽い話題ではなく、背後には深く複雑な科学があります。私自身も過去に真剣な研究を行い、いくつかのカンファレンスで発表してきましたが、今回はさておきましょう。

実例を挙げます。当サイトで公開している典型的なLinuxレビュー記事です。これらはかなり長く、本文は約4万文字(2,500〜3,000語相当)、1ページに30〜40枚の画像を含みます。読み込みには多少の時間がかかります。

しかし……記事は必ず2段落のテキストから始まり、そこを読むだけで15〜20秒はかかるでしょう。読者が読み終える頃には、すべてのアセットはとっくに読み込みを終えています。速度はユーザー体験にほぼ影響しないのです。

ところが、いわゆる「SEO」の観点から見ると、専門家気取りの人々には「長すぎる」ようです。特定のツールや思想にスポットを当てるのは避けますが、「記事は500〜600語以内にすべき」といった推奨をするSEOツールを目にしたことがあります。それ自体、まったく無意味な数字です。機械が本当には定量化できないものに疑似科学を持ち込むと、こうなるのです。

そして、それこそが「品質」の問題だ

SEO関連の情報に決して登場しないのが「品質」です。これは機械には永遠に判定できないものです。品質は信頼に似ています――見つけ、築き、育てるのに時間がかかります。ブログの一文か二文を読んだだけで「質の高いコンテンツだ」と判断することは通常できません(その分野の熟練者なら別ですが)。一般には、公開資料の一貫性と正確性を見極めるために、繰り返しの経験が必要です。

速度の話に戻りましょう。あえて従うなら、ページをできるだけ速く表示したいなら、コンテンツはできるだけ短くあるべきであり、それはおそらく品質を削ることを意味します。コンテンツを複数ページに分割すればよいと言われるかもしれませんが、そうすると読者は何度もページ番号や矢印をクリックさせられます。世間の評価は知りませんが、私はこれをかなり煩わしく感じ、できる限り避けています(ごく一部の例外を除く)。

実際、ウェブページという概念(同じコンテンツの「ページ」を複数ページに分割して提供すること)自体、速度が不要な場面での無意味な速度追及の産物です。画像の話なら、ギャラリーは本来、個別の(独立した)フレームの集合体です。テキストの話なら、それは正当な理由のある長文であり、それを読もうとする人は最初から全文を読む根気を持っているはずです。つまり、速度への配慮はここでは完全なジレンマなのです。

では、実際にページを採点してみよう

冒頭で述べたとおり、具体的な数字が必要です。dedoimedo.comの速度テストを実施したので、結果をお見せしましょう。デスクトップ表示とモバイル表示で、それぞれ別の結果が出る点に注意してください。スコアは0〜100で、高いほど良好です。

データを見ると、デスクトップのパフォーマンスは良好ですが、モバイルはそうではありません。内容はまったく同じなのに、です。両者の差はごくわずかで、確認できる限りFCPパラメータで200msほどしかありません。

ラボデータ(Lab Data)ではさらに詳しい情報が得られます。しかし繰り返しますが、ページの「性質」という文脈なしでは、これらの数字はあまり意味を持ちません。たとえばTime to Interactiveですが、私のページには本質的なインタラクティブ性がありません――テキストと画像があるだけです。読んで、見る。そのうち、ページの内容が視覚的に表示されるまでの速さはSpeed Indexで示されます。ここでも、速度が無意味であるという私の主張に行き着きます。Dedoimedoのトップページには過去数ヶ月分の公開記事の見出しが並んでいます。少なければ読み込みも速くなるでしょうが、それは要点ではないのです。

数字は深刻に見えるかもしれませんが、信じてください、Dedoimedoは世の大半のウェブサイトより高いスコアを出しています。人気のテック系メディアをいくつか入力してみて、ご自身で確かめてみてください。

さらに理解を深めるため、レポート内の「Opportunities(改善提案)」と「Diagnostics(診断)」も確認しました。これらはスコアには直接影響しませんが、それ自体が多くを物語っています。

診断によると、サードパーティのコードがメインスレッドを丸々約1秒ブロックしていたようです。内訳を見ると、主犯は私が各ページで利用しているGoogle Adsのコードでした。また、document.write()も低速回線のユーザーへの問題として指摘されていますが、これもサードパーティコードによるものです。

改善提案にも興味深い項目がありました。画像です。「次世代フォーマット」を古いJPGやPNGの代わりに使えという提案です。これで約2.7秒の読み込み時間を節約できるとのことですが、2.7秒といえば、私のサイトのどのページでも人が一行のテキストを読むのにかかる時間より短いのです。実用上、違いはほぼありません。ただ、これは記事で大量の画像を使っていることと無関係ではありません。まさに、読者が私のガイドやチュートリアルから最大限の価値を得られるようにしている部分です。これがスコアに直接影響しないとしても、アルゴリズムには、私がユーザーに提供しているものに価値があるかどうかを判断することは到底できません。画像そのものが無価値かもしれないのですから。

さらに奇妙だったのは「未使用のJavaScript」の指摘――そのすべてが、Dedoimedoで使っているGoogle関連のサードパーティコンテンツでした。私は正確さと綿密さを誇りとしています。常に最善のソリューションを実装し、最も大切な存在である読者に最高の体験を提供しようとしてきました。

だからこそ、Dedoimedoには独自実装のJavaScriptがゼロであり、軽快であるべきなのです。Cookieなし、コメント欄なし、余計なものなし。唯一のサードパーティコードは、基本的なアクセス解析、検索、小銭稼ぎのための広告、そしてGDPRとCCPAで求められるCookie同意オーバーレイだけです。しかし上記の結果を見ると、最善策はサードパーティスクリプトを完全に撤去することのように見えます。

もちろん、上記のコードを私が作ったわけではありません。広告コードはGoogleが指定した通りの形式で設置し、Cookie同意アプリもCivicが指定した通りに使っています。非同期読み込みなどの改善余地があるとしても、私には実装する手段がありません。サードパーティ企業がどうコードを書くかは制御できないのです。私が制御できるのは、それを使うかどうかの選択だけ――そして、その選択こそ見直しが必要かもしれない、ということです。

さらに、テストごとに結果がかなり異なるようです。最初の計測の数日後に取得したモバイル結果がこちらです。構いませんが、私側の変更が一切ないのにこれほど変わるのなら、どうやってこれらの数値を判断材料にすればいいのでしょうか?

この数字はGoogle Search Consoleのレポート――すべてのページが「良好」と報告されています――とは食い違っていますが、Field Dataのテキストレポートとは概ね一致しています。余談ですが、インデックスされた全ページのうち、モバイルユーザビリティの問題が検出されたのはわずか2ページで、どちらも誤検出のようです。ライブテストではすべて緑(実際にスマートフォンでも正しく表示される)だからです。たとえば、フラグが立った2ページのうちの1つ、Windows 10エクスプロイト対策ガイドがこちらです。

「使いやすさ」ついでに言えば、グレー背景の上の淡いグレー文字は本当に親切設計とは言えません。まったくもって。

結論

以上が私の調査結果です。文脈なしではほとんど何も語らない数字。デスクトップとモバイルで大きく異なり、サンプルごとに値が変わる数字。類似機能を持つ別のツールの結果と一致しない数字。主にサードパーティスクリプト――その大半はGoogle製――に左右されるように見える数字。そして誤検出まで含まれるデータ。

これは短く簡単なテストですが、パフォーマンス/速度がどう解釈されているかに大きな変動と曖昧さがあることを示しています。繰り返しますが、数字の背後にあるコンテンツについては何も分からず、実際の品質についてはなおさらです。完璧なスコアを持つページはあり得ますが、現代インターネットの大部分はゴミ溜めです。まずそちらに対処すべきでしょう。でもまあ、私はただの下っ端のコックにすぎません。

ここに書いたことに誰が関心を持つかは分かりません――一介の人間の意見ですから。しかし、速度をランキングの計算式に加えることは事態を悪化させるだけだと確信しています。人々が神話的な「SEO」ユニコーンを追いかけているだけで既に状況は悪いのに、速度評価はさらに薄められた「高速」コンテンツ、機械を喜ばせるための中身のないふわふわした文章を量産するだけです。ヒントを一つ:私は一度もSEOの推奨に従ったことがありませんが、私のサイトの人気は伸び、縮み、再び伸び(私の手は一切加えていません)、私の制御外の金銭的事情のリズムに合わせて縮み、また伸びてきました。代わりに私は品質と楽しさに集中しています。とはいえ、私が絶滅危惧種となった旧世代の技術者であり、未来はタッチ操作に夢中な人々のものであることも分かっています。それでいいのです、それは彼らの未来なのだから。私はどこか日当たりの良い島でのんびり隠居しながら、低関心の大衆から莫大な利益を上げる企業の配当を享受しつつ、彼らに静かに敬意を表することにしましょう。

それでは、また。