WordPress Hızlandırma Rehberi: Core Web Vitals İçin 15 Adım

Okuma süresi: 18 dk

Yavaş bir WordPress sitesi hem ziyaretçi hem de arama motoru açısından maliyetlidir: Kullanıcılar bekledikçe sayfayı terk eder, e-ticaret sitelerinde sepetler yarım kalır ve Google’ın sayfa deneyimi sinyallerinden olan Core Web Vitals olumsuz etkilenir. İyi haber şu ki WordPress’in yavaşlığının nedenleri büyük ölçüde bilinir ve ölçülebilir. Bu rehberde, “hız eklentisi kurup bekleme” yaklaşımı yerine, her adımın neyi neden düzelttiğini açıklayan sistematik bir yöntem izliyoruz. Adımların çoğu ücretsizdir ve birkaç saat içinde uygulanabilir.

Önce ölçün: hangi metrikler önemli?

Ölçmeden yapılan optimizasyon, çoğu zaman yanlış soruna zaman harcamak demektir. Başlamadan önce şu metrikleri tanıyın:

INP, 12 Mart 2024’te FID’in (First Input Delay) yerine Core Web Vitals metriği oldu. TTFB bir Core Web Vitals metriği değildir; ancak LCP’nin ilk bileşeni olduğu için sunucu performansının en net göstergesidir. Google, bir sayfanın “iyi” kabul edilmesi için bu eşiklerin ziyaretlerin 75. yüzdelik diliminde sağlanmasını ölçüt alır.

Laboratuvar verisi ve saha verisi

• Saha verisi (field data): Gerçek Chrome kullanıcılarından toplanan veridir (CrUX). PageSpeed Insights’ın üst bölümünde ve Search Console’daki Core Web Vitals raporunda görünür. Sıralama sinyalinde kullanılan budur.
• Laboratuvar verisi (lab data): Lighthouse’un tek bir simüle cihazda yaptığı testtir. Sorunları teşhis etmek için idealdir ama tek başına gerçek kullanıcı deneyimini yansıtmaz.

Az trafikli sitelerde saha verisi bulunmayabilir; bu durumda laboratuvar testlerini mobil profil ile, birkaç kez tekrarlayarak kullanın. Ölçüm yaparken giriş yapmış yönetici oturumunu kullanmayın; önbellek çoğu zaman yöneticilere devre dışıdır.

TTFB’yi komut satırından ölçmek

PageSpeed Insights dışında, sunucu yanıt süresini kendi bilgisayarınızdan da hızlıca ölçebilirsiniz. Aşağıdaki komut DNS çözümleme, bağlantı, TLS el sıkışması ve ilk bayt sürelerini ayrı ayrı gösterir:

curl -o /dev/null -s -w "dns:%{time_namelookup} baglanti:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} toplam:%{time_total}\n" https://www.ornek.com/

Komutu birkaç kez çalıştırın. İlk istekte önbellek henüz oluşmamış olabilir; sonraki isteklerde TTFB belirgin biçimde düşmüyorsa sayfa önbelleği çalışmıyor demektir. Yanıt başlıklarını curl -I ile inceleyerek önbelleğin “HIT” mi “MISS” mi döndüğünü de görebilirsiniz (başlık adı kullandığınız önbellek çözümüne göre değişir; LiteSpeed’de x-litespeed-cache).

Neyin yavaş olduğunu bulmak

LCP değeri kötüyse, PageSpeed Insights raporundaki “LCP öğesi” bölümü hangi öğenin LCP olduğunu ve sürenin hangi alt bölümlerden (TTFB, kaynak yükleme gecikmesi, kaynak yükleme süresi, öğe oluşturma gecikmesi) oluştuğunu gösterir. Bu dağılım, sorunun sunucuda mı, görselin geç keşfedilmesinde mi yoksa görselin büyüklüğünde mi olduğunu söyler. INP için ise Search Console’daki rapor hangi URL gruplarının etkilendiğini, Chrome Geliştirici Araçları’nın Performance paneli ise hangi etkileşimin hangi betik nedeniyle yavaş kaldığını gösterir.

