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öreceksiniz. Bu yayında, yeni bir panel üzerinde çalışmamızın nedenlerinin yanı sıra karşılaştığımız teknik zorlukları ve bu süreçte 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 oluşturmanın neden önemli olduğu ve bu panelle web sitenizin performansı hakkında nasıl harekete geçirici analizler elde edebileceğinizle ilgili bir video yayınladık.)

Web sitenizin tüm verilerini tek bir yerde görmek istiyorsanız mevcut performans paneli harika bir kaynak olsa da bu panelin biraz karmaşık olabileceğini düşündük. Performans uzmanı değilseniz tam olarak ne arayacağınızı ve kaydın hangi bölümlerinin alakalı olduğunu bilmek zordur.

İzlemenizin zaman çizelgesini görüntüleyebileceğiniz ve verileri inceleyebileceğiniz, ancak DevTools'un incelenmeye değer ana "Analizler" olarak kabul ettiği öğelerin kullanışlı bir listesini de alabileceğiniz Analizler Paneli'ne girin. Analizler, oluşturmayı engelleyen istekler, düzen kaymaları ve uzun görevler gibi sorunları tespit eder. Bu sorunların tümü, web sitenizin sayfa yükleme performansını ve özellikle sitenizin Core Web Vitals (CWV) puanlarını olumsuz etkileyebilir. Performans analizleri, sorunları işaretlemenin yanı sıra CWV puanlarınızı iyileştirmek için uygulanabilir öneriler sunar ve daha fazla kaynak ile dokümana bağlantılar sağlar.

Paneldeki geri bildirim bağlantısı

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

Performans analizlerini nasıl geliştirdik?

Geliştirici Araçları'nın geri kalanı gibi, Performans Analizleri'ni de TypeScript ile oluşturduk ve kullanıcı arayüzünü oluşturmak için lit-html tarafından desteklenen web bileşenlerini kullandık. Performans analizlerinin farklı olduğu nokta, birincil kullanıcı arayüzünün bir HTML canvas öğesi olması ve zaman çizelgesinin bu tuval üzerine çizilmesidir. Karmaşıklığın büyük bir kısmı bu tuvali yönetmekten kaynaklanır: Yalnızca doğru ayrıntıları doğru yere çizmek değil, aynı zamanda fare etkinliklerini yönetmek (örneğin: kullanıcı tuvalde nereye tıkladı? Kullanıcılar, çizdiğimiz bir etkinliği tıkladı mı?) ve tuvali etkili bir şekilde yeniden oluşturduğumuzdan emin olmamızı sağlar.

Tek bir tuvalde birden fazla parça

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

Panele yeni özellikler eklemeye devam ettikçe daha fazla parça eklenmesini bekliyoruz.

İlk düşüncemiz, ana görünümün dikey olarak yerleştirilmiş birden fazla tuval öğesi haline gelmesi için bu parçaların her birinin kendi <canvas> öğesini oluşturmasıydı. Bu yaklaşım, her parça ayrı olarak işlenebileceği ve bir parçanın kendi sınırları dışında işlenme tehlikesi olmayacağı için parça düzeyinde işlemeyi basitleştirir. Ancak bu yaklaşımın iki büyük sorunu vardır:

canvas öğelerinin (yeniden) oluşturulması maliyetlidir. Tuval daha büyük olsa bile birden fazla tuval kullanmak tek bir tuval kullanmaktan daha maliyetlidir. Birden fazla parça boyunca uzanan yer paylaşımlarının (örneğin, FCP süresi gibi etkinlikleri işaretlemek için kullanılan dikey çizgiler) oluşturulması karmaşık bir hâl alır: Birden fazla tuvalde oluşturma yapmamız ve bunların hepsinin birlikte oluşturulup düzgün şekilde hizalandığından emin olmamız gerekir.

Tüm kullanıcı arayüzü için tek bir canvas kullanmak, her parçanın doğru koordinatlarda oluşturulmasını ve başka bir parçaya taşmamasını nasıl sağlayacağımızı bulmamız gerektiği anlamına geliyordu. Ö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 tuval tarafından kırpılır.

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

