Napredna zmogljivost Reacta: od razvojnih gradenj do spletnih delavcev

Domov » Python » Napredna zmogljivost Reacta: od razvojnih gradenj do spletnih delavcev

React se lahko zdi bliskovito hiter že od samega začetka, toda ko vaša aplikacija raste, je presenetljivo enostavno dodati subtilne regresije delovanja. ki gladke vmesnike spremenijo v počasne, baterijsko lačne pošasti. Dolgi seznami, težke komponente, nerodne strukture stanj in gradnje za odpravljanje napak v produkciji se seštevajo, dokler uporabniki ne začnejo zapuščati vaših strani.

Dobra novica je, da React ponuja bogat nabor orodij za merjenje, razumevanje in izboljšanje učinkovitosti upodabljanja., in okoliški ekosistem (združevalniki, profilirniki, knjižnice za delo z okni, spletni delavci, ogrodja SSR) vam ponuja vse, kar potrebujete, da bo vaš uporabniški vmesnik oster tudi v velikem obsegu. V tem priročniku bomo podrobno pregledali ta orodja, pokazali, kako se med seboj ujemajo, in izpostavili nekaj manj očitnih trikov, ki jih ekipe pogosto preskočijo, vendar se vsekakor splača.

Uporabite pravo React gradnjo: razvoj, produkcija in profiliranje

Prvo preverjanje delovanja katere koli React aplikacije je preverjanje, ali pošiljate produkcijsko različico in ne razvojne.Razvojna različica vključuje ogromno prijaznih opozoril, dodatnih preverjanj in pomočnikov za odpravljanje napak, ki so fantastični med kodiranjem, a opazno počasnejši in večji v produkciji.

Katero gradnjo uporabljate, lahko preverite z razširitvijo brskalnika React Developer Tools.Ko odprete spletno mesto z uporabo Reacta, ima ikona razširitve v produkcijskem okolju temno ozadje, v razvojnem okolju pa rdeče ozadje. Če na svojem spletnem mestu v živo kdaj vidite rdečo barvo, vaša konfiguracija paketa pušča napačno različico.

Za projekte, ki so bili zagnani s Create React App, je ustvarjanje optimiziranega produkcijskega paketa tako preprosto kot zagon skripta za gradnjo., ki v izhod vnese minimiziran sveženj build/ imenik. Med lokalnim razvojem se morate držati npm start (ali enakovredno) in zaženite produkcijsko različico samo za uvajanje ali za realistične meritve zmogljivosti.

Če se zanašate na enodatotečne gradnje UMD za React in React DOM (na primer v okolju brez paketa), se prepričajte, da vključite datoteke, ki se končajo z .production.min.jsVsaka neminimificirana ali neprodukcijska datoteka je namenjena samo razvoju in bo vašim uporabnikom povzročila nepotrebne stroške odpravljanja napak.

Paketi: Browserify, Rollup, Brunch in webpack

Različni paketniki zahtevajo različne nastavitve, da v celoti omogočijo optimizacije produkcije Reacta., vendar vsi sledijo isti osnovni ideji: nastaviti okolje na produkcijsko, odstraniti veje samo za razvoj in zmanjšati nastali JavaScript.

Pri Brunchu je priporočen pristop namestitev vtičnika za minifier, kot je na primer terser-brunch, nato pa zaženite gradnjo s produkcijsko zastavico (na primer z -p). Ta konfiguracija zagotavlja, da so opozorila v času razvoja odstranjena in da je končni sveženj agresivno stisnjen.

Pri Browserifyju običajno povežete nekaj transformacij v določenem vrstnem redu: najprej se prijavi envify globalno za injiciranje NODE_ENV="production", nato pa uporabite uglifyify globalno za izbris razvojnih uvozov in poti kode ter končno prenos svežnja skozi terser za popačenje in stiskanje. Vrstni red je tukaj pomemben, ker vsak korak pripravi kodo za naslednjo transformacijo.

Ko uporabljate Rollup, povežete trio vtičnikov, da dosežete vitko produkcijsko gradnjo.: replace nastavi okolje za produkcijo, commonjs omogoča združevanje modulov CommonJS in terser izvede končno minifikacijo in mangling. Ta kombinacija ustvari majhen, produkcijsko pripravljen paket brez pomočnikov, ki so namenjeni samo razvijalcem.

