Få din React-app til at køre hurtigere med gennemprøvede teknikker til ydeevneoptimering

Din React-app var hurtig, da du først udviklede den. Nu hakker den, indlæsningstiderne er steget, og brugerne begynder at lægge mærke til det. Den gode nyhed er, at de fleste ydeevneproblemer i React skyldes en håndfuld årsager, der kan afhjælpes.

Denne guide gennemgår syv gennemprøvede teknikker til at Gør din React-app hurtigere med konkrete data, praktiske kodemønstre og klare retningslinjer for, hvornår de enkelte løsninger skal anvendes. Uanset om din app er langsom ved den første indlæsning, reagerer langsomt på brugerindtastninger eller har svært ved at håndtere store datasæt, vil du her finde en målrettet løsning.

Inden du rører ved en eneste kodelinje, skal du åbne React DevTools Profiler og optage en interaktion, der føles langsom. Flamegraph-visningen viser dig præcis, hvilke komponenter der renderes, hvor lang tid hver rendering tager, og hvad der udløste den. Optimering uden disse data er ren gætteri. Med disse data kan du målrette din indsats der, hvor det rent faktisk gør en forskel.

1. Opdeling af kode for hurtigere indlæsning

Som standard samler dit build-værktøj hele din React-applikation i én JavaScript-fil. Hver bruger downloader det hele – selv de dele, de aldrig besøger.

Kodeopdeling opdeler denne pakke i mindre dele, der kun indlæses, når der er brug for dem. React.lazy() sammen med Spænding gør opdeling på ruteniveau til en enkel sag:

import { lazy, Suspense } from 'react';

const Dashboard = lazy(() => import('./Dashboard'));

function App() {
  return (
    <Suspense fallback={<div>Loading...</div>}>
      <Dashboard />
    </Suspense>
  );
}

Den Dashboard Komponenten indlæses nu kun, når den vises, og ikke ved det første besøg på siden. For de fleste apps reducerer opdeling af koden på ruteniveau den indledende pakkestørrelse med 30–50 %, hvilket direkte forbedrer Largest Contentful Paint (LCP). Ifølge HTTP Archive (data fra 2024) overstiger medianværdien for JavaScript-payload for desktopbrugere allerede 500 KB. En aggressiv opdeling forhindrer, at dette tal stiger yderligere.

Ud over ruterne bør du overveje at opdele tunge tredjepartsbiblioteker – kortbiblioteker, rich text-redigeringsprogrammer og PDF-visere – som kun vises på bestemte sider. Brug Webpack Bundle Analyzer for at få et overblik over din pakke og identificere de største bidragsyderne, inden du beslutter, hvor den skal opdeles.

2. Memoization til at undgå unødvendige gengivelser

React genrenderer en komponent hver gang dens overordnede komponent genrenderes, selvom komponentens props ikke har ændret sig. I et dashboard med 50 komponenter kan en ændring i tilstanden på øverste niveau udløse, at alle 50 komponenter genrenderes unødvendigt. Ifølge en undersøgelse fra Bit.dev kan dårlig renderingsydelse forlænge script-eksekveringstiden med 30–60 %, et mærkbart tilbageslag for begge brugeroplevelse og SEO.

React.memo er dit første forsvarslinje. Den indkapsler en komponent og foretager en overfladisk sammenligning af props, før den beslutter sig for at genrendere:

const ExpensiveList = React.memo(function ExpensiveList({ items }) {
  return (
    <ul>
      {items.map(item => <li key={item.id}>{item.name}</li>)}
    </ul>
  );
});

React.memo fungerer kun, når de props, den modtager, har stabile referencer. Brug den sammen med useMemo for beregnede værdier og useCallback for begivenhedshåndterere:

function ProductPage({ products }) {
  const sortedProducts = useMemo(() => {
    return [...products].sort((a, b) => b.price - a.price);
  }, [products]);

  const handleDelete = useCallback((id) => {
    // delete logic
  }, []);

  return <ExpensiveList items={sortedProducts} onDelete={handleDelete} />;
}

Hvornår man ikke bør anvende memoization: Hver React.memo Wrapperet udfører en overfladisk sammenligningskontrol ved hver rendering. For små komponenter, der renderes hurtigt, kan denne ekstra belastning koste mere end blot at genrendere. Udfør først en profilering med React DevTools, og anvend derefter memoization selektivt på komponenter med renderingstider på over 5–10 ms, der udløses hyppigt. Indkapsl alt i React.memo Manglende måling er et almindeligt antipattern.