Belirtiye göre nereden başlamalı?

Ölçüm sonucu, sorunun hangi katmanda olduğunu gösterir. Aşağıdaki tabloyu PageSpeed Insights raporunuzla yan yana okuyun ve yalnız sizin belirtinize uyan satırdan başlayın.

Her kontrolden sonra tek bir değişiklik yapıp yeniden ölçün. Aynı anda birkaç ayarı değiştirirseniz hangisinin işe yaradığını göremezsiniz.

1. Hosting: hızın temeli

Hiçbir eklenti, yavaş bir sunucuyu hızlı yapamaz (hosting türlerinin farkları için hosting nedir rehberimize bakabilirsiniz). TTFB önbellekli sayfalarda bile düzenli olarak 0,8 saniyenin üzerindeyse, sorun büyük olasılıkla sunucu tarafındadır. Hosting’den beklenmesi gerekenler:

• NVMe SSD diskler ve güncel nesil işlemciler.
• LiteSpeed veya Nginx gibi yüksek performanslı web sunucusu.
• Güncel PHP sürümleri ve OPcache.
• Yeterli kaynak limitleri (CPU, RAM, eş zamanlı süreç).
• Hedef kitlenize yakın veri merkezi.

Ziyaretçilerinizin çoğu Türkiye’deyse, sunucunun Türkiye’de olması ağ gecikmesini azaltır. WordPress için optimize edilmiş paketlerimizi WordPress hosting sayfasında bulabilirsiniz.

2. PHP sürümünü güncelleyin

Her yeni PHP sürümü performans ve güvenlik iyileştirmeleri getirir. Desteği sona ermiş bir PHP sürümü güvenlik güncellemesi almaz. WordPress.org, PHP 8.3 veya daha yeni bir sürüm kullanılmasını öneriyor. Her sürümün güvenlik desteğinin ne zaman biteceğini php.net’teki desteklenen sürümler sayfasından izleyin.

Sürüm yükseltmeden önce bir hazırlık (staging) kopyasında tema ve eklentilerinizin uyumunu test edin. WordPress.org’un “Gereksinimler” sayfası önerilen güncel PHP sürümünü listeler.

3. OPcache’in açık olduğundan emin olun

OPcache, PHP betiklerinin derlenmiş hâlini bellekte tutarak her istekte yeniden derlenmesini önler. Çoğu kaliteli hosting’de varsayılan olarak açıktır; Araçlar › Site Sağlığı › Bilgi ekranından veya phpinfo() çıktısından kontrol edebilirsiniz.

4. Sayfa önbelleği (page cache) kullanın

WordPress her sayfa isteğinde PHP çalıştırır ve veritabanına onlarca sorgu gönderir. Sayfa önbelleği, oluşturulan HTML’i saklayarak sonraki ziyaretçilere doğrudan sunar; TTFB’yi genellikle en çok iyileştiren adım budur.

• LiteSpeed sunucularda: LiteSpeed Cache (LSCache) eklentisi, sunucu düzeyindeki önbellekle entegre çalışır ve genellikle en verimli seçenektir.
• Nginx/Apache sunucularda: Sunucu düzeyinde önbellek (ör. FastCGI cache) veya WP Rocket, W3 Total Cache, WP Super Cache gibi eklentiler kullanılabilir.

Yalnızca bir önbellek eklentisi kullanın. Birden fazla önbellek eklentisi çakışmalara ve beklenmedik hatalara neden olur. Sepet, ödeme ve hesap sayfaları önbellekten hariç tutulmalıdır (WooCommerce ve popüler önbellek eklentileri bunu çoğunlukla otomatik yapar).

5. Nesne önbelleği: Redis veya Memcached

Sayfa önbelleği giriş yapmamış ziyaretçiler için çalışır. Üyelik siteleri, WooCommerce sepetleri ve yönetim paneli gibi önbelleklenemeyen sayfalarda ise veritabanı yükünü azaltmak için kalıcı nesne önbelleği kullanılır. Redis veya Memcached, sık kullanılan sorgu sonuçlarını bellekte tutar. WordPress’in Site Sağlığı ekranı, uygun durumlarda kalıcı nesne önbelleği kullanmanızı önerir. Hosting paketinizde Redis desteği olup olmadığını kontrol edin.

