Bir WordPress sitesinin neden yavaş olduğu sorusuna internette onlarca hazır cevap var, ama bu cevapların çoğu yarım doğru ya da güncelliğini yitirmiş tavsiyeler. "Şu eklentiyi kaldır", "şu temaya geç", "CDN aç" gibi öneriler bazen işe yarar, bazen hiçbir şey değiştirmez, çünkü asıl darboğaz genelde başka bir yerdedir. Bu yazı, hız konusunda en sık tekrarlanan altı yanlış inanışı tek tek ele alıyor: her birinde inanışın nereden geldiğini, gerçekte ne olduğunu ve doğru düzeltmenin ne olduğunu göreceksiniz. Amaç, bir sonraki hız sorununda hangi soruyu sormanız gerektiğini öğretmek.
Hız gerçekten önemli mi? Rakamlar ne diyor
Google, "hızlı" sayılmanın sınırını belirsiz bırakmıyor. Core Web Vitals adı verilen üç ölçüm, web.dev üzerinde resmi olarak tanımlanan eşiklere sahip: en büyük içerik boyaması (LCP) için iyi kabul edilen sınır 2.5 saniyenin altı, etkileşimden sonraki boyama (INP) için 200 milisaniyenin altı, kümülatif düzen kayması (CLS) için 0.1'in altı. Bu sınırlar ziyaretçilerin yüzde 75'inin yaşadığı gerçek deneyime göre hesaplanıyor, yani sitenizin "iyi" sayılması için gerçek trafiğinizin çoğunluğunun bu eşiklerin içinde kalması gerekiyor; tek seferlik bir laboratuvar testinin sonucu bu ölçümün yerini tutmaz.
Sayılar teoride kalmıyor. Google'ın mobil sayfa hızı üzerine yürüttüğü araştırmaya göre, yükleme süresi 1 saniyeden 10 saniyeye çıktığında ziyaretçinin sayfayı terk etme olasılığı yüzde 123 artıyor; 1 saniyede yüklenen bir sayfada terk oranı yüzde 7 iken, 3 saniyede yüzde 11'e, 5 saniyede yüzde 38'e çıkıyor. Dijital pazarlama ajansı Portent'in 100 milyondan fazla sayfa görüntülemesini incelediği araştırmasında ise, 0 ile 5 saniye aralığında her ek saniyenin dönüşüm oranını ortalama yüzde 4.42 düşürdüğü bulundu. Hız burada soyut bir teknik ayrıntı olmaktan çıkıp, doğrudan gelire yansıyan somut bir metriğe dönüşüyor.
Bu üç eşikten pratikte en çok gözden kaçırılanı INP. Çoğu WordPress sitesi ilk yüklemede hızlı görünür ama bir menüye tıklandığında, bir form gönderildiğinde ya da bir filtre uygulandığında tepki vermesi gözle görülür şekilde gecikir; bunun nedeni genelde sayfaya sonradan eklenen üçüncü taraf scriptlerin (canlı sohbet widget'ı, reklam takip kodu, sosyal medya eklentisi) ana thread'i meşgul etmesi. LCP ve CLS görsel olarak fark edilirken, INP sorunu ancak siteyle gerçekten etkileşime geçildiğinde ortaya çıkar, bu yüzden çoğu site sahibi bu sorunun farkına bile varmaz.
Yanlış inanış: En pahalı hosting her zaman en hızlı hostingdir
Fiyat etiketi ile performans arasında sanılan kadar güçlü bir bağ yok. Paylaşımlı bir sunucuda gerçek sorun, aynı fiziksel sunucuyu yüzlerce başka siteyle paylaşmanız: CPU ve bellek kaynaklarınız aynı anda onlarca farklı siteye bölünüyor. Bu paylaşım, ödediğiniz fiyattan bağımsız olarak her paylaşımlı pakette var. Pahalı bir plan bu paylaşımı bazen azaltır ama otomatik olarak çözmez; yüksek fiyatlı paketlerin bir kısmı da arka planda aynı paylaşımlı altyapıyı kullanır, sadece üzerine daha fazla destek hizmeti ekler.
Gerçek farkı yaratan şeyler daha teknik: sunucunun PHP sürümü ve OPcache yapılandırması, disk tipi (NVMe SSD ile eski bir HDD arasında sorgu yanıt süresinde kat kat fark olabilir), web sunucusu yazılımı (LiteSpeed veya doğru yapılandırılmış Nginx, standart Apache'den genelde daha hızlı yanıt verir) ve sunucunun ziyaretçilerinize coğrafi olarak ne kadar yakın olduğu. Hosting seçerken gerçek TTFB (sunucudan ilk baytın dönüş süresi) ölçümüne bakmak, fiyat etiketine güvenmekten çok daha güvenilir bir yöntem; aynı fiyat aralığındaki iki sağlayıcı arasında bile büyük fark bulabilirsiniz.
WordPress'e özel yönetilen (managed) hosting çözümleri de bu tabloya ayrı bir değişken ekliyor: bu sağlayıcılar genelde sunucu seviyesinde bir page cache, WordPress çekirdeğine göre ayarlanmış PHP-FPM havuzları ve otomatik OPcache yönetimi sunuyor. Bu, aynı fiyata genel amaçlı bir sunucudan alacağınızdan daha yüksek bir taban performans anlamına gelebilir; ama tek bir gösterge de tam güven vermez. En güvenilir yöntem, sağlayıcının gerçek dünya TTFB rakamlarını kendi test sitenizle ölçmek.
Yanlış inanış: Her hız sorunu bir eklenti sorunudur
Eklenti sayısını azaltmak sık verilen bir tavsiye ve bazı durumlarda gerçekten işe yarıyor. Ama yavaşlığın kaynağı çoğu zaman eklenti sayısından çok, tek bir eklentinin veya temanın nasıl kod yazdığıyla ilgili. İyi yazılmış on eklenti, kötü yazılmış tek bir eklentiden sunucuya daha az yük bindirebilir. Asıl belirleyici olan, her eklentinin veritabanına kaç sorgu gönderdiği, bu sorguların bir index kullanıp kullanmadığı ve sayfa her yüklendiğinde gereksiz yere tekrar çalışıp çalışmadığı.
Yaygın bir teknik sorun N+1 sorgu deseni: bir eklenti tek bir listeyi göstermek için, listedeki her öğe için ayrı ayrı veritabanı sorgusu çalıştırıyor. On öğelik bir listede bu on bir ayrı sorgu demek, yüz öğelik bir listede yüz bir sorgu. Bu tür bir sorunu, hangi eklentinin veya tema fonksiyonunun bu sorguları tetiklediğini Query Monitor gibi bir profiling aracıyla tespit ederek çözersiniz; rastgele eklenti silmek genelde aynı sonucu vermez. Render'ı bloke eden senkron JavaScript ve harici font veya analitik scriptleri de genelde eklenti listesinde görünmeyen ama gerçek darboğaz olan unsurlardır.
Somut bir örnek vermek gerekirse: 50 ürünlük bir kategori sayfasını render eden kötü yazılmış bir eklenti, her ürün için ayrı ayrı stok durumu, fiyat ve görsel sorgusu çalıştırırsa toplamda yüz elliden fazla veritabanı sorgusu gönderebilir. Aynı işi doğru yazılmış bir eklenti, tek bir toplu sorguyla (JOIN veya IN ifadesiyle) yapar. Bu iki eklenti de "bir eklenti" olarak sayılır ama sunucuya bindirdikleri yük arasında onlarca kat fark olabilir. Bu yüzden asıl işe yarayan adım, eklenti sayısını körü körüne azaltmak yerine, hangi eklentinin verimsiz çalıştığını tespit edip onu değiştirmek veya kaldırmaktır.
Yanlış inanış: Bir önbellekleme eklentisi kurmak sorunu tek başına çözer
Sayfa önbelleği (page cache), bir sayfanın önceden oluşturulmuş statik kopyasını saklar ve sonraki anonim ziyaretçilere doğrudan bu kopyayı sunar; bu yüzden özellikle ilk ziyaretlerde büyük fark yaratır. Ama bu katmanın ulaşamadığı yerler var: giriş yapmış kullanıcılar, sepet ve ödeme sayfaları, form gönderimleri gibi dinamik içerikler genelde önbelleğin dışında bırakılır, çünkü her ziyaretçiye farklı bir gövde döndürülmesi gerekir. Bu sayfalarda sunucu her seferinde PHP çalıştırıp veritabanına gidiyor, yani sayfa önbelleği devrede olsa bile TTFB yüksek kalabiliyor.
Bu boşluğu kapatan katman object cache: Redis veya Memcached gibi bellek içi bir depolama, tekrar eden veritabanı sorgu sonuçlarını saklayıp aynı sorgunun tekrar veritabanına gitmesini engelliyor. Sayfa önbelleği ile object cache farklı problemleri çözüyor, biri statik gövdeyi hızlandırıyor, diğeri dinamik sorgu yükünü azaltıyor, ikisi birlikte çalıştığında gerçek fark ortaya çıkıyor. Ayrıca yanlış yapılandırılmış bir cache invalidation kuralı, güncellediğiniz bir sayfanın ziyaretçilere eski haliyle görünmesine yol açabilir; bu yüzden bir önbellekleme eklentisini kurup unutmak yerine, hangi sayfa tiplerinin ne zaman yeniden oluşturulduğunu bilmek gerekir.
Yanlış inanış: Görseli sıkıştırmak, görseli optimize etmekle aynı şeydir
Sıkıştırma, bir görselin dosya boyutunu gözle fark edilmeyecek bir kalite kaybıyla küçültme işlemi ve tek başına faydalı. Ama optimizasyon bundan daha geniş bir kavram, üç ayrı bileşeni kapsıyor:
- Doğru format: WebP veya AVIF, aynı görsel kalitesinde JPEG'den yüzde 25 ile 50 arasında daha küçük dosya üretir
- Responsive sunum: srcset ile masaüstüne 2000 piksellik görseli, telefona ise ekranına uygun küçük boyutu gönderin
- Doğru yükleme stratejisi: ekran dışındaki görselleri lazy loading ile geciktirin, ilk ekranda görüneni asla geciktirmeyin
Sıklıkla atlanan bir detay da width ve height attribute'ları. Bu değerler tanımlanmadığında tarayıcı görsele ne kadar yer ayıracağını bilmiyor, görsel yüklendiğinde sayfa aniden kayıyor; bu da CLS skorunu doğrudan bozan, ziyaretçinin gözle görebileceği bir sorun. Sıkıştırılmış ama yanlış boyutta sunulan, lazy loading'i doğru kullanmayan veya boyut attribute'u eksik bir görsel, dosya boyutu küçük görünse bile hâlâ optimize edilmemiş sayılır.
Yanlış inanış: CDN kurmak her siteyi otomatik olarak hızlandırır
CDN (içerik dağıtım ağı), statik dosyalarınızı (görsel, CSS, JavaScript, bazı yapılandırmalarla önbelleğe alınmış HTML) dünya genelinde dağıtılmış sunuculardan, ziyaretçiye coğrafi olarak en yakın olandan sunar. Bu mekanizma gerçek bir fayda sağlar, ama büyük farkı özellikle şu koşulda yaratır: ziyaretçileriniz farklı ülke veya kıtalardan geliyorsa. Ziyaretçi kitleniz tek bir şehirde ya da bölgede yoğunlaşıyorsa, origin sunucunuz zaten yakın olduğu için CDN'in kazandırdığı mesafe avantajı sınırlı kalır.
Daha da önemlisi, CDN dinamik içeriği hızlandırmaz. PHP tarafından her istekte yeniden oluşturulan sayfa gövdesi (özellikle giriş yapmış kullanıcılar veya kişiselleştirilmiş içerik için) genelde origin sunucudan gelmeye devam eder; CDN burada devreye girmez. Yanlış yapılandırılmış cache header'ları da CDN'in statik dosyaları bile doğru önbelleğe almasını engelleyebilir, bu durumda CDN kurulu olsa da fiilen çalışmıyor demektir. CDN'i açmak önbellekleme ve hosting kalitesinin yerini tutmaz, onların üzerine eklenen bir katmandır.
Yanlış inanış: Hız optimizasyonu bir kere yapılır, biter
Bir siteyi bugün optimize etmek, altı ay sonra da hızlı kalacağı anlamına gelmiyor. Eklenti ve tema güncellemeleri zamanla yeni kod, yeni script, yeni bağımlılık ekliyor; medya kütüphaneniz büyüdükçe yedekleme ve arama işlemleri yavaşlıyor; veritabanı tabloları da sessizce şişiyor, post revizyonları, spam yorumlar ve süresi dolmuş geçici seçenekler (transient) birikip sorgu sürelerini uzatıyor.
Bu birikim genelde fark edilmiyor, çünkü tek bir güncelleme veya tek bir yeni eklenti anlık olarak büyük bir yavaşlama yaratmıyor; sorun aylar içinde küçük artışların üst üste binmesiyle ortaya çıkıyor. Bu yüzden hızı, düzenli izlenen bir metrik olarak ele almak gerekiyor: bir kerelik proje muamelesi görürse birkaç ay içinde sessizce geri döner. Periyodik hız testi, düzenli veritabanı temizliği ve eklenti veya tema güncellemelerinden sonra performansı yeniden kontrol etmek, sürekli hızlı kalmanın tek yolu; örneğin her üç ayda bir PageSpeed Insights veya benzer bir araçla kısa bir kontrol, birikmiş sorunları büyümeden yakalar.
Önce neyi yapmalısınız: etki ve efor tablosu
Yukarıdaki altı konunun hepsini aynı anda ele almanıza gerek yok. Aşağıdaki tablo, tipik etkilerine ve uygulama zorluğuna göre nereden başlamanız gerektiğini gösteriyor:
| Alan | Tipik etki | Uygulama eforu | Öncelik |
|---|---|---|---|
| Önbellekleme (page + object cache) | Yüksek | Düşük | 1 |
| Görsel optimizasyonu | Yüksek | Orta | 2 |
| Hosting kalitesi | Çok yüksek | Yüksek (genelde taşıma gerekir) | 3 |
| Eklenti ve kod temizliği | Orta | Orta | 4 |
| CDN | Orta (uluslararası trafikte yüksek) | Düşük | 5 |
| Veritabanı temizliği | Orta | Düşük (otomatikleştirilebilir) | Sürekli |
Bu sıralama makul bir başlangıç noktası, bir garanti değil. Sizin sitenizdeki asıl darboğazı bulmak için yine de gerçek bir hız testi aracıyla ölçüm yapmanız gerekiyor, çünkü bu sorunların ağırlık sırası her WordPress kurulumunda aynı görünmeyebilir.
Kaynaklar
- Google, Core Web Vitals eşikleri (web.dev, "Web Vitals" ve "Defining the Core Web Vitals metrics thresholds")
- Google, mobil sayfa hızı araştırması (Think with Google, "Find Out How You Stack Up to New Industry Benchmarks for Mobile Page Speed")
- Portent, "Site Speed is (Still) Impacting Your Conversion Rate" araştırması
Sitenizin sağlığını (hız dahil) tek tek kontrol etmek yerine, Watch Your WP tüm sitelerinizin performans ve sağlık durumunu tek panelden izler, sorun çıkmadan önce fark etmenizi sağlar.
Erdinç
Watch Your WP'yi geliştiriyor. WordPress bakım, güvenlik ve site yönetimi deneyiminden yazıyor.
LinkedIn