# Yavaş bir e-ticaret sitesi nasıl teşhis edilir

> Yavaş bir mağaza karşısında rastgele barındırma değiştirmek sorunu nadiren çözer, çünkü yavaşlığın hemen her zaman kesin ve tespit edilebilir bir nedeni vardır. Harekete geçmeden önce ölçmek, zamanı ve parayı yanlış yönde harcamayı önler.

- Source canonique : [https://allaux.fr/tr/guides/diagnostiquer-boutique-lente](https://allaux.fr/tr/guides/diagnostiquer-boutique-lente)
- Langue : TR
- Dernière mise à jour : 2026-09-30

## Kısa yanıt

> Önce, kaybedilen zamanın sunucu tarafında mı yoksa görüntüleme tarafında mı olduğunu anlamak için TTFB'yi ölçün, ardından en yavaş sayfada çalıştırılan SQL sorgularını sayın. Çoğu durumda neden bu ikisinden birinde bulunur, nadiren ikisinde birden.

## Teşhis yaklaşımı

1. **Harici bir araçla ölçün** — PageSpeed Insights veya GTmetrix, ilk objektif ölçümü verir: yükleme süresi, TTFB, sayfanın toplam ağırlığı ve yüklenmesi en yavaş kaynakların ayrıntısı.
2. **Sunucu süresini ve render süresini birbirinden ayırın** — Dinamik bir sayfada 600-800 ms'yi aşan yüksek bir TTFB, bir sunucu veya veritabanı sorununa işaret eder. Doğru bir TTFB'ye rağmen yavaş tamamlanan bir görüntüleme ise daha çok kaynakların ağırlığına veya JavaScript render sürecine işaret eder.
3. **En yavaş sayfada SQL sorgularını sayın** — PrestaShop'ta debug modu, her SQL sorgusunu ve çalışma süresini listeleyen bir profilleme çubuğunu etkinleştirir. WooCommerce'de Query Monitor eklentisi eşdeğer bir işlev sunar.
4. **Önbelleğin durumunu kontrol edin** — Devre dışı bırakılmış, kötü yapılandırılmış veya sistematik olarak geçersiz kılınan bir önbellek, başka herhangi bir optimizasyonu düşünmeden önce ele alınması gereken en sık görülen ve en kolay düzeltilen nedenlerden biridir.
5. **Sunucu yapılandırmasını kontrol edin** — Kullanılan PHP sürümü, OPcache'in varlığı ve kullanılabilir memory_limit, özellikle hacimli bir katalogda doğrudan bir etki yaratır.
6. **Şüpheli eklentileri veya modülleri izole edin** — Her sayfada ağır kod çalıştıran bir eklenti veya modül (harici çağrı, izleme, ürün önerisi), o an işlevi kullanılmıyor olsa bile sitenin tamamını yavaşlatabilir.

## Barındırmayı değiştirmeden önce neden ölçmeli

Daha güçlü bir sunucu, kötü indekslenmiş sorgular veya iyi optimize edilmemiş eklentilerden kaynaklanan bir sorunu geçici olarak gizler; ancak katalog veya trafik yeniden arttığında yavaşlık geri döner. Tersine, alınan trafik için gerçekten yetersiz kalan bir barındırma, yalnızca kodu optimize ederek düzelmez.

Ölçümün her zaman kararın önüne geçmesinin nedeni budur: sorunun yapısal mı (indekslenmemiş veritabanı, önbellek yokluğu) yoksa kapasiteyle mi ilgili (gerçek ziyaret hacmi için yetersiz sunucu kaynakları) olduğunu gösterir. İkisi farklı şekilde ve nadiren aynı aciliyetle ele alınır.

Birkaç bin ürünlük bir katalogda, birleştirme (join) işlemlerinde kullanılan sütunlarda (ürün kimliği, mağaza kimliği, dil kimliği) indeks eksikliği tekrarlayan bir nedendir; test ortamında veri hacmi düşük kaldığı sürece görünmez kalır.

## Bir teşhisi gerektiren sinyaller

- Görüntülenmesi üç saniyeden fazla süren bir ürün sayfası veya kategori sayfası
- Görünür bir teknik değişiklik olmadan aylar içinde kademeli bir yavaşlama
- Katalog birkaç bin ürünü aştığında yalnızca o zaman yavaşlayan bir yönetim paneli
- Performanslı olarak sunulan bir barındırmaya rağmen kötü bir PageSpeed skoru veya Core Web Vitals sonuçları
- Yalnızca trafik zirvelerinde ortaya çıkan bir yavaşlık

## FAQ

### Performans teşhisi siteyi daha da yavaşlatma riski taşır mı?

Hayır, ölçüm ve profilleme siteyi kesintiye uğratmadan veya işleyişini değiştirmeden yapılır. Yalnızca sonradan belirlenen düzeltmeler uygulanır ve bunlar genellikle canlıya alınmadan önce test edilir.

### Eksiksiz bir teşhis ne kadar sürer?

Genellikle temel nedenleri belirlemek için yarım günden bir güne kadar sürer. Düzeltmenin kendisi ise sorunun niteliğine göre büyük ölçüde değişir: bir indeks eklemek birkaç dakikada halledilirken, kötü optimize edilmiş bir modül daha fazla zaman gerektirir.

### Yerelde hızlı ama canlı ortamda yavaş çalışan bir site normal midir?

Evet, hatta bu oldukça yaygındır: test ortamı genellikle çok daha az veri içerir; bu da gerçek ürün ve sipariş hacmiyle ancak ortaya çıkan indeks veya sorgu sorunlarını gizler.

### Yavaşlık yalnızca yönetim panelini etkiliyorsa, bu kadar önemsenmeli mi?

Evet, ticari etkisi dolaylı olsa bile: yavaş bir yönetim paneli, katalog ve siparişlerin günlük yönetimini yavaşlatır ve katalog büyüdükçe yakında sitenin ön yüzünü de etkileyecek bir sorunun erken belirtisi olabilir.