Pendekatan kompiler untuk kinerja web: pandangan Rich Harris

Mengapa beberapa aplikasi web terasa lambat bahkan di perangkat yang bagus

Pengguna jarang menjelaskan kinerja dengan istilah teknis. Mereka bilang aplikasi terasa berat. Halaman butuh jeda terlalu lama untuk menampilkan sesuatu, tombol merespons terlambat, dan tindakan sederhana seperti membuka menu, mengetik di kotak pencarian, atau berpindah tab tersendat.

Gejalanya familiar: muat pertama yang lambat (UI kosong atau setengah jadi), interaksi yang lag (klik yang terjadi setelah jeda, scrolling yang tersendat), dan spinner lama setelah tindakan yang seharusnya instan, seperti menyimpan formulir atau memfilter daftar.

Banyak dari ini adalah biaya runtime. Secara sederhana, ini pekerjaan yang harus dilakukan browser setelah halaman dimuat agar aplikasi bisa digunakan: mengunduh lebih banyak JavaScript, memparse-nya, menjalankannya, membangun UI, memasang handler, lalu terus melakukan kerja ekstra pada setiap pembaruan. Bahkan di perangkat cepat, ada batas berapa banyak JavaScript yang bisa diproses browser sebelum pengalaman mulai melambat.

Masalah kinerja juga muncul belakangan. Awalnya, aplikasi kecil: beberapa layar, data ringan, UI sederhana. Lalu produk tumbuh. Marketing menambahkan tracker, desain menambahkan komponen yang lebih kaya, tim menambah state, fitur, dependensi, dan personalisasi. Setiap perubahan terlihat tidak berbahaya sendiri, tapi total pekerjaan menumpuk.

Itulah mengapa tim mulai memperhatikan ide kinerja yang mengedepankan kompiler. Tujuannya biasanya bukan skor sempurna. Melainkan agar terus mengirim fitur tanpa aplikasi menjadi lebih lambat tiap bulan.

Runtime-heavy vs saat kompilasi: ide dasar

Kebanyakan framework frontend membantu Anda melakukan dua hal: membangun aplikasi, dan menjaga UI tetap sinkron dengan data. Perbedaan kunci adalah kapan bagian kedua itu terjadi.

Dengan framework yang berat di runtime, lebih banyak pekerjaan terjadi di browser setelah halaman dimuat. Anda mengirim runtime tujuan-umum yang bisa menangani banyak kasus: melacak perubahan, memutuskan apa yang harus diperbarui, dan menerapkan pembaruan itu. Fleksibilitas itu bagus untuk pengembangan, tapi sering berarti lebih banyak JavaScript yang harus diunduh, diparse, dan dieksekusi sebelum UI terasa siap.

Dengan optimisasi saat kompilasi, lebih banyak pekerjaan dipindahkan ke langkah build. Alih-alih mengirimkan aturan umum ke browser, tool build menganalisis komponen Anda dan menghasilkan kode yang lebih langsung dan spesifik untuk aplikasi.

Model mental yang berguna:

• Runtime-heavy seperti mengirim instruksi dan kotak alat, lalu merakit di rumah pelanggan.
• Compile-time seperti mengirim bagian yang sudah dipotong dan diberi label, sehingga perakitan lebih cepat.

Kebanyakan produk nyata berada di tengah. Pendekatan yang mengutamakan kompiler masih mengirim beberapa kode runtime (routing, fetching data, animasi, penanganan error). Framework yang berat di runtime juga memanfaatkan teknik build-time (minification, code splitting, server rendering) untuk mengurangi kerja di klien. Pertanyaan praktisnya bukan mana yang “benar,” melainkan campuran mana yang cocok untuk produk Anda.

Rich Harris dan kenapa “framework adalah kompiler” penting

Rich Harris adalah salah satu suara paling jelas di balik pemikiran frontend yang mengutamakan kompiler. Argumennya sederhana: lakukan lebih banyak kerja sebelumnya agar pengguna mengunduh lebih sedikit kode dan browser melakukan lebih sedikit kerja.

Motivasinya praktis. Banyak framework yang berat di runtime mengirim mesin tujuan-umum: logika komponen, reaktivitas, diffing, penjadwalan, dan helper yang harus bekerja untuk setiap aplikasi. Fleksibilitas itu menghabiskan byte dan CPU. Bahkan ketika UI Anda kecil, Anda masih bisa membayar harga runtime yang besar.

