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

Paul Kinlan

Ben Paul Kinlan. Chrome'un geliştirici ilişkilerinden sorumluyum. İşim kapsamında, geliştirici memnuniyetini artırmak için kuzey yıldızı metriğiyle gerçek dünyadaki geliştiricilerin bakış açısını ürün ve mühendislik ekiplerimize taşımakla görevli tutkulu web savunucularından oluşan bir ekiple birlikte çalışıyorum.

"Memnuniyet"in izlenecek ve iyileştirilebilecek iddialı ve öznel bir metrik olduğunun farkındayız. Bu nedenle, geliştirici ihtiyaçlarına odaklanırken bir yandan da etki yaratmak için sürekli olarak tekrarlardan yararlanırız. "Geliştiricilerle bulundukları yerde buluşmak" adlı bir ilke benimsiyor. Kısa süre önce yapılan bir Stack Overflow araştırmasına göre geliştiricilerin% 75'i, çerçeveler veya bir tür soyutlama kullandığını bildiriyor. Bu nedenle kendimize, teknoloji yığınları hakkında zaten karar vermiş veya üzerinde kontrolü olmayan geliştiricilere en iyi nasıl hizmet verdiğimizi soruyoruz. Daha fazla ek yük oluşturmadan nasıl daha verimli hale getirebiliriz?

Chrome'da küçük bir ekip, web platformunun çerçeveler ve kitaplıklar gibi üçüncü taraf soyutlamalarıyla çalışma hedefiyle Aurora adlı bir proje üzerinde çalışıyor. Amaçları, yükü müşterilerinin, yani web geliştiricilerinin üstünde tutmak yerine performans kazançlarını doğrudan bu soyutlamalara getirmeye yardımcı olmak.

Chrome Dev Insider'ın üçüncü sayısında, Project Aurora Ekibi'nden Addy Osmani, Kara Erickson ve Houssein Djirdeh ile konuşarak bu projeye nasıl yaklaştığını ve onları nelerin beklediğini öğrenin.

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

Bu projenin doğuşuyla başlayalım. Nasıl ortaya çıktı?

Addy: Aurora basit bir fikirle işe koyuldu: Geliştiricilerle bulundukları yerde buluşalım ve gitmeleri gereken yere gitmelerine yardımcı olalım. Örneğin, performansı artırmak için seçtikleri popüler teknoloji yığınına yardım edin. Birçok uygulama geliştirici bugünlerde React, Vue veya Angular kullanarak ya da Next.js ve Nuxt gibi meta çerçeveleri* kullanarak (ve tabii ki daha birçok uygulama geliştiriyor) İnce, Küçük, Preact, Astr. Liste bu şekilde uzayıp gidiyor!). Bu geliştiricilerin profesyoneller olmasını (örneğin, performans) beklemek yerine, varsayılan olarak bu gruplarda daha fazla en iyi uygulamayı kullanarak başarı çukuruna sokmalarını sağlayabiliriz. Bu şekilde, daha kaliteli siteler yalnızca web için geliştirmenin yan etkisi olarak ortaya çıkar.

Aurora, iş ortaklığı kurmak için yaygın olarak kullanılan birkaç çerçeve ve meta çerçeve seçiyor. Edindiğimiz bilgileri (iyi bir resim bileşeninin nasıl oluşturulacağı gibi) kaydediyoruz. Böylece diğer kullanıcılar, Chrome Frameworks Fonu aracılığıyla diğer çerçeveler ve araçlar aracılığıyla hızlıca takip edip ölçeklendirme yapmaya çalışıyor. Web deneyimlerinin kalitesini tarayıcı aracılığıyla iyileştirmek mümkün olsa da, bu hedefin de (bazı durumlarda) çerçeveler aracılığıyla gerçekleştirilebileceğine inanıyoruz. Bu yeniliğin, herkes için daha kaliteli web hedeflerimize ulaşmamıza yardımcı olacağını umuyoruz.

