Pārlūka renderēšanas konveijera apgūšana: padziļināts apskats par JavaScript ietekmi uz veiktspēju

Digitālajā pasaulē ātrums nav tikai funkcija; tas ir lieliskas lietotāja pieredzes pamats. Lēna, nereaģējoša vietne var izraisīt lietotāju neapmierinātību, palielināt atlēcienu līmeni un galu galā negatīvi ietekmēt biznesa mērķus. Kā tīmekļa izstrādātāji mēs esam šīs pieredzes arhitekti, un ir ļoti svarīgi izprast pamatmehāniku, kā pārlūkprogramma pārvērš mūsu kodu vizuālā, interaktīvā lapā. Šis process, kas bieži vien ir sarežģīts, ir pazīstams kā pārlūka renderēšanas konveijers.

Mūsdienu tīmekļa interaktivitātes pamatā ir JavaScript. Tā ir valoda, kas atdzīvina mūsu statiskās lapas, nodrošinot visu, sākot no dinamiskiem satura atjauninājumiem līdz sarežģītām vienas lapas lietojumprogrammām. Tomēr ar lielu spēku nāk liela atbildība. Neoptimizēts JavaScript ir viens no visbiežākajiem sliktas tīmekļa veiktspējas cēloņiem. Tas var pārtraukt, aizkavēt vai piespiest pārlūkprogrammas renderēšanas konveijeru veikt dārgu, lieku darbu, kas noved pie bēdīgi slavenā 'jank' — raustītām animācijām, lēnām reakcijām uz lietotāja ievadi un vispārēji gausu sajūtu.

Šis visaptverošais ceļvedis ir paredzēts front-end izstrādātājiem, veiktspējas inženieriem un ikvienam, kas aizraujas ar ātrāka tīmekļa veidošanu. Mēs demistificēsim pārlūka renderēšanas konveijeru, sadalot to saprotamos posmos. Vēl svarīgāk, mēs pievērsīsim uzmanību JavaScript lomai šajā procesā, precīzi izpētot, kā tas var kļūt par veiktspējas vājo vietu un, kas ir būtiski, ko mēs varam darīt, lai to mazinātu. Beigās jūs būsiet apbruņoti ar zināšanām un praktiskām stratēģijām, lai rakstītu veiktspējīgāku JavaScript kodu un nodrošinātu nevainojamu, apburošu pieredzi saviem lietotājiem visā pasaulē.

Tīmekļa projekts: Pārlūka renderēšanas konveijera dekonstrukcija

Pirms mēs varam optimizēt, mums vispirms ir jāsaprot. Pārlūka renderēšanas konveijers (zināms arī kā Kritiskais renderēšanas ceļš) ir soļu secība, ko pārlūkprogramma veic, lai pārvērstu jūsu rakstīto HTML, CSS un JavaScript kodu pikseļos uz ekrāna. Iedomājieties to kā ļoti efektīvu rūpnīcas montāžas līniju. Katrai stacijai ir noteikts uzdevums, un visas līnijas efektivitāte ir atkarīga no tā, cik raiti produkts pārvietojas no vienas stacijas uz nākamo.

Lai gan specifika var nedaudz atšķirties starp pārlūkprogrammu dzinējiem (piemēram, Blink pārlūkiem Chrome/Edge, Gecko pārlūkam Firefox un WebKit pārlūkam Safari), pamatposmi konceptuāli ir vienādi. Iziesim cauri šai montāžas līnijai.

1. solis: Parsēšana – no koda līdz izpratnei

Process sākas ar neapstrādātiem teksta resursiem: jūsu HTML un CSS failiem. Pārlūkprogramma nevar tieši strādāt ar tiem; tai ir nepieciešams tos parsēt struktūrā, ko tā var saprast.

