Ölçülmesi Gerekenler: Kullanıcı Odaklı Performans için Temel Metrikler (Olculmesi Gerekenler Kullanici Odakli Performans Metrikleri)

Kullanıcı odaklı performans ölçümü

Kullanıcı odaklı performans ölçümü, sistemin trafik üretip üretmediğine veya teknik olarak yüklenip yüklenmediğine değil; insanların hedeflerine hızlı, kolay, güvenilir ve tatmin edici biçimde ulaşıp ulaşmadığına bakar. En güçlü ölçüm sistemleri davranış verisini, kullanıcı algısını, iş sonuçlarını ve teknik performansı birlikte okur.

1. Kullanıcı davranışı metrikleri

Bunlar kullanıcıların gerçekte ne yaptığını gösterir:

• Görev tamamlama oranı: Tanımlı bir görevi başarıyla bitiren kullanıcı yüzdesi.
• Görev süresi: Hedefe ulaşmak için gereken süre.
• Hata oranı: Başarısız eylemler, doğrulama hataları veya sistem hatalarının sıklığı.
• Hata kurtarma oranı: Hatadan sonra toparlanıp görevi bitiren kullanıcı yüzdesi.
• Özellik benimseme: Uygun kullanıcıların belirli bir dönemde özelliği kullanma oranı.
• Huni terki: Çok adımlı süreçte kullanıcıların nerede düştüğü.
• Değere ulaşma süresi: Kayıt veya giriş ile ilk anlamlı sonuç arasındaki süre.

Davranış metrikleri, belirli bir kullanıcı hedefine bağlandığında en işe yarar—örneğin yalnızca “tıklamayı artırmak” yerine “ödemeyi tamamlamak”. GitLab’ın UX çerçevesi görev tamamlama, görev süresi, hatalar, ilk tıklama doğruluğu ve özellik benimsemeyi temel davranış ölçüleri sayar. handbook.gitlab

2. Kullanıcı algısı metrikleri

Analitik ne olduğunu gösterir; tutum metrikleri nedenini açıklamaya yardım eder:

• Müşteri memnuniyeti (CSAT): Deneyimden ne kadar memnun oldukları.
• Algılanan kullanım kolaylığı: Ürünün kullanmayı ne kadar kolay hissettirdiği.
• Müşteri çaba skoru (CES): Harcadıklarına inandıkları çaba.
• Algılanan verimlilik: Ürünün zaman kazandırıp kazandırmadığı.
• Net Tavsiye Skoru (NPS): Ürünü önerme olasılığı.
• Algılanan fayda: Anlamlı bir sorunu çözüp çözmediği.

Bir ürün yüksek görev tamamlama oranına sahip olup yine de sinir bozucu veya gereksiz zor hissedilebilir. Bu yüzden davranışsal ve tutumsal ölçüler birlikte değerlendirilmelidir. handbook.gitlab

3. Tutma ve değer metrikleri

Bunlar ürünün süregelen değer verip vermediğini gösterir:

• Aktivasyon oranı: Yeni kullanıcıların ilk anlamlı eylemi tamamlama yüzdesi.
• Tutma oranı: Belirli bir süre sonra dönüp aktif kalan kullanıcı yüzdesi.
• Kayıp (churn) oranı: Ürünü kullanmayı bırakan kullanıcı yüzdesi.
• DAU/WAU/MAU: Günlük, haftalık ve aylık aktif kullanıcılar.
• Yapışkanlık: Genellikle DAU÷MAU oranı olarak yaklaşılır.
• Kohort tutma: Kayıt tarihine veya ortak özelliğe göre grupların ayrı izlenmesi.
• Yönlendirme oranı: Kullanıcıların başkalarını ne sıklıkla tavsiye veya davet ettiği.

İşlevsel bir yapı: kullanıcıya verilen değeri temsil eden bir Kuzey Yıldızı Metriği tanımlamak, sonra ekiplerin etkileyebileceği iki-üç girdi metriği seçmektir. Örneğin bir iş birliği ürünü Kuzey Yıldızı olarak “haftalık başarılı iş birlikleri”ni; destekleyici olarak aktivasyon, özellik benimseme ve tutmayı kullanabilir. youtube

4. Teknik performans metrikleri

Dijital ürünlerde teknik hız, kullanıcının bakış açısından ölçülmelidir:

Kullanıcı deneyimi	Yararlı metrikler
İlk görünürlük	First Contentful Paint (FCP), Largest Contentful Paint (LCP)
Yanıt verebilirlik	Interaction to Next Paint (INP), Total Blocking Time (TBT)
Kararlılık	Cumulative Layout Shift (CLS)
Sunucu yanıtı	Time to First Byte (TTFB)
Akıcılık	Kare tutarlılığı ve animasyon yanıtı
Güvenilirlik	Çökme, başarısız istek, kesinti ve hata oranları

Web performansı hem kontrollü laboratuvar testlerinde hem de gerçek kullanıcı izlemede (RUM) ölçülmelidir; çünkü cihaz, ağ, kişiselleştirme ve etkileşim deneyimi kökten değiştirir. web

5. Pratik bir ölçüm seti

Çoğu ekip beş metrikle başlayabilir:

1. Bir değer metriği: Kullanıcıların gelme nedeni olan birincil sonuç.
2. Bir davranış metriği: Görev tamamlama oranı veya görev süresi.
3. Bir algı metriği: CSAT, CES veya algılanan kullanım kolaylığı.
4. Bir tutma metriği: Kohort tutma veya tekrar kullanım.
5. Bir güvenilirlik veya performans metriği: Hata oranı, INP, LCP veya uptime.

