メニューは、ほぼすべての訪問者が触れる部分です。だからこそ、メニューアプリが遅いと、ページ全体が遅く感じられてしまいます。とはいえ「速い」という言葉は曖昧です。アプリを探していると、「超軽量」「ページを遅くしません」といった謳い文句ばかりが目に入り、それを確かめる手立てがはっきりしないことに気づきます。
この記事では、技術者でなくても自分でチェックできる、速いメニューアプリの5つの基準をまとめます。これらは、しばらく店舗を運営し、GoogleとShopifyの両方のドキュメントを読み返すなかで私が学んだことです。
始める前に、ひとつ基準点を共有しておきます。Googleはページの読み込み体験をCore Web Vitalsという指標群で測っており、「良好」のしきい値はLCPが2.5秒未満、INPが200ミリ秒未満、CLSが0.1未満です（web.dev）。良いメニューアプリとは、これらの数値を悪化させないものを指します。
1. 遅延読み込み：必要なときだけ読み込む
遅延読み込みとは、ページが開いた瞬間にすべてを読み込んでしまわないことを意味します。まだ必要のないものは保留にしておき、訪問者がホバーしたりクリックしたりして初めて読み込まれます。
デスクトップのMega Menuには、数十項目に加えてアイコンやサムネイルが収まることがあります。アプリがそれらすべてを最初から読み込もうとすると、商品画像や価格といった、訪問者が本当に見たいメインコンテンツとリソースを奪い合うことになります。遅延読み込みがあれば、サブメニューの層は訪問者が実際にホバーしたときにだけ現れます。
確認方法：パソコンでページを開き、メニューが開く瞬間に一瞬だけためらうかどうかを見てみてください。最初のホバーでわずかな間（ま）があるのは、たいていアプリが最初からすべてを詰め込むのではなく、ちょうど良いタイミングで読み込んでいるサインです。これは、雑貨店や多数の商品ラインを抱えるファッションショップのように、カテゴリーが多い店舗ほど重要になります。
2. 軽量なJavaScript
これは目で判断するのが最も難しい基準ですが、ベンダーに尋ねてみる価値はあります。考え方はシンプルで、数本のリンクを表示するためだけに、メニューが重いフレームワークまるごとを引きずり込むべきではない、ということです。
JavaScriptはアプリの「動く」部分です。JavaScriptのバンドルが大きいほど、ブラウザはそれを読み込み処理するのに時間を費やし、それは訪問者がクリックしたときの反応性であるINPに直接影響します。軽く書かれたメニューアプリは、メニューを開閉するために必要なコードだけを持ち、それ以上は抱えません。
これを判断するのにコードを読む必要はありません。GoogleのPageSpeed Insightsにページをかけ、未使用のJavaScriptの項目を見てください。メニューアプリを入れた後にこの部分が目に見えて膨らむなら、それは一度立ち止まって考えるべきサインです。
これはまた、一つのことをうまくこなすアプリが、十のことをやろうとするアプリより通常は軽い理由でもあります。詰め込めば詰め込むほど、JavaScriptのバンドルを軽く保つのは難しくなります。
3. レンダリングブロックがない
レンダリングブロックとは、アプリのスクリプトが、ブラウザがメインコンテンツを画面に描画するのを妨げてしまうことです。訪問者は、ページの残りが表示される前に、メニューアプリの読み込みが終わるのを待たなければなりません。
Googleのドキュメントによれば、既定のやり方で読み込まれたスクリプトは、そのスクリプトの読み込み・解析・実行が終わるまで、ブラウザがページを解析して表示するのをブロックします（web.dev）。これによりFirst Contentful PaintやLCPといった指標が後ろにずれ込みます。言い換えれば、置き場所を誤ったメニューアプリは、メニュー自体が何も複雑でなくても、画面を長く真っ白なままにしてしまうことがあるのです。
きちんと作られたアプリは、スクリプトを非同期に（asyncまたはdefer）読み込むため、ページはまずメインコンテンツを表示し、メニューは訪問者がほとんど気づかない程度の遅れで後から組み込まれます。この点を自分で確認するのは難しいですが、PageSpeed Insightsには「レンダリングを妨げるリソース」という具体的な警告があり、アプリ導入前後のスコアを比べることができます。
4. アセットがCDN経由で配信される
CDNとは、世界各地に分散して置かれたサーバーのネットワークです。メニューのアイコン・画像・ファイルがCDN経由で配信されると、訪問者に最も近いサーバーから引き出されるため、どの地域でも速く均一に読み込まれます。
これは国際的な顧客を狙うベトナムの事業者にとって実用的です。メニューのファイルが遠く離れた単一のサーバーに置かれていると、ヨーロッパやアメリカの訪問者は小さなアイコン一つひとつにより長く待つことになります。CDNがあれば、その距離が縮められます。
ベンダーに尋ねるのも簡単です。メニューのアイコンや画像はどこから配信されていますか、と。まともなアプリならこれに答えられますし、しばしばCDNの利用を強みとして挙げてくるでしょう。Shopifyでは大半のアセットが組み込みのCDNインフラを通りますが、それでもメニューアプリ自身が読み込む画像やアイコンは確認しておく価値があります。
5.「Built for Shopify」バッジ
Shopifyを使っていて、上記の技術的な基準を一つひとつ自分で確かめるのは避けたい、という場合、Built for Shopifyバッジは信頼できる近道です。これはShopifyが自社の品質基準を満たしたアプリに付与するラベルで、Shopifyはかなり厳しく審査しています。
注目すべきは、この基準の中にCore Web Vitalsからそのまま引かれたパフォーマンスの項目が含まれている点です。Shopifyのドキュメントによれば、アプリは読み込みの75パーセンタイルで測定して、LCP 2.5秒以下、CLS 0.1以下、INP 200ミリ秒以下を満たさなければなりません。さらに、アプリはストアフロントのLighthouseパフォーマンススコアを10ポイント以上下げてはいけません。
言い換えれば、このバッジが付いたアプリは、本来あなた自身が行わなければならない技術的な検証の一部を、すでに通過しているということです。バッジは自分の店舗での実測に取って代わるものではありませんが、候補をとても素早く絞り込んでくれます。
メニューアプリのなかで、Navi+は「Built for Shopify」バッジを持ち、上記の基準に沿って最適化されています。軽く読み込み、レンダリングをブロックせず、メニューが現れるときにレイアウトをずらすことを避けています。Navi+は、モバイル向けのボトムTab Bar、Mega Menu、Slide Menu、FAB、Grid Menuを、モバイルとデスクトップを別々に設定して、コード不要で構築できます。ここで触れたのは、いま述べた5つのポイントの身近な実例だからであって、唯一の選択肢だと言うためではありません。
チェックの習慣としてまとめる
上記の5つの基準は、10分でできるいくつかの小さなことに集約されます。
- メニューにホバーして、すべてを一度に読み込むことでためらいが出ないか見る（遅延読み込み）。
- アプリ導入の前後でPageSpeed Insightsを実行し、未使用のJavaScriptとレンダリングブロックの警告を比べる。
- アイコンと画像のCDNについてベンダーに尋ねる。
- Shopifyで販売しているなら、「Built for Shopify」バッジの付いたアプリを優先する。
店舗はたいてい多くのアプリを入れており、その一つひとつが全体の速度に少しずつ上乗せしていきます。メニューはほぼすべてのページに現れるからこそ、少し厳しく見る価値のある場所です。最初から正しく選んでおけば、後でアンインストールして入れ直す手間を省けます。
この記事は、ナビゲーションとページ速度 — Core Web Vitalsを損なわないメニューアプリの選び方という、より大きなガイドの一部です。