WordPress Core Web Vitals: Hangi Ölçümle Başlanır, Sonuç Nasıl Okunur?

WordPress'te Core Web Vitals ölçümüne hangi veriyle başlanır?

WordPress’te Core Web Vitals ölçümüne saha verisiyle başlanır, çünkü değerlendirme gerçek kullanıcıların sayfa yüklemelerinin 75. yüzdeliğine göre yapılır; laboratuvar ölçümü sorunun nedenini bulmak için ikinci adımdır. Saha verisi Chrome Kullanıcı Deneyimi Raporu’ndan (CrUX) gelir ve iki yerde okunur: Search Console’daki Önemli Web Verileri raporu ile PageSpeed Insights’ın üst bölümü. Saha verisi yoksa aynı sayfa Lighthouse ile en az beş kez ölçülür ve medyan alınır.

Kaynak	Veri türü	Ne gösterir	Ne zaman kullanılır
Search Console Önemli Web Verileri raporu	Saha (CrUX), son 28 gün	Benzer sayfalardan oluşan URL grupları ve İyi / İyileştirme gerektiriyor / Kötü durumu	Site yeterli ziyaret aldığında; yeni ya da az ziyaret alan sitede “Veri yok” görülebilir
PageSpeed Insights, üst bölüm	Saha (CrUX), önceki 28 gün, 75. yüzdelik	Tek URL ya da tüm kaynak (origin) için LCP, INP, CLS, FCP, TTFB	Tek bir sayfanın gerçek kullanıcı durumunu görmek için
PageSpeed Insights alt bölüm ve Lighthouse	Laboratuvar: benzetilmiş cihaz ve ağ	LCP, CLS, TBT, FCP, Speed Index ve nedenleri (LCP parçaları, uzun görevler, aktarım boyutu)	Teşhis ve düzeltme öncesi/sonrası karşılaştırma
Tarayıcıda PerformanceObserver	Laboratuvar: gerçek tarayıcı, kısıtlamasız	LCP, CLS olayları	Belirli bir ayarın (ör. hareket azaltma) etkisini ölçmek için

CrUX’a girmek için sayfanın herkese açık ve dizine eklenebilir olması ve yeterince ziyaretçi alması gerekir; Google bu ziyaretçi eşiğini açıklamaz. PageSpeed Insights belgesine göre URL için yeterli veri yoksa kaynak düzeyindeki veri gösterilir, o da yoksa saha verisi hiç gösterilmez. Saha verisinin gerçek bir örneği ailevegitim.com’dan: PageSpeed Insights 18 Ekim 2026 04:33 raporunda sitenin ana sayfası mobilde Önemli Web Verileri Değerlendirmesi’ni geçti (LCP 1,2 sn, INP 156 ms, CLS 0, FCP 1,1 sn, TTFB 0,6 sn; son 28 gün); aynı raporun masaüstü sekmesinde ise “Veri Yok” yazıyordu. Aynı sitede mobil kullanıcı verisinin yetip masaüstününkinin yetmemesi, saha verisinin cihaz türüne göre ayrı biriktiğini gösterir. Sitenin genel seyri eğitim sitesi SEO vaka çalışmasında.

yademreklam.com için saha verisi bu sayfada yok: PageSpeed Insights API’si 17 Ekim 23:10 ve 18 Ekim 04:31 denemelerinde anahtarsız günlük kota hatası (HTTP 429) döndürdü. Search Console kaydı: Önemli Web Verileri raporu 18 Ekim 2026’da mobil ve masaüstü için aynı şeyi gösteriyordu: son 90 günde bu cihaz türü için yeterli kullanım verisi yok (site 17 Ekim 2026’da yayına girdi). Bu yüzden aşağıdaki sonuçların tamamı laboratuvar ölçümüdür; site 17 Ekim 2026’da yayına girdi.

Core Web Vitals eşikleri nedir, laboratuvar sonucu nasıl okunur?