İyi metrikler açık, normalize, zaman içinde karşılaştırılabilir, anlamlı kullanıcı gruplarına göre dilimlenmiş ve eyleme dönüştürülebilir olmalıdır. Yalnızca toplam sayfa görüntüleme, indirme, kayıtlı kullanıcı veya oturum süresine güvenmeyin; bunlar anlamlı değer üretmeden de büyüyebilir. youtube

Örnek

Çevrimiçi bir masraf iadesi hizmeti için:

• Kuzey Yıldızı: Aktif çalışan başına başarıyla iade edilen talepler.
• Davranış: Talep tamamlama oranı ve medyan gönderim süresi.
• Algı: Gönderim sonrası kullanım kolaylığı skoru.
• Tutma: 90 gün içinde ikinci talep gönderen çalışan yüzdesi.
• Teknik: Fiş yükleme sırasında hata oranı ve INP.
• Tanı: Fiş doğrulama adımındaki terk oranı.

Bu kombinasyon yalnızca kaç kişinin sürece girdiğini değil; tamamlayıp tamamlayamadıklarını, deneyimin nasıl hissettirdiğini, geri dönüp dönmediklerini ve teknik sorunların başarıyı engelleyip engellemediğini gösterir.

Bu bölümde tekrarlayan kavramlar

📦 Laboratuvar vs saha
Kontrollü, tekrarlanabilir teşhis ile gerçek kullanıcı ortamındaki doğrulama.

📦 Core Web Vitals (CWV)
LCP, INP ve CLS—yükleme, yanıt ve görsel kararlılık; gerçek kullanıcıların 75. yüzdeliğinde.

📦 FID → INP (Mart 2024)
FID yalnızca ilk girdi gecikmesini ölçüyordu; INP ziyaret boyunca etkileşim yanıtını ölçer.

📦 RUM
Gerçek kullanıcı izleme: cihaz, ağ, rota ve özellik boyutlarında production ölçümü.

📦 CrUX
Chrome kullanıcı deneyimi raporu—uygun siteler için kamuya açık saha verisi.

📦 Performans bütçesi
LCP/INP/CLS, JS ağırlığı, üçüncü taraf maliyeti ve iş akışı başarı limitleri.

📦 Attribution (ilişkilendirme)
web-vitals attribution build: LCP öğesi, INP hedefi, LoAF ve alt faz süreleri.

Bu kavramlar önemlidir çünkü bölüm ölçümü “skor takibi”nden ayırır: lab nedeni bulur, saha gerçekliği doğrular, bütçeler regresyonu engeller—yapay zekâ ve üçüncü taraf yükleri sessizce gecikmeleri büyütmeden önce.

Laboratuvar testleri ve saha ölçümleri

Kullanıcı odaklı performansta laboratuvar testi ürünü kontrollü, tekrarlanabilir koşullarda ölçer; saha ölçümü ise kullanıcıların gerçek ortamındaki performansı gözlemler. Lab sonuçları sorunun nedenini bulmak için genelde daha iyidir; saha sonuçları ürünün günlük kullanımda işe yarayıp yaramadığını anlamak için daha iyidir. web.mit

Laboratuvar testi

Laboratuvar testi kullanıcıları, görevleri, cihazları ve koşulları tanımlı bir protokole yerleştirir.

Tipik ölçüler:

• Görev tamamlama oranı.
• Görev süresi.
• Hata sıklığı ve kurtarma.
• Gezinme veya tıklama yolları.
• İlk tıklama doğruluğu.
• Algılanan kullanılabilirlik ve iş yükü.
• Görev sonrası memnuniyet.
• Tasarım sürümleri arası karşılaştırma.

Güçlü yanlar: yüksek kontrol ve tekrarlanabilirlik; rakip tasarımları karşılaştırmak kolaydır; belirli arayüz sorunlarını izole eder; prototip ve kontrollü A/B tarzı deneyler için uygundur.

Sınırlar: katılımcılar gözlendiklerini bildikleri için farklı davranabilir; yapay görevler gerçek öncelikleri yansıtmayabilir; sessiz bir test odası her işyeri, ağ veya teknik koşulu üretemez. Lab, gerçek bağlam daha zorlayıcıysa kullanılabilirliği abartabilir.

Lab ile saha kullanılabilirlik testlerini karşılaştıran araştırmalar evrensel bir kazanan bulmaz: koşullar elverişliyken sonuçlar benzer olabilir; zor koşullar, zayıf kullanılabilirlik veya yarışan görevlerde farklar çıkar. pubmed.ncbi.nlm.nih

Saha ölçümleri

Saha ölçümü kullanıcıların normalde çalıştığı, yolculuk ettiği, alışveriş yaptığı veya ürünü işlettiği yerde yapılır. Doğrudan gözlem, bağlamsal görüşme, günlük çalışması, uzak telemetri veya sahada kullanılabilirlik testi içerebilir.

Yararlı saha ölçüleri: gerçek dünya görev başarısı; kesintiler dahil süre; çevre ve ağ koşulları; cihaz/platform farkları; hata sıklığı ve şiddeti; geçici çözümler; tekrar kullanım ve tutma; gecikme, çökme ve başarısız istekler; iş akışına uyum hakkındaki kullanıcı yorumları.