6. Görselleri optimize edin

Görseller, çoğu sayfada en büyük yük kalemidir ve genellikle LCP öğesidir.

Modern formatlar: WebP ve AVIF

WordPress, 5.8 sürümünden itibaren WebP, 6.5 sürümünden (Nisan 2024) itibaren AVIF görsel yüklemeyi destekler (sunucudaki görüntü işleme kütüphanesinin bu formatları desteklemesi gerekir). WebP ve AVIF, aynı görsel kalitede JPEG ve PNG’ye göre genellikle daha küçük dosyalar üretir.

Doğru boyut

3000 piksel genişliğinde bir fotoğrafı 800 piksellik bir alanda göstermek, gereksiz veri indirmek demektir. WordPress, yüklenen görsellerin farklı boyutlarını otomatik oluşturur ve srcset özelliğiyle tarayıcının uygun boyutu seçmesini sağlar. Görselleri yüklemeden önce makul bir maksimum genişliğe küçültün.

Boyut özniteliklerini belirtin

width ve height öznitelikleri tanımlanmamış görseller, yüklenince sayfanın kaymasına (CLS) neden olur. WordPress, editörden eklenen görsellere bu öznitelikleri otomatik ekler; tema veya sayfa oluşturucu ile eklenen görselleri kontrol edin.

7. LCP görseline öncelik verin, diğerlerini geciktirin

• Lazy-load: WordPress 5.5’ten itibaren görsellere yerel loading="lazy" özniteliğini ekler; ekran dışındaki görseller ancak kullanıcı yaklaştığında yüklenir.
• LCP görseli lazy-load edilmemelidir. Sayfanın üst bölümündeki ana görsel geç yüklenirse LCP kötüleşir. WordPress 6.3, ilk görsel için lazy-load’u atlama ve fetchpriority="high" ekleme mantığını çekirdeğe ekledi; ancak bazı temalar ve sayfa oluşturucular bunu bozabilir.
• Arka plan görseli olarak CSS ile yüklenen bir hero görsel, tarayıcı tarafından geç keşfedilir. Mümkünse <img> etiketi kullanın veya önceden yükleme (preload) tanımlayın.

Video ve harici gömmeler

YouTube videoları, haritalar ve sosyal medya gömmeleri, sayfaya büyük miktarda üçüncü taraf JavaScript ekler. Sayfanın üst bölümünde olmayan gömmeler için loading="lazy" kullanılan iframe’ler veya “tıklayınca yükle” (facade) yaklaşımı tercih edin: Önce yalnızca bir önizleme görseli gösterilir, gerçek oynatıcı kullanıcı tıkladığında yüklenir. Bu yöntem hem LCP’yi hem de INP’yi iyileştirir.

Spekülatif yükleme

WordPress 6.8 (Nisan 2025), Speculation Rules API desteğini çekirdeğe ekledi. Destekleyen tarayıcılarda bu özellik, kullanıcının tıklama olasılığı yüksek bağlantıları önceden getirerek sayfa geçişlerini hızlandırır. Varsayılan ayar ölçülüdür; ek yapılandırma gerektirmez ve oturum açmış kullanıcılarda veya bazı özel durumlarda devre dışı kalır. Önbellek eklentinizin benzer bir “önceden yükleme” özelliği varsa çakışma olmadığını kontrol edin.

8. Fontları optimize edin

• Kullanmadığınız font ağırlıklarını ve stillerini kaldırın; çoğu site için 2–3 ağırlık yeterlidir.
• Fontları kendi sunucunuzda barındırın (harici font sunucusuna ek bağlantı gerekmez; ayrıca ziyaretçi verisinin üçüncü taraflara aktarılması konusundaki KVKK/GDPR değerlendirmelerini kolaylaştırır).
• WOFF2 formatını kullanın.
• font-display: swap ile metnin font yüklenmeden görünmesini sağlayın; CLS’yi önlemek için yedek fontun boyutlarını yakın tutun.

