Chrome Dev Insider: Performansı çerçeve ekosistemiyle ölçeklendirme

Paul Kinlan

Ben Paul Kinlan. Chrome'da geliştirici ilişkilerinden sorumluyum. İşim kapsamında, gerçek dünyadaki geliştiricilerin bakış açısını ürün ve mühendislik ekiplerimize aktarmakla görevli, tutkulu bir web savunucuları ekibiyle çalışıyorum. Bu ekibin ana hedefi, geliştirici memnuniyetini artırmak.

"Memnuniyetin" takip edilmesi ve iyileştirilmesi gereken iddialı ve öznel bir metrik olduğunun farkındayız. Bu nedenle, geliştirici ihtiyaçlarına odaklanırken nasıl etki yaratabileceğimiz konusunda sürekli olarak iterasyon yapıyoruz. "Geliştiricilerle bulundukları yerde buluşun", faydalı bulduğumuz yol gösterici ilkelerden biridir. Yakın zamanda yapılan bir Stack Overflow araştırması, geliştiricilerin% 75'inin çerçeve kullandığını veya bir tür soyutlama kullandığını gösteriyor. Bu nedenle, teknoloji yığınları hakkında karar vermiş veya bu yığınlar üzerinde hiçbir kontrole sahip olmayan geliştiricilere en iyi şekilde nasıl hizmet verebileceğimizi kendimize soruyoruz. Daha fazla maliyet eklemeden onları nasıl daha üretken hale getirebiliriz?

Chrome'daki küçük bir ekip, web platformunun üçüncü taraf soyutlamalarıyla (ör. çerçeveler ve kitaplıklar) çalışmak amacıyla Aurora adlı bir proje üzerinde çalışıyor. Amacımız, yükü müşterilerine (web geliştiricileri) yüklemek yerine performans kazançlarını doğrudan bu soyutlamalara dahil etmelerine yardımcı olmaktır.

Chrome Dev Insider'ın üçüncü sayısı için Project Aurora ekibinden Addy Osmani, Kara Erickson ve Houssein Djirdeh ile görüşerek bu projeye nasıl yaklaştıkları ve gelecekte neler planladıkları hakkında daha fazla bilgi edindim.

İçeriden bilgi: Üçüncü taraf çerçeveleriyle çalışma

Bu projenin başlangıcından başlayalım. Bu nasıl oldu?

Addy: Aurora, geliştiricilerle bulundukları noktada buluşup ulaşmak istedikleri yere ulaşmalarına yardımcı olma fikriyle başladı. Örneğin, performansı artırmak için seçtikleri popüler teknoloji grubuna yardımcı oluyoruz. Birçok uygulama geliştirici günümüzde React, Vue veya Angular'ı ya da Next.js ve Nuxt gibi meta çerçeveleri* kullanıyor (ve tabii ki daha birçok araç var... Svelte, Lit, Preact, Astro. Liste bu şekilde uzayıp gidiyor. Bu geliştiricilerin derin uzmanlar (ör. performans konusunda) olmasını beklemek yerine, bu gruplara varsayılan olarak daha fazla en iyi uygulama ekleyerek başarının zirvesine çıkmalarını sağlayabiliriz. Bu sayede, web için site oluşturmanın yan etkisi olarak daha kaliteli siteler elde edebilirsiniz.

Aurora, birlikte çalışacağı birkaç yaygın çerçeve ve meta çerçeve seçer. Diğerlerinin hızlıca takip edip Chrome Frameworks Fund aracılığıyla diğer çerçeveler ve araçlar üzerinden ölçeklendirmeye çalışabilmesi için öğrendiklerimizi (ör. iyi bir resim bileşeni oluşturma) belgeleriz. Web deneyimlerinin kalitesini tarayıcı üzerinden iyileştirmek mümkün olsa da bu hedefin (bazı durumlarda) çerçeveler aracılığıyla da gerçekleştirilebileceğine inanıyoruz. Bu değişikliğin, herkes için daha yüksek kaliteli bir web sitesi oluşturma hedeflerimize ulaşmamıza yardımcı olacağını umuyoruz.

