# Ytelse for CSS-gradienter: gjør gradienter en side tregere?

[Canonical HTML page](https://gradiently.design/nb/guide/css-gradient-performance)

En statisk CSS-gradient er nesten gratis. Kostnadene kommer fra det folk gjør med gradienter: enorme uskarphetseffekter, bakgrunner som tegnes om ved rulling og animasjoner som aldri stopper. Slik ser du forskjellen.

## The short version

- En statisk CSS-gradient koster nesten ingenting å laste, for den er en tekstlinje og ikke en fil som må lastes ned og dekodes.
- Gradienter koster tegnetid, som vokser med det malte arealet og antall lag, men en statisk gradient males én gang og gjenbrukes.
- De reelle ytelsesrisikoene er store uskarphetsfiltre, bakgrunner som tegnes om under rulling og gradientanimasjoner som tegnes om for hvert bilde.
- Å animere transform eller opacity på et gradientlag er som regel langt billigere enn å animere background-position eller fargestopp.
- Det eneste pålitelige svaret for en bestemt side er å måle den, med paint flashing og en Performance-opptaking i nettleserens utviklerverktøy.

God **ytelse for CSS-gradienter** er det normale: en statisk gradient gjør ikke et nettsted tregere på noen måte du kan merke. Den er en tekstlinje, så det er ingenting å laste ned, ingenting å dekode og ingenting å vente på. Gradienter koster litt tegnetid, som alle andre farger på siden. Trege sider kommer fra noen få bestemte mønstre bygget oppå gradienter: store uskarphetseffekter, omtegning ved rulling og animasjoner som tegnes om for hvert bilde. Denne guiden viser hva som er hva og hvordan du sjekker din egen side.

## Lasting: gradienter mot bilder

`background: linear-gradient(135deg, #1e1b4b, #7c3aed 55%, #f472b6);` er 67 tegn. Den kommer inne i stilarket ditt, trenger ingen ekstra forespørsel og gjengis skarpt i alle størrelser og pikseltettheter. En bildebakgrunn trenger sin egen forespørsel, må dekodes før den kan tegnes og må være stor nok til store skjermer med høy tetthet.

67 tegn med CSS: `linear-gradient(135deg, #1e1b4b, #7c3aed 55%, #f472b6)`

Hele denne bakgrunnen, i alle størrelser, koster mindre enn en setning tekst å laste.

| Bakgrunn | Nedlasting | Dekodet minne ved 1920×1080 |
| --- | --- | --- |
| CSS-gradient | Noen titalls byte i CSS-en din | Ingen bitmap å beholde, males etter behov |
| Komprimert bilde (AVIF, WebP, JPEG) | En egen fil, ofte titalls til hundrevis av kilobyte | Omtrent 8,3 MB (bredde × høyde × 4 byte) |
| Samme bilde ved 3840×2160 til skarp 4K | Enda større | Omtrent 33 MB |

Dekodede bilder holdes som fulle bitmaps, uansett filstørrelse. Minnetallene er enkel aritmetikk: piksler ganger fire byte.

For enkle og moderat lagdelte bakgrunner vinner altså CSS på lasting hver gang. Bilder gir fortsatt mening når bakgrunnen er virkelig kompleks, som en malerisk [mesh-gradient](https://gradiently.design/nb/guide/css-mesh-gradient) med mange fargepunkter eller en fotografisk tekstur. Da er avveiningen filvekt mot visuell rikdom, og den er ofte verdt det.

## Tegning: hva en gradient koster på skjermen

For å vise en gradient regner nettleseren ut en farge for hver piksel den dekker: det er tegning. Arbeidet vokser med det malte arealet, antall stablede gradientlag og eventuelle effekter oppå. For en statisk bakgrunn skjer det én gang, og resultatet gjenbrukes mens du ruller eller samhandler, med mindre noe gjør det ugyldig.

### Tegnet én gang

- En statisk gradient på et kort eller en hero
- Flere lagdelte radielle glød som ikke beveger seg
- En flislagt støytekstur over en gradient
- En gradientkant tegnet med bakgrunner

### Tegnet om og om igjen

- Å animere `background-position` eller fargestopp
- `background-attachment: fixed` under rulling
- `backdrop-filter`-uskarphet over innhold som beveger seg
- Et element med en gradient som endrer størrelse hele tiden

## De reelle risikoene: uskarphet, faste bakgrunner og animasjon

**Store uskarphetseffekter.** `filter: blur()` og `backdrop-filter` tar prøver av mange omkringliggende piksler for hver piksel, og arbeidet vokser med både uskarphetsradius og areal. En uskarp gradient som males én gang, er som regel greit. En `backdrop-filter` over innhold som ruller under, må regnes ut på nytt mens innholdet beveger seg, og der har [glassmorfisme](https://gradiently.design/nb/guide/glassmorphism)-grensesnitt en tendens til å hakke på beskjedne mobiler.

**Faste bakgrunner.** `background-attachment: fixed` holder en bakgrunn i ro mens siden ruller, noe som kan tvinge den til å tegnes om for hvert rulletrinn. Vil du ha en gradient som blir stående, er et `position: fixed`-element bak innholdet som regel billigere, fordi nettleseren kan flytte det som et eget lag.

**Animasjon.** Å flytte `background-position` eller animere fargestopp gjennom `@property` tegner elementet om for hvert bilde. På en knapp er det trivielt. På en fullskjerms hero er det kontinuerlig arbeid så lenge siden er åpen, noe som viser seg som varme og batteridrenering på mobiler.

```css
/* repaints the whole hero every frame */
.hero--costly {
  background: linear-gradient(120deg, #1e1b4b, #7c3aed, #f472b6);
  background-size: 300% 300%;
  animation: pan 12s ease-in-out infinite alternate;
}

/* the browser can usually just move a finished layer */
.hero--cheap::before {
  content: "";
  position: absolute;
  inset: -50%;
  z-index: -1;
  background: conic-gradient(#1e1b4b, #7c3aed, #f472b6, #1e1b4b);
  animation: turn 40s linear infinite;
}

@keyframes pan { to { background-position: 100% 50%; } }
@keyframes turn { to { transform: rotate(1turn); } }
```

To animerte heroer. Den andre animerer `transform`, som nettlesere som regel kan håndtere på sammensetteren uten å tegne om.

Guiden om [animerte gradienter i CSS](https://gradiently.design/nb/guide/css-animated-gradient) har hele settet med teknikker, fra billigst til mest fleksibelt.

## Lag og will-change

Å løfte et element opp til sitt eget sammensetterlag, med `will-change: transform` eller en aktiv transform-animasjon, er det som gjør billig animasjon mulig. Det er ikke gratis: hvert lag holder sin egen bitmap i grafikkminnet, omtrent bredde × høyde × 4 byte i enhetspiksler. Ett overdimensjonert lag til en hero-bakgrunn er greit. Dusinvis av løftede kort, hver med sitt eget gradientlag, kan bruke mer minne enn de sparer i tegnetid. Legg `will-change` på elementene som faktisk animeres, ikke som en generell regel.

| Mønster | Nettleserarbeid | Billigere alternativ |
| --- | --- | --- |
| Animert `background-position` på en hero | Omtegning for hvert bilde | `transform` på et overdimensjonert gradientlag |
| `background-attachment: fixed` | Omtegning under rulling | Et `position: fixed`-gradientlag bak innholdet |
| `backdrop-filter` over innhold som ruller | Uskarphet regnes ut på nytt mens innholdet beveger seg | Et forhåndsuskarpt statisk lag, eller et mindre uskarpt område |
| Levende SVG-støyfilter på et stort element | Filteret kjører over hver piksel som tegnes om | Et lite flislagt støybilde |
| `will-change` på hvert kort | Mange lag holdt i grafikkminnet | `will-change` bare på det som animeres |

Vanlige gradientmønstre, hva de får nettleseren til å gjøre, og den lettere måten å få samme uttrykk på.

## Slik måler du gradientytelse

1. **Slå på paint flashing** Åpne Rendering-panelet i Chrome DevTools og slå på Paint flashing. Alt som blinker grønt mens ingenting skal endres, tegnes om.
2. **Ta opp et Performance-spor** Ta opp noen sekunder med rulling eller animasjon i hvile i Performance-panelet. Se på hvor mye av hvert bilde som går til tegning, og om bilder droppes.
3. **Strupe CPU-en** Bruk CPU-struping i Performance-panelet for å simulere en tregere enhet. En hero som er jevn på en rask bærbar, kan slite på en mobil i mellomklassen.
4. **Sjekk Layers-panelet** Se hvor mange sammensetterlag som finnes og hvor mye minne de bruker. Uventet mange lag betyr som regel at `will-change` er overbrukt.
5. **Test på den ekte enheten** Avslutt på en faktisk mobil. Varme og batteridrenering fra konstant animasjon er lett å overse på en stasjonær.

[web.devs guide til renderingsytelse](https://web.dev/articles/rendering-performance) forklarer rørledningen bak disse verktøyene: stil, layout, tegning og sammensetting. Å vite hvilket trinn gradienten din utløser, forteller deg om den er billig.

## En sjekkliste for gradientytelse

- Bruk CSS-gradienter til enkle og lagdelte bakgrunner, og bilder bare når uttrykket virkelig trenger dem.
- Hold uskarphetsradiene moderate, og unngå `backdrop-filter` over store rulleområder.
- Bytt ut `background-attachment: fixed` med et lag i fast posisjon.
- Animer `transform` eller `opacity`, ikke `background-position`, på store flater.
- Langsomme stemningsanimasjoner kan stoppe helt for brukere med [redusert bevegelse](https://gradiently.design/nb/guide/reduced-motion).
- Legg til korn som et lite flislagt bilde, ikke et levende SVG-filter på et stort element. Se [CSS-støytekstur](https://gradiently.design/nb/guide/css-noise-texture).
- Mål før og etter med paint flashing og en Performance-opptaking.

## FAQ

### Gjør CSS-gradienter et nettsted tregere?

Statiske CSS-gradienter gjør ikke det på noen merkbar måte. De trenger ingen nedlasting og males én gang. Store uskarphetseffekter, faste bakgrunner og konstant animasjon er det som koster ytelse.

### Er en CSS-gradient raskere enn et bakgrunnsbilde?

Som regel ja. En gradient er noen titalls byte CSS uten forespørsel eller dekoding, mens et bilde trenger en nedlasting og holdes i minnet som en full bitmap.

### Er animerte gradienter dårlig for ytelsen?

Å animere `background-position` eller fargestopp tegner om for hvert bilde, noe som betyr noe på store flater. Å animere `transform` eller `opacity` på et gradientlag er som regel mye billigere.

### Hvorfor er den uskarpe gradientbakgrunnen min treg?

Uskarphet tar prøver av mange nabopiksler for hver piksel, så kostnaden vokser med radius og areal. Det er verst med `backdrop-filter` over innhold som ruller eller animeres.

### Hvordan sjekker jeg om gradienten min tegnes om?

Slå på Paint flashing i Rendering-panelet i Chrome DevTools. Områder som fortsetter å blinke mens siden er i ro, tegnes om.