Core Web Vitals’ın üç metriği için iyi eşik, 75. yüzdelikte LCP için en fazla 2,5 saniye, INP için en fazla 200 milisaniye ve CLS için en fazla 0,1’dir; Search Console bir URL grubunun durumunu üç metriğin en kötüsüne göre belirler. Search Console’un Türkçe yardım sayfasındaki eşikler şöyledir:

Metrik	Neyi ölçer	İyi	İyileştirme gerektiriyor	Kötü
LCP (Largest Contentful Paint)	Görünür alandaki en büyük öğenin boyanma zamanı	≤ 2,5 sn	≤ 4 sn	> 4 sn
INP (Interaction to Next Paint)	Tıklama ve dokunmalara yanıt gecikmesi	≤ 200 ms	≤ 500 ms	> 500 ms
CLS (Cumulative Layout Shift)	Beklenmedik yerleşim kaymaları	≤ 0,1	≤ 0,25	> 0,25

Laboratuvar sonucu okunurken üç kural vardır. Birincisi, Lighthouse sayfayı kullanıcı etkileşimi olmadan yüklediği için INP ölçemez; web.dev belgesine göre laboratuvardaki vekil gösterge Total Blocking Time’dır (TBT). Lighthouse TBT için mobilde 200 ms’ye kadar yeşil, 200–600 ms turuncu, 600 ms üstü kırmızı sınıf kullanır; masaüstünde sınırlar 150 ve 350 ms’dir. İkincisi, Lighthouse’un mobil ön ayarı orta seviye bir cihazı mobil ağda benzetir; bizim koşularımızda yapılandırma 150 ms gidiş-dönüş süresi, yaklaşık 1,6 Mb/sn indirme hızı ve 4 kat yavaşlatılmış işlemciydi, masaüstünde 40 ms, yaklaşık 10 Mb/sn ve yavaşlatmasız işlemci. Üçüncüsü, sonuç koşudan koşuya değişir: Lighthouse belgesi beş koşunun medyanını almayı önerir ve beş koşunun medyanının tek koşudan iki kat daha kararlı olduğunu yazar; aynı makinede aynı anda birden çok Lighthouse raporu toplanmamalıdır. Performans puanı ise bir Core Web Vitals metriği değil, Lighthouse’un beş ölçümden hesapladığı ağırlıklı özettir (Lighthouse 10 belgesine göre TBT %30, LCP ve CLS %25’er, FCP ve Speed Index %10’ar).

yademreklam.com'da tekrarlı ölçüm ne gösterdi?

yademreklam.com’da 18 Ekim 2026’daki 40 koşuluk seride mobil LCP medyanı dört sayfada 5,2–7,2 sn, masaüstünde 1,1–1,4 sn çıktı; CLS medyanı her sayfada iyi eşiğin altındaydı, TBT medyanı mobilde 548–582 ms arasındaydı. Ölçüm, dört sayfayı mobil ve masaüstü ön ayarında beşer kez Lighthouse 12.8.2 ile ölçerek yapıldı (Chrome 155.0.8059.80, Windows 11, 11. nesil Intel Core i5, 24 GB bellek; her seriden önce bir ısınma isteği, koşular sırayla). Tabloda medyan ve parantez içinde en küçük–en büyük değer var:

Sayfa	Ön ayar	Performans puanı	LCP	CLS	TBT	FCP
Ana sayfa	Mobil	55 (48–60)	7,2 sn (4,2–8,0 sn)	0 (0–0,279)	582 ms (480–766 ms)	2,3 sn
Ana sayfa	Masaüstü	95 (94–95)	1,4 sn (1,4–1,5 sn)	0,009 (0,009–0,009)	21 ms (0–34 ms)	0,5 sn
SEO hizmeti sayfası	Mobil	65 (42–66)	5,2 sn (5,1–6,6 sn)	0 (0–0)	548 ms (516–1.518 ms)	2,2 sn
SEO hizmeti sayfası	Masaüstü	98 (96–98)	1,1 sn (1,1–1,3 sn)	0 (0–0)	18 ms (8–43 ms)	0,5 sn
Maliyet hesaplayıcı	Mobil	64 (63–66)	5,2 sn (5,1–5,5 sn)	0 (0–0)	567 ms (419–592 ms)	2,1 sn
Maliyet hesaplayıcı	Masaüstü	98 (95–98)	1,1 sn (1,1–1,2 sn)	0 (0–0)	34 ms (30–127 ms)	0,5 sn
AI reklam filmi sayfası	Mobil	60 (56–61)	6,3 sn (4,1–6,3 sn)	0 (0–0)	581 ms (575–1.386 ms)	2,2 sn
AI reklam filmi sayfası	Masaüstü	96 (92–96)	1,3 sn (1,3–1,4 sn)	0 (0–0)	63 ms (24–154 ms)	0,5 sn

