Yayınlanma tarihi: 4 Nisan 2025
Gerçek dünyadaki performans sorunlarını düzeltmek, geliştirme ortamınız ile kullanıcılarınızın farklı performans deneyimleri arasındaki boşluğu doldurmak anlamına gelir. Bu yayında, Chrome DevTools'taki performans hata ayıklama kararlarınızın daha fazlasını tahminden ziyade gerçek verilere dayandırmanıza yardımcı olacak yeni özelliklere göz atacağız.
Beklentileri kalibre etme
Chrome 134'ten itibaren DevTools, doğru CPU kısıtlama düzeyini seçmeyle ilgili belirsizliği ortadan kaldıran yeni bir araç olan CPU kısıtlama kalibrasyonunu içerir. Kalibrasyonu bir kez çalıştırdığınızda DevTools, geliştirme makinenize özel "alt segment mobil" ve "orta segment mobil" kısıtlama hazır ayarları oluşturur.
Web performansı çalışmalarında sık karşılaşılan bir uyumsuzluk, geliştiriciler olarak genellikle hızlı masaüstü cihazlarda siteler oluştururken kullanıcılarımızın çoğunun daha mütevazı mobil cihazları kullanmasıdır. Yalnızca çok daha yavaş bir CPU'ya sahip bir cihazda ortaya çıkan performans sorunlarını tespit etmek zor olabilir.
En iyi yöntem gerçek bir mobil cihazda uzaktan hata ayıklama olsa da Chrome, geliştirme sırasında hızlı ve hafif iterasyon döngüleri için yaklaşık on yıldır CPU tarama özelliğini de destekliyor.
Peki hangi CPU throttling seviyesini seçmelisiniz? 4x? 20x? Sitenizi ziyaret ettiğini bildiğiniz cihaz türleriyle en iyi eşleşeni nasıl anlarsınız? Üst düzey bir iş istasyonunda mı yoksa 8 yaşındaki bir Chromebook'u hareket halindeyken mi kullanıyorsunuz? Cihazınızın hızı bu kararı nasıl etkiler?
Kısıtlama kalibrasyonu süreci
Performans paneli açıldığında, Ortam ayarlarında CPU tarama düzeyini ayarlamak için bir açılır menü bulunur. Daha önce kalibrasyon yapmadıysanız açılır menüdeki "Kalibre edilmiş hazır ayarlar" bölümünde iki devre dışı seçenek ve en altta Kalibre et… seçeneğini görürsünüz.
Bu seçeneği belirlediğinizde Ayarlar'daki CPU tarama hazır ayarlarına yönlendirilirsiniz (buraya doğrudan da gidebilirsiniz).
- Kalibre et düğmesini tıklayın.
- Geçerli sayfadan kısa süreliğine ayrılacağınız konusunda uyarılınca Devam'ı tıklayın.
- Mevcut makinenizin hızını ölçmek için hızlı bir karşılaştırma çalıştırılır ve kalibrasyon tamamlanır.
Düşük ve orta sınıf cihazlar için kalibre edilmiş hazır ayarlar artık akış kısıtlaması seçeneklerine eklendi.
Bu iki hazır ayar, çoğu geliştirme kullanım alanı için yeterli olacaktır. Genellikle web'de görülen "tipik" bir mobil cihazla eşleştiği için "orta katman" hazır ayarını öneririz. Kullanıcılarınızın çoğunun daha da yavaş cihazlara sahip olduğunu veya performans sorunlarının yalnızca bu kullanıcılarda ortaya çıktığını biliyorsanız "düşük seviye" seçeneği, düşük kaliteli cihazların uzun kuyruğunu bile yakalayacak kadar yavaş olmalıdır.
Son olarak, kalibrasyonda bir sorun olduğunu düşünüyorsanız veya yerel makinenizde bir değişiklik olduysa istediğiniz zaman kısıtlama açılır menüsünden veya ayarlardan yeniden kalibrasyon yapabilirsiniz. Bu işlem, karşılaştırmayı yeniden çalıştırır ve hazır ayarları günceller.
DevTools'ta CPU kısıtlaması nasıl çalışır?
DevTools'ta CPU salma işleminin nasıl çalıştığını merak ettiyseniz bu işlemin temel mantığını anlamak oldukça kolaydır. Bir sekme için akış kısıtlamasını etkinleştirdiğinizde Chrome, sekmenin ana iş parçacığının sık sık kısa süreli kesintiye uğramasına ve askıya alınmasına neden olan ayrı bir akış kısıtlaması iş parçacığı başlatır. Amaç, ana iş parçacığının toplamda belirli bir görevin süresinin azaltma faktörü kadar artacağı kadar uzun süre askıya alınmasıdır.
Örneğin, CPU'da 4 kat azaltma yapıldığında ana iş parçacığı yaklaşık% 75 oranında askıya alınır. Bu da ana iş parçacığındaki işlemlerin tamamlanmasının dört kat daha uzun sürmesine neden olur.
Bu yaklaşımın avantajı, Chrome'un geri kalanı için çoğunlukla şeffaf olmasıdır. JavaScript'i, düzeni veya bir tarayıcının yapması gereken diğer birçok iş türünün her birini yavaşlatmak için özel kod gerekmez. İş parçacığının yalnızca zamanın bir kısmında yürütülmesine izin verildiğinden, ana iş parçacığındaki tüm işlemler daha uzun sürer.
CPU throttling gerçek bir mobil cihaz gibi davrandığında
Sonuç olarak, CPU'ya bağlı birçok mobil çalışma türü, CPU throttling ile iyi bir şekilde simüle edilir. Örneğin, bir etkileşim JavaScript'i ve sayfa düzenini tetiklerse mobil cihazda çalışacağı şekilde yürütülme olasılığı yüksektir.
Bir düğmenin tıklanmasıyla tetiklenen ve DOM'ye yeni öğeler eklemek için JavaScript çalıştıran bir görevi düşünün. Bu işlem, tarayıcının yeni içeriği konumlandırmak için Stil ve Düzen hesaplamalarını çalıştırmasını gerektirir:
Kalibre edilmiş "orta kademe mobil" CPU tarama hazır ayarı (bu geliştirme makinesinde 3,7x) kullanıldığında etkileşim çok benzer görünür ancak süre önemli ölçüde artarak uzun bir görev haline gelir:
Aynı etkileşimi uzaktan hata ayıklama özelliğini kullanarak gerçek bir orta katman cihazda test etmek, hem etkileşimin izinin şekli hem de süresi açısından oldukça benzer bir sonuç verir. Bu görev, ana iş parçacığında çoğunlukla CPU'ya bağlı olduğundan (sayfanın JavaScript kodunu ve Chrome'un stil ve düzen kodunu yürütür) kalibre edilmiş throttling, gerçek mobil performansı doğru şekilde yeniden oluşturur:
Gerçek bir mobil cihazda test yapmak isteyebileceğiniz durumlar
CPU throttling çok yararlı olsa da mobil donanımın tüm yönlerini simüle edemez. Telefonlarda disk hızı daha yavaştır, bellek bant genişliği daha sınırlıdır ve yürütme hızını düşürmek için termal sınırlama herhangi bir zamanda devreye girebilir.
Sık karşılaşılan bir kısıtlama, GPU'ya yoğun iş yükleridir. Mobil ve masaüstü GPU'lar mimari olarak farklıdır ve Chrome, GPU işlemlerini sayfanın ana iş parçacığından ayrı bir işlemde yürütür. Sonuç olarak, DevTools CPU throttling, GPU işlemine dokunmaz (Bu, DevTools'un ve tarayıcının geri kalanının yanıt verimini etkileyeceği için en iyisidir).
Karmaşık boyama, kompozisyon ve efekt ağırlıklı stil, geliştirme makinesinde iyi görünen ancak mobil cihazlarda beklenmedik şekilde yavaş olan yaygın performans sorunlarındandır. Ayrıca, sorunu geliştirme makinenizde yeniden oluşturmaya çalışırken bir sorun olduğunu fark etmek zor olabilir.
Önceki gibi aynı etkileşimi düşünün (DOM'a tıklayıp çok sayıda öğe ekleyin). Ancak bu sefer yeni öğeler, GPU'ya ağırlık veren çok sayıda kutu gölgesi ve bulanıklaştırma filtresiyle biçimlendirilir.
Etkileşimin başlangıç şekli ve süresi benzer görünüyor ancak eklenen efektler için sonunda uzun bir yeni ana iş parçacığı boyası var:
Gerçek bir orta sınıf telefonda, etkileşimin ana iş parçacığı, ek boya da dahil olmak üzere simüle edilene çok benzer görünür. Ancak etkileşimin sonucu ekranda görünmeden önce, çılgın bir GPU işleminin çok fazla iş yaptığı görülür:
GPU çalışması, etkileşimi 300 milisaniye daha uzatır ve (ana iş parçacığı) CPU tarama özelliği etkinleştirilmiş olsa bile dizüstü bilgisayar GPU'su için neredeyse hiç bulunmayan bir iştir.
Emulasyonun önemli dezavantajları olan başka durumlar da vardır. Örneğin, taklit edilen ağ tıkanması, işlemler arası iletişimler ve disk ile bellek önbellekleri arasında etkileşim olan derin bağımlılık sayfa yüklemeleri.
Uygulamanızı mutlaka gerçek mobil cihazlarda test edin. Ayrıca, saha verilerinizin mobil kullanıcıları etkilediğini gösterdiği bir sorunu laboratuvarda masaüstü makinenizde yeniden oluşturamıyorsanız gözden kaçırdığınız bir fark olup olmadığını görmek için gerçek bir cihazla uzaktan hata ayıklama özelliğini mutlaka deneyin.
Veriye dayalı hata ayıklamayla ilgili daha fazla iyileştirme
Yakın zamanda, hata ayıklama ayarlarını ve kararlarını gerçek kullanıcılarınıza göre belirlemeyi kolaylaştırmaya yardımcı olacak bazı yeni özellikler kullanıma sunuldu.
Alan verilerini etkinleştirdiyseniz Performans paneli, Chrome Kullanıcı Deneyimi Raporu (CrUX) tarafından ölçülen 75. yüzdelik dilimdeki kullanıcılarınıza göre akış kısıtlaması önerileri sunar. Yerel olarak ölçülen metrikleriniz alan verilerinden farklıysa anlık metrik görünümü sizi uyarır. Bu konu, gerçek Core Web Vitals verilerini DevTools'a getirme hakkındaki önceki bir yayında ayrıntılı olarak ele alınmıştır.
Kenar çubuğundaki performans paneli analizleri, artık bir izlemede ölçülen metrikler kullanıcılarınızın gerçek dünyada deneyimlediğiyle eşleşmezse sizi de uyarıyor.
Alan verilerinin etkinleştirilmesi, analizlerin kenar çubuğunda gösterilme sırasını belirlemeye yardımcı olmak için 75. yüzdelik dilimdeki Core Web Vitals'inizi kullanmanıza da olanak tanır. Örneğin, kullanıcılarınız genellikle Largest Contentful Paint (LCP) metriğinde iyi ancak Interaction to Next Paint (INP) metriğinde kötü performans gösteriyorsa INP'yi iyileştirmeye yardımcı olan analizler listenin en üstüne çıkar.
Son olarak, birden fazla izleme arasında geçiş yaptıysanız veya izlemeleri diskten yüklediyseniz her izlemede hangi mobil emülasyon ve tarama ayarlamalarını kullandığınızı tam olarak hatırlamanız zor olabilir. Performans panelinin üst kısmındaki izleme seçimi açılır menüsünde artık her izleme için emülasyon bilgileri gösteriliyor.
Durdurma, kalibre etme ve dinleme
Sorun giderme kararlarımızı gerçek dünyaya dayandırmamız gerekir. Öncelikle sorunları bulmak için analizlerden ve kullanıcı raporlarından elde edilen alan verilerini kullanır, ardından teşhis için bu kullanıcı deneyimlerini laboratuvarda yeniden oluştururuz. Bu yeni DevTools eklemeleri, bu süreci biraz daha kolaylaştırmaya yardımcı olacaktır.
CPU tarama kalibrasyonunun yanı sıra farklı saha ve laboratuvar deneyimleriyle ilgili uyarılar, doğru yolda olup olmadığınız konusundaki belirsizliği azaltır ve gerçek dünyadaki performansa daha tutarlı bir yaklaşım sağlar. DevTools, yapılandırmayı tahmine dayalı olmaktan çıkararak ve olası tutarsızlıkları vurgulayarak kullanıcılarınızı etkileyen gerçek performans sorunlarını düzeltmeye odaklanarak daha fazla zaman geçirmenize yardımcı olmayı amaçlar.
Daha fazla iyileştirme veya yeni özellik öneriniz mi var? Düşüncelerinizi bizimle paylaşın.