Z različico webpack 4 in novejšimi omogočanje produkcijskega načina samodejno aktivira številne optimizacije, vključno z minifikacijo.. Nastavitev mode: 'production' žice v Terserju pod pokrovom in omogočajo produkcijsko vedenje Reacta, dokler NODE_ENV ujema se. Običajno vam ni treba dodati ločenega programa za zmanjšanje števila, razen če imate zelo specifične zahteve.

Profiliranje gradenj Reacta

Poleg običajnih razvojnih in produkcijskih različic React ponuja tudi posebno gradnjo profiliranja, osredotočeno na analizo zmogljivosti.Ta različica interno oroduje React, tako da lahko orodja, kot je DevTools Profiler, zbirajo zelo podrobne informacije o času.

Če želite uporabiti gradnjo profiliranja v okolju brskalnika, uvozite react-dom/profiling Namesto react-dom/client in običajno konfigurirajte vzdevek paketnika, da se vam ni treba ročno dotikati vsakega uvoza. Nekateri ogrodji že ponujajo zastavico ali način za preklop tega vedenja.

Starejše različice Reacta (pred 17) so se zanašale na standardni API za določanje časa uporabnika za oddajanje oznak in meritev, vidnih na plošči Performance v brskalniku. Modern React te zmožnosti združuje z namenskim zavihkom Profiler v orodjih React DevTools, tako da lahko neposredno podrobno pregledate komponente.

Razumevanje in merjenje učinkovitosti delovanja Reacta

Ne moreš popraviti tistega, česar ne meriš, zato se mora delo na učinkovitosti delovanja v Reactu vedno začeti s profiliranjem.To pomeni uporabo orodij za brskalnik in profilerjev, specifičnih za React, da se vidi, kje se dejansko porablja čas in katere komponente se ponovno upodabljajo pogosteje, kot bi se smele.

Plošča Performance v orodjih za razvoj brskalnika Chrome je vaša osnova za razumevanje delovanja brskalnika.Izvajanje JavaScripta, omrežne zahteve, postavitev, slikanje, zakasnitve zanke dogodkov in sledi po meri se prikazujejo na enotni časovnici. React se integrira v ta pogled s specializiranimi sledmi, ki razkrivajo dejavnosti, specifične za ogrodje.

Modern React razkriva sledi razporejevalnika, komponent in strežnika, ki se ujemajo z običajnimi sledmi brskalnikaTo vam omogoča sinhroniziran pogled na posodobitve omrežja, JavaScripta in Reacta, kar je izjemno uporabno, ko loviš čudne zastoje ali napake, ki se pojavijo le pod obremenitvijo.

Faze sledenja in upodabljanja razporejevalnika

Razporejevalnik je notranja abstrakcija Reacta, ki orkestrira delo z različnimi prioritetami.V sledeh delovanja boste videli ločene podsledi za blokiranje dela (pogosto sinhrone posodobitve, ki jih sprožijo uporabniki), prehodno delo (posodobitve uporabniškega vmesnika v ozadju, ki jih sprožijo startTransition), naloge, povezane z napetostjo, in delo v mirovanju, ki se izvaja, ko ni nič bolj nujnega.

Vsak prehod upodabljanja gre skozi več različnih faz, ki si jih lahko ogledate na časovnicifaza posodabljanja (kaj je sprožilo upodabljanje), faza upodabljanja (kjer React pokliče vaše komponente in zgradi naslednje drevo), faza potrditve (kjer se DOM mutira in se pojavijo učinki postavitve, kot so useLayoutEffect tek) in faza preostalih učinkov (kjer so pasivni učinki, kot so useEffect običajno teče po barvi).

Kaskadne posodobitve – spremembe stanja, načrtovane med upodabljanjem – so klasičen vir skritih težav z zmogljivostjo.Med razvojem lahko React te označi na časovnici in celo pokaže, katera komponenta in metoda je načrtovala dodatno posodobitev, kar vam pomaga preprečiti nenamerne zanke upodabljanja ali ponavljajoče se delo.

Sled komponent: plameni grafi za upodabljanja in učinke

Sled komponent prikazuje, koliko časa traja upodabljanje posamezne komponente (in njenih potomcev) z uporabo plamenskega grafa. Širši kot je blok na grafu, več časa je poddrevo komponente porabilo za ta prehod upodabljanja.