• HTML parsēšana uz DOM: Pārlūkprogrammas HTML parsētājs apstrādā HTML iezīmes, tokenizējot tās un veidojot koka veida datu struktūru, ko sauc par Dokumenta Objektu Modeli (DOM). DOM attēlo lapas saturu un struktūru. Katrs HTML tags kļūst par 'mezglu' šajā kokā, veidojot vecāka-bērna attiecības, kas atspoguļo jūsu dokumenta hierarhiju.
• CSS parsēšana uz CSSOM: Vienlaikus, kad pārlūkprogramma saskaras ar CSS (vai nu <style> tagā, vai ārējā <link> stila lapā), tā to parsē, lai izveidotu CSS Objektu Modeli (CSSOM). Līdzīgi kā DOM, CSSOM ir koka struktūra, kas satur visus stilus, kas saistīti ar DOM mezgliem, ieskaitot netiešos lietotāja aģenta stilus un jūsu tiešos noteikumus.

Būtisks punkts: CSS tiek uzskatīts par renderēšanu bloķējošu resursu. Pārlūkprogramma neatveidos nevienu lapas daļu, kamēr nebūs pilnībā lejupielādējusi un parsējusi visu CSS. Kāpēc? Jo tai ir jāzina galīgie stili katram elementam, pirms tā var noteikt, kā izkārtot lapu. Lapa bez stiliem, kas pēkšņi maina savu izskatu, būtu traucējoša lietotāja pieredze.

2. solis: Renderēšanas koks – vizuālais projekts

Kad pārlūkprogrammai ir gan DOM (saturs), gan CSSOM (stili), tā tos apvieno, lai izveidotu Renderēšanas koku. Šis koks ir attēlojums tam, kas faktiski tiks parādīts lapā.

Renderēšanas koks nav DOM kopija viens pret vienu. Tas ietver tikai tos mezglus, kas ir vizuāli nozīmīgi. Piemēram:

• Mezgli, piemēram, <head>, <script> vai <meta>, kuriem nav vizuālas izvades, tiek izlaisti.
• Mezgli, kas ir skaidri paslēpti ar CSS (piemēram, ar display: none;), arī tiek atstāti ārpus Renderēšanas koka. (Ņemiet vērā: elementi ar visibility: hidden; tiek iekļauti, jo tie joprojām aizņem vietu izkārtojumā).

Katrs mezgls Renderēšanas kokā satur gan savu saturu no DOM, gan aprēķinātos stilus no CSSOM.

3. solis: Izkārtojums (jeb Reflow) – ģeometrijas aprēķināšana

Ar izveidoto Renderēšanas koku pārlūkprogramma tagad zina, ko renderēt, bet ne kur vai cik lielu. Tas ir Izkārtojuma posma uzdevums. Pārlūkprogramma šķērso Renderēšanas koku, sākot no saknes, un aprēķina precīzu ģeometrisko informāciju katram mezglam: tā izmēru (platumu, augstumu) un pozīciju lapā attiecībā pret skatvietu.

Šis process ir pazīstams arī kā Pārmaketēšana (Reflow). Termins 'reflow' ir īpaši trāpīgs, jo izmaiņas vienā elementā var izraisīt kaskādes efektu, pieprasot pārrēķināt tā bērnu, senču un blakuselementu ģeometriju. Piemēram, mainot vecākelementa platumu, visticamāk, tiks izraisīta pārmaketēšana visiem tā pēcnācējiem. Tas padara Izkārtojumu par potenciāli ļoti skaitļošanas ietilpīgu operāciju.

4. solis: Zīmēšana (Paint) – pikseļu aizpildīšana

Tagad, kad pārlūkprogramma zina katra elementa struktūru, stilus, izmēru un pozīciju, ir pienācis laiks šo informāciju pārvērst reālos pikseļos uz ekrāna. Zīmēšanas posms (jeb Pārkrāsošana) ietver pikseļu aizpildīšanu visām katra mezgla vizuālajām daļām: krāsām, tekstam, attēliem, apmalēm, ēnām utt.

Lai padarītu šo procesu efektīvāku, mūsdienu pārlūkprogrammas ne tikai zīmē uz viena audekla. Tās bieži sadala lapu vairākos slāņos. Piemēram, sarežģīts elements ar CSS transform vai <video> elements var tikt paaugstināts uz savu slāni. Zīmēšana tad var notikt katram slānim atsevišķi, kas ir būtiska optimizācija pēdējam solim.

5. solis: Kompozīcija – gala attēla salikšana