Güçlü yanlar: otantik davranış ve bağlam; dikkat dağınıklığı, altyapı veya çevre araçlarından kaynaklı sorunları ortaya çıkarır; ürünün gerçek rutinlere entegre olup olmadığını gösterir. Özellikle mobil, işyeri, endüstriyel, sağlık ve konuma bağlı ürünlerde değerlidir.

Sınırlar: değişkenler üzerinde daha az kontrol; katılımcıları doğrudan karşılaştırmak zor; veri daha gürültülü olabilir; gizlilik ve onay gereksinimleri daha ağırdır.

Alan gerçekçilikte, laboratuvar kesinlik ve kontrolde güçlidir. web.mit

Ne ölçülür?

Soru	Lab ölçüleri	Saha ölçüleri
Kullanıcılar görevi tamamlayabilir mi?	Tanımlı senaryoda tamamlama oranı	Gerçek iş sırasında tamamlama oranı
Ne kadar verimli çalışırlar?	Görev süresi, tıklama, tuş vuruşu	Kesinti, geçiş ve geçici çözümler dahil süre
Ne ters gider?	Gözlenen hatalar ve başarısız etkileşimler	Production hataları, destek talepleri, terk edilen görevler
Nasıl hissettirir?	Memnuniyet, iş yükü, algılanan kullanılabilirlik	Uzun vadeli memnuniyet, güven, hayal kırıklığı, algılanan değer
Güvenilir mi?	Kontrollü yanıt süresi ve cihaz testleri	Gerçek gecikme, bağlantı varyasyonu, çökme ve arızalar
Değer üretir mi?	Anlık görev sonucu	Tekrar kullanım, tutma, benimseme ve iş/kullanıcı sonuçları

Önerilen yaklaşım

İkisini döngü olarak kullanın; tekini seçmeyin:

1. Lab’de başlayın—bariz kullanılabilirlik sorunlarını bulun, alternatifleri karşılaştırın.
2. Sahada ölçün—otantik koşullarda davranışı test edin.
3. Lab’e dönün—önemli saha sorunlarının nedenini araştırın.
4. Production’da doğrulayın—analitik, geri bildirim ve performans izleme ile.
5. Sonuçları dilimleyin—cihaz, deneyim, erişilebilirlik ihtiyacı, konum, bağlantı ve görev tipi.

Örnek: mobil bir masraf uygulaması lab’de %95 gönderim oranı alabilir. Saha, zayıf ışıkta fiş fotoğraflarken veya zayıf mobil ağda terkleri ortaya çıkarabilir. Lab arayüz sorununu gösterir; saha onu önemli kılan çevre ve teknik koşulları açığa çıkarır.

Temel ilke: laboratuvar yeteneği açıklar; saha gerçek dünya performansını doğrular. İnanılır bir kullanıcı odaklı değerlendirme genelde ikisini de ister.

Core Web Vitals: kilit metrikler

Core Web Vitals (CWV), Google’ın bir sayfa deneyiminin üç parçasını—yükleme, yanıt verebilirlik ve görsel kararlılık—değerlendiren kullanıcı merkezli metrikleridir. Güncel set LCP, INP ve CLS’tir. web

Metrik	Ne ölçer	İyi hedef
Largest Contentful Paint (LCP)	Ana görünür içeriğin—hero görseli, başlık veya büyük metin bloğu—ne kadar çabuk göründüğü	≤ 2.5 saniye
Interaction to Next Paint (INP)	Ziyaret boyunca tıklama, dokunma ve klavye etkileşimlerine görsel yanıtın ne kadar çabuk olduğu	≤ 200 milisaniye
Cumulative Layout Shift (CLS)	Sayfa yüklenirken veya kullanılırken görünür içeriğin beklenmedik ne kadar kaydığı	≤ 0.1

Her metrik ne söyler?

• LCP — yükleme: “Kullanıcılar önemli içeriği hızlı görebilir mi?”
• INP — yanıt: “Kullanıcılar etkileşime girdiğinde arayüz hemen yanıt verir mi?”
• CLS — kararlılık: “Sayfa beklenmedik kaymadan okuyup tıklayabilirler mi?”

INP, First Input Delay (FID)’in yerini 2024’te almıştır—resmi geçiş 12 Mart 2024. FID yalnızca ilk etkileşimi ölçüyordu; INP ziyaret boyunca etkileşim yanıtını değerlendirir. Tarayıcı araçlarında FID desteği Eylül 2024 itibarıyla sonlandırılmıştır. dynatrace · developer.chrome

CWV nasıl değerlendirilir?

Gerçek kullanıcı verisini 75. yüzdelikte, mobil ve masaüstü için ayrı ölçün. Bir sayfanın genel olarak “iyi” CWV değerlendirmesi alması için üç metriğin de “iyi” eşiğini karşılaması gerekir. web

Lighthouse ve Chrome DevTools sorun teşhisi için yararlıdır; gerçek kullanıcı saha verisi cihaz, ağ ve konumlar boyunca gerçek performansı gösterir. PageSpeed Insights, CrUX ve Search Console bu sonuçları izlemeye yardım eder. web

Tipik iyileştirme eylemleri

• LCP: görselleri optimize edin, render engelleyici kaynakları azaltın, sunucu yanıtını iyileştirin, above-the-fold içeriği önceliklendirin.
• INP: uzun JavaScript görevlerini bölün, ana iş parçacığı işini sınırlayın, olay işleyicilerini hızlandırın.
• CLS: görsel ve reklamlara alan ayırın, mevcut içeriğin üstüne içerik sokmayın, font ve boyutları sabitleyin.

