Core Web Vitals'ı Doğru Ölçmek: Lighthouse Yanıltır

Lighthouse raporunda Core Web Vitals'ın (özellikle LCP'nin) yeşile boyandığını gördün, ama Search Console'daki gerçek kullanıcı verisi hâlâ kırmızı mı diyor? Yalnız değilsin. Lighthouse'un varsayılan modu sayfayı gerçekten yavaşlatmaz — CPU ve ağ kısıtını simüle eder; bu yüzden lab skorun ile sahadaki (CrUX) skorun aynı sayıyı vermez. Bu yazı, üç farklı "gerçek"i (lab, saha, gerçek trace) birbirinden ayırmayı, Lighthouse'un simülasyon motorunun nerede yanılabileceğini ve Chrome DevTools Performance panelinde 4x CPU + Slow 4G ile gerçek bir trace nasıl alınacağını gösteriyor; sona doğru Next.js 16.3'ün yeni "Instant Insights" aracını da ölçüm iş akışına nasıl katacağını bulacaksın.

💡 Pro Tip: Lighthouse panelinde "View Original Trace" butonuna bastığında gördüğün trace, simülasyondan önceki ham kayıttır — bu yüzden orada gördüğün zaman değerleri, Lighthouse'un rapor ettiği metrik sonuçlarıyla birebir örtüşmez.

İçindekiler

• Üç ayrı "gerçek": lab, saha ve gerçek trace
• Veri katmanlarının hızlı karşılaştırması
• Simüle throttling nerede yanılır: üç somut sınır
• 4x CPU + Slow 4G emülasyonuyla gerçek trace alma
• LCP elementini görsel kanıtla doğrulamak
• p75 vs ortalama: hangi sayıya güvenmelisin
• Next.js 16.3 Instant Insights'ı ölçüm aracı olarak kullanmak
• CI'da regresyon kapısı: instant() ile navigasyonu test etmek
• Sunucu-taraflı LHCI/PSI'yi ne için tutmalı, ne için tutmamalı
• Hangi soruyu hangi araç cevaplar
• SSS
• Lighthouse skoru neden gerçek kullanıcı verisinden farklı çıkıyor?
• LCP'yi gerçek Chrome trace ile nasıl ölçerim?
• Simulated throttling nedir, neden gerçek ölçümden sapabilir?
• CWV regresyonunu CI'da nasıl yakalarım?
• Lighthouse'taki "Slow 4G" gerçek bir 4G bağlantısı mı?
• p75 ile ortalama arasındaki fark neden önemli?
• Sonuç
• Kaynaklar

Üç ayrı "gerçek": lab, saha ve gerçek trace

Core Web Vitals konuşulduğunda aslında üç farklı veri katmanından bahsediyoruz ve bunlar birbirinin yerine geçmiyor:

• Lab (laboratuvar) verisi: DevTools veya Lighthouse'un tek seferlik, kontrollü bir ortamda ürettiği ölçüm. Deterministiktir, CI'a uygundur, ama tek bir cihaz/ağ senaryosunu temsil eder.
• Saha (field) verisi: Chrome UX Report'un (CrUX) gerçek kullanıcılardan topladığı anonim ölçüm. Google'ın resmi tanımı şöyle: eşikler "mobil ve masaüstü cihazlar arasında bölünmüş, sayfa yüklemelerinin 75. yüzdelik dilimi" üzerinden değerlendirilir. Search Console, PageSpeed Insights ve DevTools Performance panelinin "Field data" bölümü bu veriyi gösterir.
• Gerçek trace: DevTools Performance panelinde, CPU ve ağ kısıtlaması gerçekten uygulanmış bir oturumdan alınan canlı kayıt. Simülasyon değil, o an tarayıcıda olanın ta kendisi.

Resmi eşikler üçünde de aynıdır: LCP için 2,5 saniye, INP için 200 milisaniye, CLS için 0,1 — "iyi" kullanıcı deneyimi sınırı olarak web.dev'in Core Web Vitals dokümanında tanımlanır. Hangi katmanda ölçtüğün değişmez ama _hangi sayının doğru olduğu_ ölçüm yöntemine göre değişir — bu yazının tezi tam olarak bu.

Veri katmanlarının hızlı karşılaştırması