React tudi izpostavi trajanje učinkov kot ločen flamegraph z barvno shemo, ki odraža ustrezno fazo v sledilnem programu Scheduler, tako da lahko na prvi pogled ločite čas upodabljanja od časa učinka.

Dodatni dogodki, kot so priklopi, odklopi, ponovne povezave in prekinitve povezave, se na teh plamenih grafih prikažejo kot opombe.Na primer, označeno bo montaža novega dela drevesa ali rušenje starega, nekatere značilnosti, kot so <Activity> komponente dobijo lastne označevalnike za ponovno povezavo/prekinitev povezave.

V razvojnem načinu klik na vnos upodabljanja v sledilni vrstici Komponente razkrije, kateri propi so se spremenili, kar je neverjetno uporabno, ko poskušate izslediti nepotrebne upodobitve ali prope, ki nenehno spreminjajo reference, ne da bi dejansko spremenili vrednost.

Strežniške sledi: zahteve in strežniške komponente

Če uporabljate komponente strežnika React, lahko orodja za izboljšanje učinkovitosti delovanja prikažejo tudi vedenje na strani strežnika.Sled »Zahtev strežnika« združuje obljube, ki na koncu posredujejo podatke strežniškim komponentam, vključno s klici na fetch ali asinhrone operacije datotečnega sistema.

React poskuša združiti obljube, ustvarjene v pomočnikih tretjih oseb, v en sam razpon (span). torej boste videli eno logično operacijo, kot je getUser namesto ducata nizkonivojskih fetch klici. S klikom na razpon se prikaže, kje je bil ustvarjen, in če je na voljo, razrešena vrednost ali razlog za zavrnitev.

Ločena sled strežniških komponent prikazuje, koliko časa trajajo drevesa strežniških komponent in njihove pričakovane obljube., tudi v obliki flamegrapha. Ko lahko React sočasno upodablja strežniške komponente, ustvari primarno sled in dodatne vzporedne sledi; če sočasnost preseže določeno število, se dodatno delo združi, da ostane pogled berljiv.

Zmanjšanje nepotrebnih upodabljanj: React.memo, useMemo, useCallback in PureComponent

Ena največjih in najpogostejših izgub zmogljivosti v aplikacijah React je nepotrebno ponovno upodabljanje.Vsakič, ko se nadrejena komponenta posodobi, se njeni podrejeni elementi privzeto ponovno upodobijo, tudi če so njihovi vhodni podatki (props) enaki in se izhodni DOM dejansko ne bi spremenil.

React ponuja več orodij za zmanjšanje tega nepotrebnega dela: React.memo za funkcionalne komponente, React.PureComponent za komponente razreda in useMemo/useCallback kavlji za stabilizacijo vrednosti, ki se prenašajo kot rekvizitiTo sicer ne odpravi čarobno vseh težav z zmogljivostjo, vendar lahko, če se uporablja premišljeno, naredi veliko razliko.

React.memo zavije funkcionalno komponento in preskoči ponovno upodabljanje, ko so njeni propi plitvo enaki prejšnjimTo je najbolj dragoceno, kadar se komponenta pogosto upodablja z istimi lastnostmi, ima preobremenjeno logiko upodabljanja ali če imate iz Profilerja dokaze, da gre za ozko grlo.

Ko komponento memorizirate, morate zagotoviti tudi, da njeni propi ne spreminjajo identitete po nepotrebnem.Ustvarjanje novega objekta ali vgrajene funkcije znotraj nadrejenega JSX pri vsakem upodabljanju bo razveljavilo plitvo primerjavo in prisililo podrejenega k ponovnemu upodabljanju, tudi če so logični podatki enaki.

Tukaj je useMemo in useCallback vstopi: useMemo stabilizira vrednosti objektov ali polj, izpeljane iz drugih stanj, tako da se spremenijo le, ko se spremenijo njihove odvisnosti, in useCallback zagotavlja stabilne reference funkcij za povratne klice, posredovane v pomemizirane podrejene funkcije.

Komponente razreda: shouldComponentUpdate in React.PureComponent