CWV değerli teknik göstergelerdir; ama görev tamamlama, terk, memnuniyet ve dönüşüm gibi kullanıcı odaklı sonuçlarla birleştirilmelidir. Hızlı bir sayfa mutlaka yararlı veya başarılı bir sayfa değildir.

Largest Contentful Paint (LCP)

LCP, kullanıcının bir sayfayı açmasından sonra ana görünür içeriğin ne kadar çabuk belirdiğini ölçer. Görünüm alanındaki en büyük görsel, video karesi veya metin bloğunun render’ının tamamlandığı anı kaydeder; algılanan yükleme hızının güçlü bir göstergesidir. web

LCP sayılan nedir?

LCP öğesi sıklıkla: hero veya banner görseli; belirgin başlık veya metin bloğu; ürün görseli; video posteri veya ilk görünür video karesi; CSS ile yüklenen büyük bir görseldir.

LCP, First Contentful Paint (FCP)’ten farklıdır: FCP herhangi bir içeriğin ilk göründüğü anı ölçer; LCP birincil içeriğin görünür olduğu anı tahmin eder. web

LCP eşikleri

LCP sonucu	Deneyim
2.5 saniye veya daha az	İyi
2.5’ten fazla – 4 saniye	Geliştirilmeli
4 saniyeden fazla	Zayıf

Sayfa yüklemelerinin 75. yüzdeliğini, en azından mobil ve masaüstü ayrı, değerlendirin—sonuç yalnızca ortalamayı değil çoğu kullanıcıyı temsil etsin. web

Yavaş LCP’ye ne yol açar?

LCP genelde dört gecikmeden oluşur:

1. Sunucu yanıt gecikmesi: Tarayıcı ilk HTML yanıtını bekler (TTFB).
2. Yükleme gecikmesi: Tarayıcı LCP kaynağını geç keşfeder veya geç istemeye başlar.
3. Kaynak yükleme süresi: Görsel, video, font veya diğer içerik indirmesi uzun sürer.
4. Render gecikmesi: Kaynak hazırdır ama JavaScript, CSS veya diğer iş ekrana çizmeyi geciktirir. developer.chrome

HTTP Archive Web Almanac 2024’e göre mobil sayfaların yaklaşık %73’ünde LCP öğesi bir görseldir; görsel tabanlı LCP metin tabanlıya göre yaklaşık iki kat daha yavaş olma eğilimindedir. Above-the-fold LCP görselinde lazy-loading’i kapatmak ve gerektiğinde fetchpriority="high" ile ağ önceliği vermek kritik bütçeyi korur.

LCP nasıl iyileştirilir?

• Sunucu yanıtını iyileştirin; etkili önbellek veya CDN kullanın.
• LCP görselini optimize edin ve doğru boyutlandırın.
• Modern formatlar ve uygun sıkıştırma kullanın.
• Keşif geciktiğinde yalnızca kritik LCP kaynağını preload edin.
• Above-the-fold LCP görselini lazy-load etmeyin.
• Render engelleyici CSS ve gereksiz JavaScript’i kaldırın.
• Uzun ana iş parçacığı görevlerini azaltın.
• Web fontları yüklenirken önemli metnin hızlı görünmesini sağlayın.
• Aşırı yönlendirme ve kritik istek zincirlerinden kaçının.

Nedeni teşhis etmek için Lighthouse gibi lab araçlarını kullanın; iyileştirmeyi gerçek kullanıcı saha verisiyle doğrulayın. Kontrollü testte iyi görünen bir sayfa, yavaş cihaz veya ağdaki kullanıcılar için hâlâ zayıf LCP üretebilir.

FID, INP ve CLS

Bu metrikler deneyimin iki farklı parçasını kapsar: yanıt verebilirlik—sayfanın girdiye ne kadar çabuk tepki verdiği—ve görsel kararlılık—içeriğin kullanıcıların beklediği yerde kalıp kalmadığı.

First Input Delay (FID)

FID, kullanıcının ilk etkileşimi ile tarayıcının onu işlemeye başlaması arasındaki gecikmeyi ölçüyordu. Yalnızca ilk girdi gecikmesini yakalıyordu—örneğin bir düğmeye dokunma ile olay işleyicisinin başlaması arası.

FID, başlangıçta JavaScript ile bloke olan sayfaları tespit etmekte işe yarıyordu; ama tam etkileşimi veya sonraki etkileşimleri ölçmüyordu. FID artık Core Web Vital olarak emekliye ayrılmış ve INP ile değiştirilmiştir. developer.chrome

FID’nin mimari eksiği, geliştiricilerin olayları asenkronlaştırarak skoru yapay iyileştirmesine izin vermesiydi; arka planda uzun görevler sürerken kullanıcı sayfayı donuk hissedebiliyordu. INP bu kör noktayı kapatır.

Interaction to Next Paint (INP)

INP, ziyaret boyunca kullanıcı etkileşimlerine görsel yanıtın ne kadar çabuk olduğunu ölçer. Girdi gecikmesi, olay işleyici işleme, render işi ve bir sonraki ekran güncellemesine kadar süreyi içerir. web

Örnekler: gezinme menüsüne tıklama; arama alanına yazma; sepete ekle’ye dokunma; diyalog veya açılır menü açma; filtre veya sekme seçme.

