Magento 2 Mağazam Neden Yavaş? 12 Yaygın Sebep ve Nasıl Düzeltileceği

Yavaş bir Magento 2 mağazası genellikle tek bir büyük sorundan kaynaklanmaz. Genellikle bir araya gelmiş birkaç küçük sorundur. İşte en sık karşılaştığım 12 neden ve her birini nasıl düzelteceğiniz.

Magento 2 mağazanız yavaş hissediyorsa, bunu hayal etmiyorsunuz ve yalnız da değilsiniz. Magento güçlü bir platformdur, ancak bu güç birçok hareketli parçayla birlikte gelir. Bir mağaza yavaş olduğunda, genellikle tek bir sorun değildir. Genellikle üst üste yığılmış beş veya altı daha küçük sorun vardır.

Bu kılavuzda, Magento 2 mağazalarını denetlerken en sık karşılaştığım 12 nedeni, her birini nasıl tanıyacağınızı ve bununla ne yapmanız gerektiğini anlatıyorum. Bunu kendi ekibiniz için bir kontrol listesi olarak kullanabilirsiniz.

Öncelikle: bir şeyleri değiştirmeden önce ölçün

Koda veya sunuculara dokunmadan önce bir temel oluşturun. Aksi takdirde, hangi değişikliğin gerçekten yardımcı olduğunu asla bilemeyeceksiniz.

  • Önbellekli ve önbelleksiz bir kategori sayfasındaki İlk Bayt Zamanı (TTFB)
  • Core Web Vitals (LCP, INP, CLS) gerçek kullanıcılar tarafından Google Search Console veya CrUX raporunda
  • Sunucu tarafı profil oluşturma New Relic, Blackfire veya Tideways gibi bir araçla
  • Tam sayfa önbelleğinizin (Varnish veya yerleşik önbellek) önbellek isabet oranı

Bu numaraları yazın. Aşağıdaki her düzeltme en az birini hareket ettirmelidir.

1. Tam sayfa önbelleği gerçekten çalışmıyor.

Bu bir numaralı nedendir. Varnish yüklü, ancak çoğu sayfa her istekte PHP ile hala oluşturuluyor. Yaygın suçlular:

  • Sayfanın bir yerinde bir blok cacheable="false" olarak işaretlenmiş, bu da tüm sayfanın önbelleğe alınamaz hale gelmesine neden oluyor.
  • Müşteriye özel veriler, özel içerik (müşteri bölümleri) aracılığıyla yüklenmek yerine sunucuda işlenir.
  • Ziyaret başına yeni bir önbellek girişi oluşturmak için utm_source veya gclid gibi izleme parametreleri kullanılır.

Düzelt: cacheable="false" için düzenleme XML’inizi arayın, kişiselleştirilmiş içeriği müşteri bölümlerine taşıyın ve Varnish yapılandırmanızda pazarlama parametrelerini kaldırın, böylece önbelleği bölmezler.

2. Üretim modu etkinleştirilmemiştir

Temel gibi geliyor, ama yine de varsayılan veya geliştirici modunda çalışan mağazalar buluyorum. Statik dosyalar anında oluşturuluyor ve hatalar ayrıntılı.

Düzelt: bin/magento deploy:mode:show komutunu çalıştırın. Eğer production yazmıyorsa, uygun bir dağıtımın parçası olarak bunu değiştirin.

3. Çok fazla üçüncü taraf uzantısı

Her eklenti, her isteğe gözlemciler, eklentiler ve bazen ekstra veritabanı sorguları ekler. Yirmi eklenti “küçük” şeyler yapıyorsa, bu saniyeler ekleyebilir.

Düzelt: bin/magento module:status ile her modülü listele, kullanmadığın her şeyi kaldır ve geri kalanları profil oluştur. Ürün koleksiyonu yükleme veya ödeme sürecine entegre olan eklentilere özel dikkat göster.

4. Ağır bir frontend teması (Luma ve onun çocukları)

Varsayılan Luma ön yüzü, genellikle yüzlerce JavaScript dosyası ile birlikte RequireJS, Knockout ve jQuery’yi yükler. Mobil cihazlarda bu, En Büyük İçerik Boyaması ve Bir Sonraki Boyama ile Etkileşim üzerinde olumsuz bir etki yaratır.

Düzelt: kısa vadede, mümkün olan her şeyi bir araya getirip erteleyin. Uzun vadede, en etkili seçenek daha hafif bir ön yüz olan Hyvä’ya geçmektir. Maliyetler, zaman çizelgeleri ve riskler ile ilgili ayrı bir Luma’dan Hyvä’ya geçiş kılavuzu yazdım.

5. Optimize edilmemiş görseller

Bir kameradan veya tedarikçi akışından doğrudan yüklenen ürün görselleri her biri birkaç megabayt olabilir.

Düzelt: modern formatları (WebP veya AVIF) sunun, duyarlı srcset boyutlarını kullanın, katmanın altındaki resimleri tembel yükleyin ve genellikle LCP öğeniz olan ana ürün resmini asla tembel yüklemeyin.

6. Yavaş veya yanlış yapılandırılmış veritabanı

Varsayılan ayarlarla çalışan MySQL veya MariaDB, özellikle büyük kataloglarda yaygın bir darboğazdır.

