Core Web Vitals 2026: INP, LCP ve CLS ile daha hızlı bir site
Yeşil bir PageSpeed rozeti nihai hedef değildir. Amaç; gerçek ziyaretçiye ana içeriği hızla gösteren, dokunmalara gecikmeden yanıt veren ve kullanılırken beklenmedik biçimde kaymayan bir web sitesi kurmak, ardından iyileşmeyi doğru verilerle kanıtlamaktır.
Uygun Chrome kullanıcılarının zaman içindeki gerçek deneyimini anlamak için CrUX ve Search Console’u; sorunu yeniden üretip nedenini bulmak için PageSpeed Insights ve DevTools’u kullanın. Ardından gecikmeye yol açan kaynağı, JavaScript görevini veya yerleşim kararını düzeltin. 75. yüzdelikte LCP için 2,5 saniye veya altını, INP için 200 milisaniye veya altını, CLS için 0,1 veya altını hedefleyin. Üç metriği geçmek kullanıcı deneyimini ve sayfa deneyimini destekler; tek başına birincilik garantisi değildir.[1]
Core Web Vitals, gerçek kullanıcı deneyiminin üç boyutunu ölçer: yükleme performansı, etkileşime yanıt ve görsel kararlılık. İsimleri teknik olsa da iş açısından sordukları sorular basittir. Potansiyel müşteri ana teklifinizi zamanında görebiliyor mu? Menü dokunulduğunda tepki veriyor mu? Teklif formunun düğmesi kullanıcı tıklayacağı sırada yer değiştiriyor mu?
Bu rehber yalnız bir puanı yükseltmeyi değil, sürdürülebilir bir performans sistemi kurmayı amaçlıyor. Arama stratejisinin tamamı için SEO optimizasyonu hizmetimizi, yapısal tasarım ihtiyacı için web sitesi tasarımı yaklaşımımızı inceleyebilirsiniz. Üretken arama görünürlüğü ise ayrı bir problem alanıdır; bunun için Yapay Zekâ SEO 2026 rehberini kullanın.
Tekil metrikleri geçen çok; üç metriği birlikte geçen daha az
Largest Contentful Paint
≤ 2,5 snGörünür alandaki en büyük ana içerik öğesinin ne kadar erken çizildiğini ölçer. Aday çoğu kez hero görseli, büyük başlık veya banner’dır.
Interaction to Next Paint
≤ 200 msYalnız ilk tıklamayı değil, ziyaret boyunca gerçekleşen etkileşimlerden sonra sayfanın ne kadar hızlı görsel yanıt verdiğini değerlendirir.
Cumulative Layout Shift
≤ 0,1Sayfa açıkken biriken beklenmedik yerleşim hareketini ölçer. Düşük değer, metin ve kontrollerin öngörülebilir kaldığını gösterir.
Chrome UX Report: Temmuz 2026 origin görünümü
Temmuz 2026’da toplanan ve 11 Ağustos 2026’da yayımlanan resmî CrUX verisi. Bunlar origin düzeyinde ekosistem istatistikleridir; tek bir sitenin hedefi veya tahmini değildir. Temsil edilen origin’lerin %44,3’ünün bütün değerlendirmeyi geçemediği çıkarılabilir, fakat bu oran sizin sitenizde hangi düzeltmenin gerektiğini söylemez.[11]
Google, iyi Core Web Vitals değerlerini hem Arama başarısı hem genel kullanıcı deneyimi için öneriyor ve bunları sayfa deneyiminin bir parçası olarak açıklıyor. Alaka, yararlılık, taranabilirlik ve çok sayıda başka sinyal önemini korur. “Geçtim, dolayısıyla birinci olmalıyım” da “hızın SEO değeri yoktur” da hatalıdır. Sağlam yaklaşım; gereksiz sürtünmeyi kaldırmak, etkisini dürüstçe ölçmek ve sayfanın asıl amacını geliştirmeye devam etmektir.[1]
LCP, INP ve CLS neyi gösterir, neyi göstermez?
LCP: ana içerik geç görünür
LCP bütün ağ isteklerinin bitiş süresi değildir. Görünür alandaki en büyük uygun öğenin çizildiği anı işaretler. Yavaş sunucu yanıtı, tarayıcının hero görselini geç keşfetmesi, render’ı engelleyen CSS, ağır web fontu veya istemci tarafında oluşturma aynı metriği geciktirebilir. Aday öğe yükleme sırasında değişebildiği için tek ekran görüntüsü neden analizi için yetmez. Çözüm seçmeden önce metriği ilk bayta kadar geçen süre, kaynak yükleme gecikmesi, kaynak indirme süresi ve öğenin çizilme gecikmesi olarak bölün.[6]
INP: kullanıcı işlem yaptıktan sonra sayfa takılır
INP, ziyaret boyunca uygun tıklama, dokunma ve klavye etkileşimlerini izler; tanımındaki aykırı değer işlemiyle yüksek gecikmeli temsili etkileşimi raporlar. Girdi gecikmesini, olay kodunun işlem süresini ve bir sonraki karenin sunum gecikmesini kapsar. Büyük JavaScript paketi etkili olabilir; fakat gerçek neden uzun olay fonksiyonu, pahalı DOM işlemi, senkron yerleşim hesabı veya geç çizim de olabilir. Mümkünse alan bağlamıyla başlayın: hangi sayfa, kontrol, cihaz ve eylem yavaştı?[7]
CLS: arayüz kullanıcı istemeden hareket eder
CLS, oturum pencereleri içinde oluşan beklenmedik yerleşim kaymalarını biriktirir. Boyutları tanımlanmamış görseller, sonradan eklenen banner ve reklamlar, çerez aracı, geç yüklenen font ve yerleşimi değiştiren animasyonlar sık nedenlerdir. Gerçek kullanıcı etkileşiminin hemen ardından beklenen hareket puandan hariç tutulabilir; bu, her rahatsız arayüzün kabul edilebilir olduğu anlamına gelmez. Metriği kandırmak yerine alan ayırın ve durum değişimini öngörülebilir yapın.[8]
| Sinyal | Ziyaretçinin yaşadığı | Sık teknik nedenler | İlk incelenecek kanıt |
|---|---|---|---|
| LCP | Ana mesaj veya hero geç gelir | Sunucu gecikmesi, görsel keşfi, büyük medya, engelleyici CSS | CrUX URL grubu, LCP öğesi ve trace alt süreleri |
| INP | Dokunma ya da klavye işlemi yok sayılmış gibi görünür | Uzun görev, ağır callback, büyük DOM, üçüncü taraf betiği | Alan etkileşim bağlamı ve DevTools ana iş parçacığı kaydı |
| CLS | Metin, düğme veya ürün kartı sıçrar | Eksik boyut, dinamik embed, font değişimi, eklenen arayüz | Yerleşim kayması kümeleri ve etkilenen öğeler |
Alan verisi ile laboratuvar verisi farklı sorulara yanıt verir
Alan verisi, gerçek cihaz, ağ, önbellek durumu ve kullanıcı davranışındaki ziyaretlerden gelir. CrUX, PageSpeed Insights’ın gerçek kullanıcı panelini ve Search Console Core Web Vitals raporlamasının temelini sağlar. Veri toplulaştırılmış ve gizlilik korumalıdır; uygunluk ve yeterli örnek koşullarına bağlıdır. Geçmiş ziyaretleri içeren kayan dönem kullandığı için, yayından bir gün sonra hemen yeşile dönmez.[4][5]
Laboratuvar verisi, kontrollü bir testtir. Lighthouse, PageSpeed teşhisleri ve Chrome DevTools belirlenmiş koşullarda sayfayı yeniden üretir; ağ, render ve ana iş parçacığı çalışmasını gösterir. Hata ayıklama ve regresyon testi için çok değerlidir, ancak tek koşu bütün müşterilerin sayımı değildir. Güçlü geliştirici bilgisayarı, soğuk önbellekle mobil simülasyon ve geri dönen gerçek kullanıcı aynı URL’yi farklı yaşayabilir.[2]
Öncelik için alan verisi
Sorunun kaç gerçek ziyaretçiyi, hangi URL grubunu ve cihaz kitlesini etkilediğini, eğilimin sürüp sürmediğini sorun. Search Console örüntüyü bulur; CrUX geçmişi veya kendi gerçek kullanıcı ölçümünüz operasyonel ayrıntı ekleyebilir.
Neden için laboratuvar verisi
Temsili yavaş yolu yeniden üretin. LCP kaynağını ve istek zincirini, etkileşim çevresindeki uzun görevleri ya da kayma kümelerini inceleyin. Neden ilişkisini korumak için her tutarlı değişiklikten sonra tekrar test edin.
Alan paneli ve Lighthouse koşusu; kitle, dönem, cihaz, ağ ve mevcut metrikler açısından farklıdır. “Veri yok” ifadesi “kusursuz” demek değildir. URL’nin yeterli uygun trafiği olmayabilir ya da araç origin verisi gösterebilir. Sayıları karşılaştırmadan önce etiket ve kapsamı okuyun.[3]
Ölç → segmentle → yeniden üret → iyileştir → doğrula
Alan durumunu, 75. yüzdelik değeri, örnek kapsamını ve tarihi kaydedin. Değişiklik öncesi çizgiyi saklayın.
Şablon, cihaz, coğrafya ve trafik türüne ayırın. Tek yavaş şablon yüzlerce URL’yi etkileyebilir.
Temsili yolu DevTools’ta yeniden üretin. Metriği belirli bir kaynak, görev veya yerleşim kararına bağlayın.
Yayından önce test edin, hataları izleyin ve başarı demeden önce yeterli yeni alan verisini bekleyin.
En kolay puanı değil, iş önemi ile kullanıcı zararının en ağır birleşimini seçin. Yavaş bir teklif formu, arşiv sayfasındaki küçük kaymadan önce gelir. Yayın tarihi, etkilenen şablon, hipotez, laboratuvar kanıtı ve sonraki alan sonucunu aynı günlükte tutun. Aksi halde sezonluk trafik değişimi veya tarayıcı güncellemesi mühendislik başarısı sanılabilir.
Search Console, geniş örüntüleri göstermek için benzer URL’leri gruplar; tek etkileşimi hata ayıklamak için tasarlanmamıştır. Temsili URL’yi inceleyin, fakat şablon ve kaynakların diğer sayfalarda ortak olup olmadığını doğrulayın. DevTools Performance paneli ağ ve ana iş parçacığı sırasını, uzun görevleri ve kullanıcı zamanlamalarını gösterebilir. Ekran görüntüsü üretmek için değil, olayların sırasını anlamak için kullanın.[4][12]
Ana içeriği gizlemeden LCP nasıl iyileştirilir?
Önce LCP öğesini ve alt süreleri belirleyin. İlk bayt süresi baskınsa barındırma, uygulama işi, yönlendirme, önbellek ve içerik dağıtımını araştırın. Kaynak yükleme gecikmesi baskınsa hero kaynağını ilk HTML’de keşfedilebilir yapın; olası LCP görselini lazy-load etmeyin ve ölçüme göre preload veya fetch priority değerlendirin. İndirme süresi baskınsa görseli amacı bozmadan doğru ölçülendirin, sıkıştırın ve uygun biçimi kullanın. Öğenin çizilme gecikmesi baskınsa engelleyici CSS, font ve istemci oluşturmayı inceleyin.[6]
- İlk HTML’i hızlı sunun ve gereksiz yönlendirme sıçramalarını kaldırın.
- Olası LCP görselini markup içinde ve erken keşfedilebilir tutun.
- Görünür alandaki hero’ya genel lazy-loading kuralı uygulamayın.
- Responsive görsel adaylarıyla gerçek iç boyutları tanımlayın.
- Yalnız gerçekten kritik CSS’i erkene alın; gerisini kontrollü erteleyin.
- Font ailesi, ağırlık ve engelleyici bağlantı sayısını sınırlayın.
- Sadece ana sayfayı değil, önemli hizmet ve içerik şablonlarını ölçün.
Küçük hero görseli iki saniyelik sunucu gecikmesini telafi etmez. Hızlı hosting de yalnız büyük bir istemci paketi çalıştıktan sonra eklenen görseli erken keşfettiremez. En büyük ölçülmüş alt süreyi hedefleyin. Metrik küçülsün diye yararlı başlık veya görseli kaldırmak da çözüm değildir; teklifini anlatamayan hızlı sayfa ticari hedefi kaçırır.
Ana iş parçacığını yöneterek INP nasıl iyileştirilir?
Kötü INP çoğu zaman yükleme sonrasında ortaya çıkar: analitik, sohbet aracı, slider, filtre ve uygulama kodu ana iş parçacığı için yarışır. Alan atfı veya gerçek kullanıcı ölçümüyle yavaş etkileşimi bulun; aynı kullanıcı yolunu DevTools’ta kaydedin. Uzun görevleri bölün, callback işini azaltın, tekrar eden senkron yerleşim okuma-yazmalarından kaçının ve yalnız mevcut durum için gereken DOM’u oluşturun. Kritik olmayan iş parçaları arasında tarayıcıya kare çizme fırsatı verin.[7]
Üçüncü taraf betikleri ticari sahiplik gerektirir. Her etiketin sahibini, yüklenme koşulunu ve ölçülebilir katkısını yazın. “Pazarlama istedi” kalıcı performans muafiyeti değildir. Uygunsa destek aracını niyet sonrasında yükleyin, çift analitiği kaldırın ve çerez yönetiminin etkisini ölçün. Karmaşık özellik zorunluysa aşamalı oluşturma ve sunucudan gelen HTML, zengin davranış hazırlanırken ilk yararlı etkileşimi koruyabilir.
| Evre | Anlamı | Olası yaklaşım |
|---|---|---|
| Girdi gecikmesi | Callback başlamadan önce ana iş parçacığı meşguldü | İlgisiz uzun görevleri azaltın veya planlayın; gereksiz betikleri erteleyin |
| İşlem süresi | Olay fonksiyonları ve senkron işleri uzun sürdü | Callback’i sadeleştirin, işi bölün, DOM ve hesabı azaltın |
| Sunum gecikmesi | Tarayıcı yeni kareyi hesaplayıp çizmekte zorlandı | Yerleşim karmaşıklığını, DOM değişimini ve pahalı efektleri azaltın |
Yalnız tek demo tıklamasını iyileştirmeyin. INP ziyareti temsil eder; navigasyon, akordeon, filtre, form, doğrulama, çerez seçimi ve temel dönüşüm işlemlerini sınayın. Klavye kullanımı da kapsamdadır. Sayfa hızlı yüklenebilir ama ilk form alanı donduğu için müşteriyi yine kaybedebilir.
Alan ayırarak ve değişimi yöneterek CLS nasıl iyileştirilir?
Görsel ve videolara width-height veya aspect-ratio verin; tarayıcı dosya gelmeden yer ayırabilsin. Reklam, harita, yorum, çerez ve gömülü medya konteynerlerine öngörülebilir minimum alan tanımlayın. Koşullu banner eklenecekse bütün sayfayı itmek yerine ayrılmış bölgeyi ya da içeriği hareket ettirmeyen overlay’i tercih edin. Dekoratif animasyonda transform kullanımı çoğu zaman daha güvenlidir; yerleşimi değiştiren özellikler kaymaya yol açabilir.[8]
Fontların fallback stratejisi bilinçli olmalıdır. Ölçüleri çok farklı yedek font, web fontu gelince uzun başlığı yeniden satırlara böler. Varyant sayısını azaltın, yalnız gerekli dosyaları önceliklendirin, uygun font yükleme davranışı seçin ve desteklenen yerlerde metrik ayarlarını değerlendirin. Gerçek kayma kümelerine bakın: geç hareket eden footer, çoğu zaman footer sorunu değil, yukarıdaki boyutsuz görselin sonucudur.
- Tüm içerik ve ürün görsellerinde iç boyut veya oran tanımlayın.
- Dinamik embed ve çerez bileşenleri için gerçekçi alan ayırın.
- İlk çizimden sonra mevcut içeriğin üzerine bildirim eklemeyin.
- Dört site dilindeki uzun başlıklarda font değişimini kontrol edin.
- Satır kırılması etkilenen alanı değiştirdiği için responsive eşikleri test edin.
- Gerçek yolculuğu oynatın; kayma sayfa açıldıktan çok sonra oluşabilir.
WordPress Core Web Vitals: tek URL’yi değil sistemi düzeltin
Sunucu ve şablon katmanı
İlk bayt süresini, tam sayfa önbellek uygunluğunu, veritabanı ve PHP işini, yönlendirmeleri, tema çıktısını ve görsel üretimini ölçün. Şişkin şablon her hizmet veya makalede çoğalır. Staging ve geri dönüş planı kullanın.
Eklenti ve üçüncü taraf katmanı
Eklenti ve etiketleri işlev, sahip ve ön yüz maliyetine göre listeleyin. Çakışan işlevi kaldırın, özelliğin olmadığı sayfada dosyayı kapatın ve güncellemeleri test edin. Önbellek eklentisi her slider ve tracker’ı etkisizleştiremez.
WordPress performans belgeleri; önbellekleme, görsel optimizasyonu, dosya isteklerini azaltma ve yazılımı güncel tutmayı daha geniş bir performans uygulamasının parçaları olarak ele alır.[9] Bunu yönetişime çevirin: yeni eklentinin sahibi ve performans testi olsun; tema değişikliği şablon bazlı önce-sonra kanıtı taşısın; büyük yüklemeler otomatik varyant üretsin; kritik sayfalar yayın sonrasında sentetik kontrol alsın.
“Her şeyi optimize et” seçeneklerine dikkat edin. Tüm JavaScript’i geciktirmek navigasyon, izin, analitik veya formu bozabilir. Dosya birleştirme modern HTTP ile her zaman kazanç sağlamaz. Agresif önbellek kişiselleştirilmiş içeriği bayat gösterebilir. Tek tutarlı katmanı değiştirin, işlevi, erişilebilirliği ve dönüşüm ölçümünü doğrulayın, sonra performansı kıyaslayın. En hızlı bozuk form da sıfır lead üretir.
2026’da soft-navigation ölçümü: önemli, fakat henüz evrensel değil
Geleneksel Core Web Vitals ölçümü üst düzey sayfa navigasyonuyla başlar. Tek sayfa uygulamaları tam yenileme olmadan URL’yi ve içeriğin çoğunu değiştirebilir; bu da route deneyimini aynı modelle göstermeyi zorlaştırıyordu. 11 Ağustos 2026’da güncellenen web.dev SPA rehberine göre Chrome 151, yumuşak route geçişlerinde Core Web Vitals ölçümünü mümkün kılan API’leri sundu. Rehber, PerformanceSoftNavigation ve InteractionContentfulPaint yapı taşlarını adlandırıyor.[10]
Kapsam kritik önem taşır. Güncelleme tarihinde bu API’ler web-vitals kitaplığı, gerçek kullanıcı ölçüm çözümleri ve DevTools gibi araçlarda yeni kullanılmaya başlıyordu. Chrome, CrUX entegrasyonu için tarih açıklamamıştı; diğer tarayıcı motorları da henüz desteklemiyordu. Dolayısıyla Eylül 2026’da Search Console’un her SPA route’unu otomatik raporladığını söylemeyin. Soft-navigation verisini gelişmekte olan ayrı bir teşhis akışı olarak tutun; kitaplık, tarayıcı kitlesi ve sürümü belgeleyin.[10]
Framework ne olursa olsun Google’ın erişilebilir HTML, kaynak, bağlantı ve anlamlı render edilmiş içeriğe ihtiyacı vardır. JavaScript SEO temelleri sürer: taranabilir bağlantılar, kararlı URL’ler, doğru durum kodları ve güvenilirliği artırdığı yerde sunucu tarafı veya önceden oluşturma kullanın.[13] Performans ile indekslenebilirlik kesişir ama aynı şey değildir. Route çok hızlı fakat keşfedilemez; ya da indekslenir fakat kullanılamayacak kadar yavaş olabilir.
Tam navigasyon alan metriklerini karşılaştırılabilir temel çizgi olarak koruyun. Soft-navigation telemetrisini ayrı etiketli 2026 ölçüm katmanı olarak ekleyin. Tanım değişimini açıklamadan iki farklı kitleyi tek eğilimde birleştirmeyin.
Bütün ekibin uygulayabileceği performans bütçesi kurun
Performans bütçesi “hızlı tutalım” dileğini yayın kriterine dönüştürür. Sonuç eşiği, kaynak limiti ve süreç kuralını birlikte içermelidir. Core Web Vitals alan hedefleri sonuçtur; JavaScript ağırlığı, hero görsel boyutu ve üçüncü taraf sayısı kontrol edilebilir girdilerdir. Sınırları evrensel tablodan kopyalamak yerine mevcut site ve kitleye göre belirleyin; istisnaları süreli ve sahipli yapın.
Deneyim bütçesi
Öncelikli şablonlarda 75. yüzdelik LCP, INP ve CLS hedefleri. Form yanıtı gibi göreve özel ölçüler de eklenir.
Dağıtım bütçesi
Kararlaştırılmış mobil profil için kritik görsel, ilk JavaScript, CSS, font ve üçüncü taraf çalışma sınırları.
Yönetişim bütçesi
Her istisna için adlandırılmış sahip, yayın öncesi test, izleme penceresi, geri dönüş koşulu ve sona erme tarihi.
| Kalem | Örnek uyarı | Örnek yayın engeli | Sahip |
|---|---|---|---|
| Hero görsel aktarımı | 180 KB üstü | 260 KB üstü | Tasarım/içerik |
| İlk taraf başlangıç JS | Sıkıştırılmış 170 KB üstü | Sıkıştırılmış 230 KB üstü | Geliştirme |
| Üçüncü taraf ana iş parçacığı | Test profilinde 200 ms üstü | 350 ms üstü | Pazarlama + geliştirme |
| CLS laboratuvar koruması | 0,08 üstü | 0,10 üstü | Tasarım + kalite |
Tablodaki rakamlar bilinçli olarak temsilidir. Kendi sınırlarınızı iş açısından kritik şablon, temsili cihaz ve ölçülmüş başlangıç verisinden türetin. Laboratuvar koruması alan doğrulamasının yerini tutmaz.
Ana sayfa ekran görüntüsü yerine şablon bazlı skor kartı kullanın
Aşağıdaki kurgusal örnek, her hareketi nedensel sonuç gibi göstermeden kanıtın nasıl aktarılacağını gösterir. Alan gözlemini, laboratuvar teşhisini, yayımlanan müdahaleyi ve sonraki doğrulamayı ayırır. Süreler ve yüzdeler örnektir.
| Aşama | LCP p75 | INP p75 | CLS p75 | Yorum |
|---|---|---|---|---|
| 28 günlük temel | 3,4 sn | 248 ms | 0,07 | LCP ve INP gelişmeli; CLS iyi |
| Laboratuvar teşhisi | Hero slider betiğinden sonra keşfediliyor | Filtre callback’i uzun görev oluşturuyor | Tekrarlanan sorun yok | İki bağımsız neden |
| Yayın | İlk HTML’de statik hero | Callback bölündü; gereksiz eklenti kaldırıldı | Boyutlar korundu | İşlev ve izleme doğrulandı |
| Yeni alan penceresi | 2,3 sn | 182 ms | 0,06 | İyileşme müdahaleyle uyumlu; izleme sürer |
Skor kartının yanında URL grubu, cihaz karması, dönem, yayın tarihi ve örneklem kısıtını gösterin. Dönüşüm kalitesini koruma metriği olarak ekleyin. Hız yükselirken form bozuluyor veya nitelikli talep düşüyorsa yayın başarılı değildir. Teknik SEO metriğe değil, ziyaretçiye ve işe hizmet eder.
30/60/90 günlük Core Web Vitals planı
Temel çizgi ve triyaj
Search Console gruplarıyla CrUX geçmişini dışa aktarın, şablon ve üçüncü taraf envanteri çıkarın, temel kullanıcı yollarını seçin, laboratuvar profillerini sabitleyin, eksik görsel boyutlarıyla hatalı lazy-loading kurallarını düzeltin ve ölçüm sözlüğü oluşturun.
Kök nedeni düzeltin
Sunucu ve LCP keşif yolunu iyileştirin, gelir getiren etkileşimlerde uzun görevleri azaltın, dinamik alanı ayırın, WordPress eklentisi veya JavaScript chunk’larını denetleyin, ilk performans bütçesini uygulayın; erişilebilirlik ve analitiği test edin.
Doğrulayın ve yönetin
Tam yeni alan pencerelerini değerlendirin, öncelikli şablonları kıyaslayın, regresyonu araştırın, dönüşüm korumalarını raporlayın ve yayın kontrollerine sahip atayın. SPA’lerde soft-navigation telemetrisini CrUX’tan ayrı etiketleyin.
Güvenli ve açık bir düzeltmeyi yayınlamak için 90 gün beklemeyin; plan gecikmeyi değil yönetişimi anlatır. Buna karşılık tek laboratuvar testi yeşile döndüğü gün alan başarısı ilan etmeyin. Rapor penceresinde yeterli sayıda yeni gerçek ziyaret bulunmalıdır.
Core Web Vitals kontrol listesi
- Alan ve laboratuvar sonuçları ayrı etiketleniyor; açıklamasız tek sayıda birleştirilmiyor.
- Öncelikli URL’ler ortak şablon ve iş yolculuğuna göre gruplanıyor.
- LCP öğesi ve alt süreleri optimizasyon öncesinde kaydediliyor.
- INP teşhisi gerçek etkileşimi ve yavaş evreyi gösteriyor.
- CLS araştırması etkilenen öğeyle onu hareket ettiren öğeyi belirliyor.
- Veri yeterliyse mobil, masaüstü ve temel coğrafi kitleler ayrı okunuyor.
- İzin, form, navigasyon, analitik ve erişilebilirlik değişiklikten sonra çalışıyor.
- Yayın günlüğünde tarih, sahip, hipotez ve geri dönüş koşulu bulunuyor.
- Alan doğrulaması yeterince temsilî yeni veri penceresi kullanıyor.
- Performans limitleri tek proje sonunda değil, gelecekteki içerik ve yayınlarda denetleniyor.
Core Web Vitals 2026 SSS
Core Web Vitals Google sıralama faktörü müdür?
Google, iyi Core Web Vitals değerlerinin sayfa deneyimi kapsamında temel sıralama sistemlerinin ödüllendirmeye çalıştığı deneyimle uyumlu olduğunu söyler. Bunlar tek sinyal değildir ve geçmek üst sırayı garanti etmez. Bağımsız bir taktik değil, kullanıcı ve arama hazırlığı için iyileştirin.[1]
2026’daki iyi eşikler nedir?
75. yüzdelikte LCP 2,5 saniye veya altı, INP 200 milisaniye veya altı, CLS 0,1 veya altı hedeflenir. Tek ideal test yerine mobil ve masaüstü kullanıcı kitlesini okuyun.[1]
PageSpeed yeşilken Search Console neden kırmızı olabilir?
Lighthouse kontrollü laboratuvar anıdır; Search Console gerçek kullanıcı CrUX verisini ve URL gruplarını zaman içinde toplar. Cihaz, ağ, önbellek, kitle ve dönem farklıdır. PageSpeed’in URL mi origin alan verisi mi gösterdiğini kontrol edin.[2][4]
Search Console düzeltmeyi ne zaman gösterir?
Anında değil. Alan raporu kayan toplama dönemini kullanır ve yeni uygun ziyaretlere ihtiyaç duyar. Hemen doğrulama için staging ve laboratuvar testini kullanın; konu kapanmadan yeni alan penceresini izleyin.
Hero görsel lazy-load edilmeli mi?
Görünür alandaki olası LCP öğesiyse genellikle hayır. Erken keşfedilir, doğru ölçülendirilir ve uygun öncelikle sunulur. Görünür alan altındaki medyayı ölçerek lazy-load edin.[6]
Önbellek eklentisi bütün WordPress CWV sorunlarını çözer mi?
Hayır. Önbellek teslimatı iyileştirebilir; geç hero keşfi, büyük görsel, uzun JavaScript görevi, eksik boyut ve üçüncü taraf bileşeni farklı çözümler gerektirir.
INP yalnız ilk etkileşimi mi ölçer?
Hayır. Eski FID’den farklı olarak sayfa ziyaretindeki etkileşime yanıtı genel olarak değerlendirir ve tanımına göre yüksek gecikmeli bir etkileşimi temsil eder. Sadece ilk tıklamayı değil temel kontrolleri sınayın.[7]
CrUX her SPA soft navigation geçişini şimdiden kapsıyor mu?
Hayır. Ağustos 2026 web.dev rehberi, Chrome 151 API’lerinin araçlarda route geçişi ölçümünü yeni başlattığını; ancak CrUX entegrasyon takviminin açıklanmadığını ve diğer motorların henüz desteklemediğini belirtiyor.[10]
Aylık yönetim raporunda ne olmalı?
Öncelikli şablonlara göre alan durumu, ölçülmüş darboğaz, yayımlanan değişiklik, yeni doğrulama penceresi, performans bütçesi istisnası ve dönüşüm/işlev korumasını gösterin. Bağlamsız ana sayfa puanı sunmayın.
Kaynaklar ve yöntem
Eşikler, ürün kapsamı ve 2026 yenilikleri aşağıdaki birincil Google, Chrome ve web.dev belgelerine dayalıdır. CrUX ekosistem oranları temsil edilen origin’leri anlatır; tek işletme için benchmark değildir. Performans bütçesi ve vaka tablosundaki rakamlar açıkça temsilidir.
- Google Search Central — Core Web Vitals ve Google arama sonuçları, 10 Aralık 2025 güncellemesi.
- web.dev — Laboratuvar ve alan verisi neden farklı olabilir?
- Google Developers — PageSpeed Insights hakkında.
- Google Search Console Yardım — Core Web Vitals raporu.
- Chrome for Developers — Chrome UX Report belgeleri.
- web.dev — Largest Contentful Paint optimizasyonu.
- web.dev — Interaction to Next Paint optimizasyonu, 2 Eylül 2025 güncellemesi.
- web.dev — Cumulative Layout Shift optimizasyonu.
- WordPress Developer Resources — Optimization.
- web.dev — SPA mimarileri Core Web Vitals’ı nasıl etkiler?, 11 Ağustos 2026 güncellemesi.
- Chrome UX Report — Sürüm notları, Temmuz 2026 verisi 11 Ağustos 2026’da yayımlandı.
- Chrome for Developers — Performance özellikleri.
- Google Search Central — JavaScript SEO temelleri.
Performans verisini ziyaretçilerin güveneceği bir siteye dönüştürün
Levent Global Media, Core Web Vitals durumunuzu denetleyebilir, şablon ve üçüncü taraf darboğazlarını ayırabilir ve teknik SEO iyileştirmelerini güvenilir kullanıcı ve iş sonuçlarıyla ilişkilendirebilir.