V osnovi se večina optimizacij upodabljanja Reacta zreducira na nadzor nad tem, ali shouldComponentUpdate vrne true ali falsePrivzeta implementacija vedno vrne true, kar pomeni, da vsaka sprememba lastnosti ali stanja sproži upodabljanje in uskladitev za to komponento in njeno poddrevo.

Z razveljavitvijo shouldComponentUpdate, lahko skrajšate delo za poddrevesa, ki jih ni treba posodabljatiČe vrnete false, React ne bo klical. render() za to komponento ali katerega koli od njenih potomcev in niti ne bo primerjal novih in starih virtualnih vozlišč DOM za ta del drevesa.

Razmislite o majhnem drevesu komponent, kjer nekatera vozlišča vrnejo false iz shouldComponentUpdateReact lahko popolnoma preskoči prehod v te veje, medtem ko bodo druga vozlišča, kjer metoda vrne true, v celoti obdelana. Na koncu bodo mutacije DOM povzročila le vozlišča, katerih upodobljeni izhod se je dejansko spremenil.

Ker pisanje po meri shouldComponentUpdate logika se ponavlja, React ladje React.PureComponent, ki implementira plitvo primerjavo trenutnih in prejšnjih lastnosti in stanja. Če se ni nič plitvo spremenilo, lahko React varno preskoči ponovno upodabljanje te komponente razreda.

Nespremenljivost in zakaj lahko plitva primerjava ne uspe

Plitva primerjava predpostavlja, da se bo ob spremembi vrednosti spremenila tudi njena referenca – predpostavka, ki se prekine v trenutku, ko spremenite obstoječa polja ali objekte na mestu.To je klasičen vir hroščev pri kombiniranju optimizacij, ki temeljijo na nespremenljivosti, s spremenljivimi podatkovnimi strukturami.

Predstavljajte si ListOfWords komponenta, ki prejme words matriko in jih loči z vejicami, v paru s staršem WordAdder komponenta, ki potisne novo besedo v isto tabelo. Če ListOfWords Se razširi PureComponent, bo plitva primerjava videla isto referenco polja in predpostavila, da se ni nič spremenilo, zato se uporabniški vmesnik ne bo posodobil.

Rešitev je v tem, da se izognemo neposrednemu spreminjanju lastnosti ali stanja in namesto tega ustvarimo nova polja ali objekte, ko se podatki spremenijo.. Namesto words.push(newWord), bi uporabili words.concat(newWord) ali sintakso širjenja [...words, newWord], ki ustvari novo referenco za tabelo in sproži pravilne posodobitve.

Enako načelo velja za predmete: namesto prerazporeditve colormap.right = 'blue' na obstoječem objektu bi vrnili nov objekt z uporabo Object.assign({}, colormap, { right: 'blue' }) ali sintakso širjenja objektov { ...colormap, right: 'blue' }To zagotavlja, da plitva primerjava vidi novo referenco in prepozna spremembo.

Ko so podatki globoko ugnezdeni, lahko ročno vzdrževanje nespremenljivosti postane nerodno.Knjižnice, kot sta Immer ali immutability-helper, vam omogočajo pisanje kode, ki je videti imperativna in mutativna, hkrati pa interno ustvarja nove nespremenljive strukture, kar se lepo ujema z PureComponent in React.memo.

Virtualizacija dolgih seznamov in zahtevnih uporabniških vmesnikov

Upodabljanje stotin ali tisočev vozlišč DOM hkrati je eden najhitrejših načinov za zmanjšanje zmogljivosti Reacta., zlasti na napravah nižjega cenovnega razreda ali v kombinaciji s kompleksnimi postavitvami in slikami. Tudi z učinkovito uskladitvijo je imeti toliko vozlišč v pomnilniku in na zaslonu drago.

Virtualizacija seznamov ali oken se s tem spopada tako, da upodablja le del seznama, ki je trenutno viden v vidnem polju.Ko se uporabnik pomika, React priklopi nove elemente, ki vstopijo v pogled, in odklopi tiste, ki se pomikajo ven, pri čemer število upodobljenih vrstic ostane približno konstantno.

Priljubljene knjižnice, kot so react-window in react-virtualized zagotovite komponente za večkratno uporabo za sezname, mreže in tabele ki izvajajo učinkovite strategije virtualizacije. Obvladujejo matematiko elementov za upodabljanje, velikost, pomikanje po vsebnikih in celo neskončno nalaganje.

