En introduktion til webydelse og den kritiske gengivelsessti

De fleste af os arbejder med internettet hver dag. Det er blevet normalt for os at få alle de oplysninger, vi har brug for, leveret til os næsten øjeblikkeligt. Men hvordan den webside faktisk er sammensat og leveret til os, er lidt af et mysterium.

Nogle gange er websider utroligt hurtige, og nogle gange er vi nødt til at vente længe på at se indholdet - hvilket ofte resulterer i, at vi er ret frustrerede og forlader siden. I den følgende artikel vil jeg forsøge at rydde op i tingene lidt.

Ansvarsfraskrivelse : Al den information, jeg deler i dette indlæg, er, hvad jeg har lært gennem de gratis kurser, der er nævnt nederst og opsummeret her for alle interesserede.

Den kritiske gengivelsessti

Først og fremmest ville det være nyttigt at forstå de trin, browseren faktisk gennemgår. Det starter med almindelige HTML-, CSS- og JavaScript-filer gennemgår gengivelse og maling af en side og ankommer til sidst for at blive det, som brugeren ser.

Disse trin fra dine forskellige HTML-, CSS- og JS-filer til en malet side kaldes almindeligvis den kritiske gengivelsessti (eller kort sagt CRP).

Den kritiske gengivelsessti består af fem forskellige trin, som bedst forklares i en grafik.

Opbygning af DOM og CSSOM

De fleste websider består af HTML, CSS og JavaScript, som alle udgør en kritisk del i CRP. For at læse og behandle din HTML konstruerer browseren Document Object Model (DOM). Browseren ser på HTML-tags (

,

,

og

osv.) i din markering og konverterer dem til tokens, som igen oprettes til noder parallelt. Ved at behandle disse StartTag-tokens og EndTag-tokes i rækkefølge og se, hvad der kommer først, kan browseren etablere deres hierarki og etablere forældre og børn.

Lad ikke denne terminologi skræmme dig. Forestil dig DOM som et stort træ med grene, der repræsenterer forældrenoder, og som igen indeholder blade, barnets noder. Dette træ repræsenterer afhængigheden af ​​noder i vores HTML og ser noget ud som dette:

På billedet ovenfor kan vi se rodelementet, der omfatter alle dets børn, som igen er forældre, der også indeholder børn. Sæt det på hovedet, så ser det næsten ud som et træ!

DOM repræsenterer således vores komplette HTML-markering. Som du så, er det opbygget trinvist ved at behandle tokens og konvertere dem til noder. Faktisk kan vi bruge det til vores fordel ved at returnere delvis HTML og give vores bruger en indikation om, at der sker noget og gengives på siden.

Efter konstruktion af DOM vil din browser behandle CSS og opbygge CSS Object Model (CSSOM). Denne proces ligner meget opbygningen af ​​DOM. Men i denne proces, i modsætning til før, arver barneknudepunkter deres moderknuders stylingregler - deraf navnet Cascading Style Sheets (CSS).

Desværre kan vi ikke trinvis behandle delvis CSS, som vi kunne med DOM, da det let kunne føre til anvendelse af de forkerte stilarter, hvis en overordnet stil kommer senere i processen. Dette er grunden til, at CSS gengiver blokering, da browseren skal stoppe gengivelsen, indtil den modtager og behandler al CSS.

Vores DOM-træ og CSSOM-træ indeholder alle de noder og afhængigheder, vi har på vores side.

Sortering af alt det synlige indhold - The Render Tree

Browseren skal vide, hvilke noder der rent faktisk skal vises visuelt på siden. Render Tree opnår præcis det og er en repræsentation af det synlige indhold af DOM og CSSOM.

Vi begynder at konstruere Render Tree ved at identificere rodnoden og derefter kopiere alle de synlige oplysninger fra DOM og CSSOM. Til dette kontrollerer vi også, at vi søger efter tags, der har den samme vælger. Metadata, links osv. Kopieres ikke til gengivelsestræet. Det samme gælder for CSS, der indeholder "display: none;" da det også er et ikke-synligt element.

Når vi har gennemført denne proces, får vi noget, der ligner nedenstående (bemærk, hvordan 'webydelse' ikke kopieres).

The Render Tree er en ret nøjagtig beskrivelse af, hvad der faktisk vises for dig på skærmen, der fanger både indhold og tilknyttede stilarter. Selvfølgelig vil dette se meget mere komplekst ud i eksempler på det virkelige liv.

Gør det passer rigtigt - Layout

Mens vi nu ved hvadvi har brug for at vise og gengive til siden, det er vigtigt at vide, hvordan den gengives. For at layoutet skal se korrekt ud, skal vi vide størrelsen på browseren. Vores layout afhænger af det for at beregne de korrekte positioner og dimensioner for alle vores elementer på siden.

Alt dette sker under Layout-trin. Det er især vigtigt for mobil at tage Layout-trin i betragtning, hvor vores synspunkt kan ændre sig, når vi skifter mellem liggende og stående, når vi roterer vores telefoner. Dette betyder, at browseren bliver nødt til at køre layouttrinnet igen hver gang vi drejer vores telefon, hvilket kunne være en ydeevne flaskehals.

Mal pixlerne

Dette trin indebærer faktisk at male pixels på skærmen, specificeret af hvad (Render Tree) og hvordan (Layout). Maleritrinet inkluderer det faktiske maleri af pixels (for eksempel når du ændrer størrelsen på et billede) i modsætning til bare at placere det. Det er, hvad du i sidste ende ser på din skærm bagefter.

Lad os opsummere

