Chrome 102'de Geliştirici Araçlarınızda yeni bir deneme paneli olan Performans Analizleri'ni fark edeceksiniz. 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.
Neden başka bir panel oluşturmalısınız?
(Daha önce izlemediyseniz Performans Analizleri panelini neden oluşturduğunuza ve bu paneli kullanarak web sitenizin performansı hakkında harekete geçirici analizlere nasıl ulaşabileceğinizle ilgili bir video paylaşmıştı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 de düşündük. Performans uzmanı değilseniz tam olarak neyi arayacağınızı ve kaydın hangi bölümlerinin alakalı olduğunu bilmek zordur.
İzlemenizin zaman çizelgesini görüntülemeye ve verileri incelemeye devam edebileceğiniz Analizler Paneli'ne girin. Bununla birlikte, Geliştirici Araçları'nın araştırmaya değer olarak kabul ettiği ana "Analizler"in listesini de görebilirsiniz. Analizler sayfası oluşturma engelleme istekleri, düzen kaymaları ve uzun görevler gibi sorunları tespit eder. Bunların tümü web sitenizin sayfa yükleme performansını, özellikle de sitenizin Önemli Web Verileri (CWV) puanlarını olumsuz etkileyebilir. Performans Analizleri, sorunları işaretlemenin yanı sıra CWV puanlarınızı artırmak için uygulayabileceğiniz öneriler ve daha fazla kaynak ile belge bağlantısı sunar.
Bu panel deneme amaçlıdır. Geri bildirimlerinizi bizimle paylaşmanızı rica ediyoruz. Herhangi bir hatayla karşılaşırsanız veya sitenizin performansı üzerinde çalışırken size yardımcı olacağını düşündüğünüz özellik istekleriyle karşılaşırsanız lütfen bize bildirin.
Performans analizlerini nasıl oluşturduk?
Geliştirici Araçları'nın geri kalanı gibi biz de TypeScript'te Performans Analizleri'ni oluşturduk ve kullanıcı arayüzünü oluşturmak için lit-html ile desteklenen web bileşenlerini kullandık. Performans Analizleri, birincil kullanıcı arayüzü arayüzünün HTML canvas öğesi olması ve zaman çizelgesinin bu zemine çizilmesidir. Bu tuvalin yönetimi, karmaşıklığın önemli bir kısmını oluşturur: Yalnızca doğru ayrıntıları doğru yerde çizmekle kalmayıp fare etkinliklerini yönetme (örneğin, kullanıcı kanvası nerede tıkladı? Çizdiğimiz bir etkinliği tıkladılar mı?) ve kanvası etkili bir şekilde yeniden oluşturmamızı sağladılar.
Tek bir zeminde birden fazla parça
Belirli bir web sitesi için, her biri farklı bir veri kategorisini temsil eden birden çok "parça" oluşturmak isteriz. Örneğin, Analizler panelinde varsayılan olarak üç kanal gösterilir:
Panele özellikler eklemeye devam ederken daha fazla parçanın eklenmesini bekliyoruz.
İlk düşüncemiz, bu parçaların her birinin kendi <canvas> parçasını oluşturmasıydı. Böylece ana görünüm dikey olarak yığılmış birden fazla tuval öğesi haline gelecekti. Bu, kanal düzeyinde oluşturmayı basitleştirir. Çünkü her kanal yalıtılmış olarak oluşturulabilir ve bir kanalın sınırları dışında oluşturulması tehlikesi yoktur. Ancak ne yazık ki bu yaklaşımda iki önemli sorun vardır:
canvas öğelerinin yeniden oluşturulması pahalıdır. Birden fazla tuvale sahip olmak, tuval daha büyük olsa bile tek bir tuvalden daha pahalıdır.
Birden çok parçadan geçen bindirmelerin (örneğin, FCP zamanı gibi etkinlikleri işaretlemek için dikey çizgiler) oluşturulması karmaşık hale gelir. Birden çok tuval üzerinde oluşturmamız, hepsinin birlikte oluşturulmasını ve düzgün bir şekilde hizalanmasını sağlamamız gerekir.
Kullanıcı arayüzünün tamamı için bir canvas kullanmak, her bir kanalın doğru koordinatlarda oluşturulduğundan ve başka bir kanala taşmamasını nasıl sağlayacağımızı öğrenmemiz gerekti. Örneğin, belirli bir parçanın yüksekliği 100 pikselse 120 piksel yüksekliğinde bir parçanın oluşturulmasına ve altındaki parçaya taşmasına izin veremeyiz. Bu sorunu çözmek için clip adresini kullanabiliriz. Her bir parkuru oluşturmadan önce, görünür izleme penceresini temsil eden bir dikdörtgen çizeriz. Bu, bu sınırların dışında çizilen yolların kanvas tarafından kırpılmasını sağlar.
canvasContext.beginPath();
canvasContext.rect(
trackVisibleWindow.x, trackVisibleWindow.y, trackVisibleWindow.width, trackVisibleWindow.height);
canvasContext.clip();
Ayrıca, her parçanın dikey olarak konumunu bilmek zorunda olmasını istemiyorduk: Her parça (0, 0) sanki oluşturuluyormuş gibi oluşturulmalı ve genel parça konumunu yönetmek için daha üst düzey bir bileşenimiz (TrackManager olarak adlandırıyoruz) olmalıdır. Bunu, kanvası 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, konum olarak 0, 0 ayarına rağmen, uygulanan genel çeviri dikdörtgenin 0, 10 konumunda oluşturulmasına neden olacaktır. Bu, (0, 0) değerinde oluşturma yapıyormuş gibi tek başına çalışma yapmamızı ve her parçanın bir öncekinin altında doğru şekilde oluşturulmasını sağlamak için parça yöneticimizin her parçayı çevirirken çevirmesini sağlamamızı sağlar.
Parçalar ve öne çıkanlar için ekran dışı tuvaller
Tuval oluşturma nispeten pahalıdır. Bu nedenle, Analizler panelinin siz üzerinde çalışırken düzgün ve duyarlı kalmasını sağlamak istiyoruz. Bazen tuvalin tamamını yeniden oluşturmaktan kaçınamazsınız: Örneğin, yakınlaştırma düzeyini değiştirirseniz tekrar başlayıp her şeyi yeniden oluşturmamız gerekir. Tuvalin yeniden oluşturulması özellikle pahalıdır, çünkü tuvalin küçük bir bölümünü yeniden oluşturmak mümkün değildir, tuvalin tamamını silip yeniden çizmeniz gerekir. Bu, araçların gereken minimum düzeyde işi hesaplayıp her şeyi kaldırıp baştan başlamadığı DOM yeniden oluşturma işleminden farklıdır.
Görsel sorunlarla karşılaştığımız bir alan vurgulanıyordu. Bölmedeki metriklerin üzerine geldiğinizde bunları zaman çizelgesinde vurgularız ve aynı şekilde, belirli bir etkinlik için bir Analiz'in üzerine geldiğinizde bu etkinliğin etrafına mavi bir kenarlık çizeriz.
Bu özellik ilk olarak, vurguyu tetikleyen bir öğe üzerinde fare hareketi algılanıp ardından bu vurguyu doğrudan ana tuval üzerine çizerek uygulanmaktadır. Sorunumuz, vurguyu kaldırmamız gerektiğinde ortaya çıkıyor: Tek seçenek her şeyi yeniden çizmek. Sadece vurgunun bulunduğu alanı (büyük mimari değişiklikler olmadan değil) yeniden çizmek, sırf bir öğenin etrafındaki mavi kenarlığı fazla abartmış gibi hissettiğimiz için tüm tuvali yeniden çizmek imkansızdır. Birden çok vurgulamanın hızlı bir şekilde tetiklenmesi için farenizi farklı öğelerin üzerine hızlıca kaydırdığınızda da görsel olarak gecikme yaşanmıştır.
Bunu düzeltmek için kullanıcı arayüzümüzü iki ekran dışı tuvale böldük: parçaların oluşturulduğu "ana" tuval ve vurgulamaların çizildiği "öne çıkanlar" tuval. Ardından bu tuvalleri, ekranda kullanıcının görebildiği tek bir tuvale kopyalayarak oluşturuyoruz. Bir kanvas bağlamında drawImage yöntemini kullanabiliriz. Bu yöntem, kaynak olarak başka bir kanvası alabilir.
Bu işlem, vurguyu kaldırdığınızda ana tuvalin yeniden çizilmesine neden olmaz. Bunun yerine, ekrandaki tuvali temizleyip ana tuvali görünür tuvale kopyalayabiliriz. Bir tuvali kopyalama işlemi ucuz olduğu için çizimdir ve pahalıdır. Bu nedenle, vurguları ayrı bir kanvasa taşıyarak vurguları açıp kapadığında bu maliyetten kaçınmış oluruz.
Kapsamlı bir şekilde test edilmiş iz ayrıştırma
Sıfırdan yeni bir özellik oluşturmanın avantajlarından biri, daha önce yaptığınız teknik seçimler üzerine düşünüp iyileştirmeler yapabilmenizdir. Geliştirmek istediğimiz yönlerden biri, kodumuzu açıkça iki, neredeyse tamamen farklı bölüme bölmekti:
İzleme dosyasını ayrıştırın ve gerekli verileri çekin. Parça grubu oluşturun.
Ayrıştırmayı (1. bölüm) kullanıcı arayüzü çalışmalarından ayrı tutmak (2. bölüm), sağlam bir ayrıştırma sistemi oluşturmamızı sağladı. Her iz, farklı endişelerden sorumlu bir dizi İşleyici üzerinden çalıştırılır: LayoutShiftHandler, Layout Shift'ler için ihtiyacımız olan tüm bilgileri hesaplar, NetworkRequestsHandler ise yalnızca ağ isteklerini çeker. İzin farklı bölümlerinden sorumlu farklı işleyicilerimizin bulunduğu bu açık ayrıştırma adımının olması da faydalı oldu: İz ayrıştırma çok karmaşık olabilir ve tek seferde tek bir soruna odaklanabilmenize yardımcı olur.
Ayrıca, Geliştirici Araçları'nda kayıtları alıp kaydederek ve test paketimiz kapsamında yükleyerek iz ayrıştırma işlemimizi kapsamlı bir şekilde test edebildik. Gerçek izlerle testler yapabildiğimiz ve geçerliliğini yitirebilecek büyük miktarlarda sahte iz verisi biriktiremeyeceğimiz için bu harika bir özelliktir.
Tuval kullanıcı arayüzü için ekran görüntüsü testi
Test konusuna bağlı kalarak genellikle ön uç bileşenlerimizi tarayıcıda oluşturup beklendiği gibi davrandıklarından emin olarak test ederiz. Güncellemeleri tetiklemek için tıklama etkinliklerini dağıtabilir ve bileşenlerin oluşturduğu DOM'un doğru olduğunu onaylayabiliriz. Bu yaklaşım bizim çok işimize yarıyor ancak tuvale oluşturma seçeneğini değerlendirdiğimizde işe yaramıyor. Bir tuvali incelemek ve orada neyin çizildiğini belirlemek mümkün değildir. Bu nedenle, oluşturma ve sorgulama yaklaşımımız uygun değildir.
Test kapsamını kullanabilmek için ekran görüntüsü özelliğini kullandık. Her test bir kanvas başlatır, test etmek istediğimiz parçayı oluşturur ve ardından tuval öğesinin ekran görüntüsünü alır. Bu ekran görüntüsü daha sonra kod tabanımızda saklanır. Gelecekteki 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ı bilinçli olarak değiştirdiğimizde ve testin güncellenmesi gerektiğinde testi çalıştırmak ve ekran görüntüsü güncellemesi yapılmasını sağlamak için bir işaret de sağlarız.
Ekran görüntüsü testleri mükemmel değildir ve biraz belirgindir. Yalnızca bileşenin belirli birtakım iddialar yerine beklendiği gibi oluşturulduğunu test edebilirsiniz. Başlangıçta her bileşenin (HTML veya tuval) doğru şekilde oluşturulmasını sağlamak için bunları aşırı kullanmaktan suçluyduk. Bu durum, test paketimizi önemli ölçüde yavaşlattı ve çok küçük, neredeyse alakasız kullanıcı arayüzü değişikliklerinin (ör. göze çarpmayan renk değişiklikleri 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üncellenmesini gerektirdiğine yol açtı. Şimdi ekran görüntüsü kullanımımızı azalttık ve bunları yalnızca tuvale dayalı bileşenler için kullanıyoruz. Bu denge şimdiye kadar iyi iş çıkardı.
Sonuç
Yeni Performans Analizleri panelini oluşturmak ekip için çok keyifli bir eğitim deneyimi sağladı. İzleme dosyaları, tuval üzerinde çalışma ve çok daha fazlası hakkında çok şey öğrendik. Yeni paneli keyifle kullanacağınızı umuyoruz 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 edinme 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'yı kullanmayı düşünün. Bu önizleme kanallarıyla Geliştirici Araçları'nın en yeni özelliklerine erişebilir, son teknoloji ürünü web platformu API'lerini test edebilir ve sitenizdeki sorunları kullanıcılarınızdan önce tespit edebilirsiniz!
Chrome Geliştirici Araçları ekibiyle iletişim kurma
Yayındaki yeni özellikler ve değişiklikler ya da Geliştirici Araçları ile ilgili diğer konular hakkında konuşmak için aşağıdaki seçenekleri kullanın.
- crbug.com adresinden öneri veya geri bildirim gönderin.
- Geliştirici Araçları'nda, Diğer seçenekler
> Yardım > Geliştirici Araçları sorunu bildir'i kullanarak Geliştirici Araçları sorunlarını bildirin. - @ChromeDevTools adresine tweet gönderin.
- Geliştirici Araçları'ndaki YouTube videoları veya Geliştirici Araçları İpuçları YouTube videolarındaki yenilikler hakkındaki görüşlerinizi bizimle paylaşın.