Performans analizlerini nasıl ve neden oluşturduk?

Jack Franklin

Chrome 102'de, Geliştirici Araçları'nda Performans Analizleri adlı yeni bir deneysel panel görürsünüz. Bu yayında, yeni bir panel üzerinde neden çalıştığımızı ve bu süreçte karşılaştığımız teknik zorlukları ve verdiğimiz kararları ele alacağız.

ALT_TEXT_HERE

Neden başka bir panel oluşturmalısınız?

(Henüz görmediyseniz Performans Analizleri panelini neden oluşturduğumuz ve bu paneli kullanarak web sitenizin performansıyla ilgili nasıl uygulanabilir analizler elde edebileceğiniz hakkında bir video yayınladık.)

Web sitenizle ilgili tüm verileri tek bir yerde görmek istiyorsanız mevcut Performans Paneli mükemmel bir kaynaktır ancak bu panelin biraz göz korkutucu olabileceğini düşündük. Performans uzmanı değilseniz tam olarak nelere bakacağınızı ve kaydın hangi bölümlerinin alakalı olduğunu bilmek zordur.

Analizler paneline girin. Burada, izlemenizin zaman çizelgesini görüntüleyebilir ve verileri inceleyebilir, ayrıca DevTools'un incelenmeye değer başlıca "Analizler" olarak kabul ettiği öğelerin kullanışlı bir listesini alabilirsiniz. Analizler, web sitenizin sayfa yükleme performansını ve özellikle de sitenizin Core Web Vitals (CWV) puanlarını olumsuz yönde etkileyebilecek oluşturmayı engelleyen istekler, düzen değişiklikleri ve uzun görevler gibi sorunları tespit eder. Performans Analizleri, sorunların işaretlenmesinin yanı sıra CWV puanlarınızı iyileştirmeye yönelik uygulanabilir öneriler ve diğer kaynakların ve dokümanların bağlantılarını sağlar.

Paneldeki geri bildirim bağlantısı

Bu panel deneyseldir ve geri bildirimlerinizi bekliyoruz. Herhangi bir hatayla karşılaşırsanız veya sitenizin performansıyla ilgili çalışırken size yardımcı olacağını düşündüğünüz özellik istekleriniz varsa lütfen bize bildirin.

Performans analizlerini nasıl oluşturduk?

DevTools'un geri kalanı gibi, Performans Analizleri'ni de TypeScript'te oluşturduk ve kullanıcı arayüzünü oluşturmak için lit-html tarafından desteklenen web bileşenlerini kullandık. Performans Analizleri'nin farkı, birincil kullanıcı arayüzü arayüzünün bir HTML canvas öğesi olması ve zaman çizelgesinin bu kanvas üzerine çizilmesidir. Karmaşıklığın çoğu bu tuvali yönetmekten kaynaklanır: Yalnızca doğru ayrıntıları doğru yere çizmekle kalmaz, fare etkinliklerini de yönetirsiniz (örneğin: Kullanıcı tuvali nerede tıkladı? Kullanıcı, çizdiğimiz bir etkinliği tıkladı mı?) ve kanvası etkili bir şekilde yeniden oluşturduğumuzdan emin olun.

Tek bir tuvalde birden fazla parça

Belirli bir web sitesi için, her biri farklı bir veri kategorisini temsil eden birden fazla "parça"yı oluşturmak isteriz. Örneğin, Analizler panelinde varsayılan olarak üç kanal gösterilir:

Panele yeni özellikler eklemeye devam ettikçe daha fazla kanalın eklenmesini bekliyoruz.

İlk düşüncemiz, bu kanalların her birinin kendi <canvas>'ünü oluşturmasıydı. Böylece ana görünüm, dikey olarak yığılmış birden fazla kanvas öğesi haline gelecekti. Bu, her parça ayrı olarak oluşturulabileceği ve parçaların sınırları dışında oluşturulma tehlikesi olmayacağı için parça düzeyinde oluşturmayı basitleştirir. Ancak bu yaklaşımın maalesef iki önemli sorunu vardır:

canvas öğelerinin (yeniden) oluşturulması pahalıdır; birden fazla kanvas kullanmak, kanvas daha büyük olsa bile tek bir kanvas kullanmaktan daha pahalıdır. Birden fazla kanala yayılan yer paylaşımlarını (ör. FCP süresi gibi etkinlikleri işaretlemek için kullanılan dikey çizgiler) oluşturmak karmaşık bir işlemdir: Birden fazla kanvas üzerinde oluşturmamız ve bunların hepsinin birlikte oluşturulduğundan ve düzgün şekilde hizalandığından emin olmamız gerekir.

Kullanıcı arayüzünün tamamı için tek bir canvas kullanılması, her kanalın doğru koordinatlarda oluşturulmasını ve başka bir kanala taşmamasını nasıl sağlayacağımızı bulmamızı gerektiriyordu. Örneğin, belirli bir parça 100 piksel yüksekliğindeyse 120 piksel yüksekliğinde bir öğenin oluşturulmasına ve bu öğenin altındaki parçaya taşmasına izin veremeyiz. Bu sorunu çözmek için clip kullanabiliriz. Her parçayı oluşturmadan önce, görünür parça penceresini temsil eden bir dikdörtgen çizeriz. Bu sayede, bu sınırların dışında çizilen tüm yolların tuval tarafından kırpılmasını sağlayabilirsiniz.