Ayrıca, her parçanın dikey konumunu bilmesini istemedik: Her parça, (0, 0) konumunda oluşturuluyormuş gibi oluşturulmalı ve genel parça konumunu yönetmek için daha üst düzey bir bileşen (TrackManager olarak adlandırıyoruz) kullanıyoruz. Bu işlem, tuvali belirli bir (x, y) konumuna ç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 kod ayarı konumu 0, 0 olarak belirlese de uygulanan genel çeviri, dikdörtgenin 0, 10 konumunda oluşturulmasına neden olur. Bu sayede, (0, 0) konumunda oluşturuyormuş gibi parça bazında çalışabiliriz. Parça yöneticimiz, her parçayı oluştururken çevirerek her parçanın bir öncekinin altında doğru şekilde oluşturulmasını sağlar.

Parçalar ve önemli anlar için ekran dışı tuval

Canvas oluşturma işlemi nispeten maliyetlidir. Bu nedenle, siz panelde çalışırken Analizler panelinin sorunsuz ve hızlı yanıt vermeye devam etmesini istiyoruz. Bazen tüm tuvali yeniden oluşturmak kaçınılmaz olabilir. Örneğin, yakınlaştırma düzeyini değiştirdiğinizde her şeyi yeniden oluşturmamız gerekir. Canvas'ın yeniden oluşturulması özellikle maliyetlidir. Çünkü Canvas'ın yalnızca küçük bir bölümünü yeniden oluşturamazsınız. Canvas'ın tamamını silip yeniden çizmeniz gerekir. Bu durum, araçların gereken minimum çalışmayı hesaplayabildiği ve her şeyi kaldırıp yeniden başlamadığı DOM yeniden oluşturma işleminden farklıdır.

Görsel sorunlarla karşılaştığımız alanlardan biri vurgulama oldu. Fareyle bölmedeki metriklerin üzerine geldiğinizde bu metrikler zaman çizelgesinde vurgulanır. Benzer şekilde, belirli bir etkinliğin analizi üzerine geldiğinizde bu etkinliğin etrafına mavi bir kenarlık çizilir.

Bu özellik ilk olarak, vurgulamayı tetikleyen bir öğenin üzerinde fare hareketi algılanarak ve ardından bu vurgulama doğrudan ana tuval üzerine çizilerek uygulanmıştır. Öne çıkan anı kaldırmamız gerektiğinde tek seçeneğimiz her şeyi yeniden çizmek oluyor. Vurgunun yapıldığı alanı yeniden çizmek (büyük mimari değişiklikler yapmadan) mümkün olmasa da yalnızca bir öğenin etrafındaki mavi kenarlığı kaldırmak için tüm tuvali yeniden çizmek gereksiz bir işlem gibi görünüyordu. Ayrıca, fareyi farklı öğelerin üzerinde hızlıca hareket ettirerek kısa süre içinde birden fazla vurgu tetiklediğinizde görsel olarak gecikiyordu.

Bu sorunu düzeltmek için kullanıcı arayüzümüzü iki ekran dışı tuvale ayırdık: parçaların oluşturulduğu "ana" tuval ve öne çıkan anların çizildiği "öne çıkan anlar" tuvali. Ardından, bu kanvasları ekranda kullanıcıya görünen tek bir kanvasa kopyalayarak oluştururuz. Kaynak olarak başka bir tuvali alabilen bir tuval bağlamında drawImage yöntemini kullanabiliriz.

Bu sayede, bir vurgu kaldırıldığında ana tuval yeniden çizilmez. Bunun yerine, ekrandaki tuvali temizleyip ana tuvali görünür tuvale kopyalayabiliriz. Bir tuvali kopyalamak ucuzdur, pahalı olan çizimdir. Bu nedenle, vurguları ayrı bir tuvale taşıyarak vurguları açıp kapatırken bu maliyeti önleriz.

Kapsamlı olarak test edilmiş iz ayrıştırma

