Webbläsarrendering: från text till bilder

Men mina tankar förändrades när jag i praktiken upplevde animeringens stamning eller skärmens ryck när jag rullade (jank). ”Varför fungerar samma kod smidigt i Chrome men kraschar i Internet Explorer (IE)?” ”Varför skjuter min CPU i höjden när jag ändrar stilen bara lite med JavaScript?”

Det visar sig att webbläsaren inte bara är en bildram. Webbläsaren var en enorm ’målare’ och ’arkitekt’ som tolkade texten (HTML/CSS) vi skickade, beräknade matematiskt varje pixel och skrev ut den.

Förra gången levererade vi data säkert via tuffa nätverksvägar. Den här gången ska vi öppna datarutan (paketet) som kom och ta reda på hur webbläsaren ritar en bild som kallas skärmen. Det här är den sista historien i Re: Booting CS Basics-serien.

Lasten anlände, monteringen börjar

I vårt ’digitala logistikcenter’ världsbild har produkten (HTML-fil) nu anlänt till kundens hem (webbläsare). Det som kom var dock inte en färdig produkt, utan en ‘monteringsmanual’. Arbetslaget som kallas webbläsarmotorn (renderingsmotorn) läser denna manual och börjar omedelbart monteringen. Denna process kallas renderingspipeline.

Steg 1: Ritningsanalys (Parsing & DOM Tree)

Läser HTML-texten som kommer först och skapar ett ’skelett’.

• <html> är roten (Root), <body> är stammen, <div> är grenarna…
• Det som byggs upp i en sådan trädstruktur (Tree) kallas DOM (Document Object Model). Det är också det API som gör att JavaScript senare kan röra vid det här skelettet.

Steg 2: Inredning (CSSOM-träd)

Läs sedan CSS-filen och skapa ”stilregler”.

• ”Alla div är röda”, ”Den som har klassen box får storleken 100px”
• Detta kallas CSSOM (CSS Object Model).

Steg 3: Skapa en arbetsorder (Render Tree)

Nu kombinerar vi skelettet (DOM) och design (CSSOM). Den viktiga punkten här är att endast ”saker som faktiskt kommer att visas på skärmen” väljs.

• Ett element med egenskapen display: none? Det kommer inte att synas på skärmen, så det utesluts från renderingsträdet. (Det tar inte heller någon plats)
• Och visibility: hidden då? Elementet syns inte men tar ändå plats, så det ingår i renderingsträdet.

[Kodverifiering] Reflow och repaint

Nu är det verkligen viktiga steget. Nyckeln till prestandaoptimering ligger här. När renderingsträdet har skapats utför webbläsaren två tunga uppgifter.

1. Layout / omflödning (Reflow): Räknar matematiskt ut ’var och i vilken storlek’ varje element ska placeras. (Arkitektritningen)
2. Målning (Paint) / ommålning (Repaint): På de uträknade positionerna ’läggs färgen på’ på riktigt. (Målningsarbetet)

Låt oss känna skillnaden i kostnad med koden.

const box = document.getElementById('box');

// Case 1: Kod som utloser layout (Reflow) (dyrt!)
// Om storlek eller position andras maste kringliggande element rakna om.
box.style.width = '200px'; 
box.style.height = '200px';
box.style.margin = '20px';

// Case 2: Kod som bara utloser paint (Repaint) (relativt billigt)
// Position oforandrad, bara fargen andras. Ingen omrakning, bara ommalning.
box.style.backgroundColor = 'blue';
box.style.color = 'white';
box.style.visibility = 'hidden';

Analys:

• Ändra width: Det är ett bygge som ändrar själva byggnadens storlek. Grannhuset knuffas undan, och huset bredvid det också. Webbläsaren måste ta fram miniräknaren och räkna om allt. (Reflow uppstår -> huvudboven bakom sämre prestanda)
• Ändra color: Byggnadens storlek lämnas som den är, bara fasaden målas om. Ingenting behöver räknas om. (Repaint uppstår -> snabbt)

I praktiken uppstår de flesta fall av ”stamningsanimering” eftersom layoutegenskaper som width, left och top berörs i realtid. I det här fallet behövs en teknik för att hoppa över layoutberäkningen genom att använda egenskaper som transform.

Praktiska råd: Mobba inte din webbläsare

Jag visste inte detta när jag gick på college, så jag manipulerade DOM slumpmässigt med JavaScript. Genom att gå igenom for-satsen ändrade jag storleken och stilen för varje element. Ur webbläsarens perspektiv är det som att bli torterad genom att förstöra och bygga om en byggnad dussintals gånger per sekund.

Tips för att säkerställa prestanda:

1. Samla DOM-ändringarna och gör dem på en gång: Ändra inte stilarna en i taget, utan förbered en class i förväg och byt bara className en enda gång.
2. Lämna animeringar till GPU:n: Om du använder transform: translate() i stället för left och top hoppar webbläsaren över layoutsteget och GPU:n tar hand om resten.
3. Skillnaden när du döljer något: Ska elementet bort helt, använd display: none (utesluts från renderingsträdet); ska bara platsen stå tom, använd visibility: hidden (ingår i renderingsträdet). Håll isär dem.

Avslutning av serie 1: Min CS startade om

Med den här artikeln har [Re: Booting] CS Basics-serien tagit slut.

Vi åkte på en lång resa tillsammans.

1. Språk (Language): Koden som människor skrev översattes till maskinkod (build),
2. Minne (Memory): flyttade in i rummen som heter stacken och heapen,
3. Process (OS): delade på CPU:n med hjälp av ett kloningstrick som kallas trådar,
4. Nätverk (Network): delades upp i paket och färdades längs tuffa vägar,
5. Rendering: och mötte till sist målaren som kallas webbläsaren, för att äntligen dyka upp framför våra ögon.

Först var det bara kunskap som jag memorerade för att få ett jobb. Men efter att ha stött på fel i praktiken och tittat igen var CS (datateknik) inte en död bokstav, utan en fast grund som stödde min kod.

Grundarbetet är nu klart. Det är dags att bygga ditt eget slott på fast mark. I nästa serie [Monolith Builder] kommer jag att täcka att bygga webbapplikationer med Spring Boot och Vue.js, som jag har upplevt i praktiken. Se fram emot processen att omvandla ”teori” till ”praktik”.