Pendekatan kompiler membalik modelnya. Saat build, kompiler melihat komponen Anda dan menghasilkan kode update DOM spesifik yang dibutuhkan. Jika sebuah label tidak pernah berubah, itu menjadi HTML biasa. Jika hanya satu nilai yang berubah, hanya jalur update untuk nilai itu yang dihasilkan. Alih-alih mengirim mesin UI generik, Anda mengirim output yang disesuaikan untuk produk Anda.

Hasil yang sering terlihat: kode framework yang dikirim ke pengguna lebih sedikit, dan pekerjaan yang dilakukan pada setiap interaksi juga lebih sedikit. Ini juga cenderung terlihat paling jelas pada perangkat kelas rendah, di mana overhead runtime tambahan cepat menjadi terlihat.

Tetap ada trade-off:

• Beberapa pola dinamis lebih sulit ketika kompiler tidak bisa memahaminya di muka.
• Kualitas tooling menjadi lebih penting (kecepatan build, debugging, source map).
• Konvensi ekosistem mungkin berbeda, yang memengaruhi perekrutan dan penggunaan ulang.
• Anda mungkin masih memerlukan helper runtime, hanya lebih kecil dan lebih terarah.

Aturan praktis: jika UI Anda sebagian besar dapat diketahui saat build, kompiler bisa menghasilkan output yang ketat. Jika UI Anda sangat dinamis atau didorong plugin, runtime yang lebih berat bisa lebih mudah.

Apa yang bisa diperbaiki optimisasi saat kompilasi secara praktis

Optimisasi saat kompilasi mengubah tempat kerja dilakukan. Lebih banyak keputusan dibuat saat build, dan lebih sedikit kerja tersisa untuk browser.

Salah satu hasil yang terlihat adalah lebih sedikit JavaScript yang dikirim. Bundle yang lebih kecil mengurangi waktu jaringan, waktu parsing, dan delay sebelum halaman bisa merespons ketukan atau klik. Di ponsel kelas menengah, itu lebih penting daripada yang diperkirakan banyak tim.

Kompiler juga bisa menghasilkan update DOM yang lebih langsung. Ketika langkah build bisa melihat struktur komponen, ia dapat membuat kode update yang hanya menyentuh node DOM yang benar-benar berubah, tanpa begitu banyak lapisan abstraksi setiap interaksi. Ini membuat pembaruan yang sering terasa lebih gesit, terutama pada daftar, tabel, dan form.

Analisis saat build juga bisa memperkuat tree-shaking dan penghapusan kode mati. Imbalannya bukan hanya file yang lebih kecil. Melainkan jalur kode yang lebih sedikit yang harus dimuat dan dieksekusi oleh browser.

Hidrasi adalah area lain di mana pilihan saat build bisa membantu. Hidrasi adalah langkah ketika halaman yang dirender server menjadi interaktif dengan memasang event handler dan membangun kembali state di browser. Jika build bisa menandai apa yang butuh interaktivitas dan apa yang tidak, Anda bisa mengurangi kerja muat pertama.

Sebagai efek samping, kompilasi sering memperbaiki scoping CSS. Build dapat menulis ulang nama class, menghapus style yang tidak digunakan, dan mengurangi kebocoran gaya antar-komponen. Itu menurunkan biaya kejutan seiring bertambahnya UI.

Bayangkan dashboard dengan filter dan tabel data besar. Pendekatan compiler-first dapat menjaga muat awal lebih ringan, memperbarui hanya sel yang berubah setelah klik filter, dan menghindari hidrasi bagian halaman yang tidak pernah menjadi interaktif.

Di mana framework yang berat di runtime masih masuk akal

Runtime yang lebih besar tidak otomatis buruk. Seringkali ia membeli fleksibilitas: pola yang diputuskan saat runtime, banyak komponen pihak ketiga, dan alur kerja yang diuji selama bertahun-tahun.

Framework yang berat di runtime unggul ketika aturan UI sering berubah. Jika Anda butuh routing kompleks, layout bertingkat, form kaya, dan model state yang dalam, runtime yang matang bisa terasa seperti jaring pengaman.

Runtime membayar untuk kenyamanan

Runtime membantu ketika Anda ingin framework menangani banyak hal saat aplikasi berjalan, bukan hanya saat dibangun. Itu bisa membuat tim lebih cepat sehari-hari, meski menambah overhead.