Kara: Bunu daha ayrıntılı olarak açıklamak gerekirse, geliştirici deneyimini iyileştirerek web'deki performansı iyileştirmeyi amaçlıyoruz. Performansla ilgili en iyi uygulamaların sık sık değişmesi ve şirketlerin bu uygulamalara ayak uydurmasının zor olması nedeniyle, bu uygulamaların tanıtılması yeterli değildir. Muhtemelen performanstan önce gelecek kendi işletme öncelikleri vardır.

Bu nedenle, geliştiricilerin performansa ayıracak sınırlı zamanı varsa performanslı bir uygulama oluşturmalarını kolaylaştıralım (ve hızlandıralım). Popüler web çerçeveleriyle iş ortaklığı yaparsak daha üst düzey bileşenler, uygunluk uyarıları vb. aracılığıyla geliştirici deneyimini iyileştirmek için doğru soyutlama katmanında oluruz. Bu popüler araçları kullanan herkes bu avantajlardan yararlanabilir. Teorik olarak, önerilen tavsiye değişirse bileşenlerimizi arka planda güncelleyebiliriz. Böylece geliştiricilerin güncel kalmak için endişelenmesi gerekmez.

Houssein: Google'a Geliştirici Destek Ekibi üyesi olarak katıldım ve birkaç yıl sonra yazılım mühendisliği rolüne geçtim. Önceki çalışmalarımın büyük bir kısmı, web geliştiricilerine harika kullanıcı deneyimleri oluşturmanın birçok farklı yolunu öğretmeyi içeriyordu. Geliştiricileri, sitelerinin performansını ve kullanılabilirliğini büyük olasılıkla etkileyecek yaygın sorunlar konusunda uyarmak için aynı bilgilerin farklı versiyonları defalarca sağlandı. Aurora projesini düşünmeye başladığımızda kendimize şu soruyu sorduk: Geliştiricilere ne yapmaları gerektiğini asla söylememiz gerekmeyecek bir yöne gidebilir miyiz? Çünkü araç zincirleri her şeyi onlar için hallediyor.

Doğru anladıysam ekibiniz altı mühendisten mi oluşuyor? Herhangi bir çerçeve veya kitaplıkla çalışamayacağınızı düşünüyorum. Peki, birlikte çalışacağınız kişiyi nasıl seçersiniz? Kimler?

Addy: Web'in birçok yönü Vahşi Batı'ya benziyor. İstediğiniz çerçeveyi, paketleyiciyi, kitaplıkları ve üçüncü tarafları seçebilirsiniz. Bu, iyi veya kötü performansa katkıda bulunabilecek çeşitli karmaşıklık katmanları sunar. Performansta ilerleme kaydetmenin en iyi yollarından biri, fikir beyan etmekten çekinmeyen ve daha fazla fikir ekleyen katmanları bulmaktır.

Örneğin, web çerçeveleri (Next.js, Nuxt.js ve bir dereceye kadar Angular), daha fazla fikir ve varsayılan ayar sunmaya çalışır. Bu, onlarla çalışmayı sevmemizin nedenlerinden biri. Daha iyi Core Web Vitals için resimlerin, yazı tiplerinin ve komut dosyalarının nasıl yükleneceğiyle ilgili daha güçlü varsayılan değerlere sahip olmak bu modellerde mantıklıdır.

Ayrıca, modern en iyi uygulamaların nerede işe yaradığını veya yeniden düşünülmesi gerekebileceğini doğrulamak için iyi bir yöntemdir ve optimizasyon sorunlarının nasıl çözüleceğine dair tüm ekosistemi bilgilendirmeye yardımcı olabilir.

Kara: Gerçekçi olmak gerekirse popülerliği de göz önünde bulundurmamız gerekir. Web'de mümkün olan en büyük etkiyi yaratmak istiyorsak mevcutta büyük bir geliştirici topluluğuna sahip çerçeveler ve kitaplıklarla çalışmak idealdir. Bu sayede daha fazla geliştiriciye ve uygulamaya ulaşabiliriz. Ancak bu, yalnızca popülerlik olamaz. Sonuçta, popülerlik, bir kitaplığın ne kadar iddialı olduğu ve kullanabileceğimiz mevcut özellik grubunun kesişim noktasıdır.

