För en djupare genomgång, se Rtexs guide.
Många React-utvecklare bygger effektiva applikationer men missar de subtila misstagen som slösar resurser och energi. Här är de vanligaste problemen och konkreta lösningar.
Onödig re-rendering är den största tjuven på prestanda. En komponent som re-renderas ofta utan att dess data ändras använder energi för ingenting. Misstaget är att inte förstå React's rendering-modell — många tror att setState automatiskt är smart och bara uppdaterar relevanta delar. Det stämmer inte. Om en föräldra-komponent uppdateras, renderas alla barn om. Lösningen är React.memo() för komponenter som inte behöver uppdateras, useMemo() för beräkningar som inte ändras, och useCallback() för funktioner som skickas som props. Se till att dependency-arrays är korrekta — en tom array betyder aldrig uppdatera, en saknad array betyder alltid uppdatera.
Bundle-storlek är en dold miljökostnad. Många projekt importerar stora bibliotek för en liten funktion. Om du använder Lodash bara för debounce() lägger du till 70 KB. Importerar du hela Material-UI när du bara behöver en knapp, dubblerar du din bundle. Detta påverkar inte bara laddningstid utan också energiförbrukningen under initialisering. Undersök varje beroende med npm ls eller webpack-bundle-analyzer. Ersätt stora bibliotek med små alternativ — Preact istället för React för vissa fall, date-fns istället för Moment, eller skriv själv om funktionen är enkel.
Dålig code splitting är ett klassiskt misstag. Nya utvecklare bygger en single-page-app och tror all kod måste ladda innan användaren kan göra något. Distribuera dina routes dynamiskt med React.lazy() och Suspense. En dashboard-app behöver inte ladda admin-panelen förrän användaren navigerar dit. Dela även upp stora komponenter — en formulärkomplett med 50 input-fält bör splittas så bara det synliga formuläret laddar först.
State management är ofta överkomplicerad. Många lägger all state i Redux eller Zustand utan att tänka efter. En globalt state som uppdateras ofta tvingar alla subscribers att uppdateras ofta. Låt local state vara lokal. En input-fields fokus-state behöver inte global state. En form som bara ska valideras lokalt behöver inte Redux. Tumregel: använd component state för single-component-data, context för data som många komponenter behöver på samma nivå, och global state bara för data som ofta uppdateras eller behövs överallt.
Överflödiga render-cykler från event-handlers är en klassisk fälla. Om du har en input-field som uppdaterar global state på varje keystroke, och den globala state är ansluten till många komponenter, skapar du hundratals onödiga renders. Lösningen är debouncing eller throttling av uppdateringar, eller att hålla input-state lokalt och bara uppdatera global state när formuläret skickas.
Caching-strategier ignoreras ofta. CSS och JavaScript bör cached aggressivt av webbläsaren — använd långtidiga cache-headers och filnamn-baserad revisionering (main.abc123.js) så att nya versioner inte inkluderar gammal cache. API-svar kan cachelagras på klient-sida med SWR eller React Query. Ett API-svar som inte ändras ofta bör inte hämtas om på varje sidladdning. Många utvecklare gör fetch på mount utan att kontrollera om data redan finns.
Bild-optimering glöms ofta i React-appar. En hero-bild på 5 MB laddar långsamt och använder energi. Använd next/image (om du använder Next.js) eller en bild-optimerings-tjänst som serverar rätt storlek till rätt enhet. WebP-format är ofta 30% mindre än JPEG. Lazy-load bilder som är nedanför linjen med loading="lazy".
Felaktig prop-validering med PropTypes bör tas bort i produktion. PropTypes körs i utveckling för att fånga fel, men i produktion är det bara dödvikt. Många glömmer att sätta NODE_ENV=production vid bygging, vilket gör att PropTypes-validering fortfarande körs och saktar ned applikationen.
Utvecklare skapar komponenter som är för storslagna. En Button-komponent som hanterar loading-state, error-state, analytics, A/B-testing och accessibility-logik blir på 200 rader och svår att anpassa. Börja enkelt och lägg till funktioner när du verkligen behöver dem. En knapp bör vara en knapp — låt en wrapper-komponent eller hook hantera analytics.
useState för komplicerad state-logik skapar buggar. Om du har fem useState-hooks som måste uppdateras tillsammans, kommer någon att uppdatera en men glömma de andra. Använd useReducer() för sammanlänkad state. Det tvingar dig att tänka på alla möjliga state-övergångar på ett ställe.
Tredjepartsprogramvara utan performance-budget godkänns ofta. En chat-widget som laddar 500 KB JavaScript utan att användaren frågar efter den är ett misstag. Kräv att alla script har en budget — en analytics-tjänst bör inte vara större än 20 KB, en chat-widget inte större än 100 KB. Auditmera regelbundet med Lighthouse.
Nyckeln är att ställa rätt frågor: Renderas denna komponent ofta? Kan den cacheas? Är detta beroende nödvändigt? Kan denna stat vara lokal istället för global? Dessa små beslut samlas till stora energibesparingar och snabbare webbplatser.
Memory leaks och cleanup är ofta glömt
En vanlig bug i React är att event listeners, timers och subscriptions inte städas upp när komponenter unmountas. En komponent som registrerar ett resize-listener på window men inte tar bort det vid unmount kommer att lyssna på events långt efter att komponenten är borta. Multiplicera detta över många komponenter och du har en applikation som växer i minnesanvändning över tid.
// Fel
useEffect(() => {
window.addEventListener('resize', handleResize);
// Cleanup funktion saknas!
}, []);
// Rätt
useEffect(() => {
window.addEventListener('resize', handleResize);
return () => window.removeEventListener('resize', handleResize);
}, []);
Samma gäller för alla `setInterval()`, WebSocket-anslutningar, eller Firebase-listeners. En applikation utan ordentlig cleanup kan få minnesläckor på veckor och slösa energi på att hantera massor av inaktiva callbacks.
## Virtualisering för långa listor är underutnyttjat
En lista med 10 000 poster renderar inte alla 10 000 element på en gång. Om användaren bara ser 20 på skärmen är de andra 9 980 slöseri. Bibliotek som `react-window` eller `react-virtualized` rendererar bara elementen som är synliga, plus några buffrade utanför viewporten. Effekten är dramatisk — från ett par sekunders render-tid till millisekunder.
En e-handelswebbplats med en infinite-scroll produktlista kan se en 90% minskning i DOM-noder och RAM-användning bara genom att byta från en vanlig `map()` till virtualisering.
## Network waterfall-problem kostar tid och energi
En vanlig antipattern är att hämta användar-data först, sedan användar-inställningar, sedan användar-posts — i sekvens. Detta skapar en "vattenfalls"-effekt där varje request måste vänta på föregående. Med endast 3G-nätverk kan detta vara sekunder.
Använd `Promise.all()` för oberoende requests, eller ännu bättre — `React Query`'s parallella querys:
javascript
const { data: user } = useQuery(['user'], fetchUser);
const { data: settings } = useQuery(['settings'], fetchSettings);
const { data: posts } = useQuery(['posts'], fetchPosts);
// Alla tre startar samtidigt, inte sekventiellt
En mobil-användare sparar ofta 500+ ms per pageload bara genom att parallellisera requests.
Server-side rendering sparar energi på klient
CSR (Client-Side Rendering) kräver att webbläsaren laddar JavaScript, parsar det, och kör det för att generera HTML. SSR (Server-Side Rendering) eller Static Generation skickar redan renderad HTML, så webbläsaren behöver bara displayar det.
En sida som tar 3 sekunder att renderas på klient tar 200ms med SSR. Det är inte bara snabbare — det använder betydligt mindre strömförbrukning på användarens enhet. För användare på mobiler med svaga processorer är detta livsviktigt.
Next.js getStaticProps() för statiskt innehål eller getServerSideProps() för dynamiskt innehål bygger detta in från start. En blogg som genereras statiskt på build-tid istället för render-tid per request sparar tusental watts årligen.
Monitoring och performance budgets är den enda vägen framåt
Du kan inte optimera det du inte mäter. Många team sätter aldrig en performance budget och lägger sedan till funktioner tills sidan är långsam. Då är det för sent — källan är oklar.
Använd Lighthouse CI för att köra performance-tester automatiskt på varje commit. Definiera budgets: "JavaScript får inte överstiga 150 KB", "Largest Contentful Paint får inte överstiga 2,5 sekunder". GitHub-integreringen visar resultaten direkt i pull requests.
Lighthouse tester visar att en optimerad React-app i genomsnitt
är 40% snabbare än en ooptimerad version av samma funktionalitet.
Mät också CPU-användning och minnesförbrukning under normalt bruk. En komponent som använder 100% CPU när sidan är inaktiv är en debug-session värd.
Läs vidare: Läs mer på Rtex.
Top comments (0)