INP skoru	Yanıt verebilirlik
≤ 200 ms	İyi
> 200 – 500 ms	Geliştirilmeli
> 500 ms	Zayıf

İyi INP, gerçek sayfa ziyaretlerinin 75. yüzdeliğinde—genelde mobil ve masaüstü ayrı—değerlendirilir. web

INP üç alt faza ayrılır: girdi gecikmesi (ana iş parçacığı meşgulse), işleme süresi (ağır olay işleyicileri), sunum gecikmesi (stil/layout/paint ve büyük DOM). Optimizasyon hangi fazın baskın olduğuna göre değişir.

INP’yi iyileştirmek

• Uzun JavaScript görevlerini bölün (scheduler.yield() veya zamanlayıcı API’leri).
• Gereksiz JavaScript ve üçüncü taraf betikleri azaltın.
• Olay işleyicilerini küçük ve verimli tutun.
• Zorunlu olmayan işi etkileşimden sonraya erteleyin.
• Aşırı DOM güncellemelerinden kaçının.
• Verimli render ve animasyon teknikleri kullanın.
• Sayfa yükü sırasında ana iş parçacığı blokajını azaltın.

Long Animation Frames (LoAF) API’si, 50 ms’yi aşan görselleştirme güncellemelerini INP teşhisinde ortaya çıkarır: invoker, betik tipi ve sourceURL / karakter konumu ile suçlu kodu işaretler.

Cumulative Layout Shift (CLS)

CLS, görünür içeriğin beklenmedik hareketini ölçer. Yüksek CLS, düğme, metin veya görsellerin göründükten sonra kayması demektir; kullanıcılar yerini kaybedebilir veya yanlış kontrole tıklayabilir. web

Yaygın nedenler: boyutları ayrılmamış görsel/video; mevcut içeriğin üstüne sokulan reklam veya banner; geç yüklenen fontların metin boyutunu değiştirmesi; dinamik bildirimler; görünür olduktan sonra layout değiştiren JavaScript.

CLS skoru	Görsel kararlılık
≤ 0.1	İyi
> 0.1 – 0.25	Geliştirilmeli
> 0.25	Zayıf

CLS birimsiz bir skorudur, zaman ölçümü değildir. Hem etkilenen görünüm alanı oranını hem de kayma mesafesini dikkate alır. docs.newrelic

CLS’yi iyileştirmek

• Görsel ve videolara açık width ve height verin.
• Reklam, embed ve dinamik içerik için alan ayırın.
• Zaten görünür içeriğin üstüne içerik sokmayın.
• Önemli fontları preload edin veya sabitleyin.
• Animasyonlarda layout özelliklerinden ziyade transform ve opacity tercih edin.
• Nihai içerikle aynı boyutlarda placeholder kullanın.
• content-visibility: auto kullanıyorsanız kaymayı önlemek için contain-intrinsic-size ile yer ayırın.

Pratik ayrım

• FID: Tarayıcı ilk etkileşime hızlı işlemeye başladı mı? (tarihsel)
• INP: Sayfa ziyaret boyunca etkileşimlere hızlı yanıt veriyor mu?
• CLS: Kullanıcılar okuyup etkileşirken sayfa görsel olarak kararlı mı?

Güncel Core Web Vitals raporlamasında INP ve CLS’e odaklanın; FID çoğunlukla eski raporları veya tarihsel veriyi yorumlarken anlamlıdır.

Core Web Vitals’ın ötesi

LCP, INP ve CLS zorunludur; ama her performans sorununu açıklamaz. Destekleyici metrikler nedenleri teşhis eder; ürün ve iş metrikleri teknik iyileştirmelerin kullanıcıya gerçekten yarayıp yaramadığını gösterir.

Destekleyici metrikler ve raporları yorumlama

Metrik	Ne açıklamaya yardım eder
First Contentful Paint (FCP)	Kullanıcıların herhangi bir sayfa içeriğini ilk gördüğü an
Time to First Byte (TTFB)	Sunucu, ağ ve backend yanıt gecikmesi
Total Blocking Time (TBT)	Lab testlerinde ana iş parçacığı blokajı
Speed Index	Görünür içeriğin kademeli olarak ne kadar çabuk belirdiği
Kaynak ağırlığı	JavaScript, CSS, görsel, font ve üçüncü taraf yük boyutu
Uzun görevler / LoAF	Ana iş parçacığını bloke eden JavaScript ve uzun animasyon kareleri
Hata ve başarısızlık oranı	İstek, betik veya kritik iş akışlarının başarısız olup olmadığı
Dönüşüm, terk ve görev başarısı	Performansın kullanıcı sonuçlarını etkileyip etkilemediği

FCP ve TTFB, LCP teşhisinde özellikle yararlıdır: TTFB sunucu gecikmesini, FCP render engelleme veya erken render sorunlarını ortaya çıkarabilir. TBT esas olarak bir lab teşhisidir; saha INP’nin yerine geçmez. web

Raporları yorumlarken:

1. Saha verisiyle başlayın; etkilenen sayfa, cihaz, coğrafya, tarayıcı ve kullanıcı segmentini bulun.
2. Ortalamalara değil 75. yüzdeliğe bakın.
3. “Kullanıcıların deneyimlediği” ile “neden olanı” ayırın.
4. Nedeni yeniden üretmek ve izole etmek için lab araçlarını kullanın.
5. Yalnızca en düşük skorlu sayfaları değil; önemli yolculukları etkileyen sorunları önceliklendirin.
6. Hipotez kurun, hedefli bir değişiklik yapın, yeniden ölçün.
7. Değişikliğin hem performansı hem de tamamlama veya dönüşüm gibi bir kullanıcı sonucunu iyileştirdiğini doğrulayın.

