Hvordan skrive bedre CSS med ytelse i tankene

I dagens innlegg vil vi tenke over de kodevalgene vi kan lage i CSS for forbedret ytelse på nettstedet. Men før vi dykker inn i disse valgene, la oss først ta en kort, nærmere titt på nettsiden som gjengir arbeidsflyten for å fokusere påproblematiske (ytelsesmessige) områder som kan løses via CSS.

Her er den svake strømmen av operasjoner utført av nettleseren etter DOM-treopprettelsen:

1. Beregn stil (og gjeng træropprettelse). Browser beregner stilene som skal brukes på elementene i DOM-treet. Et gjengetre blir senere opprettet mens du kasserer nodene (elementene) fra DOM-treet som ikke skal gjengis (elementer med display: none) og de som er (pseudo-elementer).
2. Layout (aka Reflow). Ved å bruke den beregnede stilen fra før beregner nettleseren posisjonen og geometrien til hvert element på siden.
3. repaint. Når oppsettet er kartlagt, trekkes piksler til skjermen.
4. Komposittlag. Under maling kan maleriet gjøres i forskjellige lag autonomt; disse lagene blir så endelig kombinert sammen.

La oss nå fortsette med det vi kan gjøre i de tre første stadiene av operasjonen for å skrive bedre resultater CSS-koder.

1. Reduser stilberegninger

Som omtalt tidligere, beregner nettleseren stilene som skal brukes på elementene i "Rekalculate Style" -stadiet. For å gjøre dette, finner nettleseren først alle selektorer i CSS som peker på en gitt elementskode i DOM-treet. Deretter går det gjennom alle stilregler i disse selektorer og bestemmer hvilke som faktisk skal brukes på elementet.

For å unngå kostbare stilberegninger, redusere komplekse og dypt nestede selektorer slik at det er lettere for nettleseren å finne ut hvilket element en velger refererer til. Dette reduserer beregningstiden.

Andre måter å ansette inkluderer reduserer antall stilregler (Hvor mulig), fjerner ubrukt CSS og unngår redundans og overstyrrelser, slik at nettleseren ikke må gå gjennom samme stil igjen og igjen under stilberegninger.

2. Reduser Reflows

Reflows eller Layout endringer i et element er svært "dyre" prosesser, og de kan være et enda større problem når elementet som gikk gjennom layoutendringene, har en betydelig mengde barn (siden Reflows kaskade ned hierarkiet).

Reflows utløses av layoutendringer til et element, for eksempel endringer i geometriske egenskaper som høyde eller skriftstørrelse, tillegg eller fjerning av klasser til elementer, justering av vinduer, aktivert :sveve, DOM endres av JavaScript, etc..

Akkurat som i stilberegning, for å redusere Reflows, unngå komplekse selektorer og dype DOM-trær (igjen, dette er for å hindre overdreven cascading av Reflows).

Hvis du må endre layoutformatene til en komponent på siden din, mål stilene på elementet som er lavest i elementarhierarkiet at komponenten er laget av. Dette er slik at layoutendringene ikke utløser (nesten) andre Reflows.

Hvis du animerer et element som går gjennom layoutendringer, ta det ut av sidestrømmen av absoutely posisjonering det, siden Reflow i absolutt posisjonerte elementer ikke vil påvirke resten av elementene på siden.

Til oppsummering:

• Målelementer som er lavere i DOM-treet når du foretar layoutendringer
• Velg absolutt plasserte elementer for layoutendring animasjoner
• Unngå å animere layoutegenskaper når det er mulig

3. Reduser Repaints

Omfarging refererer til tegning av piksler på skjermen, og er en kostbar prosess akkurat som Reflow. Repaints kan utløses av Reflows, sideskroll, endringer i egenskaper som farge, synlighet og opasitet.

For å unngå hyppige og store repaints, bruk mindre av egenskapene som forårsaker kostbare repaints som skygger.

Hvis du er animerende egenskaper til et element som kan utløse Repaint direkte eller indirekte, vil det ha stor fordel hvis det elementet er i sitt eget lag for å hindre at malingen presterer fra å påvirke resten av siden og utløse maskinvareakselerasjon. Ved maskinvareaccelerasjon vil GPU ta opp oppgaven med å utføre animasjonsendringene i laget, og sparer CPU-ekstraarbeidet mens hastigheten på prosessen økes..

I noen nettlesere, opasitet (med en verdi mindre enn 1) og forvandle (verdi annet enn ingen) blir automatisk forfremmet til nye lag, og maskinvareaccelerasjon brukes for animasjoner og overganger. Foretrukket disse egenskapene for animasjoner er således god.

Å tvinge Fremmer et element til nytt lag og gå inn i maskinvareakselerasjon for animasjon er det to teknikker invovled:

1. Legg til transformere: translate3d (0, 0, 0); til elementet, lure nettleseren til å utløse maskinvareakselasjonen for animasjoner og overganger.
2. Legg til Kommer til å endres eiendom til elementet, som informerer nettleseren om egenskapene som sannsynligvis vil endre seg i elementet i fremtiden. Merk: Sara Soueidan har en grundig og super nyttig artikkel om dette på Dev.Opera-siden.

Til oppsummering:

• Unngå dyre stiler som forårsaker Repaints
• Søk lagkampanje og maskinvareakselerasjon for kraftige animasjoner og overganger.

Ta notat

(1) Så langt har vi ikke berørt CSS filstørrelsesreduksjon. Vi har nevnt at reduksjon i stilregler (og DOM-elementer) gir en betydelig ytelsesforbedring på grunn av hvor mye nettleseren må jobbe mindre på prosessen med å beregne stilene. Som en konsekvens av denne kodeneduksjonen, skriver du bedre valgorer og slettingen av ubrukt CSS, filstørrelsen reduseres automatisk.

(2) Det er også tilrådelig å Ikke gjør for mange konsekvensendringer til elementets stiler i JavaScript. Legg i stedet en klasse til elementet (ved hjelp av JavaScript) som inneholder de nye stilene for å gjøre disse endringene - dette forhindrer unødvendig Reflows.

(3) Du vil ønske å unngå Layout Thrashing også (tvunget synkron reflow) som oppstår på grunn av tilgang og modifisering av Layout egenskaper av elementer som bruker JavaScript. Les mer om hvordan dette dræper ytelsen her.