Kara: Konuyu daha ayrıntılı anlatmak gerekirse, geliştirici deneyimini iyileştirerek web'deki performansı iyileştirmekten bahsedelim. Performansla ilgili en iyi uygulamaları duyurmak yeterli değildir. Çünkü uygulamalar sık sık değişir ve şirketlerin bu uygulamalara ayak uydurması zordur. Muhtemelen performanstan önce ortaya çıkacak kendi iş öncelikleri vardır.

Bu nedenle, geliştiricilerin performansa ayıracak sınırlı zamanları olup olmadığını, yüksek performanslı bir uygulama oluşturmalarını kolaylaştırabilir (ve hızlandırabilir) diye düşünüyoruz. Popüler web çerçeveleriyle iş ortaklığı yaparsak üst düzey bileşenler, uygunluk uyarıları vb. ile geliştirici deneyimini iyileştirmek için doğru soyutlama katmanına ulaşırız. Bu popüler araçları kullanan herkes bu avantajlardan yararlanabilecek. Teorik olarak önerilen tavsiye değişirse bileşenlerimizi kolayca güncelleyebiliyoruz ve geliştiricilerin güncel kalma konusunda endişelenmelerine gerek kalmaz.

Houssein: Google'a Geliştirici Destekçisi olarak katıldım ve birkaç yıl sonra yazılım mühendisliği alanında çalışmaya başladım. Önceki çalışmalarımın büyük bir bölümünde web geliştiricilerine harika kullanıcı deneyimleri oluşturmanın birçok farklı yolunu öğretmiş oldum. Geliştiricileri, sitelerinin performansını ve kullanılabilirliğini etkileyebilecek yaygın sorunlar konusunda uyarmak için tekrar tekrar aynı yönergelerin farklı versiyonları sağlanmıştır. Aurora projesini düşünmeye başladığımızda kendimize şunu sorduk: Araç zincirleri onlar için her şeyi hallettiği için geliştiricilere ne yapmaları gerektiğini asla söylemek zorunda kalmayacağımız bir yönde ilerleyebilir miyiz?

Doğru anlıyorsam, altı mühendisten oluşan bir ekipsiniz. Eminim olası her çerçeve veya kitaplıkla çalışamazsınız. Peki kiminle çalışacağınıza nasıl karar vereceksiniz? Bunlar kimler?

Addy: Web, birçok açıdan vahşi vahşi batı gibidir. İstediğiniz çerçeveyi, paketleyiciyi, kitaplıkları ve üçüncü tarafları seçebilirsiniz. Bu durum, iyi veya düşük performansa neden olabilecek çeşitli karmaşıklık katmanlarına neden olur. Performans üzerinde fark yaratmanın en iyi yollarından biri, bu katmanları rahat bir şekilde görüşlü olarak bulmak ve onlara daha fazla fikir eklemektir.

Örneğin, web çerçeveleri (Next.js, Nuxt.js ve bir ölçüde Angular), daha çok elle ele alınan bir çözüme kıyasla daha fazla görüş ve varsayılan değer oluşturmaya çalışır. Onlarla çalışmayı seviyoruz! Bu modellerde, daha iyi Core Web Vitals için resimlerin, yazı tiplerinin ve komut dosyalarının daha güçlü varsayılanlara sahip olması mantıklıdır.

Aynı zamanda, modern en iyi uygulamaların nerelerde işe yaradığını veya yeniden ele alınması gerekebileceğini doğrulamak için iyi bir yol olarak işlev görür ve tüm ekosistemi, optimizasyon sorunlarının çözümüne ilişkin yaklaşım konusunda bilgilendirmeye yardımcı olabilir.

Kara: Gerçekçi olursak popülerliği de hesaba katmalıyız. Web'de mümkün olan en büyük etkiyi yaratmak istiyorsak mevcut büyük bir geliştirici topluluğuna sahip çerçeveler ve kitaplıklarla çalışmak ideal olanıdır. Bu şekilde daha fazla geliştiriciye ve uygulamaya ulaşabiliriz. Ama sadece popülerlik demek değil. Sonuç olarak, popülerliğin, kütüphanenin ne kadar düşünceli olduğunun ve birlikte çalışabileceğimiz mevcut özelliklerin kesiştiği noktadır.