Pēdējais posms ir Kompozīcija. Pārlūkprogramma ņem visus atsevišķi uzzīmētos slāņus un saliek tos pareizā secībā, lai izveidotu gala attēlu, kas tiek parādīts ekrānā. Šeit kļūst acīmredzams slāņu spēks.

Ja jūs animējat elementu, kas atrodas savā slānī (piemēram, izmantojot transform: translateX(10px);), pārlūkprogrammai nav nepieciešams atkārtoti palaist Izkārtojuma vai Zīmēšanas posmus visai lapai. Tā var vienkārši pārvietot esošo uzzīmēto slāni. Šis darbs bieži tiek nodots Grafikas apstrādes blokam (GPU), padarot to neticami ātru un efektīvu. Tas ir noslēpums aiz zīdaini gludām, 60 kadru sekundē (fps) animācijām.

JavaScript grandiozā ienākšana: interaktivitātes dzinējs

Tātad, kur JavaScript iederas šajā glīti sakārtotajā konveijerā? Visur. JavaScript ir dinamiskais spēks, kas var modificēt DOM un CSSOM jebkurā brīdī pēc to izveides. Tā ir tā galvenā funkcija un lielākais veiktspējas risks.

Pēc noklusējuma JavaScript ir parsētāju bloķējošs. Kad HTML parsētājs sastopas ar <script> tagu (kas nav atzīmēts ar async vai defer), tam ir jāaptur DOM veidošanas process. Tad tas ielādēs skriptu (ja tas ir ārējs), izpildīs to un tikai tad atsāks HTML parsēšanu. Ja šis skripts atrodas jūsu dokumenta <head> sadaļā, tas var ievērojami aizkavēt jūsu lapas sākotnējo renderēšanu, jo DOM konstrukcija ir apturēta.

Bloķēt vai nebloķēt: `async` un `defer`

Lai mazinātu šo bloķējošo uzvedību, mums ir divi spēcīgi atribūti <script> tagam:

• defer: Šis atribūts liek pārlūkprogrammai lejupielādēt skriptu fonā, kamēr HTML parsēšana turpinās. Skripts tiek garantēti izpildīts tikai pēc HTML parsētāja pabeigšanas, bet pirms DOMContentLoaded notikuma. Ja jums ir vairāki atliktie skripti, tie tiks izpildīti tādā secībā, kādā tie parādās dokumentā. Šī ir lieliska izvēle skriptiem, kuriem nepieciešams pilns DOM un kuru izpildes secība ir svarīga.
• async: Šis atribūts arī liek pārlūkprogrammai lejupielādēt skriptu fonā, nebloķējot HTML parsēšanu. Tomēr, tiklīdz skripts ir lejupielādēts, HTML parsētājs apstāsies, un skripts tiks izpildīts. Asinhronajiem skriptiem nav garantētas izpildes secības. Tas ir piemērots neatkarīgiem, trešo pušu skriptiem, piemēram, analītikai vai reklāmām, kur izpildes secībai nav nozīmes un jūs vēlaties, lai tie darbotos pēc iespējas ātrāk.

Spēja mainīt visu: Manipulēšana ar DOM un CSSOM

Pēc izpildes JavaScript ir pilna API piekļuve gan DOM, gan CSSOM. Tas var pievienot elementus, noņemt tos, mainīt to saturu un mainīt to stilus. Piemēram: document.getElementById('welcome-banner').style.display = 'none'; Šī viena JavaScript rinda modificē CSSOM 'welcome-banner' elementam. Šīs izmaiņas padarīs nederīgu esošo Renderēšanas koku, liekot pārlūkprogrammai atkārtoti palaist renderēšanas konveijera daļas, lai atspoguļotu atjauninājumu ekrānā.

Veiktspējas vaininieki: kā JavaScript aizsprosto konveijeru

Katru reizi, kad JavaScript modificē DOM vai CSSOM, pastāv risks izraisīt pārmaketēšanu un pārkrāsošanu. Lai gan tas ir nepieciešams dinamiskam tīmeklim, šo operāciju neefektīva veikšana var apturēt jūsu lietojumprogrammu. Apskatīsim visbiežāk sastopamās veiktspējas lamatas.

