Yayınlanma tarihi: 11 Şubat 2025
Chrome Kullanıcı Deneyimi Raporu (CrUX)'nun Şubat 2025 sürümü, heyecan verici bir dizi yeni (ve değişen!) metrik içeriyor:
- Largest Contentful Paint (LCP) resim alt bölümleri ve kaynak türleri
- Gidiş dönüş süresi (RTT) ayrıntıları
- Geçerli Bağlantı Türü (ECT) boyutunun kaldırılması
Bunların her biri, CrUX'ta bulunan kaynak ve URL'lerin performans metrikleri hakkında daha fazla bilgi sağlar. Bu gönderide, nedenini ayrıntılı olarak açıklayacağız.
LCP teşhis bilgileri
LCP alt bölümlerinin konseptini ilk olarak Google I/O 2022'de, yüksek LCP'nin doğru nedenlerini optimize etmek için çabalarınızı harcadığınızdan emin olmak amacıyla resim LCP'si olan sayfaların LCP süresini daha küçük bileşenlere ayırmak için etkili bir teknik olarak tanıtmıştık.
Söz konusu konuşmada, HTTP Archive laboratuvar verilerinin analizi, resim indirme süresinin genellikle LCP süresinin en küçük kısmı olduğunu gösterdi. Birçok laboratuvar aracı (Google'ın kendi Lighthouse aracı da dahil) indirme sürelerini azaltmak ve performansı artırmak için resim biçimlerini ve boyutlarını optimize etmeyle ilgili tavsiyelere odaklanıyordu. Analiz, tavsiyenin doğru olmasına rağmen bu konuya gereğinden fazla vurgu yapılmış olabileceğini ve daha büyük bir sorunun, resmin tarayıcı tarafından bulunması ve indirilmeye başlaması arasındaki gecikme olduğunu gösterdi.
Lab verileri analiz etmek yararlı olsa da web'in gerçek hayatta kullanımı genellikle farklı olabilir. Bu nedenle, alan verileri için bu alt bölümleri görebilmeniz çok önemlidir. Geçen yıl yayınlanan bir yayın, LCP'nin nasıl optimize edileceğiyle ilgili yaygın bir yanlış anlamanın saha verileriyle doğrulandığını onayladı.
LCP resim alt parçaları
Bu sürümle birlikte site sahipleri, kaynak veya URL düzeyinde resim LCP'si için kendi sitelerindeki alt bölümleri kontrol edebilir.
Alt parçalar yalnızca resimler için kullanılabilir ve ilk video karesi resimleri (indirme süresinin tamamını ölçemediğimiz için biraz daha karmaşıktır) bu kapsamda değildir. Metin alt bölümleri, daha az kullanışlı oldukları ve resim LCP'si sayılarını bozdukları için de dahil edilmez. Büyük ölçüde metin LCP'lerinden oluşan siteler için genel TTFB ve genel FCP metrikleri yararlı dökümlerdir. Ancak bu metriklerin metin LCP'lerine özel değil, tüm LCP'lerde geçerli olduğunu unutmayın. Son olarak, resim alt bölümleri yalnızca tam sayfa yüklemelerinde toplanır. LCP metriğinin aksine geri ve ileri gezinmelerde ve önceden oluşturulmuş sayfalarda da toplanır.
Bu veriler, Şubat 2025'ten itibaren CrUX API ve CrUX History API'ye eklenmiştir (BigQuery'ye değil). CrUX Geçmişi API'si kullanıma sunulduğunda iki haftalık veri içerir. Bu veri, zaman içinde 25 haftalık geçmişin tamamını içerecek şekilde büyür. API'ler, verileri her alt bölümün milisaniye cinsinden ifade edilen 75. yüzdelik dilimi olarak sunar.
Örneğin, PHONE sayfa görüntülemesi için https://web.dev/ öğesinin LCP resim alt bölümlerini almak üzere aşağıdaki curl komutunu kullanabilirsiniz (API_KEY yerine kendi anahtarınızı girin):
curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
--header 'Content-Type: application/json' \
--data '{ "formFactor": "PHONE",
"url": "https://web.dev/",
"metrics": [
"largest_contentful_paint_image_time_to_first_byte",
"largest_contentful_paint_image_resource_load_delay",
"largest_contentful_paint_image_resource_load_duration",
"largest_contentful_paint_image_element_render_delay"]}'
Bunun gibi bir yanıt alırsınız:
{
"record": {
"key": {
"formFactor": "PHONE",
"url": "https://web.dev/"
},
"metrics": {
"largest_contentful_paint_image_element_render_delay": {
"percentiles": {
"p75": 2088
}
},
"largest_contentful_paint_image_resource_load_delay": {
"percentiles": {
"p75": 828
}
},
"largest_contentful_paint_image_resource_load_duration": {
"percentiles": {
"p75": 417
}
},
"largest_contentful_paint_image_time_to_first_byte": {
"percentiles": {
"p75": 2385
}
}
},
"collectionPeriod": {
"firstDate": {
"year": 2025,
"month": 1,
"day": 12
},
"lastDate": {
"year": 2025,
"month": 2,
"day": 8
}
}
}
}
CrUX Görselleştirme Aracı'nı bu verileri içerecek şekilde güncelledik ve CrUX API'lerini kullanan diğer üçüncü taraf araçlarının da bu değerli verileri göstermesini bekliyoruz:
Bu örnekte, popüler bir medya sitesi için kaynak yükleme süresinin en küçük bileşen olduğunu görüyoruz. Bu site için gerçek iyileştirme fırsatları TTFB ve kaynak yükleme gecikmesi'ndedir. Öğe oluşturma gecikmesi'nde ise daha az fırsat vardır.
Her alt bölümdeki yüksek değerler farklı sorunları gösterir:
- Yüksek ilk bayta geçiş süresi (TTFB) genellikle TTFB'yi optimize etme bölümünde açıklandığı gibi sunucu, ağ veya yönlendirme sorunlarını gösterir.
- Yüksek kaynak yükleme gecikmesi, LCP resminin tarayıcı tarafından geç keşfedildiğini gösterir. Örneğin, istemci tarafı JavaScript tarafından enjekte edilen ve çalışması biraz zaman alan bir LCP resmi.
- Kaynak yükleme süresi yüksekse resim indirme boyutunu küçültmeniz gerekir.
- Yüksek öğe oluşturma gecikmesi, resmin kullanılabilir olduğu (belki bir
<link rel=preload>aracılığıyla) ancak uzun süredir kullanılmadığı durumlarda ortaya çıkar. Bu durum genellikle resmin gösterilmesi için istemci taraflı JavaScript'in gerekli olmasından kaynaklanır.
Bu verilerin CrUX'ta hem kaynak hem de URL düzeyinde (olağan uygunluk ölçütlerine tabidir) kullanıma sunulmasının, sitelerin LCP metriklerini optimize etmesini kolaylaştıracağını umuyoruz.
LCP kaynak türleri
Alt bölümler en iyi şekilde resim LCP'leri için görüntülendiğinden CrUX bu verileri yalnızca resim içeren sayfalarla kısıtlar. Bu nedenle, LCP'lerinizin kaçının metin LCP'si (ör. <h1> başlıkları ve uzun paragraflar) yerine resim LCP'si olduğunu anlamak önemlidir.
CrUX API'leri artık LCP resim alt bölümlerinin yanı sıra LCP sayfa yüklemelerinin metin ve resimler arasındaki dağılımını gösteren bir kaynak dökümünü de içeriyor.
Örneğin, PHONE sayfa görüntüleme için https://web.dev/ kaynağının LCP türlerini almak üzere aşağıdaki curl komutunu kullanabilirsiniz (API_KEY'yi kendi anahtarınız ile değiştirin):
curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
--header 'Content-Type: application/json' \
--data '{ "formFactor": "PHONE",
"url": "https://web.dev/",
"metrics": ["largest_contentful_paint_resource_type"]}'
Bunun gibi bir yanıt alırsınız:
{
"record": {
"key": {
"formFactor": "PHONE",
"url": "https://web.dev/"
},
"metrics": {
"largest_contentful_paint_resource_type": {
"fractions": {
"image": 0.0155,
"text": 0.9845
}
}
},
"collectionPeriod": {
"firstDate": {
"year": 2025,
"month": 1,
"day": 12
},
"lastDate": {
"year": 2025,
"month": 2,
"day": 8
}
}
}
}
CrUX Vis de bu verileri gösterecek şekilde güncellendi:
Örneğin, web.dev'in ana sayfasında LCP'lerin% 98,5'inin aslında metin LCP'leri olduğunu görebiliriz.Bu nedenle, LCP görsel alt bölümleri bu sayfa için daha az kullanışlıdır. Bu durumda, daha iyi bir teşhis dökümü olarak orijinal TTFB ve FCP metriklerini kullanabiliriz.
LCP kaynak türleri, LCP'yi anlamak ve iyileştirmek için (özellikle de LCP resim alt bölümlerinin ne kadar yararlı olduğunu öğrenmek için) yararlı bir teşhis aracıdır.
RTT teşhis bilgileri
Ayrıca, ilk olarak Ağustos 2024'te kullanıma sunulan RTT metriğini de genişlettik.
RTT üçlü kutuları
CrUX API'lerine, üç RTT yoğunluğu grubunu gösteren üçlü kutular ekledik:
| Ağ Gecikmesi | Başlat | Sonlandır |
|---|---|---|
| Düşük | 0 milisaniye | < 75 milisaniye |
| Aracı | 75 milisaniye | < 275 milisaniye |
| Yüksek | 275 milisaniye | ∞ |
Bu gruplar, 4g kategorisinde 270 milisaniyeden kısa süren tüm işlemleri içeren önceki ECT kategorilerinden daha bilgilendiricidir. Bu kategoriler kullanıma sunulduktan sonra ağ teknolojisinde yaşanan gelişmelerle birlikte, çoğu sitenin trafiğinin büyük kısmı bu kategoride gerçekleşti ve bu kategorizasyon daha az kullanışlı hale geldi.
Bu nedenle, genel iyi, iyileştirmeye ihtiyaç var ve kötü etiketleri yerine düşük, orta ve yüksek dağılım etiketlerini kullanmanızı öneririz. Bu metrikler, site sahibinin doğrudan iyileştirebileceği metrikler değildir. Bu nedenle, diğer metrikleri ve bunların neden beklenenden farklı olabileceğini anlamak için kullanılan teşhis metrikleridir. Ayrıca, kullanıcı tabanında bir değişiklik olduğunu gösteriyorlarsa site değişmemesine rağmen diğer metriklerin zaman içinde neden değiştiğini açıklamaya yardımcı olabilirler.
Bu kapsayıcılara CrUX API'lerinde erişilebilir. Örneğin, PHONE sayfa görüntüleme sayısı için web.dev (API_KEY, kendi anahtarınız ile değiştirilir):
curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
--header 'Content-Type: application/json' \
--data '{ "formFactor": "PHONE",
"url": "https://web.dev/",
"metrics": ["round_trip_time"]}'
Bu işlev şuna benzer bir sonuç döndürür:
{
"record": {
"key": {
"formFactor": "PHONE",
"url": "https://web.dev/"
},
"metrics": {
"round_trip_time": {
"histogram": [
{
"start": 0,
"end": 75,
"density": 0.1524
},
{
"start": 75,
"end": 275,
"density": 0.6641
},
{
"start": 275,
"density": 0.1835
}
],
"percentiles": {
"p75": 230
}
}
},
"collectionPeriod": {
"firstDate": {
"year": 2025,
"month": 1,
"day": 12
},
"lastDate": {
"year": 2025,
"month": 2,
"day": 8
}
}
}
}
Dağıtımlar seçildiğinde kapsayıcı kutular CrUX Görselleştirme'de gösterilir:
BigQuery'de RTT
CrUX API'lerindeki RTT metriğini üçlü kutuları içerecek şekilde genişletmenin yanı sıra, verileri aylık BigQuery veri kümesindeki ham tablolarda 25 milisaniyelik paketlerde tam bir histogram ve maddileştirilmiş tablolarda üçlü kutular ve p75 değerleri içerecek şekilde kullanıma sunduk.
Bu sayede, CrUX API'lerinde bulunan üçlü grupların ötesinde verilerin dağılımı hakkında daha derin bir anlayış elde edebilirsiniz. Ayrıca, bu aydan itibaren CrUX'tan kaldırılan ECT dökümünü yeniden oluşturmamıza olanak tanır (bu konu hakkında daha sonra daha fazla bilgi verilecektir). Bu dökümde, önceki 270 milisaniyelik eşik yerine 4g için 275 milisaniyelik bir eşik kullanılacak. ECT dökümleri (artık RTT verilerinden alınıyor) CrUX BigQuery somutlaştırılmış tablolarında kullanılmaya devam eder. Böylece CrUX Kontrol Paneli gibi araçlar bu dökümleri göstermeye devam edebilir.
BigQuery veri kümesi, ülkeye (ISO 3166-1 tarafından tanımlandığı şekilde) göre verileri de içerir. Bu sayede, performans metriklerinin bazı kullanıcılar için neden daha kötü olduğunu açıklamak amacıyla kullanılabilecek daha ayrıntılı analizler yapabilirsiniz. Örneğin, https://www.google.com verilerine bakarak Google Telefon kullanıcılarına ait verilere bakabiliriz:
SELECT
`chrome-ux-report`.experimental.GET_COUNTRY(country_code) AS geo,
least(500, p75_rtt) AS capped_p75_rtt,
p75_rtt
FROM
`chrome-ux-report.materialized.country_summary`
WHERE
origin = 'https://www.google.com' AND
yyyymm = 202501 AND
device = 'phone'
ORDER BY
p75_rtt DESC,
country_code
Ardından verileri bir coğrafi haritada görselleştiririz:
https://www.google.comiçin ülkeye göre 75. yüzde birlik dilim telefon RTT'si(etkileşimli grafik içeren kaynak veriler).
Dünyanın büyük bir kısmında (özellikle "Batı dünyası"nda) çok iyi RTT'ler elde edilirken Sahra Altı Afrika, Orta Doğu'nun bazı bölgeleri ve Asya'nın bazı bölgelerinde daha fazla sorun yaşandığını görüyoruz. Tam verilerin kullanılması renkleri çarpıttığından grafik,500 milisaniyelik RTT ile sınırlandırılmıştır. Özellikle de 3.850 milisaniyelik 75. yüzdelik dilimde yer alan Eritre'de bu durum belirgindir.
Bu, trafik kalıpları değiştiğinde de yararlı olabilir. Örneğin, sitede herhangi bir değişiklik olmamasına rağmen daha yüksek RTT'lere sahip ülkelerden gelen kullanıcıların daha büyük bir oranının olması, Core Web Vitals istatistiklerinin kötü olmasını açıklayabilir.
Siteler RTT'yi doğrudan iyileştiremez ancak bu verileri site ziyaretçilerinin kullanımına sunmak, sitenizin dünya genelindeki kullanıcılarını daha iyi anlamanızı sağlar. Ayrıca gelecekte analiz için birçok fırsat sunuyor. Araştırmacıların bu veri kümesinden ilginç analizler elde edeceğini umuyoruz.
ECT boyutunun kaldırılması
Şubat 2025 sürümündeki son değişiklik, Etkili Bağlantı Türü (ECT) boyutunun BigQuery'den kullanımdan kaldırılmasıdır (ECT'nin yerine RTT metriğini kullanıma sunduğumuzda RTT'yi Eylül 2024'te API'lerden kaldırmıştık).
Bu yayında daha önce de belirtildiği gibi, GTT metriği, bir sitenin ziyaretçilerinin bağlantı ayrıntılarını daha ayrıntılı bir şekilde görüntülemenize olanak tanır. Hatta bu histogramlardan ECT gruplarını yeniden oluşturabilirsiniz. (Teknik olarak ECT, RTT ve indirme hızının bir kombinasyonu olmalıdır ancak Chrome yalnızca RTT'yi kullanmıştır.)
Önemli bir fark, ECT'nin bir CrUX boyutu olmasıdır. Diğer metriklerin ECT'ye göre segmentlere ayrılabileceği anlamına gelir. GTT, boyut yerine bir CrUX metriğidir. Bu nedenle, örneğin GTT'ye göre LCP'yi görüntülemek mümkün değildir. Yalnızca diğer boyutlara (cihaz türü ve ülke) göre GTT'leri görebilirsiniz.
Bu durum daha sınırlayıcı gibi görünse de boyuttan metriğe geçiş, CrUX'ta daha fazla veriye erişmenizi sağlar. Bunun nedeni, CrUX'ta veri gösterebilmemiz için belirli minimum eşiklerin olmasıdır. Boyutları 2022'de isteğe bağlı hale getirdik. Yani daha yüksek bir düzeyde raporlama yapmak için gerektiğinde ECT'yi veya cihazı kaldırdık. Ancak çoğu sayfa yüklemesinde bulunmayan metrikler (Sonraki Boyamaya Etkileşim (INP), farklı gezinme türleri ve artık LCP resim alt bölümleri) BigQuery'deki kaynaklar için genellikle kullanılamıyordu.
Boyut sayısı azaltıldığında veriler daha az segmentlere ayrılır. Bu nedenle, bu minimum koşulları karşılayan kaynak sayısı artar. Ocak ayında, kaynak URL'lerinin% 68, 1'i için INP raporladık. Aralık veri kümesinde ise kaynak URL'lerinin yalnızca% 64, 5'i için INP raporladık. Bu mekanizma, bu sürümdeki Gezinme Türleri, LCP Alt Parçaları ve Kaynak Türleri için de geçerlidir. Bunların tümü, ECT boyutunun kaldırılmasından yararlanır. CrUX API'lerinde, kapsamın genişletilmesi Şubat ayının başından itibaren geçerli oldu.
ECT sütunları, önceki veri kümeleriyle tutarlılık sağlamak için BigQuery'de kalır ve somutlaştırılmış görünümlerdeki ECT verileri kullanılabilir durumda kalır ancak yeni RTT p75 ve üçlü kutulara ek olarak RTT bilgilerine (daha önce belirtildiği gibi 3g ve 4g için 5 milisaniyelik bir farkla) dayanır.
Sonuç
Herkese açık CrUX veri kümesine daha fazla metrik eklenmesiyle site sahipleri ve araştırmacılar, performans sorunlarını teşhis edip düzeltmek için çok daha fazla bilgiye sahip olur.
Herkese açık bir veri kümesi olan CrUX'te gösterebileceğimiz ayrıntı düzeyi belirli sınırlamalara sahiptir. Örneğin, bağımsız öğe seçicileri hiçbir zaman CrUX'te gösterilemez. Bu düzeyde ayrıntı isteyen site sahiplerinin, bu kadar kısıtlı olmayan bir RUM çözümü uygulamalarının önemle tavsiye edilir.
Ancak bu yayında ayrıntılı olarak açıklanan daha üst düzey toplu veriler, bir sorununuz olduğunu bilmek ile sorunun neden var olduğu arasındaki boşluğu doldurmanıza yardımcı olabilir. Bu ek verilerin işinize yarayacağını umuyoruz. Geri bildiriminiz veya sorunuz varsa iletişim grubu üzerinden bize bildirin.