Avansert React-ytelse: Fra utviklerbygg til webarbeidere

Home » Python » Avansert React-ytelse: Fra utviklerbygg til webarbeidere

React kan føles lynraskt rett ut av esken, men etter hvert som appen din vokser, er det overraskende enkelt å legge til subtile ytelsesregresjoner. som forvandler smidige grensesnitt til trege, batterislukende monstre. Lange lister, tunge komponenter, vanskelige tilstandsstrukturer og feilsøkingsbygg i produksjon summerer seg helt til brukerne begynner å forlate sidene dine.

Den gode nyheten er at React leveres med en omfattende verktøykasse for å måle, forstå og forbedre gjengivelsesytelsen., og det omkringliggende økosystemet (bundlere, profilere, vindusbiblioteker, Web Workers, SSR-rammeverk) gir deg alt du trenger for å holde brukergrensesnittet ditt pent selv i stor skala. I denne veiledningen skal vi gå gjennom disse verktøyene i dybden, vise hvordan de passer sammen og fremheve noen mindre åpenbare triks som team ofte hopper over, men som absolutt er verdt det.

Bruk riktig React-bygg: utvikling, produksjon og profilering

Den aller første ytelsestesten for enhver React-app er å bekrefte at du sender produksjonsbygget, ikke utviklingsbygget.Utviklerversjonen inkluderer massevis av brukervennlige advarsler, ekstra kontroller og feilsøkingshjelpemidler som er fantastiske under koding, men merkbart tregere og større i produksjon.

Du kan bekrefte hvilken versjon du bruker med nettleserutvidelsen React Developer ToolsNår du åpner et nettsted med React, har utvidelsesikonet en mørk bakgrunn i produksjon og en rød bakgrunn i utvikling. Hvis du noen gang ser rødt på det aktive nettstedet ditt, lekker bundlerkonfigurasjonen din feil build.

For prosjekter som er startet opp med Create React App, er det like enkelt å generere en optimalisert produksjonspakke som å kjøre byggeskriptet ditt., som sender ut en minimert bunt inn i build/ katalog. Under lokal utvikling bør du holde deg til npm start (eller tilsvarende) og bare kjøre produksjonsbygget for distribusjon eller for realistiske ytelsestester.

Hvis du bruker UMD-enkeltfilsbyggene av React og React DOM (for eksempel i et ikke-bundlet miljø), sørg for at du inkluderer filene som slutter på . .production.min.jsAlle ikke-minimerte filer eller filer som ikke er produksjonsfiler er kun ment for utvikling og vil føre til unødvendig feilsøkingskostnader for brukerne dine.

Bundlere: Browserify, Rollup, Brunch og webpack

Ulike pakkeløsninger krever ulike justeringer for å fullt ut aktivere Reacts produksjonsoptimaliseringer., men de følger alle den samme underliggende ideen: sett miljøet til produksjon, fjern kun-utviklergrener og minimer den resulterende JavaScript-koden.