Apburtais loks: piespiedu sinhronie izkārtojumi un izkārtojuma pārslogošana (Layout Thrashing)

Šī, iespējams, ir viena no nopietnākajām un smalkākajām veiktspējas problēmām front-end izstrādē. Kā mēs apspriedām, Izkārtojums ir dārga operācija. Lai būtu efektīvas, pārlūkprogrammas ir gudras un mēģina grupēt DOM izmaiņas. Tās ievieto jūsu JavaScript stila izmaiņas rindā un tad vēlāk (parasti pašreizējā kadra beigās) veiks vienu Izkārtojuma aprēķinu, lai piemērotu visas izmaiņas vienlaikus.

Tomēr jūs varat salauzt šo optimizāciju. Ja jūsu JavaScript modificē stilu un pēc tam nekavējoties pieprasa ģeometrisku vērtību (piemēram, elementa offsetHeight, offsetWidth vai getBoundingClientRect()), jūs piespiežat pārlūkprogrammu veikt Izkārtojuma soli sinhroni. Pārlūkprogrammai ir jāapstājas, jāpiemēro visas gaidošās stila izmaiņas, jāpalaiž pilns Izkārtojuma aprēķins un pēc tam jāatgriež pieprasītā vērtība jūsu skriptam. To sauc par piespiedu sinhrono izkārtojumu.

Kad tas notiek ciklā, tas noved pie katastrofālas veiktspējas problēmas, kas pazīstama kā izkārtojuma pārslogošana (Layout Thrashing). Jūs atkārtoti lasāt un rakstāt, piespiežot pārlūkprogrammu atkārtoti pārmaketēt visu lapu atkal un atkal viena kadra ietvaros.

Izkārtojuma pārslogošanas piemērs (Ko NEDRĪKST darīt):

            
function resizeAllParagraphs() {
  const paragraphs = document.querySelectorAll('p');
  for (let i = 0; i < paragraphs.length; i++) {
    // READ: gets the width of the container (forces layout)
    const containerWidth = document.body.offsetWidth;
    
    // WRITE: sets the paragraph's width (invalidates layout)
    paragraphs[i].style.width = (containerWidth / 2) + 'px';
  }
}

            

              
                Copy
              
            
          

Šajā kodā katrā cikla iterācijā mēs lasām offsetWidth (izkārtojumu izraisoša lasīšana) un pēc tam nekavējoties rakstām style.width (izkārtojumu padaroša par nederīgu rakstīšana). Tas piespiež pārmaketēšanu katram atsevišķam paragrāfam.

Optimizētā versija (Lasīšanas un rakstīšanas grupēšana):

            
function resizeAllParagraphsOptimized() {
  const paragraphs = document.querySelectorAll('p');
  
  // First, READ all the values you need
  const containerWidth = document.body.offsetWidth;
  
  // Then, WRITE all the changes
  for (let i = 0; i < paragraphs.length; i++) {
    paragraphs[i].style.width = (containerWidth / 2) + 'px';
  }
}

            

              
                Copy
              
            
          

Vienkārši pārstrukturējot kodu, lai vispirms veiktu visas lasīšanas un pēc tam visas rakstīšanas, mēs ļaujam pārlūkprogrammai grupēt operācijas. Tā veic vienu Izkārtojuma aprēķinu, lai iegūtu sākotnējo platumu, un pēc tam apstrādā visus stila atjauninājumus, kas noved pie vienas pārmaketēšanas kadra beigās. Veiktspējas atšķirība var būt dramatiska.

Galvenā pavediena blokāde: ilgi darbojošies JavaScript uzdevumi

Pārlūkprogrammas galvenais pavediens ir aizņemta vieta. Tas ir atbildīgs par JavaScript izpildes apstrādi, reaģēšanu uz lietotāja ievadi (klikšķi, ritināšana) un renderēšanas konveijera darbināšanu. Tā kā JavaScript ir vienpavediena, ja jūs palaižat sarežģītu, ilgi darbojošos skriptu, jūs efektīvi bloķējat galveno pavedienu. Kamēr jūsu skripts darbojas, pārlūkprogramma nevar darīt neko citu. Tā nevar reaģēt uz klikšķiem, nevar apstrādāt ritināšanu un nevar palaist nekādas animācijas. Lapa kļūst pilnīgi sastingusi un nereaģējoša.

