WordPress siteniz neden yavaş açılıyor? Ölçtüğümüz gerçek bir vaka
Yavaş bir siteyle karşılaşınca ilk duyduğumuz cümle hep aynı: “WordPress işte, hantaldır.” Çoğu zaman bu doğru değil. Aşağıda gerçek bir müşteri sitesinde ne bulduğumuzu, hangi ölçümleri aldığımızı ve neyin işe yarayıp neyin yaramadığını anlatıyoruz.
Önce ölçün, sonra dokunun
FD Art Gallery, WooCommerce üzerinde çalışan bir sanat galerisi ve satış sitesi. Şikâyet nettir: sepet sayfası açılmıyor. Ölçtük — 2,9 saniye. Ana sayfa ise gayet iyiydi. Bu ikilik önemli bir ipucu: sorun bütün sitede değil, önbelleğe alınamayan sayfalarda.
Buradaki refleks genelde “sunucuyu büyütelim” olur. Biz önce sayfanın nereye zaman harcadığını çıkardık. Geçici bir mu-plugin ile profil aldık:
- Veritabanı: 21 sorgu, 14 ms — toplam sürenin yaklaşık %1’i.
- Toplam süre: 2.761–3.330 ms.
- Tepe bellek kullanımı: 186 MB.
Veritabanı masumdu. Zaman PHP’nin kendisinde gidiyordu.
Asıl sebep: hiç yapılandırılmamış OPcache
PHP, her istekte kaynak dosyaları yeniden derlemesin diye derlenmiş kodu OPcache’te tutar. Sunucuda OPcache hiç yapılandırılmamıştı; PHP’nin varsayılanıyla çalışıyordu: 128 MB bellek, 10.000 dosya sınırı. Kutuda dört WordPress sitesi vardı ve her biri istek başına yaklaşık 3.240 dosya yüklüyordu.
Ölçüm şunu gösterdi:
opcache: bellek 128/128 MB DOLU · isabet %22 · kaçırma 106.213İmzası şuydu: aynı kod, aynı 12 eklenti, aynı veriyle çalışan geliştirme kopyası 1,2 saniyede ve 38 MB tepe bellekle açılıyordu; canlı ise 2,9 saniye ve 186 MB. İki ortam arasındaki bu bellek uçurumu, OPcache’in dolduğunun en net göstergesidir.
Uygulanan ayar
opcache.memory_consumption = 768 ; önce 512 denendi, 509/512 ile doldu
opcache.interned_strings_buffer = 32
opcache.max_accelerated_files = 50000
opcache.validate_timestamps = 1
opcache.revalidate_freq = 2Bu ayar PHP_INI_SYSTEM seviyesindedir; havuz başına verilemez, sunucudaki bütün siteleri birden etkiler. Dört sitenin de sahibi aynı olduğu için onay alıp uyguladık.
Sonuç — aynı yöntemle ölçüldü
| önce | sonra | |
|---|---|---|
| /cart/ | 2,9–3,2 sn | 0,94–0,97 sn |
| /my-account/ | 2,6–2,9 sn | 0,74–0,95 sn |
| /checkout/ | 1,7–2,0 sn | 0,40–0,48 sn |
| tepe bellek | 186 MB | 34 MB |
| OPcache isabet | %22 | %89 |
Reklamdan gelen ziyaretçi en yavaş deneyimi yaşıyordu
İkinci bulgu daha sinsiydi. Reklam ve bülten bağlantıları adrese ?utm_source=…, gclid, fbclid gibi parametreler ekler. Önbellek bu adresleri farklı sayfa sayar ve hepsini atlar. Yani en pahalı trafiğiniz, önbelleksiz ve en yavaş sürümü görür.
Bu parametreleri önbellek anahtarından çıkardık. TTFB ~2,3 saniyeden 15–25 milisaniyeye indi.
İşe yaramayan deneme: LCP ön yükleme
Mobil puan düşüktü ve Lighthouse “LCP ön yükleme yok” diyordu. Hero görseli, Elementor tarafından satır içi background-image olarak HTML’in 74.856. karakterinde basılıyordu; </head> ise 25.246’da bitiyordu. CSS arka planları ön tarayıcıya görünmez, yani tarayıcı görseli çok geç keşfediyordu. Mantıklı bir hedefti.
Ön yükleme etiketini <head>’e bastıran bir mu-plugin yazdık ve ölçtük:
| önce | preload ile | |
|---|---|---|
| LCP (mobil) | 12.211 ms | 12.309 ms |
| Puan | 48 | 39 |
Fark yok — hatta puan düştü. Çünkü darboğaz görseli indirmek değil, JavaScript çalıştırmaktı: Style & Layout 4,3 sn, jQuery 4,8 sn. 287 KB’lık bir görseli yüksek öncelikle çekmenin bedeli de vardı. Değişikliği geri aldık.
Geriye kalan: kod değil, tasarım kararı
Masaüstünde iş bitti (puan 85, LCP 2,0–2,3 sn). Mobilde ise sayfa hâlâ 3.358 KB ve 111 istek. Dağılım şöyleydi: görseller 1.332 KB, tek başına Turnstile widget’ları ~1 MB, elementor-all-widgets.min.js 135 KB ve bunun %82’si kullanılmıyor, woocommerce-all.min.css’in %99’u kullanılmıyor.
Bunlar sunucu ayarıyla çözülmez. Ana sayfada 33 container ve 60 widget varken “Style & Layout” maliyetini kod tarafından kısamazsınız; sayfayı sadeleştirmek gerekir. Bu noktadan sonrası müşterinin içerik ve tasarım kararıdır — ve biz de öyle söyledik.
Çıkarılacak dersler
- Ölçmeden dokunmayın. “Veritabanı yavaştır” varsayımıyla başlasaydık sorguları optimize edip hiçbir şey kazanmayacaktık.
- Sunucu ayarları sessizce bozulur. OPcache dolduğunda uyarı vermez. Aynı kodun iki ortamda farklı bellek tüketmesi güçlü bir ipucudur.
- Önbelleği reklam trafiği için de düşünün. Parametreli adresler önbelleği atlarsa en değerli ziyaretçiniz en yavaş sayfayı görür.
- İşe yaramayan denemeyi geri alın ve yazın. Ölçülebilir kazancı olmayan bir “iyileştirme” teknik borçtan başka bir şey değildir.