Simüle throttling nerede yanılır: üç somut sınır

Lighthouse'un resmi throttling dokümanı açık konuşuyor: "Lighthouse, çok daha hızlı fiber bağlantılarda çalıştırılsa bile ~85. yüzdelik mobil bağlantı hızını taklit etmek için ağ kısıtlaması uygular." Bu kısıtlama gerçek bir ağ testi değil; "Simulated throttling, Lighthouse'un varsayılan olarak kullandığı yöntemdir ve ilk kısıtlamasız yüklemeden gözlemlenen veriye dayanan bir sayfa yükleme simülasyonu kullanır."

Bunun pratik sonucu üç yerde seni yanıltabilir:

• İsim kafa karıştırıyor. Lighthouse'ta hâlihazırda "Slow 4G" diye adlandırılan preset, aslında "4G bağlantıların en yavaş %25'i ile 3G'nin en hızlı %25'ini" temsil ediyor — ve resmi dokümana göre bu preset eskiden "Fast 3G" olarak etiketleniyordu. Yani isim değişmiş, rakamlar aynı kalmış; "Slow 4G" gördüğünde bunu gerçek bir 4G bağlantısı sanmak yanlış olur.
• Karşılaştırma noktası da kusurlu. Simülasyonun alternatifi olan DevTools (istek seviyesi) throttling'de gecikme, gerçek mobil bağlantılardaki gibi paket seviyesinde değil istek seviyesinde uygulanıyor; resmi doküman o throttling için "Bunun sonucunda bu throttling yüksek doğrulukta değildir" diyor. Yani simülasyonu "gerçek" bir referansla kıyasladığını sanma.
• Edge-case'lerde sapar. Aynı doküman, simüle edilen sonuçların çoğu sitede DevTools throttling'e "eşit veya daha iyi doğrulukta" olduğunu ama "edge-case'lerden muzdarip" olduğunu ve derin bir performans incelemesinin paket seviyesinde throttling araçları kullanması gerektiğini belirtiyor.

Kısacası: simüle throttling hızlı ve deterministik bir tahmin yöntemidir, gerçek bir ölçüm cihazı değil. CI'daki hızlı geri bildirim için harika, ama "bu sayfa neden yavaş?" sorusuna kesin cevap için yetersiz kalabilir.

Bunu bir analoji ile düşünebilirsin: simüle throttling, ilk kısıtlamasız yüklemeyi izleyip "bu sayfa 4G'de büyük ihtimalle şöyle davranır" diyen bir tahmin modeli. Model her seferinde aynı girdiyle aynı çıktıyı verir — bu, CI'da flaky (kararsız) sonuçlardan kaçınmak için değerlidir. Ama tahmin, gerçek dünyadaki değişkenliği (bir kullanıcının Wi-Fi'dan hücresel veriye geçmesi, arka planda çalışan başka bir sekme, cihazın o anki ısınma durumu) yakalayamaz — ve resmi dokümanın "edge-case'lerden muzdarip" ifadesi zaten bunu kabul ediyor.

4x CPU + Slow 4G emülasyonuyla gerçek trace alma

Simülasyona güvenmek yerine, sayfayı gerçekten kısıtlanmış bir ortamda çalıştırıp izlemek istediğinde adres Chrome DevTools Performance panelidir. Resmi dokümana göre önerilen akış şöyle:

1. Incognito modda çalış. Chrome'un resmi kılavuzu şunu söylüyor: "Incognito modu, Chrome'un temiz bir durumda çalışmasını sağlar... uzantılar performans ölçümlerinde gürültü yaratabilir." Yüklü eklentilerin trace'i kirletmesini böyle önlersin.
2. CPU throttling'i aç. Performance panelinde kayıt ayarlarından CPU için "4x slowdown" seç. Doküman net: "CPU için 4x slowdown seçin. DevTools, CPU'nuzu normalden 4 kat daha yavaş çalışacak şekilde kısıtlar."
3. Ağ kısıtlamasını ayarla. Settings > Throttling altında hazır presetler (ör. Slow 4G) kullanılabilir ya da kendi özel throttling profilini tanımlayabilirsin — indirme/yükleme Kbps, gecikme (ms) ve paket kaybı değerlerini gerçek düşük/orta seviye cihaz senaryolarına göre kalibre edebilirsin.
4. Screenshots seçeneğini açık bırak. Bu, sonraki bölümde LCP elementini kanıtlamak için gerekli.
5. Kaydı başlat, sayfayı yeniden yükle, kaydı durdur.

