Browserweergave: van tekst naar afbeeldingen

Mijn gedachten veranderden echter toen ik in de praktijk ervaarde dat de animatie stotterde of dat het scherm schokte tijdens het scrollen (jank). “Waarom werkt dezelfde code soepel in Chrome, maar crasht deze in Internet Explorer (IE)?” “Waarom schiet mijn CPU omhoog als ik de stijl een klein beetje verander met JavaScript?”

Het blijkt dat de browser niet alleen maar een fotolijstje is. De browser was een enorme ‘Schilder’ en ‘Architect’ die de tekst (HTML/CSS) die we stuurden interpreteerde, elke pixel wiskundig berekende en deze afdrukte.

De vorige keer hebben we veilig gegevens afgeleverd via ruige netwerkwegen. Laten we deze keer de databox (pakket) openen die is aangekomen en kijken hoe de browser een afbeelding tekent die het scherm wordt genoemd. Dit is het laatste verhaal in de Re: Booting CS Basics-serie.

Lading aangekomen, montage begint

In ons wereldbeeld ‘digitaal logistiek centrum’ is het product (HTML-bestand) nu bij de klant thuis aangekomen (browser). Wat er echter arriveerde was geen eindproduct, maar een ‘montagehandleiding’. Het werkteam genaamd de browser-engine (rendering-engine) leest deze handleiding en begint onmiddellijk met de montage. Dit proces wordt de weergavepijplijn genoemd.

Stap 1: Blauwdrukanalyse (parsing en DOM-structuur)

Leest de HTML-tekst die als eerste binnenkomt en creëert een ‘skelet’.

Stap 2: Interieurontwerp (CSSOM-boom)

Lees vervolgens het CSS-bestand en maak ‘stijlregels’.

Stap 3: Een werkorder maken (Renderboom)

Nu combineren we het skelet (DOM) en het ontwerp (CSSOM). Het belangrijke punt hier is dat alleen ‘dingen die daadwerkelijk op het scherm verschijnen’ worden geselecteerd.

[Codeverificatie] Opnieuw plaatsen en opnieuw schilderen

Nu is de echt belangrijke stap. De sleutel tot prestatie-optimalisatie ligt hier. Zodra de renderboom is gemaakt, voert de browser twee zware taken uit.

Laten we het verschil in kosten voelen met de code.

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

// Case 1: Code die layout (Reflow) veroorzaakt (duur!)
// Bij wijzigen van formaat of positie moeten omliggende elementen opnieuw berekend worden.
box.style.width = '200px'; 
box.style.height = '200px';
box.style.margin = '20px';

// Case 2: Code die alleen paint (Repaint) veroorzaakt (relatief goedkoop)
// Positie blijft gelijk, alleen kleur verandert. Geen herberekening, alleen herverven.
box.style.backgroundColor = 'blue';
box.style.color = 'white';
box.style.visibility = 'hidden';

Analyse:

In de praktijk komen de meeste gevallen van “stotterende animatie” voor omdat lay-outeigenschappen zoals width, left en top in realtime worden aangeraakt. In dit geval is een techniek nodig om de indelingsberekening over te slaan door eigenschappen als transform te gebruiken.

Praktisch advies: pest uw browser niet

Ik wist dit niet toen ik op de universiteit zat, dus manipuleerde ik willekeurig de DOM met JavaScript. Door de for-instructie te doorlopen, heb ik de grootte en stijl van elk element gewijzigd. Vanuit het perspectief van de browser is het alsof je wordt gemarteld door tientallen keren per seconde een gebouw te vernietigen en opnieuw op te bouwen.

Tips om prestaties te garanderen:

Afsluitende serie 1: Mijn CS opnieuw opgestart

Met dit artikel is de [Re: Booting] CS Basics Series ten einde.

We hebben samen een lange reis gemaakt.

In het begin was het alleen maar kennis die ik uit mijn hoofd leerde om een ​​baan te krijgen. Nadat ik echter in de praktijk fouten tegenkwam en opnieuw keek, was CS (computertechniek) geen dode letter, maar een solide basis die mijn code ondersteunde.

De funderingswerkzaamheden zijn nu voltooid. Het is tijd om je eigen kasteel op vaste grond te bouwen. In de volgende serie [Monolith Builder] zal ik ingaan op het bouwen van webapplicaties met behulp van Spring Boot en Vue.js, wat ik in de praktijk heb ervaren. Kijk uit naar het proces waarbij ‘theorie’ in ‘praktijk’ wordt omgezet.