Sejak 15 tahun yang lalu, ekosistem JavaScript telah berkembang dengan pesat, memperkenalkan banyak alat untuk memudahkan pembangunan. Tetapi alat ini memerlukan kos: mengembangkan saiz berkas. Malah, data daripada Arkib HTTP menunjukkan bahawa jumlah purata JavaScript yang dipindahkan setiap halaman telah melonjak daripada 90 KB pada 2010 kepada 650 KB pada 2024 (sumber).
Walaupun penggunaan semakin meningkat dan kemajuan dalam pemampatan, aliran ini tidak menunjukkan tanda-tanda perlahan. Sambil kami terus menambah ciri, cabarannya kekal: Bagaimanakah kami boleh menghantar lebih sedikit JavaScript?
Cukup aneh, penyelesaiannya mudah dan sukar. Bahagian yang mudah ialah tweak peringkat projek yang boleh menghasilkan kemenangan pantas. Perkara yang sukar ialah membuat impak yang berkekalan, yang memerlukan perubahan seluruh komuniti untuk menambah baik pengikat, perpustakaan dan alatan.
Artikel ini memfokuskan pada penambahbaikan yang boleh diambil tindakan untuk projek anda, meliputi:
Artikel akan datang akan menangani penambahbaikan seluruh ekosistem yang boleh kita lakukan, tetapi buat masa ini, mari kita atasi bagaimana faktor ini menyumbang kepada himpunan kembung — dan cara mengurusnya.
JavaScript ialah enjin di sebalik interaktiviti web moden, tetapi ia tidak percuma. JavaScript ialah sumber paling mahal dari segi pengiraan yang perlu dikendalikan oleh penyemak imbas anda. Selalunya kesesakan yang menentukan sama ada halaman terasa pantas atau lembap, kerana himpunan yang kembung boleh menyekat pemaparan dan merendahkan prestasi keseluruhan.
Semakin besar berkas JavaScript, semakin lama masa yang diperlukan untuk memuatkan, menghuraikan, menyusun dan menjalankan. Ini melengahkan segala-galanya — seperti memaparkan kandungan atau membenarkan pengguna berinteraksi dengan halaman tersebut. Bagi seseorang yang menggunakan komputer riba mewah dengan sambungan gentian, ini mungkin sedikit gangguan. Tetapi bagi seseorang yang menggunakan telefon berkuasa rendah atau rangkaian jerawatan, ini boleh menjadi perbezaan antara kekal atau meninggalkan tapak anda sepenuhnya.
Langkah pertama untuk mengurangkan saiz berkas JavaScript ialah menggegarkan pokok (atau "penyingkiran kod mati"), yang dilakukan oleh kebanyakan berkas di luar kotak. Tetapi adakah semua pengikat sama?
Penghimpunan dalam JavaScript telah berjalan jauh — daripada penggabungan manual dan pelari tugas kepada pengikat yang canggih. Hari ini, prestasi pengikat adalah tumpuan utama, dengan pembangun mengutamakan binaan yang lebih pantas. Walau bagaimanapun, kepantasan binaan bukanlah segala-galanya. Sama pentingnya ialah saiz berkas yang mereka hasilkan, kerana berkas yang lebih kecil diterjemahkan kepada masa pemuatan yang lebih cepat untuk pengguna.
Dalam mencari prestasi yang lebih baik, kami telah beralih daripada menulis berkas dalam JavaScript kepada bahasa seperti Rust dan Go. Suis ini memerlukan menulisnya dari awal, jadi setiap ciri dan pengoptimuman yang terdapat dalam berkas lama perlu dilaksanakan semula. Dalam jangka masa panjang, ini mungkin akan membuahkan hasil. Walau bagaimanapun, dalam jangka pendek, ini bermakna mereka kehilangan beberapa ciri yang telah bertahun-tahun dibangunkan oleh pengikat JavaScript, seperti gegaran pokok yang baik. Dan inilah ciri yang boleh membantu kami meminimumkan saiz berkas.
Sudah tentu, bercakap itu murah, jadi mari kita lihat nombor, bukan?
Mari kita bandingkan lapan perpustakaan popular dan gabungkan dengan tujuh berkas popular. Untuk memastikan keadaan adil, saya menggunakan:
Anda boleh menyemak repositori persediaan penanda aras untuk konfigurasi yang tepat.
Bundel diuji:
Perhatikan bahawa pada masa penulisan, Rolldown masih dalam alfa, jadi ia berada pada tahap yang lemah dan keputusannya mungkin akan bertambah baik dari semasa ke semasa.
Perpustakaan diuji:
Perpustakaan ini berbeza dari segi saiz dan ciri — sesetengahnya boleh berfungsi hampir seperti aplikasi kendiri.
Mari kita mulakan dengan kelajuan binaan, kerana ini adalah sesuatu yang nampaknya sangat dipedulikan oleh pembangun. Apabila menggabungkan semua perpustakaan ini bersama-sama, esbuild adalah pemenang, dengan masa binaan 192 ms. Membandingkannya dengan masa binaan paling perlahan iaitu 7.23 saat, iaitu lebih 37 kali lebih pantas.
Berdasarkan keputusan ini, kami boleh mengumpulkan pengikat kepada tiga kategori:
Perbezaan sangat ketara. Sebagai contoh, Rolldown dan Rspack adalah 11.5× dan 3.3× lebih pantas daripada rakan sejawatnya yang lebih lama, Rollup dan webpack — semuanya sambil mengekalkan keserasian ke belakang secara teori. Beralih kepada pengikat baharu ini boleh meningkatkan produktiviti dengan ketara pada projek yang lebih besar.
Berkenaan saiz output, perbezaannya tidak sedrastik masa binaan, tetapi ia tetap penting.
Apabila menggabungkan kesemua lapan perpustakaan, Vite adalah pemenang, dengan saiz output 2087 KiB. Membandingkannya dengan saiz keluaran terbesar 2576 KiB, itu melebihi 23.5% keluaran lebih kecil.
Perbezaan 23.5% dalam saiz output adalah ketara: pada sambungan 3G yang perlahan, himpunan terkecil mungkin mengambil masa sekitar 5.7s untuk dimuat turun, manakala yang terbesar lebih hampir kepada 7s. Masa penghuraian dan pelaksanaan juga berskala dengan saiz berkas, jadi perbezaan dunia sebenar boleh menjadi lebih ketara.
Berdasarkan keputusan ini, kami boleh mengumpulkan output pengikat kepada tiga kategori sekali lagi:
Hasil agregat tidak melukiskan keseluruhan gambar kerana tidak mungkin anda akan menggunakan semua perpustakaan yang disenaraikan di atas dalam projek anda. Apa yang lebih menarik ialah cara pengikat ini mengendalikan perpustakaan individu.
Untuk perpustakaan seperti chart.js dan mobx, pilihan bundler boleh menjejaskan saiz output secara mendadak, dengan perbezaan mencecah 70%. Ini menyerlahkan kepentingan menguji pengikat dengan kebergantungan khusus anda. Dalam kebanyakan kes lain, perbezaannya jauh lebih kecil, iaitu sekitar 20-30%.
Selain itu, walaupun dalam pek web agregat berakhir di tengah, ia menunjukkan prestasi terbaik dalam 6 daripada 8 kes. Walau bagaimanapun, kerana prestasinya jauh lebih teruk apabila menggabungkan boleh hubung tangan dan chart.js, ia berakhir di tempatnya. Ini bermakna, bergantung pada perpustakaan yang anda gunakan, webpack boleh menjadi pilihan yang baik.
Di bahagian lain spektrum, kami mempunyai Rolldown. Ia menunjukkan prestasi yang paling teruk dalam 7 daripada 8 kes (ingat bahawa ia masih dalam alfa).
Rspack adalah cerita yang serupa. Walaupun ia berprestasi lebih baik daripada Rolldown, ia masih menghasilkan satu berkas jauh lebih besar daripada berkas lain.
Jika anda mempertimbangkan untuk berhijrah ke berkas yang lebih baharu, ujinya dengan perpustakaan yang anda gunakan untuk melihat sama ada kelajuan binaan yang lebih pantas tidak melibatkan kos peningkatan saiz output.
Seperti yang ditunjukkan, berkas yang lebih baharu jauh lebih pantas tetapi mungkin menghasilkan berkas yang lebih besar. Apabila berhijrah daripada berkas lama, jangan hanya bandingkan masa binaan — bandingkan saiz berkas yang terhasil juga. Anda mungkin mendapati diri anda berdagang binaan lebih pantas untuk berkas yang lebih besar.
Sebagai contoh, selepas Angular bertukar daripada webpack kepada esbuild, sesetengah pembangun melaporkan bahawa saiz apl Angular kosong meningkat sekitar 20KB. Ini menyerlahkan dengan sempurna pertukaran kelajuan binaan berbanding saiz berkas.
Bukan bermaksud anda tidak perlu melihat pada kelajuan binaan kerana ia penting untuk produktiviti dan kebahagiaan pembangun. Terdapat juga korelasi antara masa binaan CI dan masa yang diperlukan untuk menggabungkan kod.
Apabila memilih bundler, lihat ciri yang disediakannya dahulu. Kemudian sasarkan untuk keseimbangan antara kelajuan binaan dan saiz berkas. Pilih berkas yang boleh menghasilkan berkas terkecil dalam masa yang anda selesa.
Uji beberapa perpustakaan perwakilan daripada projek anda. Jika kebergantungan anda membentuk sebahagian besar pangkalan kod anda, perbezaan yang anda lihat dalam penanda aras ini boleh menjadi peramal yang baik untuk situasi anda.
Seterusnya dalam senarai kami ialah pustaka luaran, yang selalunya membentuk sebahagian besar berkas JavaScript anda. Dalam banyak, jika tidak kebanyakan, aplikasi yang saya kerjakan, mereka menyumbang sebahagian besar saiz berkas. Itulah sebabnya sangat penting untuk memilih (dan menggunakannya) dengan bijak.
Ramai di antara kita telah memasang perpustakaan seperti lodash, axios atau moment hanya untuk menggunakan satu fungsi — yang membawa kepada aplikasi kembung. Perpustakaan ini hebat dan penting dari segi sejarah, tetapi apabila ia menjadi lebih popular, alternatif yang lebih ringan telah dicipta dan beberapa cirinya telah ditambahkan pada bahasa itu sendiri.
Kita boleh memanfaatkannya. Saya boleh menyenaraikan API asli atau alternatif yang lebih baru dan lebih kecil untuk perpustakaan ini, tetapi sudah terdapat banyak artikel yang merangkumi perkara itu. Dan terdapat begitu banyak perpustakaan lain sehingga mustahil untuk menampung kesemuanya.
Itulah sebabnya saya hanya akan memberi anda nasihat umum untuk melihat perpustakaan yang anda gunakan dan melihat sama ada anda boleh mengalih keluar atau menggantikannya dengan API asli atau alternatif yang lebih kecil. Tapak web ANDA MUNGKIN TIDAK PERLU * ialah sumber yang bagus untuk bermula.
Kebanyakan perpustakaan tidak dioptimumkan untuk saiz secara lalai, tetapi sesetengahnya menawarkan laluan pemasangan khas atau binaan separa. Malah antara perpustakaan dalam ujian kami, chart.js, handsontable dan ckeditor5 menawarkan cara untuk mengurangkan saiz perpustakaan dengan hanya memasukkan bahagian yang anda perlukan. Mari kita lihat ckeditor5 sebagai contoh.
Laluan pemasangan lalai menghasilkan saiz berkas antara 660 dan 800 KiB. Walau bagaimanapun, jika kami menggunakan laluan pemasangan yang dioptimumkan, saiz berkas turun kepada 603-653 KiB, dengan hanya berkas yang dihasilkan oleh Rolldown adalah sekitar 750 KiB. Ini ialah pengurangan saiz 7% hingga 23%, bergantung pada pengikat.
Perkara lain yang perlu diberi perhatian ialah kebergantungan pendua. Ini adalah masalah biasa yang mengejutkan dalam aplikasi JavaScript. Contohnya, widget benam Bluesky mempunyai dua versi pustaka pengesahan zod. Mengalih keluar pendua mengurangkan saiz berkas sebanyak ~9%.
Masalah ini biasanya tidak berlaku kerana anda menarik dua versi berbeza pustaka yang sama, tetapi kerana anda dan salah satu perpustakaan luaran bergantung pada pustaka yang sama, tetapi dalam versi yang berbeza. Ini selalunya boleh diselesaikan dengan mengemas kini perpustakaan tempat anda bergantung.
Dengan mengambil kira semua ini, akhirnya kami boleh beralih ke bahagian terakhir teka-teki — projek anda. Berikut ialah perkara yang boleh anda lakukan untuk mengecilkan berkas anda dan meningkatkan prestasi.
Langkah pertama ialah keterlihatan. Tanpa memahami kandungan dalam bungkusan anda, mengurangkan saiznya menjadi permainan meneka. Untuk ini, anda boleh menggunakan penganalisis berkas dan visualizer yang saya buat dipanggil Sonda. Ia berfungsi dengan kebanyakan berkas yang disebut di atas (kecuali Petak) dan menunjukkan dengan tepat saiz fail individu yang menyumbang kepada berkas tersebut.
Anda boleh mulakan dengan memasangnya dalam projek anda dan memeriksa bahagian berkas anda secara visual.
Setelah anda memahami dengan baik kandungan di dalam berkas dan telah mengenal pasti bahagian yang boleh dioptimumkan, anda boleh mengklik pada jubin graf untuk melihat:
Sonda juga memberi amaran kepada anda tentang kebergantungan pendua supaya anda boleh mengenal pasti dan membetulkan punca masalah dengan cepat.
Sebaik-baiknya, anda bukan sahaja perlu melakukan pemeriksaan sekali sahaja, tetapi menyediakan pemantauan berterusan sebagai sebahagian daripada saluran paip CI anda. Menjejaki perubahan dari semasa ke semasa, terutamanya dalam projek besar, boleh membantu anda menghalang perubahan kecil daripada berbola salji menjadi kembung yang ketara dari semasa ke semasa.
Kod terpantas ialah kod yang jangan hantar. Bila-bila boleh:
Jika anda tidak dapat mengalih keluar sebahagian daripada aplikasi anda, cuba pemisahan kod. Pemisahan kod membolehkan anda menangguhkan pemuatan bahagian tertentu apl anda sehingga ia diperlukan, meningkatkan masa pemuatan awal.
Gunakan import dinamik() untuk memuatkan modul atas permintaan. Contohnya, jika ciri tertentu tidak diperlukan sehingga pengguna mengklik butang, tangguhkan memuatkannya sehingga saat itu.
Rangka kerja bahagian hadapan moden menyokong pemuatan malas di luar kotak, menjadikannya lebih mudah berbanding sebelum ini untuk menyepadukan pemisahan kod ke dalam aliran kerja anda.
Ini adalah nasihat umum, tetapi ia patut diulang. Ikuti amalan terbaik, seperti:
Jika anda berminat untuk menjadikan web lebih pantas atau sekadar mempelajari perkara baharu, anda harus mempertimbangkan untuk menyertai komuniti Prestasi Ekosistem. Kami memberi tumpuan kepada tiga bidang utama:
Saya harap artikel ini menggambarkan bahawa anda boleh menghantar ciri yang sama dengan kod yang lebih sedikit. Saiz himpunan boleh berkembang di luar kawalan jika tidak diurus, tetapi walaupun perubahan kecil boleh meningkatkan prestasi dengan ketara.
Mulakan hari ini: menganalisis berkas anda, menguji alat baharu atau menggantikan perpustakaan kelas berat. Kesannya akan mengejutkan anda.
Saya harap anda menikmati artikel ini. Jika anda mempunyai sebarang soalan atau komen, atau jika anda ingin mengetahui lebih lanjut tentang topik tertentu, sila beritahu saya dalam ulasan di bawah. Jika anda ingin mengetahui lebih lanjut tentang topik prestasi JavaScript, penggabungan dan gegaran pokok, anda boleh mengikuti saya di sini atau di BlueSky dan menyertai komuniti e18e.
Atas ialah kandungan terperinci Kecilkan JavaScript anda: Menguasai Pengoptimuman Bundler. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!
![[Web front-end] Permulaan pantas Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
