CPU Süresi Neden Performansı Yavaşlatır?

Web tarafında CPU süresi neyi anlatır

En basit haliyle CPU süresi, tarayıcının belirli bir işi gerçekten işlemek için ne kadar zaman harcadığını anlatır. Bu iş; JavaScript yürütme, stil hesaplama, layout, boyama, görsel çözümleme ya da veri işleme olabilir.

Dosyanın gelmesi tek başına yeterli değildir; o dosyayla ne yapılacağı da önemlidir. Tarayıcı kodu indirir, açar, yorumlar, uygular ve çoğu zaman ek hesaplar yapar. İşte CPU yükü burada görünür hale gelir.

Bu ayrım kritik çünkü kullanıcı "sayfa yavaş" derken çoğu zaman gecikmenin nerede oluştuğunu söylemez. Oysa bazen bekleyen şey istek değil, işlenmesi uzun süren görevdir.

Ağ hızlıyken de bekleme hissi sürebilir

Bir sayfanın hızlı indirilmesi, hızlı kullanılacağı anlamına gelmez. Özellikle büyük bileşenler, yoğun veri tabloları ve ağır istemci mantığı olan projelerde dosyalar hızlı gelir ama tarayıcı onları anlamlı bir arayüze çevirmek için ciddi işlem harcar.

Kullanıcı bu farkı teknik terimle tarif etmez. Genelde "tıklayınca geç açılıyor", "sayfa bir an takılıyor" ya da "scroll ederken ağırlaşıyor" şeklinde hisseder. Bu belirtiler çok sık biçimde yüksek CPU süresiyle ilişkilidir.

Özellikle görsel tamamlanma akışı bozuluyorsa ya da etkileşim gecikmesi artıyorsa, CPU yükü görünmeyen ana nedenlerden biri olabilir. Çünkü tarayıcı önündeki işi bitirmeden yeni komuta alan açamaz.

Tarayıcının en çok CPU harcadığı alanlar

Birçok ekip CPU maliyetini yalnızca JavaScript ile eşleştirir, ama tablo biraz daha geniştir. Kod yürütme önemli olsa da tek kaynak değildir.

• JavaScript yürütme: Büyük paketler, karmaşık state akışı ve ağır hesaplar ana iş parçacığını uzun süre meşgul edebilir.
• Stil ve layout hesaplama: Çok sayıda düğüm, sık yeniden akış ve ölçüm-sonra-stil güncellemesi zincirleri maliyeti büyütür.
• Boyama ve kompozit: Gölge, blur, büyük katmanlar ve yoğun animasyon bazı cihazlarda düşündüğünüzden pahalı olabilir.
• Görsel çözümleme: Büyük medya dosyalarının decode edilmesi, sadece ağ değil işlem tarafında da yük oluşturur.
• Üçüncü taraf script'ler: Etiketler, test araçları ve gömülü bileşenler çoğu zaman görünmeyen CPU bütçesi tüketir.

Bu yüzden problem kaynağına bakarken yalnızca paket boyutunu görmek yetmez. Aynı boyuta sahip iki farklı sayfadan biri akıcı çalışırken diğeri takılıyorsa, asıl fark kodun ne zaman ve ne yoğunlukla çalıştığında gizlidir.

Mobil cihazlarda etki daha sert hissedilir

Çünkü düşük ve orta seviye telefonlarda aynı iş daha pahalıya mal olur. Masaüstünde çok kısa süren bir yürütme zinciri mobilde belirgin gecikmeye dönüşebilir. Üstelik bu fark sadece işlemci gücüyle sınırlı değildir; termal kısıtlar, güç tasarrufu davranışları ve tarayıcı motorunun cihaz üzerindeki maliyeti de etkilenir.

Bu yüzden laboratuvarda temiz görünen pek çok arayüz gerçek cihazda ağır hissedebilir. Özellikle liste filtreleme, sekme geçişi, büyük menü açılışı ve animasyonlu bloklar bu farkı hızlı biçimde ortaya çıkarır.