9. CSS ve JavaScript’i hafifletin

INP sorunlarının en yaygın nedeni, ana iş parçacığını meşgul eden ağır JavaScript’tir.

• Kullanılmayan eklentilerin betiklerini kaldırın; bir eklentinin betiği yalnızca kullanıldığı sayfalarda yüklenmelidir.
• Kritik olmayan JavaScript’i defer ile geciktirin.
• Sohbet balonları, ısı haritaları ve reklam etiketleri gibi üçüncü taraf betikleri sorgulayın; her biri ana iş parçacığına yük bindirir.
• Birleştirme (concatenation) HTTP/2 ve HTTP/3 ile eskisi kadar kritik değildir; küçültme (minify) ise hâlâ faydalıdır.
• Kritik CSS’yi satır içi verip geri kalanını erteleme özelliğini dikkatle kullanın; yanlış yapılandırıldığında CLS’ye yol açabilir.

Chrome Geliştirici Araçları’ndaki Performance panelinde “Long tasks” (50 ms’den uzun görevler) INP sorunlarının kaynağını gösterir.

10. Eklentileri denetleyin

Sorun eklenti sayısı değil, eklentilerin ne yaptığıdır. Tek bir kötü yazılmış eklenti, iyi yazılmış yirmi eklentiden daha fazla yavaşlatabilir.

• Kullanmadığınız eklentileri devre dışı bırakmakla kalmayın, silin.
• Aynı işi yapan birden fazla eklenti varsa birini seçin.
• Query Monitor eklentisi, hangi eklentinin kaç veritabanı sorgusu çalıştırdığını ve ne kadar süre harcadığını gösterir.
• Sayfa oluşturucu (page builder) seçiminiz, ön yüzün ağırlığını büyük ölçüde belirler.

11. Veritabanını temizleyin

Zamanla WordPress veritabanında gereksiz veriler birikir:

• Yazı revizyonları: wp-config.php dosyasına define( 'WP_POST_REVISIONS', 10 ); ekleyerek yazı başına tutulan revizyon sayısını sınırlayabilirsiniz.
• Süresi dolmuş geçici veriler (transients), spam ve çöp yorumlar.
• Otomatik yüklenen (autoload) seçenekler: Kaldırılmış eklentilerin bıraktığı ve her sayfa isteğinde yüklenen veriler. WordPress 6.6, büyük autoload seçenekleri için iyileştirmeler ve Site Sağlığı uyarısı getirdi.

Veritabanı işlemlerinden önce mutlaka yedek alın.

12. WP-Cron’u gerçek cron’a taşıyın

WordPress’in zamanlanmış görevleri (WP-Cron) varsayılan olarak ziyaretçi isteklerinde tetiklenir. Yoğun sitelerde bu gereksiz yük, az trafikli sitelerde ise görevlerin gecikmesi demektir. Daha sağlıklı yaklaşım:

1. wp-config.php dosyasına define( 'DISABLE_WP_CRON', true ); ekleyin.
2. Kontrol panelinizdeki cron görevleri bölümünden, wp-cron.php dosyasını örneğin 5–15 dakikada bir çağıran bir sistem cron’u tanımlayın.

13. Heartbeat API’yi sınırlayın

Heartbeat API, yönetim panelinde otomatik kaydetme ve oturum kontrolü için düzenli aralıklarla admin-ajax.php’ye istek gönderir. Birden fazla yöneticinin aynı anda açık sekmesi olduğunda paylaşımlı hosting kaynaklarını zorlayabilir. Bazı önbellek ve performans eklentileri Heartbeat sıklığını azaltma seçeneği sunar; tamamen kapatmak otomatik kaydetme gibi özellikleri etkileyebilir.

14. CDN kullanın

İçerik dağıtım ağı (CDN), statik dosyaları ziyaretçiye en yakın noktadan sunar. Ziyaretçileriniz farklı ülkelerdeyse belirgin fayda sağlar; tamamen Türkiye’ye yönelik bir sitede, sunucu zaten Türkiye’deyse kazanç daha sınırlı olabilir, ancak DDoS koruması ve bant genişliği tasarrufu gibi ek faydaları vardır.

