Tidak ada cara yang lebih cepat untuk memperlambat situs web (permainan kata-kata) selain menggunakan banyak kode JavaScript di dalamnya. Saat menggunakan JavaScript, Anda harus membayarnya dengan kinerja proyek tidak kurang dari empat kali lipat. Inilah cara kode JavaScript situs memuat sistem pengguna:
- Mengunduh file melalui jaringan.
- Mem-parsing dan mengkompilasi kode sumber yang belum dibuka setelah diunduh.
- Eksekusi kode JavaScript.
- Konsumsi memori.
Kombinasi ini ternyata .
Dan kami menyertakan lebih banyak kode JS dalam proyek kami. Saat organisasi beralih ke situs yang diberdayakan oleh kerangka kerja dan pustaka seperti React, Vue, dan lainnya, kami membuat fungsionalitas inti situs sangat bergantung pada JavaScript.
Saya telah melihat banyak situs yang sangat berat menggunakan framework JavaScript. Tapi visi saya tentang masalah ini sangat bias. Faktanya adalah perusahaan tempat saya bekerja berpaling kepada saya justru karena mereka dihadapkan pada masalah yang kompleks di bidang kinerja situs. Akibatnya, saya menjadi penasaran tentang seberapa umum masalah ini, dan tentang "hukuman" seperti apa yang kami bayarkan ketika kami memilih satu atau beberapa kerangka kerja sebagai dasar untuk situs tertentu.
Proyek ini membantu saya mencari tahu. .
Data
Proyek Arsip HTTP melacak total 4308655 tautan ke situs desktop biasa dan 5484239 tautan ke situs seluler. Di antara banyak metrik yang terkait dengan tautan ini adalah daftar teknologi yang ditemukan di situs masing-masing. Artinya, kami dapat mengambil sampel ribuan situs yang menggunakan berbagai kerangka kerja dan pustaka serta mempelajari tentang berapa banyak kode yang mereka kirim ke klien dan berapa banyak beban yang dibuat kode ini pada sistem pengguna.
Saya mengumpulkan data bulan Maret 2020, yang merupakan data terbaru yang dapat saya akses.
Saya memutuskan untuk membandingkan data Arsip HTTP agregat di semua situs dengan data dari situs yang ditemukan menggunakan React, Vue, dan Angular, meskipun saya juga mempertimbangkan untuk menggunakan materi sumber lain.
Agar lebih menarik, saya juga menambahkan situs yang menggunakan jQuery ke kumpulan data sumber. Perpustakaan ini masih sangat populer. Itu juga memperkenalkan pendekatan yang berbeda untuk pengembangan web dari model Single Page Application (SPA) yang ditawarkan oleh React, Vue dan Angular.
Tautan di Arsip HTTP mewakili situs yang ditemukan menggunakan teknologi yang menarik
Framework atau perpustakaan
Tautan ke situs seluler
Tautan ke situs biasa
jQuery
4615474
3714643
Bereaksi
489827
241023
Pandangan
85649
43691
Kaku
19423
18088
Harapan dan impian
Sebelum kita beralih ke analisis data, saya ingin berbicara tentang apa yang ingin saya harapkan.
Saya percaya bahwa di dunia yang ideal, kerangka kerja harus lebih dari sekadar memenuhi kebutuhan pengembang dan memberikan beberapa manfaat khusus bagi rata-rata pengguna yang bekerja dengan situs kami. Performa hanyalah salah satu manfaat itu. Di sinilah aksesibilitas dan keamanan berperan. Tapi ini hanya yang paling penting.
Jadi, di dunia yang ideal, beberapa jenis kerangka kerja harus memudahkan pembuatan situs berkinerja tinggi. Ini harus dilakukan karena fakta bahwa kerangka kerja memberi pengembang basis yang layak untuk membangun proyek, atau karena fakta bahwa kerangka itu memberlakukan pembatasan pada pengembangan, mengajukan persyaratan yang mempersulit pengembangan sesuatu yang mengubah keluar menjadi lambat.
Kerangka kerja terbaik harus melakukan keduanya: memberikan dasar yang baik, dan memberlakukan batasan pada pekerjaan, memungkinkan Anda mencapai hasil yang layak.
Menganalisis nilai median data tidak akan memberi kita informasi yang kita butuhkan. Dan, nyatanya, pendekatan ini luput dari perhatian kita . Sebaliknya, saya memperoleh persentase dari data yang saya miliki. Ini adalah persentil 10, 25, 50 (median), 75, 90.
Saya sangat tertarik pada persentil ke-10 dan ke-90. Persentil ke-10 mewakili kinerja terbaik (atau setidaknya mendekati yang terbaik) untuk kerangka kerja tertentu. Dengan kata lain, ini berarti bahwa hanya 10% situs yang menggunakan framework tertentu yang berhasil mencapai level ini, atau lebih tinggi. Persentil ke-90, di sisi lain, adalah sisi lain dari koin - ini menunjukkan kepada kita betapa buruknya hal-hal yang bisa terjadi. Persentil ke-90 adalah situs yang berada di belakangβ10% situs terbawah yang memiliki kode JS terbanyak atau waktu terlama untuk memproses kodenya di utas utama.
Volume kode JavaScript
Pertama-tama, masuk akal untuk menganalisis ukuran kode JavaScript yang dikirimkan oleh berbagai situs melalui jaringan.
Jumlah kode JavaScript (Kb) yang ditransfer ke perangkat seluler
Persentil
10
25
50
75
90
Semua situs
93.4
196.6
413.5
746.8
1201.6
situs jQuery
110.3
219.8
430.4
748.6
1162.3
situs Vue
244.7
409.3
692.1
1065.5
1570.7
Situs sudut
445.1
675.6
1066.4
1761.5
2893.2
Bereaksi Situs
345.8
441.6
690.3
1238.5
1893.6
Jumlah kode JavaScript yang dikirim ke perangkat seluler
Jumlah kode JavaScript (Kb) yang ditransfer ke perangkat desktop
Persentil
10
25
50
75
90
Semua situs
105.5
226.6
450.4
808.8
1267.3
situs jQuery
121.7
242.2
458.3
803.4
1235.3
situs Vue
248.0
420.1
718.0
1122.5
1643.1
Situs sudut
468.8
716.9
1144.2
1930.0
3283.1
Bereaksi Situs
308.6
469.0
841.9
1472.2
2197.8
Jumlah kode JavaScript yang dikirim ke perangkat desktop
Jika kita hanya berbicara tentang ukuran kode JS yang dikirimkan situs ke perangkat, maka semuanya terlihat seperti yang Anda harapkan. Yakni, jika salah satu framework digunakan, ini berarti bahkan dalam situasi yang ideal, volume kode JavaScript situs akan meningkat. Ini tidak mengherankan - Anda tidak dapat menjadikan kerangka kerja JavaScript sebagai dasar situs dan berharap volume kode JS proyek akan sangat rendah.
Apa yang luar biasa tentang data ini adalah bahwa beberapa kerangka kerja dan perpustakaan dapat dianggap sebagai titik awal yang lebih baik untuk sebuah proyek daripada yang lain. Situs dengan jQuery terlihat terbaik. Pada situs versi desktop, mereka mengandung JavaScript 15% lebih banyak daripada semua situs, dan pada seluler mengandung 18% lebih banyak. (Diakui, ada beberapa kerusakan data di sini. Faktanya adalah jQuery ada di banyak situs, jadi wajar saja jika situs semacam itu terkait lebih erat daripada yang lain dengan jumlah total situs. Namun, ini tidak memengaruhi seberapa mentah data adalah keluaran untuk setiap kerangka kerja.)
Sementara peningkatan volume kode sebesar 15-18% adalah angka yang patut dicatat, membandingkannya dengan framework dan library lain, orang dapat menyimpulkan bahwa βpajakβ yang dikenakan oleh jQuery sangat rendah. Situs Angular di persentil ke-10 mengirim 344% lebih banyak data ke desktop daripada semua situs, dan 377% lebih banyak ke seluler. Bereaksi situs adalah yang terberat berikutnya, mengirim kode 193% lebih banyak ke desktop daripada semua situs, dan 270% lebih banyak ke seluler.
Sebelumnya, saya menyebutkan bahwa meskipun menggunakan kerangka kerja berarti sejumlah kode tertentu akan dimasukkan ke dalam proyek, pada awal pengerjaannya, saya berharap kerangka kerja tersebut dapat membatasi pengembang. Secara khusus, kita berbicara tentang membatasi jumlah maksimum kode.
Menariknya, situs jQuery mengikuti ide ini. Meskipun sedikit lebih berat dari semua situs pada persentil ke-10 (sebesar 15-18%), situs tersebut sedikit lebih ringan pada persentil ke-90 sekitar 3% di desktop dan seluler. Ini bukan untuk mengatakan bahwa ini adalah manfaat yang sangat signifikan, tetapi dapat dikatakan bahwa situs jQuery, setidaknya, tidak memiliki ukuran kode JavaScript yang besar, bahkan dalam versi terbesarnya.
Tetapi hal yang sama tidak dapat dikatakan tentang kerangka kerja lain.
Sama seperti dalam kasus persentil ke-10, pada persentil ke-90 situs di Angular dan React berbeda dari situs lain, tetapi sayangnya, mereka berbeda menjadi lebih buruk.
Pada persentil ke-90, situs Angular mengirim 141% lebih banyak data ke seluler daripada semua situs, dan 159% lebih banyak ke desktop. Bereaksi situs mengirim 73% lebih banyak ke desktop daripada semua situs, dan 58% lebih banyak ke seluler. Ukuran kode situs React pada persentil ke-90 adalah 2197.8 KB. Ini berarti bahwa situs tersebut mengirim 322.9 KB lebih banyak data ke perangkat seluler daripada pesaing terdekat mereka berdasarkan Vue. Kesenjangan antara situs desktop berbasis Angular dan React dan situs lain bahkan lebih besar. Misalnya, situs React desktop mengirim kode JS 554.7 KB lebih banyak ke perangkat daripada situs Vue yang setara.
Waktu yang dibutuhkan untuk memproses kode JavaScript di utas utama
Data di atas dengan jelas menunjukkan bahwa situs yang menggunakan kerangka kerja dan pustaka yang diteliti mengandung banyak kode JavaScript. Tapi tentu saja, itu hanya satu bagian dari persamaan kita.
Setelah kode JavaScript tiba di browser, kode tersebut harus dibawa ke status yang bisa diterapkan. Terutama banyak masalah yang disebabkan oleh tindakan yang harus dilakukan dengan kode di utas browser utama. Utas utama bertanggung jawab untuk memproses tindakan pengguna, untuk menghitung gaya, untuk membangun dan menampilkan tata letak halaman. Jika Anda membanjiri utas utama dengan tugas JavaScript, utas tidak akan memiliki kesempatan untuk menyelesaikan tugas lainnya tepat waktu. Hal ini menyebabkan penundaan dan "rem" dalam pekerjaan halaman.
Basis data Arsip HTTP memiliki informasi tentang berapa lama waktu yang diperlukan untuk memproses kode JavaScript di utas utama mesin V8. Artinya, kami dapat mengumpulkan data ini dan mencari tahu berapa banyak waktu yang dibutuhkan utas utama untuk memproses JavaScript dari berbagai situs.
Waktu pemroses (dalam milidetik) terkait dengan pemrosesan skrip di perangkat seluler
Persentil
10
25
50
75
90
Semua situs
356.4
959.7
2372.1
5367.3
10485.8
situs jQuery
575.3
1147.4
2555.9
5511.0
10349.4
situs Vue
1130.0
2087.9
4100.4
7676.1
12849.4
Situs sudut
1471.3
2380.1
4118.6
7450.8
13296.4
Bereaksi Situs
2700.1
5090.3
9287.6
14509.6
20813.3
Waktu pemroses terkait pemrosesan skrip di perangkat seluler
Waktu CPU (dalam milidetik) terkait dengan pemrosesan skrip di perangkat desktop
Persentil
10
25
50
75
90
Semua situs
146.0
351.8
831.0
1739.8
3236.8
situs jQuery
199.6
399.2
877.5
1779.9
3215.5
situs Vue
350.4
650.8
1280.7
2388.5
4010.8
Situs sudut
482.2
777.9
1365.5
2400.6
4171.8
Bereaksi Situs
508.0
1045.6
2121.1
4235.1
7444.3
Waktu pemroses yang terkait dengan pemrosesan skrip di perangkat desktop
Di sini Anda dapat melihat sesuatu yang sangat akrab.
Sebagai permulaan, situs dengan jQuery menghabiskan lebih sedikit untuk pemrosesan JavaScript di utas utama daripada situs lain. Pada persentil ke-10, dibandingkan dengan semua situs, situs jQuery di seluler menghabiskan 61% lebih banyak waktu untuk memproses kode JS di thread utama. Dalam kasus situs jQuery desktop, waktu pemrosesan meningkat sebesar 37%. Pada persentil ke-90, skor situs jQuery sangat dekat dengan skor agregat. Secara khusus, situs jQuery di perangkat seluler menghabiskan 1.3% lebih sedikit waktu di utas utama daripada semua situs, dan 0.7% lebih sedikit waktu di perangkat desktop.
Di sisi lain peringkat kami adalah kerangka kerja yang dicirikan oleh beban tertinggi di utas utama. Ini, sekali lagi, Sudut dan Bereaksi. Satu-satunya perbedaan antara keduanya adalah bahwa sementara situs Angular mengirim lebih banyak kode ke browser daripada situs Bereaksi, situs Angular membutuhkan lebih sedikit waktu CPU untuk memproses kode. Jauh lebih sedikit.
Pada persentil ke-10, situs Angular desktop menghabiskan 230% lebih banyak waktu di utas utama yang memproses kode JS daripada semua situs. Untuk situs seluler, angkanya adalah 313%. Bereaksi situs adalah yang berkinerja terburuk. Di desktop, mereka menghabiskan 248% lebih banyak waktu untuk memproses kode daripada semua situs, dan 658% lebih banyak di seluler. 658% bukan salah ketik. Pada persentil ke-10, situs React menghabiskan waktu thread utama 2.7 detik untuk memproses kode mereka.
Persentil ke-90, jika dibandingkan dengan angka-angka besar ini, setidaknya terlihat sedikit lebih baik. Dibandingkan dengan semua situs, proyek Angular menghabiskan 29% lebih banyak waktu di perangkat desktop di utas utama, dan 27% lebih banyak di perangkat seluler. Dalam kasus situs React, angka yang sama masing-masing terlihat seperti 130% dan 98%.
Penyimpangan persentase untuk persentil ke-90 terlihat lebih baik daripada nilai serupa untuk persentil ke-10. Namun di sini perlu diingat bahwa angka yang menunjukkan waktu tampak agak menakutkan. Katakanlah 20.8 detik pada utas seluler utama untuk situs web yang dibangun dengan React. (Menurut saya cerita tentang apa yang sebenarnya terjadi selama ini layak untuk dijadikan artikel tersendiri).
Ada satu potensi komplikasi di sini (terima kasih untuk menarik perhatian saya ke fitur ini, dan dengan hati-hati mempertimbangkan data dari sudut pandang ini). Faktanya adalah banyak situs menggunakan beberapa alat front-end. Secara khusus, saya telah melihat banyak situs menggunakan jQuery bersama React atau Vue, karena situs tersebut bermigrasi dari jQuery ke framework atau library lain. Akibatnya, saya menekan database lagi, kali ini hanya memilih tautan yang sesuai dengan situs yang hanya menggunakan React, jQuery, Angular, atau Vue, tetapi bukan kombinasi dari semuanya. Inilah yang saya dapatkan.
Waktu pemroses (dalam milidetik) terkait dengan pemrosesan skrip di perangkat seluler dalam situasi di mana situs hanya menggunakan satu kerangka kerja atau hanya satu pustaka
Persentil
10
25
50
75
90
Situs yang hanya menggunakan jQuery
542.9
1062.2
2297.4
4769.7
8718.2
Situs yang hanya menggunakan Vue
944.0
1716.3
3194.7
5959.6
9843.8
Situs yang hanya menggunakan Angular
1328.9
2151.9
3695.3
6629.3
11607.7
Situs yang hanya menggunakan React
2443.2
4620.5
10061.4
17074.3
24956.3
Waktu pemroses terkait dengan pemrosesan skrip pada perangkat seluler dalam situasi di mana situs hanya menggunakan satu kerangka kerja, atau hanya satu pustaka
Pertama, sesuatu yang tidak mengherankan: ketika sebuah situs hanya menggunakan satu kerangka kerja atau satu pustaka, kinerja situs semacam itu lebih sering meningkat daripada tidak. Setiap instrumen berkinerja lebih baik pada persentil ke-10 dan ke-25. Masuk akal. Sebuah situs yang dibuat menggunakan satu kerangka kerja harus memiliki performa yang lebih baik daripada situs yang dibuat menggunakan dua atau lebih kerangka kerja atau pustaka.
Nyatanya, performa setiap alat front-end yang dipelajari terlihat lebih baik di semua kasus, kecuali satu pengecualian yang aneh. Yang mengejutkan saya adalah bahwa pada persentil ke-50 ke atas, situs yang menggunakan React berperforma lebih buruk ketika React adalah satu-satunya pustaka yang mereka gunakan. Ngomong-ngomong, inilah alasan saya menyajikan data ini di sini.
Ini sedikit aneh, tapi saya akan tetap mencoba mencari penjelasan atas keanehan ini.
Jika sebuah proyek menggunakan React dan jQuery, maka proyek tersebut kemungkinan berada di tengah-tengah transisi dari jQuery ke React. Mungkin ia memiliki basis kode tempat perpustakaan ini digabungkan. Karena kita telah melihat bahwa situs jQuery menghabiskan lebih sedikit waktu di utas utama daripada situs React, ini mungkin memberi tahu kita bahwa mengimplementasikan beberapa fungsi di jQuery membantu kinerja situs sedikit lebih baik.
Namun saat proyek bertransisi dari jQuery ke React dan lebih bergantung pada React, banyak hal berubah. Jika situs tersebut benar-benar berkualitas tinggi, dan pengembang situs menggunakan React dengan hati-hati, maka semuanya akan baik-baik saja dengan situs seperti itu. Tetapi untuk situs React rata-rata, penggunaan React yang ekstensif berarti thread utama berada di bawah beban berat.
Kesenjangan antara perangkat seluler dan desktop
Sudut pandang lain dari mana saya melihat data yang diteliti adalah mempelajari seberapa besar kesenjangan antara bekerja dengan situs di perangkat seluler dan desktop. Jika kita berbicara tentang membandingkan volume kode JavaScript, perbandingan seperti itu tidak mengungkapkan sesuatu yang buruk. Tentu saja, akan menyenangkan melihat jumlah kode yang dapat diunduh lebih sedikit, tetapi tidak banyak perbedaan dalam jumlah kode seluler dan desktop.
Tetapi jika kami menganalisis waktu yang diperlukan untuk memproses kode, kesenjangan yang sangat besar antara perangkat seluler dan desktop menjadi terlihat.
Peningkatan waktu (persentase) terkait pemrosesan skrip di perangkat seluler dibandingkan dengan desktop
Persentil
10
25
50
75
90
Semua situs
144.1
172.8
185.5
208.5
224.0
situs jQuery
188.2
187.4
191.3
209.6
221.9
situs Vue
222.5
220.8
220.2
221.4
220.4
Situs sudut
205.1
206.0
201.6
210.4
218.7
Bereaksi Situs
431.5
386.8
337.9
242.6
179.6
Sementara beberapa perbedaan dalam kecepatan pemrosesan kode antara telepon dan laptop diharapkan, jumlah yang begitu besar memberi tahu saya bahwa kerangka kerja modern tidak cukup ditargetkan pada perangkat berdaya rendah, dan mereka berusaha untuk menutup celah yang telah mereka temukan. Bahkan pada persentil ke-10, situs React menghabiskan 431.5% lebih banyak waktu di thread utama seluler daripada di thread utama desktop. jQuery memiliki celah terkecil, tetapi bahkan di sini angka yang sesuai adalah 188.2%. Ketika pengembang situs web membuat proyek mereka sedemikian rupa sehingga pemrosesan mereka membutuhkan lebih banyak waktu prosesor (dan itu terjadi, dan itu semakin memburuk dari waktu ke waktu), pemilik perangkat berdaya rendah harus membayarnya.
Hasil
Kerangka kerja yang baik harus memberi pengembang landasan yang baik untuk membangun proyek web (dalam hal keamanan, aksesibilitas, kinerja), atau mereka harus memiliki batasan bawaan yang mempersulit pembuatan sesuatu yang melanggar batasan tersebut.
Ini tampaknya tidak berlaku untuk kinerja proyek web (dan mungkin tidak untuk proyek web mereka ).
Perlu dicatat bahwa hanya karena situs React atau Angular menghabiskan lebih banyak waktu CPU untuk menyiapkan kode daripada yang lain tidak berarti situs React lebih intensif CPU daripada situs Vue saat berjalan. Faktanya, data yang telah kami ulas menjelaskan sangat sedikit tentang kinerja operasional kerangka kerja dan pustaka. Mereka berbicara lebih banyak tentang pendekatan pengembangan yang, secara sadar atau tidak, kerangka kerja ini dapat mendorong programmer. Kami berbicara tentang dokumentasi untuk kerangka kerja, tentang ekosistemnya, tentang teknik pengembangan umum.
Perlu juga disebutkan sesuatu yang tidak kami analisis di sini, yaitu, berapa banyak waktu yang dihabiskan perangkat untuk menjalankan kode JavaScript saat menavigasi antar halaman situs. Argumen yang mendukung SPA adalah bahwa setelah aplikasi satu halaman dimuat ke dalam browser, pengguna secara teoritis akan dapat membuka halaman situs lebih cepat. Pengalaman saya sendiri memberi tahu saya bahwa ini jauh dari fakta. Tetapi kami tidak memiliki data untuk mengklarifikasi masalah ini.
Yang jelas adalah bahwa jika Anda menggunakan kerangka kerja atau pustaka untuk membuat situs web, Anda membuat kompromi dalam hal memuat proyek pada awalnya dan menyiapkannya untuk digunakan. Ini berlaku bahkan untuk skenario paling positif.
Sangat mungkin untuk membuat beberapa kompromi dalam situasi yang sesuai, tetapi penting bagi pengembang untuk membuat kompromi tersebut secara sadar.
Tapi kami juga punya alasan untuk optimis. Saya senang melihat seberapa dekat pengembang Chrome bekerja sama dengan pengembang beberapa alat front-end yang telah kami ulas dalam upaya membantu meningkatkan kinerja alat tersebut.
Namun, saya adalah orang yang pragmatis. Arsitektur baru menciptakan masalah kinerja sesering mereka menyelesaikannya. Dan butuh waktu untuk memperbaiki bug. Seperti yang seharusnya tidak kita harapkan akan menyelesaikan semua masalah kinerja, Anda seharusnya tidak mengharapkan ini dari versi baru kerangka kerja favorit kami.
Jika Anda ingin menggunakan salah satu alat front-end yang dibahas dalam artikel ini, ini berarti Anda harus berusaha ekstra agar tidak merusak kinerja proyek Anda untuk sementara. Berikut adalah beberapa pertimbangan untuk dipertimbangkan sebelum memulai kerangka kerja baru:
- Uji diri Anda dengan akal sehat. Apakah Anda benar-benar perlu menggunakan kerangka kerja yang dipilih? JavaScript murni saat ini mampu melakukan banyak hal.
- Apakah ada alternatif yang lebih ringan untuk kerangka kerja yang dipilih (seperti Preact, Svelte, atau lainnya) yang dapat memberi Anda 90% kemampuan kerangka kerja ini?
- Jika Anda sudah menggunakan kerangka kerja, pertimbangkan apakah ada sesuatu yang menawarkan opsi standar yang lebih baik, lebih konservatif (mis. Nuxt.js daripada Vue, Next.js daripada React, dan seterusnya).
- Apa yang akan Anda Performa JavaScript?
- Bagaimana Anda bisa proses pengembangan untuk mempersulit memasukkan lebih banyak kode JavaScript ke dalam proyek daripada yang diperlukan?
- Jika Anda menggunakan kerangka kerja untuk kemudahan pengembangan, pertimbangkan mengirim kode framework ke klien. Mungkin Anda bisa menyelesaikan semua masalah di server?
Biasanya ide-ide ini layak untuk dilihat, terlepas dari apa yang sebenarnya Anda pilih untuk pengembangan front-end. Tapi mereka sangat penting saat Anda mengerjakan proyek yang tidak memiliki kinerja sejak awal.
Pembaca yang terhormat Bagaimana Anda melihat framework JavaScript yang ideal?
Sumber: www.habr.com