- Enviar la compilació correcta de React i optimitzar el vostre paquet (variants de producció i perfilat) és la base per a qualsevol treball seriós de rendiment.
- La creació de perfils amb React DevTools i les pistes de rendiment del navegador revela renders innecessaris, efectes lents i colls d'ampolla del servidor que després podeu atacar.
- La memoització, la immutabilitat i la virtualització treballen conjuntament per reduir la freqüència de renderització, reduir el treball per renderització i mantenir les interfícies d'usuari grans fluides.
- La divisió de codi, l'SSR, els Web Workers i la monitorització contínua garanteixen càrregues inicials ràpides, interaccions amb resposta i un rendiment sostenible a escala.
React pot semblar increïblement ràpid des del primer moment, però a mesura que la teva aplicació creix, és sorprenentment fàcil acumular regressions subtils de rendiment. que converteixen interfícies fluides en monstres lents i afamats de bateria. Llistes llargues, components pesats, estructures d'estat incòmodes i compilacions de depuració en producció es van sumant fins que els usuaris comencen a abandonar les vostres pàgines.
La bona notícia és que React inclou una rica caixa d'eines per mesurar, entendre i millorar el rendiment del renderitzat., i l'ecosistema circumdant (agrupadors, perfiladors, biblioteques de finestres, Web Workers, frameworks SSR) us ofereixen tot el que necessiteu per mantenir la vostra interfície d'usuari àgil fins i tot a escala. En aquesta guia, analitzarem aquestes eines en profunditat, mostrarem com encaixen entre si i destacarem alguns trucs menys obvis que els equips sovint passen per alt però que valen la pena.
Utilitzeu la compilació de React adequada: desenvolupament, producció i perfilació
La primera comprovació de rendiment de qualsevol aplicació React és verificar que s'està enviant la versió de producció, no la de desenvolupament.La versió de desenvolupament inclou un munt d'avisos amigables, comprovacions addicionals i ajudants de depuració que són fantàstics durant la codificació però notablement més lents i més grans en producció.
Podeu confirmar quina compilació esteu utilitzant amb l'extensió del navegador React Developer Tools.Quan obriu un lloc web amb React, la icona de l'extensió té un fons fosc en producció i un fons vermell en desenvolupament. Si mai veieu vermell al vostre lloc web en directe, la configuració del vostre paquet està filtrant la compilació incorrecta.
Per a projectes arrencats amb Create React App, generar un paquet de producció optimitzat és tan senzill com executar el vostre script de compilació., que genera un paquet minificat al build/ directori. Durant el desenvolupament local, hauríeu de seguir el següent: npm start (o equivalent) i només executar la compilació de producció per a la implementació o per a punts de referència de rendiment realistes.
Si us baseu en les compilacions UMD d'un sol fitxer de React i React DOM (per exemple, en un entorn no inclòs en un paquet), assegureu-vos d'incloure els fitxers que acaben amb .production.min.jsQualsevol fitxer no minificat o que no sigui de producció està destinat només al desenvolupament i generarà una sobrecàrrega de depuració innecessària als vostres usuaris.
Paquets: Browserify, Rollup, Brunch i webpack
Diferents paquets requereixen diferents ajustos per habilitar completament les optimitzacions de producció de React., però totes segueixen la mateixa idea subjacent: establir l'entorn a producció, eliminar les branques només per a desenvolupadors i minimitzar el JavaScript resultant.
Amb Brunch, l'enfocament recomanat és instal·lar un complement de minificador com ara terser-brunch, després executa la teva compilació amb el senyalador de producció (per exemple, amb -p). Aquesta configuració garanteix que els avisos en temps de desenvolupament s'eliminin i que el paquet final es comprimeixi de manera agressiva.
Per a Browserify, normalment encadenes unes quantes transformacions en un ordre específic.: primer aplicar envify globalment per injectar NODE_ENV="production", després aplica uglifyify globalment per esborrar les importacions de desenvolupament i les rutes de codi, i finalment canalitzar el paquet a través terser per a la manipulació i la compressió. L'ordre és important aquí perquè cada pas prepara el codi per a la següent transformació.
Quan utilitzeu Rollup, connecteu un trio de complements per aconseguir una compilació de producció ajustada.: replace estableix l'entorn per a la producció, commonjs permet agrupar mòduls CommonJS, i terser realitza la minificació i la modificació finals. Aquesta combinació produeix un paquet petit i llest per a la producció sense els ajudants només per a desenvolupadors.
Amb webpack 4 i superior, l'activació del mode de producció activa automàticament moltes optimitzacions, inclosa la minificació.. Configuració mode: 'production' cables a Terser sota el capó i permet el comportament de producció de React sempre que NODE_ENV coincidències. Normalment no cal afegir un minificador separat tret que tingueu requisits molt específics.
Creació de perfils de compilacions de React
A més de les compilacions regulars de desenvolupament i producció, React també ofereix una compilació especial de perfils centrada en l'anàlisi del rendiment.Aquesta variant instrumenta React internament de manera que eines com el DevTools Profiler poden recopilar informació de temps molt detallada.
Per utilitzar la compilació de perfils en un entorn de navegador, importeu react-dom/profiling en lloc de react-dom/client i normalment configureu un àlies de paquet perquè no hàgiu de tocar cada importació manualment. Alguns marcs de treball ja exposen un indicador o mode per activar o desactivar aquest comportament.
Les versions anteriors de React (abans de la 17) es basaven en l'API estàndard de User Timing. per emetre marques i mesures visibles al panell de Rendiment del navegador. El React modern combina aquestes habilitats amb la pestanya dedicada Profiler a React DevTools perquè pugueu aprofundir directament en els components.
Comprendre i mesurar el rendiment de React
No es pot arreglar allò que no es mesura, per tant, el treball de rendiment a React sempre hauria de començar amb la creació de perfils.Això significa utilitzar eines del navegador i perfiladors específics de React per veure on es dedica realment el temps i quins components es renderitzen més del que haurien.
El tauler de rendiment de Chrome DevTools és la base per entendre què fa el navegador.L'execució de JavaScript, les sol·licituds de xarxa, el disseny, les pintures, els retards del bucle d'esdeveniments i els rastres personalitzats apareixen en una línia de temps unificada. React s'integra en aquesta vista amb pistes especialitzades que exposen l'activitat específica del framework.
El React modern exposa les pistes del planificador, els components i el servidor que s'alineen amb les pistes normals del navegador.Això et proporciona una vista sincronitzada de les actualitzacions de xarxa, JavaScript i React, cosa que és extremadament útil quan persegueixes errors o parades estranyes que només apareixen sota càrrega.
Fases de seguiment i renderització del planificador
El Scheduler és una abstracció interna de React que orquestra el treball amb diferents prioritats.En els seguiments de rendiment, veureu subseguiments separats per a la feina de bloqueig (sovint actualitzacions síncrones impulsades per l'usuari), la feina de transició (actualitzacions de la interfície d'usuari en segon pla activades per startTransition), Tasques relacionades amb el suspens i treball inactiu que s'executa quan no hi ha res més urgent pendent.
Cada pas de renderització passa per diverses fases diferents que podeu inspeccionar a la línia de temps: una fase d'actualització (què va desencadenar el renderitzat), una fase de renderitzat (on React crida els vostres components i construeix el següent arbre), una fase de confirmació (on el DOM es muta i s'apliquen efectes de disseny com ara useLayoutEffect executar) i una fase d'efectes restants (on els efectes passius com useEffect normalment corren després de la pintura).
Les actualitzacions en cascada (els canvis d'estat programats durant una renderització) són una font clàssica de problemes de rendiment ocults.En desenvolupament, React pot marcar-los a la cronologia i fins i tot mostrar quin component i mètode ha programat l'actualització addicional, cosa que ajuda a evitar bucles de renderització accidentals o treball repetit.
Pista de components: flamegraphs per a renders i efectes
La pista de components visualitza quant de temps triga a renderitzar-se cada component (i els seus descendents). utilitzant un flamegraph. Com més ample sigui el bloc del gràfic, més temps consumirà aquest subarbre de components en aquesta passada de renderització.
React també exposa les durades dels efectes com un flamegraph separat. amb un esquema de colors que reflecteix la fase corresponent a la pista del planificador, de manera que podeu distingir el temps de renderització del temps de l'efecte d'un cop d'ull.
Esdeveniments addicionals com ara muntatges, desmuntatges, reconnexions i desconnexions apareixen com a anotacions en aquests flamegraphs.Per exemple, es marcarà el muntatge d'una part nova de l'arbre o l'enderrocament d'una, i algunes característiques com ara <Activity> els components reben els seus propis marcadors de reconnexió/desconnexió.
En desenvolupament, en fer clic a una entrada de renderització a la pista de components es mostren quins accessoris han canviat., cosa que és increïblement útil quan intenteu localitzar renders o accessoris innecessaris que canvien les referències sense canviar realment el valor.
Pistes del servidor: sol·licituds i components del servidor
Si utilitzeu components de React Server, les eines de rendiment també poden mostrar el comportament del costat del servidor.Una pista de "Sol·licituds del servidor" agrega promeses que finalment alimenten dades als components del servidor, incloses les crides a fetch o operacions asíncrones del sistema de fitxers.
React intenta agrupar les promeses creades en ajudants de tercers en un sol tram. així veureu una operació lògica com ara getUser en lloc d'una dotzena de baix nivell fetch trucades. Si feu clic a un interval, es mostra on es va crear i, si està disponible, el valor resolt o el motiu del rebuig.
Una pista separada de components del servidor mostra quant de temps triguen els arbres de components del servidor i les seves promeses esperades., també en forma de flamegraph. Quan React pot renderitzar components del servidor simultàniament, crea una pista principal i pistes paral·leles addicionals; si la concurrència supera un nombre determinat, s'agrupa el treball addicional per mantenir la vista llegible.
Reducció de renders innecessaris: React.memo, useMemo, useCallback i PureComponent
Una de les pèrdues de rendiment més grans i comunes a les aplicacions React és la re-renderització innecessària.Cada vegada que un component pare s'actualitza, els seus fills es tornen a renderitzar per defecte, fins i tot si les seves entrades (props) són idèntiques i el DOM de sortida no canvia realment.
React ofereix diverses eines per reduir aquesta feina malgastada: React.memo per a components funcionals, React.PureComponent per als components de la classe i el useMemo/useCallback ganxos per estabilitzar valors transmesos com a accessorisAquests no solucionen màgicament tots els problemes de rendiment, però si s'utilitzen amb cura poden marcar una gran diferència.
React.memo envolta un component funcional i omet el re-renderitzat quan els seus props són superficialment iguals als anteriorsAixò és més valuós quan un component es renderitza sovint amb els mateixos accessoris, té una lògica de renderització pesada o teniu evidència del Profiler que és un coll d'ampolla.
Quan memoritzeu un component, també heu d'assegurar-vos que els seus accessoris no canviïn d'identitat innecessàriament.Crear un nou objecte o funció en línia dins del JSX principal en cada renderització invalidarà la comparació superficial i obligarà el fill a tornar a renderitzar-se, fins i tot si les dades lògiques són les mateixes.
Aquí és on useMemo i useCallback endavant: useMemo estabilitza els valors d'objectes o matrius derivats d'altres estats perquè només canviïn quan ho fan les seves dependències, i useCallback proporciona referències de funcions estables per a les retrollamades passats als fills amb memòria.
Components de la classe: shouldComponentUpdate i React.PureComponent
En l'interior, la majoria de les optimitzacions de renderització de React es redueixen a controlar si shouldComponentUpdate retorna cert o falsLa implementació per defecte sempre retorna "true", és a dir, que qualsevol canvi d'estat o de propietat activa una renderització i una reconciliació per a aquest component i el seu subarbre.
En anul·lar shouldComponentUpdate, podeu fer un curtcircuit a la feina per a subarbres que no necessiten actualitzar-seSi retornes false, React no cridarà. render() per a aquest component o qualsevol dels seus descendents, i ni tan sols compararà els nodes DOM virtuals nous i antics per a aquesta part de l'arbre.
Considereu un petit arbre de components on alguns nodes retornen fals de shouldComponentUpdateReact pot ometre completament el recorregut cap a aquestes branques, mentre que altres nodes on el mètode retorna "true" seran processats completament. Al final, només els nodes la sortida renderitzada dels quals hagi canviat realment causaran mutacions DOM.
Perquè escriure personalitzada shouldComponentUpdate La lògica és repetitiva, React ships React.PureComponent, que implementa una comparació superficial dels elements i l'estat actuals i anteriors. Si no hi ha hagut cap canvi superficial, React pot ometre amb seguretat la re-renderització d'aquest component de classe.
Immutabilitat i per què la comparació superficial pot fallar
La comparació superficial assumeix que si un valor canvia, la seva referència també canviarà, una suposició que es trenca en el moment en què es muten matrius o objectes existents al seu lloc.Aquesta és una font clàssica d'errors quan es combinen optimitzacions basades en la immutabilitat amb estructures de dades mutables.
Imagineu-vos a ListOfWords component que rep un words matriu i les renderitza separades per comes, emparellat amb un pare o mare WordAdder component que introdueix una nova paraula a la mateixa matriu. Si ListOfWords s'estén PureComponent, la comparació superficial veurà la mateixa referència de matriu i assumirà que no ha canviat res, de manera que la interfície d'usuari no s'actualitzarà.
La solució és evitar mutar els accessoris o l'estat directament i, en canvi, crear noves matrius o objectes quan les dades canvien.. En lloc de words.push(newWord), utilitzaríeu words.concat(newWord) o la sintaxi de propagació [...words, newWord], que crea una nova referència per a la matriu i desencadena les actualitzacions correctes.
El mateix principi s'aplica als objectes: en lloc de reassignar colormap.right = 'blue' en un objecte existent, retornaries un objecte nou utilitzant Object.assign({}, colormap, { right: 'blue' }) o la sintaxi de dispersió d'objectes { ...colormap, right: 'blue' }Això garanteix que una comparació superficial veu una nova referència i reconeix el canvi.
Quan les dades s'imbrican profundament, mantenir la immutabilitat manualment pot resultar difícil de manejar.Biblioteques com Immer o immutability-helper permeten escriure codi que sembla imperatiu i mutatiu mentre produeix internament noves estructures immutables, cosa que funciona bé amb PureComponent i React.memo.
Virtualització de llistes llargues i interfícies d'usuari pesades
Renderitzar centenars o milers de nodes DOM alhora és una de les maneres més ràpides de reduir el rendiment de React., especialment en dispositius de gamma baixa o quan es combina amb dissenys i imatges complexes. Fins i tot amb una reconciliació eficient, tenir tants nodes a la memòria i a la pantalla ja és car.
La virtualització de finestres, o de llistes, soluciona aquest problema només renderitzant la part d'una llista que actualment és visible a la finestra gràfica.A mesura que l'usuari es desplaça, React munta els nous elements que entren a la vista i desmunta els que es desplacen cap a fora, mantenint el nombre de files renderitzades aproximadament constant.
Biblioteques populars com ara react-window i react-virtualized proporcionar components reutilitzables per a llistes, quadrícules i taules que implementen estratègies de virtualització eficients. Gestionen els càlculs de quins elements renderitzar, la mida, el desplaçament dels contenidors i fins i tot el comportament de càrrega infinita.
La configuració de la virtualització normalment implica tres parts: triar el component adequat (per exemple, FixedSizeList per a files uniformes o VariableSizeList per a altures dinàmiques), donant al contenidor una alçada fixa amb overflow: scroll, i renderitzant només el component d'element que la biblioteca demana, normalment memoritzat amb React.memo per evitar re-renderitzacions innecessàries.
Ben feta, la virtualització manté el rendiment del desplaçament suau i l'ús de memòria baix fins i tot per a conjunts de dades massius.Les aplicacions del món real han utilitzat aquesta tècnica per navegar de manera eficient per grans col·leccions (ressenyes musicals, catàlegs de comerç electrònic, safates d'entrada) sense que la interfície d'usuari s'aturi.
L'accessibilitat requereix una mica d'atenció addicional amb les llistes virtualitzades.Cal assegurar-se que la navegació amb el teclat funcioni, que el focus es gestioni correctament a mesura que els elements es munten i es desmunten i que els lectors de pantalla tinguin prou context a través dels atributs ARIA per entendre la part de la llista que es veu actualment.
Gestió d'estats, DOM virtual i estructura de components
El DOM virtual sovint es malinterpreta com una bala de plata, però en realitat només és una capa de diferenciació intel·ligent.React manté una representació en memòria de la interfície d'usuari i compara el nou arbre amb l'antic per decidir quines operacions DOM són estrictament necessàries.
Fins i tot amb aquesta eficiència, cada renderització i diferència encara costa temps, de manera que el vostre objectiu és minimitzar la freqüència amb què els subarbres grans s'han de tornar a renderitzar.Aquí és on la gestió d'estats, els límits dels components i les estratègies de memoització s'intersequen.
Primer, trieu una estratègia de gestió d'estat adequada per a la complexitat de la vostra aplicació. Estat de reacció local (useState, useReducer) és petit i senzill per a components petits, mentre que biblioteques com Redux o magatzems lleugers com Zustand poden centralitzar estats globals més complexos amb patrons de subscripció optimitzats.
En segon lloc, estructura el teu estat de manera que les dades relacionades s'agrupin de manera sensata.De vegades això significa consolidar múltiples useState crides a un sol objecte perquè les actualitzacions siguin coherents; en altres casos, és més efectiu dividir l'estat perquè les preocupacions independents no s'obliguin mútuament a tornar a renderitzar-se.
Quan s'actualitza l'estat derivat de valors anteriors, sempre cal utilitzar actualitzacions funcionals. tal com setCount(prev => prev + 1)i mantenir la immutabilitat clonant matrius i objectes en comptes de mutar-los al seu lloc. Això porta a un comportament predictible i funciona bé amb la memoització i els PureComponents.
Una regla general pràctica és mantenir l'estat el més local possibleCom més amunt a l'arbre emmagatzemeu un valor d'estat, més components es tornaran a renderitzar cada vegada que canviï. Si envieu l'estat cap avall als components que realment l'utilitzen, es limita el radi de ràdio de cada actualització.
Finalment, divideix els components grans en peces més petites i centrades, els accessoris de les quals rarament canvien.Els components de fulla memoritzats amb accessoris estables redueixen la quantitat de DOM virtual que React necessita per diferenciar i escurcen el camí a un conjunt mínim d'actualitzacions de DOM.
Divisió de codi, càrrega lenta i millor càrrega d'actius
La mida del paquet de JavaScript és un factor important que contribueix al baix rendiment, especialment a les xarxes mòbils.Si el vostre paquet React triga uns segons a descarregar-se i analitzar-se, els usuaris abandonaran molt abans de veure la vostra atractiva interfície d'usuari.
Divisió de codi amb React.lazy i Suspense ajuda carregant components a demanda en comptes d'enviar-ho tot per avançatEn lloc d'agrupar totes les funcions a la càrrega útil inicial, importeu dinàmicament les peces que només es necessiten per a rutes o interaccions específiques.
Una estratègia comuna és la divisió a nivell de ruta, on cada pàgina és un bloc propi i només es carrega quan l'usuari hi navega. Podeu anar més enllà i dividir components de funcions grans o panells que s'utilitzen rarament, sempre que els emboliqueu en Suspense amb una interfície d'usuari alternativa adequada.
La càrrega lenta també s'aplica a les imatges. Sumant loading="lazy" a <img> Les etiquetes ajornen la càrrega de les imatges per sota del plec fins que apareixen a la vista, cosa que estalvia ample de banda i accelera la pintura inicial. Per a efectes més avançats, biblioteques com ara react-lazy-load-image-component admet marcadors de posició borrosos i càrrega progressiva.
Quan s'implementa la divisió de codi, és important equilibrar la mida dels fragments i l'experiència de l'usuari.Una divisió excessiva pot crear massa sol·licituds petites, mentre que una divisió insuficient us deixa amb un paquet inicial pesat. Uns bons recursos alternatius i límits d'error al voltant dels components mandrosos són essencials perquè les sol·licituds de xarxa fallides no facin fallar tota l'aplicació.
Renderització del costat del servidor, components de React Server i accions del servidor
El renderitzat del costat del servidor (SSR) renderitza l'aplicació React al servidor i envia HTML al client, cosa que pot millorar dràsticament el rendiment percebut i el SEO.Els usuaris veuen contingut útil més aviat i els motors de cerca poden indexar les vostres pàgines de manera més fiable.
Els frameworks com Next.js fan que SSR i la transmissió d'HTML siguin pràctics per a les aplicacions quotidianes.Obteniu dades al servidor, renderitzeu els components en HTML (de vegades fins i tot com a flux) i després hidrateu aquest marcatge al client perquè esdevingui interactiu.
Més enllà de l'SSR clàssic, els components de React Server impulsen més lògica de la interfície d'usuari al costat del servidor., permetent-vos renderitzar components que no s'envien mai al client. Això pot reduir significativament la mida del paquet del client i simplificar l'obtenció de dades, ja que els components del servidor poden cridar bases de dades o API directament.
Les accions del servidor amplien aquesta idea permetent definir funcions que s'executen al servidor però que s'activen des de components del client.Això elimina molts punts finals REST estàndard o controladors d'API a mida i pot simplificar la manera de gestionar les mutacions, els enviaments de formularis i altres operacions amb estat.
Si s'utilitzen conjuntament, SSR, components del servidor i accions del servidor us ofereixen un espectre d'estratègies de renderització.: el contingut crític es pot transmetre ràpidament des del servidor, la lògica pesada es manté fora del client i el temps d'execució de React ho uneix tot en una UX cohesionada.
Descarregar la feina pesada amb Web Workers
Fins i tot l'arbre de React millor optimitzat fallarà si executeu tasques amb molta CPU al fil principal.Els càlculs costosos bloquegen el renderitzat, retarden la gestió d'esdeveniments i fan que l'aplicació no respongui.
Els treballadors web proporcionen una manera de moure les tasques pesades a un fil de treball en segon pla.Envieu dades al treballador, deixeu que faci càlculs o processi grans conjunts de dades i després rebeu el resultat mitjançant el pas de missatges, deixant el fil principal lliure per gestionar les actualitzacions de la interfície d'usuari.
Les càrregues de treball típiques per als treballadors web inclouen el processament de dades, l'anàlisi en temps real o simulacions complexes.Per exemple, els jocs creats amb la pila web sovint deleguen la lògica central del joc a un treballador, mentre que el fil principal es dedica a la renderització i la gestió de l'entrada.
Integrar un treballador amb React implica crear un fitxer de script separat, que escolti onmessage dins del treballador i publicant missatges des dels vostres componentsEn el component, instancia el treballador, li envieu entrades amb postMessage i actualitza l'estat quan respon, idealment netejant el treballador quan el component es desmunta.
Biblioteques com ara els complements Comlink, workerize o bundler poden simplificar aquest patró. eliminant el pas de missatges de baix nivell i oferint-vos una API que sembla cridar funcions asíncrones, cosa que és més fàcil de raonar en una base de codi React.
Mètriques clau del navegador i centrades en l'usuari a tenir en compte
A un nivell superior, el rendiment web general es fa un seguiment habitual mitjançant mètriques centrades en l'usuari. com ara la primera pintura amb contingut (FCP), la pintura amb contingut més gran (LCP) i el temps d'interacció (TTI). Aquests resultats permeten fer-se una idea de la rapidesa amb què els usuaris veuen el contingut i del temps amb què poden interactuar-hi.
Les aplicacions Healthy React tenen com a objectiu un FCP inferior a aproximadament 1.8 segons, un LCP inferior a uns 2.5 segons i un TTI molt inferior a 4 segons en dispositius típics., tot i que els llindars exactes poden variar segons el projecte. Si supereu constantment aquestes xifres, és un senyal que cal millorar els vostres paquets, l'estratègia de renderització o els temps de resposta del servidor.
Eines com Lighthouse, WebPageTest i el panell de rendiment de Chrome us ajuden a mesurar aquestes mètriques en entorns de proves sintètiques.Per obtenir informació del món real, les eines de monitorització d'usuaris reals (RUM) com ara SpeedCurve, Datadog, LogRocket o Sentry rastregen les sessions d'usuari reals i connecten les experiències lentes amb els canvis de codi.
La pròpia API Profiler de React s'integra perfectament amb aquesta imatge.: pots embolicar parts del teu arbre <Profiler>, registra els renders lents i correlaciona'ls amb fluxos d'usuari específics. Quan s'utilitza juntament amb la supervisió del backend i de la xarxa, això us ofereix una visió completa del rendiment de principi a fi.
Flux de treball pràctic en equip per a l'optimització del rendiment
En projectes reals, l'ajustament del rendiment funciona millor quan es tracta com un flux de treball repetible en lloc d'una neteja puntual.Un bucle simple de quatre fases (identificar, investigar, implementar, confirmar) ajuda a prevenir microoptimitzacions aleatòries i manté els esforços centrats en allò que importa.
La identificació significa utilitzar perfiladors, mètriques i informes d'usuaris per trobar símptomes concrets. com ara pàgines lentes, baixes taxes de fotogrames o un alt abandonament durant certs fluxos. Voleu problemes mesurables, no intuïcions.
La investigació aprofundeix en la causa arrel: potser una pàgina inclou desenes d'iframes ocults, potser un component en particular es torna a renderitzar massa sovint o s'està carregant una biblioteca de proveïdors enorme a cada ruta. Aquí us baseu molt en el React DevTools Profiler i la cronologia de Chrome.
La implementació és on apliqueu correccions específiques.—memoritzar un component calent, virtualitzar una llista llarga, dividir un paquet, descarregar la feina a un treballador web o habilitar SSR per a determinades pàgines. Cada canvi hauria de ser prou petit per poder-lo raonar.
La confirmació és l'últim pas i sovint el més passat per altTorneu a executar els escenaris de perfilació i comproveu els taulers de control de mètriques per assegurar-vos que el canvi realment ha millorat les xifres i no ha introduït regressions en altres parts del sistema.
Quan combines la compilació correcta de React, la memoització reflexiva, les pràctiques d'estat immutables, la virtualització de llistes, la divisió estratègica de codi, SSR, Web Workers i el mesurament continu, acabes amb aplicacions React que es mantenen ràpides i responsives fins i tot a mesura que es tornen més complexes.; les tècniques anteriors no tracten de microajustament prematur, sinó de construir una arquitectura on el rendiment continuï sent un subproducte natural en lloc d'una lluita constant.
