WordPress site hızı tek bir eklentiyle değil, katmanlı bir yaklaşımla iyileştirilir. Sıra şudur: önce Core Web Vitals ile ölç (LCP, INP, CLS), sonra sunucu tarafında önbelleği kur, görselleri WebP veya AVIF formatına geçir, render’ı bloklayan CSS ve JavaScript’i ertele, en altta da hosting altyapısını sağlamlaştır.
Yavaşlık WordPress’in kendisinden değil, kurulumun üzerine yıllar içinde yığılan katmanlardan gelir. Doğru yöntem her zaman aynıdır: önce ölç, en yüksek getirili darboğazı çöz, her değişikliği tek tek doğrula. Bu rehber beş katmanın tamamını özetler ve her başlığın uygulama detayını ilgili alt rehbere bağlar.
Siteniz açılırken yaşanan o küçük bekleme anını hepimiz biliriz. Sekme döner, ekran boştur, saniye uzar. Ziyaretçiniz de tam olarak aynı anı yaşıyor. Tek fark, onun sabrının sizinki kadar olmaması.
WordPress site hızı sorunlarının kaynağı çoğu zaman WordPress’in kendisi değildir. Yavaşlık, kurulumun üzerine yıllar içinde biriken katmanlardan gelir: sıkıştırılmamış görseller, hiç kurulmamış bir önbellek, şişkin bir sayfa oluşturucu, geride kalmış bir PHP sürümü, kalabalık bir paylaşımlı sunucu.
İyi haber şu: bu katmanların hepsi somut, ölçülebilir ve doğru sırayla ele alındığında çoğu birkaç saatte çözülebilir.
Bu rehberi WordPress ve SEO tarafında uzun yıllara dayanan deneyimimle, kendi siteme ve müşteri sitelerine uyguladığım gerçek ölçüm verileri üzerinden yazdım. Amacım genel tavsiye sıralamak değil. Hangi katmanın sizi yavaşlattığını bulmanız ve en çok kazandıran müdahaleden başlamanız.
WordPress Site Hızı Neden Önemli?
WordPress site hızı iki ayrı kanaldan getiri sağlar. Birincisi doğrudan ve acımasızdır: yavaş site ziyaretçiyi kaybeder.
Sayfa açılışı birkaç saniyeyi geçtiğinde insanların önemli bir kısmı beklemeden geri döner. E-ticarette bunun karşılığı doğrudan cirodur. Kurumsal bir sitede ise gelmeyen teklif formudur.
İkinci getiri dolaylı ama kalıcı. Google, sayfa deneyimini sıralama sinyalleri arasında sayıyor. İki sayfa içerik olarak birbirine yakınsa, hızlı olan öne geçer. Google’ın bu konudaki resmi tutumunu Search Central dokümantasyonunda okuyabilirsiniz.
Burada atlanan bir nokta var. Hız bir his değil, ölçülebilir bir değerdir. “Sitem yavaş hissettiriyor” cümlesi veri değildir.
Hangi metriğin hangi sayfada ne kadar sorunlu olduğunu bilmeden yapılan optimizasyon, sektörün en yaygın zaman kaybıdır. Önce ölçün.
WordPress Site Hızı: Performansı Belirleyen 5 Katman
WordPress site hızı tek bir üründe değil, üst üste binen katmanlarda yaşar. Aşağıdaki beş katman bir sitenin performansının tamamını oluşturur.
Her katmanın özünü burada veriyorum, derinlemesine uygulama için ilgili rehbere yönlendiriyorum.
1. Doğru Ölçüm: Core Web Vitals
Optimizasyona başlamadan önce mevcut durumu sayıyla kaydetmek şart. Yoksa neyi düzelttiğinizi de bilemezsiniz.
Google’ın kullandığı üç metrik olan LCP (yükleme), INP (yanıt verme) ve CLS (görsel kararlılık), sitenizin gerçek kullanıcılarda nasıl davrandığını söyler. Bu metriklerin resmi tanımlarını ve güncel eşiklerini Google’ın web.dev üzerindeki Web Vitals dokümantasyonundan takip edebilirsiniz.
Kritik ayrım şurada: laboratuvar verisi (Lighthouse) ile alan verisi (CrUX) aynı şey değildir. Bunu bilmeden yapılan ölçüm yanıltır.
Üç metriğin ne anlama geldiğini, nasıl ölçüleceğini ve iki veri tipinin farkını Core Web Vitals nedir rehberinde ayrıntılı ele aldım.
2. Önbellekleme
Önbellek yoksa her ziyaretçi için PHP çalışır, veritabanı sorgulanır, sayfa sıfırdan üretilir. Her seferinde.
Sayfa önbelleği bu döngüyü ortadan kaldırır ve tek başına sunucu yanıt süresini genellikle üçte birine indirir. WordPress site hızı çalışmalarında en hızlı geri dönen müdahale budur.
Ama eklenti seçimi sunucunuza bağlıdır. Ve aynı anda iki önbellek eklentisi kullanmak siteyi bozar, hızlandırmaz.
Hangi eklentinin hangi sunucuya uygun olduğunu WordPress önbellek eklentileri karşılaştırmasında yan yana koydum.
3. Görsel Optimizasyonu
Görseller çoğu WordPress sitesinde toplam sayfa ağırlığının yarısından fazlasını oluşturur. LCP öğesi de neredeyse her zaman bir görseldir.
Yani en yüksek getirili alan burası. Modern formatlar (WebP, AVIF), doğru lazy loading, LCP görselinin önceliklendirilmesi ve boyut rezervasyonuyla CLS önleme.
Hepsini adım adım görsel optimizasyonu rehberinde anlattım.
4. Render’ı Bloklayan Kaynaklar
Tarayıcı sayfayı çizmeye başlamadan önce bazı dosyaları beklemek zorundadır. Senkron yüklenen her CSS ve JavaScript dosyası bu beklemeyi uzatır.
Bu katmanın işi net: ilk ekranda görünen kısmın CSS’ini satır içine almak, geri kalanını ertelemek, JavaScript’i defer ile geciktirmek ve web fontlarını font-display: swap ile çağırmak.
Bir de kimsenin konuşmadığı bir kayıp var: koşullu yükleme. İletişim sayfasındaki form eklentisi, ana sayfaya da kendi CSS ve JavaScript dosyalarını basar. Slider eklentisi, slider olmayan sayfalara yüklenir. Bunları sayfa bazında kapatmak çoğu sitede yüzlerce kilobayt kazandırır.
Uyarı niteliğinde bir not. İyi önbellek eklentileri bu işlerin bir kısmını otomatik yapar ama “tümünü birleştir ve küçült” tarzı toplu anahtarlar sıklıkla menüyü, sliderı ya da sepeti bozar.
Doğru yöntem, ayarları teker teker açıp her birinden sonra siteyi gezmektir. Bir şey bozulduğunda hangi ayardan kaynaklandığını böyle bilirsiniz. Toplu açıp sonra sorunu aramak, WordPress sorun giderme sürecini gereksiz yere uzatır.
5. Sunucu ve Hosting Altyapısı
Ön uç optimizasyonu, sunucunun bıraktığı yerden başlar. Sunucu ilk baytı geç gönderiyorsa hiçbir ön uç müdahalesi sizi kurtarmaz.
TTFB değeriniz 600 milisaniyenin üzerindeyse sorun büyük ihtimalle burada. Bakılacak yerler sırayla şunlar:
- PHP sürümü: Güncel sürümler eski sürümlere göre belirgin şekilde hızlıdır ve geçiş çoğu zaman tek tıktır.
- OPcache: PHP kodunu derlenmiş halde tutar, kapalıysa her istekte aynı iş tekrarlanır.
- Nesne önbelleği: Redis veya Memcached, veritabanı sorgularını hafızada tutar. WooCommerce ve üyelikli sitelerde farkı en net hissedilen ayardır.
- Depolama: NVMe diskler, klasik SSD’ye göre veritabanı yoğun sitelerde ciddi fark üretir.
- Sunucu konumu: Ziyaretçiniz Türkiye’deyse sunucunun Türkiye ya da Avrupa’da olması, ABD’deki bir sunucuya göre gidiş dönüş süresini kısaltır.
Paylaşımlı hostingin kendisi baştan kötü değildir. Sorun, aynı fiziksel sunucuda yüzlerce sitenin aynı kaynağı paylaşmasıdır. Komşu sitelerden biri kaynağı tükettiğinde sizin siteniz yavaşlar ve elinizde yapabilecek bir şey kalmaz.
Bu noktaya geldiyseniz eklenti ayarlarıyla uğraşmayı bırakıp altyapıyı konuşmanın zamanı gelmiştir. Hosting değiştirme rehberinde geçişin ne zaman gerektiğini ve süreçte neyin kaybedilebileceğini anlattım.
Hangi Katmandan Başlamalısınız?
Beş katmanı aynı anda ele almak gerekmiyor. Çoğu sitede kazancın büyük kısmı ilk üç satırdan gelir.
| Katman | Tipik kazanç | Zorluk | Kendiniz yapabilir misiniz? |
|---|---|---|---|
| Görsel optimizasyonu | Yüksek | Düşük | Evet |
| Önbellekleme | Yüksek | Orta | Genellikle |
| PHP sürümü ve OPcache | Orta | Düşük | Evet |
| Render bloklayan kaynaklar | Orta | Yüksek | Kısmen |
| Sunucu ve altyapı değişimi | Yüksek | Yüksek | Hayır |
Sıralamayı ezberlemek yerine ölçümünüze bakın. Raporunuzda en büyük kalem hangisiyse iş oradan başlar.
E-Ticaret Siteleri İçin Hız
WooCommerce mağazalarında WordPress site hızı, standart bir kurumsal siteye göre yapısal olarak daha zordur. Bunun teknik sebepleri var.
Sepet, ödeme ve hesabım sayfaları kişiye özel veri taşıdığı için tam sayfa önbelleğe alınamaz. Cart fragments her sayfada sepeti yeniden sorgular. Ürün filtreleri veritabanında ağır JOIN’ler üretir.
Bu yüzden mağazalarda her sayfa tipini ayrı ele almak gerekir: kategori, ürün, sepet ve ödeme sayfaları farklı stratejiler ister.
Somut yol haritasını WooCommerce hız optimizasyonu rehberinde ele aldım. Mağazanızı sıfırdan kuruyorsanız e-ticaret sitesi tasarımı tarafındaki yaklaşımıma da göz atabilirsiniz.
Kendiniz mi Yapmalısınız, Profesyonel Destek mi?
Dürüst cevap: temel işlerin çoğunu kendiniz yapabilirsiniz. Görselleri sıkıştırmak, bir önbellek eklentisi kurmak, PHP sürümünü güncellemek teknik bilgiyle çözülebilecek adımlar.
Ayrım şurada başlıyor. PageSpeed raporundaki otuz maddenin belki dördü sizin sitenizde gerçekten fark yaratır. Gerisi zaman kaybıdır ve hangisinin hangisi olduğunu ölçüm söyler.
Render’ı bloklayan kaynakları tek tek çözmek, sunucu tarafı sıkılaştırma yapmak ve bir düzeltmenin kaç milisaniye kazandıracağını önceden kestirmek deneyim işidir.
Karar verirken sitenizin rolüne bakın. Ticari gelir üreten, kesintinin doğrudan maliyet olduğu bir sitede WordPress site hızı çalışmasını profesyonel ölçümle yürütmek en güvenli yol.
Sıkça Sorulan Sorular
WordPress sitemi en hızlı nasıl hızlandırırım?
En yüksek getirili üç adım şu: görselleri WebP formatına çevirip sıkıştırın, sunucu tipinize uygun tek bir önbellek eklentisi kurun, render’ı bloklayan CSS ve JavaScript’i erteleyin.
Bu üçü çoğu sitede skoru belirgin şekilde yükseltir. Ama sıralama her sitede değişir. Önce ölçüp en büyük darboğazınızı bulmak, körlemesine uygulamaktan her zaman daha verimli.
PageSpeed skorum kaç olmalı?
Skoru hedef değil, tanı aracı olarak kullanın. Google sıralamada PageSpeed skorunu değil, alan verisindeki Core Web Vitals eşiklerini kullanıyor.
90 puanla üç metriği de yeşil olan bir site, 100 puanla sahada yanıt süresinden kalan bir siteden daha iyi durumdadır. Ölçümü PageSpeed Insights üzerinden yapın ve aynı sayfayı farklı saatlerde birkaç kez test edin.
Hangi önbellek eklentisi en iyisi?
Sunucunuza bağlı. LiteSpeed sunucudaysanız LiteSpeed Cache ücretsiz ve rakipsiz, çünkü önbellek sunucu seviyesinde çalışıyor. Apache veya Nginx kullanıyorsanız ve bütçe varsa WP Rocket varsayılan ayarlarıyla bile işi görür.
Değişmeyen kural: aynı anda yalnızca bir önbellek eklentisi. Karşılaştırmanın detayını önbellek eklentileri rehberinde bulabilirsiniz.
WordPress site hızı SEO’yu gerçekten etkiler mi?
Evet, ama tek başına belirleyici değil. Hız, sayfa deneyimi sinyallerinin bir parçası ve içerik kalitesi, alaka ile otoriteden sonra geliyor.
Etkisi en çok rekabetin dengeli olduğu aramalarda görülür. Ayrıca dolaylı etkisi doğrudan etkisinden büyüktür: yavaş sayfada çıkma oranı artar, dönüşüm düşer, bu davranış sinyalleri zamanla sıralamaya yansır.
Search Console’da “veri yetersiz” yazıyor, sitem yavaş mı?
Hayır. Bu mesaj, Chrome kullanıcı trafiğinizin CrUX’un anonimlik eşiğini geçmediği anlamına gelir. Performansla ilgisi yok.
Düşük ve orta trafikli sitelerin çoğunda normaldir. Bu durumda Lighthouse ölçümlerini sabit koşullarda düzenli tekrarlayın. web.dev’in Core Web Vitals kaynağı alan verisi toplamak için kullanabileceğiniz yöntemleri de listeliyor.
Eklenti sayısı siteyi yavaşlatır mı?
Sayı tek başına ölçüt değil. Sorun eklentinin varlığı değil, her eklentinin her sayfaya enjekte ettiği CSS ve JavaScript dosyaları.
Sadece iletişim sayfasında kullanılan bir form eklentisi ana sayfaya da kod yükleyebilir. Belirleyici olan eklentilerin ne yaptığı ve nerede çalıştığı. Koşullu yüklemeyle gereksiz yükün çoğu kaldırılabilir.
Sunucum yurt dışında, taşımam gerekir mi?
Ziyaretçilerinizin büyük kısmı Türkiye’deyse mesafe her istekte size gecikme olarak geri döner. Bir CDN statik dosyalarda bunu telafi eder ama ilk bayt süresini değiştirmez.
TTFB değeriniz yüksekse ve önbellek düzgün çalışıyorsa, sunucu konumu ciddi bir aday demektir.
Bu yazıları da okumak isteyebilirsiniz ...
Yazar Hakkında
2014'ten bu yana web tasarım, WordPress ve SEO & AI görünürlük alanlarında 550'den fazla işletmeye hizmet veriyorum.