このページで: [隠れる]
ほとんどの 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 ホスティングのまとめ breaks down which providers ship the right stack out of the box.
Here’s a specific diagnostic. If your host can’t install OpenSearch 2.19 or doesn’t let you run Varnish 7.6, you’re not on Magento-capable hosting. Migrate before you spend another weekend chasing TTFB on a stack that can’t support the store.
3. Configure Varnish Plus Valkey (or Redis) Properly
ワニス 7.6 is the full-page cache. Configured right, it serves cached pages at sub-200ms TTFB 対 2-5 seconds uncached. The benchmark numbers back it up: cached-from-Varnish requests don’t even appear in Tideways’ slow-TTFB percentiles because they’re that much faster.
Configuration checklist:
- Varnish backend host and port point to your real web server
- Access list (ACL) restricted to admin IPs that should purge cache
- Grace period set to at least 10 分 (serves stale content while fetching fresh)
- Magento set to use Varnish under Stores > 構成 > 高度 > システム > Full Page Cache
Then layer Valkey 8 (or Redis 7.2) for cache, session storage, and object cache. トランシーバー 8 is the recommended new-install backend for 2.4.8. レディス 7.2 still works for existing stores. Valkey’s edge over Redis on Magento is under memory pressure, where it holds latency better on session reads.
4. Switch the Storefront to Hyvä
Hyvä sites score around 90-100 on Google PageSpeed デフォルトでは, と 65% of Hyvä stores hit excellent Core Web Vitals versus 41% for Luma stores. The JavaScript payload is a fraction of Luma’s because Hyvä dropped RequireJS and Knockout in favor of Alpine.js and Tailwind.
Here’s the 2026 update most guides haven’t caught: Hyvä went MIT-licensed and free in late 2024. There’s no per-domain theme license anymore. 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. Production mode pre-compiles dependency injection, deploys static view files once, 開発エラー出力を取り除きます.
単線スイッチ:
- 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 時間, ログイン時のバイパス
- カート, チェックアウト, customer account: bypass entirely
Magento’s Full Page Cache headers tell Varnish what’s cacheable. The CDN should respect those headers. If you’re overriding with blanket rules, you’re working against Magento’s own cache logic.
Also enable HTTP/3 at the CDN layer if it’s an option (Cloudflare and Fastly both support it). HTTP/3 uses QUIC instead of TCP, which recovers from packet loss faster on mobile networks. Real-world mobile LCP improvements of 100-300ms are typical on 4G connections, which is the difference between “読み込み中” と “loaded” for a lot of shoppers.
9. Rebuild Indexers and Maintain the Database
Even with 2.4.8’s Update by Schedule default, indexers drift. 走る bin/magento インデクサー:再インデックス on a weekly cron minimum, plus targeted reindex after bulk catalog imports.
Database maintenance nobody does:
- Truncate 引用 と quote_item tables quarterly (abandoned carts accumulate forever)
- クリーン sales_bestsellers_aggregated_* レポートを使用しない場合
- より古い注文をアーカイブする 24 Adobe Commerce の組み込みアーカイブを使用して数か月 (オープンソース ユーザーにはサードパーティ ツールが必要です)
A 6 GB 引用 テーブルはすべての管理クエリを遅くします. ほとんどの Magento ストアはこれを切り捨てたことはありません.
10. Defer JavaScript and Merge CSS Carefully
JS の縮小化を有効にする, 結合する, ストアの下のバンドル > 構成 > 高度 > デベロッパー. バンドルによりリクエスト数が削減されます. 小型化によりペイロードが削減される. 非クリティカルな JS の延期 (分析, チャットウィジェット) 初期レンダリングをブロックしないようにする.
1 つの警告. Luma の高度なバンドルには、特定のサードパーティ モジュールに対する既知のリグレッションがあります. 本番環境に切り替える前に、合成 Lighthouse 実行を使用してステージングでテストします。.
How to Diagnose Where Your Store Is Actually Losing Time
測定のない最適化は推測にすぎません. これは、単一の設定に触れる前に、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 がどのくらい削減されるか?
On a product page where LCP is a hero product image, 300-700ms improvement is typical. If your LCP image drops from 420KB to 140KB, that translates directly into faster render on any connection below 10 Mbps. Caveat: AVIF encoding is CPU-heavy, so generate at upload time (or via CDN) rather than on each request.
Magento の最速のホスティングは何ですか 2.4.8 お店?
“最速” depends on whether you want managed or self-managed. Managed Magento specialists like Nexcess and Hypernode ship a pre-tuned stack (PHP-FPM, ワニス, Redis or Valkey, オープンサーチ) and typically deliver sub-300ms TTFB out of the box. On the self-managed side, a Hetzner CX32 or equivalent at 8 GB RAM with Varnish and Valkey correctly configured can match that performance at 40-60% lower monthly cost, at the price of sysadmin work. The Magento VPS roundup linked earlier in this guide has the provider-by-provider breakdown.
Magentoはそのままの状態ではShopifyより遅いですか?
On raw page speed metrics, はい. 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 はカートと見積テーブルの読み取りを別のレイテンシ クラスに移動します. 上にリンクされているホスティングおよびテーマのガイドと組み合わせてください。, これでスタック全体がカバーされます.