Performans analizlerini nasıl ve neden oluşturduk?

Jack Franklin

Chrome 102'de, Geliştirici Araçları'nda yeni bir deneysel panel olan Performans Analizleri'ni görürsünüz. Bu gönderide, yalnızca neden yeni bir panel üzerinde çalıştığımızı değil, aynı zamanda karşılaştığımız teknik zorlukları ve süreç boyunca aldığımız kararları da 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 harika bir kaynaktır ancak bunun 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 Paneli'ne girin. Burada, izinlerinizin zaman çizelgesini görüntülemeye ve verileri incelemeye devam edebilir, ayrıca DevTools'un ayrıntılı olarak incelemeniz gereken temel "Analizler"i listeledikleri bir listeyi inceleyebilirsiniz. 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 tuvalde ç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 kanvasta 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 izleme sınırları dışında parça oluşturma tehlikesi bulunmadığı için kanal düzeyinde oluşturmayı basitleştirir. Ancak ne yazık ki bu yaklaşımın iki önemli sorunu vardır:

canvas öğelerinin oluşturulması (yeniden) pahalıdır. Birden fazla tuvale sahip olmak, daha büyük olsa bile tek bir kanvastan 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 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çanın yüksekliği 100 pikselse 120 piksel yüksekliğindeki bir parçanın, altındaki parçaya sığ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 gerekmiyordu: Her kanal kendisini (0, 0) konumundaymış gibi oluşturmalıydı ve genel kanal konumunu yönetmek için daha üst düzey bir bileşenimiz (TrackManager olarak adlandırdığımız) vardı. 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

Konum olarak rect kod ayarı 0, 0 olsa da uygulanan genel çeviri, dikdörtgenin 0, 10 konumunda oluşturulmasına neden olacaktır. 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şturdukça ç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. Tuvalin yeniden oluşturulması özellikle pahalıdır. Çünkü tuvalin küçük bir kısmını yeniden oluşturmak yeterli olmaz. Tuvalin tamamını silip yeniden çizmeniz gerekir. 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 yer alan metriklerin üzerine geldiğinizde metrik zaman çizelgesinde vurgulanır. Benzer şekilde, fareyle belirli bir etkinliğe ait bir analizin üzerine geldiğinizde söz konusu etkinliğin etrafına mavi bir kenar çizilir.

Bu özellik ilk olarak, vurgulamayı tetikleyen bir öğe üzerine fare hareketi algılanıp ardından vurguyu doğrudan ana zemine çizilerek uygulanmıştır. Sorunumuz, vurgulamayı kaldırmamız gerektiğinde ortaya çıkar: Tek seçenek, her şeyi yeniden çizmektir. Öne çıkarılan alanı yeniden çizmek (büyük mimari değişiklikler olmadan değil) imkansızdır. Sırf bir öğenin çevresindeki mavi kenarlığı kaldırmak istediğimiz için tüm tuvali yeniden çizmek imkansızdır. 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 tuvali kopyalama işi ucuzdur ve pahalıdır; bu nedenle, vurguları ayrı bir zemine taşıyarak vurgulamaları açıp kapatırken bu maliyetten kaçınmış oluruz.

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'da kayıt alıp saklayıp test paketimize yükleyerek iz ayrıştırma yöntemimizi kapsamlı bir şekilde test ettik. Bu muhteşem bir özellik, çünkü gerçek izlerle test edebilmemiz ve geçerliliğini yitirebilecek çok fazla sahte iz verisi biriktirmememiz gerekiyor.

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 çok işe yarıyor ancak bir tuvalde oluşturma fikrini düşünürken başarısız oluyor. Bir tuvali incelemenin ve orada çizilenleri belirlemenin 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 oluşturur, 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şturulduğunu 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 kullanıcı arayüzünde yapılan ufak, neredeyse alakasız değişiklikler (örneğin, kolay fark edilmeyen renk değişiklikleri veya öğeler arasına bir miktar boşluk eklemek) birden fazla ekran görüntüsünün başarısız olmasına ve güncellenmesi gereken 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şmenizi sağlar, en yeni web platformu API'lerini test etmenize olanak tanır 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.