Core Web Vitals

TL;DR — Core Web Vitals, Google’ın bir sayfanın gerçek kullanıcılar için nasıl hissettiğini ölçmekte kullandığı üç puandır: ne kadar hızlı yüklendiği (LCP), dokunduğunuzda veya tıkladığınızda ne kadar hızlı yanıt verdiği (INP) ve yüklenirken öğelerin ne kadar sıçradığı (CLS). “İyi”, LCP’nin 2,5 saniyenin, INP’nin 200 milisaniyenin ve CLS’nin 0,1’in altında olmasıdır. Sıralamaları biraz etkilerler — ancak iyi içerik çok daha önemlidir.

Core Web Vitals nedir

Google, kullanımı keyifli sayfaları ödüllendirmek istediği için “iyi sayfa deneyimi”ni ölçülebilir üç unsura indirdi. Bunların tümüne birlikte Core Web Vitals (çoğu zaman CWV olarak kısaltılır) denir:

• Largest Contentful Paint (LCP) — yükleme. Ekrandaki en büyük şeyin (genellikle bir hero görseli veya başlık) görünmesinin ne kadar sürdüğü. İyi değer ≤ 2,5 saniyedir.
• Interaction to Next Paint (INP) — yanıt verme. Bir düğmeye dokunduğunuzda veya yazdığınızda sayfanın tepki vermesine kadar geçen süre. İyi değer ≤ 200 milisaniyedir.
• Cumulative Layout Shift (CLS) — görsel kararlılık. Yüklenirken sayfanın ne kadar sıçradığı (tam dokunmaya giderken bir reklamın metni aşağı itmesi gibi). İyi değer ≤ 0,1’dir.

Puanlar nereden gelir

Google’ın gerçekten kullandığı puanlar, yaptığınız bir testten değil, Chrome’da sitenizi ziyaret eden gerçek kişilerden gelir. Google bu verileri toplar ve bir sayfa, ziyaretçilerin %75’inin yaşadığı deneyime göre değerlendirilir. Bu nedenle kendi makinenizde tek bir hızlı sonuç alarak “geçemezsiniz”; gerçek ziyaretçilerinizin çoğunun iyi bir deneyim yaşaması gerekir. Evidence for this claim Core Web Vitals are real-world experience metrics used by Google ranking systems; lab measurements are diagnostic and can differ from field measurements. Scope: Google Search use of Core Web Vitals and Chrome UX Report field data. Confidence: high · Verified: 2026-07-14 Google: Core Web Vitals and Search web.dev: Lab and field data

Bu yüzden hız testi aracında kusursuz bir puan almanız geçeceğinizi garanti etmez. PageSpeed Insights ve Lighthouse gibi araçlar, simüle edilmiş bir telefonda tek bir laboratuvar testi çalıştırır — sorunları bulmak için harikadırlar, ancak Google’ın sıralama yaptığı sayılar bunlar değildir.

Sıralamaları etkiler mi?

Bir miktar. Google, Core Web Vitals’ın sıralama sistemleri tarafından kullanıldığını söylüyor — ancak bunlara bağlanmış resmi bir ağırlık veya yüzde yok ve Google, alakalı içeriğin sayfa deneyimi yetersiz bir sayfayı yine de geçebileceğini açıkça belirtiyor. İçeriğiniz alakalı değilse hızlı ve kararlı olması sizi kurtarmaz. Google’dan John Mueller’ın ifadesiyle, “it’s not going to make your site’s rankings jump up.”

Yıllardır bu işle uğraştıktan sonraki dürüst görüşüm şu: çoğu site bu sayıları kovalamaktan büyük bir sıralama faydası görmez. Ancak sitenizi daha hızlı ve kararlı hâle getirmenin yanlış bir tarafı yok — ziyaretçiler bunu fark eder ve sıralamaları değiştirmese bile dönüşümlere yardımcı olur.

İnsanların yanlış anladığı bir nokta

Eski ad uyarısı: FID (First Input Delay) ifadesini hâlâ bir Core Web Vital olarak görebilirsiniz. Artık yok — INP, 12 Mart 2024’te FID’in yerini aldı. Bir araç veya makale hâlâ size FID’i optimize etmenizi söylüyorsa güncel değildir.

Kesin eşikleri, saha ve laboratuvar verileri arasındaki farkı, sıralamadaki gerçek ağırlığını ve hangi aracın ne zaman kullanılacağını ele alan daha ayrıntılı sürümü mü istiyorsunuz? Gelişmiş sekmesine geçin.

TL;DR — Core Web Vitals, LCP (yükleme, “iyi” ≤ 2,5 s), INP (yanıt verme, ≤ 200 ms) ve CLS (görsel kararlılık, ≤ 0,1) olmak üzere sahada ölçülen üç UX metriğidir; her biri gerçek Chrome kullanıcılarının (CrUX) hareketli 28 günlük bir dönem içindeki 75. yüzdelik diliminde değerlendirilir. Eşikler mobil ve masaüstü için aynıdır, ancak Google her birini ayrı değerlendirir ve yalnızca birinin değil üç metriğin tamamının iyi olmasını bekler. INP, 12 Mart 2024’te FID’in yerini aldı. Google, sıralama sistemlerinin Core Web Vitals’ı kullandığını söylüyor, ancak buna bağlanmış resmi bir ağırlık veya “tiebreaker” yüzdesi yok — iyi puan daha iyi sıralamayı garanti etmez ve alaka hâlâ kazanabilir. Laboratuvar puanları (Lighthouse/PSI) tanı amaçlı ölçümlerdir ve çoğu zaman saha verileriyle örtüşmez. TTFB ve FCP tanı amaçlı “diğer Web Vitals” metrikleridir; TBT ve Speed Index laboratuvar vekilleridir.

Core Web Vital sayılanlar

