問題点
商品画像の最適化、CSS の圧縮、遅延読み込みの設定、軽量テーマの選択に何週間もかけました。PageSpeed が85〜90になりました。そして新しいメニューアプリをインストールした——スコアが55に落ちました。
これは非常によくある状況です。市場にある多くのメニューアプリは重い JavaScript フレームワークで構築され、独自のフォントを読み込み、ページロード時にスクリプトを挿入し、レイジーローディングに正しく対応していません。最適化されていないメニューアプリ1つで読み込み時間に1〜2秒追加される——それだけで Google の順位が下がり、ページが読み込み終わる前にお客様が離脱するには十分です。
「人気の mega menu アプリを試したら、モバイルの PageSpeed が82から48に一夜で落ちました。アプリを削除したら元に戻る。インストールしたら落ちる。軽いものを探さないといけませんでした。」
— Navi+ のお客様
重いメニューアプリが積み上げてきた最適化をすべて台無しにする
ページ速度はユーザー体験だけでなく、売上と検索順位に直接影響します。Google は Core Web Vitals（LCP、FID/INP、CLS）をランキング要素として使用します。そしてお客様は待ちません——多くの調査によると、1秒の遅延が約7%のコンバージョン率低下につながります。
メニューアプリが引き起こす速度問題の典型例：
- レンダリングブロッキング JavaScript——アプリのスクリプトがコンテンツを表示する前に実行され、LCP（Largest Contentful Paint）が増加する
- 不要な CSS、ツリーシェイキング未対応——使用していない部分も含めてスタイルシート全体を読み込む
- プリロードされていない独自フォント——フォントスワップ時のレイアウトシフト（CLS）が発生する
- 遅延読み込み不可——メニューを開く前からページロード時にすべて読み込まれる
- 不要な HTTP リクエストが多い——リクエストが増えるほど遅延が増し、特に低速回線のお客様に影響する
あなたはすべて正しく最適化してきました——ただしメニューアプリが正しく構築されていなかっただけです。
Navi+ はなぜ軽量なのか？
Navi+ は速度を後から追加するのではなく、最初から最優先として構築されています。JavaScript はすべて遅延・遅延読み込みで読み込まれ、CSS は必要な部分のみを読み込むよう最適化され、メニューパネルはお客様が実際に操作したときにのみレンダリングされます。結果として、インストール前後で PageSpeed はほぼ変わりません。
| 速度の基準 | 一般的なメニューアプリ | Navi+ Menu Builder |
|---|---|---|
| ページロード時の JavaScript ブロッキング | あり——LCP が増加する | ✓ 遅延実行、レンダリングをブロックしない |
| メニューパネルの遅延読み込み | ✗ 全体を即座に読み込む | ✓ 必要なときだけレンダリング |
| CSS のツリーシェイキング | ✗ スタイルシート全体を読み込む | ✓ 使用中のスタイルのみ読み込む |
| 追加フォント | 通常、独自フォントを読み込む | ✓ テーマのフォントを使用、追加なし |
| モバイル PageSpeed への影響 | 15〜30点の低下は普通 | ✓ 影響は最小限（3点未満） |
| インストール後の Core Web Vitals | LCP が増加、CLS が発生する可能性 | ✓ 大きな変化なし |
確認と移行の方法
Navi+ をインストールする前に、PageSpeed Insights（pagespeed.web.dev）でストアのベースラインスコアを取得します。インストールして設定が完了したら再度測定して比較します。ほとんどのマーチャントは大きな変化を確認できません——それが目標です。
他のメニューアプリを使っていてストアが遅くなっていると疑っている場合、そのアプリを一時的に無効化してから PageSpeed を計測して確認します。無効化後にスコアが大幅に上昇したなら——原因を特定できました。Navi+ に置き換えて再測定して比較してください。
古いメニューアプリから Navi+ への移行全体——メニュー構造のインポート、デザインのカスタマイズ、デスクトップとモバイルでの確認——は通常15〜30分で完了します。