Core/Dash Boyutu: Cihaz ve İstemci Kapasitesi

Bu boyutlar neyi ölçer

CoreDash, Cihaz ve İstemci Kapasitesi kategorisi altında iki boyut sunar. Bunlar farklı soruları yanıtlar ancak birbirlerini doğrudan tamamlarlar.

Cihaz Belleği (grup kodu m), tarayıcının navigator.deviceMemory üzerinden döndürdüğü RAM dilimini raporlar. Spesifikasyon, kasıtlı olarak en yakın ikinin kuvvetine aşağı yuvarlar ve sonucu sınırlandırır; bu nedenle kesin rakamlar yerine 0.25, 0.5, 1, 2, 4 veya 8+ GB gibi değerler görürsünüz. Bu yuvarlama işlemi bilinçlidir: parmak izi (fingerprinting) komut dosyalarının kullanabileceği hassasiyeti sınırlar, ancak geliştiricilere yine de kullanılabilir bir sinyal verir.

İstemci Kapasite Puanı (grup kodu ccs), CoreDash tarafından tarayıcının sunduğu üç sinyalden hesaplanan bileşik bir değerdir: cihaz belleği, navigator.hardwareConcurrency (mantıksal CPU çekirdekleri) ve Ağ Bilgisi API'sinden (Network Information API) elde edilen efektif bağlantı türü. Sonuç altı dilimden biridir:

Bileşik puan, tek başına herhangi bir sinyalden daha kullanışlıdır. 2G bağlantısına sahip 4 GB RAM'li bir cihaz, Wi-Fi üzerindeki aynı cihazdan çok farklı davranır. Belleği, çekirdekleri ve bağlantı türünü tek bir sıralı ölçekte birleştirmek, her değişken için ayrı bir kırılım çalıştırmadan performans verilerini filtrelemenize ve karşılaştırmanıza olanak tanır.

Tarayıcı desteği ve veri kapsamı

navigator.deviceMemory yalnızca Chromium tabanlı tarayıcılarda bulunan bir API'dir. Firefox ve Safari bunu sunmaz, bu da söz konusu tarayıcıların bellek bileşeni için her zaman Bilinmeyen (CCS 0) raporlayacağı anlamına gelir. Pratikte Chrome ve Chrome tabanlı tarayıcılar, Android trafiğinin büyük çoğunluğunu oluşturur ve Android cihazlar düşük bellek koşullarının yoğunlaştığı yerlerdir. Yani bu sinyal, tam da en çok önem taşıdığı yerde en yüksek oranda mevcuttur.

Cihaz Belleği HTTP başlığı (Device-Memory), sunucunun aynı değeri bir Accept-CH müzakereli isteğinden okumasını sağlayan ayrı bir mekanizmadır. CoreDash, sayfa yükleme anında toplanan JavaScript API'sini kullanır, böylece değer sunucu tarafında başlık yapılandırması gerektirmek yerine RUM sinyaliyle birlikte taşınır.

Cihaz kapasitesi Core Web Vitals için neden önemlidir

LCP öncelikle bir ağ ve oluşturma (render) sorunudur. INP ise öncelikle bir CPU ve bellek sorunudur. CCS boyutunun en belirgin şekilde INP verilerinde ortaya çıkmasının nedeni bu ayrımdır.

Ana iş parçacığındaki uzun görevler (long tasks) girdi yanıtını engeller. 1 GB RAM'e sahip bir cihazda, tarayıcı daha sizin JavaScript kodunuz çalışmadan bile bellek baskısı altındadır: daha agresif çöp toplama, daha sık sekme atma ve JIT derlemesi için daha az boş alan, doğrudan daha uzun görev sürelerine dönüşür. Modern bir telefonda 180 ms ile INP testini geçen bir site, Kısıtlı bir cihazda rahatlıkla 400 ms seviyesinde kalabilir.

2025 Web Almanac Performans bölümü bu eğilimi doğruluyor: mobil INP geçiş oranları genel olarak %77'ye ulaşıyor, ancak bu rakamdaki yüksek güçlü ve düşük donanımlı cihazlar arasındaki uçurum çok geniş. Mobil web kullanıcılarının yaklaşık %29'u, mevcut bir amiral gemisinden üç kat daha düşük güce sahip cihazlarda bulunuyor. Bu kullanıcılar çoğu küresel pazarda istisna değildir; onlar medyan ziyaretçilerdir.