Tablodan dört gözlem çıkıyor. Masaüstünde dört sayfanın puan medyanı 95–98, mobilde 55–65; fark, mobil ön ayarın yavaş ağ ve işlemci benzetiminden geliyor. Mobil LCP, laboratuvar değeri eşikle karşılaştırıldığında dört sayfada da Kötü sınıfına düşüyor; bu sonuç gerçek kullanıcı değerlendirmesi değildir ama ilk düzeltilecek metriği gösterir. Ana sayfanın mobil serisinde beş koşudan birinde CLS 0,279 çıktı ve aynı koşuda LCP öğesi H1 yerine giriş paragrafı oldu; medyan (0) bu kaymayı gizliyor, bu yüzden aralığa da bakmak gerekir. Video sayfası en ağır ikinci sayfa olmasına rağmen CLS’si 0 kaldı.

Aynı makinede yaklaşık beş saat arayla alınan iki seri (17 Ekim 22:51 ve 18 Ekim 03:46), laboratuvar ölçümünün neden tek başına karşılaştırılamayacağını da gösteriyor. Lighthouse’un benzetilmiş kısıtlaması işlemci yavaşlatmasını ölçüm yapılan makineye göre uygular ve makinenin hızını benchmarkIndex değeriyle raporlar:

Ölçüt	LCP 17 Ekim	LCP 18 Ekim	TBT 17 Ekim	TBT 18 Ekim
Ana sayfa (mobil)	7,7 sn	7,2 sn	252 ms	582 ms
SEO hizmeti sayfası (mobil)	6,0 sn	5,2 sn	616 ms	548 ms
Maliyet hesaplayıcı (mobil)	5,6 sn	5,2 sn	402 ms	567 ms
Makine hızı (benchmarkIndex medyanı, tüm koşular)	17 Ekim: 1.625		18 Ekim: 1.100

Ortak üç sayfanın mobil LCP medyanı iki seri arasında 0,4–0,8 sn oynadı, TBT ise çok daha fazla değişti; 18 Ekim serisinde makinenin benchmarkIndex medyanı yaklaşık üçte bir düşüktü. Lighthouse’un kısıtlama belgesi, bu değer beklenen aralığın dışındaysa işlemci çarpanının ayarlanmasını önerir. Pratik sonuç: bir düzeltmenin etkisini aynı makinede, aynı ön ayarla, yakın zamanda alınmış iki seriyle ve benchmarkIndex’i de yazarak karşılaştırın. Ölçülen sayfalar: SEO hizmeti, maliyet hesaplayıcı ve AI reklam filmi sayfaları ile ana sayfa.

Mobilde LCP neden yavaş? LCP parçaları nasıl okunur?

Mobilde LCP’yi en çok uzatan parça öğe boyama gecikmesidir: dört sayfanın mobil serisinde ilk baytın gelmesi (TTFB) 73–220 ms sürerken LCP öğesinin hazır olduğu hâlde ekrana çizilmesini bekleme süresi 671–961 ms arasındaydı. web.dev belgesi LCP’yi dört parçaya ayırır: TTFB, kaynak yükleme gecikmesi, kaynak yükleme süresi ve öğe boyama gecikmesi. Lighthouse 12’nin LCP dökümüne göre medyan değerler:

