ストアが遅いと感じたとき、私たちはまず重い画像やぜい肉のついたテーマを疑いがちです。しかし、ほとんど誰も気づかない要素が一つあります。それは、メニューアプリがページの読み込み速度にどう影響するか、という点です。メニューはページの一番上に配置されるため、ブラウザが最初に処理しなければならないものの一つになります。丁寧に作られていないナビゲーションアプリは、ストア全体を引きずり下ろしかねません。
この記事は二部構成です。前半では仕組み、つまりメニューアプリがなぜ速度を落とすのかを扱います。後半では警告サインを取り上げ、推測ではなく、自分のストアを実際にチェックできるようにします。
メニューアプリがストアの速度に影響する理由
表面的に見れば、メニューアプリはいくつかのボタンにすぎません。しかし、その裏側では通常、JavaScript、フォント、アイコン、画像を読み込んでいます。そのどれもが速度というコストを伴います。最もよくある原因を4つ紹介します。
メニューが表示される前に実行しなければならない重いJavaScript
多くのメニューアプリは、そのインターフェースをJavaScriptで構築しています。顧客がページを開くと、ブラウザはファイルをダウンロードし、解析(パース)し、そして実行する必要があります。それが終わって初めてメニューが表示されるのです。
JavaScriptが重ければ重いほど、この工程には時間がかかります。高性能なパソコンならほとんど気づきません。しかし、買い物客の大半はスマートフォンで購入しており、ミドルレンジのスマホはJavaScriptの処理が格段に遅くなります。数百KBのファイルは、デスクトップなら一瞬ですが、安価なAndroidスマホでは丸1秒かかることもあります。
ストアにとって、その1秒は、タップできるメニューもないまっさらな画面を顧客が眺めて過ごす時間なのです。
レンダリングブロック:メニューを待つあいだ、アプリがページ全体を止めてしまう
この点はしばしば見落とされます。Googleのドキュメントによると、JavaScriptはデフォルトでパーサーをブロックします。ブラウザがページを構築している途中でscriptタグに行き当たると、いったん停止してそのスクリプトを実行し終え、それからようやく構築を再開しなければなりません。
これがレンダリングブロックと呼ばれるものです。スクリプトを不適切な場所に置き、asyncやdefer属性を使っていないメニューアプリは、メニューだけでなくページ全体の描画をブロックしてしまうことがあります。
実際に起こることはこうです。顧客が商品リンクをクリックしても、メニューのスクリプトが終わるのを待っているせいで、ページが一瞬フリーズします。画像も価格も、まだ何も見えません。本当に速く読み込まれてほしいのは、メニューバーではなく、売り上げにつながるコンテンツのはずなのに。
アイコン、フォント、画像のすべてがHTTPリクエスト
見栄えのよいメニューには、カスタムフォントのアイコンが付いていることが多く、項目ごとに背景画像やロゴが付いている場合さえあります。リソースの一つひとつがHTTPリクエスト、つまりブラウザがサーバーにファイルを送ってほしいと頼む一往復の通信です。
各リクエストには、接続を確立し、応答を待つための時間がかかります。アイコンが10個あれば、10回の往復が発生します。メニュー専用のカスタムフォントを加えれば、リストはさらに長くなります。一つひとつは小さくても、合わせれば積み重なっていきます。とりわけ、電波の弱い地域で脆弱な3G/4G回線を使っている顧客にとっては顕著です。
インラインのSVGアイコンや、端末にもとから入っているシステムフォントを使った軽量なメニューなら、こうしたリクエストをかなり減らせます。
CLS:遅れて読み込まれるメニューがレイアウトをずらす
CLS(Cumulative Layout Shift)は、GoogleのCore Web Vitals指標の一つです。ページが読み込まれるあいだに、インターフェースがどれだけずれるかを測定します。Googleによると、良好とされる基準値はCLS 0.1未満です。
同じくGoogleによると、CLSはJavaScriptがページにコンテンツを遅れて挿入し、既存の要素を下に押し下げるときによく発生します。メインコンテンツの後に読み込まれるメニューバーやナビゲーションバナーは、その典型例です。あとから現れてスペースを占め、その下にあるものすべてを押し下げてしまうのです。
買い物中にこんな経験をしたことがあるかもしれません。「カートに追加」をタップしようとした、まさにその瞬間にメニューがぽんと現れ、レイアウトがずれて、別のものを間違えてタップしてしまう。それがCLSです。煩わしいうえに、顧客が離脱する理由にもなります。
メニューがストアを遅くしているサイン
仕組みを理解したところで、実践的な部分に入ります。メニューアプリが問題を引き起こしているかどうかを見分ける方法です。深い技術知識は必要なく、いくつかの無料ツールだけで済みます。
PageSpeed Insightsを実行する
pagespeed.web.devにアクセスし、自分のストアのアドレスを貼り付けて分析を実行します。このGoogleのツールはページを採点し、問題点を「改善できる項目(Opportunities)」と「診断(Diagnostics)」の2つのセクションに一覧表示します。
レンダリングを妨げるリソース(render-blocking resources)や、JavaScriptの実行時間を短縮(reduce JavaScript execution time)といった記述に注目してください。ファイル名や説明にnavigation、menu、drawerといった単語が含まれていれば、メニューアプリが速度低下の一因である可能性が高いです。
モバイルとデスクトップの両方のモードで実行しましょう。モバイルのスコアは通常より低く、顧客の実際の体験に近いものになります。買い物客の大半がスマホで購入しているからです。
Chrome DevToolsのNetworkタブを使う
Chromeでストアを開き、F12を押してDevToolsを呼び出し、Networkタブを選びます。ページを再読み込みし、種類でJSをフィルタして、JavaScriptファイルだけを表示します。
表示された表には、各ファイルの重さと所要時間が示されます。ナビゲーションアプリらしい名前のファイルを探してください。メニューのファイルが数百KBあり、読み込み完了までしばらくかかるようなら、それは推測ではなく具体的な証拠になります。
ちょっとしたコツがあります。DevToolsには、低速なネットワーク(スロットリング)や非力なCPUをシミュレートするオプションがあります。これをオンにして実際の顧客の端末を模倣すれば、自分のマシンが示す数値よりもずっと現実に近い値が見られます。
アプリ導入の前と後でスコアを比較する
最も正直な方法は、導入の前後で測定することです。新しいメニューアプリを入れる前にPageSpeed Insightsを実行し、スコアとあわせてLCP、INP、CLSの各指標を記録しておきます。アプリを導入してメニューを作り終えたら、もう一度実行して比較します。
Googleによると、良好とされる基準値はLCPが2.5秒未満、INPが200ミリ秒未満、CLSが0.1未満です。アプリ導入後にLCPが上がったり、CLSが0.1を超えて跳ね上がったりすれば、そのアプリは速度というコストを支払わせていることになります。
これが重要なのは、平均的なストアがアプリを一つしか入れていないわけではないからです。多くの情報源が引用するデータによれば、典型的なShopifyストアには約6つのアプリが導入されており、なかには30個まで使っているストアもあります。各アプリが少しずつ抵抗を加え、合わせれば決して小さくない数字になります。そして速度は、何人がページを離れるかに直結します。Baymard Instituteによれば、平均的なカート放棄率はすでに約70%。1秒余分にかかるたびに、その数字はさらに悪化しかねません。
速度に配慮したメニューアプリを選ぶ
すべてのメニューアプリが速度を落とすわけではありません。問われるのは、そのアプリが速度を念頭に置いて作られているかどうかです。軽量なJavaScript、レンダリングブロックがないこと、無駄なリクエストが少ないこと、そしてメニュー用にスペースを確保してレイアウトをずらさないこと、です。
これは、私たちがNavi+を作るうえで最優先にしている点です。Navi+は、Shopifyおよびあらゆるウェブサイト向けに、コードなしでメニューを構築できます。Tab Bar、Mega Menu、Slide Menu、FAB、Grid Menuに対応し、モバイルとデスクトップで別々の設定が可能で、Core Web Vitalsを引きずり下ろさないよう最適化されています。それでも、上記の手順を使い、導入の前後で自分自身で測定することをおすすめします。それが最も信頼できる検証方法です。
要するに、メニューアプリは体験の一部ではありますが、それがストア全体を静かに遅くしてしまうことは避けたいものです。PageSpeed Insightsを実行し、Networkタブを確認する数分間が、明確な答えを与えてくれます。
この記事は、より大きなガイド「ナビゲーションとページ表示速度 — Core Web Vitalsを損なわないメニューアプリの選び方」の一部です。