このページで: [隠れる]
ほとんどの Magento スピード ガイドは次のように開きます。 “キャッシュをクリアします。” そのアドバイスはスキップしてください. キャッシュがボトルネックになるまでに, すでにスタック引数を失っています. 1 秒の遅延により Magento ストアにコストがかかる 7% コンバージョン数, そしてタイドウェイズ’ Q2 2025 ベンチマークは最も遅いことを示しています 25% マジェントの 2 最悪のページで 3 秒の TTFB に達する店舗. The 2026 勝利はホスティングスタック内に存在します (PHP 8.3+, トランシーバー 8, ワニス 7.6) 最初のリクエストが届く前に行うこと. Magento 2.4.8 (3月現在は安定している 2026) その一部を修正した. あとは店主次第.
簡単な回答: Magentoを実行する 2.4.8 の上 PHP 8.3+ と トランシーバー 8 キャッシュの処理, ワニス 7.6 全ページ実行中, と オープンサーチ 2.19 カタログ検索を強化. 収益がプロジェクトに見合う場合は店頭を Hyvä に切り替える. 優良サイトがヒット 65% 優れたコアウェブバイタル 対 41% ルマです. 以下のすべてのステップは、そのベースラインに対してスコアを付けます.
最終レビュー済み: 4月 2026. バージョン番号, キャッシュスタック, Adobe Commerce リリースノートと Tideways Q2 に対して検証されたベンチマーク データ 2025 報告.
Why Magento Speed Is a Revenue Problem
買い物客は Magento ストアをアーキテクチャで評価しない. 彼らは保釈される. コンテンツスクエアのデータショー 57% ページを放棄した買い物客の割合 ロードに 3 秒以上かかる, そしてコンバージョンが低下する 4.42% その後はさらに 1 秒ごとに. チェックアウトはもっと悪いです. チェックアウトに時間がかかる場合、ユーザーの半数以上が歩きます 30 端から端まで秒.
Magento は遅れて開始します. プラットフォーム上に構築された店舗では、カート放棄が発生します。 72-76% 範囲と世界の e コマース平均との比較 78.77% 8月現在 2025. Magento の販売者が Shopify や WooCommerce のショップよりもはるかに高い平均注文額を達成していることを思い出すまで、その差は小さいように思えます。. A 2% 店舗のコンバージョン上昇率が GMV で 400 万米ドルを押し上げる (商品総価値, 処理された総売上高) およそ米ドルです 80,000 回収された収益の年間あたり.
これはどれも理論的なものではありません. タイドウェイズ’ Q2 2025 キャッシュされていないMagentoに記録されたレポート 2 TTFBで 2 最も遅い場合は数秒 25% お店の様子とこれまでの様子 3 95 パーセンタイルの秒. それはあなたのテーマの前にあります, あなたの CDN, あなたの拡張子, またはホスティングが写真を入力してください. それはベースラインです.
The Real Causes of a Slow Magento 2 店
ほとんどのパフォーマンス作業は、飼い主が症状を追いかけるために失敗します. ジェネリックをスキップする “キャッシュをクリアして希望を持ってください” ルーティーン. これらは実際に Magento が遅い原因となる 6 つのパターンです 2 に店舗を構える 2026:
- PHP の仕様が不足しているか、設定が間違っています. PHPの実行 8.1 の上 2.4.8 作品, ある種の, しかし、OPcache, ジット, PHP の型システムの改善 8.3 Magento ワークロードでの複合. ホストがオンの場合 8.0 また 8.1, 測定可能な TTFB をテーブルの上に残し、アドビがテストを終了したバージョンのセキュリティ リスクを引き継ぐことになります.
- キャッシュスタックが不完全. ヴァルキーなしのワニス (or Redis), またはワニスなしの Valkey, 最も一般的な壊れた設定です. ワニス 7.6 匿名トラフィックのフルページ キャッシュを処理します. トランシーバー 8 キャッシュを処理します, セッション, ログイントラフィック用のオブジェクトキャッシュ. 両方必要です.
- OpenSearch が見つからないか、サイズが小さすぎます. Magento 2.4.8 必要 オープンサーチ 2.19. Elasticsearch は非推奨になりました. 一部の店舗では依然として古い ES 7.x を実行しており、なぜ検索ページに 4 秒かかるのか疑問に思っています.
- 拡張部の膨張. すべてのサードパーティ拡張機能は、依存関係注入コンパイラーとランタイム チェックにとって潜在的なプランキラーになります。. あるお店 80+ 拡張機能には、ほとんどの場合、チェックアウト イベントで不正な動作をするオブザーバーが 1 人存在します。.
- Luma のコモディティ ホスティング. Luma は以下のために設計されました 2015. Core Web Vitals 向けに設計されたものではありません. 良かったです.
- 画像は生の JPEG として提供されます. WebP は 25-34% JPEGより小さい. AVIF により、ヒーロー製品ショットのファイル サイズが再び半分になります. ほとんどのストアは依然として 400KB の製品画像を出荷していますが、なぜ LCP なのか疑問に思っています (最大の満足のいくペイント, 表示されている最大の要素のレンダリングにかかる時間) は 4 秒.
あなたのストアがそのリストのどこに位置するかによって、その後に続くものの順序が決まります.
Speed Up Magento Step-by-Step
これはビルドオーダーです. 手順を上から下に実行します. 初期のステップをスキップして次のステップにジャンプする “JavaScriptを最適化する” Magento では、基礎を固定する前に家にペンキを塗ることに相当します。.
1. Upgrade to Magento 2.4.8 (また 2.4.9 When It Lands)
Magento 2.4.8-p4 は 3 月現在の安定リリースです。 10, 2026. バージョン 2.4.9-ベータ1 GA でテスト中（5 月予定） 2026, MySQLを削除する 8.0 およびMariaDB 10.6 そしてPHPが必要です 8.4 また 8.5.
命名に関する簡単なメモ. Adobe Commerce と Magento オープンソースは同じコアコードベースと同じバージョン番号を共有します. B2B 見積における Adobe Commerce レイヤー, コマースのステージングとプレビュー, 高度なレポート作成, およびマネージド Adobe Commerce Cloud ホスティング スタック. このガイドのパフォーマンスに関するヒントは両方に当てはまります. クラウド層の Adobe Commerce の顧客は Fastly を利用できます, New Relic, および管理された Varnish がバンドルされています, それでステップ 3 と 8 以下はその層ですでに事前構成されています.
アップグレードする理由? 2.4.8 すべてのインデクサーを次のように反転します スケジュールモードによる更新 新規インストールおよびアップグレード時にデフォルトで. それだけで、ほとんどの店舗で管理者の商品保存のラグとチェックアウト更新の待ち時間が短縮されます。, 以前のデフォルトなので (“保存時に更新”) 完全なインデックスの再作成時にすべての保存がブロックされました. The 2.4.8 このリリースでは、REST API を介した一括階層価格更新も改善されました, B2B カタログにとって重要なこと.
ランニング 2.4.5 それ以前の? サポートされていないコードを使用しています. ここからパフォーマンスの仕事を始めましょう, 死んだブランチのキャッシュ調整は不要.
2. Fix the Hosting Stack Before Anything Else
いくらキャッシングしても救われない 1 vCPU / 2 Magento を実行する GB 共有プラン. プロダクションにとっての正直な最低限 2.4.8 店は 4 GB RAM, と 8-16 GB 過去のものの実用的なフロア 500 毎日の注文. 私たちの Magento VPS ホスティングのまとめ どのプロバイダがすぐに適切なスタックを出荷するかを分類します.
具体的な診断はこちら. ホストが OpenSearch をインストールできない場合 2.19 または、Varnish を実行できません 7.6, Magento 対応ホスティングを使用していない. ストアをサポートできないスタック上で TTFB を追いかけて週末を過ごす前に移行してください.
3. Configure Varnish Plus Valkey (or Redis) Properly
ワニス 7.6 フルページキャッシュです. 正しく構成されました, キャッシュされたページを提供します 200ms未満のTTFB 対 2-5 キャッシュされていない秒数. ベンチマークの数字がそれを裏付けています: Varnish からキャッシュされたリクエストは Tideways にも表示されません’ 遅い TTFB パーセンタイルははるかに速いため.
構成チェックリスト:
- Varnish バックエンド ホストとポートは実際の Web サーバーを指します
- アクセスリスト (ACL) キャッシュを削除する必要がある管理 IP に限定されます
- 猶予期間は少なくとも次のように設定されています 10 分 (新しいコンテンツを取得しながら古いコンテンツを提供します)
- Magento がストアで Varnish を使用するように設定 > 構成 > 高度 > システム > フルページキャッシュ
次にヴァルキーを重ねます 8 (or Redis 7.2) キャッシュ用, セッションストレージ, とオブジェクトキャッシュ. トランシーバー 8 に推奨される新規インストール バックエンドです 2.4.8. レディス 7.2 既存の店舗でも引き続き利用可能. Magento 上の Redis に対する Valkey の優位性はメモリ負荷にさらされています, セッション読み取り時のレイテンシがより良く保たれる場合.
4. ストアフロントを Hyvä に切り替える
良いサイトのスコアはおよそ 90-100 Google PageSpeed で デフォルトでは, と 65% の Hyvä 店舗が優れた Core Web Vitals に達したのに対し 41% ルマストア向け. Hyvä が Alpine.js と Tailwind を優先して RequireJS と Knockout を削除したため、JavaScript ペイロードは Luma の一部です.
こちらが 2026 ほとんどのガイドがキャッチできていないアップデート: Hyvä は後期に MIT ライセンスを取得し、無料になりました 2024. ドメインごとのテーマライセンスはもうありません. What still costs money is the migration work on a customized Luma store, 通常 80-200 時間, plus optional paid add-ons like Hyvä Checkout (ユーロ 1,000), Hyvä UI (ユーロ 250), or Hyvä Enterprise (ユーロ 2,500) if you need them. For any revenue-generating storefront, this is the single biggest Core Web Vitals move available. Still stuck on Luma? 私たちの Magentoテーマのまとめ covers faster Luma-compatible options, though none of them close the Hyvä gap.
重要な注意事項: それだけ 51% of Hyvä shops actually hit good CWV. The theme sets your ceiling. Poor implementation still lowers the floor. Audit third-party modules compiled into the Hyvä theme before you assume you’re done.
5. Enable Production Mode (Properly)
This one’s quick and people still miss it. Magento has three modes: デフォルト, 開発者, および生産. Developer and default modes regenerate view files on every request, log aggressively to var/log, and skip the compiled dependency injection configuration. 実稼働モードでは依存関係の注入をプリコンパイルします。, 静的ビュー ファイルを 1 回デプロイします, 開発エラー出力を取り除きます.
単線スイッチ:
- php bin/magentoデプロイ:モード:セット制作
コマンドが実行される内部で 設定:の:コンパイル と 設定:静的コンテンツ:配備. デプロイウィンドウ中に、モードを切り替えずにこれら 2 つのコマンドを手動で実行することもできます。, これは、ほとんどの CI パイプラインがそれを処理する方法です. 見返りは測定可能です: 誤って構成されたストアを開発者モードから運用モードに切り替えると、通常、TTFB がドロップされます 30-50% 他に何も変更せずに, すべてのリクエストで DI 生成と静的ファイル再構築税の支払いが停止されるためです。.
ステージング環境から実稼働環境にデプロイする場合, ステージングでコンパイルとデプロイの手順を実行し、生成されたファイルを再同期します. ピーク時の本番環境での再生成を回避する. コンパイルスパイク CPU 3-8 テーマの複雑さに応じて分, 静的コンテンツのデプロイメントにより、それをプッシュすることができます。 10-15 複数のロケールを含む Hyvä サイトでの分数.
6. Optimize Images With AVIF and WebP
ネイティブの遅延読み込みは、Magento に同梱されています。 2.4.0 HTMLのloading=を使用する”怠け者” カタログ画像の属性. テーマのカスタマイズ中に無効になった場合, 再度有効にする.
それ以上, 最新の形式で画像をプッシュする:
- WebP: JPEGサイズを次のようにカットします 25-34% ほぼ同じビジュアル品質で
- AVIF: ファイルサイズをさらに削減 40-50% 対 WebP, エンコードにはより多くの CPU が必要になります
- 商品撮影用, AVIF は色の忠実度が維持されるため、エンコードに時間を費やす価値があります。
高速画像最適化 (Adobe Commerce Cloud 上で) ブラウザごとにフォーマットネゴシエーションを自動的に実行します. 自己ホスト型ストアは、JaJuMa Ultimate Image Optimizer などの拡張機能を使用したり、デプロイ パイプラインに AVIF 生成を組み込んだりできます。. どちらにしても, CDN レベルの画像変換 週に数件以上の SKU アップロードを行うストアでは、リクエストごとの PHP 変換よりも優れたパフォーマンスを発揮します。.
7. Prune Extensions That Murder TTFB
インストールされているすべての拡張機能には少なくとも 1 つのプラグインが同梱されています, 観察者, または好み. 多くは数十隻を出荷します. チェックアウト イベントは、Magento で最もよく観察される単一のイベントであり、500 ～ 800 ミリ秒の TTFB リグレッションの最も一般的な原因です。.
監査ワークフロー:
- 走る bin/magentoモジュール:状態 有効なサードパーティモジュールをリストします
- ステージング時に重要でないモジュールを 1 つずつ無効にする
- 各無効化後のベンチマーク チェックアウト TTFB
- 明らかなビジネスコストをかけずに 100 ミリ秒以上を節約できるものはすべて無効にしておきます
出荷中のモジュールをよく見てください, プロモーション, およびB2Bカテゴリー. チェックアウト イベントの負荷が最も重いもの.
8. Add a CDN With Cache Rules That Actually Cache
Cloudflare, ファストリー, または、Magento の前の KeyCDN は賭け金です. 間違いは、デフォルトのルールを放置しておくことです. すぐに使える, ほとんどの CDN は、クエリ文字列を含むものについてはキャッシュをバイパスします。, これにより、フィルタリング可能なカテゴリページのキャッシュが強制終了されます。 ?p=2 ページネーション.
最小キャッシュ ルール セット:
- 静的資産 (JS, CSS, フォント, 画像): キャッシュ 1 年, 再検証中に古いものを提供する
- カテゴリページ: キャッシュ 1 匿名の場合は 1 時間, ログイン時のバイパス
- 製品ページ: キャッシュ 4-12 時間, ログイン時のバイパス
- カート, チェックアウト, 顧客アカウント: 完全にバイパスする
Magento のフル ページ キャッシュ ヘッダーは、キャッシュ可能なものを Varnish に伝えます. CDN はこれらのヘッダーを尊重する必要があります. 包括的なルールで上書きする場合, Magento 独自のキャッシュ ロジックに対して作業している.
も有効にします HTTP/3 オプションの場合は CDN 層で (CloudflareとFastlyは両方ともサポートしています). HTTP/3 は TCP の代わりに QUIC を使用します, モバイルネットワーク上でパケット損失からより早く回復します. 実際のモバイル LCP は 4G 接続で 100 ～ 300 ミリ秒改善されるのが一般的です, の違いは何ですか “読み込み中” と “ロード済み” たくさんの買い物客のために.
9. Rebuild Indexers and Maintain the Database
2.4.8 のデフォルトのスケジュールによる更新でも, インデクサーのドリフト. 走る bin/magento インデクサー:再インデックス 毎週の最小 cron, さらに、カタログの一括インポート後のターゲットを絞った再インデックス.
データベースのメンテナンスは誰も行わない:
- 切り詰める 引用 と 見積項目 四半期ごとの表 (放棄されたカートは永遠に蓄積されます)
- クリーン sales_bestsellers_aggregated_* レポートを使用しない場合
- より古い注文をアーカイブする 24 Adobe Commerce の組み込みアーカイブを使用して数か月 (オープンソース ユーザーにはサードパーティ ツールが必要です)
A 6 GB 引用 テーブルはすべての管理クエリを遅くします. ほとんどの Magento ストアはこれを切り捨てたことはありません.
10. Defer JavaScript and Merge CSS Carefully
JS の縮小化を有効にする, 結合する, ストアの下のバンドル > 構成 > 高度 > デベロッパー. バンドルによりリクエスト数が削減されます. 小型化によりペイロードが削減される. 非クリティカルな JS の延期 (分析, チャットウィジェット) 初期レンダリングをブロックしないようにする.
1 つの警告. Luma の高度なバンドルには、特定のサードパーティ モジュールに対する既知のリグレッションがあります. 本番環境に切り替える前に、合成 Lighthouse 実行を使用してステージングでテストします。.
店舗が実際に時間をロスしている場所を診断する方法
測定のない最適化は推測にすぎません. これは、単一の設定に触れる前に、Magento ストアで実行する診断スタックです。:
- PageSpeed Insights + CrUX: Chrome からの実際のユーザー データ. 75 パーセンタイルにある 3 つのコア ウェブ バイタルに焦点を当てる: LCP (最大の満足のいくペイント, Googleの “良い” しきい値は 2.5 秒未満です), インド (次のペイントへのインタラクション, 200ms未満を目標とする), とCLS (累積レイアウトシフト, 下のターゲット 0.1).
- Tideways または New Relic APM: トランザクションレベルのPHPトレース. どのコントローラーかを示します, 観察者, プラグインは時間を食います.
- DebugBear または SpeedCurve: 過去の傾向を利用した総合的なモニタリング. デプロイ後にリグレッションを捕捉する.
- Magento の組み込みプロファイラー: 経由で有効にする .htaccess, 遅いページの出力を検査する.
95 パーセンタイルを確認する, 中央値ではありません. 中央値は大丈夫かもしれません. The 5% 最も遅いページは通常、カート放棄が隠れている場所です.
Magento パフォーマンス スペシャリストを派遣する場合
一部のパフォーマンスの問題は DIY の問題ではありません. こんなときは専門家に依頼してください:
- Varnish が適切に構成され、インフラストラクチャが適切なサイズであれば、TTFB は 800 ミリ秒を超えます. これは、コードでは見つからない深いコードの問題またはプラグイン チェーンを示しています。 モジュール:状態.
- チェックアウト イベントは大幅にカスタマイズされてきました 3+ 年. オブザーバーのチェーンのもつれを解くことは完全な監査です, 午後ではない.
- カスタマイズされた Luma ストアからの Hyvä の移行を計画している場合. バジェット 120-200 簡単なカタログ以外のことについては、認定 Hyvä 代理店と何時間でも対応します.
- このガイドの最初の 6 つのステップはすでに完了していますが、TTFB はまだ上にあります 1 2番目.
A 40-60 Magento パフォーマンススペシャリストによる 1 時間の監査は通常、USD を実行します 8,000-15,000. 計算してみるまではかなりの量のように思えますが、 1% コンバージョン上昇率は年間 GMV に相当します.
よくある質問
Hyvä は小規模な Magento ストアにとって価値がありますか? 500 月ごとの注文数?
テーマ自体は今なら無料です (後期からMITライセンスを取得 2024), したがって、残るコストは移行作業だけです, 米ドルを運用する 5,000-15,000 控えめな店にオールイン. 下 500 米ドルでの月あたりの注文数 100 AOV, それでも投資回収期間は数年かかる. ホスティングを修正する, ワニス, 画像, そして最初に拡張監査. 年間GMVが100万ドルを超えたらHyväを再訪問してください, または、移行コストを前もって吸収できる場合はそれより早く.
Magento の最小ホスティング仕様はどれくらいですか 2.4.8 生産ストア?
4 GB RAM 絶対下限, 8 Varnish を実行している場合は GB, トランシーバー, 同じボックス上の OpenSearch と, 16 持っていればGB 50,000+ SKU または B2B カタログを実行する. CPUはRAMより重要ではない. Magento のボトルネックのほとんどはメモリ不足です, CPUではありません. 私たちの eコマースVPSのまとめ エンタープライズ価格なしでこれらの仕様を満たすプロバイダーをリストします.
Magento の Varnish はログインしている顧客に役立ちますか?
直接ではありません. Varnish は匿名トラフィックを提供します, ほとんどの B2C ストアではこれは 70-85% ページビューの. ログインしている顧客はコンテンツがパーソナライズされているため、フルページ キャッシュをバイパスします. ここで Valkey または Redis オブジェクト キャッシュが重要になります. ホームページとカテゴリ ページが新規訪問者に表示されます。. ログインユーザーの製品詳細とチェックアウトは引き続き PHP と Valkey にフォールバックします.
AVIF または WebP に切り替えると実際に LCP がどのくらい削減されるか?
LCP がヒーロー製品画像である製品ページ, 300-700ms の改善は典型的です. LCP イメージが 420KB から 140KB に減少した場合, これは、以下の接続でのレンダリングの高速化に直接変換されます。 10 Mbps. 警告: AVIF エンコードは CPU に負荷がかかります, したがって、アップロード時に生成します (またはCDN経由) リクエストごとではなく.
Magento の最速のホスティングは何ですか 2.4.8 お店?
“最速” 管理対象か自己管理対象かによって異なります. Nexcess や Hypernode などのマネージド Magento スペシャリストは、事前調整されたスタックを出荷しています (PHP-FPM, ワニス, Redis または Valkey, オープンサーチ) 通常、すぐに 300ms 未満の TTFB を実現します. 自己管理側では, Hetzner CX32 または同等品 8 Varnish と Valkey が正しく構成された GB RAM は、次のパフォーマンスに匹敵します。 40-60% 月額費用が安くなる, システム管理者の仕事の代償として. このガイドの前半にリンクされている Magento VPS のまとめには、プロバイダーごとの内訳が記載されています.
Magentoはそのままの状態ではShopifyより遅いですか?
生のページ速度メトリクスについて, はい. Shopify は、積極的なキャッシュを使用して、グローバル エッジ CDN からほとんどのページビューを提供します, そのため、TTFB では通常、新しい Shopify ストアが新しい Magento ストアを上回ります。. Magento が Varnish と CDN に移行すると、その差は劇的に縮まります. 店頭の柔軟性について, カスタマイズの深さ, およびB2B機能, マジェントの勝利, これが、企業がインフラストラクチャの複雑さを許容する理由です. Magento レベルのコントロールで Shopify のようなスピードが必要な場合, それが Hyvä とマネージド ホスティングのコンボです.
Magento サイトの速度を正確にテストするにはどうすればよいですか?
3 つのツールを実行して比較する. PageSpeed Insights は Google の公式 LCP を提供します, インド, 実際の Chrome ユーザーの 75 パーセンタイルに CLS が含まれています. WebPageTest.org を使用すると、特定の地理的位置とネットワーク速度からテストできます (正直なモバイル読み取りのために 4G Moto G4 プロファイルを選択してください). GTmetrix または DebugBear は時間の経過とともに回帰を追跡します. 両方の匿名カテゴリ ページをテストする (ワニスを効かせる場所) ログインしたチェックアウト (そうならないところは). 2 つの間のギャップから、キャッシュされていないスタックがどれだけの作業を行っているかがわかります。.
テイクアウト
より高速な Magento ストアへの最短ルートが魅力的なルートであることはほとんどありません。. 画像圧縮, CDN キャッシュ ルール, そして、Hyvä の移行は毎回、十数の拡張機能レベルの微細最適化を打ち破ります。. 走る 2.4.8 (また 2.4.9 5月に発送されたら 2026) 対応したハードウェア上で, レイヤーワニスとヴァルキー, 拡張機能を容赦なく監査する. ほとんどのお店が見ています 40-60% これら 4 つの動きだけで TTFB が改善.
まだインフラストラクチャを検討している場合, the NVMe ホスティング ガイド 有用な出発点です. 古い SATA ドライブでは、ディスク I/O が Magento のチェックアウト時間に大きく影響します, NVMe はカートと見積テーブルの読み取りを別のレイテンシ クラスに移動します. 上にリンクされているホスティングおよびテーマのガイドと組み合わせてください。, これでスタック全体がカバーされます.