Nastavitev virtualizacije običajno vključuje tri deleizbira ustrezne komponente (npr. FixedSizeList za enakomerne vrste oz. VariableSizeList za dinamične višine), kar daje posodi fiksno višino z overflow: scrollin upodablja samo komponento elementa, ki jo knjižnica zahteva, običajno v memo formatu React.memo da se izognemo nepotrebnim ponovnim upodabljanjem.

Dobro izvedena virtualizacija zagotavlja nemoteno delovanje pomikanja in nizko porabo pomnilnika tudi pri ogromnih naborih podatkov.Aplikacije iz resničnega sveta so to tehniko uporabljale za učinkovito brskanje po ogromnih zbirkah – glasbenih recenzijah, katalogih e-trgovine, nabiralnikih – brez ustavljanja uporabniškega vmesnika.

Dostopnost zahteva nekaj dodatne pozornosti pri virtualiziranih seznamihZagotoviti morate, da navigacija s tipkovnico deluje, da se fokus pravilno upravlja med priklapljanjem in odklapljanjem elementov ter da imajo bralniki zaslona dovolj konteksta prek atributov ARIA, da razumejo trenutno vidni del seznama.

Upravljanje stanja, virtualni DOM in struktura komponent

Virtualni DOM se pogosto napačno razume kot čarobna rešitev, vendar je v resnici le pametna plast za razlikovanje.React vzdržuje predstavitev vašega uporabniškega vmesnika v pomnilniku in primerja novo drevo s starim, da se odloči, katere operacije DOM so nujno potrebne.

Kljub tej učinkovitosti vsako upodabljanje in razlikovanje še vedno zahteva čas, zato je vaš cilj čim bolj zmanjšati pogostost ponovnega upodabljanja velikih poddreves.Tu se križajo upravljanje stanja, meje komponent in strategije pomnjenja.

Najprej izberite ustrezno strategijo upravljanja stanja glede na kompleksnost vaše aplikacijeLokalno stanje React (useState, useReducer) je majhen in preprost za majhne komponente, medtem ko lahko knjižnice, kot je Redux, ali lahke trgovine, kot je Zustand, centralizirajo bolj kompleksno globalno stanje z optimiziranimi vzorci naročnin.

Drugič, strukturirajte svoje stanje tako, da so povezani podatki smiselno združeniVčasih to pomeni združevanje več useState klicev v en sam objekt, tako da so posodobitve koherentne; v drugih primerih je učinkovitejša razdelitev stanja, tako da neodvisni problemi ne silijo drug drugega v ponovno upodabljanje.

Pri posodabljanju stanja, izpeljanega iz prejšnjih vrednosti, vedno uporabite funkcionalne posodobitve kot setCount(prev => prev + 1)in ohraniti nespremenljivost s kloniranjem polj in objektov namesto njihovega spreminjanja na mestu. To vodi do predvidljivega vedenja in se lepo ujema z memoizacijo in PureComponents.

Priročno pravilo je, da država ostane čim bolj lokalnaVišje kot je v drevesu shranjena vrednost stanja, več komponent se bo ponovno upodobilo ob vsaki spremembi. Potiskanje stanja navzdol do komponent, ki ga dejansko uporabljajo, omejuje polmer eksplozije vsake posodobitve.

Končno, velike komponente razdelite na manjše, osredotočene dele, katerih lastnosti se redko spreminjajo.Memoizirane listne komponente s stabilnimi lastnostmi zmanjšajo količino virtualnega DOM-a, ki ga React potrebuje za razlikovanje, in skrajšajo pot do minimalnega nabora posodobitev DOM-a.

Delitev kode, leno nalaganje in boljše nalaganje sredstev

Velikost paketa JavaScript je pomemben dejavnik slabe zmogljivosti, zlasti v mobilnih omrežjihČe prenos in razčlenjevanje vašega paketa React traja več sekund, bodo uporabniki zapustili stran dolgo preden bodo videli vaš čudovit uporabniški vmesnik.

Delitev kode z React.lazy in Suspense pomaga z nalaganjem komponent po naročilu, namesto da se vse pošlje vnaprejNamesto da bi vse funkcije združili v začetni koristni tovor, dinamično uvozite dele, ki so potrebni le za določene poti ali interakcije.