Örneğin, yalnızca popülerliğe bakarsak dikkate alınacak "en büyük üç" olan React, Vue ve Angular'dır. Ancak biz 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 buralarda oluşturmak imkansızdır. Dolayısıyla, bunların üzerine inşa edilen, düşünceli meta çerçevelerle daha yakın bir şekilde çalışıyoruz: Next.js ve Nuxt. Bu soyutlama düzeyinde, yerleşik bileşenler oluşturabiliriz. Aynı zamanda yerleşik sunucuları olduğundan sunucu tarafı optimizasyonları dahil edebiliriz.

Angular'ın derin ortaklıklar listesinde yer aldığını fark edebilirsiniz, ancak bu bir meta çerçeve değildir. Angular oldukça özel bir durum; çünkü oldukça popüler ama React ve Vue gibi tamamlayıcı bir meta çerçevesine sahip değil. Bu yüzden onlarla doğrudan çalışıyor ve mümkün olduğunda KSA üzerinden özelliklere katkıda bulunuyoruz.

Gatsby gibi diğer projelerle de düzenli olarak tasarım senkronizasyonu yaptığımız ancak aktif olarak kod katkısında bulunmadığımız birkaç ilişki olduğunu da belirtmekte fayda var.

Peki bu uygulama nasıl görünür? Bu sorunu çözmek için nasıl bir yaklaşım benimsediniz?

Kara: Pratikte yakın işbirliği yaptığımız birkaç çerçevemiz var. Bu çerçeveyi kullanarak uygulamaların profilini çıkarmak ve performansla ilgili sık karşılaşılan sorunları belirlemek için biraz zaman ayıracağız. Ardından çerçeve ekibiyle birlikte çalışarak bu sorunları çözecek deneysel özellikler tasarlıyor ve bunları uygulamak için doğrudan OSS deposuna kod katkı sağlıyoruz.

Performans etkisinin tahmin ettiğimiz gibi olduğunu doğrulamak bizim için gerçekten çok önemli. Bu nedenle, üretim aşamasında performans testi yapmak için harici şirketlerle de çalışıyoruz. Sonuçlar cesaret vericiyse özelliğin "kararlı" hale gelmesine ve muhtemelen varsayılan bir hale getirilmesine yardımcı oluruz.

Tüm bunlar dile getirdiğiniz kadar kolay olamaz. Şimdiye kadar karşılaştığınız zorluklar veya öğrendikleriniz nelerdi?

Houssein: Elimizden gelenin en iyisini yapmaya çalıştığımız önemli şeylerden biri, birçok rekabet önceliği olan popüler açık kaynaklı kod depolarına katkıda bulunmak. Google ekibi olmamız, özelliklerimize öncelik verileceği anlamına gelmez. Bu nedenle, elimizden geldiğince zorlanmadan yeni özellikler teklif etme ve gönderme şeklindeki tipik sürece uyum sağlamaya çalışırız. Next.js, Nuxt ve Angular ekosistemlerinde alıcı sağlayıcılarla çalıştığımız için çok şanslıyız. Web ekosistemiyle ilgili endişelerimizi dinlemeye açık oldukları ve bizimle çeşitli şekillerde işbirliği yapmaya istekli oldukları için minnettarız.

Birlikte çalıştığımız çerçevelerin çoğunda genel misyonumuz aynıdır: Geliştiriciler mükemmel bir geliştirici deneyiminden yararlanırken aynı zamanda daha iyi bir kullanıcı deneyimini nasıl iyileştirebilirler? Her biri birbiriyle kesişen farklı projelerde çalışan yüzlerce, hatta binlerce olmasa da topluluğa katkıda bulunan ve çerçeve destekçilerinin yüzlerce, hatta binlerce kişi olduğunun farkındayız ve onlara saygı duyuyoruz.