15. WooCommerce’e özel optimizasyonlar

WooCommerce siteleri, önbelleklenemeyen sayfaları (sepet, ödeme, hesabım) nedeniyle sunucu kaynağına daha çok ihtiyaç duyar.

• WooCommerce’in HPOS (Yüksek Performanslı Sipariş Depolama) özelliğini etkinleştirin; siparişleri yazı tablolarından ayrı, optimize tablolarda saklar (8.2 sürümünden itibaren yeni kurulumlarda varsayılandır).
• Sepet parçacıkları (cart fragments) isteğinin hangi sayfalarda çalıştığını kontrol edin.
• Ürün filtreleme ve arama eklentilerinin sorgu yükünü Query Monitor ile ölçün.
• Kampanya dönemlerinden önce kaynak kullanımını izleyin ve gerekirse paket yükseltin.

Yüksek trafikli mağazalar için izole kaynaklı paketlerimiz e-ticaret hosting sayfasında yer alıyor; paylaşımlı ortamın sınırına ulaştıysanız VPS sunucu seçeneklerini değerlendirebilirsiniz; VPS ile VDS arasında kararsızsanız VPS ve VDS farkı yazımıza göz atın.

Sıkıştırma ve tarayıcı önbelleği

HTML, CSS ve JavaScript gibi metin dosyaları sıkıştırılarak gönderildiğinde aktarılan veri belirgin biçimde azalır. Yaygın iki yöntem Gzip ve Brotli’dir: tarayıcı desteklediği yöntemleri istekte bildirir, sunucu da bunlardan birini seçer. Sıkıştırmanın çalışıp çalışmadığını yanıttaki content-encoding başlığından anlarsınız; Gzip testi aracı bu başlığı ve kazanılan boyutu gösterir. Paylaşımlı hostingte ayarı açma adımları Gzip ve Brotli sıkıştırma rehberinde. Tarayıcı önbelleği, tekrar gelen ziyaretçinin aynı dosyayı yeniden indirmesini önler. Görsel, yazı tipi, CSS ve JavaScript dosyalarına uzun bir Cache-Control: max-age süresi verin ve dosya değiştiğinde adının ya da sürüm parametresinin de değişmesini sağlayın; böylece ziyaretçi eski dosyada takılı kalmaz. HTML sayfalarında kısa süre ya da yeniden doğrulama daha güvenlidir, aksi hâlde yeni içerik geç görünür. Yanıt başlıklarını HTTP başlık kontrolü ile inceleyebilirsiniz.

LiteSpeed sunucuda LiteSpeed Cache

LiteSpeed Cache eklentisinin sayfa önbelleği, LiteSpeed web sunucusu ya da QUIC.cloud CDN gerektirir. Görsel optimizasyonu, küçültme ve geç yükleme gibi özellikleri ise her sunucuda kullanılabilir. dticaret WordPress hosting paketleri LiteSpeed web sunucusunda çalıştığı için eklentinin sayfa önbelleği sunucu düzeyinde devreye girer. Önerilen sıra:

Ekran adımları LiteSpeed Cache kurulumu rehberinde anlatılıyor.

• Başka bir sayfa önbelleği eklentisi kuruluysa önce onu devre dışı bırakın.
• Önbelleği açın, oturum açmamış bir tarayıcıda sayfayı iki kez yükleyin; ikinci yanıtta x-litespeed-cache: hit başlığı görünmelidir.
• CSS ve JavaScript birleştirme, JavaScript geciktirme gibi sayfa optimizasyonu seçeneklerini tek tek açın; her birinden sonra menüyü, formları ve ödeme adımlarını deneyin.
• Görsel optimizasyonunu en son açın ve LCP görselinin geç yüklemenin dışında kaldığını kontrol edin.

Tema ve sayfa oluşturucu seçimi

