ストアに追加するアプリは、どれもページに少しずつコードを差し込みます。メニューアプリは最初に読み込まれるものの一つです。ページが開いた瞬間に、お客さまはナビゲーションを目にする必要があるからです。ですから メニューアプリ と Core Web Vitals の関係は、どこか遠い技術的な話ではなく、お客さまの第一印象にそのまま直結します。
見落とされがちなのはこの点です。美しいけれど読み込みの遅いメニューは、ときに何もないより悪いことさえあります。お客さまにコードは見えません。見えるのは、もたつくページ、あちこち動くコンテンツ、タップしても反応しないメニューだけです。この記事は、自分のストアを運営し、何度も測定を重ねてきた経験からまとめたものです。速度であなたを脅すためではなく、体験を犠牲にせずにメニューアプリを選ぶための手がかりを十分にお渡しするためです。
- メニューアプリは顧客が最初に触れるナビゲーションに影響します。
- Core Web Vitals は読み込み遅延、タップ遅延、レイアウトずれを示します。
- 宣伝を信じるより、導入前後で測定します。
Core Web Vitals とは何か、そしてなぜあなたに関係するのか
Core Web Vitals は、ページ読み込みの実際の体験を測るために Google が使う3つの指標です。ラボでのスコアではなく、実際のお客さまから集めたデータです。
3つの指標は次のとおりです。
- LCP（Largest Contentful Paint） — 最も大きなコンテンツが表示されるまでの時間。Google は2.5秒以下を良好としています。
- INP（Interaction to Next Paint） — お客さまがクリックやタップをしたときの遅延。良好は200ミリ秒未満です。
- CLS（Cumulative Layout Shift） — ページの読み込み中にコンテンツがどれだけ動くか。良好は0.1未満です。
よく誤解される点があります。Google は75パーセンタイルで測定します。つまり、ページが合格と見なされるには、アクセスの75%が「良好」に達している必要があります。お客さまの4分の1が悪い体験をしていたら、平均が良くても救われません。
なぜマーチャントが気にかけるべきなのか。理由は2つあります。1つ目は、これが Google のランキングシグナルの一つだからです（最大のものではないにせよ）。2つ目は、より重要なことに、お客さまが実際にどう感じるかを反映しているからです。ファネルの入り口での小さな引っかかり — 読み込みの遅いページを含め — は積み重なっていきます。
良い知らせは、この3つの数値を読むのにコードの知識はいらないことです。これらは無料で入手でき、かなり分かりやすく説明されています。
詳しく見る完全ガイドを読む → Core Web Vitals とは何か、そしてなぜあなたに関係するのか
メニューアプリは速度にどう影響するか — そして見抜き方
Shopify の多くのアプリは、ストアフロントに JavaScript を差し込むことで動きます。メニューアプリも例外ではありません。それ自体が悪いわけではなく、問題はそのコードがどう読み込まれ、いつ実行されるかです。
スクリプトがレンダリングをブロックする形で読み込まれると、ブラウザはページの残りを組み立てる前に、それをダウンロードし、読み込み、実行し終える必要があります。メニューアプリは、ページのいちばん上に早く現れる必要があるため、問題を起こしやすいグループにまさに当てはまります。
メニューアプリが速度を落としたり、体験を損なったりする道筋は3つあります。
- LCP を悪化させる — メニューがページ上部の大きな部分を占め、表示前にスクリプトの完了を待たなければならない場合。
- INP を上げる — メニューへのタップのたびに JavaScript の処理を待つ必要があり、もたついて感じられる場合。
- CLS を増やす — メニュー（特に上部バーや下部のタブバー）が遅れて現れ、ほかのコンテンツを押しのける場合。
ツールなしで肉眼で気づけるサインは次のとおりです。
- ページ本体よりも明らかに遅れてメニューが現れる。
- メニューが現れた瞬間にページがカクッと動く、または揺れる。
- メニューをタップしてから、開くまで一拍待たされる。
- モバイルで、読み込み中に下部タブバーがちらついたり、位置が飛んだりする。
これらのサインが見えたからといって、メニューアプリだけが原因とは限りません。ですが、外す前と後で測定してみる価値はあります。
詳しく見る完全ガイドを読む → メニューアプリは速度にどう影響するか — そして見抜き方
速度の面で良いメニューアプリの条件
メニューアプリが何に影響するかを理解すれば、選ぶのは楽になります。以下は、私が重視する価値があると思う条件を、おおよそ重要度の順に並べたものです。
軽く読み込み、レンダリングをブロックしない。 アプリは defer や async でコードを読み込み、メニューがページを待たせないようにすべきです。これを直接確認することはできませんが、結果はインストール前後の速度スコアに表れます。
安定したスペースを確保し、レイアウトのずれを起こさない。 良いメニューアプリは、CLS が上がらないよう、あらかじめメニューの場所を取っておくべきです。これは非常に見落とされやすい点で、特に固定タブバーや上部の追従ナビゲーションバーで顕著です。
Built for Shopify バッジを持っている。 これは信頼できるシグナルです。Built for Shopify バッジを得るには、Shopify が公開している要件により、ストアフロントの Lighthouse スコアを10ポイント以上下げてはなりません。完璧の保証ではありませんが、そのアプリがページ速度の最低ラインをクリアしたことを示します。
モバイルとデスクトップで別々に設定できる。 軽いメニューでも、場面を間違えれば良くありません。モバイルにはタブバー、デスクトップにはメガメニューと設定できれば、すべてを1つのデザインに詰め込まずに済みます。
テーマを変えても安定している。 メニューがテーマとは独立して保存されていれば、デザインを切り替えるたびに作り直す必要がなく、切り替え時に不要なコードが積み上がるリスクも避けられます。
典型的な「重い」メニューアプリと、最適化されたメニューアプリの簡単な比較です。
| 観点 | 速度を考慮しないアプリ | 速度を最適化したアプリ |
|---|---|---|
| コードの読み込み方 | レンダリングをブロック | Defer / async |
| CLS への影響 | レイアウトがずれることが多い | 安定したスペースを確保 |
| Built for Shopify | たいていなし | バッジあり |
| デバイスごとの設定 | 共通の1デザイン | モバイルとデスクトップで別々 |
Navi+ はこうした方針に沿って作られています。コードなしでメニューを作れること、モバイルとデスクトップを別々に設定できること、テーマを変えてもメニューがそのまま残ること、そして Built for Shopify バッジを保有していること。naviplus.io をご覧ください。とはいえ、マーケティングを — 私たちのものも含め — 鵜呑みにせず、ご自身のストアで測定されることを、なおおすすめします。
詳しく見る完全ガイドを読む → 速度の面で良いメニューアプリの条件
メニューアプリをインストールする前のチェックリスト
ここは、技術的な知識なしで、15分ほどでできる実践的な手順をまとめたものです。
- まずベースラインを測る。 PageSpeed Insights を開き、ホームページの URL と商品ページを貼り付けて、現在の LCP・INP・CLS を書き留めます。これが比較の基準点になります。
- トライアルモードでメニューアプリをインストールする。 ほとんどのアプリにはトライアルがあります。実際に使うつもりの形でメニューを作りましょう — 中途半端に設定してはいけません。
- 同じページをもう一度測る。 3つの指標をベースラインと比較します。わずかな差は普通ですが、CLS や LCP の大きな差は、見直すべきサインです。
- 実機のスマホで目視確認する。 できれば 4G で読み込みましょう。メニューが遅れて現れないか、レイアウトをずらさないか、タップしたときにもたつかないかを観察します。
- バッジとレビューを見る。 Built for Shopify があり、速度について具体的に触れているレビューがあるアプリを優先しましょう。
- 残さないなら、きれいに削除する。 残さないと決めたら、差し込まれたコードがすべて削除されることを確認し、もう一度測定して、スコアがベースラインに戻ることを確かめます。
習慣についての一言。比較のために複数のメニューアプリを同時にインストールしないでください。コードが重なり合い、測定結果を狂わせることがあります。1つずつ試し、次をテストする前にそれぞれをきれいに削除しましょう。
詳しく見る完全ガイドを読む → メニューアプリをインストールする前のチェックリスト
速度だけでなく、ナビゲーションについての一言
速度は大切です。ですが、それはより大きな目的のためにあります — お客さまが必要なものを見つけられるようにすることです。ナビゲーションをすべて隠してしまう速いメニューは、何も解決しません。
Nielsen Norman Group が179人のユーザーを対象に行った調査では、ナビゲーションを隠すと発見しやすさがほぼ半減し、同時にお客さまの行動が遅くなり、目的のものを見つけるのも難しく感じられることが分かりました。教訓は十分に明快です。隠さなくてよいなら、隠さないこと。
だからこそ、モバイルでは、ただのハンバーガーメニューよりも下部のタブバーのほうがうまく機能する傾向があります — 主要な項目が常に手の届くところにあり、見るために何かを開く必要がないからです。速度と良いナビゲーションは両立します。メニューアプリを選ぶことは、その両方を同時に選ぶことなのです。
どこから始めるか
まず基準値導入前にPageSpeedの数値を保存し、設定後に同じページで比較します。
速度は開発者だけの問題ではありません。マーチャントであるあなたも、自分で確認し、根拠のある判断を下すことが十分にできます。メニューアプリがストアを遅くしているかどうかを知るのに、コードを1行も読む必要はありません。どこを見ればいいかを知っていればよいのです。
PageSpeed Insights のような無料ツールがあれば始められます。今日あなたのストアのスコアを測り、ベースラインとして保存し、新しいメニューアプリを試した後に比較しましょう。数字は、どんなマーケティングの主張よりも多くを語ってくれます — この記事を書いた人間の主張よりも、ずっと。
トピックを見る
このガイドは各テーマの記事にリンクしています——それぞれをさらに深く学べます。