Keuntungan umum termasuk ekosistem besar, pola yang familiar untuk state dan data fetching, dev tools yang kuat, ekstensi ala plugin yang lebih mudah, dan onboarding yang lebih mulus saat merekrut dari pool bakat umum.

Kefamilaran tim adalah biaya dan manfaat nyata. Framework yang sedikit lebih lambat yang tim Anda bisa kirim dengan percaya diri bisa mengalahkan pendekatan yang lebih cepat tetapi memerlukan pelatihan ulang, disiplin lebih ketat, atau tooling khusus untuk menghindari jebakan.

Saat overhead runtime bukan bottleneck

Banyak keluhan “aplikasi lambat” bukan disebabkan oleh runtime framework. Jika halaman menunggu API yang lambat, gambar berat, terlalu banyak font, atau skrip pihak ketiga, berpindah framework tidak akan memperbaiki masalah inti.

Dashboard admin internal yang berada di balik login sering terasa baik walau dengan runtime lebih besar, karena pengguna memakai perangkat kuat dan pekerjaannya didominasi tabel, izin, dan query backend.

"Cukup cepat" bisa menjadi target yang tepat di awal. Jika Anda masih membuktikan nilai produk, jaga kecepatan iterasi tinggi, tetapkan anggaran dasar, dan baru ambil kompleksitas compiler-first ketika ada bukti bahwa itu penting.

Kinerja vs kecepatan iterasi: trade-off nyata di tim

Kecepatan iterasi adalah time-to-feedback: seberapa cepat seseorang bisa mengubah layar, menjalankannya, melihat apa yang rusak, dan memperbaikinya. Tim yang menjaga loop ini pendek mengirim lebih sering dan belajar lebih cepat. Itu sebabnya framework yang berat di runtime bisa terasa produktif di awal: pola yang familiar, hasil cepat, banyak perilaku bawaan.

Pekerjaan kinerja memperlambat loop itu ketika dilakukan terlalu dini atau terlalu luas. Jika setiap pull request berubah menjadi debat mikro-optimisasi, tim berhenti mengambil risiko. Jika Anda membangun pipeline kompleks sebelum tahu apa produk itu, orang menghabiskan waktu melawan tooling daripada bicara dengan pengguna.

Triknya adalah sepakat apa arti “cukup baik” dan iterasi di dalam kotak itu. Anggaran kinerja memberi Anda kotak itu. Bukan soal mengejar skor sempurna. Melainkan batas yang melindungi pengalaman sambil menjaga pengembangan bergerak.

Anggaran praktis bisa meliputi:

• Halaman menjadi dapat digunakan dalam beberapa detik di ponsel kelas menengah.
• JavaScript per-route tetap di bawah batas yang disepakati tim.
• Interaksi kunci (cari, tambah ke keranjang, simpan) merespons cepat.
• Tidak ada fitur tunggal yang menambah lebih dari sedikit jumlah JS atau CSS.

Jika Anda mengabaikan kinerja, Anda biasanya membayar belakangan. Begitu produk tumbuh, kelambanan terkait keputusan arsitektur, bukan hanya tweak kecil. Rewrite terlambat bisa berarti membekukan fitur, melatih ulang tim, dan memecah alur kerja yang dulu berfungsi.

Tooling compiler-first dapat menggeser trade-off ini. Anda mungkin menerima build yang sedikit lebih lama, tetapi mengurangi jumlah kerja yang dilakukan pada setiap perangkat, setiap kunjungan.

Tinjau ulang anggaran seiring produk terbukti. Di awal, lindungi dasar. Saat trafik dan pendapatan tumbuh, perketat anggaran dan investasikan di tempat yang benar-benar memengaruhi metrik, bukan gengsi.

Cara mengukur kinerja tanpa tersesat

Argumen kinerja menjadi berantakan ketika tidak ada yang sepakat apa arti “cepat.” Pilih beberapa metrik kecil, tuliskan, dan perlakukan sebagai papan skor bersama.

Set starter yang sederhana:

• Waktu muat awal (waktu ke layar pertama yang dapat digunakan)
• Delay interaksi (berapa lama ketukan atau klik terasa macet)
• Ukuran bundle (apa yang harus diunduh dan diparse browser)
• Latency API (lama backend menjawab)

Ukur di perangkat representatif, bukan hanya laptop pengembangan. CPU cepat, cache hangat, dan server lokal bisa menyembunyikan delay yang muncul di ponsel kelas menengah lewat data seluler rata-rata.