canvasContext.beginPath();
canvasContext.rect(
    trackVisibleWindow.x, trackVisibleWindow.y, trackVisibleWindow.width, trackVisibleWindow.height);
canvasContext.clip();

Ayrıca her kanalın dikey konumunu bilmesi gerekmemesini istedik: Her kanal kendisini (0, 0) konumundaymış gibi oluşturmalıdır ve genel kanal konumunu yönetmek için daha üst düzey bir bileşenimiz (TrackManager olarak adlandırdığımız) vardır. Bu işlem, kanvası belirli bir (x, y) konumuna göre çeviren translate ile yapılabilir. Örneğin:

canvasContext.translate(0, 10); // Translate by 10px in the y direction
canvasContext.rect(0, 0, 10, 10); // draw a rectangle at (0, 0) that’s 10px high and wide

rect kodunun konum olarak 0, 0 değerini ayarlamasına rağmen, uygulanan genel çevirme, dikdörtgenin 0, 10 konumunda oluşturulmasına neden olur. Bu sayede, (0, 0) noktasında oluşturma yapıyormuşuz gibi parça bazında çalışabilir ve parça yöneticimizin her parçayı oluşturduktan sonra çevirmesini sağlayarak her parçanın öncekinin altında doğru şekilde oluşturulmasını sağlayabiliriz.

Parçalar ve öne çıkan anlar için ekran dışı kanvaslar

Tuval oluşturma işlemi nispeten pahalıdır. Analizler panelinin, siz çalışırken sorunsuz ve duyarlı kalmasını sağlamak istiyoruz. Bazen tuvalin tamamını yeniden oluşturmanız gerekebilir. Örneğin, yakınlaştırma düzeyini değiştirirseniz baştan başlamamız ve her şeyi yeniden oluşturmamız gerekir. Özellikle kanvasın küçük bir kısmını yeniden oluşturamazsınız. Bunun yerine kanvasın tamamını silerek yeniden çizmeniz gerekir. Bu nedenle, kanvasın yeniden oluşturulması oldukça pahalıdır. Bu, araçların gereken minimum çalışmayı hesaplayabileceği ve her şeyi kaldırıp yeniden başlamadığı DOM yeniden oluşturma işleminin aksinedir.

Görsel sorunlarla karşılaştığımız alanlardan biri vurgulama özelliğiydi. Fareyle bölmede metriklerin üzerine geldiğinizde metrik zaman çizelgesinde vurgulanır. Benzer şekilde, fareyle belirli bir etkinlikle ilgili bir analizin üzerine geldiğinizde söz konusu etkinliğin etrafına mavi bir kenar çizilir.

Bu özellik ilk olarak, farenin bir öğe üzerinde hareket ettiğinde vurguyu tetikleyen ve ardından bu vurguyu doğrudan ana kanvas üzerine çizen bir yöntemle uygulandı. Sorunumuz, öne çıkan anı kaldırmamız gerektiğinde ortaya çıkıyor: Tek seçenek her şeyi yeniden çizmek. Vurgulanan alanın yeniden çizilmesi (büyük mimari değişiklikler olmadan) imkansızdır. Ancak yalnızca bir öğenin etrafındaki mavi kenarlığı kaldırmak için kanvasın tamamını yeniden çizmek abartılı bir işlem gibiydi. Ayrıca, farenizi hızlıca farklı öğelerin üzerine getirerek art arda birden fazla öne çıkan anı tetiklediğinizde görsel olarak gecikme yaşanıyordu.

Bu sorunu düzeltmek için kullanıcı arayüzümüz iki ekran dışı tuvale ayrıldı: Parçaların oluşturulduğu "ana" tuval ve öne çıkan anların çizildiği "öne çıkan anlar" tuvali. Ardından bu kanvasları, kullanıcının ekranda gördüğü tek kanvaya kopyalayarak oluşturuyoruz. Bir kanvas bağlamında drawImage yöntemini kullanabiliriz. Bu yöntem, kaynağı olarak başka bir kanvas alabilir.

Bu sayede, bir vurgunun kaldırılması ana kanvasın yeniden çizilmesine neden olmaz. Bunun yerine, ekrandaki kanvası temizleyip ana kanvası görünür kanvaya kopyalayabiliriz. Bir kanvası kopyalamak ucuzdur, pahalı olan çizimdir. Bu nedenle, öne çıkan anları ayrı bir kanvaya taşıyarak öne çıkan anları açıp kapatırken bu maliyetten kaçınırız.

Kapsamlı şekilde test edilmiş izleme ayrıştırma

Yeni bir özelliği sıfırdan oluşturmanın avantajlarından biri, daha önce yapılan teknik seçimleri gözden geçirip iyileştirmeler yapabilmenizdir. İyileştirmek istediğimiz konulardan biri, kodumuzu neredeyse tamamen farklı iki bölüme açıkça ayırmaktı:

İz dosyasını ayrıştırın ve gerekli verileri alın. Bir parça grubunu oluşturma.

Ayrıştırmayı (1. bölüm) kullanıcı arayüzü çalışmalarından (2. bölüm) ayrı tutmak, sağlam bir ayrıştırma sistemi oluşturmamıza olanak tanıdı. Her izleme, farklı endişelerden sorumlu bir dizi işleyici üzerinden çalıştırılır: LayoutShiftHandler, düzen değişiklikleri için ihtiyaç duyduğumuz tüm bilgileri hesaplar ve NetworkRequestsHandler yalnızca ağ isteklerini almayla ilgilenir. İzlemenin farklı bölümlerinden sorumlu farklı işleyicilere sahip olduğumuz bu açık ayrıştırma adımı da faydalı oldu: İzlemenin ayrıştırılması çok karmaşık olabilir ve aynı anda tek bir soruna odaklanabilmenize yardımcı olur.

Ayrıca, DevTools'ta kayıtlar alarak, bunları kaydedip test paketimizin bir parçası olarak yükleyerek izleme ayrıştırma işlemimizi kapsamlı bir şekilde test edebildik. Bu, gerçek izlerle test yapabildiğimiz ve eskiyebilecek büyük miktarlarda sahte izleme verisi oluşturmadığımız için mükemmel bir özelliktir.

Kanvas kullanıcı arayüzü için ekran görüntüsü testi

Test konusuna devam edecek olursak, genellikle ön uç bileşenlerimizi tarayıcıda oluşturarak ve beklenen şekilde davrandıklarından emin olarak test ederiz. Güncellemeleri tetiklemek için tıklama etkinlikleri gönderebilir ve bileşenlerin oluşturduğu DOM'un doğru olduğunu doğrulayabiliriz. Bu yaklaşım bizim için iyi çalışıyor ancak kanvas oluşturma söz konusu olduğunda işe yaramıyor. Bir kanvası inceleyip üzerinde nelerin çizildiğini belirlemenin hiçbir yolu yok. Bu nedenle, oluşturma ve ardından sorgulamaya yönelik olağan yaklaşımımız uygun değildir.

Test kapsamını biraz genişletmek için ekran görüntüsü testine başvurduk. Her test bir kanvas başlatır, test etmek istediğimiz parçayı oluşturur ve ardından kanvas öğesinin ekran görüntüsünü alır. Bu ekran görüntüsü daha sonra kod tabanımızda depolanır ve sonraki test çalıştırmalarında depolanan ekran görüntüsü, oluşturulan ekran görüntüsüyle karşılaştırılır. Ekran görüntüleri farklıysa test başarısız olur. Ayrıca, oluşturmayı kasıtlı olarak değiştirdiğimizde ve testin güncellenmesi gerektiğinde testi çalıştırmak ve ekran görüntüsünü güncellemeyi zorunlu kılmak için bir işaret de sağlarız.

Ekran görüntüsü testleri mükemmel değildir ve biraz kabadır; daha spesifik iddialar yerine yalnızca bileşenin tamamının beklendiği gibi oluşturulup oluşturulmadığını test edebilirsiniz. Başlangıçta, her bir bileşenin (HTML veya tuval) doğru şekilde oluşturulduğundan emin olmak için bunları aşırı derecede kullandığımız için suçlu olduğumuzu kabul ediyoruz. Bu durum, test paketimizi önemli ölçüde yavaşlattı ve küçük, neredeyse alakasız kullanıcı arayüzü ayarlarının (ince renk değişiklikleri veya öğeler arasına biraz kenar boşluğu ekleme gibi) birden fazla ekran görüntüsünün başarısız olmasına ve güncellenmesine neden olduğu sorunlara yol açtı. Artık ekran görüntülerini yalnızca kanvas tabanlı bileşenler için kullanıyoruz. Bu denge, şimdiye kadar bizim için iyi sonuç verdi.

Sonuç

Yeni Performans Analizleri panelini oluşturmak ekip için çok keyifli ve eğitici bir deneyim oldu. İzleme dosyaları, tuval ile çalışma ve daha pek çok konu hakkında bilgi edindik. Yeni panelden memnun kalacağınızı umuyor ve geri bildirimlerinizi sabırsızlıkla bekliyoruz.

Performans Analizleri paneli hakkında daha fazla bilgi edinmek için Performans analizleri: Web sitenizin performansıyla ilgili uygulanabilir analizler edinin başlıklı makaleyi inceleyin.

Önizleme kanallarını indirme

Varsayılan geliştirme tarayıcınız olarak Chrome Canary, Yeni Geliştirilenler veya Beta sürümünü kullanabilirsiniz. Bu önizleme kanalları, en son DevTools özelliklerine erişmenize, en yeni web platformu API'lerini test etmenize ve sitenizdeki sorunları kullanıcılarınızdan önce bulmanıza yardımcı olur.

Chrome Geliştirici Araçları Ekibi ile iletişime geçme

Yeni özellikler, güncellemeler veya Geliştirici Araçları ile ilgili başka herhangi bir konu hakkında konuşmak için aşağıdaki seçenekleri kullanın.