Webbläsaren målning och överväganden för web performance

0
41

Processen för en webbläsare att vrida HTML -, CSS-och JavaScript-kod i en klar visuell representation är ganska komplex och innebär en bra bit av magi. Här är en förenklad uppsättning steg webbläsaren går igenom:

  1. Webbläsaren skapar DOM och CSSOM.
  2. Webbläsaren skapar göra träd, där DOM och stilar från CSSOM beaktas (display: none element är undvikas).
  3. Webbläsaren beräknar geometri layout och element baserat på render träd.
  4. Webbläsaren färger pixel för pixel för att skapa den bild vi ser på skärmen.

I denna artikel skulle jag vilja fokusera på den sista delen: målning.

Alla dessa åtgärder i kombination är en hel del arbete för en webbläsare att göra på ladda… och faktiskt, inte bara på last, men varje gång DOM (eller CSSOM) ändras. Det är därför många webbutvecklare tenderar att delvis lösa detta genom att använda någon form av skal ram, som Reagerar som, förutom många andra fördelar, som kan hjälpa till mycket optimera förändringar i DOM för att undvika onödiga räkna eller rendering.

Du kanske har hört termer som staten, komponent rendering, eller oföränderlighet. Alla av dem har något att göra med optimering av DOM förändringar, eller med andra ord, att endast göra ändringar till DOM när det är nödvändigt.

För att ge ett exempel, staten en webbapplikation kan förändras, och att det skulle leda till en förändring i UI. Men vissa (eller många) komponenter påverkas inte av denna förändring. Vad Reagerar hjälper till att göra är att begränsa skriva till DOM för element som faktiskt påverkas av en förändring i staten och i slutändan begränsar rendering till den minsta delen av webbapplikationen möjligt:

DOM/CSSOM → rita träd → layout → målning

Dock webbläsaren målning är speciell på sitt eget sätt, så det kan hända även utan några ändringar till DOM och/eller CSSOM.

Exempel på sida prestanda sammanfattning

Ovanstående diagram genererades med hjälp av Chromes resultat panel i DevTools (mer om det senare) och det visar hur mycket tid som togs av varje uppgift i webbläsaren i den inspelade tiden (0-7.12 s) efter att ladda en sida. Som du kan se, målning tar en betydande del, och det är inte automatiskt en dålig sak. I detta exempel, den ökade målning är orsakat av en kombination av animerade Gif-bilder på sidan och duk ritning (på 60fps), där både föranleder inte några ändringar till den DOM eller dess format, samtidigt som utlöser målning.

Ett annat bra exempel på en funktion som kan orsaka målning utan någon inblandning utifrån är CSS-animation egendom, och jämfört med animerade GIF-eller canvas, det är nog mer vanligt på webben. En animation är vanligtvis utlöst av indata från användaren, som hovring, men tack vare animation och @keyframes regler, vi kan även skapa ganska avancerade animeringar kör ständigt på sidan utan mycket av en insats, vilket är ganska fantastiskt.

Vad en del kanske inte inser, är att de animationer kan lätt få ut av hand och ständigt utlösa målning, och det kan kosta oss en hel del processorkraft. Naturligtvis finns det en del regler som kan användas för att undvika att måla. Mest uppenbara är att begränsa manipulation av delar till CSS förändra och opacitet egenskaper, som normalt inte leder till att måla, om inte några särskilda omständigheter, såsom att animera ett SVG väg.

Färg blinkande

Du vet förmodligen att Chrome har DevTools. Vad du kanske inte vet om är en liten genväg (Shift+Cmd+P på Mac eller Kontroll+Shift+P för PC) som kan användas inuti DevTools för att få upp en liten sökning bar och kommando-menyn.

Kommando-Menyn

Jag har börjat gräva runt det och bortsett från många andra bra och otroligt intressant alternativ, göra panel som fångade min uppmärksamhet.

Gör Panel

Vid första anblicken, kan du se några intressanta alternativ som kan vara mycket till hjälp när det kommer till felsökning animation på webben, som ett FPS-mätaren.

FPS-mätaren

Lager gränser och måla blottande är också intressant verktyg. Lager gränser används för att visa gränser lager som tolkas av webbläsaren så att någon omvandling eller förändring i storlek är den lätt att känna igen. Färg blinkande tjänar till att belysa delar av den webbsida där webbläsaren är tvungen att måla om.

Färg blinkande

Efter att ha upptäckt färg blinkande, det första jag gjorde var att kolla ut det på ett projekt till mig. På de flesta ställen, det var inga problem. Till exempel, en rörelse som utlöses genom att bläddra på webbplatsen drivs av CSS förvandla egendom, som vi omfattas, inte orsaka målning. Målningen var närvarande där man skulle förvänta sig att det ska vara, som förändringar i sms: a färg på muspekaren, men det är inte något som ska vara mycket av en oro på grund av dess område och närvaro endast på hover av elementet. För att sammanfatta det, kan du alltid hitta något att förbättra, även om du skrev koden i går…