Yeni bir özelliği sıfırdan oluşturmanın avantajlarından biri, daha önce yapılan teknik seçimleri değerlendirip iyileştirmeler yapabilmektir. İyileştirmek istediğimiz noktalardan biri, kodumuzu neredeyse tamamen farklı iki bölüme ayırmaktı:

İzleme dosyasını ayrıştırın ve gerekli verileri çıkarın. Bir dizi parçayı oluşturun.

Ayrıştırmayı (1. bölüm) kullanıcı arayüzü çalışmasından (2. bölüm) ayrı tutarak sağlam bir ayrıştırma sistemi oluşturmamızı sağladık. Her iz, farklı konularla ilgilenen bir dizi işleyici aracılığıyla çalıştırılır: LayoutShiftHandler, düzen kaymaları için ihtiyaç duyduğumuz tüm bilgileri hesaplar ve NetworkRequestsHandler yalnızca ağ isteklerini çekmekle ilgilenir. İzlemenin farklı bölümlerinden sorumlu farklı işleyicilerin bulunduğu bu açık ayrıştırma adımının da faydası oldu: İzleme ayrıştırması çok karmaşık olabilir ve her seferinde tek bir soruna odaklanabilmek yardımcı olur.

Ayrıca, Geliştirici Araçları'nda kayıt alıp bunları kaydederek ve ardından test paketimizin bir parçası olarak yükleyerek iz ayrıştırmamızı kapsamlı bir şekilde test edebildik. Bu, gerçek izlerle test yapabildiğimiz ve eski hale gelebilecek büyük miktarlarda sahte iz verisi oluşturmadığımız için harika 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 beklendiği gibi 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 onaylayabiliriz. Bu yaklaşım bizim için iyi çalışıyor ancak tuval üzerinde oluşturma söz konusu olduğunda başarısız oluyor. Tuvali inceleyip neyin çizildiğini belirlemenin bir yolu yok. Bu nedenle, önce oluşturma sonra sorgulama şeklindeki normal yaklaşımımız uygun değildir.

Test kapsamı oluşturmak için ekran görüntüsü testini kullandık. Her testte bir tuval oluşturulur, test etmek istediğimiz parça oluşturulur ve ardından tuval öğesinin ekran görüntüsü alınır. Bu ekran görüntüsü daha sonra kod tabanımızda saklanır ve gelecekteki test çalıştırmalarında saklanan 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şturma işlemini kasıtlı olarak değiştirdiğimiz ve testin güncellenmesi gerektiği durumlarda testi çalıştırmak ve ekran görüntüsü güncellemesini zorlamak için bir işaret de sunuyoruz.

Ekran görüntüsü testleri mükemmel değildir ve biraz kaba olabilir. Daha ayrıntılı onaylar 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 bu testleri aşırı kullandığımızı kabul ediyoruz. Bu durum, test paketimizin hızını önemli ölçüde düşürdü ve küçük, neredeyse alakasız kullanıcı arayüzü ince ayarlarının (ör. renklerdeki küçük değişiklikler veya öğeler arasına biraz kenar boşluğu ekleme) 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ı. Ekran görüntüsü kullanımımızı azaltarak yalnızca tuval tabanlı bileşenlerde kullanmaya başladık. Bu denge şu ana kadar bizim için iyi sonuçlar verdi.

Sonuç

Yeni performans analizleri panelini oluşturmak, ekip için çok keyifli ve eğitici bir deneyim oldu. İzleme dosyaları, tuvalle çalışma ve daha birçok konu hakkında bilgi edindik. Yeni paneli kullanmaktan keyif alacağınızı umuyor ve geri bildirimlerinizi bekliyoruz.

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

Önizleme kanallarını indirme

Varsayılan geliştirme tarayıcınız olarak Chrome Canary, Dev veya Beta'yı kullanmayı düşünebilirsiniz. Bu önizleme kanalları, en yeni DevTools özelliklerine erişmenizi sağlar, en yeni web platformu API'lerini test etmenize olanak tanır ve kullanıcılarınızdan önce sitenizdeki sorunları 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 diğer konuları tartışmak için aşağıdaki seçenekleri kullanın.