Bir sitenin ön yüz ağırlığını belirleyen en büyük karar çoğu zaman tema seçimidir. Çok amaçlı (multipurpose) temalar, kullanmadığınız onlarca özelliğin CSS ve JavaScript dosyalarını her sayfada yükleyebilir. Yeni bir site kuruyorsanız ya da yeniden tasarım planlıyorsanız şu ölçütlere dikkat edin:

• Blok tabanlı temalar: WordPress’in blok editörü ve tam site düzenleme (Full Site Editing) özellikleriyle tasarlanmış temalar, genellikle yalnızca sayfada kullanılan blokların stillerini yükler.
• Demo sitesini ölçün: Temanın demo sayfasını PageSpeed Insights ile test edin; demo hızlı değilse sizin sitenizde de hızlı olmayacaktır.
• Sayfa oluşturucu bağımlılığını sorgulayın: Sayfa oluşturucular esneklik sağlar, ancak iç içe geçmiş çok sayıda HTML öğesi (DOM boyutu) ve ek betikler üretebilir. Kullanıyorsanız, yalnızca gereken modülleri etkinleştirin ve sağlayıcının performans ayarlarını açın.
• Kaydırıcı (slider) kullanmaktan kaçının: Ana sayfa kaydırıcıları genellikle büyük görseller ve ağır betikler içerir ve LCP’yi kötüleştirir. Tek ve optimize edilmiş bir kapak görseli çoğu zaman daha etkilidir.

Sunucu tarafında PHP işçileri ve kaynak limitleri

Önbelleklenemeyen her istek (sepet, ödeme, arama, yönetim paneli) bir PHP işçisi (PHP worker / süreç) tarafından işlenir. Aynı anda gelen istek sayısı, paketinizin izin verdiği eş zamanlı süreç (EP) veya PHP işçisi sayısını aşarsa, istekler sıraya girer ve site yavaşlar ya da hata verir. Bu yüzden:

• Kontrol panelinizdeki kaynak kullanımı ekranında EP ve CPU sınırlarına ne sıklıkla ulaşıldığını izleyin.
• Yavaş veritabanı sorguları işçileri uzun süre meşgul eder; Query Monitor ile en yavaş sorguları bulun.
• Bot trafiğini sınırlayın: Kötü niyetli tarayıcılar ve agresif SEO botları, gerçek ziyaretçiler için gereken kaynakları tüketebilir. Hosting sağlayıcınızın bot koruma ve hız sınırlama seçeneklerini kullanın.

Adım adım hızlandırma planı

Yukarıdaki adımları aşağıdaki sırayla uygulamak, her değişikliğin etkisini ayrı ayrı görmenizi sağlar:

1. Yedek alın ve ölçün: Tam yedek alın; PageSpeed Insights (mobil) ve Search Console Core Web Vitals raporundan başlangıç değerlerini kaydedin.
2. Sunucu tarafını düzeltin: PHP’yi desteklenen güncel bir sürüme yükseltin, OPcache’i doğrulayın ve tek bir sayfa önbelleği yapılandırın.
3. Nesne önbelleğini ekleyin: Önbelleklenemeyen sayfalarınız çoksa Redis veya Memcached ile kalıcı nesne önbelleğini etkinleştirin.
4. Görselleri düzeltin: Görselleri WebP/AVIF’e dönüştürün, boyutlarını küçültün, LCP görselinin lazy-load edilmediğini ve öncelikli yüklendiğini doğrulayın.
5. Fontları ve betikleri hafifletin: Font ağırlıklarını azaltın, fontları yerelde barındırın, gereksiz ve üçüncü taraf JavaScript’i kaldırın veya erteleyin.
6. Eklenti ve veritabanı temizliği yapın: Gereksiz eklentileri silin, revizyonları sınırlayın, autoload verilerini ve geçici verileri temizleyin.
7. WP-Cron ve Heartbeat’i düzenleyin: WP-Cron’u sistem cron’una taşıyın ve Heartbeat sıklığını azaltın.
8. Yeniden ölçün ve izleyin: Laboratuvar testlerini tekrarlayın; saha verilerinin güncellenmesi için yaklaşık 28 gün bekleyin ve Search Console raporunu izleyin.

Sık yapılan hatalar