Sayfa (mobil)	LCP öğesi	TTFB	Kaynak yükleme gecikmesi	Kaynak yükleme süresi	Öğe boyama gecikmesi
Ana sayfa	H1 başlığı (5 koşunun 4’ünde)	74 ms	—	—	961 ms
SEO hizmeti sayfası	Sayfa görseli	73 ms	29 ms	116 ms	673 ms
Maliyet hesaplayıcı	Sayfa görseli	77 ms	28 ms	122 ms	671 ms
AI reklam filmi sayfası	Sayfa görseli	220 ms	31 ms	202 ms	762 ms

Bu parçalar Lighthouse’un kısıtlamasız gözlenen yüklemesinden gelir; benzetilmiş LCP değeriyle toplanmaz. Lighthouse önce sayfayı kısıtlamasız yükler, sonra kısıtlı koşulları bu gözleme göre benzetir; bu yüzden parçaların oranı yorumlanır, toplamı değil. Oran açık: sunucu hızlı yanıt veriyor (LiteSpeed önbelleği), görseller hızlı iniyor, bekleme ise tarayıcının öğeyi çizmeye hazır olmasında. web.dev, öğe boyama gecikmesinin nedenleri olarak head bölümünde hâlâ yüklenen render engelleyici stil dosyalarını ve betikleri, öğeyi gizleyen kodu ve ana iş parçacığını tutan uzun görevleri sayar. yademreklam.com’da Lighthouse iki render engelleyici stil dosyası (style.css ve hareket.css) raporladı; mobilde en uzun görev 596–756 ms sürdü ve Lighthouse bu görevi sayfanın HTML belgesine atfetti; onu Google Analytics betiğinin (gtag.js, 176 KB) görevleri izledi. Aktarım dökümü:

Sayfa (mobil)	Toplam aktarım	İstek	Görsel	Yazı tipi	gtag.js	En uzun görev
Ana sayfa	1.280 KB	33	667 KB	331 KB	176 KB	756 ms
SEO hizmeti sayfası	705 KB	21	105 KB	318 KB	176 KB	687 ms
Maliyet hesaplayıcı	722 KB	21	117 KB	318 KB	176 KB	596 ms
AI reklam filmi sayfası	932 KB	27	323 KB	318 KB	176 KB	648 ms

Tabloda yazı tiplerinin payı dikkat çekiyor. Temada altı @font-face tanımı var ve Türkçedeki ğ, ş ve İ harfleri Latin Extended aralığında (U+0100–02BA) kalıyor; bu yüzden ana sayfanın mobil koşusunda altı yazı tipi dosyasının altısı da indi, bunların üçü latin-ext dosyasıydı (Unbounded 116 KB, Inter 83 KB, Instrument Serif 12 KB). Önceden yükleme (preload) ise yalnız iki latin dosyası için yapılmış. Bu durumun LCP’ye etkisini ayrıca ölçmedik. LCP görseli ise doğru işaretlenmiş: sayfa görselinde fetchpriority=”high”, genişlik ve yükseklik öznitelikleri ilk HTML’de var. WordPress 6.3’ten beri çekirdek, LCP olma olasılığı en yüksek içerik görseline bu özniteliği kendisi ekler ve ilk görünümdeki görselleri tembel yüklemeden çıkarmaya çalışır.

Videolu WordPress sayfasında Core Web Vitals'ı ne etkiler?

Videolu bir WordPress sayfasında ilk kontrol, video dosyasının ilk yüklemede inip inmediğidir; video yerinde bir kapak görseli duruyor ve oynatıcı yalnız tıklanınca yükleniyorsa video, ilk yüklemenin aktarımına ve LCP adaylarına eklenmez. yademreklam.com’un AI reklam filmi sayfasında beş kendi barındırdığı video ve bir YouTube videosu var. Videolar preload="none", kapak görseli (poster) ve sessiz önizleme döngüsüyle yerleştiriliyor; YouTube videosu yerinde yalnız küçük resim (genişlik ve yükseklik belirtilmiş) duruyor ve oynatıcı tıklanınca yükleniyor.