Lighthouse skorunu hedef sanmayın. Amaç “100” değildir; gerçek kullanıcılar için daha hızlı, daha yanıtlı, daha kararlı deneyimlerdir.

Gelişen istemci mimarileri (kısa)

SPA’larda soft navigation LCP’yi sıfırlamaz ve CLS birikmeye devam edebilir. Deneysel Soft Navigations API, kullanıcı eylemi + URL değişimi + görünür paint koşullarında soft navigation’ı tespit ederek ara geçiş LCP’sinin RUM’da ölçülmesine kapı açar. Speculation Rules API ile prerender/prefetch, LCP’yi sıfıra yaklaştırabilir (Ray-Ban örneği izleme bölümünde). Üçüncü taraf etiket ağırlığını tarayıcıdan almak için sGTM (Server-Side Tag Manager) ana iş parçacığı ve DNS/TLS maliyetini düşürür—INP ve LCP’ye doğrudan yansır.

Laboratuvar araçları

Lighthouse: performans denetimi

Lighthouse performans, erişilebilirlik, SEO, en iyi uygulamalar ve PWA özellikleri için otomatik denetimler sunar. Performans raporu metrikler, tanı denetimleri, fırsatlar ve önerilen iyileştirme bağlantıları içerir. developer.chrome

Lighthouse’u şunlar için kullanın:

• Pull-request veya build kontrolleri.
• Tekrarlanabilir temel çizgi karşılaştırmaları.
• Render engelleyici kaynakları tespit etmek.
• Aşırı büyük görseller ve kullanılmayan JavaScript bulmak.
• LCP, CLS, FCP, TBT ve ilgili lab metriklerini araştırmak.
• Saha trafiği az veya yok olan sayfaları test etmek.

Tutarlı koşullarla çalıştırın—aynı URL, cihaz emülasyonu, ağ profili, kimlik doğrulama durumu ve tekrarlar. Tek koşuları gürültülü sayın; medyan veya trendlere bakın. Lighthouse CI’da numberOfRuns (ör. 3–5) ve metrik tabanlı assertions, skor gürültüsüne göre daha güvenilir kapılar oluşturur.

Chrome DevTools Performance paneli: derin teşhis ve yapay zekâ yardımı

Performance paneli ağ etkinliği, CPU işi, JavaScript yürütme, render, layout, paint ve kullanıcı etkileşimlerini içeren bir tarayıcı izi kaydeder. Lighthouse bir semptom bulduğunda ama tam bloke edici etkinliği bulmanız gerektiğinde kullanılacak araçtır. developer.chrome

Pratik iş akışı:

• Sayfa yükünü veya yavaş bir etkileşimi kaydedin.
• Insights görünümünde LCP fazları, render engelleyici istekler, layout-shift suçluları ve uzun görevlere bakın.
• Ana zaman çizelgesi ve flame chart ile sorumlu betik, stil yeniden hesaplama, layout veya paint’i bulun.
• İzi Network paneli ve etkilenen DOM öğesiyle ilişkilendirin.
• Düzeltmeden sonra yeniden kaydedin.

Chrome DevTools, kaydedilmiş performans profilleri için yapay zekâ yardımı da sunar. Seçili insight veya iz etkinliklerini açıklayabilir ve olası iyileştirmeler önerebilir; analiz yardımcısı olarak kullanın, her öneriyi iz ve kodunuza karşı doğrulayın. developer.chrome LoAF kayıtları INP darboğazını fonksiyon ve kaynak konumuna kadar daraltır.

WebPageTest: gerçekçi test ve ileri analiz

WebPageTest konumlar, tarayıcılar, cihazlar, bağlantı profilleri ve tekrarlı koşular boyunca gerçekçi, ileri test için yararlıdır. Filmstrip kullanıcıların zaman içinde ne gördüğünü; waterfall istek bağımlılıkları, zamanlama, öncelik ve kaynak gecikmelerini gösterir. performance.shopify

Şunları araştırırken kullanın:

• Belirli ülke veya bölgeden yavaş performans.
• Mobil cihaz ve yavaş ağ davranışı.
• İlk görünüm ile tekrar görünüm.
• CDN, DNS, TLS, sunucu ve bağlantı zamanlaması.
• Görsel keşfi ve istek önceliklendirme.
• Üçüncü taraf betikler ve waterfall darboğazları.
• Yalnızca nihai skor değil görsel ilerleme.
• Üçüncü taraf SPOF simülasyonu (etiket sunucusu düştüğünde kritik yolun bloke olup olmadığı).

Saha araçları

web-vitals.js ile sahada CWV yakalama

web-vitals kütüphanesi tarayıcıda Core Web Vitals’ı ölçer ve sonuçları analitik veya gözlemlenebilirlik sisteminize gönderir. Minimal bir uygulama:

<script type="module">
  import {onCLS, onINP, onLCP}
    from 'https://unpkg.com/web-vitals@4?module';

  function sendToAnalytics(metric) {
    navigator.sendBeacon('/rum', JSON.stringify({
      name: metric.name,
      value: metric.value,
      id: metric.id,
      path: location.pathname
    }));
  }

  onCLS(sendToAnalytics);
  onINP(sendToAnalytics);
  onLCP(sendToAnalytics);