Bu adımları script'leyip tekrarlanabilir hâle getirmek istersen, Playwright'ın kendi trace API'si ile aynı DevTools protokolünü otomasyona bağlayabilirsin — elle tıklama yerine CI adımına dönüştürebilirsin.

1# PageSpeed Insights API'sinden saha (CrUX) + lab (Lighthouse) verisini birlikte çekmek
2# PSI v5 public uç noktası — lab + saha verisini tek yanıtta döner
3curl -sS "https://www.googleapis.com/pagespeedonline/v5/runPagespeed?url=https://example.com&strategy=mobile" \
4  | jq '{lab: .lighthouseResult.audits.metrics, field: .loadingExperience.metrics}'

Bu komut sana hem simüle edilmiş lab metriklerini hem de CrUX saha verisini aynı yanıtta verir — ikisi arasındaki farkı görmenin en hızlı yolu budur.

Ben genelde bu akışı iki aşamalı çalıştırmayı tercih ederim: önce PSI API'sinden gelen field/lab farkına bakıp "bu sayfada gerçekten bir sorun var mı yoksa lab tahmini mi şişirdi" sorusuna kabaca cevap veririm; fark küçükse zaten DevTools'a inmeye gerek kalmaz. Fark büyükse ancak o zaman Incognito'da elle trace almaya geçerim — her sayfa için baştan gerçek trace almak zaman kaybı olabilir, çünkü field/lab farkı büyümediğinde gerçek trace almanın bana çoğu zaman yeni bir şey göstermediğini görüyorum.

LCP elementini görsel kanıtla doğrulamak

"LCP elementi bu mu?" sorusuna sözle değil görselle cevap vermenin yolu scrubbing. DevTools resmi kılavuzu şöyle tarif ediyor: "Fare imlecini FPS, CPU veya NET grafiklerinin üzerine getir. DevTools o andaki sayfanın ekran görüntüsünü gösterir... Buna scrubbing denir." Kaydı aldıktan sonra zaman çizelgesi üzerinde ileri geri gezinerek sayfanın hangi anda neyi gösterdiğini kare kare izleyebilirsin.

Bunun ön koşulu var: kayıt alırken "Screenshots" onay kutusunun açık olması gerekir — doküman bunu net bir gereklilik olarak belirtir. Kapalıysa scrubbing'de boş kare görürsün ve LCP elementini görsel olarak doğrulayamazsın.

Pratikte akış şu: trace'i al → zaman çizelgesinde LCP marker'ına git → o noktanın hemen öncesine scrub et → ekran görüntüsünde hangi elementin son kez boyandığını gözle doğrula → Elements panelinde o node'u seç. Bu, "LCP her zaman hero görselim olur" gibi varsayımların yanlış çıkabildiği yerdir — özellikle lazy-load edilen bir bileşen ya da geç render olan bir metin bloğu asıl suçlu olabilir.

Node'u bulduktan sonra ben genelde scrubbing'i bir kez de geriye doğru yaparım: LCP anından başlayıp kayıt başına kadar kare kare geri gidip o elementin ilk hangi karede görünmeye başladığını ararım. İlk görünme ile LCP işareti arasındaki boşluk, elementin neden geç boyandığını anlatan asıl bölgedir — optimizasyonu oraya yöneltirsin.

p75 vs ortalama: hangi sayıya güvenmelisin

Resmi CWV metodolojisi ortalama değil p75'i (75. yüzdelik dilim) kullanır — web.dev'in tanımı yukarıda alıntılandığı gibi net: eşikler "sayfa yüklemelerinin 75. yüzdelik dilimi" üzerinden değerlendirilir. Bunun nedeni basit: ortalama, uç değerleri (çok hızlı ve çok yavaş oturumları) birbirine karıştırıp gerçek dağılımı gizler; p75 ise "kullanıcılarının çoğunluğu bundan daha kötü bir deneyim yaşamadı" diyebileceğin bir eşiktir.