Pogosta strategija je razdelitev na ravni poti, kjer je vsaka stran svoj del in se naloži šele, ko jo uporabnik obišče. Lahko greste še dlje in razdelite velike komponente funkcij ali redko uporabljene plošče, če jih le zavijete v Suspense z ustreznim rezervnim uporabniškim vmesnikom.

Počasno nalaganje velja tudi za slike. Dodajanje loading="lazy" do <img> Oznake odložijo nalaganje slik pod pregibom, dokler se ne pomaknejo v vidno polje, s čimer prihranijo pasovno širino in pospešijo začetno risanje. Za naprednejše učinke so na voljo knjižnice, kot so react-lazy-load-image-component podpira zamegljene nadomestne znake in progresivno nalaganje.

Pri izvajanju delitve kode je pomembno uravnotežiti velikosti blokov in uporabniško izkušnjo.Prevelika razdelitev lahko ustvari preveč drobnih zahtev, premajhna razdelitev pa povzroči težek začetni sveženj. Dobre rezervne rešitve in omejitve napak okoli lenobnih komponent so bistvenega pomena, da neuspele omrežne zahteve ne povzročijo sesutja celotne aplikacije.

Upodabljanje na strani strežnika, komponente strežnika React in dejanja strežnika

Strežniško upodabljanje (SSR) upodobi vašo aplikacijo React na strežniku in pošlje HTML odjemalcu, kar lahko drastično izboljša zaznano zmogljivost in SEO.Uporabniki prej vidijo uporabno vsebino, iskalniki pa lahko zanesljiveje indeksirajo vaše strani.

Okviri, kot je Next.js, omogočajo SSR in pretakanje HTML-ja praktično za vsakodnevne aplikacije.Podatke pridobite na strežniku, komponente upodobite v HTML – včasih celo kot tok – in nato to oznako na odjemalcu hidrirate, da postane interaktivna.

Poleg klasičnega SSR-ja, komponente React Server prenesejo več logike uporabniškega vmesnika na stran strežnika., kar vam omogoča upodabljanje komponent, ki se sploh nikoli ne pošljejo odjemalcu. To lahko znatno zmanjša velikost odjemalskega svežnja in poenostavi pridobivanje podatkov, saj lahko strežniške komponente neposredno kličejo baze podatkov ali API-je.

Dejanja strežnika razširjajo to idejo tako, da vam omogočajo definiranje funkcij, ki se izvajajo na strežniku, vendar jih sprožijo odjemalske komponente.To odpravlja veliko standardnih končnih točk REST ali prilagojenih obdelovalcev API-jev in lahko poenostavi način obravnave mutacij, oddaj obrazcev in drugih operacij, ki upoštevajo stanje.

SSR, strežniške komponente in strežniška dejanja, ki se uporabljajo skupaj, vam ponujajo spekter strategij upodabljanja.: kritično vsebino je mogoče hitro pretakati s strežnika, težka logika ostane stran od odjemalca, izvajalno okolje React pa vse skupaj združi v celovito uporabniško izkušnjo.

Razbremenitev težkega dela s spletnimi delavci

Tudi najbolje optimizirano drevo React se bo zatikalo, če boste v glavni niti izvajali naloge, ki obremenjujejo procesor.Dragi izračuni blokirajo upodabljanje, zamujajo z obdelavo dogodkov in povzročajo, da se vaša aplikacija ne odziva.

Spletni delavci omogočajo prenos teh težkih nalog v nit v ozadju.Podatke pošljete delavcu, pustite, da obdeluje številke ali velike nabore podatkov, nato pa rezultat prejmete nazaj prek posredovanja sporočil, tako da je glavna nit prosta za obravnavo posodobitev uporabniškega vmesnika.

Tipične delovne obremenitve za spletne delavce vključujejo obdelavo podatkov, obdelavo slik, analitiko v realnem času ali kompleksne simulacije.Na primer, igre, zgrajene s spletnim skladom, pogosto prenesejo osnovno logiko igre na delavca, medtem ko je glavna nit namenjena upodabljanju in obdelavi vnosa.

Integracija delavca z Reactom vključuje ustvarjanje ločene skriptne datoteke, ki posluša onmessage znotraj delavca in objavljanje sporočil iz vaših komponentV komponenti ustvarite instanco delavca in mu pošljete vhodne podatke z postMessage in posodobi stanje, ko se odzove, idealno pa je, da se delavec očisti, ko se komponenta odklopi.