Google, Core Web Vitals’ı “the subset of Web Vitals that apply to all web pages, should be measured by all site owners, and will be surfaced across all Google tools.” olarak tanımlar. Her biri bir sayfanın nasıl hissettirdiğinin farklı bir boyutunu ölçen tam üç metrik vardır:

Google üç “iyi” eşiği 75. yüzdelik dilimde değerlendirir: LCP 2,5 saniye, INP 200 milisaniye ve CLS 0,1. Bir sayfa genel olarak ancak üçünün tamamı p75’te kendi eşiğini geçtiğinde “iyi” sayılır — yalnızca biri veya ikisi yetmez. Eşiklerin kendisi mobil ve masaüstünde aynıdır; ancak Google her cihaz sınıfını ayrı değerlendirir ve raporlar. Evidence for this claim Core Web Vitals are assessed at the 75th percentile, with good thresholds of 2.5 seconds for LCP, 200 milliseconds for INP, and 0.1 for CLS. Scope: Current stable Core Web Vitals definitions from the Chrome team. Confidence: high · Verified: 2026-07-14 web.dev: Web Vitals

TTFB, FCP, TBT ve Speed Index gibi duyduğunuz diğer her şey Core Web Vital değildir. Bunları aşağıda daha ayrıntılı ele alacağız.

LCP — yükleme

LCP, “reports the render time of the largest image, text block, or video visible in the viewport, relative to when the user first navigated to the page.” Bir başka deyişle LCP öğesi genellikle bir ana görsel, büyük bir arka plan görseli veya başlık bloğudur. En büyük görünür öğe olduğunu unutmayın — farklı görüntü alanı boyutlarında farklı LCP öğeleri bulunabilir; saha ve laboratuvar sayılarının ayrışmasının nedenlerinden biri budur.

INP — yanıt verme

INP, “assesses a page’s overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user’s visit to a page.” ifadesindeki gibi, kullanıcı etkileşimlerine karşı sayfanın genel yanıt verebilirliğini değerlendirir. Etkileşimin tamamını ölçer: giriş gecikmesi → olay işleyicisinin işlenmesi → sonraki karenin boyanma süresi.

Bu, yerini aldığı metriğe göre büyük bir iyileştirmedir. INP, yalnızca ilk etkileşimi gözlemleyen FID’in aksine tüm etkileşimleri gözlemleyerek FID’i geliştirir — FID yalnızca ilk etkileşimin giriş gecikmesini ölçüyordu. INP, 12 Mart 2024’te First Input Delay’in (FID) yerini alarak Core Web Vital oldu. Evidence for this claim INP became a Core Web Vital and replaced FID on March 12, 2024. Scope: Chrome and Google tooling transition from FID to INP. Confidence: high · Verified: 2026-07-14 web.dev: INP launch FID aynı gün Search Console’dan kaldırıldı. Artık tamamen emekli edildi — onu optimize etmeyin.

Akılda tutulması gereken bir nüans: INP, tek bir etkileşimin en kötüsü değildir; tüm etkileşimlerin yüksek bir yüzdelik dilimidir. Tek bir takılan tıklama, normalde iyi olan bir sayfayı batırmaz.

CLS — görsel kararlılık

CLS, “is a measure of the largest burst of layout shift scores for every unexpected layout shift that occurs during the entire lifecycle of a page.” ifadesindeki gibi, bir sayfanın tüm yaşam döngüsü boyunca gerçekleşen beklenmedik her düzen kaymasının puanlarındaki en büyük kümeyi ölçer. “Küme” (oturum penceresi), birbiriyle 1 saniye içinde gerçekleşen kaymaları toplamda en fazla 5 saniyelik bir pencerede gruplar. Google’ın belirttiği olağan nedenler şunlardır: “images or videos with unknown dimensions,” “fonts that render larger or smaller than its initial fallback,” ve “third-party ads or widgets that dynamically resize themselves.”

Saha verileri ve laboratuvar verileri — ölçüm ve tanı

En çok kafa karışıklığına yol açan ayrım budur; bu nedenle kesin konuşalım.

• Saha verileri (CrUX), “data collected from the real users visiting your site.” olarak tanımlanır. Hareketli 28 günlük bir dönem boyunca mobil ve masaüstü segmentlerinde, 75. yüzdelik dilimde raporlanır. Core Web Vitals bu tür gerçek dünya deneyimini temsil eder ve Google’ın sıralama sistemleri tarafından kullanılır. Gerçek cihazları, ağları, önbellek durumlarını ve geri/ileri önbelleğini yansıtır.
• Laboratuvar verileri, “data collected in a controlled environment with predefined device and network settings” — tek bir emüle edilmiş telefon, soğuk önbellek ve gerçek kullanıcı yok — olarak tanımlanır. Lighthouse ve PageSpeed Insights’ın laboratuvar bölümü bunu üretir. Bu, saha ölçümü değil, sorunları bulmaya yarayan bir tanı aracıdır. Evidence for this claim Core Web Vitals are real-world experience metrics used by Google ranking systems; lab measurements are diagnostic and can differ from field measurements. Scope: Google Search use of Core Web Vitals and Chrome UX Report field data. Confidence: high · Verified: 2026-07-14 Google: Core Web Vitals and Search web.dev: Lab and field data

Google’ın kendi yönlendirmesi şöyledir: “If you have both field data and lab data for a given page, field data is what you should use to prioritize your efforts.” Ayrıca Lighthouse’ın Performance Score’u “often does not correlate with field Core Web Vitals.” Ben de Core Web Vitals rehberimde aynı şeyi söylüyorum: saha CWV verileri 28 günlük hareketli bir ortalama olduğu için laboratuvar verileri test etmek ve yinelemek için daha kullanışlıdır — yaptığınız düzeltmenin yansımasını haftalarca göremezsiniz.

p75 kuralı ve neden önemli olduğu