Pratik sonucu: panelinde yalnızca "ortalama LCP" başlığıyla tek bir sayı gösteren bir dashboard gördüğünde bu, CWV değerlendirmesi için kullanılan sayı değildir. p75 kolonunu ayrıca kontrol et — aradaki fark büyük olabilir, özellikle trafiğin bir kısmı düşük uçlu cihazlardan veya zayıf ağlardan geliyorsa. Ortalama uç değerleri gizler; p75 ise resmi ölçüttür.

Ben kendi ölçümlerimde ortalama ve p75'i her zaman yan yana tutmayı tercih ederim: aradaki makas açıldığında bu genellikle dağılımın kuyruğunda (düşük uçlu cihaz veya zayıf ağ segmenti) bir sorun olduğunun ilk işareti oluyor — tek başına p75'e bakmak da o kuyruğun ne kadar kalın olduğunu göstermez, ikisini birlikte okumak gerekiyor.

Next.js 16.3 Instant Insights'ı ölçüm aracı olarak kullanmak

3 Ağustos 2026'da yayınlanan Next.js 16.3, ölçüm iş akışına yeni bir katman ekliyor: Instant Insights. Resmi duyuru bunu şöyle tanımlıyor: "Yavaş navigasyonları otomatik olarak yüzeye çıkaran yeni bir devtool." Daha da ileri gidiyor: "Instant Insights ile, geliştirme ortamında yavaş navigasyonları bir hataya çevirdik." Yani artık "acaba bu route geçişi yavaş mı" sorusunu Lighthouse çalıştırıp beklemene gerek kalmadan, geliştirme sırasında anında görebiliyorsun.

Bu davranış cacheComponents: true bayrağıyla opt-in edilir (Partial Prefetching davranışı için ayrıca partialPrefetching: true gerekiyor) ve bir route bir veriyi await ettiğinde üç seçenekten biri sunulur: Stream ve Cache navigasyonu anında yapar, Block ise bilinçli olarak sunucuya bağlar.

1import { Suspense } from "react";
2 
3// 1) Stream: Suspense ile — veri gelene kadar bir fallback göster,
4//    navigasyon yine de "anında" sayılır çünkü UI hemen boyanır
5export default function ProductPage() {
6  return (
7    <Suspense fallback={<ProductSkeleton />}>
8      <ProductDetails />
9    </Suspense>
10  );
11}
12 
13// 2) Cache: 'use cache' ile — veriyi build/request zamanında önbelleğe al
14async function getProduct(id: string) {
15  "use cache";
16  return db.product.findUnique({ where: { id } });
17}
18 
19// 3) Block: bilinçli olarak "instant" davranışından çık
20export const instant = false;

Next.js ekibi bu davranışların "gelecekteki bir major sürümde varsayılan olacağını" açıkça belirtiyor — henüz gerçekleşmedi, ama yön bu. Ölçüm açısından pratik faydası şu: Instant Insights, geliştirme aşamasında hangi route'un "anında" sayılmadığını sana söylüyor; bu da senin Lighthouse çalıştırmadan önce zaten hangi sayfaların sorunlu olacağını bilmen anlamına geliyor.

CI'da regresyon kapısı: instant() ile navigasyonu test etmek

Instant Insights'ın CI karşılığı @next/playwright paketinden gelen instant() yardımcı fonksiyonu. Dokümandaki örnekten uyarlanmış hâli şöyle:

1import { expect, test } from "@playwright/test";
2import { instant } from "@next/playwright";
3 
4test("product title is available immediately", async ({ page }) => {
5  await page.goto("/products/shoes");
6 
7  // Ağı beklemeden neyin görünür olduğunu doğrula
8  await instant(page, async () => {
9    await page.click('a[href="/products/hats"]');
10    await expect(page.locator("h1")).toContainText("Baseball Cap");
11    await expect(page.getByText("Checking inventory...")).toBeVisible();
12  });
13 
14  await expect(page.getByText("12 in stock")).toBeVisible();
15});

instant(), bloğun içindeki assertion'ları "navigasyonda anında görünür olması gereken UI" ile sınırlıyor — yani test, ağ isteğini beklemeden hangi arayüzün hemen boyanması gerektiğini doğruluyor. Bir refactor navigasyonu yavaşlatıp bu UI'yi geciktirirse test kırmızı olur; bu, CWV'nin lab-testi katmanını doğrudan CI'a taşıyan somut bir araç.