CLS, donanım sınıfına INP'den daha az duyarlıdır; ancak yavaş CPU'lara sahip cihazlar, yazı tipleri veya geç yüklenen resimler, tarayıcı bir kareyi işledikten sonra tamamlanan yeniden akışlara (reflows) neden olduğunda yine de düzen kaymaları üretebilir.

CoreDash'te CCS ve Cihaz Belleği nasıl kullanılır

En verimli iş akışı, CCS'yi bir filtre olarak kullanarak başlamak ve ardından hipotezinizi doğrulamak için Cihaz Belleği'ni kullanmaktır.

İlk olarak, CCS'ye göre INP kırılımınızı açın. Eğer 75. yüzdelik INP değeriniz Çok Kapasiteli (CCS 1) ve Kapasiteli (CCS 2) ziyaretçiler için iyi durumdaysa ancak Sınırlı (CCS 3) ve altı için başarısız oluyorsa, bir ağ darboğazından ziyade bir CPU veya bellek darboğazınız var demektir. Bu durum, bütün bir düzeltme kategorisini (önceden yükleme, bağlantı ipuçları, CDN ayarları) devre dışı bırakır ve dikkatinizi JavaScript yürütme süresine odaklar: uzun görevler, girdi işleyici yükü ve her etkileşimde çalışan üçüncü taraf komut dosyaları.

Ardından, hangi RAM dilimlerinin en kötü sonuçlara yol açtığını görmek için Cihaz Belleği'ne göre filtreleyin. Eğer 1 GB'lık cihazlar zayıf INP puanlarında orantısız bir paya sahipse, eşiği biliyorsunuz demektir. 4 GB'ta kabul edilebilir olan komut dosyaları, yalnızca bu veriye dayanarak ertelenme veya kaldırılma adayı olabilirler.

Küresel kitlelere sahip siteler için CCS'yi Ülke boyutuyla eşleştirin. Güney ve Güneydoğu Asya pazarları, Sahra altı Afrika ve Latin Amerika'nın bazı bölgeleri Kısıtlı ve Çok Sınırlı cihazların yüksek yoğunluğuna sahiptir. Ülkeye göre filtrelenmiş bir CCS kırılımı, farkın nerede en büyük olduğunu size gösterecek ve ilk olarak hangi pazara yöneleceğinizi önceliklendirmenize yardımcı olacaktır.

Bilinmeyen (CCS 0) dilimi, tüm Firefox ve Safari trafiğinin yanı sıra API'lerin hiçbir değer döndürmediği tüm oturumları kapsar. Bunu görmezden gelmeyin. Önemli bir Firefox veya Safari payına sahip sitelerde Bilinmeyen, tüm oturumların dörtte birini veya daha fazlasını temsil edebilir. Bu, söz konusu kullanıcıların kötü cihazlara sahip olduğu anlamına gelmez; sinyalin kullanılamadığı anlamına gelir. Bilinmeyen dilimini temel ölçütünüze (baseline) dahil etmek yerine ayrı bir segment olarak ele alın.

Verilerle ne yapılmalı

CCS 3, 4 veya 5 ziyaretçileri trafiğinizin %15'inden fazlasını oluşturuyorsa ve INP değerleri sürekli olarak 200 ms'nin üzerindeyse, çözüm kümesi belirgindir:

• En uzun görevlerinizi Chrome DevTools'ta sınırlandırılmış (throttled) bir cihazda profillendirin. Performance panelindeki Task Attribution (Görev Nitelendirme) hangi komut dosyalarının sorumlu olduğunu gösterecektir.
• Kritik olmayan üçüncü taraf komut dosyalarını bir etkileşim veya görünürlük tetikleyicisinin arkasına taşıyın, böylece ilk yükleme penceresi sırasında ana iş parçacığı için rekabet etmezler.
• Kritik yollardaki JavaScript paket boyutunu küçültün. Düşük bellekli bir cihazda ayrıştırılan her kilobayt, amiral gemisi bir cihaza göre daha maliyetlidir çünkü JIT derleyicisinin derlenmiş kodu önbelleğe almak için daha az alanı vardır.
• Uzun görevleri parçalara ayırmak ve tarayıcıya parçalar arasında girdi olaylarını işlemesi için bir şans vermek amacıyla scheduler.yield() veya setTimeout(0) kullanın.

CoreDash, CCS ve Cihaz Belleği boyutlarını her Core Web Vitals metriğinin yanında sunar, böylece üst düzey cihazlarda INP'yi iyileştiren bir düzeltmenin sadece en iyi durumdaki kullanıcılarınız için değil, aynı zamanda Kısıtlı ziyaretçileriniz için de rakamları iyileştirip iyileştirmediğini doğrulayabilirsiniz.