Bir sayfa yalnızca gerçek kullanıcıların %75’i “iyi” eşiğine ulaştığında geçer. Bu, kasıtlı olarak hoşgörülü ama gerçekçi bir çıtadır: ziyaretçilerinizin çoğu (4 kişiden 3’ü) iyi bir deneyim yaşamıştır ve siz kötü bağlantılardaki birkaç aykırı değer yüzünden rehin kalmazsınız. Telefonunuzda 1,8 saniyelik bir yükleme görmenizin tek başına hiçbir anlam ifade etmemesinin nedeni de budur — önemli olan herkes üzerindeki p75 değerinizdir.

Sayfa düzeyi ve kaynak düzeyi — yanıltılmayın

Birçok araç varsayılan olarak kaynak düzeyi (tüm site ortalaması) puanını gösterir; bu, tek tek sayfalarınızdan çok daha pembe olabilir. CWV veri çalışmamda (Ahrefs Site Audit’ten CrUX ve 5,2 milyon sayfa), tek tek sayfaların yalnızca %21,2’si üç eşiğin tamamını geçerken kaynak düzeyinde bu oran %33 idi. Google’ın sayfa deneyimi belgeleri, sistemlerinin genellikle sayfaları tek tek değerlendirdiğini; ancak daha geniş site geneli değerlendirmeleri de yaptığını söylüyor — bu nedenle “geçen” bir kaynak, başarısız birçok tekil sayfayı gizleyebilir. Bir araç her iki görünümü de sunuyorsa kaynak düzeyi ortalamanın belirli bir sayfanın ne yaptığını gösterdiğini varsaymayın; sayfa düzeyi sayıyı da kontrol edin.

Bununla ilişkili bir tuzak daha var: yeterli trafiği olmayan sayfalarda hiç CrUX saha verisi bulunmaz ve CrUX yalnızca kullanım istatistiklerini paylaşmayı seçmiş Chrome kullanıcılarını kapsar (iOS Chrome yoktur, diğer tarayıcılar da yoktur). Bu bir veri uygunluğu açığıdır, başarısızlık değildir — eksik saha verisi düşük puanla aynı şey değildir. Belirli bir aracın benzer sayfaları nasıl grupladığı veya trafiği düşük URL’ler için nasıl geri dönüş yaptığı (PSI, Search Console, CrUX API), tek bir evrensel kuralla değil, o ürünün kendi belgeleriyle açıklanır.

Core Web Vitals sıralama için gerçekte ne kadar önemli?

Bunlar doğrulanmış bir sıralama sinyalidir — Google, sıralama sistemlerinin Core Web Vitals’ı kullandığını söylüyor. Ancak Google’ın güncel belgeleri bu sinyale resmî bir ağırlık, yüzde veya “eşitlik bozucu” etiketi vermez; dolayısıyla bu nitelemeleri Google’ın kendi ifadeleriymiş gibi tekrarlarken dikkatli olun.

“Gerçek” olduğunu savunan tarafta Google’ın belgeleri, Core Web Vitals’ın “along with other page experience aspects, aligns with what our core ranking systems seek to reward,” olduğunu söylüyor; John Mueller da bunun “more than a tie-breaker, but it also doesn’t replace relevance.” olduğunu açıkça belirtti.

“Abartmayın” tarafında ise Mueller, “Core Web Vitals are not giant factors in ranking, and I doubt you’d see a big drop just because of that,” dedi; Mart 2024’teki belge güncellemesinde LinkedIn üzerinden “it’s not going to make your site’s rankings jump up.” sözlerini ekledi. Google’ın kendi sayfa deneyimi belgeleri açık konuşuyor: “Google Search always seeks to show the most relevant content, even if the page experience is sub-par.” 2024 belgeleri ayrıca “trying to get a perfect score just for SEO reasons may not be the best use of your time.” uyarısını yapıyor. Evidence for this claim Google says Core Web Vitals are used by ranking systems, while page experience does not override more relevant content. Scope: Google Search ranking guidance; no fixed weight or ranking-position effect is promised. Confidence: high · Verified: 2026-07-14 Google: Core Web Vitals and Search Google: Page experience

Pratik yorumum şu: alaka baskın gelir, Google CWV’nin ne kadar ağırlığı olduğunu bir sayıya bağlamadı ve çoğu site bunlar üzerinde sıralamalar için çalışmaktan büyük fayda görmez. Bununla birlikte, temel UX iyileştirmeleri kullanıcılar ve dönüşümler için değerlidir — ayrıca platformlar (WordPress, Cloudflare, framework’ler) optimizasyon yükünün büyük bölümünü otomatik olarak üstlenmeye devam ediyor. Özellikle küçük ve yerel işletmeler için bu konu genellikle listenin en üstünde olmamalıdır.

2024 güncellemesinden bir açıklama daha: daha geniş sayfa deneyimi sinyalleri arasından yalnızca Core Web Vitals’ın sıralamaya doğrudan katkı yaptığı doğrulandı. HTTPS, mobil uyumluluk, rahatsız edici geçiş reklamlarının olmaması ve içerik açıklığı iyi uygulamalardır; ancak belgelerin bir zamanlar ima ettiği gibi sıralamayı doğrudan yükseltmezler.

”Diğer Web Vitals” — temel metrikler değil, tanı araçları

Bunlarla sürekli karşılaşılır ve kategorileri sık sık yanlış sınıflandırılır. Hiçbiri Core Web Vitals değildir:

• Time to First Byte (TTFB) — yanıtın ilk baytının gelmesine kadar geçen süre. “precedes every other meaningful loading performance metric” ve LCP’ye katkıda bulunur; ancak Google açıkça şunu söyler: “Because TTFB isn’t a Core Web Vitals metric, it’s not absolutely necessary that sites meet the ‘good’ TTFB threshold.” (İyi değer ≤ 0,8 s.) Tanı amaçlıdır.
• First Contentful Paint (FCP) — herhangi bir içeriğin boyanmasına kadar geçen süre. Yararlı bir yükleme tanısıdır (iyi değer ≤ 1,8 s), ancak Core değildir.
• Total Blocking Time (TBT) — INP için laboratuvar vekili. Lighthouse gibi araçlar gerçek bir kullanıcı olmadan “cannot measure INP”, bu nedenle bunun yerine TBT raporlar. Yalnızca laboratuvar içindir.
• Speed Index — algılanan yükleme hızı için laboratuvar vekili. Yalnızca Lighthouse’a özgüdür.