Next.js ekibi bunun bir adım ötesini de araştırıyor: "Geliştirmede gördüğün hataları build sürecinde de yüzeye çıkarmanın yollarını araştırıyoruz, böylece instant route'lardaki regresyonlar build zamanında yakalanabilir." Bu henüz kesinleşmiş bir özellik değil, planlanan bir yön olarak okunmalı.

Pratikte instant() testlerini nereye koyacağın önemli: her sayfaya değil, kullanıcı akışının kritik noktalarına (ana navigasyon, checkout adımları, arama sonucu tıklamaları) odaklan. Her route için bir test yazmak bakım yükünü artırır ve asıl sinyali gürültüye boğar; CWV'nin kendisi gibi, burada da az sayıda ama doğru yerde ölçüm, çok sayıda yüzeysel ölçümden daha değerlidir.

Sunucu-taraflı LHCI/PSI'yi ne için tutmalı, ne için tutmamalı

Pratik kural şu: sunucu tarafında koşan LHCI/PSI trend içindir, kesin kanıt için gerçek Chrome trace gerekir. Bunun teknik dayanağı da resmi dokümanda var: "Simulated throttling varsayılan ayar olmaya devam ediyor. Bu, PageSpeed Insights ve Lighthouse CLI'nin varsayılan kurulumuyla eşleşiyor ve araçlar arası tutarlılığı koruyor."

Yani PSI/LHCI'nin günlük çalışması sana karşılaştırılabilir bir trend hattı verir — "bir gün 2,1 sn, ertesi gün 2,4 sn" gibi bir sinyali güvenle okuyabilirsin çünkü aynı simülasyon motoru her seferinde aynı varsayımlarla çalışıyor. Ama "neden 2,4 sn'ye çıktı?" sorusunun cevabı için deterministik simülasyon yetmez; oraya 4x CPU + Slow 4G ile alınan gerçek bir trace ve scrubbing ile bulunan LCP elementi kanıtı gerekir.

Hangi soruyu hangi araç cevaplar

CI'da bir bütçe kapısı kurmak istiyorsan, Lighthouse CI'nin kendi eşik yapılandırmasını kullanabilirsin; rakamları kendi p75 hedefine göre doldurman gerekir — burada gösterilen değerler bir şablon, ölçülmüş bir sonuç değil:

1{
2  "ci": {
3    "assert": {
4      "assertions": {
5        "largest-contentful-paint": ["error", { "maxNumericValue": 2500 }],
6        "cumulative-layout-shift": ["error", { "maxNumericValue": 0.1 }],
7        "interaction-to-next-paint": ["warn", { "maxNumericValue": 200 }]
8      }
9    }
10  }
11}

Bu eşikler web.dev'in resmi "iyi" sınırlarıyla aynı (2,5 sn / 0,1 / 200 ms) — CI kapını doğrudan CWV'nin kendi tanımına bağlamış olursun.

SSS

Lighthouse skoru neden gerçek kullanıcı verisinden farklı çıkıyor?

Çünkü Lighthouse, sabit bir CPU/ağ senaryosu altında tek bir sentetik oturumu simüle eder; CrUX ise gerçek kullanıcıların günler boyunca biriktirdiği p75 verisidir. Cihaz çeşitliliği, değişken ağ koşulları ve gerçek üçüncü taraf script davranışı lab sonucunu sahadan ayırır. İkisi de "yanlış" değil, farklı sorulara cevap veriyorlar.

LCP'yi gerçek Chrome trace ile nasıl ölçerim?

Lighthouse'un simülasyonuna güvenmek yerine DevTools Performance panelinde Incognito modda, CPU throttling'i 4x slowdown'a, ağı Slow 4G'ye (veya kalibre ettiğin özel profile) ayarlayıp Screenshots açıkken bir kayıt al. Kayıttan sonra LCP marker'ına scrub ederek elementi gözle doğrula.

Simulated throttling nedir, neden gerçek ölçümden sapabilir?

