LCP, INP ve CLS — Google'ın kullanıcı deneyimini özetlediği üç sinyal. Sayfanızın hızını saha verisiyle anlamak, performans bütçesi koymak ve doğru yerden iyileştirmeye başlamak için bir başvuru rehberi hazırladık.
Her metrik tek bir soruya cevap arar: "Ne zaman göründü?", "Tepki verdi mi?" ve "Sayfa yerinde mi durdu?". Üçü birlikte, kullanıcının sayfanızla geçirdiği ilk saniyelerin bir özetini verir. Eşik değerler Google'ın saha verisinden çıkarılmıştır ve sıralama sinyali olarak da kullanılır.
Görünür alandaki en büyük içerik öğesinin boyandığı an. Çoğu sayfada hero görseli, başlık ya da öne çıkan blok bu rolü üstlenir.
Bir kullanıcı etkileşiminden (tık, dokunuş, tuş) sonra ekranın bir sonraki boyamaya kadar geçen süre. Mart 2024'te FID'in yerini aldı; tüm etkileşimleri kapsar.
Sayfa yüklenirken görsel öğelerin beklenmedik biçimde yer değiştirmesinin toplam puanı. Geç gelen reklam, ölçüsü belirsiz görsel, geç yüklenen yazı tipi en yaygın kaynaklardır.
Aynı sayfaya farklı yerden bakan iki ölçüm. Saha verisi gerçek kullanıcılardan toplanır ve sıralamayı etkiler; laboratuvar verisi kontrollü ortamdaki tek bir koşudur. İkisinin de işi farklıdır ve birinin yerine diğeri konulamaz.
# pagespeed.web.dev → irdaweb.com
LCP p75 1.9 s iyi
INP p75 148 ms iyi
CLS p75 0.14 geliştirilmeli
# lighthouse — yerel koşu, mobil profil
Performance 92 / 100
LCP 1.4 s (simülasyon)
TBT 120 ms (INP'e yaklaşık)
CLS 0.02 (tek koşu)Bütçe, sayfanızın bir kaynağı (görsel, JS, font) ne kadar yüklenebilir sorusuna verdiğiniz sayısal cevaptır. Ekibin geri kalanı için hayır demeyi kolaylaştırır; CI'de eşik aşılırsa sürüm durur. Aşağıdaki değerler 3G/4G karışık mobil için yaygın bir başlangıç noktasıdır.
srcset ile cihaz başına uygun boyut sunun; hero için preload kullanın.font-display: swap, woff2 ve self-hosting kombinasyonu CLS'i ve FOUT'u azaltır.Saha verisinden başlayın: en kötü metriği bulun, onu üreten sayfayı ve cihazı belirleyin. Sonra büyük etki / düşük maliyet işlerden başlayarak ilerleyin. Aşağıdaki sıra çoğu projede ilk değer üreten yoldur.
Her adımdan sonra CrUX güncellenene kadar ~28 gün beklemeniz gerekebilir; o yüzden değişiklikleri tek tek değil, küçük gruplar hâlinde yayınlayın.
LCP öğesi çoğu zaman buradan gelir. AVIF veya WebP, doğru boyut, fetchpriority="high" ve preload kullanın. Lazy-load'u hero'ya değil, görünür alanın altındakilere uygulayın.
<link rel="preload" as="font" crossorigin>, font-display: swap ve self-hosted woff2; CLS'i azaltır, FOUT'u kontrol altına alır.
width + height ya da aspect-ratio ile yerleri rezerve edin; geç gelen içerik sayfayı kaydırmasın.
Üçüncü taraf script'leri kullanıcı etkileşimi sonrası yükleyin. Route-level kod bölme; ana iş parçacığı boş kaldığında çalışacak işleri requestIdleCallback ile zamanlayın. INP'yi en çok bu adım iyileştirir.
Statik varlıklar için uzun cache, HTML için kısa cache + revalidate. Brotli sıkıştırma, HTTP/2 ya da HTTP/3 ve TLS oturum yeniden kullanımı — TTFB ve LCP'yi birlikte düşürür. Bu konunun derinine için bkz. CDN, DDoS & Edge; TLS tarafı için TLS, SSL ve Sertifikalar.
Lighthouse CI veya WebPageTest ile kritik sayfalara bütçe koyun; bütçe aşıldığında build başarısız olsun. Saha tarafında CrUX dashboard'unu haftalık takip edin.
FCP (First Contentful Paint) herhangi bir içeriğin ilk göründüğü an; LCP ise görünür alandaki en büyük içerik öğesinin boyandığı an. FCP iyi olsa bile LCP yavaş olabilir — sayfanın iskeletinin değil, gerçek içeriğinin gelmesini ölçer.
FID (First Input Delay) sadece sayfadaki ilk etkileşimin gecikmesini ölçerdi. INP Mart 2024'te onun yerine geçti ve sayfanın yaşam süresi boyunca tüm etkileşimlerin en kötülerinden birini raporlar. Daha temsili, ama daha zor iyileştirilir.
CrUX gerçek Chrome kullanıcılarından toplanan saha verisidir, son 28 günü kapsar ve sıralamayı etkiler. Lighthouse kontrollü ortamda tek bir koşunun raporudur; sıralamayı etkilemez ama regresyon yakalamak için vazgeçilmezdir.
TTFB (Time To First Byte) sunucunun ilk byte'ı göndermesine kadar geçen süredir; LCP en büyük içeriğin ekranda boyanmasına kadar geçer. Yavaş TTFB neredeyse her zaman yavaş LCP demektir; iyileştirme genelde sunucu/CDN tarafından başlar.
Kullanıcı için ikisi de aynı bekleme hissidir, ama kökenleri ayrıdır. Backend süresi sunucu / veritabanı yanıt zamanı; frontend süresi tarayıcının HTML, CSS, JS, görsel ve font işleme zamanı. Bir profil çıkarmadan hangisinin baskın olduğunu varsaymayın.
Konuyu tanımlayan resmi belgeler ve referans yayınlar.
CrUX raporu, Lighthouse koşusu ve hangi adımdan başlanması gerektiği üzerine küçük bir oturum — bizimle konuşmak ister misiniz?