Bunları hata ayıklamak için kullanın. Core Web Vitals olarak raporlamayın veya eşiklerini sıralama kapısı olarak görmeyin.

Emekliye ayırılması gereken bir mit

“Engagement Reliability” ifadesinin yeni bir Core Web Vital olarak ortaya atıldığını görebilirsiniz. Böyle bir metrik için resmî bir Google duyurusu yok — yalnızca üçüncü taraf içeriklerde dolaşıyor. Core Web Vitals, LCP, INP ve CLS’dir. Google aksini söyleyene kadar liste budur.

Nasıl ölçülür — hangi araç ne için kullanılır

Aracı işe göre eşleştirin:

• Sıralamayla ilgili (saha verileri): PageSpeed Insights (sayfa ve kaynak düzeyinde CrUX saha verilerini gösterir), Google Search Console’un Core Web Vitals raporu (benzer sayfaları gruplar ve site geneli örüntüleri ortaya çıkarır), CrUX API / BigQuery (özel ve ülke düzeyinde analiz) ve web-vitals JS kütüphanesi (kendi RUM verinizi toplamak için).
• Hata ayıklama (laboratuvar verileri): Lighthouse, Chrome DevTools Performance paneli ve PSI laboratuvar bölümü. Bunlar nedeni bulur; sıralamanıza karar vermez.

Önereceğim iş akışı şu: sahada hangi sayfa gruplarının başarısız olduğunu bulmak için GSC’yi kullanın, sayfa düzeyinde PageSpeed Insights ile doğrulayın, ardından tanı koyup yinelemek için Lighthouse / DevTools’a geçin — saha sayılarının güncellenmesinin 28 güne kadar sürebileceğini bilerek.

Sırada nereye gidilir: web performansı kümesi

Bu merkez, genel yol haritasını sunar. Aşağıdaki konuların her biri ayrı bir derinlemesine incelemedir.

Üç Core Web Vital

• Largest Contentful Paint — yükleme metriği: LCP öğesi sayılan şey, ≤2,5 s hedefi ve daha erken boyanmasının yolları.
• Interaction to Next Paint — FID’in yerini alan yanıt verme metriği: giriş gecikmesi, olay işleme ve sunum gecikmesi ile her birini azaltma yolları.
• Cumulative Layout Shift — görsel kararlılık metriği: oturum pencereleri, olağan nedenler (boyutlandırılmış medya, fontlar, eklenen reklamlar) ve ≤0,1 değerine ulaşma.

Destekleyici ve tanı amaçlı metrikler

• Time to First Byte — LCP’ye katkı yapan sunucu/yanıt gecikmesi; hata ayıklamak için yararlıdır, Core Web Vital değildir.
• First Contentful Paint — ilk içeriğin boyandığı an; bir yükleme tanısıdır.
• Total Blocking Time — Lighthouse’ın INP’yi yaklaşık olarak ölçmek için kullandığı laboratuvar vekilidir.
• Speed Index — algılanan yükleme hızı için laboratuvar vekilidir.

Nasıl ölçülür

• PageSpeed Insights — tek yerde saha (CrUX) verileri ve Lighthouse laboratuvar raporu.
• Google Lighthouse — PSI ve DevTools’un arkasındaki laboratuvar/tanı motoru.
• Chrome UX Report (CrUX) — Google’ın değerlendirmesinin dayandığı gerçek kullanıcı veri kümesi.

Kümenin tamamı için Web Performance merkezine bakın. Her kardeş sayfa yayımlandığında buraya otomatik olarak bağlantı verir.

AI özeti

Gelişmiş sürümün kısa özeti:

• Core Web Vitals = üç saha metriği: LCP (yükleme, iyi ≤ 2,5 s), INP (yanıt verme, ≤ 200 ms) ve CLS (görsel kararlılık, ≤ 0,1). Diğer her şey (TTFB, FCP, TBT, Speed Index) Core değildir.
• Saha verileriyle değerlendirilir: hareketli 28 günlük dönemde 75. yüzdelik dilimde gerçek Chrome kullanıcıları (CrUX). Eşikler mobil ve masaüstü için aynıdır ancak ayrı değerlendirilir; Google yalnızca birinin değil üç metriğin tamamının iyi olmasını bekler.
• INP, 12 Mart 2024’te FID’in yerini aldı. FID tamamen emekli edildi; INP yalnızca ilk etkileşimi değil tüm etkileşimleri ölçer.
• Laboratuvar araçları (Lighthouse/PSI) tanı amaçlıdır, saha ölçümü değildir ve çoğu zaman saha CWV ile örtüşmez. Bunları nedenleri bulmak için kullanın; saha sayıları 28 güne kadar gecikir.
• Sayfa düzeyi ve kaynak düzeyi önemlidir: sayfaların yaklaşık %21,2’si, kaynakların yaklaşık %33’ü geçer (benim CWV çalışmam). Google sayfa düzeyini kullanır — kaynak ortalamaları başarısız sayfaları gizler.
• Sıralama ağırlığı: kullanılır ama ağırlıklandırılmamıştır. Google, sıralama sistemlerinin Core Web Vitals’ı kullandığını söylüyor; buna bağlanmış resmi bir yüzde veya “tiebreaker” etiketi yoktur. Alaka baskındır ve iyi puan sıralama garantisi değildir. Mueller: “not giant factors in ranking.” 2024 belgelerine göre yalnızca CWV (HTTPS, mobil uyumluluk ve geçiş reklamları değil) doğrudan katkıda bulunur.
• Atlanacak mit: “Engagement Reliability” doğrulanmış bir Core Web Vital değildir.
• Araçlar: saha = PSI, GSC CWV raporu, CrUX API, web-vitals.js; hata ayıklama = Lighthouse, DevTools, PSI laboratuvar bölümü.