Ölçüm bu düzenin işe yaradığını gösteriyor: video sayfasının 10 koşusunun hiçbirinde .mp4 dosyası indirilmedi, YouTube’dan yalnız küçük resim (hqdefault.jpg) istendi ve oynatıcı betiği yüklenmedi. Sayfanın mobil toplam aktarımı 932 KB, CLS’si beş koşunun beşinde 0’dı. Video sayfasının mobil LCP medyanı (6,3 sn) SEO hizmeti sayfasından (5,2 sn) yüksek; LCP öğesi iki sayfada da sayfanın üstündeki görsel; videolar ilk yüklemede inmediği için farkın nedeni sayfa görselinin boyutu ya da sunucu yanıtı olabilir (video sayfasında sunucu yanıtı medyanı 155 ms, diğer sayfalarda 17–24 ms); hangisi olduğu bu ölçümle ayrılmadı.

Web sitesindeki videonun arama tarafı, yani yapısal veri, kapak ve dizine ekleme, web sitesi video SEO sayfasının konusudur; VideoObject işaretlemesini kontrol etmek için VideoObject schema oluşturucu aracını kullanabilirsiniz.

WordPress'te Core Web Vitals için ilk ne düzeltilir?

Sırayı ölçülen veri belirler: önce kullanıcıyı en çok etkileyen ve en kesin ölçülen sorun, sonra en büyük süre payı. yademreklam.com’un kayıtlarına göre sıra şöyle; hiçbir düzeltmenin etkisi henüz ölçülmedi, her madde bir sonraki ölçüm serisinde doğrulanacak.

1. Ana sayfadaki ara sıra büyük kayma. Mobil serinin bir koşusunda CLS 0,279 (Kötü sınırı 0,25’in üstü) ve Lighthouse kaymanın öğesini belirleyemedi. 17 Ekim’de kısıtlamasız gerçek tarayıcıda yapılan hareket deneyi de aynı işareti verdi: yedişer koşuda ana sayfanın tipik CLS’si hareket açıkken 0,003, sistemde “hareketi azalt” tercihi açıkken 0,055 idi; hareket açıkken iki koşuda 0,089, hareket azaltılmışken iki koşuda 0,249 değerine çıktı. CLS’nin yükseldiği her koşuda LCP öğesi H1 değil, animasyonlu giriş paragrafıydı (yd-fade sınıfı). Kaymayı Chrome DevTools’un Performans panelindeki Layout Shift kayıtlarıyla bulmak ilk iştir.
2. Öğe boyama gecikmesi. İki render engelleyici stil dosyasından animasyona ait olanı (hareket.css) ilk boyamayı beklemeyecek şekilde yüklemek ve ilk ekran için gereken stili küçük tutmak, LCP’nin en büyük parçasını hedefler.
3. Uzun görevler ve TBT. Sayfa belgesine atfedilen en uzun görev ile gtag.js görevleri mobil TBT’yi 548–582 ms aralığında tutuyor. Animasyon kurulumunu ilk boyamadan sonraya almak ve ölçüm betiğini geciktirmek denenecek ilk iki adımdır.
4. Yazı tipleri. Türkçe başlıklar latin-ext dosyalarını da indiriyor; hangi yazı tipinin LCP öğesinde kullanıldığına bakıp yalnız onu önceden yüklemek ya da alt kümeyi daraltmak ölçülerek denenmeli.

Her düzeltmeden sonra aynı seri yeniden alınır: aynı dört sayfa, aynı iki ön ayar, beşer koşu, benchmarkIndex kaydıyla. Tek koşuluk fark sonuç sayılmaz; saha verisi oluştuğunda değerlendirme Search Console’dan yapılır. Hangi teknik sorunun önce ele alınacağına karar vermek için SEO hataları önceliklendirme yöntemi, JavaScript’in arayüze etkisi için JavaScript SEO sayfası, temel WordPress ayarları için WordPress SEO ayarları sayfası kullanılabilir. Genel teknik kontrol listesi teknik SEO rehberinde; bu ölçümü sitenizde yapmamızı isterseniz SEO hizmeti kapsamında teknik denetim olarak teklif veriyoruz.

Sık sorulan sorular