Men en sak var ett slag i ansiktet.

Det spelar ingen roll hur erfaren eller försiktig du är, du kan — och kommer sannolikt att — göra ett misstag. Vi är bara människor och en del skulle hävda att fastställa din egna fel är det mesta av jobbet när det gäller utveckling. Men, för att ett fel skall repareras, vi måste vara medvetna om det… och det är precis där det gör panelen hjälper till.

Fallstudie

Låt oss ta en närmare titt på den aktuella frågan. Konstruktionen kom in med begäran om en bullrig bakgrund. Denna typ av effekt som gamla Tv hade när det var ingen signal.

Det är känt att Gif har många frågor, där prestanda är definitivt en av dem, så har jag definitivt inte kunde använda den till en hel sida bakgrunden. Om du vill läsa lite mer om varför man ska undvika Gif-bilder, här är en bra resurs med en massa skäl.

Med hjälp av JavaScript är definitivt ett alternativ i detta fall. Visa eller dölja delar med en något rörd bakgrunden var den första som kom till mitt sinne, och med hjälp av canvas kan hjälpa också. Men allt detta verkade lite för mycket för att bara ha en bakgrund. Jag bestämde mig för att gå till en CSS-enda sättet.

Min lösning var att ta en liten “bullriga” PNG-bild som bakgrund-bild, aktivera background-repeat och kasta den över en enfärgad bakgrund. Hur kunde jag uppnå buller effekt? Med oändlig CSS-animation! Genom att sätta background-position till olika värde över tiden för 200 millisekunder. Här är hur det gick:

Se Pennan MXoddr av Georgy Marchuk (@gmrchk) på CodePen.

Kan du gissa problemet? Det verkade som en ganska elegant lösning för mig, och jag var jätteglad över min prestation för att göra det igenom utan en skit GIF och inte ens en enda rad JavaScript. Bara enkla CSS som är optimerad i webbläsare i dessa dagar.

Jo, färg blinkande visade något helt annat. Lagret av storleken på fönstret var ständigt ommålning, utan att användaren ens göra något. Du kan se färgen som blinkar i demo ovan om du aktiverar det i render-panel (observera att måla blinkar inte dyker upp i inbyggda penna).

Utan färg blinkande (vänster) jämfört med färg blinkande (höger)

Som verkligen inte spelar bra med resultatet av webbplatsen och avlopp laptop batterier som det inte finns någon morgondag.

CPU-användning för animation gjort med background-position (överst) och förändra (botten)

Allt detta CPU-användning skulle ha kunnat undvikas genom att ersätta de ändringar background-position med hjälp förändra eller opacitet.

Se Pennan XYOYGm av Georgy Marchuk (@gmrchk) på CodePen.

Problemet

Jag har hållit på med webbutveckling för ett tag och jag visste mycket väl att animera en bakgrund är aldrig en bra idé. Det kändes som en rookie-misstag. Människor gör misstag… men det är inte hela historien. Webbplatsen var allt laggar och obehagligt att navigera. Hur kunde jag missa det?

Något som verkligen spelar en stor roll är det faktum att jag (och kanske du också) lite bortskämd när det kommer till utveckling av utrustning. Jag har en fin, kraftfull dator för arbete och tillgång till snabb internet. Om vi inte skriva några riktigt skit-kod, något vi skriver går ganska smidigt i våra ögon. Men det är inte alltid fallet för våra användare.

Ett liknande problem gäller många andra saker — som att visa storleken. Med hjälp av en liten överdrift, samtidigt som vi utvecklar på 27″ skärm med 4K-upplösning och få den design främst för 1920×1080, våra besökare kommer i huvudsak från 1366×768 bärbara datorer och har en helt annan arbetsflödet när det gäller att använda en dator.

Slutsats

Medan denna artikel började som en pjäs om målning, och dess huvudsakliga ämne är egentligen mycket mer om att vara medveten om den inverkan som vår kod har på målning process eller resultat i allmänhet. Medan målning fungerar som ett bra exempel på något som kan vara problematiskt och lätt att missa, det är mer av en frånkoppling mellan utvecklare och användare som är problemet.

Webben är en plats för många miljöer, där utvecklaren miljön är ofta helt annorlunda än användaren. Medan det finns ingen anledning att ändra vårt sätt eller byta till lata datorer, det hjälper definitivt att se vårt arbete på det sätt som det ses av andra från tid till tid. Mitt förslag är: när du kommer hem från jobbet och har lite ledig tid, försök att plocka upp din gamla dator och kontrollera ditt arbete, för att komma lite närmare på vad dina användare upplever.

Om du inte har denna typ av dator runt, verktyg som gör panelen kan visa sig vara väldigt praktiskt.