Örneğin, yalnızca popülerliğe bakarsak React, Vue ve Angular dikkate alınması gereken "üç büyük"tür. Ancak en çok Next.js, Nuxt ve Angular ile çalışıyoruz. Bunun nedeni, React ve Vue gibi görüntüleme kitaplıklarının çoğunlukla oluşturmaya odaklanmasıdır. Bu nedenle, istediğimiz tüm özellikleri doğrudan bunlara dahil etmek imkansızdır. Bu nedenle, bunların üzerine inşa edilmiş Next.js ve Nuxt gibi meta çerçevelerle daha yakından çalışıyoruz. Bu soyutlama düzeyinde yerleşik bileşenler oluşturabiliriz. Ayrıca yerleşik sunucuları olduğundan sunucu tarafı optimizasyonları da dahil edebiliriz.

Angular'ın bu derin iş ortakları listesinde yer aldığını fark edebilirsiniz ancak Angular bir meta çerçeve değildir. Angular, oldukça popüler olmasına rağmen React ve Vue gibi tamamlayıcı bir meta çerçeveye sahip olmadığı için özel bir durumdur. Bu nedenle, doğrudan onlarla çalışır ve mümkün olduğunda CLI'leri aracılığıyla özellikler sunarız.

Gatsby gibi diğer projelerle devam eden ilişkilerimiz olduğunu da belirtmek isteriz. Bu projelerde tasarım konusunda düzenli olarak senkronize oluruz ancak aktif olarak kod katkısında bulunmayız.

Peki bu, pratikte nasıl gerçekleşiyor? Bu sorunu çözme yaklaşımınız neydi?

Kara: Uygulamada, yakın iş birliği yaptığımız birkaç çerçevemiz var. Bu çerçeveyi kullanarak uygulamaların profilini oluşturmak ve yaygın performans sorunlarını belirlemek için biraz zaman ayıracağız. Ardından, bu sorun noktalarını çözmek için deneysel özellikler tasarlamak üzere çerçeve ekibiyle birlikte çalışır ve bunları uygulamak için doğrudan açık kaynak depoya kod katkısında bulunuruz.

Performans etkisinin tahmin ettiğimiz gibi olduğunu doğrulamak bizim için çok önemlidir. Bu nedenle, üretimde performans testi yapmak için harici şirketlerle de birlikte çalışırız. Sonuçlar cesaret vericiyse özelliğin "kararlı" hale gelmesine yardımcı olur ve muhtemelen varsayılan olarak etkinleştiririz.

Bütün bunlar sizin anlattığınız kadar kolay olamaz. Şimdiye kadar karşılaştığınız zorluklar veya edindiğiniz bilgilerden bazıları nelerdi?

Houssein: Elimizden geldiğince önem verdiğimiz konulardan biri, birçok farklı önceliği olan popüler açık kaynak depolarına katkıda bulunmaktır. Google ekibi olmamız, özelliklerimize öncelik verileceği anlamına gelmez. Bu nedenle, kimsenin hakkını yemeden yeni özellikler önerme ve yayınlama sürecine uymak için elimizden geleni yapıyoruz. Next.js, Nuxt ve Angular ekosistemlerindeki duyarlı koruyucularla çalışmaktan çok memnunuz. Web ekosistemiyle ilgili endişelerimizi dinlediler ve bizimle birden fazla şekilde işbirliği yapmaya hazır olduklarını gösterdiler.

Çalıştığımız birçok çerçevede genel misyonumuz aynıdır: Geliştiriciler, hem harika bir geliştirici deneyiminin keyfini çıkarırken hem de kutudan çıkar çıkmaz iyileştirilmiş bir kullanıcı deneyimi elde edebilir mi? Her biri birbirini kesiştiren farklı projelerde çalışan yüzlerce, hatta binlerce topluluk katılımcısı ve çerçeveyi koruyan kişi olduğunun farkındayız ve onlara saygı duyuyoruz.