Når memoization anvendes korrekt, kan den reducere antallet af genrenderinger med 30–50 % på tværs af store lister. En intern revision dokumenterede en 40 % reduktion i antallet af genberegninger på en produktoversigtsside efter målrettet memoization.

3. Virtualisering af store lister

Når en liste med 500 elementer vises, betyder det, at browseren opretter 500 DOM-noder, administrerer 500 hændelseslyttere og udfører layout- og tegningsoperationer for dem alle – selv dem, der ligger langt uden for det synlige visningsområde. Det resulterer i langsom indledende visning, trægt rulning og højt hukommelsesforbrug.

Virtualisering løser dette problem ved kun at gengive de elementer, der i øjeblikket er synlige i visningsområdet, samt en lille buffer. react-window er det mest udbredte bibliotek til dette formål:

import { FixedSizeList } from 'react-window';

function VirtualizedList({ items }) {
  return (
    <FixedSizeList
      height={400}
      itemCount={items.length}
      itemSize={50}
      width={300}
    >
      {({ index, style }) => (
        <div style={style}>{items[index].name}</div>
      )}
    </FixedSizeList>
  );
}

For en liste med 10.000 elementer renderer dette på ethvert givet tidspunkt ca. 20 DOM-noder i stedet for 10.000. Det er dokumenteret, at denne ene ændring reducerer renderetiden for listen fra over 3 sekunder til næsten øjeblikkelig.

Brug virtualisering, når din liste indeholder mere end 100 elementer. Under dette antal håndterer DOM belastningen uden mærkbar forringelse. Over dette antal forstærkes fordelene i takt med, at listen vokser. Sørg også for at bruge stabile, unikke nøgleprops — brug af array-indekset som nøgle forårsager subtile fejl under omarrangering og filtrering og tvinger React til unødvendigt at genrendere hele listen.

4. Optimering af billeder og andre ressourcer

Billeder er typisk de største filer på en React-side. Store, ukomprimerede billeder forsinker indlæsningen af siden, forlænger LCP-tiderne og spilder båndbredde, især på mobilnetværk.

Skift til moderne formater. WebP-billeder er 25–35 % mindre end JPEG-filer med tilsvarende kvalitet. AVIF tilbyder endnu større komprimering, hvor browseren understøtter det. At opdatere din billedbehandlingsproces, så den som standard leverer WebP, er en af de hurtigste måder at opnå forbedringer på:

<img src="photo.webp" alt="Product image" />

Indlæs billeder uden for skærmen ved behov. Den indfødte loading="lazy" Denne attribut instruerer browseren om at udskyde indlæsningen af billeder, indtil de kommer til syne, når man ruller ned på siden. Dette reducerer sidens indledende størrelse og forhindrer, at billeder, der ligger uden for skærmbilledet, konkurrerer om ressourcerne med vigtige elementer:

<img src="photo.webp" loading="lazy" alt="Product image" />

Vis responsive billeder. At sende et billede på 2000 px til en mobilskærm på 400 px spilder båndbredde og gør indlæsningen langsommere. Brug srcSet og størrelser for at vise billeder i passende størrelse i forhold til visningsområdet:

<img
  srcSet="photo-400.webp 400w, photo-800.webp 800w"
  sizes="(max-width: 600px) 400px, 800px"
  src="photo-800.webp"
  alt="Product image"
/>

Hvis du er udvikling med Next.js, den næste/billede Komponenten håndterer automatisk formatkonvertering, responsiv størrelsesjustering og lazy loading.

5. Brug en produktionsversion og reducer pakkens størrelse

Udviklingsversioner af React indeholder ekstra advarsler, fejlfindingsværktøjer og ikke-minificeret kode, som ingen af delene hører hjemme i produktionsmiljøet. Du skal altid implementere ved hjælp af en produktionsversion. I Opret React-app, det vil sige at løbe npm run build. I Next.js betyder det næste build. Forskellen i bundtstørrelse er betydelig.

Ud over build-tilstanden kan du holde bundlestørrelsen under kontrol ved hjælp af »tree shaking«. Moderne bundlere (Webpack, Vite, Rollup) fjerner automatisk ubrugt kode, men kun hvis du importerer præcis det, du har brug for:

// Imports the entire lodash library (~70KB)
import _ from 'lodash';

