Pembengkakan Ukuran JavaScript pada 2024
(tonsky.me)- Kasus ketika halaman web mengunduh JavaScript tak terkompresi yang jauh lebih besar daripada konten sebenarnya makin umum, sehingga beban browser meningkat dari landing page sederhana hingga aplikasi kerja
- Pengukuran dilakukan di Firefox on macOS dengan ekstensi dan cache dimatikan, menghitung hanya JavaScript, untuk berfokus pada biaya eksekusi kode di luar gambar, video, dan style
- Wikipedia hanya 0,2MB, tetapi halaman sederhana pun naik dari beberapa MB hingga belasan MB, seperti Linear 3MB, Zoom·Vercel 6MB, dan GitLab 13MB
- Di area aplikasi, Gmail 20MB dan FastMail 2MB menunjukkan selisih 10 kali lipat, sementara jumlah kode alat chat dan kerja sangat besar, seperti Jira sekitar 50MB dan Slack 55MB
- Setelah diunduh, JavaScript juga menimbulkan biaya parsing, penyimpanan di memori, dan eksekusi, sehingga struktur yang membutuhkan bundle kode raksasa untuk merender konten kecil menjadi beban langsung bagi performa dan baterai
Metode pengukuran dan tolok ukur perbandingan
- Lingkungan pengukuran adalah Firefox on macOS, dengan asumsi hasilnya secara umum akan mirip meski browser berbeda
- Kondisinya sebagai berikut
- Mode biasa, bukan mode incognito
- Semua ekstensi dinonaktifkan
- Mengukur hanya JavaScript
- Berdasarkan ukuran tak terkompresi
- Service Worker aktif
- Cold load dengan cache dinonaktifkan
- Konten dikeluarkan dari perbandingan karena variasinya besar antar-situs
- Video YouTube dan pesan teks Slack pada dasarnya berbeda ukurannya
- JavaScript digunakan sebagai metrik umum untuk membandingkan kompleksitas interaksi
- Intinya adalah beban kerja yang harus ditanggung browser untuk mem-parsing dan mengeksekusi kode
- Sebagai titik acuan, blog tonsky.me sendiri terukur 0,004MB
Landing page dan konten statis
- Dalam contoh halaman umum dengan sedikit interaksi, Wikipedia berada di kisaran 0,2MB
- Landing page yang lebih berat adalah sebagai berikut
- Linear: 3MB
- Zoom: 6MB
- Vercel: 6MB
- GitLab: 13MB
- Angka di atas adalah ukuran kode JavaScript saja, tidak termasuk gambar, video, dan style
- Situs web yang menampilkan teks statis pun mengunduh beberapa MB JavaScript
- Medium: 3MB
- Substack: 4MB
- Quora: 4,5MB
- Pinterest: 10MB
- Patreon: 11MB
- Ada kasus ketika bundle JavaScript besar dipakai untuk tugas menampilkan konten yang tampaknya bisa dilakukan sebagai halaman statis
Pencarian dan aplikasi dengan interaksi sederhana
- Aplikasi berfokus pencarian terutama berisi input kueri dan tampilan daftar hasil, tetapi ukuran JavaScript-nya tidak kecil
- StackOverflow: 3,5MB
- NPM: 4MB
- Airbnb: 7MB
- Booking.com: 12MB
- Google Search terukur 9MB meski layarnya berpusat pada kolom teks dan daftar tautan
- Layanan dengan UI input sederhana pun menggunakan beberapa MB JavaScript
- Google Translate: 2,5MB
- ChatGPT: 7MB
- Terlepas dari fakta bahwa kompleksitas ChatGPT berada di sisi server, browser tetap menerima 7MB JavaScript
Layanan media dan email
- Ukuran JavaScript layanan video adalah sebagai berikut
- Loom: 7MB
- YouTube: 12MB
- Pornhub: 1,4MB
- Pada layanan audio, SoundCloud dan Spotify masing-masing terukur sekitar 12MB
- Pada layanan email, selisihnya sangat besar
- Google Mail: 20MB
- FastMail: 2MB
- FastMail menggunakan JavaScript 10 kali lebih sedikit daripada Google Mail dalam kategori layanan email yang sama
- Angka 20MB milik Google Mail cukup besar hingga dapat dibandingkan dengan aplikasi seperti Figma yang mencakup rendering kustom C++/OpenGL
Alat produktivitas dan pengeditan dokumen
- Aplikasi produktivitas juga memiliki JavaScript yang besar dibandingkan tugas sederhananya
- Todoist: 9MB
- Dropbox: 10MB
- 1Password: 13MB
- Trello: 13,5MB
- Discord: 21MB
- Dropbox menggunakan lebih dari 10MB untuk daftar file dalam folder, 1Password untuk daftar kata sandi, dan Trello untuk menampilkan kartu
- Layanan pengeditan dokumen berada di kisaran belasan MB
- Google Docs: 13,5MB
- Notion: 16MB
- Pengeditan dokumen memang memiliki fitur sulit seperti pergerakan kursor dan sinkronisasi, tetapi ukuran JavaScript layanan-layanan pembanding tetap besar
Jejaring sosial dan kasus sangat besar
- Jejaring sosial umumnya menggunakan JavaScript sekitar 12MB untuk like, feed, messaging, dan sebagainya
- Twitter: 11MB
- Facebook: 12MB
- TikTok: 12,5MB
- Instagram: 16MB
- LinkedIn: 31MB
- LinkedIn mencakup blog, platform, pencarian, messaging, dan fitur sosial, dan terukur 31MB
- Contoh web app yang sangat besar nyaris menjadi kategori tersendiri
- Jira: hampir 50MB
- Slack: 55MB
- Slack adalah aplikasi chat yang menangani daftar pengguna, pesan, dan reaksi, tetapi mengunduh 55MB JavaScript
- react.dev awalnya dimulai dari 2MB, tetapi teramati bahwa JavaScript terus bertambah jika scrolling dilakukan berulang kali
- Sebagai contoh, ukurannya bisa dinaikkan hingga 100MB
- Menurut pembaruan, dalam pengalaman pengguna umum, editor kode tertanam disimpan di cache setelah load pertama sehingga traffic jaringan berikutnya tidak terlihat
- Namun saat scrolling, 100MB JavaScript dapat terus di-parse, dievaluasi, dan diinisialisasi
Makna kode 10MB
- Pada 2015, ukuran rata-rata halaman web sedang mendekati 2,5MB milik versi shareware Doom 1
- Pada 2024, Slack mencapai 55MB, ukuran seluruh resource Quake 1 asli, hanya dari JavaScript
- Kode 10MB mungkin terlihat seperti level yang umum, tetapi jika satu baris kode rata-rata diasumsikan 65 karakter, itu setara dengan sekitar 150 ribu baris
- Kode ini sudah dalam kondisi di-minify, sehingga berdasarkan kode sumber aslinya bisa mencapai lebih dari 300 ribu baris
- Google Maps sering disebut sebagai contoh utama SPA, tetapi terukur 4,5MB, sehingga dibandingkan standar web app modern justru termasuk kecil
- Figma adalah aplikasi frontend kompleks sehingga wajar jika ukuran unduhan JavaScript-nya besar, tetapi Gmail mirip dengan Figma, LinkedIn 1,5 kali lipat, dan Slack 2,5 kali lipat
Biaya yang dibayar browser
- Masalahnya tidak berhenti pada ukuran unduhan
- JavaScript harus di-parse, dipertahankan di memori, dan dieksekusi oleh browser, sehingga menimbulkan biaya berkelanjutan
- Jika dilihat dari kriteria bahwa ukuran konten seharusnya lebih besar daripada ukuran kode, struktur yang membutuhkan JavaScript 1000 kali lebih besar untuk merender artikel blog 10K karakter adalah berlebihan
- Situs yang disebut sebagai contoh baik dapat berjalan cukup dengan JavaScript 0,1MB
- Dalam lingkungan web yang sama, GitLab dibandingkan sebagai kasus yang membutuhkan 13MB, atau lebih dari sekitar 500 ribu baris JavaScript, untuk menampilkan landing page statis
1 komentar
Opini Hacker News
Bandingkan saja hal-hal seperti 10MB, 12MB dengan Pornhub 1,4MB yang benar-benar memperhatikan performa
Situs porno selalu menjadi high-tech web yang nyata, dan rekayasanya juga bagus, berbeda dari perusahaan raksasa “tech” yang seperti lelucon
Hampir tidak ingat mereka pernah merusak UI/UX dasar, pengiriman konten, atau desain yang masuk akal
Rasanya, hanya karena refresh halaman adalah perilaku yang tidak diinginkan pada aplikasi web sungguhan, tiba-tiba semua orang jadi takut dengan refresh halaman di situs web
Saya sudah 20 tahun menangani aplikasi enterprise, dan juga melihat sistem yang dibuat sebelum saya lahir; menurut saya React adalah frontend terbaik untuk menggantikan UI client/server lama yang mengerikan pada sistem-sistem seperti itu
Angular/Vue dan lainnya juga berada dalam konteks yang sama. Namun untuk halaman web biasa, hampir tidak diperlukan kecuali interaksi dan pembaruan real-time merupakan inti produk seperti Gmail atau Facebook
Untuk tempat seperti Pornhub, PHP pun sudah cukup, dan begitu juga sebagian besar situs web. Lihat saja banyaknya orang yang masih lebih suka HN atau old.reddit.com; saya rasa banyak juga yang akan lebih menyukai old.Facebook daripada Facebook baru yang makin lambat
Seperti popup, popunder, mengirim pengguna ke situs agregator serupa dengan konten palsu, membuka situs afiliasi alih-alih konten, dan mencemari hasil pencarian
Porno bukanlah industri yang mendorong teknologi sejauh yang sering dikatakan orang, legenda urban terkait Betamax vs VHS juga tidak benar, dan klaim bahwa mereka memimpin inovasi internet juga berlebihan
Ada beberapa pemain yang membuat produk berkualitas tinggi, tetapi itu tidak mewakili seluruh industri. Banyak link farm, konten dummy, situs kloning, iklan menyesatkan, dan manipulasi hasil pencarian
Situs-situs teratas sekarang terasa responsif sepertinya karena hasil persaingan. Kalau UX buruk, karena porno gratis berlimpah, pengguna langsung pindah ke tempat lain, jadi mereka harus mengoptimalkan retensi
Situs web lain punya insentif berbeda seperti pemegang saham, penyedia konten, kontrak eksklusif, dan posisi monopoli, sehingga tidak perlu mengoptimalkan pengalaman pengguna sejauh itu
Waktu yang tak terhitung banyaknya dihabiskan untuk mengoptimalkan segala hal, seperti pengiriman video, siaran langsung (dulu Flash, sekarang WebRTC), ukuran halaman, dan sebagainya
Saya penasaran kenapa yang dilihat adalah data sebelum kompresi. Beberapa situs yang dijadikan contoh buruk pun jika dikompresi dengan mudah menjadi lebih kecil daripada 1,5MB milik GMaps
Untuk aplikasi dinamis seperti Spotify atau GMail, menurut saya tidak masalah jika navigasi setelah page load cepat
Discord yang butuh beberapa detik untuk update saat start lebih baik daripada GitLab yang membuat kita menunggu hingga 2 detik setiap kali mengklik
Menurut saya prioritas cold start dan static rendering belakangan ini justru merusak pengalaman di sebagian situs
Sebagai eksperimen, coba telusuri file tree di GitHub; di perangkat saya, bagian itu jauh lebih responsif daripada bagian GitHub lainnya. Kebetulan, bagian ini adalah salah satu dari sangat sedikit bagian yang tidak di-render secara statis
Saya mengklik ratusan halaman GitHub setiap hari, dan daripada setiap kali harus mengunduh ulang seluruh footer hanya untuk melihat satu pipeline, saya lebih suka mereka mengirim JavaScript dalam jumlah besar sekali lalu men-cache sebanyak mungkin
[1]: GMail dan Spotify hanya contoh, saya tidak benar-benar memakainya
Masalah ini sering muncul dalam pembahasan keterjangkauan akses; kesenjangan performa CPU antara iOS dan Android besar, dan jika melihat perangkat kelas bawah yang banyak dipakai masyarakat, ada perangkat Android baru yang dijual hari ini pun yang lebih lambat daripada iPhone tahun 2014
Jika developer hanya memakai iPhone terbaru atau Android flagship, mudah sekali melewatkan seberapa besar dampak pembengkakan kode terhadap pengguna menengah
https://infrequently.org/2024/01/performance-inequality-gap-...
Caching memang mengurangi biaya daya dan waktu untuk download serta dekompresi, tetapi tidak menghilangkan biaya penggunaan sebenarnya
Sebagai aturan praktis pribadi, semakin besar JavaScript sebelum kompresi, semakin banyak kode yang terus dijalankan CPU saat menggerakkan mouse, menekan tombol, atau menggulir
Lebih baik mengorbankan sedikit efisiensi waktu untuk mendapatkan efisiensi daya, dan di tempat yang bisa digantikan dengan CSS, saya lebih memilih yang statis daripada perilaku yang cantik
Atau mungkin masalah yang benar-benar lebih besar adalah situs yang mengunduh file tambahan untuk berbagai tindakan selain klik yang memindahkan URL ke halaman lain. Ini adalah pembengkakan tersembunyi dan juga sangat buruk untuk pengarsipan
Saya berharap mereka tidak membuat JavaScript menampilkan “halaman” lain sementara URL di address bar tetap sama. Ini juga sangat buruk untuk pengarsipan
Aturan praktis lain: semakin besar JavaScript sebelum kompresi, semakin kecil kemungkinan versi situs yang diarsipkan dapat berfungsi dengan benar
Minggu lalu internet saya lambat, dan saat mengklik file di situs web GitHub, file tree benar-benar tidak berfungsi karena mencoba memuatnya lewat script lalu gagal
Sebaliknya, jika menyalin URL file dan menempelkannya ke address bar browser, file itu dimuat dengan benar
Spotify punya masalah besar pada konektivitas jaringan. Bahkan setelah mengunduh album, jika jaringan berubah, ia benar-benar panik. Lebih baik mode offline saja daripada terus mencoba tetap online
Sulit menilai seluruh arsitektur itu hanya dari sana; ini mirip dengan menunjuk satu SPA yang sangat buruk lalu mengatakan semua SPA buruk
Semua perangkat lunak mencerminkan wujud organisasi yang membuatnya
Sebagian besar data yang dikirim kemungkinan besar bukan JavaScript yang benar-benar diperlukan untuk perilaku halaman, melainkan alat analitik dan berbagai skrip pihak ketiga
Hanya kategori “elephant” yang termasuk modul lazy loading seperti React
Banyak dari hal seperti ini didorong oleh tim pemasaran yang tidak tahu atau tidak peduli dengan masalah ini
Sering kali developer hanya menempelkan Google Tag Manager atau layanan penyisip skrip lain ke halaman. Dalam beberapa kasus, developer bahkan tidak melakukan itu; proxy di infrastruktur operasi yang memodifikasi halaman
Kekhawatiran yang lebih bermakna mungkin adalah bahwa pemasaran punya kendali lebih besar atas hasil akhir daripada orang-orang yang benar-benar mengerjakan pekerjaannya
Dalam kasus halaman “elephant”, pembengkakannya ada pada organisasi itu sendiri. Ini bukan masalah beberapa orang bodoh, melainkan kebodohan yang diskalakan
Di tempat kerja sebelumnya, departemen nonteknis yang memegang Google Tag Manager, dan kami harus terus mengawasi sampah yang disuntikkan ke halaman produksi
Saya benar-benar berjuang keras untuk menghapusnya
Google Search seperti itu dibanding Yahoo, dan Chrome juga begitu dibanding IE/Firefox saat diluncurkan
Chrome sendiri hampir tidak punya UI, dan itu adalah fiturnya
Saya baru saja kembali dari road trip di Selandia Baru, dan di banyak wilayah pedesaan sinyal ponsel sangat lemah atau tidak ada sama sekali
Jika ditambah roaming, rasanya ada satu lapisan tambahan yang membuat semuanya lebih lambat, sehingga menggunakan banyak bagian web benar-benar sulit
Kalau ada PM Spotify, saya harap mereka meninjau UX offline. Offline adalah salah satu fitur inti premium, tetapi ketika benar-benar mencoba memakai aplikasinya secara offline, dalam banyak hal pengalamannya sangat buruk
Jika Spotify menganggap ada internet, ia menanyakan seluruh isi menu konteks ke server, menunggu respons selama beberapa detik, lalu kadang menyerah menampilkan menu dan kadang kembali ke tindakan yang akan langsung terjadi jika dalam mode offline
Saya benar-benar benci pemutar ini
Dalam kondisi tengah dengan latensi sangat tinggi atau banyak packet loss, seharusnya ia berperilaku seperti offline, tetapi Spotify menganggapnya online
Namun masalah seperti ini sangat umum dan bukan hanya Spotify yang gagal; menentukan ambang batas yang tepat memang mungkin sulit
Saya tidak mengerti mengapa Spotify membuat aplikasi menunggu 30 detik untuk memuat sesuatu saat tidak ada sinyal. Saya hanya ingin terus mendengarkan podcast yang sudah saya unduh
Saya penasaran keputusan rekayasa seperti apa yang membuat pembobotan skenario seperti ini menjadi begitu rumit
Tulisan ini terutama benar-benar melewatkan fakta bahwa ia tidak membongkar mengapa file JavaScript pada aplikasi web nyata bisa sebesar itu
Misalnya, jika dilihat lebih rinci, Google Translate bukan aplikasi yang hanya berinteraksi sekali lalu selesai. Ada kamus, saran alternatif, transliterasi, pelafalan, berbagai metode input, dan sebagainya
Meski mempertimbangkan hal-hal itu, 2,5MB tetap terlalu besar, dan menurut saya beberapa fitur opsional bisa dan seharusnya dimuat secara lazy loading, tetapi tulisan ini terlalu malas sehingga tidak banyak membantu diskusi yang lebih dalam
Seberapa banyak JavaScript yang diperlukan untuk
if data.transliteration show icon with audio embed?Bisa dimengerti karena gambarnya mungkin besar dan banyak, tetapi agak ironis
Saya paham implikasi di sini adalah “JavaScript terlalu banyak”, tetapi kita juga perlu membahas seberapa banyak dari ini yang merupakan sampah pelacakan murni
Yang lebih buruk, sebagian diambil dari luar dan tidak dibundel dengan kode host, sehingga menambah latensi dan potensi risiko keamanan
Itu adalah alat yang memungkinkan marketer menyuntikkan sampah apa pun ke aplikasi web tanpa campur tangan developer
Hubungan juga agak rusak, saya tidak menang, dan performanya tetap buruk
Penyebab masalah performa berikutnya adalah pustaka berat seperti peta dan chart, dan biasanya bisa diselesaikan dengan lazy loading yang cerdas
Dari yang pernah saya alami langsung: ada fitur sangat kecil yang tetap memuat pustaka pemindai kode QR dan pustaka peta saat startup; semua string internasionalisasi diminta secara waterfall saat startup sehingga terblokir sebelum JS apa pun bisa berjalan; Zendesk benar-benar merusak performa halaman, tetapi karena perintah atasan, yang bisa dilakukan hanya menambahkan lazy load
Berikutnya adalah kode yang dirancang buruk yang memicu terlalu banyak elemen DOM, re-render, atau permintaan waterfall
Terakhir baru ukuran kode tingkat aplikasi, dan ini juga bisa diperbaiki dengan lazy loading, tetapi biasanya tidak diperlukan sebelum aplikasinya menjadi sangat besar
Misalnya, landing page GitLab turun dari 13MB menjadi “hanya” 6MB setelah skrip pelacakan diblokir
Departemen pemasaran akan selalu menggandakan pembengkakan perangkat lunak
Ini membandingkan seberapa banyak JavaScript yang dimuat situs-situs populer saat cold load. Poin utamanya sebagai berikut
PornHub memuat JS sekitar 10 kali lebih sedikit daripada YouTube (1,4 MB vs 12 MB)
Gmail memiliki footprint yang sulit dipahami besarnya (20 MB). Fastmail 10 kali lebih ringan di 2 MB, sementara Figma, meski aplikasinya lebih kompleks, mirip di 20 MB
Jira 58 MB, itu luar biasa besar
Jira, setelah sekali diunduh, kemungkinan akan dimuat secara lokal seperti aplikasi offline sampai ada pembaruan
Pornhub kemungkinan besar dijalankan dalam mode incognito, jadi cache tidak banyak membantu
Jira juga buruk dan lambat
Semua halaman di https://wordsandbuttons.online/ tetap di bawah 64 KB meski memiliki animasi dan interaksi
Misalnya halaman ini https://wordsandbuttons.online/trippy_polynomials_in_arctang... berukuran 51 KB
Kodenya juga sama sekali tidak hemat. 80% adalah salin-tempel dengan sedikit perbedaan, tanpa upaya cerdas untuk memperkecilnya. Semuanya vanilla JS lama, tanpa kompresi maupun penghapusan spasi
Kalau dibuka dengan “View page source”, kodenya sepenuhnya masih terbaca
Rahasianya adalah kebijakan nol dependensi. Tidak ada pihak ketiga maupun dependensi internal. Semua kode yang dibutuhkan diambil bersama file HTML
Secara paradoks, dalam jangka panjang salin-tempel bukan penyebab bloat, melainkan pencegahnya
Di mobile, bagian tepinya benar-benar tidak terlihat
Dependensi itu sendiri bukan penyebab, melainkan gejala. Karena situs web dan perusahaan tidak lagi punya insentif untuk mengurangi bloat, dependensi yang duplikatif hampir tidak pernah dibereskan
Saya teringat artikel The Website Obesity Crisis dari 2015 [1]. Sejak itu [2] situasinya makin buruk, dan hampir 10 tahun sudah berlalu
Apakah bodoh kalau mengatakan bahwa 10 tahun lagi, menjelajah web dengan PC sekitar tahun 2015 akan menjadi mustahil? Jika tidak ada yang berubah, tampaknya begitu
Bahkan MacBook lama keluaran 2013 dengan Firefox terbaru tidak mampu menangani 23,98 MB JavaScript di halaman https://civitai.com, dan macet sekitar 30 detik saat mencoba merender frontend web yang kacau ini
Ini bukan hanya masalah web. Aplikasi all-in-one mobile juga sudah terlalu besar sehingga ponsel 2013 pun tidak bisa memuatnya, dan separuhnya ditulis di atas stack teknologi web
Saya tidak tahu mengapa perusahaan beranggaran besar tidak mampu memakai aplikasi native
[1] https://idlewords.com/talks/website_obesity.htm
[2] https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
Kondisi web sangat menyedihkan
Kebanyakan orang yang memakai koneksi fiber bahkan tidak merasakan betapa lambatnya web sekarang
Tetapi jika masih berada di koneksi 2 Mbps, rasanya benar-benar mengerikan. Saya berada dalam situasi itu, dan menyakitkan
Karena itu, tidak memakai pemblokir iklan/pelacak sama sekali bukan opsi
Saya ingin melihat tes ini dengan Ublock Origin aktif
Sepertinya sebagian besar kode ini untuk pelacakan pengguna dan pengelolaan iklan
Saya tidak mengerti apakah maksudnya, meski kita sudah punya komputer dan kecepatan jaringan yang lebih baik dan lebih cepat, kita harus tetap berfokus membuat aplikasi dan situs web semakin kecil
Berkat Hukum Moore, developer bisa mengorbankan optimalitas, mendorong lebih banyak hal, dan bergerak cepat; ini sering terjadi