Jebkurš uzdevums, kas ilgst vairāk nekā 50 ms, tiek uzskatīts par 'ilgu uzdevumu' un var negatīvi ietekmēt lietotāja pieredzi, īpaši Core Web Vital rādītāju Mijiedarbība līdz nākamajai zīmēšanai (INP). Biežākie vaininieki ir sarežģīta datu apstrāde, lielu API atbilžu apstrāde vai intensīvi aprēķini.

Risinājums ir sadalīt garus uzdevumus mazākos gabalos un starp tiem 'atdot' vadību galvenajam pavedienam. Tas dod pārlūkprogrammai iespēju apstrādāt citus gaidošos darbus. Vienkāršs veids, kā to izdarīt, ir ar setTimeout(callback, 0), kas ieplāno atzvanīšanas funkcijas izpildi nākamajā uzdevumā, pēc tam, kad pārlūkprogrammai ir bijusi iespēja 'ieelpot'.

Nāve no tūkstoš griezieniem: pārmērīgas DOM manipulācijas

Lai gan viena DOM manipulācija ir ātra, tūkstošiem šādu manipulāciju veikšana var būt ļoti lēna. Katru reizi, kad jūs pievienojat, noņemat vai modificējat elementu dzīvajā DOM, jūs riskējat izraisīt pārmaketēšanu un pārkrāsošanu. Ja jums ir jāģenerē liels saraksts ar vienumiem un jāpievieno tie lapai pa vienam, jūs radāt daudz nevajadzīga darba pārlūkprogrammai.

Daudz veiktspējīgāka pieeja ir veidot savu DOM struktūru 'bezsaistē' un pēc tam pievienot to dzīvajam DOM vienā operācijā. DocumentFragment ir viegls, minimāls DOM objekts bez vecākelementa. Jūs varat to uzskatīt par pagaidu konteineru. Jūs varat pievienot visus savus jaunos elementus fragmentam un pēc tam pievienot visu fragmentu DOM vienā piegājienā. Tas rezultējas tikai vienā pārmaketēšanā/pārkrāsošanā neatkarīgi no tā, cik daudz elementu jūs pievienojāt.

Piemērs DocumentFragment izmantošanai:

            
const list = document.getElementById('my-list');
const data = ['Apple', 'Banana', 'Cherry', 'Date', 'Elderberry'];

// Create a DocumentFragment
const fragment = document.createDocumentFragment();

data.forEach(itemText => {
  const li = document.createElement('li');
  li.textContent = itemText;
  // Append to the fragment, not the live DOM
  fragment.appendChild(li);
});

// Append the entire fragment in one operation
list.appendChild(fragment);

            

              
                Copy
              
            
          

Raustītas kustības: neefektīvas JavaScript animācijas

Animāciju veidošana ar JavaScript ir izplatīta, bet, darot to neefektīvi, rodas raustīšanās un 'jank'. Izplatīts antipaterns ir setTimeout vai setInterval izmantošana, lai atjauninātu elementu stilus ciklā.

Problēma ir tā, ka šie taimeri nav sinhronizēti ar pārlūkprogrammas renderēšanas ciklu. Jūsu skripts varētu palaisties un atjaunināt stilu tieši pēc tam, kad pārlūkprogramma ir pabeigusi zīmēt kadru, piespiežot to veikt papildu darbu un potenciāli nokavējot nākamā kadra termiņu, kas noved pie nomesta kadra.

Mūsdienīgs, pareizs veids, kā veikt JavaScript animācijas, ir ar requestAnimationFrame(callback). Šis API paziņo pārlūkprogrammai, ka vēlaties veikt animāciju, un pieprasa, lai pārlūkprogramma ieplāno loga pārkrāsošanu nākamajam animācijas kadram. Jūsu atzvanīšanas funkcija tiks izpildīta tieši pirms pārlūkprogramma veiks nākamo zīmēšanu, nodrošinot, ka jūsu atjauninājumi ir perfekti laikoti un efektīvi. Pārlūkprogramma var arī optimizēt, neizpildot atzvanīšanas funkciju, ja lapa atrodas fona cilnē.