// Imports only the function you need (~2KB)
import debounce from 'lodash/debounce';

Denne ene ændring i importen reducerer en afhængigheds størrelse fra 70 KB til 2 KB. Ganger man dette mønster på 10–15 afhængigheder, bliver den samlede reduktion betydelig.

Anvendelse Webpack Bundle Analyzer for at finde de største pladsoptagere. Du vil ofte opdage, at en eller to pakker udgør en uforholdsmæssig stor del af din samlede pakke, og at der findes mindre pladsoptagende alternativer.

6. Implementer »lazy loading« for komponenter

Lazy loading hænger tæt sammen med kodedeling, men omfatter mere end blot ruter. Enhver komponent, der er ressourcekrævende at gengive og ikke er nødvendig ved den første indlæsning, er en kandidat til lazy loading.

Du har allerede set React.lazy() I afsnittet om kodesplitning. Anvend det samme mønster på:

• Modaldialogbokse som først vises efter en brugerhandling
• Administrationspaneler eller indstillingsskærmbilleder, der sjældent besøges
• Diagrammer og datavisualiseringer som kun indlæses på bestemte sider
• Tredjepartsintegrationer — videoafspillere, PDF-visere, kort

Undgå at anvende »lazy loading« på komponenter, der vises lige over folden. Hvis brugeren ser dem ved den første visning, skal de indlæses med det samme; ellers skaber du en synlig forsinkelse, der opleves som en fejl.

Ved søgeindtastninger og andre interaktioner, der udløser ressourcekrævende beregninger, bør du overveje at anvende debouncing for at begrænse, hvor ofte disse beregninger udføres:

useEffect(() => {
  const timer = setTimeout(() => {
    setDebouncedQuery(query);
  }, 300);
  return () => clearTimeout(timer);
}, [query]);

Et debounce-vindue på 300 ms opfanger de fleste pauser i indtastningen uden at medføre en mærkbar forsinkelse. For React-applikationer, der bruger React 18 eller nyere, useTransition Tilbyder et alternativ til React Native, der sikrer, at brugergrænsefladen forbliver responsiv, samtidig med at ikke-presserende statusopdateringer udskydes – hvilket er særligt effektivt i forbindelse med »søg mens du skriver«-mønstre.

7. Løbende overvågning og analyse af resultaterne

Ydeevne er ikke en engangsopgave. Nye funktioner lanceres, afhængigheder hober sig op, og det, der er hurtigt i dag, kan blive en flaskehals om tre måneder. Det er netop den løbende overvågning, der adskiller de teams, der opretholder ydeevnen, fra dem, der først opdager problemerne, når brugerne klager.

Her er de værktøjer, du kan indarbejde i din daglige arbejdsgang:

React DevTools-profiler viser, hvilke komponenter der blev renderet, hvor lang tid hver rendering tog, og hvad der udløste den. Brug det under udviklingen og efter større funktionsudgivelser for at opdage regressionsfejl, før de når produktionsmiljøet.

Fyrtårn (tilgængelig i Chrome DevTools) kontrollerer din app i forhold til tærskelværdierne for Core Web Vitals: LCP under 2,5 sekunder, INP under 200 millisekunder og CLS under 0,1. Kør værktøjet i din CI-pipeline for at forhindre, at ydelsesforringelser når ud i produktionsmiljøet uden at blive opdaget.

Web Vitals JS indsamler data fra reelle brugere i produktionsmiljøet. Laboratoriemålinger afspejler ikke altid de faktiske brugeroplevelser på tværs af forskellige enheder og netværksforhold. Det gør feltdata derimod.

Fanen »Ydeevne« i Chrome DevTools giver et billede af JavaScript-udførelsestiden, lange opgaver, paint- og layout-hændelser samt frame drops, ramme for ramme. Brug den, når Profiler viser en langsom komponent, men du har brug for at forstå, hvad der sker på browserniveau.

Indarbejd profilering i jeres kodegennemgangsproces, især for delte komponenter og UI-kits. Gennemgå flamegrafikker efter større omstruktureringer. Opret alarmer for forringelser af Core Web Vitals. De teams, der opdager ydelsesproblemer tidligst, bruger mindst tid på at løse dem.

En hurtigere React-app starter med den rigtige tilgang

Hastighed er ikke blot et teknisk mål. Hver 100 millisekunders forsinkelse har en målbar indvirkning på konverteringsraterne, og websteder, der konsekvent overholder alle tre Core Web Vitals-tærskelværdier, klarer sig bedre end konkurrenterne i den organiske søgning.

