どのメニューアプリでも「アプリを追加」をクリックする前に、やっておく価値のある小さなことが一つあります。それは、今のストアがどれくらい速いかを記録しておくことです。単純なことに聞こえますが、ここを飛ばしてしまう人がほとんどです。そして数週間後、原因のアプリが分からないまま「サイトが重くなった気がする」と感じることになるのです。
これは、実際にストアを運営してきた経験から導いた、すぐに実践できる短いメニューアプリ導入チェックリストです。難しいことは何もありません。導入前と後でいくつか測定するだけ。そうすれば、美しいメニューと引き換えに、知らないうちに速度を手放してしまうことを防げます。インストールするアプリが増えるほど、この習慣の効果は大きくなります。追加するアプリはどれも、ページ速度に影響を与え得るからです。
なぜ速度を気にする価値があるのか
そもそもオンラインの買い物客は、ちょっとしたことで離脱します。Baymard Instituteによると、カート放棄率の平均はおよそ70%前後で推移しており、この数字は10年以上ほとんど変わっていません。読み込みが1秒延びるたびに、読み込み中にレイアウトがガタつくたびに、お客様が離脱する理由が一つ増えていきます。
Googleもまた、ページの速度と安定性を体験の一部として扱っており、Core Web Vitalsと呼ばれる一連の指標にまとめています。Googleによる主要な3つの数値は次のとおりです。
- LCP(Largest Contentful Paint):2.5秒未満で良好。
- INP(Interaction to Next Paint):200ミリ秒未満で良好。
- CLS(Cumulative Layout Shift — ページがガタつかないか):0.1未満で良好。
これらを暗記する必要はありません。覚えておくべきはただ一つ。丁寧に作られたメニューアプリなら、この3つの数値を目に見えて悪化させることはない、ということです。下のチェックリストは、それを勘ではなくデータで確認するのに役立ちます。
メニューアプリ導入チェックリスト:4ステップ、前後で測定する
ここが本記事の核心です。順番どおりに4ステップ進めます。
ステップ1:導入前にストアのPageSpeedスコアを測定する
GoogleのPageSpeed Insightsを開き、トップページのURLと代表的な商品ページのURLを貼り付けてテストを実行します。スコアを記録しましょう。スクリーンショットを撮るか、小さなファイルに保存しておきます。
なぜ保存するのか。「導入前」のスナップショットがないと、比較する対象が何もないからです。数週間後にサイトが重く感じられたとき、原因がメニューアプリなのか、新しく入れたレビューアプリなのか、それとも先日まとめて追加した商品画像なのか、判断できなくなってしまいます。
PageSpeed Insightsは2種類のデータを示します。上部のセクションは実際のユーザーから収集したフィールドデータ(Chrome User Experience Reportによるもの)、下部のセクションはラボデータ(Googleのマシンが1回のページ読み込みをシミュレートしたもの)です。このステップでは、総合スコアと、LCP・INP・CLSの3つの数値を記録するだけで十分です。
ステップ2:アプリを導入し、もう一度測定して比較する
使う予定のメニューアプリを導入したら、実際に使うとおりに正確に設定します。つまり、これから使うメニュータイプを有効にするということです。モバイルでは画面下のTab Bar、デスクトップではMega Menu、あるいはSlide Menu。初期設定のまま測定するのではありません。
そのうえで、ステップ1と同じURLに対してPageSpeed Insightsを再度実行します。2つの結果を並べて見比べましょう。
一点注意があります。導入直後は、フィールドデータ(上部のセクション)はまだ変化していないのが普通です。これは直近28日間を集計しているためです。すぐに比較できるのはラボデータの方です。ラボスコアが数ポイント下がっても慌てる必要はありません。大事なのは下がり幅です。2〜3ポイントの低下なら通常は気にする必要はありませんが、大きく下がった場合や、CLSが急に跳ね上がった場合(メニューが表示されるときにページがガタつく)は、もう一度見直す価値があります。
ステップ3:1〜2週間後にSearch ConsoleでCore Web Vitalsを確認する
これは本当の数値が得られるステップです。実際のお客様の体験を測定しているからです。Google Search Consoleを開き、Core Web Vitals(ページエクスペリエンス)に進みます。このレポートは、あなた自身のユーザーから得たフィールドデータを使います。
なぜ1〜2週間待つのか。フィールドデータは、移動する28日間のウィンドウで計算されるからです。約2週間が経つと、そのウィンドウのうち相当な割合が新しいデータになり、傾向を読み取れるようになります。Search Consoleでは、URLが「良好」から「改善が必要」や「不良」へ移っていないか注視しましょう。メニューアプリを導入した直後に不合格のURL群が一気に膨らんだなら、それは一つのシグナルです。
ストアへの訪問がまだ少ない場合、Search Consoleにレポートを表示するだけのデータが集まらないことがあります。そのときはPageSpeed Insightsとラボデータの方を頼りにしましょう。
ステップ4:スコアが目に見えて下がったら、アプリを替えるか設定を調整する
測定した結果、指標が明らかに悪化していたら、選択肢は2つあります。
一つは設定を最適化することです。不要なアニメーションをオフにする、巨大化したMega Menuの項目数を減らす、メニューに詰め込んだ重い画像を外す。多くの場合、問題はアプリそのものではなく、メニューを欲張って作りすぎたことにあります。
もう一つは、アプリそのものが重く、抑える方法がない場合に、アプリを替えることです。良いメニューアプリは、速度を自らの責任として扱うべきであり、その負担をあなたに押し付けたりはしません。
モバイルでの測定を忘れずに
多くのベトナムの事業者は、デスクトップよりもスマートフォンからのアクセスの方が多いものです。お客様はFacebookをスクロールし、リンクをタップして、スマホからそのままストアを開きます。
モバイルのスコアは、ほぼ必ずデスクトップより低くなります。スマホは性能が劣り、モバイル回線はwifiより安定しないからです。PageSpeed Insightsでは、Mobileタブに切り替えて測定することを忘れないでください。見栄えが良いからといってDesktopのスコアだけを見てはいけません。
これはとくにモバイルメニューで重要です。画面下に雑に作られたTab Barや、Slide Menuは、お客様がストアを開いたまさにその瞬間にページをガタつかせ(CLSを押し上げ)てしまうことがあります。自分のスマホでストアを開いてみて、ページ読み込み中に何かが飛び跳ねたり、もたついたりしないか観察してみましょう。スコアにまだ反映されていないことを、自分の目が捉えてくれることはよくあります。
やさしいひとこと
上のチェックリストは、メニューアプリから遠ざけようとするものではありません。良いナビゲーションはお客様がより速く商品を見つける助けになり、それは投資する価値があります。言いたいことはただ一つ。速度に配慮したアプリを選びましょう、ということです。
Navi+は、まさにその精神で作られています。Tab Bar、Mega Menu、Slide Menu、FAB、Grid Menuを、ノーコードのドラッグ&ドロップで構築できるメニュービルダーで、モバイルとデスクトップを別々に設定でき、Core Web Vitalsを引き下げないように調整されています。それでも、正直な助言は変わりません。上の4つの測定ステップを、Navi+を含めどのアプリにも実行してみてください。そうすれば、自分のストアの数値で自分自身を安心させられます。
この記事は、より大きなガイドナビゲーションとページ速度 — Core Web Vitalsを損なわないメニューアプリの選び方の一部です。