Bir WordPress sitesi tarayıcıda açıldığında gözünüze hızlı görünebilir; ne var ki Google'ın ölçtüğü şey sizin izleniminiz değil, sahadaki gerçek ziyaretçilerin yaşadığı deneyimdir. Bu deneyimi somut sayılara döken üç metrik var: LCP, INP ve CLS. Topluca Core Web Vitals adı verilen bu üçlü, sayfanın ne kadar çabuk göründüğünü, tıklamaya ne kadar hızlı yanıt verdiğini ve yüklenirken içeriğin ne kadar zıpladığını ölçer. İyi haber şu: bu metriklerin üçü de doğrudan sıralama sinyali olarak kullanılır ve üçünü de kod bilmeden ya da çok az teknik dokunuşla iyileştirebilirsiniz.
Bu rehberde önce üç metriğin her birini sade dille açıklayacağız; ardından WordPress'te bu skorları en sık bozan somut nedenleri — ağır bir tema, render engelleyen JavaScript, boyutu belirtilmemiş görseller, geç yüklenen fontlar — ve bunların çözümlerini tek tek ele alacağız. Kritik CSS'i satır içine almaktan JavaScript'i ertelemeye, görsellere width/height vermekten font-display ayarına kadar her adımı uygulamalı göstereceğiz. Son bölümde de tüm bunları Google PageSpeed Insights ile nasıl ölçüp yorumlayacağınızı ve nereden başlamanız gerektiğini bulacaksınız.
Core Web Vitals Nedir ve Neden Önemlidir?#
Core Web Vitals, Google'ın "sayfa deneyimi" (page experience) değerlendirmesinin ölçülebilir çekirdeğidir. Üç metrik, kullanıcının bir sayfayla kurduğu ilişkinin üç farklı anını temsil eder: yükleme (LCP), etkileşim (INP) ve görsel kararlılık (CLS). Her biri için Google net eşikler tanımlar ve sitenizi "iyi", "iyileştirilmeli" ya da "zayıf" olarak sınıflar. Değerlendirme, sayfalarınızın en az yüzde 75'inin "iyi" eşiğini geçmesine bakar.
| Metrik | Ölçtüğü şey | İyi | İyileştirilmeli | Zayıf |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | En büyük içerik öğesinin görünme süresi | ≤ 2,5 sn | 2,5 - 4 sn | > 4 sn |
| INP (Interaction to Next Paint) | Etkileşime verilen tepki süresi | ≤ 200 ms | 200 - 500 ms | > 500 ms |
| CLS (Cumulative Layout Shift) | Yüklenirken oluşan yerleşim kayması | ≤ 0,1 | 0,1 - 0,25 | > 0,25 |
Burada çok önemli bir ayrım var: saha verisi (field data) ile laboratuvar verisi (lab data) aynı şey değildir. Google'ın sıralamada kullandığı skor, gerçek Chrome kullanıcılarının son 28 günlük verisinden derlenen CrUX (Chrome User Experience Report) veri setinden gelir. PageSpeed Insights'ta üstteki renkli bölüm bu saha verisidir. Alttaki Lighthouse bölümü ise tek bir simülasyon çalıştırmasının laboratuvar sonucudur; hızlı geri bildirim için değerlidir ama sıralamayı doğrudan belirleyen o değildir. Bu yüzden bir değişiklik yaptıktan sonra saha verisinin güncellenmesi birkaç hafta sürebilir — sabırlı olun ve laboratuvar skoruna bakarak "düzeldi" diye acele karar vermeyin.
INP metriğinin, Mart 2024'te eski FID (First Input Delay) metriğinin yerini aldığını da bilmekte fayda var. FID yalnızca ilk etkileşimin gecikmesini ölçüyordu; INP ise sayfadaki tüm etkileşimlerin en kötüsünü dikkate aldığı için çok daha gerçekçi ve çoğu WordPress sitesi için geçmesi daha zor bir sınavdır.
LCP: En Büyük İçeriğin Ne Zaman Göründüğü#
LCP, ekranın görünen alanındaki en büyük öğenin — çoğunlukla bir kapak (hero) görseli, büyük bir başlık ya da video posteri — ne zaman çizildiğini ölçer. Ziyaretçinin "sayfa açıldı" hissini büyük ölçüde bu an belirler. WordPress'te LCP'yi bozan tipik üç neden vardır ve genellikle üçü bir arada bulunur.
Birincisi yavaş sunucu yanıtı (yüksek TTFB): önbelleksiz bir WordPress her istekte veritabanına sorgu atıp sayfayı PHP ile sıfırdan üretir; zayıf bir paylaşımlı planda bu, ilk baytın gelmesini bile geciktirir. İkincisi optimize edilmemiş kapak görseli: doğrudan telefondan yüklenmiş 4-5 MB'lık bir hero görseli LCP'yi tek başına saniyelerce geciktirir. Üçüncüsü render engelleyen kaynaklar: <head> içinde bekleyen büyük CSS ve senkron JavaScript, tarayıcının boyamaya başlamasını erteler.
Çözüm de bu üç cepheye ayrılır. Önce sağlam bir barındırma ve önbellek katmanıyla TTFB'yi düşürün — NVMe diskli, LiteSpeed tabanlı bir WordPress hosting altyapısı burada gözle görülür fark yaratır. Sonra kapak görselini WebP'ye çevirip doğru boyuta indirin ve onu asla tembel yüklemeyin; aksine tarayıcıya erken indirmesini söyleyin:
<!-- Kapak görselini erken keşfet ve öncelikli indir -->
<link rel="preload" as="image" href="/wp-content/uploads/kapak.webp" fetchpriority="high">
<!-- İlk ekrandaki ana görsele lazy load UYGULAMAYIN -->
<img src="/wp-content/uploads/kapak.webp" width="1600" height="900"
fetchpriority="high" alt="Kapak">
fetchpriority="high" ve preload, tarayıcının kapak görselini diğer kaynaklardan önce indirmesini sağlar; bu tek dokunuş çoğu sitede LCP'yi yarım saniyeden fazla iyileştirir. Görsel tarafının tamamı için WordPress hız optimizasyonu rehberimizdeki adımlar bu metriği besleyen en etkili yatırımdır.
INP: Sayfanın Etkileşimlere Verdiği Tepki#
INP, bir kullanıcı butona tıkladığında, menüyü açtığında ya da bir alana yazı yazdığında sayfanın yeniden boyanana kadar geçen süreyi ölçer; sayfa boyunca yaşanan tüm etkileşimler içinde en kötüsünü rapor eder. Yüksek INP, "tıkladım ama bir şey olmadı" hissinin sayısal karşılığıdır ve neredeyse her zaman ağır JavaScript kaynaklıdır.
WordPress'te başlıca suçlular şunlardır: birbiriyle çakışan onlarca eklentinin her sayfaya eklediği script yığını, üçüncü taraf gömülü içerikler (canlı sohbet widget'ı, reklam ağları, sosyal medya beğeni butonları) ve ana iş parçacığını (main thread) uzun süre meşgul eden "uzun görevler" (long tasks). Tarayıcı bu görevlerle uğraşırken kullanıcının tıklamasını işleyemez; INP fırlar.
İyileştirmenin en etkili yolu, çalışan JavaScript miktarını azaltmak ve zorunlu olmayanı ertelemektir. İlk ekran için gerekmeyen script'leri defer ile geciktirin; böylece HTML çözümlenirken indirilir ama yürütmesi sayfa çizildikten sonraya bırakılır:
<!-- Senkron (INP'yi bozar): <script src="analiz.js"></script> -->
<!-- Ertelenmiş (tercih edilen): -->
<script src="analiz.js" defer></script>
Üçüncü taraf script'leri (chat, harita, reklam) mümkünse kullanıcı sayfayla ilk kez etkileşime geçene kadar hiç yüklemeyin — birçok performans eklentisinde "JavaScript'i geciktir" veya "etkileşimde yükle" seçeneği tam olarak bunu yapar. Kullanmadığınız eklentileri devre dışı bırakmakla yetinmeyip tamamen silin; her etkin eklenti potansiyel bir INP yüküdür. Yoğun trafikli ya da işlem yükü ağır bir sitede kaynakları size ayrılmış bir VDS sunucu da tarayıcı tarafı gecikmeleri değil, sunucu tarafı gecikmeleri ortadan kaldırarak dolaylı katkı sağlar.
CLS: Yerleşim Kaymasını Önlemek#
CLS, sayfa yüklenirken öğelerin beklenmedik biçimde yer değiştirmesini ölçer. Hepimiz yaşamışızdır: bir yazıyı okumaya başlarsınız, üstte geç yüklenen bir görsel ya da reklam metni aşağı iter, tam okuduğunuz satırı kaybedersiniz — ya da tıklamak istediğiniz butona basacakken buton kayar. CLS bu can sıkıcı deneyimin puanıdır ve düşük olması (0,1 altı) gerekir.
WordPress'te CLS'yi bozan en yaygın neden, boyutu belirtilmemiş görsellerdir. Bir <img> etiketinde width ve height yoksa tarayıcı görselin kaplayacağı alanı önceden bilemez; görsel yüklenince altındaki her şey aşağı zıplar. Çözüm basittir ve zaten modern WordPress'in yaptığı şeydir: her görsele boyut değeri verin. Böylece tarayıcı yerini baştan ayırır.
<!-- CLS yaratır (tarayıcı yer ayıramaz) -->
<img src="urun.webp" alt="Ürün">
<!-- CLS'i önler (oran baştan bilinir) -->
<img src="urun.webp" width="800" height="600" alt="Ürün">
İkinci büyük neden web fontlarıdır: font geç yüklendiğinde metin önce yedek fontla, sonra asıl fontla çizilir ve satır uzunlukları değiştiği için yerleşim kayar. Üçüncüsü, dinamik olarak enjekte edilen içeriktir — mevcut içeriğin üstüne sonradan giren reklam bloğu, çerez bildirimi ya da "abone ol" çubuğu. Bunların hepsi için altın kural aynıdır: öğe gelmeden önce ona yer ayırın. Reklam ve gömülü içerik kutularına CSS ile sabit bir minimum yükseklik verin; hiçbir şeyi mevcut içeriğin üstüne, kullanıcı zaten okurken itmeyecek şekilde yerleştirin.
/* Reklam/afiş yuvasına baştan yer ayır, geldiğinde zıplamasın */
.reklam-yuvasi {
min-height: 280px;
display: block;
}
Render Engelleyen Kaynakları Kaldırma ve Kritik CSS#
Hem LCP hem de genel algılanan hız için en belirleyici teknik konu, render engelleyen kaynaklardır. Tarayıcı, <head> içindeki senkron CSS ve JavaScript'i indirip işlemeden sayfayı boyamaya başlamaz. Tema ve eklentiler sayfaya onlarca stil ve script dosyası eklediğinde, ilk boyama bu kuyruğun sonuna kadar bekler.
Buradaki çözüm "kritik CSS" yaklaşımıdır: ilk ekranın (above the fold) çizilmesi için gereken az miktardaki stili doğrudan HTML'in içine satır içi (inline) gömersiniz; geri kalan büyük stil dosyasını ise boyama tamamlandıktan sonra, engellemeden yüklersiniz. Aynı mantıkla, ilk görünüm için şart olmayan JavaScript'i defer veya async ile ertelersiniz.
<!-- Kritik CSS satır içi: ilk ekran hemen çizilir -->
<style>/* yalnızca üst kısım için gereken minimum stil */</style>
<!-- Ağır stil dosyasını engellemeden, sonradan yükle -->
<link rel="preload" href="/wp-content/themes/tema/style.css" as="style"
onload="this.rel='stylesheet'">
Bu ince ayarların neredeyse tamamı elle kod yazmadan yapılabilir. WP Rocket, LiteSpeed Cache ve W3 Total Cache gibi eklentilerin hepsinde "Kritik CSS üret", "Kullanılmayan CSS'i kaldır" ve "JavaScript'i ertele/geciktir" seçenekleri bulunur. Bir uyarı: bu seçenekleri açtıktan sonra siteyi baştan sona gezin. Agresif "kullanılmayan CSS'i kaldır" ayarı bazen gerçekten kullanılan bir stili de eleyebilir ya da script birleştirme bir butonu çalışmaz hâle getirebilir; böyle bir durumda sorunlu dosyayı istisna listesine ekleyip düzeltirsiniz.
font-display ile Web Fontlarını Optimize Etme#
Web fontları, hem CLS'yi hem de metnin görünme süresini (dolayısıyla LCP'yi) doğrudan etkiler. Bir font indirilirken tarayıcının nasıl davranacağını font-display özelliği belirler. Varsayılan davranış çoğu zaman metni font gelene kadar hiç göstermemektir (FOIT — görünmez metin) — bu, ziyaretçiye birkaç saniye boş bir sayfa gösterir. font-display: swap ise metni hemen yedek sistem fontuyla çizer, asıl font gelince değiştirir; içerik anında okunur hâle gelir.
@font-face {
font-family: "Inter";
src: url("/wp-content/fonts/inter.woff2") format("woff2");
font-weight: 400;
font-display: swap; /* metni bekletme, hemen göster */
}
swap metnin erken görünmesini sağlar ama font değişimi anında hafif bir kayma yaratabilir; bunu en aza indirmek için yedek font ile asıl fontun boyutlarını size-adjust ile yakınlaştırabilir ya da fontu preload ederek değişim penceresini kısaltabilirsiniz. En temiz yaklaşım ise fontları kendi sunucunuzda barındırmaktır: Google Fonts'u uzaktan çağırmak yerine .woff2 dosyalarını kendi hostinginize koyup oradan sunmak, hem ekstra bir DNS/bağlantı turunu ortadan kaldırır hem de gizlilik açısından daha temizdir.
<!-- Kritik fontu erken indir: değişim penceresini kısaltır -->
<link rel="preload" href="/wp-content/fonts/inter.woff2" as="font"
type="font/woff2" crossorigin>
Yalnızca gerçekten kullandığınız font ağırlıklarını (örneğin 400 ve 700) yükleyin; bir temanın varsayılan olarak sekiz farklı ağırlığı çağırması hem gereksiz bant genişliği hem de fazladan istek demektir. Kullanmadığınız ağırlıkları kaldırmak, tek başına birkaç yüz kilobayt tasarruf sağlayabilir.
PageSpeed Insights ile Ölçme ve Yorumlama#
Optimizasyonun altın kuralı değişmez: önce ölç, sonra dokun, sonra tekrar ölç. Aksi hâlde yaptığınız değişikliğin gerçekten işe yarayıp yaramadığını asla bilemezsiniz. Core Web Vitals için başvuracağınız temel araç Google PageSpeed Insights'tır (pagespeed.web.dev). Sitenizin adresini girdiğinizde iki ayrı bölüm görürsünüz ve ikisini karıştırmamak kritiktir.
| Bölüm | Kaynak | Ne işe yarar |
|---|---|---|
| Saha verisi (üst) | Gerçek Chrome kullanıcıları, son 28 gün (CrUX) | Google'ın sıralamada kullandığı gerçek skor |
| Laboratuvar verisi (alt) | Tek seferlik Lighthouse simülasyonu | Anlık geri bildirim ve somut öneri listesi |
Günlük çalışmada hızlı geri bildirim için laboratuvar (Lighthouse) bölümüne bakarsınız; "Fırsatlar" ve "Tanılama" listeleri size hangi kaynağın engellediğini, hangi görselin büyük olduğunu tek tek söyler. Ancak nihai kararı saha verisi belirler ve o birkaç hafta gecikmeyle güncellenir. Komut satırından tekrarlı ölçüm yapmak isterseniz Lighthouse'un CLI sürümünü kullanabilirsiniz:
# Lighthouse CLI ile komut satırından ölçüm (Node.js gerektirir)
npm install -g lighthouse
lighthouse https://siteniz.com --only-categories=performance --view
Tarayıcının kendi araçları da çok işe yarar: Chrome'da F12 ile geliştirici araçlarını açıp "Performance" sekmesinde bir kayıt alarak uzun görevleri (INP'nin kaynağı) ve "Performance insights" panelinde LCP öğesinin tam olarak hangi görsel olduğunu görebilirsiniz. Ayrıca sunucu yanıt süresini (TTFB) hızlıca kontrol etmek için curl yeterlidir:
# Sunucunun ilk bayta kadar geçen süresini ölç (TTFB göstergesi)
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\nToplam: %{time_total}s\n" https://siteniz.com
Ölçümü her zaman aynı araç, aynı cihaz profili (mobil) ve tarayıcı/site önbelleği temizlenmiş hâlde tekrarlayın; farklı koşullarda alınan iki sonucu karşılaştırmak yanıltıcıdır. Core Web Vitals'ın SEO tarafındaki yerini ve neyi beslediğini merak ediyorsanız WordPress SEO başlangıç rehberimiz bu bağlamı bütünüyle açıklar.
Öncelik Sırası ve Sürdürülebilir Bir Bakım Rutini#
Üç metriği aynı anda kovalamak yerine sizi en çok zorlayandan başlamak, harcadığınız emeğin karşılığını en hızlı verir. Çoğu WordPress sitesinde etki sırası şöyledir: önce LCP (sağlam hosting + önbellek + kapak görseli), sonra INP (eklenti temizliği + JavaScript erteleme), en sonra CLS (görsel boyutları + font ayarı). PageSpeed raporunuzda hangi metrik kırmızı ya da turuncuysa oradan başlayın; genellikle tek bir darboğaz skorun büyük kısmını aşağı çeker.
Bir kez iyileştirmek de yetmez. Zamanla yeni eklentiler eklenir, tema güncellenir, içerik birikir ve kazandığınız skor yavaşça erir. Şu kısa rutini alışkanlık hâline getirin:
- Ayda bir PageSpeed Insights saha verinizi kontrol edin; bir metrikte düşüş varsa erken yakalayın.
- Yeni bir eklenti kurduğunuzda ölçümü tekrarlayın — özellikle slider, form ve sohbet eklentileri INP'yi bozmaya yatkındır.
- Yeni içerik yüklerken görsellerin boyutlandırılmış ve WebP olduğundan emin olun.
- WordPress çekirdeğini, temayı ve eklentileri güncel tutun; her güncelleme öncesi mutlaka yedek alın.
Bu takibi kendiniz üstlenmek istemiyorsanız, düzenli güncelleme, yedekleme ve performans denetimini kapsayan bir WordPress bakım hizmeti bu yükü büyük ölçüde omuzlarınızdan alır. Sitenizi başka bir sunucuya taşırken bu ayarların kaybolmasından çekiniyorsanız site taşıma hizmetimiz süreci sizin yerinize yürütür.
Sıkça Sorulan Sorular#
Core Web Vitals skorum düzeldi ama Google'da hâlâ eski değeri görüyorum, neden?#
Çünkü Google'ın sıralamada ve Search Console'da gösterdiği değer, gerçek kullanıcıların son 28 günlük verisinden (CrUX saha verisi) derlenir. Bir değişiklik yaptığınızda laboratuvar (Lighthouse) skoru anında iyileşir, ancak saha verisinin bu iyileşmeyi yansıtması genellikle iki ila dört hafta sürer. Bu yüzden değişikliğinizi laboratuvar sonucuyla doğrulayıp sabırla bekleyin; erken panik yapıp ayarları geri almak en sık yapılan hatadır.
INP ile eski FID arasındaki fark nedir?#
FID yalnızca kullanıcının sayfayla ilk etkileşiminin ne kadar geciktiğini ölçüyordu ve çoğu site bu sınavı kolayca geçiyordu. Mart 2024'te yerini alan INP ise sayfa boyunca yaşanan tüm etkileşimlerin en kötüsünü dikkate alır, dolayısıyla çok daha gerçekçi ve geçmesi daha zor bir metriktir. Pratikte bu, ağır JavaScript çalıştıran eklenti yığınlarının artık gizlenemediği anlamına gelir; INP'yi iyileştirmenin yolu neredeyse her zaman çalışan script miktarını azaltmaktan geçer.
Bir önbellekleme eklentisi kurmak Core Web Vitals için yeterli mi?#
Önbellekleme çoğu zaman en büyük tek kazancı LCP tarafında sağlar, çünkü sunucu yanıt süresini (TTFB) belirgin biçimde düşürür. Ancak tek başına yeterli değildir; INP'yi bozan ağır JavaScript ve CLS'ye yol açan boyutsuz görseller önbelleklemeden etkilenmez. En sağlıklısı, önbeklemeyle birlikte JavaScript erteleme, görsel optimizasyonu ve font ayarlarını da devreye almaktır. İyi haber, çoğu modern önbellekleme eklentisinin bu ek işlevleri tek arayüzde barındırmasıdır.
Görsellere width ve height eklemek CLS için gerçekten şart mı?#
Evet ve bu, en düşük emekle en yüksek CLS kazancını veren adımdır. Görselde boyut değeri yoksa tarayıcı onun kaplayacağı alanı önceden ayıramaz; görsel yüklendiğinde altındaki içerik aşağı zıplar ve tam da bu zıplama CLS skorunuzu bozar. Modern WordPress temaları boyut değerlerini otomatik ekler, ama elle eklenmiş ya da eski bir temadaki görsellerde bunu kontrol etmelisiniz. Değerleri eklediğinizde tarayıcı yeri baştan ayırır ve kayma ortadan kalkar.
Paylaşımlı hosting'de iyi bir Core Web Vitals skoru mümkün mü?#
Kesinlikle mümkün. Bu rehberdeki adımların büyük çoğunluğu — görsel optimizasyonu, JavaScript erteleme, boyut değerleri, font ayarı, önbellekleme — paylaşımlı planlarda da uygulanır ve ciddi kazanç getirir. Yalnızca LCP'nin sunucu tarafı bileşeni olan TTFB, kaynakların paylaşıldığı planlarda bir tavana çarpabilir. Siteniz büyüyüp trafik arttıkça kaynakları size ayrılmış bir VDS ya da sanal sunucu çözümüne geçmek, özellikle LCP'de en kalıcı iyileştirmeyi sağlar.
Hangi araçla ölçüm yapmalıyım?#
Sıralamayı etkileyen değeri görmek için mutlaka Google PageSpeed Insights'ın saha verisi (üstteki renkli) bölümüne bakın; günlük iyileştirme çalışmasında ise aynı sayfadaki laboratuvar (Lighthouse) bölümü size somut öneriler verir. Daha derin analiz için Chrome geliştirici araçlarındaki "Performance" sekmesi uzun görevleri ve LCP öğesini net gösterir. Ölçümü her zaman mobil profille ve önbellek temizlenmiş hâlde tekrarlayın ki karşılaştırmalarınız anlamlı olsun.
Kapanış#
Core Web Vitals, ziyaretçinin sitenizle yaşadığı deneyimi üç somut sayıya indirir: içeriğin ne kadar çabuk göründüğü (LCP), tıklamaya ne kadar hızlı yanıt verdiği (INP) ve yüklenirken ne kadar oynadığı (CLS). Bu üçünü iyileştirmek büyülü bir tek dokunuş değil, birbirini tamamlayan küçük ve mantıklı adımların toplamıdır: hızlı bir sunucu, iyi kurulmuş bir önbellek, hafifletilmiş görseller, ertelenmiş JavaScript, boyut verilmiş öğeler ve doğru ayarlanmış fontlar. Her değişikliği ölçerek doğruladığınızda hem skorun hem de gerçek ziyaretçi memnuniyetinin birlikte yükseldiğini göreceksiniz.
Bütün bu iyileştirmelerin oturacağı zemin en baştan sağlamsa yolun yarısını almış olursunuz. NVMe diskli, LiteSpeed tabanlı bir WordPress hosting paketi TTFB ve LCP tarafında güçlü bir çıkış noktasıdır; büyüyen, kaynak açlığı olan bir site işletiyorsanız kaynakları yalnızca size ayrılmış bir VDS sunucu çok daha kararlı bir performans sunar. Genel hız tarafını derinleştirmek isterseniz WordPress hız optimizasyonu rehberimiz, arama görünürlüğüyle bağlantısını görmek isterseniz de WordPress SEO başlangıç rehberimiz bu yolda size adım adım eşlik eder.