Teknikkerne i denne vejledning – kodesplitning, memoisation, virtualisering, billedoptimering, produktionsbuilds, lazy loading og kontinuerlig overvågning – tager fat på de grundlæggende årsager til de fleste ydeevneproblemer i React. Anvend dem systematisk, mål ydeevnen før og efter hver ændring, og fokuser din indsats på de flaskehalse, som Profiler rent faktisk afslører.

Er du klar til at forbedre ydeevnen i dit React-projekt yderligere?

Monarch Innovation samarbejder med udviklingsteams om at identificere flaskehalse i ydeevnen, gennemføre optimeringsstrategier og udvikle hurtigere og mere skalerbare React-applikationer. Se, hvad Monarch Innovation kan gøre for dit projekt.

Ofte stillede spørgsmål

Hvad er kodedeling, og hvordan gør det en React-app hurtigere?

Kodeopdeling er en teknik, der opdeler din React-applikation i mindre JavaScript-pakker i stedet for at indlæse hele applikationen på én gang. Dette gør det muligt for brugerne kun at downloade den kode, der er nødvendig for den aktuelle side, hvilket reducerer den indledende indlæsningstid og forbedrer ydeevnen. React understøtter kodeopdeling ved hjælp af React.lazy() og dynamisk import().

Hvornår skal jeg bruge React.memo, useMemo og useCallback?

Disse React-optimeringsværktøjer hjælper med at undgå unødvendige genrenderinger:

• React.memo: Indkaps funktionelle komponenter, der ofte modtager de samme props, for at undgå unødvendig genrendering.
• useMemo: Gem resultaterne af ressourcekrævende beregninger, så de kun udføres, når forudsætningerne ændrer sig.
• useCallback: Gem callback-funktioner i cachen for at undgå unødvendig genoprettelse af funktioner, især når der overføres funktioner til underordnede komponenter.

Brug dem kun, når profilering viser, at der er flaskehalse i ydeevnen, da overdreven memoization kan medføre unødvendig kompleksitet.

Hvordan virtualiserer jeg store lister i React?

Virtualisering gengiver kun de synlige elementer i en lang liste i stedet for alle elementer i DOM. Dette forbedrer gengivelsesydelsen betydeligt og reducerer hukommelsesforbruget. Biblioteker som f.eks. react-window og react-virtualized bruges ofte til effektivt at vise tusindvis af rækker og samtidig sikre jævn rulning.

Hvordan kan jeg optimere billeder i en React-app?

Billedoptimering forbedrer sidens hastighed og brugeroplevelsen ved at:

• Komprimering af billeder før implementering.
• Ved hjælp af moderne formater som WebP eller AVIF.
• Visning af responsive billeder i passende størrelser.
• Implementering af »lazy loading« for billeder, der ligger under folden.
• Brug af et CDN til hurtigere levering af billeder.

Disse fremgangsmåder reducerer forbruget af båndbredde og forbedrer Core Web Vitals.

Hvad er »lazy loading«, og hvilke komponenter bør jeg anvende »lazy loading« på i React?

Lazy loading udskyder indlæsningen af komponenter, indtil der reelt er brug for dem. Det reducerer den indledende filstørrelse og gør indlæsningen af den første side hurtigere.

Eksempler på elementer, der egner sig godt til lazy loading, er:

• Rute-baserede sider
• Administrator-dashboards
• Indstillingssider
• Diagrammer og analysemoduler
• Store former
• Modalvinduer og dialogbokse
• Tredjepartskomponenter, der ikke umiddelbart er synlige

React tilbyder React.lazy() og Spænding for at implementere lazy loading på en effektiv måde.

Hvordan kan jeg løbende overvåge ydeevnen i en React-app?

Overvågning af ydeevnen bør være en løbende proces. Overvåg regelmæssigt nøgletal som f.eks. sidens indlæsningstid, reaktionstid ved interaktion, bundtstørrelse og Core Web Vitals. Brug værktøjer som Lighthouse, React DevTools Profiler, Chrome DevTools’ Performance-panel og RUM-løsninger (Real User Monitoring) til at identificere flaskehalse. Kontinuerlig overvågning hjælper med at opdage forringelser i ydeevnen på et tidligt tidspunkt og sikrer, at din React-applikation forbliver hurtig, efterhånden som den udvikler sig.