Tetap realistis: pilih dua atau tiga perangkat yang sesuai pengguna nyata dan jalankan alur yang sama setiap kali (layar beranda, login, tugas umum). Lakukan itu secara konsisten.

Sebelum mengubah framework, ambil baseline. Rekam angka build hari ini untuk alur yang sama dan simpan. Baseline itu adalah foto “sebelum” Anda.

Jangan menilai kinerja dari satu skor lab. Tool lab membantu, tapi bisa memberi penghargaan pada hal yang salah (muat pertama yang hebat) sementara melewatkan yang dikeluhkan pengguna (menu yang tersendat, mengetik yang lambat, delay setelah layar pertama).

Saat angka memburuk, jangan menebak. Periksa apa yang dikirim, apa yang memblokir rendering, dan ke mana waktu pergi: jaringan, JavaScript, atau API.

Kerangka keputusan langkah-demi-langkah yang bisa Anda gunakan

Untuk membuat pilihan yang tenang dan berulang, anggap keputusan framework dan rendering seperti keputusan produk. Tujuannya bukan teknologi terbaik, melainkan keseimbangan antara kinerja dan laju yang tim Anda butuhkan.

1. Definisikan permukaan produk Anda. Pisahkan halaman marketing, dashboard yang sudah login, mobile, dan alat admin internal. Setiap permukaan punya pengguna, perangkat, dan ekspektasi berbeda.
2. Tetapkan anggaran kinerja. Pilih 2 atau 3 angka yang akan Anda lindungi, seperti muat pertama di ponsel kelas menengah dan waktu untuk satu interaksi kunci (cari, filter, simpan).
3. Peringkatkan kendala Anda. Jujurlah tentang apa yang paling penting saat ini: keterampilan tim, tenggat, SEO, aturan privasi data, dan tempat aplikasi harus berjalan.
4. Pilih pendekatan. Compiler-first cocok ketika muat pertama dan kecepatan interaksi tidak bisa ditawar. Runtime-first cocok ketika Anda butuh fleksibilitas maksimal dan iterasi cepat. Hybrid sering menang: buat permukaan sensitif-performa tetap ringan, dan gunakan tooling runtime yang lebih berat di tempat interaktivitas jelas memberi manfaat.
5. Validasi dengan thin slice, lalu tetapkan. Bangun satu alur pengguna nyata ujung-ke-ujung, ukur terhadap anggaran, dan tuliskan apa yang Anda pilih dan mengapa.

Thin slice harus mencakup bagian yang berantakan: data nyata, auth, dan layar paling lambat Anda.

Jika Anda ingin cara cepat memprototipe thin slice itu, Koder.ai (koder.ai) memungkinkan Anda membangun alur web, backend, dan aplikasi mobile lewat chat, lalu mengekspor source code. Itu membantu menguji route nyata sejak dini dan menjaga eksperimen dapat dibalik dengan snapshot dan rollback.

Dokumentasikan keputusan dalam bahasa sederhana, termasuk apa yang akan membuat Anda meninjau kembali (pertumbuhan trafik, pangsa mobile, tujuan SEO). Itu membuat pilihan bertahan saat tim berganti.

Kesalahan umum tim dalam memilih kinerja

Keputusan kinerja biasanya salah saat tim mengoptimalkan apa yang mereka lihat hari ini, bukan apa yang akan dirasakan pengguna tiga bulan kemudian.

Salah satu kesalahan adalah over-optimizing di minggu pertama. Tim menghabiskan hari memotong milidetik pada halaman yang masih berubah setiap hari, sementara masalah nyata adalah pengguna belum punya fitur yang tepat. Di awal, percepat pembelajaran dulu. Kunci pekerjaan kinerja lebih dalam setelah rute dan komponen stabil.

Kesalahan lain adalah mengabaikan pertumbuhan bundle sampai terasa. Semua terasa baik di 200 KB, lalu beberapa tambahan “kecil” membuat Anda mengirim megabyte. Kebiasaan sederhana membantu: lacak ukuran bundle dari waktu ke waktu dan anggap lonjakan tiba-tiba sebagai bug.

Tim juga sering default ke rendering client-only untuk segalanya, bahkan ketika beberapa rute sebagian besar statis (halaman harga, konten bergaya docs, langkah onboarding). Halaman-halaman itu sering bisa disajikan dengan jauh lebih sedikit kerja di perangkat.

