この記事でわかること
この記事の目次Contents閉じる開く
「Shopifyはアプリを入れすぎると重くなる」。よく聞く話ですが、実際に何個から重くなるのか、どのアプリが原因なのかを教えてくれる記事はほとんどありません。
そのため多くのストアは、感覚で使っていないアプリを削除し、速度が変わらないまま終わります。あるいは逆に、必要なアプリまで削って機能を失います。
問題は、アプリの速度影響は推測ではなく計測できるという事実が知られていないことです。Shopifyはアプリの速度影響を測る方法を公開しており、管理画面には「どの日にどのアプリを入れたか」と数値を重ねて見るためのレポートも用意されています。
この記事では、Shopifyヘルプセンターとshopify.devの記載をもとに、アプリと表示速度の関係を整理し、原因アプリを絞り込む手順をまとめます。調査日は2026年8月31日です。
先に結論
判断は次の4点に整理できます。
アプリは速度要因の1つだが、単独犯ではありません。 Shopifyはウェブパフォーマンスに影響する最大の要因として、テーマ、インストール済みアプリ、手動で追加した外部コード（タグマネージャーとその中のタグを含む）の3つを挙げています。アプリだけを疑う前に、テーマと自分で貼ったタグも同じ土俵に載せる必要があります。
すべてのアプリが速度に影響するわけではありません。 影響が出るのは、ストアフロント（お客様が見るページ）にコードを読み込むアプリです。管理画面の中だけで動くアプリや、バックグラウンドの処理だけを行うアプリは、この記事で扱う意味での速度影響とは別に考えます。
「Built for Shopify」バッジは、速度影響がゼロであることの保証ではありません。 後述するとおり、この認定の基準は「一定の範囲内に収まっていること」です。
原因の特定は管理画面だけで始められます。 有料ツールや開発者に依頼する前に、確認できることが3段階あります。
Shopifyはアプリの速度影響をどう測っているか
まず、Shopify自身が使っている物差しを知っておくと、その後の判断がぶれません。
shopify.devの開発者向けドキュメントには、アプリがストアフロントに与える影響をShopifyがどう評価しているかが公開されています。方法は明快で、アプリをインストールする前と後で Lighthouse のパフォーマンススコアを測り、その差を見るというものです。
このとき、3種類のページを単純平均せず、次の重み付けで加重平均します。
| ページ | 重み |
|---|---|
| ホーム | 17% |
| 商品詳細 | 40% |
| コレクション | 43% |
ホームページの比重が最も低い点が重要です。ストアの顔はトップページですが、購買に直結するのは商品ページとコレクションページであり、Shopifyの評価もそこに寄っています。自分のストアで速度を測るときも、トップページだけを見て安心しないほうがよいということです。
このドキュメントは開発者向けですが、書かれている手順自体はマーチャントでも実行できます。実際にどう使うかは後半で説明します。
「Built for Shopify」は速度影響ゼロの証明ではない
アプリ選びの目印としてよく紹介されるのが、Shopify App Storeの「Built for Shopify」バッジです。品質基準を満たしたアプリに付与されるもので、検索結果で絞り込むこともできます。
ただし、速度に関して何が保証されるのかは正確に理解しておく必要があります。shopify.devに公開されている認定基準では、ストアフロントのパフォーマンスについて次のように定められています。
アプリはストアフロントの Lighthouse パフォーマンススコアを10ポイントを超えて低下させてはならない
つまり、10ポイント以内の低下は基準を満たしているということです。バッジが付いているアプリでも、スコアが数ポイント下がる可能性はあります。そして複数のアプリを入れれば、その影響は積み上がります。
もう1点補足すると、Shopifyはストアフロントと決済のパフォーマンスについて「一部のアプリに対して測定する」と説明しています。ストアフロントに関与しないアプリは、この項目自体が評価対象になりません。バッジの有無だけで速度影響の大小を比較することはできない、ということです。
このほか、認定基準にはShopify管理画面側のパフォーマンス（75パーセンタイルでLCP 2.5秒以内、CLS 0.1以下、INP 200ミリ秒以内）や、決済のスピードに関する条件も含まれています。管理画面の快適さとストアフロントの速さは別々に評価されている、という点も押さえておくとよいでしょう。
Built for Shopifyは「品質の下限が確認されている」目印としては有用です。ただし「入れても遅くならない」と読み替えてはいけません。
管理画面で確認する：ウェブパフォーマンスレポート
ここからは自分のストアの話です。
Shopify管理画面には、かつて「オンラインストアの速度レポート」と呼ばれる機能がありました。調査時点では、そのヘルプページのURLはウェブパフォーマンスレポートの解説へ転送されており、内容も性質も変わっています。旧レポート前提の解説記事はまだ多く残っているため、実際の画面と照らしながら読んでください。
現在のレポートの特徴は次のとおりです。
テスト環境のスコアではなく、実際の訪問者のデータです。 実ユーザー計測（RUM）にもとづき、Core Web Vitals の3指標で評価されます。読み込み速度（LCP）、応答性（INP）、視覚的な安定性（CLS）の3つです。
評価は上位75%の体験を反映します。 ランクは「良好」「改善が必要」「低い」の3段階で、しきい値は次のとおりです。
| 指標 | 良好 | 改善が必要 | 低い |
|---|---|---|---|
| LCP（読み込み速度） | 2500ミリ秒以下 | 2500〜4000ミリ秒 | 4000ミリ秒超 |
| INP（応答性） | 200ミリ秒以下 | 200〜500ミリ秒 | 500ミリ秒超 |
| CLS（視覚的安定性） | 0.1以下 | 0.1〜0.25 | 0.25以上 |
そして、この記事の本題にとって最も重要な機能があります。 時系列レポートの折れ線グラフには、アプリのインストール、テーマの更新、新しいコードの追加といったストア側の変更が、番号付きの縦線（イベントアノテーション）として重ねて表示されます。カーソルを合わせると、その変更の内容を確認できます。
つまり、「このアプリを入れた日を境にLCPが伸びた」という関係を、グラフ上で直接確認できるということです。原因アプリを探す出発点としては、これが最も手間がかかりません。
確認手順は、管理画面の「分析」→「レポート」から各レポートを開くか、「オンラインストア」のテーマページに表示されるパフォーマンス指標サマリーから時系列レポートへ移動します。表示にはレポートに関するスタッフ権限が必要です。
利用にあたって、次の制約は知っておく必要があります。
- データは最大36時間遅れる場合がある
- 過去90日分しか保持されない
- パスワード保護（プライベートモード）中のストアではデータが集まらない
- 訪問数が少ないストアは日々の変動が大きく出るため、週単位・月単位のフィルターに切り替えたほうが読み取りやすい
90日という保持期間は実務上効いてきます。半年前に入れたアプリの影響を後から遡ることはできません。アプリを追加した直後に一度確認しておく習慣が、結果的にいちばん早い診断になります。
個別のアプリを切り分ける
レポートで「怪しい時期」が見えたら、次はアプリ単位の検証です。手順は、Shopifyが開発者向けに公開しているテスト方法をそのまま使います。
1. テスト用のテーマを用意する。 公開中のテーマを直接いじらず、複製したテーマで作業します。テーマを切り替えるとアプリの埋め込みは初期状態では有効にならないため、比較条件を揃えるには注意が必要です。
2. 3種類のURLを用意する。 ホーム、商品詳細、コレクションの各ページのプレビューURLを取得します。テーマページの「ストアを表示する」のリンクをコピーすると、パスワード保護中でも外部ツールから測定できるURLが得られます。
3. アプリの埋め込みをオフにして測る。 テーマエディタの「アプリ埋め込み」からトグルで無効化し、PageSpeed Insights でモバイルのパフォーマンススコアを記録します。ブロックとして配置されているアプリは、該当ブロックを削除して比較します。
4. オンに戻して測る。 同じ3ページを再度測定します。
5. 加重平均で差を出す。 ホーム17%、商品40%、コレクション43%で加重平均し、前後の差を取ります。これがそのアプリの影響ポイントです。
Lighthouseのスコアは実行ごとにぶれるため、Shopify自身も複数回測って平均するよう推奨しています。1回の測定で3ポイント動いた程度では判断できません。
この手順を全アプリに対して行うのは現実的ではないので、レポートのイベントアノテーションで当たりをつけたアプリから順に、2〜3本に絞って検証するのが実際的です。
削除しても、コードは残ることがある
切り分けの結果、あるアプリを外すと決めたとします。ここに落とし穴があります。
Shopifyヘルプセンターは、パフォーマンス改善の手順のなかで明確にこう記載しています。アプリをアンインストールしても、テーマ内のコードが自動的に削除されるとは限らず、完全に削除するにはアプリ開発元に手順を確認する必要がある場合がある、と。
自動で消えるかどうかを分けているのが、**テーマアプリ拡張（theme app extension）**という仕組みです。Built for Shopifyの「クリーンなアンインストール」要件では、オンラインストア向けのアプリはテーマアプリ拡張でテーマ内の要素を作ることが求められています。この方式で作られたアプリは、テーマコードにコードを注入せず、アンインストール時に関連ブロックがテーマから自動的かつ完全に削除されます。
裏を返すと、テーマコードに直接コードを差し込むタイプのアプリは、削除しても痕跡が残り得るということです。「アプリを消したのに速度が戻らない」の典型的な原因がこれにあたります。残ったコードの見つけ方と手順は、Shopifyアプリの棚卸しガイド｜削除しても消えないもの、止まらない請求に整理しています。
外部ツールの指摘は、そのまま受け取らない
速度診断ツールを使うと、多くの改善提案が並びます。ただしShopifyヘルプセンターは、第三者のスキャンツールが出す推奨事項の多くは、Shopifyがすでに実装済みか、Shopifyストアには当てはまらないと明記しています。
具体的に、次はShopify側で標準提供されています。
- CDN（Cloudflare運用、追加料金なし、HTTP/2で配信）
- ブラウザキャッシュ（キャッシュ可能なリソースに最長1年を設定）
- gzip圧縮（CSS、JavaScript、ドキュメント、ページ）
- 画像最適化（JPGの自動圧縮、多くの場合WebPで配信）
- CSS・JavaScriptの自動minify
そのため「CDNを導入しましょう」「圧縮を有効にしましょう」「サーバー設定を見直しましょう」といった指摘は、Shopifyストアでは対応不要です。逆に、意味があるのはアップロードした画像のサイズと枚数、テーマのセクション数、そしてアプリと外部コードの見直しです。
アプリを減らす前のチェックリスト
削除の判断に入る前に、次を確認してください。
- ウェブパフォーマンスレポートで、実際に「改善が必要」または「低い」の指標があるか
- 悪化した時期とアプリのインストール時期が、イベントアノテーション上で一致するか
- そのアプリはストアフロントにコードを読み込むタイプか、管理画面内で完結するタイプか
- 検証は複製テーマで行い、公開中のテーマを直接変更していないか
- 測定は複数回の平均か、1回の結果だけで判断していないか
- 商品ページとコレクションページを測っているか（トップページだけになっていないか）
- そのアプリが生んでいる売上や工数削減は、失う速度に見合うか
- テーマアプリ拡張を使っているアプリか（削除後にコードが残るか）
- 同じ役割のアプリが二重に入っていないか
最後の2つは見落とされがちです。特に、レビュー表示やポップアップのように役割が重なるアプリが並行して動いていると、どちらも同じような処理を読み込みます。
まとめ
判断の順序をまとめます。
- ウェブパフォーマンスレポートで現状を確認する。 LCP・INP・CLSのどれが「改善が必要」以下なのかを特定します。指標がすべて良好なら、アプリを減らす作業は優先度が低いと判断できます。
- 時系列レポートのイベントアノテーションで、悪化した時期と変更内容を突き合わせる。 ここで候補が2〜3本に絞れます。
- 複製テーマとPageSpeed Insightsで、候補アプリを個別に検証する。 ホーム17%、商品40%、コレクション43%の加重平均で前後の差を出します。
- 削除する場合は、テーマ内にコードが残っていないかまで確認する。 アンインストールは接続を切る操作であって、痕跡を消す操作ではありません。
「アプリが多いから重い」ではなく、「どのアプリが、どのページで、何ポイント」まで分解できれば、削るべきものと残すべきものは自然に分かれます。
アプリを入れる前の判断そのものを整理したい場合は、Shopifyのブログ機能はどこまで使える？標準機能とアプリの境界線もあわせてご覧ください。標準機能で足りる範囲を先に把握しておくことが、結果として最も確実な速度対策になります。
参考にした一次情報
注文確認メールの差出人が自社ドメインではなく [email protected] になっていたら、それはバグではなくShopifyの仕様です。2024年2月1日のGmail・Yahooの送信者要件に合わせて、Shopifyは認証が通らないドメインの送信元を自動的に書き換えます。厄介なのは、CNAMEを入れただけでは足りないこと、自動認証がDMARCを設定しないこと、DMARCが2つあると失敗すること、adkim=s が付いていると弾かれること、そしてメール転送を使うと「不要」なはずのSPFレコードが必要になることです。2026年9月1日時点のShopify公式ドキュメントで全条件を確認しました。