Simulated throttling, Lighthouse'un sayfayı gerçekten yavaşlatmadan ilk kısıtlamasız yüklemeden gözlemlenen veriye dayanarak bir yükleme simüle eden varsayılan yöntemidir. Çoğu sitede DevTools throttling'e yakın doğrulukta çalışır ama edge-case'lerde sapabilir. Kıyas noktası da kusursuz değil: gecikmeyi gerçek mobil ağlardaki gibi paket seviyesinde değil istek seviyesinde uygulayan DevTools throttling'dir, bu yüzden iki laboratuvar sonucunu kıyaslamak saha gerçeğinin yerini tutmaz.

CWV regresyonunu CI'da nasıl yakalarım?

Next.js 16.3 ile gelen @next/playwright paketinin instant() yardımcı fonksiyonunu kritik route'larına ekle; bu, navigasyonda anında görünmesi gereken UI'yi ağ isteğini beklemeden test eder. Ayrıca geliştirme ortamında Instant Insights, yavaş navigasyonları otomatik olarak hataya çevirir — regresyonu commit'ten önce yakalarsın.

Lighthouse'taki "Slow 4G" gerçek bir 4G bağlantısı mı?

Hayır. Resmi dokümana göre bu preset, "4G bağlantıların en yavaş %25'i ile 3G'nin en hızlı %25'ini" temsil ediyor ve eskiden "Fast 3G" olarak etiketleniyordu. İsim değişmiş ama kısıtlama seviyesi aynı kalmış; ismin kendisine güvenip gerçek bir 4G testi yaptığını varsayma.

p75 ile ortalama arasındaki fark neden önemli?

Resmi CWV değerlendirmesi ortalamayı değil p75'i kullanır çünkü ortalama uç değerleri birbirine karıştırıp gerçek dağılımı gizler. Bir dashboard'da "ortalama LCP" gördüğünde bu, sitenin CWV değerlendirmesinde kullanılan sayı değildir — p75 kolonunu ayrıca kontrol etmen gerekir.

Sonuç

Lighthouse skorunla saha verisi tutmuyorsa önce hangi katmanda konuştuğunu netleştir: lab mı, saha (CrUX) mı, yoksa gerçek bir trace mi? Simüle throttling CI'da hızlı geri bildirim için değerlidir ama kök neden analizi için 4x CPU + Slow 4G ile alınan gerçek bir DevTools trace'i ve scrubbing ile doğrulanmış bir LCP elementi gerekir. Next.js 16.3'ün Instant Insights'ı ve @next/playwright'ın instant() yardımcı fonksiyonu bu iş akışını geliştirme ve CI'a taşıyor; LHCI/PSI'yi ise günlük trend için bırakıp kesin kanıtı gerçek trace'e sakla.

Next.js tarafında caching ve navigasyon davranışını daha derinlemesine görmek istersen Next.js 16.3 Instant Navigations ve Cache Components Rehberi'ne bak; runtime tarafındaki değişiklikler için Next.js 16.3'te runtime='edge' Bitti: Node'a Dönüş makalesi tamamlayıcı. Profiling metodolojisini farklı bir platformda görmek istersen Instruments ile iOS Performance Profiling: Tam Rehber benzer "lab vs gerçek ölçüm" ayrımını iOS tarafında işliyor; sürekli izleme kurmak için iOS Performance Monitoring & Observability Rehberi faydalı. Flutter tarafında 60fps hedefiyle çalışıyorsan Flutter Performans Optimizasyonu: 60fps Garanti Rehberi de aynı "ölç, sonra optimize et" disiplinini uyguluyor.

Kaynaklar

• Core Web Vitals — web.dev — LCP/INP/CLS eşikleri ve p75 metodolojisinin resmi tanımı
• Lighthouse Throttling — GoogleChrome/lighthouse — Simulated throttling, Slow 4G/Fast 3G preset tarihi, paket vs istek seviyesi gecikme
• Chrome DevTools Performance panel dokümanı — 4x CPU throttling, Incognito önerisi, scrubbing ve Screenshots ayarı
• Chrome DevTools Throttling ayarları — özel ağ throttling profilleri (Kbps, gecikme, paket kaybı)
• Next.js 16.3 duyurusu — Instant Insights ve gelecekteki varsayılan davranış planı
• Next.js Instant Navigations rehberi — Stream/Cache/Block modelleri, @next/playwright instant() örneği ve build-time araştırması