Resmî belgeler

Google’ın birincil kaynak belgeleri.

web.dev (Chrome ekibi)

• Web Vitals — girişim, üç metrik, p75 kuralı ve TTFB/FCP’nin neden “diğer” Web Vitals olduğu.
• Largest Contentful Paint (LCP) — tanım, eşikler ve uygun LCP öğeleri.
• Interaction to Next Paint (INP) — tanım, eşikler ve giriş gecikmesi → işleme → sunum ayrımı.
• Cumulative Layout Shift (CLS) — tanım, oturum pencereleri ve yaygın nedenler.
• Core Web Vitals metrik eşiklerini tanımlama — her “iyi” eşiğin ve 75. yüzdelik dilimin neden seçildiği.
• Lab ve saha verileri arasındaki farklar — saha (CrUX) ve laboratuvar (Lighthouse) sayılarının neden ayrıştığı.
• Core Web Vitals iş akışları / araçları — hangi aracın saha ve laboratuvar verilerini raporladığı.
• INP, Core Web Vitals’a ilerliyor (Mayıs 2023) — INP’nin FID’in yerini alacağının duyurusu.
• Interaction to Next Paint resmen Core Web Vital oldu (12 Mart 2024) — lansman doğrulaması.
• TTFB ve FCP — tanı amaçlı “diğer Web Vitals”.

Google Search Central

• Core Web Vitals’ı ve Google arama sonuçlarını anlama — CWV’nin sıralamayla ilişkisi.
• Google arama sonuçlarında sayfa deneyimini anlama — daha geniş sayfa deneyimi resmi ve “alaka kazanır” çerçevesi.
• INP’yi Core Web Vitals’a tanıtma (Mayıs 2023) — Search Central duyurusu.

Chrome for Developers

• Chrome User Experience Report (CrUX) — gerçek kullanıcı veri kümesi, uygunluk ve 28 günlük dönem.

Kaynaktan alıntılar

Google’dan kayda geçmiş ifadeler. Her bağlantı, kaynak sayfadaki alıntı bölümüne atlayan bir derin bağlantıdır.

Google — Core Web Vitals nedir

• “Core Web Vitals are the subset of Web Vitals that apply to all web pages, should be measured by all site owners, and will be surfaced across all Google tools.” — Philip Walton, web.dev. Alıntıya git
• “LCP reports the render time of the largest image, text block, or video visible in the viewport, relative to when the user first navigated to the page.” — web.dev (LCP). Alıntıya git
• “INP is a metric that assesses a page’s overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user’s visit to a page.” — web.dev (INP). Alıntıya git
• “CLS is a measure of the largest burst of layout shift scores for every unexpected layout shift that occurs during the entire lifecycle of a page.” — web.dev (CLS). Alıntıya git

Google — INP’nin FID’in yerini alması

• “Interaction to Next Paint (INP) is now a stable Core Web Vital metric, replacing First Input Delay (FID).” — Rick Viscomi, web.dev (12 Mart 2024). Alıntıya git

Google — saha ve laboratuvar verileri ile sıralama

• “If you have both field data and lab data for a given page, field data is what you should use to prioritize your efforts.” — Philip Walton, web.dev. Alıntıya git
• “The Chrome User Experience Report (also known as the Chrome UX Report, or CrUX for short) is a dataset that reflects how real-world Chrome users experience popular destinations on the web.” — Chrome for Developers (CrUX belgeleri). Alıntıya git

Google’dan John Mueller

• “It is a ranking factor, and it’s more than a tie-breaker, but it also doesn’t replace relevance.” — Search Engine Journal aracılığıyla (Reddit, Ağustos 2021). Kapsamı oku
• “Core Web Vitals are not giant factors in ranking, and I doubt you’d see a big drop just because of that.” — Stan Ventures aracılığıyla (2024). Kapsamı oku

Core Web Vitals kontrol listesi

Doğru şeyi ölçtüğünüzü ve doğru sayfaları düzelttiğinizi doğrulamak için hızlı bir kontrol:

• Google’ın sıralama yaptığı metrikler için yalnızca bir laboratuvar puanını değil saha verilerini (CrUX) okuyorsunuz.
• Yalnızca kaynak düzeyi ortalamaya değil sayfa düzeyi sayılara bakıyorsunuz.
• Üçünün tamamı kontrol edildi: p75’te LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1.
• Mobil ve masaüstü ayrı ayrı inceleniyor (Google her birini değerlendirir).
• FID’i optimize etmiyorsunuz — 12 Mart 2024’te emekliye ayrıldı (INP’yi kullanın).
• GSC Core Web Vitals raporu tekil örnekler için değil, başarısız sayfa grupları için incelendi.
• Trafiği düşük sayfalarda hiç CrUX saha verisi bulunmayabileceğini anlıyorsunuz.
• Laboratuvar araçları (Lighthouse/PSI) geçer/kalır kapısı olarak değil, tanı koymak için kullanılıyor — kusursuz Performance Score’u beklemiyorsunuz.
• Saha düzeltmelerinin görünmesi için 28 güne kadar süre tanıyorsunuz.
• CWV’yi içerik alaka düzeyinin ve daha büyük SEO kazanımlarının önüne koymuyorsunuz.

Zihinsel modeller

1. Üç boyut, üç metrik. LCP = yükleme, INP = yanıt verme, CLS = görsel kararlılık. Bir sorunun hangi boyutta olduğunu adlandırabiliyorsanız hangi metriği (ve hangi derinlemesine incelemeyi) açacağınızı bilirsiniz.