</script>

Resmi kütüphane ayrıca bir attribution build sunar: LCP öğesi veya kaynağı, INP için inputDelay / processingDuration / presentationDelay, interactionTarget ve LoAF kayıtları gibi hata ayıklama bağlamı ekler. Skor yerine suçlu koordinatı verir. developers.google

Production’da gizlilik-güvenli boyutlar ekleyin: sayfa şablonu ve rota; cihaz sınıfı ve bağlantı tipi; tarayıcı ve işletim sistemi; ülke veya bölge; sürüm; oturum açmış / anonim; deney veya özellik bayrağı.

URL, kullanıcı kimliği, form içeriği veya diğer kişisel verileri gizlilik tasarımınız açıkça izin vermedikçe göndermeyin.

CrUX ve dış veri

Chrome User Experience Report (CrUX), popüler sitelerdeki uygun gerçek Chrome kullanıcılarının deneyimini temsil eder. LCP, INP, CLS ve diğer boyutlar için saha verisini PageSpeed Insights, Search Console, CrUX API ve BigQuery üzerinden sağlar. developer.chrome

CrUX şunlar için değerlidir: kamuya açık web’e karşı kıyaslama; performans sorunlarının gerçek kullanıcıları etkileyip etkilemediğini kontrol; bir sürümün saha performansını değiştirip değiştirmediğini doğrulama; mobil–masaüstü karşılaştırması; tarihsel trendler.

CrUX kapsama ve uygunluk sınırları vardır; her kullanıcıyı veya her sayfayı temsil etmeyebilir. 28 günlük hareketli ortalama, dünkü dağıtımın etkisini göstermekte yetersiz kalır. Tam kitle ve ürüne özgü boyutlar için birinci taraf RUM ile birlikte kullanın.

Web Vitals’ın ötesinde RUM

Gerçek kullanıcı izleme ayrıca şunları yakalamalıdır:

• Rota değişimi veya SPA gezinme zamanlaması (Soft Navigations ile zenginleştirilebilir).
• API gecikmesi ve başarısız istekler.
• JavaScript hataları ve promise reddi.
• Uzun görevler ve uzun animasyon kareleri (LoAF).
• Özelliğe göre etkileşim gecikmesi.
• Arama, ödeme, giriş veya yükleme tamamlama.
• Rage click, yeniden deneme ve terk.
• Çökme, çevrimdışı durumlar ve bağlantı değişiklikleri.
• Ölçülebildiği yerde erişilebilirlikle ilgili başarısızlıklar.

Yararlı soru yalnızca “INP kötü mü?” değildir; “Hangi etkileşim, hangi kullanıcılar için, hangi sürümde yavaş—ve bu görev tamamlamayı engelliyor mu?”

Üçüncü taraf pazarlama/analitik betikleri ölçüm için eklendiğinde paradoksal olarak INP/LCP’yi bozabilir. sGTM, tarayıcıdaki onlarca betiği tek bir birinci taraf akışına indirger; JS yürütme, DNS ve SSL maliyetini buluta taşır—ölçümün kendisi performansı zehirlemesin diye.

Bütçeler, uyarılar ve sürekli izleme

Performans bütçeleri kalite hedeflerini uygulanabilir limitlere çevirir. Hem kullanıcı metrikleri hem nedenler için bütçe tanımlayın:

• LCP: 75. yüzdelik ≤ 2.5 saniye.
• INP: 75. yüzdelik ≤ 200 milisaniye.
• CLS: 75. yüzdelik ≤ 0.1.
• JavaScript transferi: rotaya göre üzerinde anlaşılan maksimum.
• Toplam sayfa ağırlığı: cihaz sınıfına göre maksimum.
• Üçüncü taraf istekler: onaylı liste ve maksimum maliyet.
• Hata oranı: kabul edilebilir maksimum yüzde.
• Kritik iş akışı başarısı: minimum tamamlama oranı.

Üç uyarı seviyesi kullanın:

• Uyarı: metrik limite yaklaşıyor.
• Regresyon: metrik üzerinde anlaşılan yüzdeyi aşarak kötüleşti.
• Kritik: bir Core Web Vital veya önemli iş akışı başarısızlık eşiğini aştı.

Lighthouse CI assertions örneği—skor yerine metrik tabanlı kapılar tercih edin:

{
  "ci": {
    "collect": {
      "url": ["http://localhost:3000/", "http://localhost:3000/blog"],
      "numberOfRuns": 3,
      "settings": { "preset": "desktop" }
    },
    "assert": {
      "assertions": {
        "categories:performance": ["error", {"minScore": 0.9}],
        "first-contentful-paint": ["warn", {"maxNumericValue": 2000}],
        "largest-contentful-paint": ["error", {"maxNumericValue": 2500}],
        "cumulative-layout-shift": ["error", {"maxNumericValue": 0.1}]
      }
    }
  }
}

Sürekli izleme örneği

Pratik bir sistem şöyle işleyebilir:

1. Temsilî sayfa setinde her sürümde Lighthouse çalışır.
2. WebPageTest gece birkaç konum ve bağlantı profilinden koşar.
3. web-vitals.js (mümkünse attribution) production’dan anonimleştirilmiş LCP, INP ve CLS gönderir.
4. Pano sonuçları sürüm, rota, cihaz ve coğrafyaya göre dilimler.
5. Mobil INP iki ardışık dönemde %15 kötüleşince uyarı ateşlenir.
6. Ekip DevTools + LoAF ile etkilenen etkileşimi izler.
7. Uzun bir JavaScript görevi kısaltıldıktan sonra hem iz hem saha verisi doğrulanır.
8. Değişiklik yalnızca performans iyileşir ve görev başarısı/dönüşüm düşmezse tutulur.

