モバイルpageの表示速度は順位だけで決めず読者が待つ画面から直す

モバイルpageの表示速度を直すときは、scoreを上げることから始めません。検索結果から最初に開かれるpage、問い合わせや予約へ進むpage、重い画像やJavaScriptを読み込むpageを分け、読者が待たされる場所から確かめます。順位に関わるかだけを理由にすると、読者が使わないpageを先に直し、事業に必要な入口を後回しにします。

Googleは1月17日、7月からモバイル検索でpage speedをranking factorに使うと案内しました。ただし影響を受けるのは最も遅い体験を提供するpageで、対象となるqueryは少ないとしています。検索意図は引き続き強いsignalであり、内容が役立つ遅いpageが高く表示される場合もあります。Googleは影響の有無を直接示すtoolはないとし、Chrome User Experience Report、Lighthouse、PageSpeed Insightsを確認の手掛かりとして挙げました。 Google Search Central Blog

速度の点数と読者が待つ場面を分ける

表示速度を測るtoolは、改善の候補を見つけるために使います。点数が低いからといって、表示された指摘をすべて同じ順で直す理由にはなりません。画像、stylesheet、JavaScript、外部serviceなどは、pageごとに読み込む量も、読者が必要とする順番も違います。

たとえば、会社案内のpageは画像が多くても、問い合わせへ進む人が少なければ急ぐ理由は限られます。一方、検索広告や自然検索から多くの人が最初に開くservice pageでは、説明文が出る前に大きな画像や外部scriptを待たせていないかを先に見ます。速度の改善は、すべてのpageを同じ形へそろえる作業ではありません。読者が必要な情報を読む前に何を待たされるかを確かめる作業です。

scoreが高くても、電話番号、料金の条件、問い合わせへのlinkが画面の下に押しやられていれば、読者は次の行動を決めにくくなります。逆に、少し時間がかかっても、最初に必要な説明と連絡先が読めるなら、改善の優先順位は変わります。表示時間と情報の順番は別の問題として見ます。

最初に開かれるpageを三つ選ぶ

調査するpageを増やしすぎないために、まず三つを選びます。一つ目は検索や広告から最初に開かれるpageです。二つ目は問い合わせ、予約、資料請求など、読者が行動を決めるpageです。三つ目は画像、動画、外部serviceを多く使うpageです。この三つを比べれば、遅さがsite全体の問題なのか、特定の作り方に偏った問題なのかを考えられます。

各pageでは、モバイルのbrowserで開き、最初に読める内容を確認します。読み込み中に画面が大きく動かないか、本文や価格の条件が遅れて現れないか、問い合わせbuttonを押すまでに別の画面を待たせないかを見ます。次にPageSpeed Insightsなどの結果を開き、重い要素がどこにあるかを調べます。先に画面を見てからtoolを使うと、数字と読者の操作を結びつけやすくなります。

たとえば、画像が大きいという指摘が出ても、その画像が最初の説明に必要なのか、下の方にある装飾なのかで対応は変わります。必要な画像なら、表示する順やfileの大きさを制作側と相談します。装飾であれば、最初に読むpageへ必要かを運用側が決めます。技術的な指摘を受け取る人と、何を残すかを決める人を分けると、改善が目的を失いません。

JavaScriptと外部serviceは役割を確認してから減らす

計測tag、地図、form、font、広告、SNSのbuttonなどは、外部からfileを読み込むことがあります。表示速度を上げるために一律で外すと、計測できなくなったり、問い合わせが送れなくなったりします。遅いという結果を見たら、まずそのscriptが何のためにあるか、誰が管理しているか、外してよいかを確認します。

たとえば、古いcampaign用のscriptが残っているなら、今も使う広告や計測と区別します。地図が最初の画面に必要でないなら、載せるpageや表示の順を見直せます。フォームに必要なscriptなら、送信ができることを保ったまま、ほかに待たせている要素を調べます。読み込みを減らす作業は、fileを消す作業ではなく、読者に必要な機能を残す作業です。

制作会社へ頼むときは、「速くしてほしい」だけで終えません。対象URL、読者が最初に知るべき内容、遅いと感じる場面、残さなければならない機能を渡します。制作側は画像、template、JavaScript、server responseを調べられます。siteを運用する側は、どの情報と導線を残すかを決めます。役割が分かれていれば、scoreだけを追う修正になりません。

変更後は数字と操作を同じpageで見る

改善した後は、同じURLをモバイルで開き、直す前に待たせていた場面が変わったかを確かめます。PageSpeed Insightsなどの結果も見ますが、数字だけで完了にしません。本文、画像、電話番号、form、外部linkが意図どおりに表示され、操作できるかを確認します。

変更した内容は、URLごとに残します。画像を替えたのか、scriptを外したのか、表示の順を替えたのかを記録しておけば、別のpageで同じ問題を見つけたときに比べられます。順位や問い合わせがすぐ変わるとは限りません。だからこそ、先に読者が待つ場面を減らせたか、必要な案内が読めるかを確認します。

モバイルの表示速度は、順位を上げるためだけの数字ではありません。読者が検索結果から開き、内容を読み、次の行動へ進めるまでの時間です。最も遅いpageだけを恐れるより、事業に必要な入口から画面とtoolを並べて見ます。その順なら、技術的な修正も、残すべき情報も判断できます。