FCP ve LCP gibi yüklenme metrikleri makul görünse bile, CPU tarafı zayıfsa kullanım deneyimi yavaş kalabilir. Bu da ekibin "rapor iyi ama kullanıcı hâlâ ağır diyor" ikilemine düşmesine neden olur.

Yüksek CPU süresinin bozduğu metrikler

CPU yükü tek bir metriği değil, çoğu zaman bir grup metriği birlikte etkiler. Çünkü işlem süresi uzadığında hem yüklenme akışı hem etkileşim akışı bozulur.

• INP: Kullanıcı komutları işlenmeden bekler, tepki süresi uzar.
• Speed Index: Üst alan parça parça dolarsa görsel tamamlanma gecikir.
• LCP: Büyük görünür öğe istemci tarafında oluşturuluyor ya da geç işleniyorsa son görünme anı ötelenebilir.
• Total Blocking benzeri sinyaller: Uzun görevler ana thread'i işgal ederek zincirleme bekleme üretir.

Bu yüzden CPU süresi yüksek olduğunda sadece tek bir grafik çizgisine bakmak yeterli değildir. Farklı metriklerdeki bozulma bazen aynı temel işlem yükünden çıkabilir.

Profil çıkarırken bakılacak işaretler

İlk bakılması gereken şey, uzun görevlerin nerede kümelendiğidir. Eğer tarayıcı kaydında arka arkaya 50 ms üzeri bloklar görüyorsanız, kullanıcı komutlarına alan açmakta zorlanan bir ana iş parçacığı vardır.

Ardından şu sorular yardımcı olur:

• En çok süre JavaScript'te mi, style/layout hesaplarında mı harcanıyor?
• Bir etkileşim sonrası tek bir büyük görev mi, yoksa çok sayıda orta ölçekli görev mi çalışıyor?
• Üçüncü taraf kodlar kritik anda mı devreye giriyor?
• Üst alan görünmeden önce gereksiz bileşenler de hazırlanıyor mu?

Burada önemli olan yalnızca "çok CPU var" demek değil, bu maliyetin görünür fayda üretip üretmediğini ayırmaktır. Bazen pahalı iş gerçekten gerekli olabilir; bazen de yanlış zamanda çalıştığı için gereksiz görünür.

Gerçek fark yaratan optimizasyonlar

En büyük kazanç çoğu zaman daha az şey yapmaktan değil, doğru şeyi doğru anda yapmaktan gelir. Her işi ilk render anına ya da ilk etkileşime yüklemek, performansın en pahalı hatalarından biridir.

Özellikle JavaScript yükünü daha doğru dağıtmak, ilk ekrana gerekmeyen işleri ertelemek, büyük listeleri parçalara ayırmak, hesaplama maliyetini düşürmek ve gereksiz yeniden render zincirlerini azaltmak pratikte etkili sonuç verir.

Aynı şekilde görünür alanın dışında kalan pahalı bileşenleri geç hazırlamak, üst ekranı daha hafif kurmak ve sürekli ölçüm yapan kod yollarını sadeleştirmek de CPU bütçesini rahatlatır. Amaç sadece puan değil, tarayıcının nefes almasını sağlamaktır.

Üçüncü taraf kodların beklenmedik CPU maliyeti

Birçok projede ekip kendi uygulama kodunu dikkatle inceler ama etiket yöneticisi, sohbet aracı, reklam betiği, analiz pikseli ya da A/B test kodunun işlem maliyetini ikinci plana iter. Oysa bu parçalar çoğu zaman görünür faydaları sınırlı olsa bile ana iş parçacığı üzerinde ciddi yük üretir.

Sorun sadece dosya boyutu değildir. Küçük görünen bir script, sayfa açıldıktan sonra arka arkaya event dinleyicileri kurabilir, DOM'u tarayabilir, ölçüm yapabilir ya da kullanıcı etkileşiminde yeni görevler başlatabilir. Bu da özellikle orta sınıf mobil cihazlarda hissedilir gecikmeye dönüşür.

