WordPress Site Hızlandırma Rehberi: Ölçümden Uygulamaya
- Yayınlandı:
- Son teknik kontrol:
Hız ve Performans
Kısa cevap
WordPress hızlandırma bir eklenti kurmakla değil, ölçmekle başlar. Önce gerçek kullanıcı verisine (Core Web Vitals) ve sunucu yanıt süresine bakılır; sorun sunucu tarafındaysa hosting, PHP sürümü ve önbellek; tarayıcı tarafındaysa görseller, JavaScript ve üçüncü taraf kodlar ele alınır. Her değişiklik tek tek uygulanır ve aynı koşullarda yeniden ölçülür. Sırayı etkisi en büyük ve riski en düşük adımdan başlatmak, hem zamanı hem sitenin bozulma riskini azaltır.
Önemli noktalar
- Laboratuvar skoru (PageSpeed) ile gerçek kullanıcı verisi (alan verisi) farklı şeyleri ölçer; karar alan verisiyle verilir.
- Sunucu yanıtı yavaşsa tarayıcı tarafındaki optimizasyonlar sorunu çözmez, yalnızca maskeler.
- Sayfa önbelleği çoğu sitede en büyük tek kazançtır; oturum açık ve sepet sayfaları hariç tutulmalıdır.
- Görseller genellikle en büyük bayt yüküdür: doğru boyut, modern biçim ve tembel yükleme.
- JavaScript’i geciktiren “optimizasyon” ayarları siteyi bozabilir; her ayar tek tek ve kopya ortamda denenmeli.
Adım 0: Önce doğru ölçün
Hızlandırmanın en sık yapılan hatası, ölçmeden ayar değiştirmektir. İki tür veri vardır ve ikisi farklı soruları cevaplar. Hangi metriklerin önemli olduğunu Core Web Vitals nedir rehberinde ayrıntılı anlattık.
| Veri türü | Nereden | Ne söyler |
|---|---|---|
| Alan verisi (gerçek kullanıcı) | PageSpeed Insights’ın üst bölümü, Search Console Core Web Vitals raporu | Ziyaretçilerinizin gerçekte yaşadığı hız — Google’ın değerlendirdiği veri |
| Laboratuvar verisi | Lighthouse, PageSpeed skoru, tarayıcı geliştirici araçları | Sabit koşullarda tek bir yükleme — nedenleri bulmak ve değişikliği karşılaştırmak için |
Temsil eden sayfaları seçin
Ana sayfa tek başına yetmez: en çok trafik alan içerik sayfası, bir kategori sayfası ve e-ticaretse ürün ve ödeme sayfası.
Başlangıç ölçümünü kaydedin
Her sayfa için mobil ve masaüstü değerleri, aynı araçla ve not ederek alın. Karşılaştırmanın temeli budur.
Darboğazı belirleyin
Sunucunun ilk baytı geç veriyorsa (yüksek TTFB) sorun sunucudadır; ilk bayt hızlı ama sayfa geç çiziliyorsa sorun tarayıcı tarafındadır.
Adım 1: Sunucu yanıt süresi
Tarayıcı ilk baytı alana kadar hiçbir şey çizemez. Sunucu yavaşsa görsel sıkıştırmak veya JavaScript ertelemek sonucu değiştirmez. Nedenlerin ayrıntısı WordPress sitesi neden yavaşlar rehberinde; burada yapılacaklar:
- PHP sürümü — desteklenen güncel bir sürüm kullanın (WordPress.org PHP 8.3+ öneriyor). Eski PHP sürümleri hem yavaş hem güvenlik desteğinden yoksundur. Yükseltmeden önce tema ve eklenti uyumunu kopya ortamda deneyin.
- Hosting kaynakları — paylaşımlı pakette başka sitelerin yükü sizi etkileyebilir. Sorun sürekli ve ölçülebilir biçimde sunucudaysa paket veya sağlayıcı değişikliği gündeme gelir.
- Nesne önbelleği — yoğun veritabanı sorgusu yapan sitelerde (üyelik, e-ticaret, çok eklentili siteler) Redis gibi kalıcı bir nesne önbelleği sorgu yükünü azaltır.
- Ağır eklentiler — her sayfada çalışan ve sorgu üreten eklentiler sunucu süresini doğrudan uzatır. Etkin eklentileri tek tek devre dışı bırakıp süreyi ölçmek suçluyu gösterir.
Hosting’in gerçekten yeterli olup olmadığını değerlendirmek için hosting seçim rehberine bakabilirsiniz.
Adım 2: Sayfa önbelleği
Sayfa önbelleği, her ziyaret için PHP’nin çalışıp veritabanını sorgulaması yerine önceden üretilmiş HTML’in gönderilmesidir. Çoğu içerik sitesinde en büyük tek kazançtır. Katmanları ve doğru kurulum sırasını WordPress önbellek nedir rehberinde anlattık.
Birden fazla önbellek eklentisini aynı anda kullanmayın; aynı işi yapan iki katman birbirinin ayarlarını bozar ve sorunları izlemeyi imkânsız hâle getirir. Hosting sunucu düzeyinde önbellek sunuyorsa (ör. LiteSpeed veya Nginx tabanlı), eklenti seçimini buna göre yapın.
Adım 3: Görseller
Görseller çoğu sayfada en büyük bayt yüküdür ve Largest Contentful Paint (LCP) öğesi sıklıkla bir görseldir. Etkisi yüksek, riski düşük bir alandır:
- Görseli gösterileceği boyuttan çok daha büyük yüklemeyin; 4000 piksellik bir fotoğrafı 800 piksellik alanda göstermek boşa bayt taşır.
- WebP veya AVIF gibi modern biçimler aynı görsel kalitede daha küçük dosya üretir.
- Ekranın altındaki görselleri tembel yükleyin (WordPress bunu varsayılan olarak yapar), ama sayfanın ilk görünen büyük görselini tembel yüklemeyin — LCP’yi geciktirir.
- Görsellerin genişlik ve yükseklik öznitelikleri olmalı; yoksa görsel yüklendiğinde sayfa kayar (CLS).
Adım 4: JavaScript, CSS ve yazı tipleri
Tarayıcının ana iş parçacığını meşgul eden JavaScript, hem sayfanın geç çizilmesine hem de tıklamalara geç tepki verilmesine (INP) yol açar. Kaynakları genellikle sayfa oluşturucular, slider’lar, sosyal paylaşım ve sohbet araçlarıdır.
Kullanılmayanı kaldırın
En etkili optimizasyon, kodu hiç yüklememektir. Kullanılmayan eklentileri silin; yalnızca belirli sayfada gereken bir eklentinin betiklerini diğer sayfalarda yüklemeyin.
Erteleyin, ama test ederek
Betikleri ertelemek (defer) veya kullanıcı etkileşimine kadar geciktirmek (delay) çoğu zaman kazanç sağlar; ancak menü, form veya ödeme gibi işlevleri bozabilir. Her ayarı tek tek açıp kritik akışları deneyin.
CSS’i sadeleştirin
Birçok tema ve oluşturucu her sayfada kullanılmayan büyük CSS dosyaları yükler. Kullanılmayan CSS’i kaldırma ayarları da işlev bozabilir; görsel kontrol şart.
Yazı tiplerini yerel ve sınırlı tutun
Kullanmadığınız yazı tipi ağırlıklarını yüklemeyin. Yazı tiplerini kendi sunucunuzdan sunmak ek bir bağlantı kurulumunu ortadan kaldırır.
Adım 5: Üçüncü taraf kodlar ve CDN
Analitik, reklam, sohbet, harita ve video yerleştirmeleri sizin kontrolünüzde olmayan sunuculardan kod yükler. Her birinin gerçekten gerekli olup olmadığını sorgulayın; gerekenleri mümkünse etkileşimle yükleyin (ör. videoyu tıklanınca yüklenen bir önizlemeyle değiştirmek). Ziyaretçileriniz coğrafi olarak dağınıksa bir CDN statik dosyaları ziyaretçiye yakın sunuculardan dağıtır.
Adım 6: Doğrulayın
Her değişiklikten sonra başlangıçtaki sayfaları aynı araçla yeniden ölçün ve kritik akışları (form gönderimi, sepete ekleme, ödeme, giriş) elle deneyin. Laboratuvar ölçümü değişikliği hemen gösterir; alan verisi ise son 28 günlük gerçek kullanıcı verisinden hesaplandığı için iyileşmenin raporlara yansıması birkaç hafta sürer.
| Alan | Tipik etki | Bozma riski |
|---|---|---|
| Sunucu / PHP / hosting | Yüksek (TTFB yüksekse) | Orta — uyumluluk testi gerekir |
| Sayfa önbelleği | Yüksek | Düşük–orta — hariç tutmalar doğru olmalı |
| Görseller | Yüksek | Düşük |
| Gereksiz eklenti/kod kaldırma | Orta–yüksek | Düşük |
| JS erteleme/geciktirme | Orta | Yüksek — işlev bozabilir |
| Kullanılmayan CSS kaldırma | Orta | Yüksek — görünüm bozabilir |
Ölçerek hızlandıralım
Sitenizin darboğazını ölçüp değişiklikleri tek tek, işlevleri bozmadan uygulayalım.
WordPress Hız OptimizasyonuSık sorulan sorular
Tek bir hızlandırma eklentisi yeterli mi?
PageSpeed skorum düşük ama site hızlı açılıyor, sorun var mı?
Hızlandırma çalışması sitemi bozar mı?
İyileştirmeler Google’a ne zaman yansır?
Kaynaklar ve teknik referanslar
Bu içeriği hazırlayan
WPHizmet EkibiWordPress teknik ekibi
WPHizmet içeriklerini hazırlayan teknik ekip. Rehberler, WordPress ve WooCommerce sitelerinde günlük olarak karşılaşılan sorunlara dayanır; sürüm, yapılandırma ve gereksinim bilgileri yayın öncesinde resmi dokümantasyondan doğrulanır.
- WordPress teknik destek
- Performans ve Core Web Vitals
- Güvenlik ve zararlı kod temizliği
- WooCommerce
- Teknik SEO
İlgili içerikler
- RehberPageSpeed Insights Skoru Nasıl Artırılır? (WordPress)
- RehberWordPress Veritabanı Temizleme ve Optimizasyonu (wp_options, Revizyon, Transient)
- RehberLiteSpeed Cache Ayarları: WordPress İçin Önerilen Yapılandırma
- RehberCloudflare WordPress Kurulumu ve Doğru Ayarlar
- SözlükSayfa Önbelleği
- SözlükNesne Önbelleği
- SözlükCDN
- HizmetWordPress Hızlandırma
- HizmetWordPress Bakım