Hız eklentisi kurmak çoğu sitede puanı yükseltir ama yükleme süresini beklendiği kadar düşürmez. Gerçek kazanç dört yerde: görsel formatı, LCP öğesi, düzen kayması ve üçüncü taraf istekleri.
WordPress'te ölçülebilir hız kazancının büyük bölümü dört müdahaleden gelir: (1) görselleri sunucu tarafında WebP'ye çevirmek — çoğu sitede en büyük tek kalem budur; (2) ilk ekrandaki en büyük görseli (LCP öğesi) preload ile bildirmek ve tembel yüklemeden muaf tutmak; (3) görsel ve logolara sabit ölçü vererek düzen kaymasını (CLS) kapatmak; (4) Google Fonts gibi üçüncü taraf isteklerini kendi sunucunuza taşımak. Eklenti kurmak bunların yerine geçmez.
Optimizasyona başlamadan önce siteyi neyin yavaşlattığını bilmek gerekir; aksi hâlde saatler yanlış yerde harcanır.
Pratik yöntem: tarayıcının geliştirici araçlarında ağ sekmesini açın, önbelleği devre dışı bırakın ve sayfayı yükleyin. Ardından iki soruyu cevaplayın:
Bu iki cevap, yapılacak işin sırasını da belirler.
Bu, neredeyse her sitede en büyük tek kazançtır ve en çok atlanan adımdır.
Tipik bir WordPress sitesinde yükleme klasörü, yıllar içinde optimize edilmemiş JPEG ve PNG'lerle şişer. Gerçek bir örnekte, bir kafenin sitesindeki görsel klasörü 147 MB'tan yaklaşık 10 MB'a düştü — sadece format dönüşümüyle, görünür kalite kaybı olmadan.
Doğru yaklaşım iki parçalıdır:
Dönüşümde dikkat edilecekler: orijinal dosyaları hemen silmeyin (geri dönüş gerekebilir), şeffaflık içeren PNG'lerin şeffaflığının korunduğunu kontrol edin ve dönüşümden sonra sitenin görsel kalitesini gerçekten gözle inceleyin. Aşırı sıkıştırma, kazandığınız saniyeden daha pahalıya mal olur.
Largest Contentful Paint, ilk ekranda görünen en büyük öğenin ne zaman çizildiğini ölçer. Çoğu sitede bu öğe bir hero görselidir ve sorun şudur: tarayıcı o görselin varlığını, CSS'i indirip işledikten sonra öğrenir.
Bu gecikme, görseli HTML'in başında bildirerek ortadan kalkar:
<link rel="preload" as="image"
href="/uploads/2026/hero.webp"
fetchpriority="high" />Bununla birlikte iki hata sık yapılır:
loading="lazy" ilk ekrandaki görsele uygulandığında LCP'yi iyileştirmez, doğrudan kötüleştirir. Tembel yükleme yalnızca ekranın altındaki görseller içindir.Not: LCP öğesi her sayfada aynı olmayabilir. Ana sayfada hero görseli, ürün sayfasında ürün fotoğrafı, yazı sayfasında ise bir metin bloğu olabilir. Metin bloğuysa preload edilecek görsel yoktur — o zaman iş fontlara döner.
Cumulative Layout Shift, sayfa yüklenirken içeriğin zıplamasını ölçer. Kullanıcı açısından en sinir bozucu davranıştır: okumaya başladığınız satır aşağı kayar, tıklamak üzere olduğunuz düğme yerinden oynar.
Sebebi neredeyse her zaman aynıdır: tarayıcı bir öğenin ne kadar yer kaplayacağını önceden bilmiyor.
En sık karşılaşılan üç kaynak:
<img> etiketinde width ve height bulunmalıdır. Tarayıcı bu iki sayıdan oranı hesaplar ve yeri baştan ayırır.font-display: swap ve yakın ölçülü bir yedek font yığını bunu azaltır.Google Fonts kullanan bir sayfa, en az iki ayrı sunucuya bağlanır: stil dosyası için fonts.googleapis.com, font dosyaları için fonts.gstatic.com. Her yeni sunucu bağlantısı DNS çözümlemesi, TCP el sıkışması ve TLS anlaşması demektir.
Fontları kendi sunucunuza taşımak bu iki bağlantıyı tamamen ortadan kaldırır. Yöntem:
woff2 dosyalarını indirin ve sitenize koyun.@font-face kurallarını birebir kendi stil dosyanıza taşıyın — unicode-range satırlarını mutlaka koruyun.preload edin.unicode-range satırlarını atlamak sık yapılan bir hatadır. O satırlar tarayıcıya hangi dosyanın hangi karakter aralığını kapsadığını söyler; atlanırsa tarayıcı ihtiyaç duymadığı alfabelerin dosyalarını da indirir. Türkçe için ayrıca dikkat: İ, ş, ğ, ç gibi karakterler latin-ext aralığındadır — yalnızca latin dosyasını alırsanız bu harfler yedek fontla çizilir ve metin karışık görünür.
Aynı ilke tüm üçüncü taraf istekleri için geçerlidir: her harici sunucu bir gecikme kaynağıdır ve çoğu gerçekten gerekli değildir.
Optimizasyonun en tehlikeli tarafı, ölçtüğünüz şeyi iyileştirirken ölçmediğiniz şeyi bozmaktır.
En sık görülen örnek: hız eklentisinin tüm JavaScript'i toptan ertelemesi. Puan yükselir, sayfa hızlı görünür — ama WooCommerce'in blok tabanlı ödeme sayfası çalışmaz hâle gelir ve müşteri "sepetiniz boş" mesajıyla karşılaşır. Bu hatanın ayrıntısı ve çözümü ayrı bir notta.
Bu yüzden her optimizasyondan sonra, puana değil akışa bakın: gizli sekmede ürünü sepete ekleyin, ödeme sayfasına gidin, formu doldurun. Puan 100 olup satış alamayan siteler, puanı 80 olup satan sitelerden çok daha yaygın.
Sıralama nettir: önce görselleri WebP'ye çevirin, sonra LCP öğesini önden yükleyin ve tembel yüklemeden muaf tutun, ardından ölçüsü belirtilmemiş görselleri düzeltin, en son üçüncü taraf isteklerini kendinize taşıyın.
Bu dördü yapıldıktan sonra hız eklentisinin katkısı ölçülebilir ama küçüktür. Yapılmadan kurulan eklenti ise çoğunlukla puanı süsler, deneyimi değiştirmez.
Genellikle değil. Eklentiler önbellek, sıkıştırma ve birleştirme yapar; bunlar faydalıdır ama çoğu sitede ağırlığın büyük kısmını oluşturan optimize edilmemiş görselleri, yanlış işaretlenmiş LCP öğesini ve ölçüsü belirtilmemiş görselleri düzeltmezler. Bu dördü yapılmadan kurulan eklenti puanı süsler, deneyimi az değiştirir.
Doğru ayarlarla gözle fark edilmeyecek düzeyde. Gerçek bir kurulumda görsel klasörü 147 MB'tan yaklaşık 10 MB'a düştü ve görünür kalite kaybı olmadı. Dikkat edilecek noktalar: orijinalleri hemen silmemek, şeffaf PNG'lerin şeffaflığını doğrulamak ve dönüşüm sonrası siteyi gözle kontrol etmek.
Hayır, tam tersi. loading="lazy" ilk ekrandaki görsele uygulandığında tarayıcı o görseli daha geç istemeye başlar ve LCP doğrudan kötüleşir. Tembel yükleme yalnızca ilk ekranın altındaki görseller için doğrudur; LCP öğesi ise tersine preload edilmelidir.
Evet, ölçülebilir bir kazanç sağlar çünkü iki ayrı harici bağlantı ortadan kalkar. Taşırken @font-face kurallarını birebir kopyalayın ve unicode-range satırlarını mutlaka koruyun. Türkçe için kritik: İ, ş, ğ gibi harfler latin-ext aralığındadır; yalnızca latin dosyasını alırsanız bu harfler yedek fontla çizilir.