Kara: Ek olarak, performansın etkisini doğrulamayı ve verilere göre hareket etmeyi önemsdiğimiz için işlem biraz daha zaman alır. Keşfedilmemiş bir dönemdeyiz, bu yüzden bazen iyi sonuç vermeyen bir optimizasyonla denemeler yaparız ve planlanmış bir özellik oluşturmazız. Bir özellik başarılı olsa bile, performansı değerlendirmek için bu birkaç ekstra adım zaman alır ve takvimi uzatır.

Özelliklerimizi test edecek prodüksiyon iş ortakları bulmak da zor olabilir. Daha önce de bahsedildiği gibi, işletmeler birer işletmedir ve kendi öncelikleri vardır. Bu nedenle, daha önce gelmesi gereken mevcut projelere uygun olmadıklarında yeni girişimlere uymaları zor olabilir. Ayrıca, yardımcı olmakla en çok ilgilenen şirketler halihazırda performansa yatırım yapmaya zaman ayırıyor. Bu nedenle, aslında hedef kitlemiz bu şirketler değil. Topluluğun performansa yatırım yapamayan büyük çoğunluğundan geri bildirim almaya çalışıyoruz, ancak bize ulaşma olasılığı en düşük olan kullanıcılar bunlar.

Peki, ne tür optimizasyonlara odaklanıyorsunuz?

Houssein: Binlerce uygulamayı analiz ettikten sonra en büyük performans sorunlarının, çerçevenin kendisinden ziyade genellikle uygulama kodundaki karşıt kalıplardan kaynaklandığını tespit ettik. Örneğin, gereksiz şekilde büyük resimler göndermek, özel yazı tiplerinin çok geç yüklenmesi, ana iş parçacığını engelleyen çok sayıda üçüncü taraf isteği alınması ve eşzamansız içeriğin sayfada diğer öğelerin kaymasına yol açabileceği durumlar dikkate alınmamalıdır. Bunların hepsi, kullandığınız araçtan bağımsız olarak ortaya çıkabilecek sorunlar. Bu yüzden, çerçeve araçlarına güzel bir şekilde uyum sağlayan düzgün bir geliştirici deneyimiyle bu sorunları iyi bir şekilde ele alan bazı varsayılan optimizasyonlar yapabilir miyiz?

Bu düşünceden yola çıkarak şunları hazırladık:

Çalışmalarımız, benzer optimizasyonların uygulanması için diğer çerçevelere ve araçlara ilham verdi. Bu, aşağıdakileri kapsar, ancak bunlarla sınırlı değildir:

Çalışmanızın olumlu sonuçlarını bu oyunculardan bazılarıyla paylaşabilir misiniz?

Houssein: Çoğu sitede, gönderdiğimiz optimizasyonlar nedeniyle performansta iyileşmeler yaşanmıştır. En sevdiğim örneklerden biri Leboncoin. Next.js resim bileşenine geçtikten sonra LCP değerini 2,4 saniyeden 1,7 saniyeye düşürdü. Şu anda deneme ve test aşamalarında daha pek çok program bulunuyor. Bu adımlardan öğrendiklerinizi ve kazanımlarınızı buradan paylaşmaya devam edeceğiz.

Anlıyorum. En popüler olanlara odaklanıyorsunuz. Peki, birlikte çalışmadığınız diğer çerçeveler veya kitaplıkların proaktif olarak faydalanabileceği yöntemler var mı?

Ekle: Aurora'nın üzerinde ç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ına bakın. Bu tür uygulamalar genellikle mevcut en iyi uygulamalar grubunu kodlar. Bu tür bileşenlerin oluşturulmasının "nasıl" yapıldığını ve bunların her çerçevede nasıl göründüğünü belgelemeye çalışıyoruz. Umarız bu, fikri kopyalamak için iyi bir başlangıç olmuştur.