Knjižnice, kot so vtičniki Comlink, workerize ali bundler, lahko poenostavijo ta vzorec. z abstrahiranjem nizkonivojskega posredovanja sporočil in zagotavljanjem API-ja, ki deluje kot klicanje asinhronih funkcij, o čemer je lažje razmišljati v kodni bazi React.

Ključne meritve, osredotočene na brskalnik in uporabnika, ki jih je treba spremljati

Na višji ravni se splošna spletna uspešnost običajno spremlja z uporabo metrik, osredotočenih na uporabnika. kot so prvo izrisovanje vsebine (FCP), največje izrisovanje vsebine (LCP) in čas do interakcije (TTI). Ti vam dajo občutek, kako hitro uporabniki vidijo vsebino in kako hitro lahko dejansko komunicirajo z njo.

Aplikacije Healthy React si prizadevajo za FCP pod približno 1.8 sekunde, LCP pod približno 2.5 sekunde in TTI precej pod 4 sekunde na tipičnih napravah., čeprav se natančni pragovi lahko razlikujejo glede na projekt. Če te številke dosledno presegate, je to znak, da je treba izboljšati vaše pakete, strategijo upodabljanja ali odzivne čase strežnika.

Orodja, kot so Lighthouse, WebPageTest in Chromova plošča Performance, vam pomagajo meriti te meritve v sintetičnih testnih okoljih.Za vpogled v resnični svet orodja za spremljanje dejanskih uporabnikov (RUM), kot so SpeedCurve, Datadog, LogRocket ali Sentry, sledijo dejanskim uporabniškim sejam in povezujejo počasne izkušnje s spremembami kode.

React-ov lastni Profiler API se lepo integrira s to slikodele drevesa lahko zavijete v <Profiler>, beležite počasne upodabljanja in jih povežite s specifičnimi uporabniškimi tokovi. Če se to uporablja skupaj z nadzorom zaledja in omrežja, vam to omogoča celovit pregled delovanja.

Praktičen timski potek dela za optimizacijo učinkovitosti delovanja

V resničnih projektih optimizacija zmogljivosti deluje najbolje, če se obravnava kot ponovljiv potek dela in ne kot enkratno čiščenje.Preprosta štirifazna zanka – identifikacija, raziskovanje, izvedba, potrditev – pomaga preprečiti naključne mikrooptimizacije in ohranja prizadevanja osredotočena na tisto, kar je pomembno.

Identifikacija pomeni uporabo profilerjev, metrik in uporabniških poročil za iskanje konkretnih simptomov kot so počasne strani, nizka hitrost sličic na sekundo ali visoka stopnja opustitve med določenimi poteki. Želite merljive težave, ne občutka.

Preiskava odkriva temeljni vzrokMorda stran vsebuje na ducate skritih okvirjev iframe, morda se določena komponenta prepogosto ponovno upodablja ali pa se na vsaki poti nalaga ogromna knjižnica ponudnikov. Tukaj se močno zanašate na React DevTools Profiler in časovnico Chroma.

Izvajanje je tista, kjer uporabite ciljno usmerjene popravke—pomnjenje vroče komponente, virtualizacija dolgega seznama, razdelitev svežnja, prenos dela na spletni delavec ali omogočanje SSR za določene strani. Vsaka sprememba mora biti dovolj majhna, da se o njej lahko premisli.

Potrditev je zadnji korak in pogosto najbolj spregledanPonovno zaženete scenarije profiliranja in preverite nadzorne plošče z meritvami, da se prepričate, da je sprememba dejansko izboljšala številke in ni povzročila regresij drugje v sistemu.

Ko združite pravilno gradnjo Reacta, premišljeno pomnjenje, prakse nespremenljivih stanj, virtualizacijo seznamov, strateško delitev kode, SSR, spletne delavce in neprekinjeno merjenje, dobite aplikacije React, ki ostanejo hitre in odzivne, tudi ko postajajo bolj kompleksne.; pri zgornjih tehnikah ne gre za prezgodnje mikro uglaševanje, temveč za gradnjo arhitekture, kjer zmogljivost ostaja naravni stranski produkt in ne nenehen boj.