2. Sıralama için saha, düzeltme için laboratuvar. Google, hareketli 28 günlük dönemde p75 düzeyindeki CrUX saha verilerini sıralama sistemlerinde kullanır. Lighthouse/PSI laboratuvar puanları nedenleri bulmaya yarar. Laboratuvar puanını asla sıralama ölçütünüz olarak görmeyin — bu puanlar çoğu zaman saha verileriyle örtüşmez.

3. Sayfa düzeyi kaynak düzeyini geçer. “Geçen” bir kaynak, başarısız sayfaları gizleyebilir. Google, elinde olduğunda sayfa düzeyi verileri kullanır. Bir araç ikisini de gösteriyorsa sayfa düzeyi görünüme güvenin.

4. Kullanılır ama ağırlıklandırılmaz. CWV, Google’ın hiçbir zaman resmi bir ağırlık bağlamadığı doğrulanmış bir sıralama sinyalidir — alaka hâlâ bunun önüne geçebilir. CWV’yi kullanıcılar ve dönüşümler için düzeltin; sıralamaların birden sıçramasını beklemeyin.

5. “Gerçekten Core mu?” testi. Yalnızca LCP, INP ve CLS Core Web Vitals’tır. TTFB ve FCP tanı amaçlıdır; TBT ve Speed Index laboratuvar vekilleridir. “Engagement Reliability” hiç doğrulanmış değildir.

Core Web Vitals — hızlı başvuru

Üç Core Web Vital (saha verisi, p75)

Tanı amaçlı metrikler — Core Web Vitals DEĞİL

Hızlı bilgiler

• Değerlendirme = CrUX saha verileri, 75. yüzdelik dilim, 28 günlük hareketli dönem, mobil ve masaüstü ayrı ayrı.
• INP, 12 Mart 2024’te FID’in yerini aldı. FID tamamen emekli edildi.
• Laboratuvar puanları tanı amaçlıdır, saha ölçümü değildir — ayrıca saha CWV ile çoğu zaman örtüşmez.
• Google’ın kullandığı şey sayfa düzeyidir; kaynak düzeyi ortalamalar yanıltabilir (benim CWV çalışmamda sayfaların yaklaşık %21,2’si geçerken kaynakların yaklaşık %33’ü geçer).
• Sıralama ağırlığı: Google’ın sıralama sistemleri tarafından kullanılır, resmi ağırlık belirtilmemiştir — alaka baskındır ve iyi puan garanti değildir.
• “Engagement Reliability” doğrulanmış bir Core Web Vital değildir.

İlk olarak hangi Core Web Vital’ı incelemeliyim?

Yayın sonrası Core Web Vitals geriliyor

1. Sinyali doğrulayın. Sahayı laboratuvardan, URL’yi kaynaktan ve mobil cihazı masaüstünden ayırın. Yalnızca bir laboratuvar çalışması değiştiyse olayı ilan etmeden önce yeniden üretin.
2. Başarısız metriği belirleyin. LCP, INP ve CLS farklı sorunları temsil eder. Birden fazlası değiştiyse önce ortak yayın değişikliklerini ve üçüncü taraf komut dosyalarını kontrol edin.
3. Gerilemeyi bir dağıtıma bağlayın. Yayından önceki ve sonraki RUM verilerini veya tekrarlanabilir laboratuvar izlerini karşılaştırın. Zamanlama uyuşmuyorsa bunun yerine trafik/cihaz karmasını inceleyin.
4. Puanı değil metriği tanılayın. LCP için öğeyi ve alt parçalarını inceleyin; INP için yavaş etkileşimleri ve ana iş parçacığı çalışmasını inceleyin; CLS için kayma kaynaklarını inceleyin.
5. Nedeni belirlenebilen en küçük düzeltmeyi yayınlayın. Bunu hemen laboratuvarda doğrulayın. İşlevselliği bozuyor veya başka bir metriği kötüleştiriyorsa geri alın.
6. Gerçek kullanıcıları izleyin. Öncü sinyal için RUM’ı, hareketli saha kararı için CrUX/Search Console’u kullanın. Paydaşların aynı gün içinde CrUX’un sıfırlanmasını beklememesi için kapsamı ve pencereyi belgeleyin.

Boşa iş çıkaran Core Web Vitals hataları

Birleşik Lighthouse puanını optimize etmek

Google’ın saha değerlendirmesi, tek Lighthouse Performance sayısını değil, gerçek kullanıcı verilerinden gelen LCP, INP ve CLS’yi kullanır. Başarısız saha metriğini tanılayın ve Lighthouse’ı kontrollü bir hata ayıklama ortamı olarak kullanın.

Core Web Vitals’ı sıralama kestirmesi olarak görmek

CWV, Google’ın hiçbir zaman resmi bir ağırlık vermediği bir sayfa deneyimi sinyalidir; alaka hâlâ baskındır. Kullanıcılar için kötü deneyimi düzeltin, ancak kanıt olmadan sıralama sıçraması vaat etmeyin veya daha önemli içerik ve dizine ekleme çalışmalarını geri plana atmayın.

URL, kaynak, mobil ve masaüstü değerlerini karıştırmak

Farklı kapsamlar farklı hikâyeler anlatabilir. Her değeri etiketleyin ve kaynak geri dönüşü veya masaüstü toplamı yeşil olduğu için bir sayfanın geçtiğini iddia etmeyin.

Bir yayını kontrol etmeden önce CrUX’u beklemek

Hareketli 28 günlük pencere dağıtım kalite kontrolü için fazla yavaştır. Mekanizmayı hemen laboratuvarda ve RUM’da doğrulayın, ardından daha uzun vadeli saha sonucunu doğrulamak için CrUX’u kullanın.

Core Web Vitals’ı ölçme araçları

Core Web Vitals History & Competitor Comparison ile kontrol edin:

1. Bir site ekleyin (example.com gibi çıplak bir kaynak en fazla CrUX verisine sahiptir; karşılaştırma için en fazla 5 site ekleyebilirsiniz).
2. Mobil veya masaüstünü seçin, ardından karşılaştırmayı çalıştırın.
3. LCP, INP ve CLS’nin bugünkü geçer/kalır durumunu puan kartından okuyun; ardından her metriğin iyi aralığa yaklaşıp yaklaşmadığını görmek için haftalık eğilim grafiğini inceleyin.

Saha verileri — gerçek kullanıcı Core Web Vitals ölçümü

• PageSpeed Insights — sayfa ve kaynak düzeyinde CrUX saha verileri ile yanında bir Lighthouse laboratuvar raporu.
• Google Search Console — Core Web Vitals raporu — benzer sayfaları gruplar ve site geneli saha örüntülerini ortaya çıkarır; başarısız sayfa gruplarını bulmanın en hızlı yoludur.
• CrUX API / BigQuery — doğrudan kaynak veri kümesinden özel ve ülke düzeyinde analiz.
• web-vitals JavaScript kütüphanesi — örneğin analitik sistemine aktararak kendi gerçek kullanıcı (RUM) verilerinizi toplayın.

Laboratuvar verileri — hata ayıklama için (sıralama için değil)

• Lighthouse — tanı amaçlı fırsatlar ve (sıralama yapmayan) Performance Score.
• Chrome DevTools Performance paneli — LCP, düzen kaymaları ve uzun görevlerde iz düzeyinde hata ayıklama.
• PageSpeed Insights laboratuvar bölümü — saha verilerinin altındaki Lighthouse destekli öneriler.

Pratik kural: Sahada nerede başarısız olduğunuzu bulmak için GSC → sayfa düzeyinde doğrulamak için PSI → tanı koyup yinelemek için Lighthouse / DevTools.

Zaman ayırmaya değer kaynaklar

İlgili yazılarım

• Core Web Vitals: Nasıl İyileştirilir (Ahrefs) — üç metriğe ve düzeltilmesi gerekenlere dair kapsamlı pratik rehberim.
• Core Web Vitals Veri Çalışması (Ahrefs) — CrUX + 5,2 milyon sayfa; sayfa düzeyi ile kaynak düzeyi geçiş oranı bulgusu.
• Largest Contentful Paint (LCP) rehberi (Ahrefs).
• Cumulative Layout Shift (CLS) rehberi (Ahrefs).
• PageSpeed Insights rehberi (Ahrefs).
• Teknik SEO için Başlangıç Rehberi — sayfa deneyiminin büyük resimdeki yeri.

Resmî

• web.dev — Web Vitals ve Resmî Belgeler altında bağlantısı verilen metrik makaleleri.
• Google, sıralama sinyallerini açıklığa kavuşturmak için sayfa deneyimi belgelerini güncelliyor (Search Engine Land) — Barry Schwartz’ın Mart 2024 belge değişikliği hakkındaki yazısı.

Sektörün çeşitli yerlerinden

• Google Core Web Vitals Sıralama Faktörü: Eşitlik Bozucudan Fazlası (Search Engine Journal) — John Mueller’ın CWV’nin “more than a tie-breaker” olduğu ancak alakanın yerini almadığı yönündeki Reddit ifadesinin kapsamı.
• Küçük/Yerel İşletmeler için Google Core Web Vitals Önceliği (Search Engine Roundtable) — Mueller’ın CWV çalışmalarının küçük/yerel işletmeler için en üst öncelik olmaması gerektiğine dair Mastodon yorumu.
• Doğrulandı: Core Web Vitals Büyük Bir Sıralama Faktörü Değil (Stan Ventures) — Mueller’ın “not giant factors in ranking” sözünün bağlamı.
• Core Web Vitals’ın SEO Üzerindeki Etkisi (RUMvision) — Kasım 2025’te güncellendi; temsilci alıntıları ve sıralama sinyali nüansını ele alan kapsamlı SSS özeti.
• Google Sayfa Deneyimi Güncellemesi: Eşitlik Bozucu (Search Engine Roundtable) — güncelleme yayımlanmadan önceki erken Mueller/Illyes eşitlik bozucu çerçevesi.

Alıntılanmaya değer istatistikler

• Tek tek sayfaların yalnızca yaklaşık %21,2’si üç Core Web Vital’ın tamamını geçer — kaynak düzeyinde bu oran yaklaşık %33’tür; Ahrefs Site Audit’ten CrUX + 5,2 milyon sayfaya dayanan CWV veri çalışmamdan. Google’ın sistemleri genellikle sayfaları tek tek değerlendirir; bu nedenle iyimser bir kaynak düzeyi ortalaması hâlâ başarısız birçok sayfayı gizleyebilir. Kaynak
• Siteler en çok LCP’de zorlanır. Bu çalışma, sitelerin eski FID ve CLS’de ilerleme kaydettiğini ancak LCP’de geride kaldığını buldu — ayrıca “almost no sites on 3G or slower connections are passing.” Kaynak
• “İyi” eşikler: Her biri saha verilerinin 75. yüzdelik diliminde olmak üzere LCP ≤2,5 s, INP ≤200 ms, CLS ≤0,1 — Google’ın belgelenmiş Core Web Vitals hedefleri. Kaynak
• INP, 12 Mart 2024’te FID’in yerini aldı — FID’in Core Web Vital olmayı bıraktığı ve Search Console’dan kaldırıldığı tarih. Kaynak

Kendinizi sınayın: Core Web Vitals

Core Web Vitals hakkında beş kısa soru. Her biri için bir yanıt seçin, sonra kontrol edin.

Bir LCP/INP/CLS düzeltmesinin gerçekten yayına girdiğini kanıtlayın

Bir performans düzeltmesindeki tuzak, yayımladığınız gün laboratuvar puanını kutlamaktır. Laboratuvar (Lighthouse) değişikliğin işe yarayabileceğini söyler; gerçek kullanıcılar için işe yarayıp yaramadığını yalnızca saha verileri (CrUX) söyler — üstelik bu veriler 28 günlük hareketli bir gecikmeyle değişir. İkisini de bu sırayla çalıştırın.

