PrestaShop mağazanız yüklenirken çok uzun sürüyor

Yavaş PrestaShop sitesi: sunucu mu, tarayıcı mı?

Herhangi bir şeyi düzeltmeden önce zamanın sunucuda mı yoksa tarayıcıda mı kaybolduğunu bilmek gerekir. Tarayıcının geliştirici araçlarını açın, Ağ sekmesinde ilk satıra bakın: sunucunun yanıt vermesi için geçen süre, yani TTFB.

• Yüksek TTFB, yaklaşık bir saniyenin üzerinde: sunucu sayfayı üretmekte gecikiyor. Neden PHP’de, veritabanında ya da bir modüldedir; bu sayfanın konusu da budur.
• TTFB iyi ama sayfa geç görünüyor: sunucu hızlı yanıt veriyor, ardından tarayıcı zorlanıyor. Fazla ağır görseller, üçüncü taraf betikler (canlı sohbet, yorumlar, reklam izleme), ertelenmemiş yazı tipleri ve JavaScript: bu sunucu değil, ön yüz işidir.
• Yalnızca yönetim paneli yavaş: büyük hacimli sipariş, ürün ya da müşteri listelerine, gösterge paneli modüllerine ve hiçbir şey temizlemediğinde sınırsızca büyüyen ps_connections, ps_guest ya da ps_pagenotfound gibi istatistik tablolarının boyutuna bakın.

Tüm mağazayı yavaşlatan unutulmuş ayarlar

Gördüğüm yavaş mağazaların şaşırtıcı bir kısmında kod sorunu yoktur: yalnızca bir arıza giderme ayarı açık kalmıştır.

• Bir müdahaleden sonra config/defines.inc.php içinde true olarak bırakılan _PS_MODE_DEV_. 1.7, 8 ve 9’da yönetim panelini Symfony’nin belirgin biçimde daha yavaş olan geliştirme ortamında da çalıştırır.
• Etkin bırakılan _PS_DEBUG_PROFILING_: her sayfa kendi profilini hesaplayıp gösterir, bu da her görüntülemede zaman kaybettirir.
• Gelişmiş Parametreler > Performans altında şablon derlemesinin “Derlemeyi zorla” olarak ayarlanması: Smarty şablonları yeniden kullanmak yerine her görüntülemede yeniden derler.
• Aynı ekranda, bazen “bir değişikliği görmek” için kapatılıp bir daha açılmayan önbellek.

Bu dört nokta birkaç dakikada kontrol edilir ve hiçbir geliştirme gerektirmez. Barındırma hakkında herhangi bir sonuca varmadan önce bakılmalıdır.

En sık düzelttiğim sorunlar

PrestaShop'un varsayılan dosya önbelleği (var/cache), birkaç yüz ürünlük bir katalogda gayet iyi çalışır; ancak yoğun eşzamanlı trafiğe sahip büyük bir katalogda darboğaz haline gelir, çünkü her önbellek yazma işlemi diski kilitler. Bellek içi önbelleğe geçmek, koda dokunmadan çoğu zaman durumu tamamen değiştirir.

Veritabanı tarafında, join işlemlerinde kullanılan sütunlarda (id_product, id_shop, id_lang) indeks bulunmaması, katalog büyüdükçe yanıt süresini ciddi şekilde artırır; oysa aynı sayfa, az veri içeren test ortamında hızlı kalmaya devam eder.

Son olarak, bazı öneri, pazarlama izleme veya PDF oluşturma eklentileri, işlev o anda kullanılmıyor olsa bile her sayfa görüntülemesinde ağır kod çalıştırır. Bunları hook hata ayıklayıcısı üzerinden tespit ediyor ve koşullu devre dışı bırakma ya da asenkron göreve geçirme öneriyorum.