Lad os nu samle al denne information igen, så vi kan se, at vi har forstået alle de trin, vi skal gennemgå i CRP (Critical Rendering Path).

  1. Browseren starter med at konstruere DOM ved at analysere al relevant HTML.
  2. Derefter fortsætter det med at se på CSS- og JavaScript-ressourcerne og anmode om dem, hvilket normalt sker i hovedet, hvor vi ofte lægger vores eksterne links.
  3. Browseren analyserer derefter CSS og konstruerer CSSOM efterfulgt af kørsel af JavaScript.
  4. Derefter flettes DOM og CSSOM sammen til Render Tree.
  5. Vi kører derefter Layout og malingstrin for at præsentere siden for brugeren.

Okay, det er godt at vide - men hvorfor betyder det noget?

Nu er det hele pænt at vide, og vi har fået en bedre forståelse af, hvad browseren rent faktisk laver i baggrunden. Men hvorfor betyder det nøjagtigt? Skal vi alle vide, hvad der sker under emhætten?

Ja vi gør!

Hvis vi bliver ved med at øge størrelsen på vores filer og ikke er opmærksomme på, hvad vi beder browseren om at gengive og male på siden, skal browseren længere tid til at behandle alle ressourcerne. Dette resulterer normalt i en langsommere og mindre behagelig brugeroplevelse, hvilket betyder at sider ikke kan bruges og gengives korrekt, hvilket fører til frustration på brugerens side.

Dette gælder især hvis du anmoder om en side fra et landdistrikt, hvor hurtig bredbånd ikke nødvendigvis er den bedste.

Men heldigvis er der et par måder omkring dette, og vi kan gøre vores sider hurtigere!

Optimering af ydeevne

Der er en række strategier, vi kan udnytte for at gøre vores sider hurtigere og bedre at bruge for vores brugere. Dette er især vigtigt for brugere, der muligvis befinder sig mere fjerntliggende steder, hvor hurtigere internet ikke er normen, eller hvor sider ofte er tilgængelige via mobilt internet.

Når vi taler om optimeringsstrategier, har vi stort set tre teknikker til rådighed.

Minifiering, komprimering og caching

Disse teknikker kan alle anvendes på vores HTML, CSS og JS. Derefter reducerer de mængden af ​​data, som vi sender frem og tilbage mellem klienten og serveren, gennem deres mindre størrelse. Jo færre byte vi skal sende, jo hurtigere får browseren dataene og begynder at behandle og gengive siden.

Minimer brugen af ​​render-blokerende ressourcer (CSS)

CSS i sig selv gengiver blokering som vi diskuterede ovenfor, hvilket betyder at browseren stopper gengivelsen af ​​siden, indtil CSS er fuldt indlæst og behandles.

Vi kan dog afbøde for store CSS-filer ved at fjerne blokering af gengivelsen for bestemte stilarter og visningsport. Vi gør dette ved at bruge udskriftsregler i vores medieforespørgsler, analyse og enhedsretning (hvis du vil vide hvordan, foreslår jeg, at du tjekker ressourcerne nedenfor). Vi kan desuden reducere antallet af ressourcer, der skal indlæses, ved at indsætte nogle af vores CSS under visse omstændigheder.

Minimer brugen af ​​parserblokerende ressourcer (JS-dokumentparser)

Vi kan også udskyde udførelsen af ​​vores JavaScript og bruge async-attributter i vores script for at opnå dette. Det betyder, at resten af ​​siden kan behandles, og i mellemtiden ser brugeren en indikation på, at der sker noget på siden. Det betyder også, at vi ikke behøver at vente på, at JavaScript indlæses.

Så bredt set efterlader det os med 3 optimeringsmønstre:

  1. Minimer antallet af byte, du sender
  2. Reducer antallet af kritiske ressourcer i den kritiske gengivelsessti (analytics behøver muligvis ikke at blive indlæst i starten, når siden er bygget)
  3. Forkort den kritiske gengivelsessti-længde (hvilket betyder at reducere antallet af rundrejser mellem din browser og den server, som vi har brug for for at gengive siden)

Prøv det selv

Hvis du er vild med at prøve dette og begynde at optimere, kan du måle ydeevnen på dit websted eller andre med et antal værktøjer. De nemmeste er sandsynligvis Google-produkter som PageSpeedInsights eller Google Lighthouse, en praktisk lille Google Chrome-udvidelse, som du nemt kan installere gennem Chrome App Store.

Klik bare på udvidelsen, og generer derefter en rapport, så får du en rapport, der indeholder følgende:

Du kan derefter sammenligne din præstation med en række metrics, såsom First Pixel Painted til skærmen, First Interactive, Visual Compleetness på dit websted og mange andre.

Din foretrukne browsers Dev-værktøjer er også et godt sted at se på med hensyn til at finde ud af belastningstider og ydeevne flaskehalse. Hvis du holder de samlede belastningstider lave, vil det helt sikkert øge den samlede hastighed, hvormed dit websted serveres til dine slutbrugere.

Konklusion

Forhåbentlig har dette belyst det indre arbejde med, hvordan din browser viser en side for dig, og det tunge arbejde, den skal udføre i baggrunden for at sikre, at din HTML, CSS og JavaScript transformeres korrekt.

At være opmærksom på disse trin hjælper os med at gøre eksisterende sider mere performante. Men det gør det også muligt for os at være opmærksomme på, hvordan vi udvikler applikationer og websteder, og overveje, hvordan vores sider ser ud til mennesker i andre områder af verden.

Ressourcer

Det meste af min viden, som jeg har delt her, har jeg erhvervet gennem følgende:

  1. Optimering af webstedsydelse på Udacity
  2. Hvorfor præstationer er vigtige for Google-udviklere
  3. High Performance Browser Networking af Ilya Grigorik (//hpbn.co/)
  4. Websteder med høj ydeevne: Essential Knowledge for Front-end Engineers af Steve Souders