Pembunuh yang lebih sunyi adalah menambahkan library UI besar demi kenyamanan tanpa mengukur biayanya di build produksi. Kenyamanan sah, tapi jelaskan apa yang Anda bayar dalam JS ekstra, CSS ekstra, dan interaksi yang lebih lambat di ponsel kelas menengah.

Akhirnya, mencampur pendekatan tanpa batasan jelas membuat aplikasi sulit di-debug. Jika setengah aplikasi menganggap update dihasilkan kompiler sementara setengah lain bergantung pada sihir runtime, Anda berakhir dengan aturan yang tidak jelas dan kegagalan yang membingungkan.

Beberapa panduan yang tahan di tim nyata:

• Tetapkan anggaran ukuran bundle per-route utama, bukan hanya untuk seluruh aplikasi.
• Putuskan rute mana yang harus cepat di muat pertama, dan desain rendering di sekitarnya.
• Tambah library hanya setelah memeriksa bobotnya di produksi.
• Tulis batasan (bagian mana yang dioptimalkan kompiler, mana yang runtime).
• Tinjau kembali keputusan setelah data pengguna nyata, bukan sebelumnya.

Contoh realistis: mengirim SaaS tanpa mengurung diri

Bayangkan tim 3 orang membangun SaaS untuk penjadwalan dan penagihan. Ia punya dua wajah: situs marketing publik (landing, harga, docs) dan dashboard otentikasi (kalender, faktur, laporan, pengaturan).

Dengan jalur runtime-first, mereka memilih setup yang berat di runtime karena membuat perubahan UI cepat. Dashboard menjadi aplikasi klien besar dengan komponen yang dapat dipakai ulang, library state, dan interaksi kaya. Iterasi cepat. Seiring waktu, muat pertama mulai terasa berat di ponsel kelas menengah.

Dengan jalur compiler-first, mereka memilih framework yang memindahkan lebih banyak kerja ke waktu build untuk mengurangi JavaScript klien. Alur umum seperti membuka dashboard, berpindah tab, dan mencari terasa lebih gesit. Trade-off-nya tim harus lebih disiplin soal pola dan tooling, dan beberapa trik runtime tidak semudah plug-and-play.

Pemicu perubahan jarang soal selera. Biasanya tekanan dari realitas: halaman yang lebih lambat merugikan signup, lebih banyak pengguna datang dari perangkat kelas rendah, pembeli enterprise minta anggaran yang dapat diprediksi, dashboard selalu terbuka jadi memori penting, atau tiket dukungan menyebut kelambanan di jaringan nyata.

Opsi hybrid sering menang. Buat halaman marketing tetap ringan (server-rendered atau sebagian besar statis, kode klien minimal) dan terima runtime yang lebih berat di dashboard di mana interaktivitas memberi manfaat jelas.

Menggunakan langkah keputusan: mereka menamai perjalanan kritis (signup, faktur pertama, laporan mingguan), mengukurnya di ponsel kelas menengah, menetapkan anggaran, dan memilih hybrid. Default compiler-first untuk halaman publik dan komponen bersama, runtime-heavy hanya di tempat yang jelas meningkatkan kecepatan eksperimen.

Daftar periksa cepat dan langkah selanjutnya untuk produk Anda

Cara termudah membuat ide-ide ini nyata adalah loop mingguan singkat.

Mulai dengan scan 15 menit: apakah ukuran bundle meningkat, rute mana yang terasa lambat, apa bagian UI terbesar di rute itu (tabel, chart, editor, peta), dan dependensi mana yang paling berkontribusi. Lalu pilih satu bottleneck yang bisa Anda perbaiki tanpa menulis ulang stack.

Untuk minggu ini, jaga kecil:

• Ukur satu baseline: cold load dari rute terlama Anda dan satu aksi umum.
• Tetapkan satu anggaran yang sesuai produk Anda.
• Perbaiki satu bottleneck (hapus dependensi, pisah route, lazy-load komponen berat, kurangi render yang tidak perlu).
• Ukur ulang dan catat apa yang berubah.

Untuk menjaga pilihan dapat dibalik, gambar batasan jelas antara route dan fitur. Pilih modul yang bisa Anda ganti nanti (chart, editor teks kaya, SDK analytics) tanpa menyentuh seluruh aplikasi.