Test 1 — Düzeltme laboratuvar metriğini iyileştirdi

• Çalıştırılacak test — Değişiklikten önce ve sonra sayfayı Core Web Vitals Checker (veya Lighthouse / PageSpeed Insights) üzerinden çalıştırın.
• Beklenen sonuç — Hedeflenen laboratuvar metriği doğru yönde hareket eder; örneğin LCP öğesi daha erken boyanır, yeni bir düzen kayması oluşmaz ve üzerinde çalıştığınız belirli tanı temizlenir.
• Başarısızlık yorumu — Laboratuvar hareketi olmaması, değişikliğin kritik yola dokunmadığı anlamına gelir (LCP öğesi olmayan bir öğeyi veya engelleme yapmayan bir komut dosyasını optimize etmiş olabilirsiniz).
• İzleme penceresi — Anında — laboratuvar testleri isteğe göre çalıştırılır.
• Geri alma tetikleyicisi — Başka bir metriktede gerileme (LCP’yi düzeltip CLS’yi bozmanız veya INP’yi kötüleştiren JS eklemeniz) — laboratuvar bunu gerçek kullanıcılardan önce yakalar.

Test 2 — Gerçek kullanıcılar gerçekten fark ediyor (saha verileri)

• Çalıştırılacak test — Sayfanın/kaynağın LCP, INP ve CLS için p75 değerlerini CrUX’ta, Core Web Vitals History & Competitor Comparison aracında veya GSC Core Web Vitals raporunda izleyin.
• Beklenen sonuç — Düzeltilen metriğin p75 değeri “İyi” aralığına geçer ve orada kalır (Google’ın eşikleri: LCP ≤ 2,5 s, INP ≤ 200ms, CLS ≤ 0,1).
• Başarısızlık yorumu — Laboratuvar sonucu iyileştiği hâlde saha sonucu iyileşmediyse düzeltme, hızlı bağlantıyla yapılan teste yardımcı olmuş ancak gerçek cihaz/ağ karmasında etkili olmamış olabilir ya da gruptaki yeterli sayıda URL aynı düzeltmeyi içermiyor olabilir.
• İzleme penceresi — Hareketli 28 günlük dönem — CrUX geriye dönük 28 günlük bir pencere kullandığından, p75 değerinin güvenilir hâle gelmesi için düzeltmenin yaklaşık 4 haftalık saha verisi biriktirmesi gerekir. İlk haftada sonuca varmayın.
• Geri alma tetikleyicisi — p75 değerinin yeniden “kötü” eşiğini aşması veya bir şablon değişikliğinden sonra GSC’deki “İyi” URL sayısının düşmesi, dağıtımın gerçek kullanıcı performansını gerilettiğine dair güçlü bir işarettir.

Bu konu için sürekli izlenecek KPI

Herhangi bir düzeltmeyi doğrulamaktan ayrı olarak, sayfa deneyiminin sağlıklı olup olmadığını çeyrekten çeyreğe bilmek için izlediğiniz şey budur. Burada savunulabilir bir kıyaslama vardır — Google eşikleri yayımlar — dolayısıyla hiçbir sayı uydurulmamıştır.

p75 LCP, INP ve CLS (saha verileri)

• Metrik — Her sayfa grubu ve cihaz için gerçek ziyaretlerdeki her Core Web Vital’ın 75. yüzdelik dilim değeri.
• Size ne söyler — Gerçek kullanıcıların %75’inin iyi bir deneyim yaşayıp yaşamadığını, yani Google’ın bir URL’yi başarılı olarak sınıflandırmak için kullandığı kesin eşiği gösterir. Daha yavaş olan uzun kuyruğu yansıttığı için önemli değer ortalama değil p75’tir.
• Nasıl alınır — Core Web Vitals History & Competitor Comparison üzerinden CrUX, URL örüntüsüne göre gruplandırılmış saha verilerini sunan GSC Core Web Vitals raporu veya tek bir URL için PageSpeed Insights kullanılabilir.
• Kıyaslama / gerçekçi aralık — Google’ın kendi eşikleri: “İyi” için LCP ≤ 2,5s, INP ≤ 200ms, CLS ≤ 0,1; “İyileştirme gerekli” / “Kötü” aralıkları sırasıyla 2,5–4s / >4s, 200–500ms / >500ms ve 0,1–0,25 / >0,25’tir. Bunlar uydurma hedefler değil, yayımlanmış eşiklerdir.
• Sıklık — Hareketli 28 günlük dönem nedeniyle aylık inceleyin; günlük kontrol yalnızca aynı geriye dönük pencereyi yeniden okur. Laboratuvar puanlarını öncü, CrUX p75 değerini ise gecikmeli gösterge olarak değerlendirin.

Site genelindeki “İyi URL” kapsamı

• Metrik — GSC Core Web Vitals raporundaki “İyi” grubunda bulunan dizine eklenmiş URL’lerinizin payı (mobil ve masaüstü ayrı ayrı izlenir).
• Size ne söyler — Düzeltmelerin ne kadar geniş bir alana yayıldığını gösterir; tek bir hızlı sayfa siteyi değiştirmez, şablon düzeyindeki kazanımlar değiştirir.
• Nasıl alınır — GSC → Core Web Vitals raporu → zaman içindeki İyi / İyileştirme gerekli / Kötü URL sayısı.
• Kıyaslama / gerçekçi aralık — Duruma bağlıdır; şablonlarınıza ve trafik karmanıza göre değişir. Bu nedenle kendi başlangıç düzeyinizi belirleyin ve uydurma bir yüzdeyi kovalamak yerine İyi URL payını zaman içinde artırın.
• Sıklık — Aylık veya bir şablon/tema değişikliğinin hemen ardından, saha verisi penceresi güncellenirken haftalık.

Değişiklik günlüğü