Med Brunch er den anbefalte tilnærmingen å installere en minifier-plugin som for eksempel terser-brunch, og kjør deretter byggingen din med produksjonsflagget (for eksempel med -pDenne konfigurasjonen sikrer at advarsler under utviklingstid fjernes, og at den endelige pakken komprimeres aggressivt.

For Browserify kjeder du vanligvis noen transformasjoner i en bestemt rekkefølge.: først søke envify globalt å injisere NODE_ENV="production", og bruk deretter uglifyify globalt for å slette utviklingsimporter og kodestier, og til slutt sende pakken gjennom terser for mangling og komprimering. Rekkefølgen er viktig her fordi hvert trinn forbereder koden for neste transformasjon.

Når du bruker Rollup, kobler du til en trio av plugins for å oppnå en lean produksjonskonstruksjon: replace setter miljøet til produksjon, commonjs tillater samling av CommonJS-moduler, og terser utfører den siste minifiseringen og manglingen. Denne kombinasjonen produserer en liten, produksjonsklar pakke uten de utviklervennlige hjelperne.

Med webpack 4 og nyere aktiverer aktivering av produksjonsmodus automatisk mange optimaliseringer, inkludert minifisering.. Innstilling mode: 'production' ledninger i Terser under panseret og aktiverer Reacts produksjonsatferd så lenge som NODE_ENV treff. Du trenger vanligvis ikke å legge til en separat minifikator med mindre du har svært spesifikke krav.

Profilering av React-bygg

I tillegg til vanlige utviklings- og produksjonsbygg tilbyr React også en spesiell profileringsbygg fokusert på ytelsesanalyse.Denne varianten av instrumentene reagerer internt slik at verktøy som DevTools Profiler kan samle inn svært detaljert tidsinformasjon.

For å bruke profileringsbygget i et nettlesermiljø, importerer du react-dom/profiling istedenfor react-dom/client og konfigurerer vanligvis et alias for en bundler, slik at du ikke trenger å berøre hver import manuelt. Noen rammeverk eksponerer allerede et flagg eller en modus for å slå av og på denne oppførselen for deg.

Tidligere versjoner av React (før 17) var avhengige av standard User Timing API. å sende ut merker og målinger som er synlige i nettleserens Ytelsespanel. Moderne React kobler disse funksjonene med den dedikerte Profiler-fanen i React DevTools, slik at du kan gå direkte inn i komponenter.

Forstå og måle React-ytelse

Du kan ikke fikse det du ikke måler, så ytelsesarbeid i React bør alltid starte med profilering.Det betyr å bruke nettleserverktøy og React-spesifikke profiler for å se hvor tiden faktisk brukes og hvilke komponenter som gjengis mer enn de burde.

Chrome DevTools-ytelsespanelet er grunnlaget for å forstå hva nettleseren gjør.JavaScript-utførelse, nettverksforespørsler, layout, maling, forsinkelser i hendelsesløkker og tilpassede spor vises alle på en enhetlig tidslinje. React integreres i denne visningen med spesialiserte spor som eksponerer rammeverksspesifikk aktivitet.

Modern React eksponerer spor for planleggere, komponenter og servere som stemmer overens med vanlige nettleserspor.Dette gir deg en synkronisert oversikt over nettverks-, JavaScript- og React-oppdateringer, noe som er ekstremt nyttig når du jakter på useriøse funksjoner eller merkelige stalls som bare dukker opp under belastning.

Planleggersporing og gjengivelsesfaser

Scheduleren er en intern React-abstraksjon som orkestrerer arbeid med forskjellige prioriteringer.I ytelsesspor ser du separate underspor for blokkeringsarbeid (ofte synkrone brukerdrevne oppdateringer), overgangsarbeid (bakgrunnsoppdateringer av brukergrensesnittet utløst av startTransition), Spenningsrelaterte oppgaver og inaktivt arbeid som kjører når ingenting mer presserende pågår.

Hver rendering går gjennom flere forskjellige faser du kan inspisere på tidslinjenen oppdateringsfase (hva som utløste renderingen), en renderingsfase (der React kaller komponentene dine og bygger det neste treet), en commit-fase (der DOM-en muteres og layouteffekter som useLayoutEffect løp) og en gjenværende effektfase (der passive effekter som useEffect kjører vanligvis etter maling).

Kaskadeoppdateringer – tilstandsendringer planlagt under en gjengivelse – er en klassisk kilde til skjulte ytelsesproblemer.Under utvikling kan React flagge disse i tidslinjen og til og med vise hvilken komponent og metode som planla den ekstra oppdateringen, noe som hjelper deg med å unngå utilsiktede renderingsløkker eller gjentatt arbeid.

Komponentspor: flammegrafer for gjengivelser og effekter

Komponentsporet visualiserer hvor lang tid det tar å gjengi hver komponent (og dens etterkommere). ved hjelp av en flammegraf. Jo bredere blokken på grafen er, desto mer tid brukte komponentundertreet på den gjengivelsesprosessen.

React eksponerer også effektvarigheter som en separat flammegraf. med et fargeskjema som speiler den tilsvarende fasen i planleggersporet, slik at du raskt kan skille gjengivelsestid fra effekttid.

Ytterligere hendelser som monteringer, avmonteringer, gjentilkoblinger og frakoblinger vises som merknader på disse flammegrafene.For eksempel vil det bli merket å montere en ny del av treet eller å rive ned en, og noen funksjoner som <Activity> Komponentene får sine egne markører for tilkobling/frakobling.

I utviklingsprogrammet vil det å klikke på en renderingsoppføring i komponentsporet avsløre hvilke rekvisitter som er endret., noe som er utrolig nyttig når du prøver å spore opp unødvendige gjengivelser eller rekvisitter som stadig endrer referanser uten å faktisk endre verdi.

Serverspor: forespørsler og serverkomponenter

Hvis du bruker React Server Components, kan ytelsesverktøy også avdekke serversideatferd.Et spor for «serverforespørsler» samler løfter som til slutt mater data inn i serverkomponenter, inkludert kall til fetch eller asynkrone filsystemoperasjoner.

React forsøker å gruppere løfter opprettet i tredjepartshjelpere i ett enkelt spann. så du vil se én logisk operasjon som for eksempel getUser snarere enn et dusin lavnivå fetch anrop. Hvis du klikker på et spenn, vises hvor det ble opprettet, og hvis tilgjengelig, den løste verdien eller avvisningsårsaken.

Et separat spor for serverkomponenter viser hvor lang tid det tar å få serverkomponenttrær og deres ventede løfter., også i flamegraph-form. Når React kan gjengi serverkomponenter samtidig, oppretter det et primært spor og ekstra parallelle spor. Hvis samtidigheten overstiger et visst antall, grupperes ekstra arbeid for å holde visningen lesbar.

Redusere unødvendige gjengivelser: React.memo, useMemo, useCallback og PureComponent

En av de største og vanligste ytelsestabene i React-apper er unødvendig re-renderingHver gang en overordnet komponent oppdateres, gjengis de underordnede komponentene på nytt som standard, selv om inndataene (props) deres er identiske og utdata-DOM-en faktisk ikke ville endret seg.

React tilbyr flere verktøy for å redusere dette bortkastede arbeidet: React.memo for funksjonelle komponenter, React.PureComponent for klassekomponenter, og useMemo/useCallback kroker for å stabilisere verdier som er gitt videre som rekvisitterDisse løser ikke alle ytelsesproblemer på magisk vis, men brukt med omtanke kan de utgjøre en stor forskjell.

React.memo pakker inn en funksjonell komponent og hopper over ny rendering når rekvisittene er omtrent like de forrige.Dette er mest verdifullt når en komponent gjengis ofte med de samme rekvisittene, har tung gjengivelseslogikk eller du har bevis fra Profiler på at det er en flaskehals.

Når du husker en komponent, må du også sørge for at rekvisittene ikke endrer identitet unødvendig.Hvis du oppretter et nytt objekt eller en innebygd funksjon i den overordnede JSX-en på hver gjengivelse, vil den overfladiske sammenligningen ugyldiggjøres og barnet må gjengis på nytt, selv om de logiske dataene er de samme.

Dette er hvor useMemo og useCallback kom inn: useMemo stabiliserer objekt- eller matriseverdier avledet fra andre tilstander, slik at de bare endres når avhengighetene deres gjør det, og useCallback gir stabile funksjonsreferanser for tilbakekallinger sendt til memo-registrerte underordnede.

Klassekomponenter: shouldComponentUpdate og React.PureComponent

Under panseret koker de fleste React-renderingsoptimaliseringer ned til å kontrollere om shouldComponentUpdate returnerer sann eller usannStandardimplementeringen returnerer alltid `true`, som betyr at enhver prop- eller tilstandsendring utløser en gjengivelse og avstemming for den komponenten og dens undertre.

Ved å overstyre shouldComponentUpdate, kan du kortslutte arbeid for undertrær som ikke trenger å oppdateresHvis du returnerer false, vil ikke React kalle render() for den komponenten eller noen av dens etterkommere, og den vil ikke engang sammenligne de nye og gamle virtuelle DOM-nodene for den delen av treet.

Tenk deg et lite komponenttre der noen noder returnerer usann fra shouldComponentUpdateReact kan hoppe over traversering til disse grenene fullstendig, mens andre noder der metoden returnerer sann vil bli fullstendig behandlet. Til slutt vil bare noder hvis gjengitte utdata faktisk endres forårsake DOM-mutasjoner.

Fordi det å skrive tilpasset shouldComponentUpdate Logikken er repeterende, React leveres React.PureComponent, som implementerer en overfladisk sammenligning av nåværende og tidligere props og tilstand. Hvis ingenting endres overfladisk, kan React trygt hoppe over å gjengi den klassekomponenten på nytt.

Uforanderlighet og hvorfor overfladisk sammenligning kan mislykkes

Overfladisk sammenligning antar at hvis en verdi endres, vil referansen endres – en antagelse som brytes i det øyeblikket du muterer eksisterende matriser eller objekter på plass.Dette er en klassisk kilde til feil når man kombinerer uforanderlighetsbaserte optimaliseringer med foranderlige datastrukturer.

Tenk deg a ListOfWords komponent som mottar en words array og gjengir dem kommaseparerte, sammen med en forelder WordAdder komponent som skyver et nytt ord inn i den samme tabellen. Hvis ListOfWords strekker PureComponent, vil den overfladiske sammenligningen se den samme arrayreferansen og anta at ingenting er endret, så brukergrensesnittet vil ikke oppdateres.

Løsningen er å unngå å mutere props eller state direkte, og i stedet opprette nye arrays eller objekter når data endres.. I stedet for words.push(newWord), ville du bruke words.concat(newWord) eller spredningssyntaksen [...words, newWord], som oppretter en ny referanse for arrayet og utløser riktige oppdateringer.

Det samme prinsippet gjelder for objekter: i stedet for å omfordele colormap.right = 'blue' på et eksisterende objekt, ville du returnere et nytt objekt ved å bruke Object.assign({}, colormap, { right: 'blue' }) eller objektspredningssyntaksen { ...colormap, right: 'blue' }Dette garanterer at overfladisk sammenligning ser en ny referanse og gjenkjenner endringen.

Når data blir dypt nestet, kan det bli uhåndterlig å opprettholde uforanderlighet manueltBiblioteker som Immer eller immutability-helper lar deg skrive kode som ser imperativ og mutativ ut, samtidig som de internt produserer nye uforanderlige strukturer, noe som fungerer fint sammen med PureComponent og React.memo.

Virtualisering av lange lister og tunge brukergrensesnitt

Å gjengi hundrevis eller tusenvis av DOM-noder samtidig er en av de raskeste måtene å redusere React-ytelsen på., spesielt på rimelige enheter eller når det kombineres med komplekse oppsett og bilder. Selv med effektiv avstemming er det dyrt å bare ha så mange noder i minnet og på skjermen.

Vindusbygging, eller listevirtualisering, takler dette ved bare å gjengi den delen av en liste som for øyeblikket er synlig i visningsporten.Etter hvert som brukeren blar, monterer React nye elementer som kommer inn i visningen og avmonterer de som blar ut, slik at antallet gjengitte rader holdes omtrent konstant.

Populære biblioteker som react-window og react-virtualized tilby gjenbrukbare komponenter for lister, rutenett og tabeller som implementerer effektive virtualiseringsstrategier. De håndterer matematikken rundt hvilke elementer som skal gjengis, størrelse, rulling av containere og til og med uendelig lasteatferd.

Oppsett av virtualisering innebærer vanligvis tre deler: velge riktig komponent (for eksempel, FixedSizeList for ensartede rader eller VariableSizeList for dynamiske høyder), noe som gir beholderen en fast høyde med overflow: scroll, og gjengir kun elementkomponenten biblioteket ber om, vanligvis husket med React.memo for å unngå unødvendige gjengivelser.

Virtualisering gjør det bra, og sørger for jevn rulleytelse og lavt minneforbruk selv for massive datasettEkte apper har brukt denne teknikken til å effektivt bla gjennom enorme samlinger – musikkanmeldelser, e-handelskataloger, innbokser – uten at brukergrensesnittet stopper opp.

Tilgjengelighet krever litt ekstra oppmerksomhet med virtualiserte listerDu må sørge for at tastaturnavigasjonen fungerer, at fokus styres riktig når elementer monteres og avmonteres, og at skjermlesere har nok kontekst gjennom ARIA-attributter til å forstå den synlige delen av listen.

Tilstandsstyring, virtuell DOM og komponentstruktur

Den virtuelle DOM-en blir ofte misforstått som en mirakelløsning, men den er egentlig bare et smart differensieringslag.React vedlikeholder en representasjon av brukergrensesnittet ditt i minnet og sammenligner det nye treet med det gamle for å avgjøre hvilke DOM-operasjoner som er strengt nødvendige.

Selv med den effektiviteten koster hver gjengivelse og diff fortsatt tid, så målet ditt er å minimere hvor ofte store undertrær må gjengis på nytt.Det er her tilstandsstyring, komponentgrenser og memoiseringsstrategier møtes.

Først, velg en passende tilstandsstyringsstrategi for appens kompleksitetLokal React-tilstand (useState, useReducer) er liten og enkel for små komponenter, mens biblioteker som Redux eller lette butikker som Zustand kan sentralisere mer kompleks global tilstand med optimaliserte abonnementsmønstre.

For det andre, strukturer staten din slik at relaterte data grupperes på en fornuftig måte.Noen ganger betyr det å konsolidere flere useState kall til et enkelt objekt slik at oppdateringene er sammenhengende; i andre tilfeller er det mer effektivt å dele tilstand slik at uavhengige bekymringer ikke tvinger hverandre til å gjengis på nytt.

Når du oppdaterer tilstand utledet fra tidligere verdier, bruk alltid funksjonelle oppdateringer slik som setCount(prev => prev + 1), og opprettholde uforanderlighet ved å klone arrayer og objekter i stedet for å mutere dem på plass. Dette fører til forutsigbar oppførsel og fungerer fint sammen med memoisering og PureComponents.

En nyttig tommelfingerregel er å holde staten så lokal som muligJo høyere opp i treet du lagrer en tilstandsverdi, desto flere komponenter vil gjengis på nytt når den endres. Å skyve tilstanden ned til komponentene som faktisk bruker den, begrenser eksplosjonsradiusen for hver oppdatering.

Til slutt, del opp store komponenter i mindre, fokuserte deler hvis rekvisitter sjelden endresMemoriserte bladkomponenter med stabile props reduserer mengden virtuell DOM React trenger å differensieres og forkorter veien til et minimalt sett med DOM-oppdateringer.

Kodesplitting, lat lasting og bedre lasting av ressurser

Størrelsen på JavaScript-pakker er en viktig bidragsyter til dårlig ytelse, spesielt på mobilnettverkHvis det tar flere sekunder å laste ned og analysere React-pakken din, vil brukerne hoppe over siden lenge før de ser det vakre brukergrensesnittet ditt.

Kodesplitting med React.lazy og Suspense hjelper ved å laste komponenter på forespørsel i stedet for å sende alt på forhåndI stedet for å samle alle funksjonene i den første nyttelasten, importerer du dynamisk de delene som bare trengs for bestemte ruter eller interaksjoner.

En vanlig strategi er rutenivådeling, hvor hver side er sin egen del og bare lastes inn når brukeren navigerer til den. Du kan gå videre og dele store funksjonskomponenter eller sjelden brukte paneler, så lenge du pakker dem inn Suspense med et passende reservegrensesnitt.

Lat lasting gjelder også for bilder. legge loading="lazy" til <img> Tagger utsetter lasting av bilder under brettet til de rulles inn i visningen, noe som sparer båndbredde og øker hastigheten på den første malingen. For mer avanserte effekter, biblioteker som react-lazy-load-image-component støtter uskarpe plassholdere og progressiv lasting.

Når man implementerer kodedeling, er det viktig å balansere chunkstørrelser og brukeropplevelse.Overoppdeling kan skape for mange små forespørsler, mens underoppdeling gir deg en tung innledende pakke. Gode reserveløsninger og feilgrenser rundt late komponenter er avgjørende, slik at mislykkede nettverksforespørsler ikke krasjer hele appen.

Serverside-rendering, React Server-komponenter og serverhandlinger

Serverside-rendering (SSR) gjengir React-appen din på serveren og sender HTML til klienten, noe som kan forbedre opplevd ytelse og SEO dramatisk.Brukere ser nyttig innhold raskere, og søkemotorer kan indeksere sidene dine mer pålitelig.

Rammeverk som Next.js gjør SSR og strømming av HTML praktisk for hverdagsapperDu henter data på serveren, gjengir komponenter til HTML – noen ganger til og med som en strøm – og hydrerer deretter den markupen på klienten slik at den blir interaktiv.

Utover klassisk SSR, flytter React Server Components mer av brukergrensesnittlogikken din til serversiden., slik at du kan gjengi komponenter som aldri sendes til klienten i det hele tatt. Dette kan redusere størrelsen på klientbuntene betydelig og forenkle datahenting, siden serverkomponenter kan kalle databaser eller API-er direkte.

Serverhandlinger utvider denne ideen ved å la deg definere funksjoner som kjører på serveren, men som utløses fra klientkomponenter.Dette eliminerer mange standard REST-endepunkter eller skreddersydde API-håndterere, og kan effektivisere hvordan du håndterer mutasjoner, skjemainnsendinger og andre tilstandsfulle operasjoner.

Brukt sammen gir SSR, serverkomponenter og serverhandlinger deg et spekter av gjengivelsesstrategier.Kritisk innhold kan strømmes raskt fra serveren, tung logikk forblir utenfor klienten, og React-kjøretiden setter alt sammen til en sammenhengende brukeropplevelse.

Avlaste tungt arbeid med Web Workers

Selv det best optimaliserte React-treet vil hakke hvis du kjører CPU-tunge oppgaver på hovedtråden.Dyre beregninger blokkerer gjengivelse, forsinker hendelseshåndtering og gjør at appen din føles uresponsiv.

Nettarbeidere gir en måte å flytte de tunge oppgavene til en bakgrunnstrådDu sender data til arbeideren, lar den analysere tallene eller behandle store datasett, og mottar deretter resultatet tilbake via meldingsoverføring, slik at hovedtråden er fri til å håndtere UI-oppdateringer.

Typiske arbeidsbelastninger for nettarbeidere inkluderer dataknusing, bildebehandling, sanntidsanalyse eller komplekse simuleringer.For eksempel delegerer spill bygget med webstacken ofte kjernelogikk i spillet til en arbeider, mens hovedtråden er dedikert til gjengivelse og inputhåndtering.

Å integrere en arbeider med React innebærer å opprette en separat skriptfil, lytte etter onmessage inne i arbeideren og sende meldinger fra komponentene dineI komponenten instansierer du arbeideren, sender den inndata med postMessage og oppdater tilstanden når den svarer, ideelt sett rydder man opp i arbeideren når komponenten avmonteres.

Biblioteker som Comlink, Workerize eller Bundler-pluginer kan forenkle dette mønsteret ved å abstrahere bort lavnivåmeldingsoverføringen og gi deg et API som føles som å kalle asynkrone funksjoner, noe som er enklere å resonnere rundt i en React-kodebase.

Viktige nettleser- og brukersentrerte målinger å følge med på

På et høyere nivå spores vanligvis den generelle nettytelsen ved hjelp av brukersentrerte målinger. som for eksempel Første innholdsrike maling (FCP), Største innholdsrike maling (LCP) og Tid til interaksjon (TTI). Disse gir deg en følelse av hvor raskt brukere ser innhold og hvor snart de faktisk kan samhandle med det.

Healthy React-apper sikter mot FCP under omtrent 1.8 sekunder, LCP under omtrent 2.5 sekunder og TTI godt under 4 sekunder på typiske enheter., selv om de nøyaktige tersklene kan variere fra prosjekt til prosjekt. Hvis du konsekvent overskrider disse tallene, er det et tegn på at pakkene, gjengivelsesstrategien eller serverresponstidene dine trenger arbeid.

Verktøy som Lighthouse, WebPageTest og Chromes ytelsespanel hjelper deg med å måle disse beregningene i syntetiske testmiljøer.For innsikt i den virkelige verden sporer RUM-verktøy (Real User Monitoring) som SpeedCurve, Datadog, LogRocket eller Sentry faktiske brukerøkter og kobler trege opplevelser tilbake til kodeendringer.

Reacts eget Profiler API integreres pent med dette bildetdu kan pakke inn deler av treet ditt <Profiler>, logge trege gjengivelser og korrelere dem med spesifikke brukerflyter. Når det brukes sammen med backend- og nettverksovervåking, gir dette deg en fullstendig ende-til-ende-oversikt over ytelsen.

Praktisk teamarbeidsflyt for ytelsesjustering

I virkelige prosjekter fungerer ytelsesjustering best når den behandles som en repeterbar arbeidsflyt i stedet for en engangsopprydding.En enkel firefaseløkke – identifiser, undersøk, implementer, bekreft – bidrar til å forhindre tilfeldige mikrooptimaliseringer og holder innsatsen fokusert der den betyr noe.

Identifisering betyr å bruke profiler, målinger og brukerrapporter for å finne konkrete symptomer som for eksempel trege sider, lave bildefrekvenser eller høy grad av avbrudd under visse flyter. Du ønsker målbare problemer, ikke magefølelse.

Etterforskning graver i rotårsakenKanskje en side inneholder dusinvis av skjulte iframes, kanskje en bestemt komponent gjengis altfor ofte, eller kanskje et enormt leverandørbibliotek lastes inn på hver rute. Her lener du deg tungt på React DevTools Profiler og Chromes tidslinje.

Implementering er der du bruker målrettede løsninger– å huske en aktiv komponent, virtualisere en lang liste, dele en bunt, avlaste arbeid til en webarbeider eller aktivere SSR for bestemte sider. Hver endring bør være liten nok til at det er mulig å resonnere over den.

Bekreftelse er det siste steget og ofte det mest oversetteDu kjører profileringsscenariene dine på nytt og sjekker måleinstrumentbordene dine for å forsikre deg om at endringen faktisk forbedret tallene og ikke introduserte regresjoner andre steder i systemet.

Når du kombinerer riktig React-bygg, gjennomtenkt memoisering, uforanderlige tilstandspraksiser, listevirtualisering, strategisk kodedeling, SSR, Web Workers og kontinuerlig måling, ender du opp med React-applikasjoner som holder seg raske og responsive selv når de blir mer komplekse.Teknikkene ovenfor handler ikke om for tidlig mikrotuning, men om å bygge en arkitektur der ytelse forblir et naturlig biprodukt i stedet for en konstant skuddveksling.