Hızlı Cevap
Core Web Vitals raporunda iyi görünen ama yavaş hissedilen sayfa şudur: LCP, INP ve CLS eşikleri geçse bile TTFB, geç çalışan JavaScript, URL gruplaması, 28 günlük CrUX penceresi ve düşük donanımlı mobil segmentler gerçekteki beklemeyi gizleyebilir. Bu yüzden rapor iyi, deneyim zayıf olabilir.
Önemli Noktalar
- CWV skoru, gerçek deneyimin tamamını değil kritik eşikleri özetler.
- 28 günlük CrUX penceresi yeni sorunları raporda geç görünür kılar.
- URL grupları tek bir şablondaki mobil sorunu ortalama içinde saklayabilir.
- RUM, oturum kaydı ve Lighthouse birlikte okunmadan kök neden zor bulunur.
Core Web Vitals raporunda iyi görünen bir sayfa neden gerçek kullanıcıda yavaş hissedilir?
Core Web Vitals iyi görünüyorsa bu, her şeyin hızlı olduğu anlamına gelmez. Çünkü bu rapor kullanıcının yaşadığı tüm akışı değil, belirli eşikleri geçen birkaç kritik metriği özetler. Google for Developers dokümantasyonuna göre PageSpeed Insights alan verisi son 28 günlük gerçek kullanıcı deneyimini gösterir ve değerlendirmeyi 75. yüzdelik dilim üzerinden yapar. Yani çoğunluğun deneyimi iyi olabilir; ama daha zayıf cihazdaki, daha yavaş bağlantıdaki veya giriş sonrası daha ağır akış gören bir segment hâlâ belirgin biçimde yavaşlık hissedebilir.
Bir sayfa LCP, INP ve CLS tarafında iyi görünürken yine de ağır hissedilebilir; çünkü kullanıcı algısı yalnızca bu üç metriğe indirgenmez. İlk baytın geç gelmesi, içerik görünse bile butonların geç çalışması, filtrelerin sonradan canlanması, üçüncü taraf etiketlerin ana iş parçacığını meşgul etmesi ve girişli deneyimde ek API çağrıları oluşması bu çelişkinin tipik nedenleridir. Kısacası rapor size “eşikler geçildi” der; kullanıcı ise “sayfa akmıyor” diyebilir.
- CWV neyi gösterir: LCP, INP ve CLS için toplulaştırılmış saha kalitesini.
- CWV neyi kaçırabilir: Akış içi beklemeleri, geç canlanan bileşenleri ve segment farklarını.
- Asıl sorun: İyi skor ile iyi hissin her zaman aynı şey olmaması.
Search Console URL grupları ve CrUX penceresi tekil sorunu nasıl gizler?
Search Console’daki Core Web Vitals raporu çoğu zaman tek bir URL’yi değil, benzer deneyim sunan URL gruplarını gösterir. Bunu Google’ın resmi Search Console Yardım dokümanı açıkça anlatır: rapor durum, metrik türü ve benzer sayfa grupları üzerinden çalışır. Bu yaklaşım büyük sitelerde pratik olsa da tek bir şablondaki veya yalnızca belirli parametre kombinasyonunda ortaya çıkan sorunu perdeleyebilir. Özellikle ürün varyasyonları, filtreli kategori sayfaları veya giriş sonrası açılan sürümler, grup ortalamasında “iyi” görünürken gerçek kullanıcıyı yavaşlatabilir.
İkinci perdeleme katmanı 28 günlük kayan penceredir. CrUX Tools sayfasına göre Search Console ve PageSpeed Insights saha verisi günlük güncellenir, ancak önceki 28 günün toplulaştırılmış görünümünü sunar. Bu şu anlama gelir: dün eklenen ağır bir kişiselleştirme scripti veya geçen hafta bozulan sunucu yanıt süresi, raporda hemen sert biçimde görünmeyebilir. Aynı şekilde kısa süreli iyileştirmeler de anında büyük zafer gibi görünmez. Rapor doğası gereği stabildir; bu da onu karar vermek için değerli kılar, ama anlık teşhis için yetersiz bırakır.
2026 tarafında bu farkı daha görünür yapan iyi bir örnek var. Chrome UX Report release notes içinde Haziran 2026 verisi 14 Temmuz 2026’da yayımlandı ve küçük mevsimsel gerilemelerin kısa dönem kıyasları yanıltabileceği not edildi. Bu detay önemli; çünkü bazı ekipler tek bir haftalık düşüşü gerçek bozulma sanıyor. Oysa sahadaki dağılım, cihaz karışımı ve mevsimsel trafik değişimi de raporun tonunu etkileyebilir. Bu yüzden “iyi görünüyor ama kullanıcı şikâyet ediyor” senaryosunda tek güne değil, segment ve akış bazında okumaya ihtiyaç vardır.
LCP, INP ve CLS iyi olsa bile hangi darboğazlar kullanıcıya yavaş gelir?
LCP iyi olsa bile sayfa ağır hissedebilir; çünkü büyük görsel veya hero başlığı zamanında gelirken asıl işlevler geç açılıyor olabilir. Bunun en net örneği TTFB ile sonradan başlayan JavaScript yüküdür. Kullanıcı üst alanı gördüğü için rapor iyi görünür, fakat ürün filtresi, sepet butonu, fiyat varyasyonu veya arama kutusu geç etkileşime giriyorsa deneyim akıcı hissedilmez. Özellikle SPA veya yoğun hydration kullanan yapılarda “görüntü var ama sayfa hazır değil” duygusu çok yaygındır.
INP iyi çıktığında da her etkileşimin iyi olduğu sanılmamalı. INP, en problemli etkileşimlerin genel dağılımını özetler; fakat bazı akışlar az trafik aldığı için veri setinde baskın olmayabilir. Örneğin giriş yapan kullanıcıların kullandığı kupon alanı, hesap paneli filtresi veya stok sorgulama bileşeni yalnızca küçük bir segmentte ağır çalışıyorsa toplu skor iyi kalabilir. Üçüncü taraf scriptler, tag manager kuralları, A/B testleri ve reklam etiketleri de özellikle düşük CPU’lu mobil cihazlarda ana iş parçacığını bloklayarak hissedilen yavaşlığı büyütür.
- Yüksek TTFB: İlk içerik gelse bile akışın geri kalanı gecikir.
- Büyük JS paketleri: Mobil CPU’da parse ve execute süresi uzar.
- Hydration gecikmesi: Arayüz görünür, ama butonlar geç canlanır.
- Üçüncü taraf etiketler: Ana iş parçacığında beklenmeyen long task üretir.
Algılanan hızda bir başka kırılım da bfcache tarafında oluşur. web.dev’in bfcache rehberi 2 Temmuz 2026 güncellemesinde geri-ileri gezinmenin neredeyse anlık hissettirebildiğini vurguluyor. Bu nedenle aynı kullanıcı ilk ziyarette sayfayı orta hızda algılarken, geri dönüp tekrar açtığında çok hızlı sanabilir. Tersine, bfcache’e uygun olmayan sayfalar tekrar ziyarette de tam yükleme yaşatır ve “bu site bazen çok hızlı, bazen çok yavaş” şikâyeti üretir. Ekip içinde ortak dil kurmak için web.dev tarafındaki güncel lab vs field data ve bfcache anlatımları burada faydalı olur.
Üç segmentli saha incelemesi: düşük Android, hızlı iPhone ve geri-ileri ziyaretçi
Performans incelemelerinde en sık gördüğümüz desen şu: aynı URL, raporda iyi görünür; ama düşük donanımlı Android cihazdaki kullanıcı sayfayı daha ağır hisseder. Bunun nedeni genellikle ağdan çok CPU tarafıdır. HTML ve hero alanı zamanında gelir, LCP eşiği geçilir; ancak filtre, menü, varyasyon seçici veya yorum sekmesi gibi bileşenler geç canlanır. Kullanıcı teknik olarak “yüklenmiş” bir sayfaya bakar, ama işini yapmaya başlayamaz. İşte hissedilen yavaşlık çoğu zaman tam burada başlar.
Aynı sayfa hızlı iPhone ve Wi-Fi senaryosunda çok daha temiz bir izlenim bırakabilir. Daha güçlü işlemci, daha iyi ağ koşulu ve tarayıcının daha rahat JS yürütmesi sayesinde üçüncü taraf etiketlerin veya büyük bileşenlerin maliyeti daha az hissedilir. Bu da ekip içinde yanıltıcı bir durum doğurur: masa başındaki testlerde sorun yoktur, müşteri şikâyeti ise gerçektir. web.dev’in lab ve field veri farkı rehberi tam olarak bu ayrımı anlatır; laboratuvar tutarlıdır, saha ise gerçek çeşitliliği taşır.
Üçüncü segment olan geri-ileri ziyaretçi ise algıyı daha da değiştirir. Kullanıcı liste sayfasından ürün detayına gidip tekrar geri döndüğünde bfcache devreye girerse deneyim çok hızlı hissedilir. Aynı URL’nin ilk ziyareti yavaş, ikinci ziyareti neredeyse anlık olabilir. Bu yüzden oturum kaydı, RUM kırılımı ve CrUX verisini yan yana okumadan “sayfa hızlı mı yavaş mı?” sorusuna tek cevap vermek sağlıklı değildir. Daha doğru soru şudur: hangi kullanıcı, hangi cihazda, hangi adımda yavaşlık hissediyor?
İyi skor ama yavaş his problemi nasıl doğrulanır: CrUX, PSI, Lighthouse, RUM ve SEOYEN
Doğrulama sırası önemlidir. Önce Search Console ve CrUX ile saha verisine bakılır; böylece problem site geneline mi, belirli cihaz tipine mi, yoksa yalnızca belirli şablonlara mı yayılmış anlaşılır. Sonra aynı URL’yi PageSpeed Insights içinde açıp alan verisi ile Lighthouse laboratuvar verisi yan yana okunur. CrUX Tools sayfasının da anlattığı gibi bu araçlar aynı kaynaktan beslense bile kapsamları farklıdır: Search Console sayfa grubu, PSI sayfa veya origin, Lighthouse ise kontrollü teşhis üretir. Bu farkı bilmeden araçlar birbirine zıt sonuç veriyormuş gibi görünür.
Bir sonraki katmanda RUM ve oturum kaydı devreye girmelidir. Çünkü kullanıcı “yavaş” dediğinde çoğu zaman kastettiği şey yalnızca yükleme süresi değildir; tıkladığında tepki alamamak, içerik görünse de filtreyi kullanamamak veya kişiselleştirme tamamlanana kadar beklemektir. Bu yüzden site sağlığı ve site audit bulguları tek başına yeterli değildir; bunların saha sinyaliyle birlikte yorumlanması gerekir. Sorunun sayfa genelinde mi, yalnızca girişli kullanıcıda mı, yoksa sadece düşük Android segmentinde mi yaşandığı ancak bu katmanlı okuma ile netleşir.
SEOYEN burada araç listesinden çok teşhis akışı tarafında öne çıkar: tek platformda SEO ve performans sinyallerini Türkçe arayüzle takip etmek, ekip içi karar hızını artırır; TL bazlı operasyon ve yerel destek de uygulamayı kolaylaştırır. Ahrefs ve SEMrush geniş veri ekosistemleri sunar; SEOYEN ise bunu Türkiye pazarına uyarlanmış yorumlama akışıyla tamamlar. Karşılaştırma mantığını derinleştirmek isterseniz Ahrefs karşılaştırması ve SEMrush karşılaştırması sayfaları yararlı çerçeve sunar. Operasyonel planlama için de doğrudan paket ve fiyat sayfası üzerinden güncel yapıya bakmak daha doğrudur.
Adım Adım: İyi CWV skoruna rağmen yavaş hissi doğrulama süreci
İyi Core Web Vitals skoru ile zayıf kullanıcı hissi arasındaki farkı çözmek için tek ekrana bakmak yetmez. Aşağıdaki sıra, sorunun gerçekten saha kaynaklı mı, şablon kaynaklı mı, yoksa ölçüm kör noktası mı olduğunu ayırmak için pratik bir teşhis akışı sunar.
- Önce alan verisini kullanıcı segmentleriyle kontrol et: Search Console ve CrUX tarafında mobil-masaüstü ayrımını, mümkünse ülke ve cihaz seviyesi kırılımlarını inceleyin. Amaç, şikâyetin tüm kullanıcıları mı yoksa dar bir segmenti mi etkilediğini ayırmaktır. Eğer yalnızca belirli şablonlar veya belirli cihaz sınıfları etkileniyorsa, toplu “iyi” görünüm sizi yanlış güvene sürükleyebilir.
- PSI içinde alan ve laboratuvarı ayrı oku: Aynı URL’de önce saha verisine, sonra Lighthouse çıktısına bakın. Alan verisi iyi ama laboratuvar kötü ise darboğaz henüz tüm kullanıcıları vurmuyor olabilir. Alan verisi kötü ama laboratuvar iyi ise sorun muhtemelen gerçek kullanıcı çeşitliliğinde, üçüncü taraf yüklerde veya oturum akışında saklıdır.
- CWV dışı hissedilen darboğazları listele: TTFB, render-blocking CSS, hydration, büyük JS paketleri, long task ve üçüncü taraf scriptler için ayrı bir kontrol listesi oluşturun. LCP veya INP eşiklerini geçmek, bu bileşenlerin kullanıcıya hiç zarar vermediği anlamına gelmez. Özellikle mobil CPU maliyeti burada kritik rol oynar.
- RUM ve oturum kaydıyla davranışı doğrula: Gerçek kullanıcıların hangi adımda beklediğini, ilk tıklamada tepki alıp almadığını ve giriş sonrası akışın nasıl değiştiğini izleyin. Bu aşama, “sayfa geç açılıyor” ile “sayfa açılıyor ama kullanılamıyor” ayrımını netleştirir. Kök neden çoğu zaman ikinci gruptadır.
- Şablon ve araç seviyesinde düzeltme önceliği ver: Sorunu sayfa geneli, sayfa grubu veya belirli şablon bazında sınıflandırın. Sonra iyileştirmeyi ölçüm planına bağlayın: hangi script kaldırılacak, hangi bileşen bölünecek, hangi şablon izlenecek? SEOYEN gibi Türkçe arayüzlü izleme akışları bu aşamada takibi ve ekip içi paylaşımı hızlandırır.
Bu sırayı uyguladığınızda “iyi skor ama yavaş his” problemini soyut bir şikâyet olmaktan çıkarıp ölçülebilir bir teşhis dosyasına dönüştürürsünüz. Asıl hedef puan toplamak değil, kullanıcının işini daha az bekleyerek tamamlamasını sağlamaktır.
| Kaynak | Ölçtüğü şey | Neyi kaçırabilir | Bu içerikte kullanım amacı |
|---|---|---|---|
| Search Console Core Web Vitals raporu | Benzer deneyime sahip URL gruplarının mobil ve masaüstü CWV durumu | Tekil URL sapmalarını, ülke ve bağlantı kalitesi kırılımını | Sorunun site geneline mi, belirli şablona mı ait olduğunu görmek |
| CrUX alan verisi | Gerçek Chrome kullanıcılarının 28 günlük saha deneyimi | Site içi olay akışını ve oturum açmış kullanıcı davranışını | Genel kullanıcı dağılımını ve segment riskini anlamak |
| PageSpeed Insights alan verisi | Sayfa veya origin düzeyinde CrUX saha verisi | Tarihçeyi, ülke boyutunu ve tüm özel segmentleri | Aynı URL’de alan ve lab farkını yan yana okumak |
| Lighthouse laboratuvar verisi | Kontrollü ortamda tek cihaz ve ağ simülasyonu | Gerçek kullanıcı çeşitliliğini ve zamansal üçüncü taraf etkilerini | Darboğazı yeniden üretmek ve teknik teşhis yapmak |
| Site içi RUM ve oturum kaydı | Gerçek oturumdaki tıklama, bekleme ve akış davranışı | Kurulum yoksa veri boşluğunu | Hangi segmentin hangi adımda yavaşlık hissettiğini doğrulamak |
Kaynaklar
Sıkça Sorulan Sorular
Çünkü Core Web Vitals, sitenin tüm deneyimini değil LCP, INP ve CLS gibi belirli performans sinyallerini özetler. Bir sayfa bu eşikleri geçse bile TTFB yüksek olabilir, JavaScript geç çalışabilir, üçüncü taraf scriptler ana iş parçacığını bloke edebilir veya kullanıcı sayfayı gördüğü hâlde etkileşime başlayamayabilir. Ayrıca saha verisi 28 günlük bir pencereye dayandığı için yeni başlayan sorunlar hemen görünmez. Özellikle düşük donanımlı mobil kullanıcılar, ortalama iyi görünse de belirgin yavaşlık hissedebilir.
PageSpeed Insights iki farklı veri türünü aynı ekranda gösterir: alan verisi ve laboratuvar verisi. Alan verisi, CrUX üzerinden gerçek kullanıcıların son 28 gündeki deneyimlerinden gelir. laboratuvar verisi ise Lighthouse’ın kontrollü bir cihaz ve ağ simülasyonundan oluşur. Bu nedenle aynı URL, laboratuvarda kötü ama sahada iyi ya da tam tersi görünebilir. Ayrıca PSI bazen sayfa düzeyinde yeterli veri yoksa origin düzeyine düşer. Farklılık genellikle ölçüm hatası değil, kapsam farkıdır.
Search Console Core Web Vitals raporu, CrUX tabanlı gerçek kullanıcı verileriyle LCP, INP ve CLS performansını özetler. Rapor çoğu zaman tek tek URL’leri değil, benzer deneyim sunan URL gruplarını gösterir ve mobil ile masaüstü için ayrı görünüm sunar. Değerlendirme sahadaki toplulaştırılmış deneyime dayanır. bu nedenle tekil bir sayfanın ya da az trafik alan bir akışın sorunu grup içinde kaybolabilir. Rapor site genel eğilimi görmek için güçlüdür, fakat tek URL teşhisinde tek başına yeterli değildir.
Laboratuvar verisi, kontrollü bir ortamda önceden tanımlanmış cihaz ve ağ koşullarıyla yapılan sentetik ölçümdür. Lighthouse bunun tipik örneğidir. Alan verisi ise gerçek kullanıcıların farklı cihaz, bağlantı, ülke ve oturum koşullarındaki deneyimlerinden oluşur. CrUX ve RUM bu sınıfa girer. Bu yüzden laboratuvar verisi tekrar üretilebilir ve hata ayıklamak için iyidir, alan verisi ise gerçekte kimin zorlandığını gösterir. Performans kararlarında ikisini karşıt değil, tamamlayıcı okumak gerekir.
Çünkü toplulaştırılmış raporlar küçük ama kritik segmentleri gizleyebilir. Düşük donanımlı Android cihazlar, zayıf 4G bağlantısı kullanan kullanıcılar veya giriş sonrası daha ağır bileşen gören ziyaretçiler veri setinde azınlıkta kalırsa, genel skor yine iyi çıkabilir. Üstelik Search Console veriyi URL grubu halinde gösterdiği için tek bir şablondaki sorun tüm grubu bozmayabilir. Bu nedenle mobil şikâyet geldiğinde sadece ortalama skora değil, segment ve akış bazında saha verisine bakmak gerekir.
Üçüncü taraf scriptler, ana iş parçacığında ek parse, execute ve long task yükü oluşturarak özellikle mobil cihazlarda hissedilen yavaşlığı artırır. Reklam kodları, etiket yöneticisi kuralları, kişiselleştirme katmanları ve A/B test araçları sayfa görünür olduktan sonra da çalışmaya devam edebilir. Bu durumda kullanıcı içerği görür ama butonların tepki vermesini bekler. CWV metriği tamamen bozulmasa bile deneyim ağırlaşır. Bu yüzden script etkisini yalnızca yükleme anında değil, etkileşim sonrası akışta da ölçmek gerekir.