I-profile ang customer journey bago baguhin ang code
Pumili ng isang mahalagang ruta at interaction, gaya ng pagbukas ng navigation, pag-filter ng resulta, o pagsusumite ng form. I-record ito sa Chrome DevTools Performance panel mula sa malinis na estado ng browser. Ulitin ang aksyon at kuhanin ang isang throttled-CPU run pati na rin ang isang development-machine run; maaaring maitago ng desktop traces ang trabaho na nakakaistorbo sa mas mababang-powered na telepono.
Gamitin ang trace upang subukan ang isang tiyak na hypothesis, hindi upang sisihin ang isang component batay lamang sa ulat ng bundle. Sa Main flame chart, mas mahahabang bar ang tumatagal nang mas matagal at ipinapakita ng mga nakapatong na bar ang call stack. Ang pulang tatsulok sa isang Task ay nagsasaad ng posibleng long task; piliin ito at sundan ang link papunta sa code na nagpasimula nito. I-save ang mga trace bago at pagkatapos ng mahahalagang pagbabago.
I-record kaagad bago ang aksyon at itigil pagkatapos ng nakikitang resulta.
Panatilihin ang pare-parehong ruta, account state, at pagkakasunod-sunod ng aksyon.
Itatalaga ang bawat nangungunang gastos sa team o vendor na may kakayahang magbago nito.
Basahin ang trace bilang pila ng trabaho
Ang long task ay hangganan para simulan ang imbestigasyon, hindi kumpletong diagnosis. Nagtatala ang W3C Long Tasks specification ng mga task na tumatagal nang 50 millisecond o higit pa. Suriin ang nasa loob ng task: JavaScript evaluation, event handler, style recalculation, layout, o paint. Ipinapakita ng call stack kung saan magsisimula; ipinapakita ng timing kung code, rendering, o third-party frame ang problema.
Bigyang prayoridad ang gastos na paulit-ulit sa isang mahalagang interaction. Ang isang maikling handler ay maaaring magmukhang mabagal kapag ito ay nagti-trigger ng layout o nag-aantay sa likod ng naunang trabaho. Ang trace ay sukat sa lab, kaya i-confirm ang pag-aayos sa mga kinatawang device at, kung mayroon, gamit ang privacy-conscious na field telemetry.
Iba ang lunas para sa startup parsing kumpara sa post-tap handler.
Hanapin ang paulit-ulit na pattern ng style-write at layout-read bago mag-refactor.
I-attach ang trace, scenario, at nangungunang mga gastos sa work item.
Mag-ship ng mas kaunting code kung kailan mahalaga
Gumawa ng imbentaryo ng mga script ayon sa ruta at layunin. Alisin ang hindi nagagamit na packages, duplicate, mga retiradong eksperimento, at code para sa mga tinapos na feature. Pagkatapos ay i-split ang route-specific o bihirang ginagamit na feature upang mag-load lamang kapag kailangan sa halip na sa initial path. Maaaring bawasan ng dynamic loading ang startup work, ngunit maaari itong magdulot ng nakikitang pagkaantala kapag kailangan agad ng user ang feature.
Tanungin kung kailangan ng isang component ang buong client-side framework, kung duplicate ng umiiral na kakayahan ang isang utility, at kung sapat na ang static HTML na may maliit na enhancement. Subukan ang fallback state ng module na naantala ang pag-load. Kapag naantala ang isang opsyonal na kakayahan, dapat manatiling magagamit nang maayos ang pahina sa halip na magpakita ng kontrol na walang gumaganang aksyon.
Idokumento kung aling mga script ang pinapayagan sa isang ruta at bakit.
Isaalang-alang ito para sa mga optional editor, mapa, player, o reporting view.
Subukan ang authentication, accessibility, payment, at form completion; humingi ng kwalipikadong review kapag naapektuhan ang controls.
Hatiin ang trabaho para makaresponde ang browser
Ang pagbibigay lang ng pangalan sa mas maliliit na function ay hindi awtomatikong lumilikha ng magkakahiwalay na task sa browser kung sabay-sabay pa rin silang tumatakbo. Para sa mahabang loop, hatiin sa batch ang trabaho, i-update ang agarang nakikitang estado para sa user, saka mag-yield bago magpatuloy. Nagbibigay ito ng pagkakataon sa browser na iproseso ang input at rendering sa pagitan ng mga batch.
Kung sinusuportahan, ang scheduler.yield() ay nag-yield sa main thread at nagpapatuloy ng trabaho mamaya; i-feature-detect ito at gumamit ng fallback para sa mga browser na hindi sinusuportahan. Huwag mag-yield pagkatapos ng bawat napakaliit na operasyon: may overhead ito at maaaring magpahaba ng kabuuang oras ng pagkumpleto. Pumili ng mga hangganan mula sa mga sukat, panatilihin ang cancellation, at iwasang pahintulutang palitan ng stale results ang mas bagong state.
Ipakita ang pagtanggap o progreso bago ang nonvisible follow-up work.
Mag-yield bago ang nasusukat na trabaho ay maging long, sa halip na isang beses kada item.
Ang kasalukuyang web.dev guidance ay hindi nagrerekomenda ng bagong estratehiya batay sa isInputPending().
Ilipat ang compute, hindi ang interface, sa worker
Ang isang Web Worker ay nagpapatakbo ng script sa background thread na hiwalay sa main execution thread. Akma ito para sa mabibigat na parsing, data transformation, search indexing, at iba pang computation na hindi kailangan ng direktang access sa interface. Magpadala ng defined input, ibalik ang defined result, at panatilihin ang rendering at nakikitang state changes sa main thread.
Hindi universal ang workers. Hindi nila direktang mababago ang DOM o magagamit ang Window, at ang pangkalahatang message communication ay nagko-copy ng data. Ang paglikha ng worker, paglipat ng data, at koordinasyon ng error ay maaaring lumampas sa benepisyo para sa maliit na kalkulasyon. Sukatin ang buong interaction, i-terminate ang hindi kinakailangang workers, at magdisenyo ng fallback kung mabibigo ang worker work.
Magsimula sa kalkulasyon na ang input at output ay maaaring i-serialize at subukan.
Itapon ang mga resulta na ginawa para sa mas lumang filter, ruta, o aksyon.
I-komunika ang makahulugang progreso sa pamamagitan ng normal na interface.
Pamahalaan ang third-party JavaScript bilang production dependency
Maaaring magdagdag ang analytics, advertising, experiments, social embeds, video players, at support widgets ng requests, JavaScript evaluation, iframes, at dependencies. Maaaring kailanganin ang vendor script, ngunit ito ay nasa labas ng direktang kontrol ng application team at maaaring makaapekto sa performance, privacy, security, at continuity. I-inventory ang layunin nito, mga ruta, loading condition, approver, consent requirement, at removal owner.
Kung pinapayagan ng mga kondisyon at kontrata, ihambing ang isang kinatawang pahina na may at walang isang third-party origin. Maaaring ilantad ng mga performance tool ang magastos na evaluation, payload, at pagtukoy kung aling long task ang nauugnay dito. Panatilihin lamang ang magaan o ipinagpalibang integration kapag ang dokumentadong pakinabang nito ay nagbibigay-katwiran sa nasusukat na gastos. Tiyaking gumagana ang pangunahing content at pangunahing transaksyon kapag mabagal o wala ang isang opsyonal na dependency.
I-load ang tag lamang sa mga ruta at kondisyon na nangangailangan nito.
Isama ang mga pagbabago sa tag-manager sa performance, privacy, security, at rollback review.
Idokumento at subukan kung paano i-disable ang hindi-kritikal na integration.
Gawing release safeguard ang responsiveness
Gawing maliit na regression check ang winning trace para sa mahalagang journey. Tukuyin ang sakop na interactions, device o CPU constraint, inaasahang tugon, at reviewer. Ipaloob ito sa bundle at third-party inventory review upang ang bagong package o tag ay hindi makapagpakilala nang tahimik ng main-thread work.
Ginagamit ng Status Is UP ang ebidensyang ito para sa proactive optimization at ligtas na remedyo, hindi bilang kapalit ng live availability monitoring. Bago ang high-risk na pagbabago, maghanda ng rollback at i-verify ang kritikal na daloy pagkatapos ng release. Nag-iiba ang resulta ayon sa device, network, browser, content, at account state; tratuhin ang mga threshold bilang guardrails, hindi garantiya.
Kailangang may before-and-after traces para sa shared navigation, checkout, search, o malalaking bundle.
Alamin ang feature flag, tag setting, o bersyon ng deployment na magbabalik sa napatunayang maayos na pagganap.
Muling i-profile pagkatapos ng malalaking release, pagbabago ng vendor, o pagbabago sa device mix.