Kara: Ayrıca, performans üzerindeki etkiyi doğrulamayı ve verilere dayalı hareket etmeyi önemsediğimiz için süreç biraz daha zaman alıyor. Henüz keşfedilmemiş bir alandayız. Bu nedenle, bazen işe yaramayan bir optimizasyon deneyebilir ve planladığımız özelliği oluşturamayabiliriz. Bir özellik başarılı olsa bile performansı incelemek için gereken birkaç ek adım zaman alır ve zaman çizelgelerini uzatır.

Özelliklerimizi test edecek prodüksiyon iş ortakları bulmak da zor olabilir. Daha önce de belirtildiği gibi, bu iş ortakları kendi önceliklerine sahip işletmelerdir. Bu nedenle, öncelikli olarak ele alınması gereken mevcut projelerle uyumlu değilse yeni girişimleri uygulamak onlar için zor olabilir. Ayrıca, yardım almak isteyen şirketler zaten performansa yatırım yapmak için zaman ayırma eğiliminde olduğundan, hedef kitlemiz bunlar değil. Performansa yatırım yapamayan ancak bize ulaşma olasılığı en düşük olan topluluk üyelerinden geri bildirim toplamaya çalışıyoruz.

Sıradaki sorum şu: Ne tür optimizasyonlara odaklanıyorsunuz?

Houssein: Binlerce uygulamayı analiz ettikten sonra, en büyük performans sorunlarının genellikle çerçevenin kendisinden ziyade uygulama kodundaki anti-pattern'lerden kaynaklandığını tespit ettik. Örneğin, gereksiz yere büyük resimler gönderme, özel yazı tiplerini çok geç yükleme, ana iş parçacığını engelleyen çok fazla üçüncü taraf isteği getirme ve asenkron içeriğin sayfadaki diğer öğelerin kaymasına neden olabileceği durumların ele alınmaması. Bunların tümü, kullandığınız araçtan bağımsız olarak ortaya çıkabilecek sorunlardır. Bu nedenle, bu sorunları iyi bir şekilde ele alan ancak çerçeve araçlarına iyi uyan temiz bir geliştirici deneyimi sunan bazı varsayılan optimizasyonlar ekleyebilir miyiz diye düşündük.

Bu düşünceyle, şu özellikleri kullanıma sunduk:

Çalışmalarımız, diğer çerçevelerin ve araçların benzer optimizasyonlar uygulamasına ilham verdi. İhlaller aşağıdakileri kapsar ancak bunlarla sınırlı değildir:

Bu oyunculardan bazılarıyla yaptığınız çalışmaların olumlu sonuçlarından bahseder misiniz?

Houssein: Gönderdiğimiz optimizasyonlar sayesinde birçok site performans açısından iyileştirme elde etti. En sevdiğim örneklerden biri, Next.js resim bileşenine geçtikten sonra LCP'sini 2,4 saniyeden 1,7 saniyeye düşüren Leboncoin. Şu anda deneme ve test aşamalarında olan daha birçok özellik var. Bu özelliklerden edindiğimiz bilgileri ve kazançları burada paylaşmaya devam edeceğiz.

Anladım. En popüler olanlara odaklandığınızı belirtmişsiniz. Ancak proaktif olarak çalışmadığınız diğer çerçevelerin veya kitaplıkların da bu durumdan yararlanması için bir yol var mı?

Addy: Aurora'nın birlikte çalıştığı performans optimizasyonlarının çoğu herhangi bir çerçeve tarafından kopyalanabilir. Örneğin, resim veya komut dosyası bileşeni çalışmalarımızın arkasındaki mantığı inceleyin. Bu çalışmalar genellikle mevcut bir en iyi uygulama grubunu kodlar. Bu tür bileşenlerin nasıl oluşturulacağını ve her bir çerçevede nasıl göründüğünü belgelemeye çalışıyoruz. Bu fikirleri kopyalamak için iyi bir başlangıç olduğunu umuyoruz.

