CSS contain

Kort fortalt: CSS-egenskaben contain fortæller browseren at et element er mere “selvstændigt” end normalt. Det gør at browseren kan begrænse hvor langt layout- og paint-arbejde spreder sig, når noget ændrer sig – og det kan give mærkbar gevinst på lange sider og komponenttunge layouts.

Hvad betyder contain?

Normalt kan en lille ændring i DOM (tekst ændrer sig, billede loader, komponent åbner) trigge layout-arbejde i store dele af siden. contain lader dig sige: “den her komponent påvirker ikke resten af siden på samme måde”.

Der findes flere containment-typer. De vigtigste at forstå er:

• contain: layout: layout-beregninger afgrænses
• contain: paint: painting/clipping afgrænses
• contain: size: elementet “lover” at dets størrelse ikke afhænger af indholdet (kraftigt – og farligt hvis forkert)
• contain: content: kombinerer typisk layout + paint (og nogle gange size – afhængigt af specifikation/version)

Hvorfor er det vigtigt?

Performance (rendering og interaktion)

Containment kan reducere:

• dyre reflows (layout) der ellers spreder sig op og ud i DOM
• dyre repaints der ellers påvirker store områder
• og dermed forbedre oplevelsen ved interaktion (tæt på INP, især når UI åbner/lukker paneler)

Hvis du oplever at et klik “fryser” siden, er det ofte fordi browseren skal lave for meget layout/paint efter DOM-ændringen. contain kan være en del af løsningen – sammen med at reducere JS-arbejde og DOM-ændringer.

Mere forudsigelig komponentadfærd

Containment kan også fungere som en “kontrakt”: komponenten bør være isoleret og ikke afhænge af omverdenens layout. Det kan gøre design-systemer mere robuste.

Eksempel: Hvornår giver det mening?

Gode kandidater:

• Cards i en lang liste
• Kommentar-/FAQ-sektioner hvor expansion ikke bør trigge layout på hele siden
• Sidebars og panels der toggles

Hvis du samtidig bruger content-visibility til at springe offscreen-indhold over, kan contain hjælpe de dele der er onscreen til at være billigere at opdatere.

Typiske fejl og misforståelser

1) “Bare sæt contain: content på alt”

Det kan give bugs. Containment ændrer layout-kontrakter, og især size-containment kan få elementer til at måle “forkert” hvis indholdet faktisk bestemmer højden.

Start med isolerede komponenter hvor du kan teste visuelt.

2) “Containment løser render-blocking”

Nej. Render-blocking handler om ressourcer (CSS/JS) der blokerer første paint. Se render-blocking og Critical CSS for den del. contain er mere relevant når siden kører og ændrer sig.

3) “Containment er kun en micro-optimering”

På små sider: ja. På lange indholdssider med mange komponenter kan det være en af de få CSS-ændringer der reelt flytter noget – især når brugere scroller og interagerer.

Hvordan du måler om det hjælper

For øvede:

• Profilér i Chrome DevTools Performance
• Kig efter store layout/paint-blokke omkring interaktioner
• Sammenlign før/efter med samme viewport og samme data

For begyndere:

• Mærk efter: “bliver det mere responsivt når jeg åbner/lukker UI?”
• Brug Lighthouse/PSI til at se om “Avoid large layout shifts” og “Main-thread work” ændrer sig – men stol mest på DevTools traces når det handler om contain.

Relaterede begreber

• content-visibility – spring offscreen rendering over
• INP – interaktionsrespons hvor layout/paint ofte er en del af problemet
• Long Task og Main thread – når JS blokerer før browseren overhovedet når til layout/paint