Pima safari ya mteja kabla ya kubadilisha msimbo
Chagua njia moja muhimu na mwingiliano, kama kufungua urambazaji, kuchuja matokeo, au kutuma fomu. Rekodi katika kidirisha cha Performance cha Chrome DevTools ukiwa na hali safi ya kivinjari. Rudia kitendo hicho na chukua rekodi yenye CPU iliyopunguzwa kasi pamoja na rekodi kwenye mashine ya maendeleo; trace za desktop zinaweza kuficha kazi inayotatiza kwenye simu yenye uwezo mdogo wa kuchakata.
Tumia trace kujaribu nadharia nyembamba, si kumkashifu sehemu kutoka kwenye ripoti ya bundle. Katika mchoro wa moto wa Main, pau pana huchukua muda mrefu, na pau zilizopangwa juu kwa juu huonyesha mnyororo wa miito. Pembetatu nyekundu kwenye Task inaonyesha potential long task; chagua hiyo na fuata kiungo cha msimbo uliosababisha. Hifadhi traces kabla na baada kwa mabadiliko yenye maana.
Rekodi tu kabla ya kitendo na simamisha baada ya matokeo ya kuonekana.
Hifadhi njia, hali ya akaunti, na mlolongo wa hatua sawa.
Peana kila gharama kuu kwa timu au muuzaji anayeweza kuibadilisha.
Soma trace kama foleni ya kazi
Long task ni kigezo cha kuanzisha uchunguzi, si utambuzi kamili. W3C Long Tasks specification inaripoti tasks zinazodumu 50 milliseconds au zaidi. Angalia chini ya task kwa ajili ya JavaScript evaluation, event handler, recalculation ya style, layout, au paint. Call stack inaonyesha wapi kuanza; nyakati zinaonyesha ikiwa tatizo ni msimbo, rendering, au fremu ya mtu wa tatu.
Panga kipaumbele gharama zinazojirudia wakati wa mwingiliano wenye thamani. Handler fupi bado inaweza kuonekana polepole inapochochea layout au kusubiri nyuma ya kazi iliyotangulia. Trace ni kipimo cha maabara, hivyo thibitisha marekebisho kwenye vifaa vinavyowakilisha na, pale zinapopatikana, kwa telemetry ya uwanja inayozingatia faragha.
Parsing ya startup inahitaji tiba tofauti na handler baada ya kugusa.
Tafuta mifumo ya kuandika style mara kwa mara na kusoma layout kabla ya kufanyia refactor.
Ambatisha trace, senario, na gharama kuu kwenye kazi.
Pakia msimbo mdogo wakati unapouhitaji
Orodhesha skripti kwa njia na kusudi. Ondoa vifurushi visivyotumiwa, nakala rudufu, majaribio yaliyositishwa na msimbo wa vipengele vilivyoondolewa. Kisha gawanya vipengele vya njia fulani au vinavyotumiwa mara chache ili vipakizwe vinapohitajika badala ya kupakiwa katika njia ya mwanzo. Loading ya dynamic inaweza kupunguza kazi ya startup, lakini inaweza kuleta ucheleweshaji unaoonekana wakati mtumiaji anahitaji kipengele mara moja.
Jiulize ikiwa sehemu inahitaji framework kamili ya upande wa mteja, ikiwa utility inarudia uwezo uliopo, na ikiwa HTML tuli pamoja na uboreshaji mdogo itatosha. Jaribu hali ya fallback ya moduli iliyocheleweshwa. Kwa uwezo wa hiari, ukurasa unapaswa kuendelea kufanya kazi kwa staha hata kipengele hicho kisipatikane, badala ya kuonyesha kidhibiti kisichofanya kazi.
Tambua scripts zilizokubaliwa kwenye njia na kwa nini.
Fikiria hili kwa wahariri wa hiari, ramani, wachezaji, au maoni ya ripoti.
Jaribu uthibitisho, upatikanaji, malipo, na kukamilisha fomu; tafuta ukaguzi wenye sifa ambapo vidhibiti vinaguswa.
Gawanya kazi ili browser iwasilishe mwitikio
Kugawa msimbo katika functions ndogo hakuundi browser tasks tofauti zinapoendeshwa kwa mfuatano. Kwa loop ndefu, fanya kazi kwa batch, sasisha hali inayoonekana kwa mtumiaji mara moja, kisha ipe browser nafasi ya kushughulikia kazi nyingine (yield) kabla ya kuendelea. Hilo huruhusu browser kuchakata ingizo na rendering kati ya batch.
Pale inapoungwa mkono, scheduler.yield() huipa main thread nafasi ya kushughulikia kazi nyingine kabla ya kuendelea na kazi; tambua upatikanaji wake kwa feature detection na utumie fallback kwa vivinjari visivyounga mkono. Usitumie yield baada ya kila operesheni ndogo: ina gharama na inaweza kuongeza muda wa kukamilisha. Chagua mipaka kwa vipimo, hifadhi uwezo wa kughairi, na zuia matokeo ya zamani yasibadilishe hali mpya.
Onyesha kukubaliwa au maendeleo kabla ya kazi ya ziada isiyoonekana.
Rudisha kabla kazi iliyopimwa kuwa ndefu, badala ya mara kwa mara kwa kila kipengee.
Mwongozo wa sasa wa web.dev haupendekezi mkakati mpya unaotegemea isInputPending().
Hamisha uchakataji, si kiolesura, hadi worker
Web Worker huendesha script kwenye thread ya usuli, tofauti na main execution thread. Inafaa kwa uchanganuzi mzito, ubadilishaji wa data, uorodheshaji wa utafutaji na hesabu nyingine ambazo hazihitaji ufikiaji wa moja kwa moja wa kiolesura. Tuma ingizo lililobainishwa, rejesha matokeo yaliyobainishwa, na weka rendering pamoja na mabadiliko ya hali inayoonekana kwenye main thread.
Workers si suluhisho la kila kitu. Haziwezi kubadilisha DOM moja kwa moja wala kutumia Window, na mawasiliano ya ujumbe kwa kawaida hunakili data. Uundaji wa worker, uhamisho wa data, na uratibu wa makosa unaweza kuzidi faida kwa hesabu ndogo. Pima mwingiliano mzima, sitisha workers zisizohitajika, na tengeneza fallback ikiwa kazi ya worker itashindwa.
Anzisha na kalkuleti ambayo input yake na output inaweza kuserializiwa na kujaribiwa.
Tupa matokeo yaliyotengenezwa kwa filter, njia, au hatua ya zamani.
Wasiliana maendeleo yenye maana kupitia kiolesura cha kawaida.
Dhibiti JavaScript ya mtu wa tatu kama utegemezi wa uzalishaji
Analytics, matangazo, majaribio, embeds za kijamii, wachezaji wa video, na widgets za msaada vinaweza kuongeza maombi, JavaScript evaluation, iframes, na utegemezi. Script ya muuzaji inaweza kuwa muhimu, lakini ipo nje ya udhibiti wa moja kwa moja wa timu ya programu na inaweza kuathiri utendaji, faragha, usalama, na kuendelea kwa huduma. Orodhesha kusudi chake, njia, hali ya upakiaji, mthibitishaji, hitaji la ridhaa (consent), na mwenye kuiondoa.
Pale masharti na mikataba vinaporuhusu, linganisha ukurasa unaowakilisha ukiwa na bila origin moja ya mtu wa tatu. Zana za utendaji zinaweza kufichua evaluation yenye gharama, payloads, na attribution ya long task. Dumisha integration nyepesi au iliyocheleweshwa tu pale thamani yake iliyoandikwa inapoidhinisha gharama iliyopimwa. Thibitisha maudhui ya msingi na kazi kuu ya muamala pale utegemezi wa hiari unapokuwa polepole au haupatikani.
Pakia tag tu kwenye njia na masharti zinazohitaji.
Jumuisha mabadiliko ya tag-manager katika ukaguzi wa utendaji, faragha, usalama, na rollback.
Hifadhi na jaribu jinsi ya kuzima ushirikiano usio wa lazima.
Fanya mwitikio kuwa kinga ya utoaji
Geuza trace iliyo bora kuwa cheki ndogo ya regression kwa safari muhimu. Bainisha mwingiliano uliokamilishwa, kifaa au vizuizi vya CPU, mwitikio unaotarajiwa, na mkaguzi. Unganisha hili na ukaguzi wa bundle na orodha ya wahusika wengine ili package mpya au tag isirudi kwa utulivu kazi za main-thread bila kutambulika.
Status Is UP hutumia ushahidi huu kwa uboreshaji wa mapema na urejeshaji salama, si kuchukua nafasi ya ufuatiliaji hai wa upatikanaji. Kabla ya mabadiliko yenye hatari kubwa, andaa rollback na thibitisha mtiririko muhimu baada ya utoaji. Matokeo hutofautiana kulingana na kifaa, mtandao, kivinjari, maudhui, na hali ya akaunti; tibu vizingiti kama kinga, si dhamana.
Hitaji traces kabla na baada kwa urambazaji uliooshirikishwa, checkout, utafutaji, au bundles kubwa.
Tambua feature flag, mipangilio ya tag, au toleo la deployment linalorejesha tabia iliyojulikana inayofanya kazi.
Pima tena baada ya utoaji mkubwa, mabadiliko ya muuzaji, au mabadiliko ya muundo wa vifaa.