Turklāt, ko jūs animējat, ir tikpat svarīgi kā kā jūs to animējat. Mainot īpašības, piemēram, width, height, top vai left, tiks iedarbināts Izkārtojuma posms, kas ir lēns. Lai iegūtu visgludākās animācijas, jums vajadzētu pieturēties pie īpašībām, kuras var apstrādāt tikai Kompozitors, kas parasti darbojas uz GPU. Tās galvenokārt ir:

• transform (pārvietošanai, mērogošanai, rotēšanai)
• opacity (parādīšanai/pazušanai)

Šo īpašību animēšana ļauj pārlūkprogrammai vienkārši pārvietot vai izmainīt elementa esošā uzzīmētā slāņa caurspīdīgumu, neveicot atkārtotu Izkārtojumu vai Zīmēšanu. Tas ir atslēga uz konsekventu 60fps animāciju sasniegšanu.

No teorijas uz praksi: veiktspējas optimizācijas rīkkopa

Teorijas izpratne ir pirmais solis. Tagad apskatīsim dažas praktiskas stratēģijas un rīkus, ko varat izmantot, lai šīs zināšanas ieviestu praksē.

Skriptu gudra ielāde

Tas, kā jūs ielādējat savu JavaScript, ir pirmā aizsardzības līnija. Vienmēr jautājiet, vai skripts ir patiešām kritisks sākotnējai renderēšanai. Ja nē, izmantojiet defer skriptiem, kuriem nepieciešams DOM, vai async neatkarīgiem skriptiem. Mūsdienu lietojumprogrammās izmantojiet tādas tehnikas kā koda sadalīšana (code-splitting), izmantojot dinamisku import(), lai ielādētu tikai to JavaScript, kas nepieciešams pašreizējam skatam vai lietotāja mijiedarbībai. Rīki, piemēram, Webpack vai Rollup, piedāvā arī koka kratīšanu (tree-shaking), lai no gala pakotnēm izņemtu neizmantoto kodu, samazinot failu izmērus.

Augstas frekvences notikumu savaldīšana: Debouncing un Throttling

Daži pārlūkprogrammas notikumi, piemēram, scroll, resize un mousemove, var tikt izsaukti simtiem reižu sekundē. Ja jums ir piesaistīts dārgs notikumu apstrādātājs (piemēram, tāds, kas veic DOM manipulācijas), jūs varat viegli aizsprostot galveno pavedienu. Šeit ir būtiski divi paterni:

• Throttling (Droselēšana): Nodrošina, ka jūsu funkcija tiek izpildīta ne biežāk kā reizi noteiktā laika periodā. Piemēram, 'palaist šo funkciju ne biežāk kā reizi 200ms'. Tas ir noderīgi tādām lietām kā bezgalīgās ritināšanas apstrādātāji.
• Debouncing (Atsitienu slāpēšana): Nodrošina, ka jūsu funkcija tiek izpildīta tikai pēc neaktivitātes perioda. Piemēram, 'palaist šo meklēšanas funkciju tikai pēc tam, kad lietotājs ir pārtraucis rakstīt 300ms'. Tas ir ideāli piemērots automātiskās pabeigšanas meklēšanas joslām.

Slogojuma noņemšana: Ievads Web Workers

Patiesi smagiem, ilgi darbojošiem JavaScript aprēķiniem, kuriem nav nepieciešama tieša DOM piekļuve, Web Workers ir revolucionārs risinājums. Web Worker ļauj palaist skriptu atsevišķā fona pavedienā. Tas pilnībā atbrīvo galveno pavedienu, lai tas paliktu atsaucīgs lietotājam. Jūs varat nodot ziņojumus starp galveno pavedienu un darbinieka pavedienu, lai nosūtītu datus un saņemtu rezultātus. Lietošanas gadījumi ietver attēlu apstrādi, sarežģītu datu analīzi vai fona ielādi un kešošanu.

Kļūstot par veiktspējas detektīvu: pārlūka izstrādātāja rīku (DevTools) izmantošana