Bu bir geri bildirim döngüsü yaratır: Lighthouse tespit eder, DevTools teşhis eder, WebPageTest stres test eder, RUM doğrular, bütçeler regresyonu engeller.

Pratikte sürekli izleme (kısa vaka notları)

• Taboola: Yayıncı sitelerinde yüksek TBT/INP; LoAF ile darboğaz işaretleme, üçüncü taraf küçültme ve render motoru yeniden tasarımı.
• Fotocasa: FID döneminde yeşil; Mart 2024 INP sonrası Search Console’da “geliştirilmeli/zayıf”. Galeri, harita ve filtre etkileşimlerindeki gizli istemci yavaşlıkları RUM ile çözüldü.
• Ray-Ban: Speculation Rules ile ürün sayfalarını prerender; LCP ~%43 düşüş (1 sn altı) ve PDP dönüşümünde mobil ~%101 / masaüstü ~%156 artış raporlandı.
• T-Mobile: LCP 2 sn’yi aştıkça her 100 ms gecikmede dönüşüm düşüşü ve bounce artışı; hızı KPI’ya çevirip ziyaretten siparişe dönüşümü ~%60 artırdılar.

Ölçüm, panoyu yeşile boyamak için değil; gerçek yolculuklarda görevi mümkün kılmak içindir.

En sık karıştırılan eşlemeler

❌ FID hâlâ güncel bir Core Web Vital’dır
✓ FID Mart 2024’te emekli oldu; odak INP’dedir (ziyaret boyunca yanıt)

❌ Yeşil Lighthouse skoru saha CWV’nin iyi olduğu anlamına gelir
✓ Lab teşhis eder; CrUX/RUM gerçek kullanıcı deneyimini doğrular

❌ Ortalama LCP “yeterince iyi”yi temsil eder
✓ 75. yüzdeliği mobil ve masaüstü ayrı izleyin

❌ TBT, INP’nin yerine geçer
✓ TBT lab teşhisidir; saha yanıtı için INP kullanın

❌ web-vitals skoru tek başına kök nedeni gösterir
✓ Attribution + LoAF etkileşim hedefi ve suçlu betiği gösterir

❌ CrUX dünkü deploy’u yansıtır
✓ CrUX ~28 günlük ortalamadır; anlık regresyon için birinci taraf RUM şarttır

Kontrol listesi: ölçülmesi gerekenleri ölçün

1. Bir Kuzey Yıldızı + davranış, algı, tutma ve teknik/güvenilirlikten birer metrik seçin.
2. Kritik yolculuklar için lab senaryoları ve saha boyutları (cihaz, ağ, coğrafya, rota) tanımlayın.
3. LCP, INP ve CLS için p75 “iyi” eşiklerini mobil/masaüstü ayrı sabitleyin.
4. LCP’yi dört gecikmeye ayırın (TTFB, keşif, indirme, render); INP’yi üç faza ayırın.
5. Lighthouse CI + WebPageTest’i temsilî URL’lerde çalıştırın; medyan/trend okuyun.
6. Production’da web-vitals (attribution tercih) + gizlilik-güvenli boyutlarla RUM kurun.
7. CrUX’u kıyaslama için kullanın; regresyon ve özellik teşhisi için RUM’a güvenin.
8. Bütçe ve üç seviyeli uyarı (uyarı / regresyon / kritik) tanımlayın; iyileştirmeyi görev başarısı veya dönüşümle doğrulayın.

Bu sekiz maddeyi cevaplayamıyorsanız hâlâ “skor izliyorsunuz”; henüz kullanıcı odaklı ölçüm yapmıyorsunuz.

Bu bölümün sabitlediği noktalar

1. Kullanıcı odaklı ölçüm davranış, algı, tutma ve teknik performansı birleştirir—yalnızca trafik veya lab skoru değil.
2. Lab yeteneği ve nedeni açıklar; saha gerçek dünya performansını doğrular; ikisi bir döngüdür.
3. Güncel Core Web Vitals LCP, INP ve CLS’dir; FID tarihseldir. Eşikler p75’te: LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1.
4. LCP dört gecikmeye, INP üç faza ayrılır; LoAF ve attribution kök nedeni skor yerine koordinata bağlar.
5. Soft Navigations, Speculation Rules ve sGTM gibi mimari araçlar ölçüm kör noktalarını ve üçüncü taraf ağırlığını kapatmaya yardım eder.
6. Bütçeler, uyarılar ve sürekli izleme iyileştirmeyi kalıcı kılar; Taboola, Fotocasa, Ray-Ban ve T-Mobile ölçümün iş sonucuna bağlandığını gösterir.

Amaç panoyu yeşile çevirmek değildir. Amaç, kullanıcıların önemli görevleri hızlı, güvenilir ve tatmin edici biçimde tamamlayıp tamamlayamadığını bilmek—ve bilince göre mühendislik yapmaktır.

Sırada: Core Web Vitals’ı “güzel metrikler” olmaktan çıkarıp ürün gereksinimlerine, bütçelere ve yayın kapılarına dönüştüreceğiz.