• Yalnızca PageSpeed puanına odaklanmak. Puan bir laboratuvar özetidir; asıl hedef saha verisindeki Core Web Vitals değerleridir.
• Birden fazla önbellek veya optimizasyon eklentisi kullanmak. Çakışmalar sitenin bozulmasına yol açabilir.
• Her şeyi ertelemek. Tüm JavaScript’i geciktirmek menülerin, formların veya ödeme adımlarının çalışmamasına neden olabilir; her değişiklikten sonra kritik akışları test edin.
• Kaynak yetersizliğini eklentiyle çözmeye çalışmak. Kontrol panelinde sürekli CPU veya bellek sınırına ulaşılıyorsa, “508 Resource Limit Reached” hatası gibi belirtiler görülür; bu durumda 508 hatası rehberimizdeki teşhis adımlarını uygulayın.
• Dosya sayısını göz ardı etmek. Binlerce önbellek dosyası ve küçük resim boyutu, inode limitlerine ulaşmanıza yol açabilir; ayrıntılar için inode nedir rehberine bakabilirsiniz.

Hızı kalıcı kılmak: izleme ve bakım

Bir kez yapılan optimizasyon, yeni eklentiler, tema güncellemeleri ve büyüyen içerikle zamanla aşınır. Hızı kalıcı kılmak için:

• Aylık kontrol: Search Console’daki Core Web Vitals raporunu ayda bir inceleyin; “iyileştirme gerekiyor” veya “kötü” grubuna düşen URL gruplarını not edin.
• Değişiklik öncesi ölçüm: Yeni bir eklenti veya tema özelliği eklemeden önce ve sonra aynı sayfada laboratuvar testi yapın.
• Hazırlık ortamı: Büyük güncellemeleri önce bir staging kopyasında deneyin.
• Kaynak kullanımını izleyin: Hosting kontrol panelinizdeki CPU, bellek ve süreç grafikleri, trafik artışlarının sunucuyu ne zaman zorladığını gösterir. Hizmet durumumuzu ve planlı bakımları durum sayfamızdan takip edebilirsiniz.
• Güvenliği ihmal etmeyin: Hız için kurulan her eklenti de güncel tutulmalıdır; güncelleme, yedek ve erişim önlemleri için web sitesi güvenliği ve KVKK rehberimize bakın.
• Erişilebilirlik ve SEO ile birlikte düşünün: Hız optimizasyonu, görsellerin alternatif metinlerini veya yapılandırılmış verileri silmemelidir.

Sık sorulan sorular

Sonuç

WordPress hızlandırma bir eklenti kurmaktan ibaret değildir; ölçüm, sunucu, ön yüz ve bakım katmanlarından oluşan bir süreçtir. Önce ölçün, ardından en büyük etkiyi yaratan sunucu tarafındaki adımlardan başlayın, sonra görselleri, fontları ve betikleri hafifletin; her değişiklikten sonra yeniden ölçün. Bu döngü düzenli olarak tekrarlandığında siteniz hem kullanıcılar hem de arama motorları için hızlı kalır.

Kaynaklar

• web.dev – Web Vitals ve eşikler: https://web.dev/articles/vitals
• web.dev – INP, Core Web Vitals metriği oldu (12 Mart 2024): https://web.dev/blog/inp-cwv-launch
• web.dev – TTFB: https://web.dev/articles/ttfb
• PHP – Desteklenen sürümler: https://www.php.net/supported-versions.php
• WordPress 6.5 – AVIF desteği: https://make.wordpress.org/core/2024/02/23/wordpress-6-5-adds-avif-support/
• WordPress 6.3 – fetchpriority ve lazy-load iyileştirmeleri: https://make.wordpress.org/core/2023/07/13/image-performance-enhancements-in-wordpress-6-3/
• WordPress Developer – Cron: https://developer.wordpress.org/plugins/cron/
• WordPress 6.8 – Speculative loading: https://make.wordpress.org/core/2025/03/06/speculative-loading-in-6-8/
• WooCommerce – HPOS: https://developer.woocommerce.com/docs/features/high-performance-order-storage/