Düzelt: innodb_buffer_pool_size değerini ayarlayın, böylece çalışma veri kümeniz belleğe sığsın, yavaş sorgu günlüğünü etkinleştirin ve nelerin göründüğüne bakın. Veritabanasını hızlı NVMe depolama alanında tutun.

7. Yoğun saatlerde “Kaydettiğinde Güncelle” çalışan dizinleyiciler

İndeksleyiciler “Kaydetme sırasında Güncelle” olarak ayarlandığında, yönetici panelinde her ürün kaydı, müşteriler gezinirken ağır yeniden indekslemeyi tetikleyebilir.

Düzelt: indeksleyicileri “Zamanlama ile Güncelle” olarak değiştirin ve cron’un güvenilir bir şekilde çalıştığından emin olun. “işlem” durumunda takılı kalan indeksler için bin/magento indexer:status komutunu kontrol edin.

8. Cron sorunları

Magento, indeksleme, e-postalar, önbellek temizleme ve daha fazlası için cron’a bağımlıdır. Bozuk veya çakışan bir cron, her şeyi sessizce yavaşlatır.

Düzelt: “beklemede” veya “çalışıyor” durumunda biriken işler için cron_schedule tablosunu kontrol edin ve eski kayıtları temizleyin.

9. Redis kullanılmadı (veya kötü paylaşıldı)

Yük altında dosya sisteminde saklanan oturumlar ve önbellek yavaşlar.

Düzeltme: önbellek ve oturumlar için Redis kullanın, ideal olarak ayrı örnekler, böylece bir önbellek temizliği müşterilerinizi asla oturumdan çıkarmaz.

10. Arama motoru baskı altında

OpenSearch (veya eski sürümlerde Elasticsearch) katalog aramasını ve birçok kurulumda katmanlı navigasyonu destekler. Yetersiz bellek, kategori sayfalarını yavaşlatır.

Düzelt: arama motoruna özel bellek verin, yığın kullanımını izleyin ve onu web sunucularınızla aynı ağda tutun.

11. Gün içinde büyük katalog ithalatları

Büyük ürün veya fiyat ithalatları, tabloları kilitler ve önbellekleri geçersiz kılar. Eğer bunlar bir Pazartesi günü saat 11:00’de çalıştırılırsa, müşterileriniz bunu hisseder.

Düzelt: ithalatları gece yapın, partiler halinde ithalat yapın ve her ithalattan sonra tam önbellek temizlemelerinden kaçının. Sadece değişen etiketleri temizleyin.

12. Yetersiz veya güncel olmayan barındırma

Bazen sorun gerçekten sunucudadır: eski PHP sürümleri, yetersiz PHP-FPM işçileri veya Magento için asla tasarlanmamış paylaşımlı barındırma.

Çözüm: desteklenen bir PHP sürümünü çalıştırın, PHP-FPM işçilerini trafiğinize göre boyutlandırın ve statik varlıkların önüne bir CDN yerleştirin. Sadece donanım genellikle yavaş bir mağazayı düzeltmez, ancak kötü donanım iyi bir mağazayı yavaşlatabilir.

Pratik bir çalışma sırası

Nereden başlayacağınızdan emin değilseniz, bu sipariş en az riskle en büyük kazançları sağlar:

  1. Tam sayfa önbellek hit oranını düzeltin
  2. Üretim modunu, Redis’i ve cron’u onaylayın
  3. Kullanılmayan uzantıları kaldırın
  4. Görüntüleri ve LCP öğesini optimize edin
  5. Veritabanını ayarlayın ve arama yapın
  6. Bir ön yüz yükseltmesi planlayın (örneğin Hyvä’ya).

Sıkça sorulan sorular

Bir Magento 2 mağazası ne kadar hızlı olmalıdır?

Önbelleklenmiş TTFB’yi yarım saniyenin oldukça altında ve Core Web Vitals’ı çoğu gerçek kullanıcı için “iyi” aralığında hedefleyin: LCP 2.5 saniye veya altında, INP 200 ms veya altında ve CLS 0.1 veya altında.

Daha fazla sunucu gücü, yavaş bir Magento mağazasını düzeltir mi?

Genellikle sadece kısmen. Eğer tam sayfa önbelleği çoğu isteği kaçırıyorsa, daha büyük bir sunucu sadece yavaş kodu biraz daha hızlı çalıştırır. Önce önbelleği ve kodu düzeltin.

2026’da Magento 2 hala iyi bir seçim mi?

Karmaşık kataloglara, B2B ihtiyaçlarına veya birden fazla mağazaya sahip olan mağazalar için evet. Düzenli teknik bakıma ihtiyaç duyar, bu yüzden performans çalışmaları planlanmalı, reaktif olmamalıdır.

İkinci bir çift göze mi ihtiyacınız var?

Mağaza sahiplerine ve e-ticaret ekiplerine, Varnish yapılandırmasından tam Hyvä geçişlerine kadar bu sorunları bulup çözmelerine yardımcı oluyorum. Mağazanız yavaşsa ve net, önceliklendirilmiş bir plana ihtiyacınız varsa, Magento 2 ve Hyvä hizmetime veya performans denetimi talep etmeye bir göz atın.