Bir ekosistemden (ör. React ve Next.js) edinilen bilgileri başka ekosistemlere aktararak iyi sonuçlar elde ettik. Örneğin, yeni Angular Image Directive (Next.js Image Component'i oluştururken edindiğimiz bilgilerle geliştirildi) veya Gatsby'nin ayrıntılı JavaScript parçalara ayırma yaklaşımımızı kullanıma sunması.

Aynı zamanda, her çerçevenin, katkıda bulunanların benzer performans özellikleri oluşturması veya kullanıcıları için önemli olduğuna inandıkları diğer optimizasyonlara yatırım yapması için gerekli bant genişliğine veya finansmana sahip olmayacağının farkındayız. Chrome Web Framework'leri Fonu, projelerin katkıda bulunanlara ödeme yapmasına ve performans çalışmalarının ekosistemde daha da ölçeklendirilmesine olanak tanımak için JavaScript ekosistemindeki performans çalışmalarına sponsor olmamızı sağlar.

Ekibinizin yol haritasında neler var?

Kara: Yakında heyecan verici birçok projeyi kullanıma sunacağız. Bazı önemli noktalar:

  • Yazı tipiyle ilgili CLS'yi azaltma: Bir web yazı tipi yüklendiğinde ve yedek yazı tipinin yerini aldığında düzen kaymalarını görmek oldukça yaygındır. Next.js'de yazı tipiyle ilgili CLS'yi varsayılan olarak azaltmak için yazı tipi metriği geçersiz kılma işlemlerini ve "size-adjust" mülkünü kullanmayı araştırıyoruz. Bu konuda Nuxt ekibine de danışıyoruz ve bu fikri önümüzdeki yıl daha fazla çerçeveye yaymayı planlıyoruz.
  • INP'de hata ayıklama: Interaction to Next Paint (INP) metriği kullanıma sunulduğundan, INP sorunlarının topluluklarındaki en yaygın temel nedenlerini araştırmak ve düzeltme önerileri sunmak için çerçevelerle birlikte çalışıyoruz. Bu konuda Angular ile yakın bir iş ortaklığı yapıyoruz ve yakında bazı sonuçları paylaşmayı umuyoruz.
  • Yaygın üçüncü taraf komut dosyalarını optimize etme: Üçüncü taraf komut dosyalarının yanlış zamanda yüklenmesi, performansı önemli ölçüde olumsuz etkileyebilir. Çok yaygın olan birkaç üçüncü taraf olduğundan, bunların çerçevelerle optimum şekilde yüklenmesini ve ana iş parçasını engellememesini sağlamak için bunlara yönelik bazı sarmalayıcılar sunup sunamayacağımızı araştırıyoruz. Bu inceleme için başlangıç noktası olarak oluşturduğumuz Next.js komut dosyası bileşenini kullanıyoruz.

Geliştiriciler, ilerleme durumumuzu bu sitede takip edebilir.

Haberlerde

Sohbeti sonlandırmadan önce, Google'da çerçeve dünyasında gerçekleşen birkaç ilgi çekici güncellemeyi sizinle paylaşmak istedim.

Temmuz ayında Chrome Ekibi, web'deki performansı, kullanıcı deneyimini ve geliştirici deneyimini iyileştirmeyi amaçlayan projeleri desteklemeye odaklanan Çerçeveler ve araçlar fonu için 500.000 ABD doları tutarında son finansman turunu duyurdu. Gelecekteki fonlamada yeni projeler dikkate alınacağından isteğinizi göndermeyi unutmayın.

Elbette, topluluğumuzda da bir sürü harika şey oluyor. Ekosistem, Deno'nun Fresh gibi yeni çerçevelerle ve Svelte'nin yalnızca tarayıcı içi bir demo değil, aynı zamanda Node.js'i tarayıcıda yerel olarak çalıştırmak için Web Container API'yi kullanan ilk katılım eğitimi gibi harika deneyimlerle doludur. Çok güzel şeyler var.

Ekosistemin bir araya gelip tarayıcıda neler yapılabileceğini zorladığını ve geliştiricilerin herkes için işe yarayan ürünler oluşturmasına yardımcı olduğunu görmek beni gerçekten heyecanlandırıyor. Web geliştirici olmak için heyecan verici bir dönemdeyiz.

Bir sonraki Insider'a kadar, Hwyl fawr.

Chrome Dev Insider'ın bu sayısı hakkında ne düşünüyorsunuz? Geri bildiriminizi paylaşın.