Jūs nevarat optimizēt to, ko nevarat izmērīt. Veiktspējas panelis (Performance panel) mūsdienu pārlūkprogrammās, piemēram, Chrome, Edge un Firefox, ir jūsu spēcīgākais rīks. Šeit ir īss ceļvedis:

1. Atveriet Izstrādātāja rīkus (DevTools) un dodieties uz cilni 'Performance'.
2. Noklikšķiniet uz ierakstīšanas pogas un veiciet darbību savā vietnē, par kuru jums ir aizdomas, ka tā ir lēna (piemēram, ritināšana, pogas nospiešana).
3. Pārtrauciet ierakstīšanu.

Jums tiks parādīta detalizēta liesmu diagramma (flame chart). Meklējiet:

• Ilgi uzdevumi (Long Tasks): Tie ir atzīmēti ar sarkanu trīsstūri. Tie ir jūsu galvenā pavediena bloķētāji. Noklikšķiniet uz tiem, lai redzētu, kura funkcija izraisīja aizkavi.
• Violeti 'Layout' bloki: Liels violets bloks norāda uz ievērojamu laiku, kas pavadīts Izkārtojuma posmā.
• Piespiedu sinhronā izkārtojuma brīdinājumi: Rīks bieži vien skaidri brīdinās jūs par piespiedu pārmaketēšanu, parādot precīzas koda rindas, kas par to ir atbildīgas.
• Lieli zaļi 'Paint' bloki: Tie var norādīt uz sarežģītām zīmēšanas operācijām, kuras, iespējams, var optimizēt.

Turklāt cilnē 'Rendering' (bieži vien paslēpta DevTools atvilktnē) ir opcijas, piemēram, 'Paint Flashing', kas iekrāsos ekrāna apgabalus zaļā krāsā ikreiz, kad tie tiek pārkrāsoti. Tas ir lielisks veids, kā vizuāli atkļūdot nevajadzīgas pārkrāsošanas.

Noslēgums: ātrāka tīmekļa veidošana, pa kadram vien

Pārlūka renderēšanas konveijers ir sarežģīts, bet loģisks process. Kā izstrādātāju, mūsu JavaScript kods ir pastāvīgs viesis šajā konveijerā, un tā uzvedība nosaka, vai tas palīdz radīt gludu pieredzi vai izraisa traucējošus sastrēgumus. Izprotot katru posmu — no parsēšanas līdz kompozīcijai — mēs iegūstam ieskatu, kas nepieciešams, lai rakstītu kodu, kas strādā ar pārlūkprogrammu, nevis pret to.

Galvenie secinājumi ir apziņas un rīcības apvienojums:

• Cieniet galveno pavedienu: Uzturiet to brīvu, atliekot nekritiskus skriptus, sadalot garus uzdevumus un nododot smagu darbu Web Workers.
• Izvairieties no izkārtojuma pārslogošanas: Strukturējiet savu kodu, lai grupētu DOM lasīšanas un rakstīšanas. Šī vienkāršā izmaiņa var sniegt milzīgus veiktspējas uzlabojumus.
• Esiet gudri ar DOM: Izmantojiet tādas tehnikas kā DocumentFragments, lai samazinātu reižu skaitu, kad jūs aiztiekat dzīvo DOM.
• Animējiet efektīvi: Dodiet priekšroku requestAnimationFrame pār vecākām taimera metodēm un pieturieties pie kompozitoram draudzīgām īpašībām, piemēram, transform un opacity.
• Vienmēr mēriet: Izmantojiet pārlūkprogrammas izstrādātāja rīkus, lai profilētu savu lietojumprogrammu, identificētu reālās pasaules vājās vietas un apstiprinātu savas optimizācijas.

Augstas veiktspējas tīmekļa lietojumprogrammu veidošana nav saistīta ar priekšlaicīgu optimizāciju vai neskaidru triku iegaumēšanu. Tas ir par fundamentālu izpratni par platformu, kurai jūs veidojat. Apgūstot mijiedarbību starp JavaScript un renderēšanas konveijeru, jūs dodat sev spēku radīt ātrākas, noturīgākas un galu galā baudāmākas tīmekļa pieredzes ikvienam un visur.