Saya Paul Kinlan, dan saya memimpin hubungan developer untuk Chrome. Sebagai bagian dari pekerjaan saya, saya bekerja dengan tim advokat web yang penuh semangat yang ditugaskan untuk menghadirkan perspektif developer 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 dipantau dan ditingkatkan, jadi kami terus melakukan iterasi tentang cara untuk memberikan dampak sambil berfokus pada kebutuhan developer. Prinsip panduan yang menurut kami bermanfaat untuk diikuti adalah—"menemui developer di mana pun mereka berada". Studi Stack Overflow baru-baru ini menunjukkan bahwa 75% developer melaporkan menggunakan framework atau abstraksi tertentu. Jadi, kami bertanya-tanya bagaimana cara terbaik untuk melayani developer yang telah membuat keputusan tentang, atau tidak memiliki kendali atas, tech stack mereka? Bagaimana kita membuatnya lebih produktif tanpa menambahkan lebih banyak biaya?
Sebuah tim kecil di Chrome telah mengerjakan project bernama Aurora, dengan tujuan untuk bekerja dengan abstraksi pihak ketiga dari platform web seperti framework dan library. Sasaran mereka adalah membantu menghadirkan peningkatan performa langsung ke dalam abstraksi ini, bukan membebani pelanggan mereka—developer web.
Untuk Chrome Dev Insider edisi ketiga, saya berbicara dengan Addy Osmani, Kara Erickson, dan Houssein Djirdeh dari tim Project Aurora untuk mempelajari lebih lanjut cara mereka menyikapi project ini dan apa yang akan mereka raih di kemudian hari.
Informasi eksklusif: Menggunakan kerangka kerja pihak ketiga
Mari kita mulai dengan asal usul project ini. Bagaimana masalah ini terjadi?
Addy: Aurora memulai dengan sebuah ide sederhana: mari temui developer di mana ia berada dan bantu mereka mencapai tujuan yang diinginkan. Misalnya, bantu tech stack populer yang mereka pilih untuk meningkatkan performa. Banyak developer aplikasi membangun menggunakan React, Vue, atau Angular akhir-akhir ini--atau meta-framework* seperti Next.js dan Nuxt -- (dan tentu saja banyak yang lainnya... Pendek, Lit, Preact, Astro. Daftarnya terus bertambah!). Daripada mengharapkan developer ini menjadi pakar yang mendalam (misalnya, dalam hal performa), kami dapat memastikan mereka sukses dengan menyertakan lebih banyak praktik terbaik secara default ke dalam stack ini. Dengan demikian, situs berkualitas lebih baik adalah efek samping dari sekadar membangun untuk web.
Aurora memilih beberapa framework dan meta-framework yang banyak digunakan untuk berpartner. Kami mendokumentasikan pembelajaran kami (seperti cara membuat komponen gambar yang bagus), sehingga orang lain dapat mengikuti dan mencoba meningkatkan skala melalui framework dan alat lain melalui Chrome Frameworks Fund. Meskipun kualitas pengalaman web melalui browser dapat ditingkatkan, kami percaya bahwa tujuan ini juga (dalam beberapa kasus) dapat dicapai melalui kerangka kerja. Semoga hal ini dapat membantu kita mencapai sasaran web yang berkualitas lebih tinggi untuk semua orang.
Kara: Untuk memperluas hal tersebut, kami ingin meningkatkan performa di web dengan meningkatkan pengalaman developer. Tidak cukup untuk memublikasikan praktik terbaik performa, karena praktik tersebut sering berubah dan sulit bagi perusahaan untuk mengikutinya. Mereka memiliki prioritas bisnis sendiri yang kemungkinan akan terjadi sebelum performa.
Jadi, pemikiran kami adalah jika developer memiliki waktu yang terbatas untuk berfokus pada performa, mari permudah pembuatan aplikasi berperforma tinggi. Jika kami berpartner dengan framework web populer, kami berada di lapisan abstraksi yang tepat untuk meningkatkan pengalaman developer melalui komponen dengan tingkat yang lebih tinggi, peringatan kesesuaian, dll. Siapa pun yang menggunakan alat populer tersebut akan memiliki akses ke manfaat ini. Dan secara teoritis, jika saran yang direkomendasikan berubah, kita dapat memperbarui komponen kita di balik layar dan developer tidak perlu khawatir untuk tetap mengikuti perkembangan.
Houssein: Saya bergabung dengan Google sebagai Advokat Developer sebelum beralih ke peran software engineering beberapa tahun kemudian. Sebagian besar pekerjaan saya sebelumnya adalah dengan mengajari developer web berbagai cara untuk membuat pengalaman pengguna yang luar biasa. Variasi dari panduan yang sama diberikan berulang kali untuk memperingatkan developer tentang masalah umum yang kemungkinan akan memengaruhi performa dan kegunaan situs mereka. Ketika kami mulai memikirkan project Aurora, kami bertanya pada diri sendiri: bisakah kami menuju ke arah di mana kami tidak perlu memberi tahu developer apa yang harus dilakukan karena toolchain mereka menangani semuanya untuk mereka?
Jika saya paham dengan benar, Anda adalah tim yang terdiri dari enam engineer. Saya yakin Anda tidak dapat bekerja dengan setiap {i>framework<i} atau library yang memungkinkan. Jadi, bagaimana Anda memilih siapa yang akan bekerja sama? Dan siapa mereka?
Addy: Web dalam banyak cara seperti dunia liar. Anda dapat memilih hampir semua framework, pemaket, library, dan pihak ketiga yang diinginkan. Hal ini menimbulkan beberapa lapisan kompleksitas yang dapat berkontribusi pada performa yang baik atau buruk. Salah satu cara terbaik untuk meningkatkan kinerja adalah dengan menemukan lapisan tersebut nyaman untuk tidak memiliki opini dan menambahkan lebih banyak pendapat pada lapisan tersebut.
Misalnya, framework web (Next.js, Nuxt.js, dan sejauh mana Angular) mencoba menyertakan lebih banyak opini dan default daripada solusi yang lebih sederhana. Inilah salah satu alasan kami senang bekerja sama dengan mereka. Model ini memerlukan setelan default yang lebih kuat untuk cara memuat gambar, font, dan skrip agar Data Web Inti yang lebih baik.
Ini juga berfungsi sebagai cara yang tepat untuk memastikan di mana praktik terbaik modern bekerja atau mungkin memerlukan pemikiran ulang, dan dapat membantu menginformasikan seluruh ekosistem tentang cara menyelesaikan masalah pengoptimalan.
Kara: Secara realistis, kita juga harus mempertimbangkan popularitas. Jika kita ingin mendapatkan dampak terbesar pada web, idealnya bekerja dengan framework dan library yang memiliki komunitas developer yang besar. Kami dapat menjangkau lebih banyak developer dan aplikasi dengan cara tersebut. Tapi, ini tidak bisa hanya berupa popularitas. Pada akhirnya, aspek ini adalah titik temu antara popularitas, seberapa tidak dapat berubahnya library, dan set fitur yang tersedia yang dapat kita gunakan.
Misalnya, jika kita melihat popularitas saja, React, Vue, dan Angular adalah "tiga hal penting" yang perlu dipertimbangkan. Namun, kami paling sering bekerja dengan Next.js, Nuxt, dan Angular. Hal ini karena library tampilan seperti React dan Vue sebagian besar berfokus pada rendering, jadi tidak mungkin untuk membangun semua fitur yang kita inginkan secara langsung ke dalamnya. Jadi, kami bekerja lebih erat dengan kerangka kerja meta tidak berubah yang dibangun di atasnya: Next.js dan Nuxt. Pada tingkat abstraksi ini, kita dapat membuat komponen bawaan. Mereka juga memiliki server bawaan, sehingga kita dapat menyertakan pengoptimalan sisi server.
Anda mungkin memperhatikan bahwa Angular ada di daftar kemitraan mendalam, tetapi itu bukan framework meta. Angular merupakan kasus khusus karena cukup populer, tetapi tidak memiliki framework meta pelengkap seperti React dan Vue. Jadi, kami bekerja sama dengan mereka secara langsung dan memberikan kontribusi fitur melalui CLI jika memungkinkan.
Perlu diperhatikan bahwa kami memiliki beberapa hubungan berkelanjutan dengan project lain seperti Gatsby. Dalam hal ini, kami sedikit menyinkronkan desain tetapi tidak secara aktif memberikan kontribusi kode.
Jadi, seperti apa penerapannya? Apa pendekatan Anda untuk menyelesaikan masalah ini?
Kara: Dalam praktiknya, kami memiliki beberapa framework yang berkolaborasi erat. Kita akan meluangkan waktu untuk membuat profil aplikasi menggunakan kerangka kerja tersebut dan mencari tahu titik masalah kinerja umum. Kemudian kami bekerja sama dengan tim framework untuk mendesain fitur eksperimental guna menyelesaikan masalah tersebut dan menyumbangkan kode langsung ke repo OSS untuk menerapkannya.
Penting bagi kami untuk memvalidasi bahwa dampak performa adalah apa yang telah kami prediksi. Jadi, kami juga bekerja sama dengan perusahaan eksternal untuk melakukan pengujian performa dalam produksi. Jika hasilnya menggembirakan, kami akan membantu fitur menjadi "stabil", dan berpotensi menjadikannya default.
Semua ini tidak akan semudah Anda membuatnya terdengar. Apa saja tantangan atau pembelajaran yang Anda miliki sejauh ini?
Houssein: Satu hal penting yang kami coba manfaatkan sebaik mungkin adalah berkontribusi pada repositori open source populer yang memiliki banyak prioritas bersaing. Hanya karena kami tim Google, bukan berarti fitur kami akan diprioritaskan, jadi kami berusaha sebaik mungkin untuk menyelaraskannya dengan proses yang umum dalam mengusulkan dan mengirimkan fitur baru tanpa menginjak kaki siapa pun. Kami sangat beruntung dapat bekerja dengan pengelola yang reseptif di ekosistem Next.js, Nuxt, dan Angular. Kami berterima kasih karena mereka telah bersedia mendengarkan kekhawatiran kami tentang ekosistem web dan bersedia untuk berkolaborasi dengan kami dalam lebih dari satu cara.
Dengan banyak framework yang kami gunakan, misi kami secara keseluruhan tetap sama; bagaimana developer bisa meningkatkan pengalaman pengguna yang lebih baik sekaligus menikmati pengalaman developer yang luar biasa? Kami menyadari dan menghormati bahwa ada ratusan, bahkan ribuan, kontributor komunitas dan pengelola kerangka kerja yang masing-masing mengerjakan project berbeda yang bersinggungan.
Kara: Selain itu, karena kami ingin memvalidasi dampak performa dan tindakan berdasarkan data, proses ini memerlukan waktu sedikit lebih lama. Kita berada di wilayah yang belum dipetakan, jadi terkadang kami bereksperimen dengan pengoptimalan yang tidak berhasil dan akhirnya tidak membuat fitur yang direncanakan. Meskipun suatu fitur berjalan dengan baik, beberapa langkah tambahan untuk memeriksa performa tersebut memerlukan waktu dan memperpanjang rentang waktu.
Menemukan partner produksi untuk menguji fitur kami juga dapat menjadi tantangan tersendiri. Seperti disebutkan sebelumnya, mereka adalah bisnis yang memiliki prioritas sendiri, sehingga akan sulit bagi mereka untuk menyesuaikan inisiatif baru jika mereka tidak dapat menyesuaikan dengan baik proyek yang ada saat ini yang harus didahulukan. Selain itu, perusahaan yang paling berminat untuk membantu cenderung sudah meluangkan waktu untuk berinvestasi pada kinerja, jadi mereka sebenarnya bukan target audiens kami. Kami mencoba mengumpulkan masukan dari sejumlah besar komunitas yang tidak dapat berinvestasi dalam performa, tetapi mereka cenderung tidak menghubungi kami.
Selanjutnya, jenis pengoptimalan apa yang Anda fokuskan?
Houssein: Setelah menganalisis ribuan aplikasi, kami menemukan bahwa masalah performa terbesar biasanya disebabkan oleh antipola dalam kode aplikasi, bukan framework itu sendiri. Misalnya, mengirimkan gambar berukuran besar yang tidak perlu, memuat font kustom terlambat, mengambil terlalu banyak permintaan pihak ketiga yang memblokir thread utama, dan tidak menangani bagaimana konten asinkron dapat menyebabkan hal-hal lain bergeser di halaman. Ini semua adalah masalah yang dapat muncul terlepas dari alat yang Anda gunakan, jadi kami berpikir—dapatkah kita memasukkan beberapa pengoptimalan default yang menanganinya dengan baik, tetapi dengan pengalaman developer yang rapi dan cocok dengan alat framework mereka?
Dengan pemikiran ini, kami telah mengirimkan:
- Komponen gambar Next.js.
- Komponen skrip Next.js.
- Penyisipan font otomatis dalam proses build Next.js.
- Perintah gambar sudut.
- Plugin ESLint kesesuaian Next.js untuk memberikan panduan yang dapat ditindaklanjuti kepada developer.
Upaya kami telah menginspirasi framework dan alat lain untuk mengimplementasikan pengoptimalan serupa. Ini mencakup, tetapi tidak terbatas pada:
- Modul gambar nuxt
- Penggantian metrik font nuxt
- Komponen skrip Nuxt (sedang berlangsung)
- Komponen Skrip Gatsby
Dapatkah Anda menyampaikan beberapa hasil positif dari upaya Anda kepada beberapa pemain ini?
Houssein: Banyak situs telah mengalami peningkatan performa berkat pengoptimalan yang kami lakukan. 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 fase eksperimen dan pengujian yang saat ini masih dalam tahap eksperimen dan kami akan terus membagikan pelajaran dan hasil pembelajaran dari sana di sini.
Baik, saya mengerti bahwa fokus Anda adalah pada software yang paling populer. Namun, apakah ada manfaat yang juga dapat diuntungkan oleh framework atau library lain yang tidak Anda ajak bekerja sama?
Addy: Banyak pengoptimalan performa yang berkolaborasi dengan Aurora dapat direplikasi oleh framework apa pun. Lihat di balik upaya komponen Gambar atau Skrip kami, misalnya, yang sering kali menyusun kumpulan praktik terbaik yang sudah ada. Kami mencoba mendokumentasikan "cara" pembuatan komponen tersebut dan tampilannya di setiap framework. Semoga ini adalah awal yang baik untuk meniru ide tersebut.
Kami telah meraih kesuksesan besar dengan mengambil pembelajaran dari satu ekosistem (misalnya, React dan Next.js) dan membawanya ke ekosistem lain. Misalnya, Angular Image Directive baru (yang dibuat berdasarkan pembelajaran kami dalam pembuatan Komponen Gambar Next.js) atau Gatsby menerapkan pendekatan kami pada pemotongan JavaScript yang terperinci.
Pada saat yang sama, kami memahami bahwa tidak semua framework memiliki bandwidth atau dana bagi kontributor untuk membangun fitur performa serupa atau berinvestasi dalam pengoptimalan lain yang mereka yakini penting bagi pengguna. Chrome Web Frameworks Fund adalah cara bagi kami untuk mensponsori pekerjaan performa di ekosistem JavaScript agar project dapat membayar kontributornya dan memungkinkan pekerjaan berbasis performa meningkat skalanya lebih lanjut dalam ekosistem tersebut.
Jadi, apa rencana tim Anda ke depan?
Kara: Kami memiliki banyak proyek menarik yang akan datang. Beberapa sorotan:
- Mengurangi CLS terkait font: Sering kali melihat pergeseran tata letak saat font web dimuat dan menggantikan font penggantian. Kami sedang berusaha menggunakan penggantian metrik font dan properti "size-menyesuaikan" untuk mengurangi CLS terkait font secara default di Next.js. Kami juga telah berkonsultasi dengan tim Nuxt mengenai hal ini dan berencana memperluas ide ini ke lebih banyak framework tahun depan.
- Proses debug INP: Setelah metrik Interaction to Next Paint (INP) dirilis, kami bekerja sama dengan framework untuk menyelidiki penyebab paling umum masalah INP bagi komunitas mereka dan menyarankan perbaikan. Kami telah bekerja sama erat dengan Angular dalam hal ini dan berharap dapat segera membagikan beberapa hasil!
- Mengoptimalkan skrip pihak ketiga yang umum: Memuat skrip pihak ketiga pada waktu yang tidak tepat dapat berdampak negatif besar pada performa. Karena ada beberapa pihak ketiga yang sangat umum, kami sedang mempertimbangkan apakah kami dapat menawarkan beberapa wrapper untuk hal ini guna memastikan mereka dimuat secara optimal dengan framework dan tidak memblokir thread utama. Kami menggunakan komponen skrip Next.js yang kami buat sebagai titik awal untuk penyelidikan ini.
Developer dapat mengikuti progres kami di situs ini.
Dalam berita
Sebelum saya undur diri, saya ingin memberi Anda beberapa pembaruan menarik dari dunia framework yang terjadi di Google.
Pada bulan Juli, tim Chrome mengumumkan putaran terbaru pendanaan sebesar $500 ribu untuk Frameworks and tools funding yang berfokus pada pendanaan project yang bertujuan membantu meningkatkan performa, pengalaman pengguna, dan pengalaman developer di web. Pendanaan mendatang akan mempertimbangkan proyek baru, jadi ingatlah untuk mengirimkan permintaan Anda.
Dan, tentu saja, ada BANYAK hal menakjubkan yang terjadi di komunitas ini. Ekosistem sudah dipenuhi dengan framework baru seperti Deno's Fresh, dan pengalaman luar biasa seperti tutorial aktivasi 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 benar-benar bersemangat melihat ekosistem yang bersatu, mendorong berbagai hal yang mungkin dilakukan di browser, dan membantu developer membuat produk yang cocok untuk semua orang. Ini adalah masa yang menyenangkan sebagai pengembang web.
Sampai jumpa Insider, Hwyl fawr.
Apa pendapat Anda tentang edisi The Chrome Dev Insider ini? Berikan masukan Anda.