Saya Paul Kinlan, dan saya memimpin hubungan developer untuk Chrome. Sebagai bagian dari pekerjaan saya, saya dapat bekerja sama dengan tim pendukung web yang bersemangat yang ditugaskan untuk menghadirkan perspektif developer di dunia nyata kepada tim produk dan engineering kami, dengan metrik bintang utara untuk meningkatkan kepuasan developer.
Kami menyadari bahwa "kepuasan" adalah metrik yang ambisius dan subjektif untuk dilacak dan ditingkatkan, sehingga kami terus melakukan iterasi tentang cara kami dapat memberikan dampak sekaligus berfokus pada kebutuhan developer. Prinsip panduan yang kami temukan berguna untuk diikuti adalah—"menjangkau developer di mana pun mereka berada". Studi Stack Overflow terbaru menunjukkan bahwa 75% developer melaporkan penggunaan framework atau semacam abstraksi. Jadi, kami bertanya-tanya bagaimana cara terbaik untuk melayani developer yang telah membuat keputusan tentang, atau tidak memiliki kontrol atas, stack teknologi mereka? Bagaimana cara meningkatkan produktivitas mereka tanpa menambah overhead?
Tim kecil di Chrome telah mengerjakan project bernama Aurora, dengan tujuan untuk menggunakan abstraksi pihak ketiga dari platform web seperti framework dan library. Tujuannya adalah membantu meningkatkan performa secara langsung ke dalam abstraksi ini, bukan membebankan beban kepada pelanggan mereka—developer web.
Untuk edisi ketiga Chrome Dev Insider, saya berbicara dengan Addy Osmani, Kara Erickson, dan Houssein Djirdeh dari tim Project Aurora untuk mempelajari lebih lanjut cara mereka menangani project ini dan apa yang akan mereka lakukan selanjutnya.
Info eksklusif: Bekerja dengan framework pihak ketiga
Mari kita mulai dengan asal-usul project ini. Bagaimana hal itu bisa terjadi?
Addy: Aurora dimulai dengan ide sederhana: mari kita temui developer di mana pun mereka berada dan bantu mereka mencapai tujuan mereka. Misalnya, bantu stack teknologi populer yang telah mereka pilih untuk meningkatkan performa. Banyak developer aplikasi yang membuat aplikasi menggunakan React, Vue, atau Angular saat ini--atau meta-framework* seperti Next.js dan Nuxt -- (dan tentu saja banyak lainnya... Svelte, Lit, Preact, Astro. Daftarnya terus bertambah). Daripada mengharapkan developer ini menjadi pakar mendalam (misalnya, dalam performa), kita dapat memastikan mereka meraih kesuksesan dengan menyertakan lebih banyak praktik terbaik secara default ke dalam stack ini. Dengan begitu, situs yang berkualitas lebih baik adalah efek samping dari hanya membuat untuk web.
Aurora memilih beberapa framework dan meta-framework yang banyak digunakan untuk berpartner, kami mendokumentasikan pembelajaran kami (seperti cara mem-build komponen gambar yang baik), sehingga orang lain dapat mengikuti dengan cepat dan mencoba menskalakan melalui framework dan alat lain melalui Chrome Frameworks Fund. Meskipun kualitas pengalaman web dapat ditingkatkan melalui browser, kami yakin bahwa sasaran ini juga dapat (dalam beberapa kasus) dicapai melalui framework. Kami harap hal ini membantu kami mencapai sasaran kami untuk menyediakan web yang berkualitas lebih tinggi bagi semua orang.
Kara: Untuk memperluasnya, idenya adalah meningkatkan performa di web dengan meningkatkan pengalaman developer. Mempublikasikan praktik terbaik performa saja tidak cukup, karena praktik tersebut sering berubah dan sulit bagi perusahaan untuk mengikutinya. Mereka memiliki prioritas bisnis mereka sendiri yang kemungkinan akan lebih diutamakan daripada performa.
Jadi, pemikiran kami adalah jika developer memiliki waktu terbatas untuk berfokus pada performa, mari kita permudah (dan percepat) mereka dalam membuat aplikasi yang berperforma tinggi. Jika berpartner dengan framework web populer, kita berada di lapisan abstraksi yang tepat untuk meningkatkan pengalaman developer melalui komponen tingkat tinggi, peringatan kepatuhan, dll. Siapa pun yang menggunakan alat populer tersebut akan memiliki akses ke manfaat ini. Dan secara teoritis, jika saran yang direkomendasikan berubah, kita dapat mengupdate komponen di balik layar dan developer tidak perlu khawatir untuk tetap mengikuti perkembangan terbaru.
Houssein: Saya bergabung dengan Google sebagai Developer Advocate sebelum beralih ke peran software engineering beberapa tahun kemudian. Sebagian besar pekerjaan saya sebelumnya melibatkan pengajaran berbagai cara kepada developer web untuk membangun pengalaman pengguna yang luar biasa. Variasi panduan yang sama diberikan berulang kali untuk memperingatkan developer tentang masalah umum yang kemungkinan akan memengaruhi performa dan kegunaan situs mereka. Saat mulai memikirkan project Aurora, kami bertanya pada diri sendiri: dapatkah kita menuju ke arah yang tidak perlu memberi tahu developer apa yang harus dilakukan karena toolchain mereka menangani semuanya?
Jika saya tidak salah paham, Anda adalah tim yang terdiri dari enam engineer? Saya yakin Anda tidak dapat menggunakan semua framework atau library yang ada. Jadi, bagaimana cara Anda memilih orang yang akan diajak bekerja sama? Dan siapa mereka?
Addy: Web dalam banyak hal seperti wild wild west. Anda dapat memilih hampir semua framework, bundler, library, dan pihak ketiga yang Anda inginkan. Hal ini menyebabkan beberapa lapisan kompleksitas yang dapat berkontribusi pada performa yang baik atau buruk. Salah satu cara terbaik untuk meningkatkan performa adalah menemukan lapisan yang nyaman dengan memiliki pendapat dan menambahkan lebih banyak pendapat ke dalamnya.
Misalnya, framework web (Next.js, Nuxt.js, dan sampai batas tertentu Angular) mencoba memasukkan lebih banyak pendapat dan default daripada solusi yang lebih di-roll sendiri. Inilah salah satu alasan kami senang bekerja sama dengan mereka. Memiliki setelan default yang lebih kuat untuk cara memuat gambar, font, dan skrip guna mendapatkan Data Web Inti yang lebih baik adalah hal yang wajar dalam model ini.
Hal ini juga berfungsi sebagai cara yang baik untuk mengonfirmasi tempat praktik terbaik modern yang berhasil atau mungkin perlu dipikirkan ulang dan dapat membantu menginformasikan seluruh ekosistem tentang cara mendekati pemecahan masalah pengoptimalan.
Kara: Secara realistis, kita juga harus mempertimbangkan popularitas. Jika kita ingin memiliki dampak terbesar di web, bekerja dengan framework dan library yang memiliki komunitas developer yang besar adalah hal yang ideal. Dengan begitu, kami dapat menjangkau lebih banyak developer dan aplikasi. Namun, popularitas saja tidak cukup. Pada akhirnya, ini adalah persimpangan antara popularitas, seberapa banyak library memiliki opini, dan kumpulan fitur yang tersedia yang dapat kita gunakan.
Misalnya, jika kita hanya melihat popularitas, React, Vue, dan Angular adalah "tiga besar" yang perlu dipertimbangkan. Namun, kami paling banyak menggunakan Next.js, Nuxt, dan Angular. Hal ini karena library tampilan seperti React dan Vue sebagian besar berfokus pada rendering, sehingga tidak mungkin untuk mem-build semua fitur yang kita inginkan secara langsung. Jadi, kami bekerja lebih dekat dengan meta-framework yang dibuat berdasarkan pendapat: Next.js dan Nuxt. Pada tingkat abstraksi ini, kita dapat membuat komponen bawaan. Aplikasi ini juga memiliki server bawaan, sehingga kita dapat menyertakan pengoptimalan sisi server.
Anda mungkin melihat bahwa Angular ada dalam daftar kemitraan mendalam tersebut, tetapi Angular bukanlah meta-framework. Angular agak merupakan kasus khusus karena cukup populer, tetapi tidak memiliki meta-framework pelengkap seperti React dan Vue. Jadi, kami bekerja sama dengan mereka secara langsung dan berkontribusi pada fitur melalui CLI mereka jika memungkinkan.
Selain itu, perlu diperhatikan bahwa kami memiliki beberapa hubungan berkelanjutan dengan project lain seperti Gatsby, tempat kami menyinkronkan desain secara rutin, tetapi tidak secara aktif berkontribusi pada kode.
Jadi, seperti apa penerapannya? Apa pendekatan Anda untuk memecahkan masalah ini?
Kara: Dalam praktiknya, kami memiliki beberapa framework yang kami ajak berkolaborasi secara erat. Kita akan meluangkan waktu untuk membuat profil aplikasi menggunakan framework tersebut dan mencari tahu poin masalah performa yang umum. Kemudian, kami bekerja sama dengan tim framework untuk mendesain fitur eksperimental guna mengatasi masalah tersebut dan berkontribusi pada kode langsung ke repo OSS untuk menerapkannya.
Kami sangat ingin memvalidasi bahwa dampak performa sesuai dengan yang kami prediksi, jadi kami juga bekerja sama dengan perusahaan eksternal untuk melakukan pengujian performa dalam produksi. Jika hasilnya menggembirakan, kami akan membantu fitur tersebut menjadi "stabil", dan berpotensi menjadikannya sebagai default.
Semua ini tidak semudah yang Anda bayangkan. Apa saja tantangan atau pembelajaran yang Anda dapatkan sejauh ini?
Houssein: Salah satu hal penting yang kami coba lakukan sebaik mungkin adalah berkontribusi pada repositori open source populer yang memiliki banyak prioritas yang bersaing. Hanya karena kami adalah tim Google, bukan berarti fitur kami akan diprioritaskan. Jadi, kami mencoba semaksimal mungkin untuk menyesuaikan dengan proses standar dalam mengusulkan dan meluncurkan fitur baru tanpa mengganggu siapa pun. Kami sangat beruntung dapat bekerja sama dengan pengelola yang responsif di ekosistem Next.js, Nuxt, dan Angular. Kami berterima kasih karena mereka telah bersedia mendengarkan kekhawatiran kami tentang ekosistem web dan bersedia berkolaborasi dengan kami dalam berbagai cara.
Dengan banyak framework yang kami gunakan, misi kami secara keseluruhan sama; bagaimana developer bisa mendapatkan pengalaman pengguna yang lebih baik secara langsung sekaligus menikmati pengalaman developer yang luar biasa? Kami menyadari dan menghormati bahwa ada ratusan, bahkan ribuan, kontributor komunitas dan pengelola framework yang masing-masing mengerjakan project berbeda yang saling tumpang-tindih.
Kara: Selain itu, karena kami ingin memvalidasi dampak performa dan bertindak berdasarkan data, prosesnya memerlukan waktu lebih lama. Kami berada di wilayah yang belum dijelajahi, jadi terkadang kami akan bereksperimen dengan pengoptimalan yang tidak berhasil dan kami tidak akan membuat fitur yang direncanakan. Meskipun fitur berhasil, beberapa langkah tambahan untuk memeriksa performa memerlukan waktu dan memperpanjang linimasa.
Menemukan partner produksi untuk menguji fitur kami juga bisa menjadi tantangan. Seperti yang disebutkan sebelumnya, mereka adalah bisnis dan memiliki prioritas mereka sendiri, sehingga mereka mungkin kesulitan untuk menyesuaikan inisiatif baru jika tidak selaras dengan project yang sudah ada dan harus didahulukan. Selain itu, perusahaan yang paling tertarik untuk membantu cenderung sudah meluangkan waktu untuk berinvestasi dalam performa, sehingga mereka bukan target audiens kami. Kami mencoba mengumpulkan masukan dari sebagian besar komunitas yang tidak dapat berinvestasi dalam performa, tetapi mereka adalah orang yang paling tidak mungkin menghubungi kami.
Selanjutnya, jenis pengoptimalan apa yang telah Anda fokuskan?
Houssein: Setelah menganalisis ribuan aplikasi, kami mendapati bahwa masalah performa terbesar biasanya disebabkan oleh anti-pola dalam kode aplikasi, bukan framework itu sendiri. Misalnya, mengirimkan gambar yang tidak perlu besar, memuat font kustom terlalu lambat, mengambil terlalu banyak permintaan pihak ketiga yang memblokir thread utama, dan tidak menangani bagaimana konten asinkron dapat menyebabkan hal lain bergeser di halaman. Semua ini adalah masalah yang dapat muncul terlepas dari alat yang Anda gunakan, jadi kami berpikir—dapatkah kita menyertakan beberapa pengoptimalan default yang menanganinya dengan baik, tetapi dengan pengalaman developer yang rapi yang cocok dengan alat framework mereka?
Dengan pemikiran ini, kami telah mengirimkan:
- Komponen gambar Next.js.
- Komponen skrip Next.js.
- Penyertaan font otomatis dalam proses build Next.js.
- Perintah gambar Angular.
- Plugin ESLint kepatuhan Next.js untuk memberikan panduan yang bisa ditindaklanjuti kepada developer.
Pekerjaan kami telah menginspirasi framework dan alat lain untuk menerapkan pengoptimalan serupa. Hal ini mencakup, tetapi tidak terbatas pada:
- Modul gambar Nuxt
- Penggantian metrik font Nuxt
- Komponen skrip Nuxt (sedang berlangsung)
- Komponen Skrip Gatsby
Dapatkah Anda membagikan beberapa hasil positif dari pekerjaan Anda kepada beberapa pemain ini?
Houssein: Banyak situs mengalami peningkatan performa karena pengoptimalan yang telah kami kirimkan. Salah satu contoh favorit saya adalah Leboncoin, yang mengurangi LCP dari 2,4 detik menjadi 1,7 detik setelah beralih ke komponen gambar Next.js. Masih banyak lagi fitur yang saat ini dalam tahap eksperimen dan pengujian, dan kami akan terus membagikan pembelajaran dan pencapaian dari fitur tersebut di sini.
Oke, saya mengerti bahwa fokus Anda adalah pada framework atau library yang paling populer, tetapi apakah ada cara agar framework atau library lain yang tidak Anda gunakan secara proaktif juga mendapatkan manfaat?
Addy: Banyak pengoptimalan performa yang dikolaborasikan Aurora dapat direplikasi oleh framework apa pun. Lihat upaya kami dalam membuat komponen Gambar atau Skrip, misalnya, komponen tersebut sering kali mengkodifikasi serangkaian praktik terbaik yang ada. Kami mencoba mendokumentasikan "cara" membuat komponen tersebut dan tampilannya di setiap framework. Semoga ini adalah awal yang baik untuk menyalin ide.
Kami telah melihat beberapa kesuksesan yang baik dengan mengambil pembelajaran dari satu ekosistem (misalnya, React dan Next.js) dan menerapkannya ke ekosistem lainnya. Misalnya, Angular Image Directive baru (dibuat berdasarkan pembelajaran kami dalam membuat Komponen Gambar Next.js) atau Gatsby yang mengirimkan pendekatan kami untuk pengelompokan JavaScript terperinci.
Pada saat yang sama, kami memahami bahwa tidak setiap framework akan memiliki bandwidth atau pendanaan bagi kontributor untuk membuat fitur performa serupa atau berinvestasi dalam pengoptimalan lain yang mereka yakini penting bagi pengguna. Dana Framework Web Chrome adalah cara bagi kami untuk mensponsori pekerjaan performa di ekosistem JavaScript agar project dapat membayar kontributornya dan memungkinkan pekerjaan performa untuk diskalakan lebih lanjut di ekosistem.
Jadi, apa yang ada dalam rencana tim Anda ke depannya?
Kara: Kami memiliki banyak project menarik yang akan datang. Beberapa sorotan:
- Mengurangi CLS terkait font: Pergeseran tata letak saat font web dimuat dan menggantikan font penggantian cukup umum terjadi. Kami sedang mempelajari penggunaan penggantian metrik font dan properti "size-adjust" untuk mengurangi CLS terkait font secara default di Next.js. Kami juga telah berkonsultasi dengan tim Nuxt terkait hal ini dan berencana untuk memperluas ide ini ke lebih banyak framework tahun depan.
- Men-debug INP: Setelah metrik Interaction to Next Paint (INP) dirilis, kami bekerja sama dengan framework untuk menyelidiki akar penyebab paling umum dari masalah INP untuk komunitas mereka dan menyarankan perbaikan. Kami telah bekerja sama dengan Angular dalam hal ini dan berharap dapat segera membagikan beberapa hasilnya.
- Mengoptimalkan skrip pihak ketiga umum: Memuat skrip pihak ketiga pada waktu yang salah dapat berdampak negatif yang signifikan pada performa. Karena ada beberapa pihak ketiga yang sangat umum, kami sedang mencari tahu apakah kami dapat menawarkan beberapa wrapper untuk memastikannya dimuat secara optimal dengan framework dan tidak memblokir thread utama. Kita menggunakan komponen skrip Next.js yang kita buat sebagai titik awal untuk investigasi ini.
Developer dapat mengikuti progres kami di situs ini.
Dalam berita
Sebelum mengakhiri, saya ingin menyampaikan beberapa info terbaru yang menarik dari dunia framework yang terjadi di Google.
Pada bulan Juli, tim Chrome mengumumkan putaran pendanaan terbaru sebesar $500 ribu untuk Dana framework dan alat yang berfokus pada pendanaan project yang bertujuan untuk membantu meningkatkan performa, pengalaman pengguna, dan pengalaman developer di web. Pendanaan mendatang akan mempertimbangkan project baru, jadi jangan lupa untuk mengirimkan permintaan Anda.
Dan, tentu saja, ada banyak hal luar biasa yang terjadi di komunitas ini. Ekosistem ini sudah matang dengan framework baru seperti Fresh Deno, dan pengalaman luar biasa seperti tutorial orientasi Svelte yang tidak hanya merupakan demo dalam browser, tetapi juga menggunakan Web Container API untuk menjalankan Node.js secara native di browser. Banyak hal bagus!
Saya sangat senang melihat ekosistem ini terwujud, mendorong kemungkinan di browser, dan membantu developer membuat produk yang cocok untuk semua orang. Saat ini adalah waktu yang menyenangkan untuk menjadi developer web.
Sampai jumpa di Insider berikutnya, Hwyl fawr.
Bagaimana pendapat Anda tentang edisi The Chrome Dev Insider ini? Berikan masukan Anda.