Ora ana cara sing luwih cepet kanggo nyuda situs web (ora ana sing dimaksudake) tinimbang mbukak akeh kode JavaScript. Nalika nggunakake JavaScript, sampeyan kudu mbayar ing kinerja project paling kaping papat. Mangkene apa kode JavaScript situs ngemot sistem pangguna:
- Ngunggah file liwat jaringan.
- Parsing lan kompilasi kode sumber sing ora dibungkus sawise diundhuh.
- Ngeksekusi kode JavaScript.
- Konsumsi memori.
Kombinasi iki dadi .
Lan kita kalebu luwih akeh kode JS ing proyek kita. Nalika organisasi pindhah menyang situs sing didhukung dening kerangka kerja lan perpustakaan kaya React, Vue lan liya-liyane, kita nggawe fungsi inti situs kasebut gumantung banget marang JavaScript.
Aku wis ndeleng akeh situs web sing abot banget nggunakake kerangka JavaScript. Nanging wawasanku babagan masalah kasebut bias banget. Kasunyatane yaiku perusahaan sing aku kerja bareng teka kanthi tepat amarga duwe masalah kinerja situs web sing rumit. Akibaté, aku dadi penasaran kanggo ngerti carane nyebar masalah iki, lan apa "denda" kita mbayar nalika kita milih siji utawa framework liyane minangka basis kanggo situs tartamtu.
Proyek iki mbantu aku ngerteni iki. .
data
Proyek Arsip HTTP nglacak total 4308655 pranala menyang situs desktop biasa lan 5484239 pranala menyang situs seluler. Ing antarane akeh indikator sing ana gandhengane karo tautan kasebut yaiku dhaptar teknologi sing ditemokake ing situs sing cocog. Iki tegese kita bisa conto ewu situs sing nggunakake kerangka kerja lan perpustakaan sing beda-beda lan sinau babagan jumlah kode sing dikirim menyang klien lan jumlah beban kode kasebut ing sistem pangguna.
Aku ngumpulake data wiwit Maret 2020, yaiku data paling anyar sing bisa diakses.
Aku mutusake kanggo mbandhingake data Arsip HTTP sing dikumpulake kanggo kabeh situs kanthi data kanggo situs sing ditemokake nggunakake React, Vue, lan Angular, sanajan aku uga nganggep nggunakake bahan sumber liyane.
Kanggo nggawe luwih menarik, aku uga nambahake situs sing nggunakake jQuery menyang set data sumber. Perpustakaan iki isih populer banget. Iki uga ngenalake pendekatan kanggo pangembangan situs web sing beda karo model Single Page Application (SPA) sing ditawakake React, Vue lan Angular.
Tautan ing Arsip HTTP sing makili situs sing ditemokake nggunakake teknologi sing menarik kanggo kita
Framework utawa perpustakaan
Pranala menyang situs seluler
Pranala menyang situs biasa
jQuery
4615474
3714643
nanggepi
489827
241023
Vue
85649
43691
sudut
19423
18088
Pangarep-arep lan impen
Sadurunge nerusake nganalisis data, aku arep ngomong babagan apa sing dikarepake.
Aku percaya yen ing jagad sing cocog, kerangka kerja bakal ngluwihi kabutuhan pangembang lan menehi sawetara keuntungan konkrit kanggo pangguna saben dina saka situs kita. Produktivitas mung minangka salah sawijining keuntungan kasebut. Aksesibilitas lan safety uga dipikirake ing kene. Nanging iki mung sing paling penting.
Dadi, ing jagad sing cocog, sawetara kerangka kerja kudu luwih gampang nggawe situs web kanthi kinerja dhuwur. Iki kudu ditindakake amarga kasunyatane kerangka kasebut menehi pangembang basis sing cocog kanggo mbangun proyek, utawa amarga kasunyatane mbatesi pangembangan, ngetrapake syarat-syarat sing nggawe angel ngembangake apa wae. sing dadi alon.
Kerangka paling apik kudu nindakake loro-lorone: nyedhiyakake basis sing apik, lan ngetrapake watesan ing karya sing ngidini sampeyan entuk asil sing apik.
Nganalisa nilai median data ora bakal menehi informasi sing dibutuhake. Lan, nyatane, pendekatan iki ngluwihi perhatian kita . Nanging, aku entuk skor persentil saka data sing aku duwe. Iki minangka 10, 25, 50 (median), 75, 90 persentil.
Aku utamané kasengsem ing persentil 10 lan 90. Persentil kaping 10 nggambarake kinerja sing paling apik (utawa paling ora luwih cedhak karo sing paling apik) kanggo kerangka tartamtu. Ing tembung liya, iki tegese mung 10% situs sing nggunakake kerangka tartamtu tekan level iki, utawa tingkat sing luwih dhuwur. Ing persentil kaping 90, ing sisih liya, yaiku sisih liya saka koin - nuduhake yen kedadeyan sing ala. Persentil kaping 90 minangka situs mburi - 10% situs pungkasan sing duwe kode JS paling gedhe utawa wektu paling dawa sing dibutuhake kanggo ngolah kode kasebut ing utas utama.
Volume kode JavaScript
Kanggo miwiti, ana gunane kanggo nganalisa ukuran kode JavaScript sing dikirim dening macem-macem situs liwat jaringan.
Jumlah kode JavaScript (KB) sing ditransfer menyang piranti seluler
Persentil
10
25
50
75
90
Kabeh situs
93.4
196.6
413.5
746.8
1201.6
situs jQuery
110.3
219.8
430.4
748.6
1162.3
situs web Vue
244.7
409.3
692.1
1065.5
1570.7
situs web sudut
445.1
675.6
1066.4
1761.5
2893.2
React situs web
345.8
441.6
690.3
1238.5
1893.6
Jumlah kode JavaScript sing dikirim menyang piranti seluler
Jumlah kode JavaScript (KB) sing ditransfer menyang piranti desktop
Persentil
10
25
50
75
90
Kabeh situs
105.5
226.6
450.4
808.8
1267.3
situs jQuery
121.7
242.2
458.3
803.4
1235.3
situs web Vue
248.0
420.1
718.0
1122.5
1643.1
situs web sudut
468.8
716.9
1144.2
1930.0
3283.1
React situs web
308.6
469.0
841.9
1472.2
2197.8
Jumlah kode JavaScript sing ditransfer menyang piranti desktop
Yen kita mung ngomong babagan ukuran kode JS sing dikirim situs menyang piranti, mula kabeh katon kaya sing dikarepake. Yaiku, yen salah sawijining kerangka digunakake, iki tegese sanajan ing kahanan sing cocog, volume kode JavaScript kanggo situs kasebut bakal nambah. Iki ora nggumunake - sampeyan ora bisa nggawe kerangka JavaScript minangka basis situs lan ngarepake yen jumlah kode JS kanggo proyek kasebut bakal sithik banget.
Sing menarik babagan data iki yaiku sawetara kerangka kerja lan perpustakaan bisa uga dianggep minangka titik wiwitan sing luwih apik kanggo proyek tinimbang liyane. Situs web kanthi jQuery katon paling apik. Situs desktop ngemot 15% luwih akeh JavaScript tinimbang kabeh situs, lan situs seluler ngemot 18% luwih akeh JavaScript. (Diakoni, ana sawetara skew ing data kene. Kasunyatan iku jQuery ana ing akeh situs, supaya iku alam sing situs kuwi luwih raket related kanggo jumlah total situs saka liyane. Nanging, iki ora mengaruhi carane data sumber output kanggo saben framework.)
Nalika 15-18% wutah kode punika tokoh pinunjul, yen dibandhingake frameworks lan perpustakaan liyane, tax dileksanakake dening jQuery banget kurang. Situs sudut ing persentil kaping 10 ngirim 344% luwih akeh data menyang piranti desktop tinimbang kabeh situs, lan 377% luwih akeh menyang piranti seluler. Situs React minangka sing paling abot sabanjure, ngirim kode 193% luwih akeh menyang piranti desktop tinimbang kabeh situs, lan 270% luwih akeh menyang piranti seluler.
Aku kasebut sadurungé sing sanajan nggunakake framework tegese jumlah tartamtu saka kode bakal klebu ing project ing awal banget karya ing, Mugi framework bisa Piye wae mbatesi pangembang. Utamane, kita ngomong babagan mbatesi jumlah maksimum kode.
Sing menarik yaiku situs jQuery ngetutake ide iki. Sanajan padha, ing tingkat persentil kaping 10, rada luwih abot tinimbang kabeh situs (dening 15-18%), ing tingkat persentil kaping 90, rada luwih entheng tinimbang kabeh situs - kira-kira 3% ing versi desktop lan seluler. Iki ora ngomong sing iki entuk manfaat banget pinunjul, nanging bisa ngandika situs jQuery paling ora duwe ukuran kode JavaScript ageng malah ing versi paling gedhe.
Nanging padha ora bisa ngandika bab frameworks liyane.
Kaya ing kasus persentil kaping 10, ing situs persentil kaping 90 ing Angular lan React beda karo situs liyane, nanging beda-beda, sayangé, luwih elek.
Ing persentil kaping 90, situs Angular ngirim 141% luwih akeh data menyang piranti seluler tinimbang kabeh situs, lan 159% luwih akeh menyang piranti desktop. Situs React ngirim 73% luwih akeh menyang piranti desktop tinimbang kabeh situs, lan 58% luwih akeh menyang piranti seluler. Ukuran kode situs React ing persentil kaping 90 yaiku 2197.8 KB. Iki tegese situs iki ngirim 322.9 KB luwih akeh data menyang piranti seluler tinimbang saingan basis Vue sing paling cedhak. Jurang antarane situs desktop adhedhasar Angular lan React lan situs liyane malah luwih gedhe. Contone, situs desktop React ngirim kode JS 554.7 KB luwih akeh menyang piranti tinimbang situs Vue sing padha.
Wektu kanggo ngolah kode JavaScript ing utas utama
Data ing ndhuwur kanthi jelas nuduhake yen situs sing nggunakake kerangka kerja lan perpustakaan sing ditliti ngemot kode JavaScript sing akeh. Nanging, mesthi, iki mung salah siji bagéan saka persamaan kita.
Sawise kode JavaScript wis teka ing browser, kudu digawa menyang negara sing bisa digunakake. Utamane akeh masalah sing disebabake dening tumindak sing kudu ditindakake kanthi kode ing utas browser utama. Utas utama tanggung jawab kanggo ngolah tumindak pangguna, ngetung gaya, lan mbangun lan nampilake tata letak kaca. Yen sampeyan ngatasi utas utama karo tugas JavaScript, ora bakal duwe kesempatan kanggo ngrampungake tugas liyane ing wektu sing tepat. Iki nyebabake telat lan "rem" ing operasi kaca.
Database HTTP Archive ngemot informasi babagan suwene proses kode JavaScript ing utas utama mesin V8. Iki tegese kita bisa ngumpulake data iki lan sinau sepira suwene thread utama kanggo ngolah JavaScript saka macem-macem situs.
wektu CPU (ing milliseconds) related kanggo Processing script ing piranti seluler
Persentil
10
25
50
75
90
Kabeh situs
356.4
959.7
2372.1
5367.3
10485.8
situs jQuery
575.3
1147.4
2555.9
5511.0
10349.4
situs web Vue
1130.0
2087.9
4100.4
7676.1
12849.4
situs web sudut
1471.3
2380.1
4118.6
7450.8
13296.4
React situs web
2700.1
5090.3
9287.6
14509.6
20813.3
wektu CPU related kanggo Processing script ing piranti seluler
wektu CPU (ing milliseconds) related kanggo proses script ing piranti desktop
Persentil
10
25
50
75
90
Kabeh situs
146.0
351.8
831.0
1739.8
3236.8
situs jQuery
199.6
399.2
877.5
1779.9
3215.5
situs web Vue
350.4
650.8
1280.7
2388.5
4010.8
situs web sudut
482.2
777.9
1365.5
2400.6
4171.8
React situs web
508.0
1045.6
2121.1
4235.1
7444.3
wektu CPU related kanggo Processing script ing piranti desktop
Kene sampeyan bisa ndeleng soko banget menowo.
Kanggo wiwitan, situs karo jQuery mbuwang luwih akeh ngolah JavaScript ing utas utama tinimbang liyane. Ing persentil kaping 10, dibandhingake karo kabeh situs, situs jQuery ing piranti seluler nglampahi 61% luwih akeh wektu ngolah kode JS ing utas utama. Ing kasus situs jQuery desktop, wektu pangolahan mundhak 37%. Ing persentil kaping 90, skor situs jQuery cedhak banget karo skor agregat. Secara khusus, situs jQuery ing piranti seluler nggunakake wektu 1.3% luwih sithik ing utas utama tinimbang kabeh situs, lan ing piranti desktop padha nglampahi wektu kurang 0.7% ing utas utama.
Ing sisih liya rating kita yaiku kerangka kerja sing ditondoi kanthi beban paling gedhe ing utas utama. Iki, maneh, Angular lan React. Bentenipun mung ing antarane yaiku, sanajan situs Angular ngirim kode sing luwih gedhe menyang browser tinimbang situs React, butuh wektu CPU kurang kanggo ngolah kode situs Angular. Kurang adoh.
Ing persentil kaping 10, situs desktop Angular nglampahi 230% wektu utas utama ngolah kode JS tinimbang kabeh situs. Kanggo situs seluler angka iki 313%. Situs React duwe kinerja paling awon. Ing piranti desktop padha nglampahi 248% wektu pangolahan kode luwih akeh tinimbang kabeh situs, lan ing piranti seluler nggunakake kode pangolahan 658% luwih akeh. 658% dudu salah ketik. Ing persentil kaping 10, situs React nglampahi 2.7 detik wektu utas utama ngolah kode sing wis ana.
Nomer persentil kaping 90 katon luwih apik yen dibandhingake karo nomer gedhe kasebut. Proyek sudut, dibandhingake karo kabeh situs, nglampahi 29% luwih akeh wektu ing utas utama ing piranti desktop, lan 27% luwih akeh wektu ing piranti seluler. Ing kasus situs React, indikator sing padha katon kaya 130% lan 98%.
Persentase panyimpangan kanggo persentil kaping 90 katon luwih apik tinimbang nilai sing padha kanggo persentil kaping 10. Nanging ing kene kudu eling yen angka sing nuduhake wektu katon cukup medeni. Ayo ngomong - 20.8 detik ing utas utama piranti seluler kanggo situs sing dibangun ing React. (Aku yakin crita apa sing kedadeyan sajrone wektu iki pantes kanggo artikel sing kapisah).
Ana siji komplikasi potensial ing kene (matur nuwun kanggo narik kawigaten babagan fitur iki, lan kanthi teliti mriksa data saka sudut pandang iki). Kasunyatane manawa akeh situs nggunakake sawetara alat ngarep. Utamane, aku wis ndeleng akeh situs sing nggunakake jQuery bebarengan karo React utawa Vue amarga situs iki pindhah saka jQuery menyang kerangka kerja utawa perpustakaan liyane. Akibaté, aku bali menyang database, wektu iki mung milih pranala sing cocog karo situs sing mung digunakake React, jQuery, Angular utawa Vue, nanging ora kombinasi. Iki aku entuk.
Wektu prosesor (ing milidetik) sing gegandhengan karo pangolahan skrip ing piranti seluler ing kahanan nalika situs mung nggunakake siji kerangka utawa mung siji perpustakaan
Persentil
10
25
50
75
90
Situs sing mung nggunakake jQuery
542.9
1062.2
2297.4
4769.7
8718.2
Situs sing mung nggunakake Vue
944.0
1716.3
3194.7
5959.6
9843.8
Situs sing mung nggunakake Angular
1328.9
2151.9
3695.3
6629.3
11607.7
Situs web sing mung nggunakake React
2443.2
4620.5
10061.4
17074.3
24956.3
Wektu prosesor sing ana gandhengane karo ngolah skrip ing piranti seluler ing kahanan ing ngendi situs mung nggunakake siji kerangka, utawa mung siji perpustakaan
Kaping pisanan, ana sing ora nggumunake: nalika situs nggunakake mung siji kerangka utawa siji perpustakaan, kinerja situs kasebut luwih kerep tinimbang ora. Kinerja kanggo saben instrumen katon luwih apik ing persentil 10 lan 25. Iku ndadekake pangertèn. Situs sing digawe nggunakake siji kerangka kudu luwih cepet tinimbang situs sing digawe nggunakake rong utawa luwih kerangka utawa perpustakaan.
Nyatane, skor kanggo saben alat ngarep sing ditliti katon luwih apik ing kabeh kasus, kanthi pengecualian sing aneh. Sing nggumunake aku yaiku ing persentil kaping 50 lan ndhuwur, situs sing nggunakake React luwih elek nalika React minangka perpustakaan sing digunakake. Iki, kanthi cara, iki minangka alesan aku nampilake data iki ing kene.
Iki rada aneh, nanging aku isih bakal nyoba goleki panjelasan babagan keanehan iki.
Yen proyek nggunakake React lan jQuery, mula proyek kasebut bisa uga ana ing tengah-tengah proses migrasi saka jQuery menyang React. Mbok menawa dheweke duwe basis kode ing ngendi perpustakaan kasebut dicampur. Awit kita wis weruh yen situs jQuery nglampahi wektu kurang ing utas utama tinimbang situs React, iki bisa uga ngandhani yen nindakake sawetara fungsi ing jQuery mbantu nambah kinerja situs.
Nanging nalika proyèk pindhah saka jQuery kanggo React lan gumantung liyane lan liyane ing React, owah-owahan kahanan. Yen situs kasebut digawe kanthi kualitas sing bener, lan pangembang situs nggunakake React kanthi ati-ati, mula kabeh bakal apik karo situs kasebut. Nanging kanggo situs React rata-rata, panggunaan React kanthi ekstensif tegese utas utama kena beban sing tambah.
Longkangan antarane piranti seluler lan desktop
Cara liya aku ndeleng data kasebut yaiku njelajah sepira gedhene jurang antarane pengalaman seluler lan desktop. Yen kita ngomong babagan mbandhingake volume kode JavaScript, perbandingan kasebut ora nuduhake apa wae sing nggegirisi. Mesthine, luwih becik ndeleng kode sing bisa didownload sing luwih cilik, nanging ora ana bedane ing jumlah kode seluler lan desktop.
Nanging yen sampeyan nganalisa wektu sing dibutuhake kanggo ngolah kode kasebut, jurang sing gedhe banget ing antarane piranti seluler lan desktop bakal katon.
Tambah wektu (ing persentase) sing ana gandhengane karo pangolahan skrip ing piranti seluler dibandhingake karo desktop
Persentil
10
25
50
75
90
Kabeh situs
144.1
172.8
185.5
208.5
224.0
situs jQuery
188.2
187.4
191.3
209.6
221.9
situs web Vue
222.5
220.8
220.2
221.4
220.4
situs web sudut
205.1
206.0
201.6
210.4
218.7
React situs web
431.5
386.8
337.9
242.6
179.6
Nalika sawetara prabédan ing kacepetan pangolahan kode ing antarane telpon lan laptop kudu diarepake, jumlah gedhe kasebut ngandhani yen kerangka modern ora cukup ditargetake ing piranti sing kurang daya lan kepinginan kanggo nutup celah sing wis diidentifikasi. Malah ing persentil kaping 10, situs React nglampahi 431.5% luwih akeh wektu ing utas utama seluler tinimbang ing utas utama desktop. jQuery wis longkangan paling cilik, nanging malah kene tokoh cocog 188.2%. Nalika pangembang situs web nggawe proyek kanthi cara sing mbutuhake wektu CPU luwih akeh kanggo ngolah (lan iki kedadeyan, lan saya suwe saya suwe), para pamilik piranti kurang daya kudu mbayar.
Hasil
Kerangka kerja sing apik kudu menehi pangembang dhasar sing apik kanggo mbangun proyek web (ing babagan keamanan, aksesibilitas, kinerja), utawa kudu duwe watesan sing nggawe angel nggawe barang sing nglanggar larangan kasebut.
Iki kayane ora ditrapake kanggo kinerja proyek web (lan ketoke ).
Perlu dicathet yen mung amarga situs React utawa Angular nglampahi wektu CPU luwih akeh kanggo nyiapake kode tinimbang liyane, ora ateges situs React luwih intensif CPU tinimbang situs Vue nalika mlaku. Nyatane, data sing kita deleng ora ujar babagan kinerja operasional kerangka kerja lan perpustakaan. Dheweke luwih akeh ngomong babagan pendekatan pangembangan sing, kanthi sadar utawa ora, kerangka kerja kasebut bisa nyurung programer. Kita ngomong babagan dokumentasi kanggo kerangka kerja, ekosistem, lan teknik pangembangan umum.
Sampeyan uga kudu nyebutake babagan sing ora dianalisis ing kene, yaiku, sepira suwene piranti nggunakake kode JavaScript nalika transisi ing antarane kaca situs kasebut. Argumentasi kanggo SPA yaiku yen aplikasi siji kaca dimuat menyang browser, pangguna bakal, ing teori, bisa ngakses kaca situs luwih cepet. Pengalamanku dhewe ngandhani yen iki adoh saka kasunyatan. Nanging kita ora duwe data kanggo njlentrehake masalah iki.
Sing jelas yaiku yen sampeyan nggunakake kerangka utawa perpustakaan kanggo nggawe situs web, sampeyan nggawe kompromi babagan wiwitan ngemot proyek kasebut lan siap-siap. Iki ditrapake malah kanggo skenario paling positif.
Sampeyan bisa nggawe sawetara kompromi ing kahanan sing cocog, nanging penting yen pangembang nggawe kompromi kasebut kanthi sadar.
Nanging kita uga duwe alesan kanggo optimisme. Aku diwanti-wanti dening sepira cedhake para pangembang Chrome nggarap wong-wong sing ana ing mburi sawetara alat ngarep sing wis kita bahas kanggo mbantu ningkatake kinerja alat kasebut.
Nanging, aku wong sing pragmatis. Arsitèktur anyar nggawe masalah kinerja kaya asring ngatasi. Lan butuh wektu kanggo ngilangi kekurangan kasebut. Kaya sing ora kudu kita ngarepake bakal ngatasi kabeh masalah kinerja, sampeyan ora kudu nyana iki saka versi anyar saka frameworks favorit.
Yen sampeyan pengin nggunakake salah siji saka ngarep-mburi pribadi rembugan ing materi iki, iki tegese sampeyan kudu nggawe tambahan efforts kanggo mesthekake yen, satleraman, sampeyan ora cilaka kinerja project. Mangkene sawetara pertimbangan sing kudu ditimbang sadurunge sampeyan miwiti nggunakake kerangka kerja anyar:
- Priksa dhewe kanthi akal sehat. Apa sampeyan pancene kudu nggunakake kerangka sing dipilih? JavaScript murni bisa nindakake akeh dina iki.
- Apa ana alternatif sing luwih entheng kanggo kerangka pilihan sampeyan (kaya Preact, Svelte utawa liya-liyane) sing bisa menehi sampeyan 90% kemampuan kerangka kasebut?
- Yen sampeyan wis nggunakake framework, mikir bab apa ana sing nawakake luwih apik, konservatif, opsi standar (Contone, Nuxt.js tinimbang Vue, Next.js tinimbang React, etc.).
- Apa sing bakal sampeyan Kinerja JavaScript?
- Kok bisa proses pangembangan supaya luwih angel ngenalake luwih akeh kode JavaScript menyang proyek tinimbang pancen perlu?
- Yen sampeyan nggunakake framework kanggo ease pembangunan, nimbang ngirim kode framework kanggo klien. Mungkin sampeyan bisa ngatasi kabeh masalah ing server?
Biasane, gagasan-gagasan kasebut kudu dideleng kanthi cetha, preduli saka apa sing sampeyan pilih kanggo ngembangake mburi ngarep. Nanging penting banget nalika sampeyan lagi nggarap proyek sing ora duwe kinerja.
Para pamaca ingkang kinurmatan! Apa sampeyan ndeleng minangka kerangka JavaScript sing cocog?
Source: www.habr.com