Üçüncü taraf araçların en riskli yanı, performans bütçesi içinde görünmeden çoğalabilmeleridir. Her ekip kendi eklediği betiği "küçük bir ihtiyaç" gibi görür. Ama birkaç küçük ihtiyaç bir araya geldiğinde CPU tarafında büyük birikim yaratır. Sayfa ilk anda kabul edilebilir görünse bile, menü açılışı, filtreleme ve kaydırma akıcılığı bundan zarar görebilir.

Bu yüzden performans gözden geçirmesinde "bizim kodumuz ne kadar pahalı" sorusu kadar "bizim adımıza çalışan üçüncü taraflar ne kadar pahalı" sorusu da sorulmalıdır. Kimi zaman en büyük kazanç kendi bileşeninizi küçültmekten değil, kritik anda gereksiz çalışan üçüncü tarafı ertelemekten gelir.

CPU süresini düşürmek için gerekli takip disiplini

CPU yükü tek seferlik temizlikle kalıcı biçimde çözülmez. Çünkü her yeni bileşen, her yeni script ve her yeni görsel davranış işlem bütçesinden pay alır. Eğer ekip bunun kaydını tutmuyorsa, performans borcu tekrar birikmeye başlar.

Pratikte işe yarayan yaklaşım, yüksek maliyetli ekranları ve kritik kullanıcı akışlarını ayrı ayrı notlamaktır. Hangi sayfada hangi etkileşim ağırlaşıyor, sorun ilk yükte mi sonradan mı başlıyor, değişiklikten sonra hangi kayıt iyileşti; bunlar düzenli tutulduğunda CPU darboğazı da daha yönetilebilir hale gelir.

Ayrıca her iyileştirmeyi yalnızca skor artışı üzerinden değerlendirmemek gerekir. Bazen CPU süresi belirgin azalır ama diğer metriklere etkisi sınırlı görünür. Böyle durumlarda kullanıcı hissine yakın işaretleri de izlemek önemlidir: daha az takılma, daha seri kaydırma, daha temiz etkileşim cevabı gibi. Teknik kayıtla kullanıcı hissi arasında köprü kurulduğunda ekip yanlış öncelik verme riskini azaltır.

CPU süresi takibi, performans kültürünün parçası haline geldiğinde daha iyi çalışır. Sorunu yalnızca bir kez ölçüp kapatmak yerine, yeni eklenen her özelliğin işlem maliyetini de tasarım ve geliştirme kararının doğal parçası olarak görmek gerekir.

Sık başvurulan ama sınırlı kalan çözümler

Sadece dosya küçültmek her zaman yeterli değildir. Kod daha küçük olsa bile hâlâ tek bir anda yoğun biçimde çalışıyorsa kullanıcı için fark sınırlı kalır. Aynı şekilde, görünürde akıcı hissettirmek için animasyon eklemek bazen CPU yükünü daha da yükseltebilir.

Bir başka yaygın hata da altyapıyı suçlayıp istemci tarafını ihmal etmektir. Sunucu tarafı düzeltilmiş olsa bile arayüz hâlâ pahalıysa, gerçek darboğaz kullanıcı cihazındadır. Bu yüzden performans tartışmasını sadece ağ ve sunucu çevresinde kurmak eksik kalır.

Sorunun arayüz tarafında yoğunlaştığı durumlar

Sayfa ilk yüklenmede çok kötü görünmüyor ama kullanım sırasında ağırlaşıyorsa, filtre açınca takılıyor, sekme değiştirince donuyor ya da form alanlarında gecikme başlıyorsa, problem çoğu zaman arayüz iş yükündedir. Bu durumda sunucu tepkisini biraz daha düşürmek sınırlı katkı verir.

Buna karşılık ilk ekrana gelmek bile uzun sürüyorsa CPU ile birlikte ağ ve kaynak teslimi tarafını da düşünmek gerekir. Yani doğru teşhis, gecikmenin hangi anda oluştuğunu ayırmakla başlar.

CPU süresi, performansın arka planda çalışan maliyetidir. Kullanıcı bunu adını koymadan hisseder; ekip ise ancak bu maliyeti görünür hale getirdiğinde gerçekten etkili öncelik sırası kurabilir.