Bir ekosistemden (ör. React ve Next.js) öğrendiklerimizi başka ekosisteme taşıyarak oldukça başarılı olduk. Örneğin, yeni Angular Resim Direktifi (Next.js Resim Bileşeni'ni geliştirirken edindiğimiz bilgiler üzerine inşa edilmiştir) veya Gatsby, ayrıntılı JavaScript öbekleme yaklaşımımızı iletir.

Aynı zamanda, katkıda bulunanların benzer performans özellikleri geliştirmeleri veya kullanıcıları için önemli olduğunu düşündükleri diğer optimizasyonlara yatırım yapmaları için gereken bant genişliğine veya finansmana sahip olmadığını her çerçevenin farkındayız. Chrome Web Frameworks Fonu, projelerin katkıda bulunanlara ödeme yapmasını sağlamak ve performans çalışmalarının ekosistemde daha da büyümesini sağlamak amacıyla JavaScript ekosistemindeki performans çalışmalarına sponsor olmanın bir yoludur.

Peki, ekibinizin önünüzdeki yol haritası ne?

Kara: Yaklaşan heyecan verici pek çok projemiz var. 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ı oldukça yaygın bir durumdur. Next.js'de varsayılan olarak yazı tipiyle ilgili CLS'yi azaltmak için yazı tipi metriği geçersiz kılmalarını ve "size-adjust" özelliğini kullanmayı inceliyoruz. Bu konuda Nuxt ekibine de danışıyor ve bu fikri önümüzdeki yıl daha fazla çerçeveye uygulamayı planlıyoruz.
  • INP'de hata ayıklama: Sonraki Boyamayla Etkileşim (INP) metriği kullanıma sunulduktan sonra topluluklarında INP sorunlarının en yaygın temel nedenlerini araştırmak ve çözüm önerileri sunmak için çerçevelerle çalışıyoruz. Bu konuda Angular ile yakın işbirliği içinde çalışıyoruz ve yakında sizinle bazı sonuçları paylaşmayı umuyoruz!
  • Yaygın kullanılan üçüncü taraf komut dosyalarını optimize etme: Üçüncü taraf komut dosyalarını yanlış zamanda yüklemek, performansı önemli ölçüde olumsuz yönde etkileyebilir. Çok yaygın olan birkaç 3P olduğundan, çerçevelerle optimum şekilde yüklendiklerinden ve ana iş parçacığını engellemediğinden emin olmak için bunlar için 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 siteden takip edebilirler.

Haberlerde

Son olarak, Google'daki çerçeve dünyasındaki gelişmelerden birkaç ilginç paylaşmak istiyorum.

Chrome ekibi Temmuz ayında, web'deki performansı, kullanıcı deneyimini ve geliştirici deneyimini iyileştirmeye yardımcı olmayı amaçlayan fon projelerine odaklanan Frameworks ve araçlar fonu için 500.000 ABD doları tutarındaki en son fonlamayı duyurdu. Gelecekteki fonlarda yeni projeler de dikkate alınacaktır. Bu nedenle talepinizi göndermeyi unutmayın.

Tabii ki toplulukta gerçeğe dönüşen bir ton şey var. Ekosistem, Deno'nun Fresh gibi yeni çerçevelerle ve yalnızca tarayıcı içi bir demo olan değil, aynı zamanda Node.js'yi tarayıcıda yerel olarak çalıştırmak için Web Container API'yi kullanan Svelte'in ilk katılım eğiticisi gibi mükemmel deneyimlerle olgunlaşmıştır. Çok iyi şeyler!

Ekosistemin bir araya geldiğini, tarayıcıda mümkün olan her şeyi ortaya koyduğunu ve geliştiricilerin herkesin işine yarayan ürünler oluşturmasına yardımcı olduğunu görmek beni gerçekten heyecanlandırıyor. Web geliştiricisi olmak heyecan verici bir dönemden geçiyoruz.

Bir sonraki Insider'a kadar Hwyl fawr.

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