Nettleseren maleri og hensyn for web ytelse

0
12

Prosessen med en nettleser for å slå HTML, CSS og JavaScript til et ferdig visuell representasjon er ganske komplisert og innebærer en god bit av magi. Her er en forenklet fremgangsmåte nettleseren går gjennom:

  1. Leseren skaper DOM og CSSOM.
  2. Nettleseren oppretter gjengi tre, hvor DOM og stiler fra CSSOM er tatt hensyn til (display: none elementer unngås).
  3. Nettleseren regner geometri og utforming og dens elementer basert på gjengi treet.
  4. Nettleseren maling piksel for piksel for å lage den visuelle representasjonen vi ser på skjermen.

I denne artikkelen ønsker jeg å fokusere på den siste delen: maleri.

Alle disse trinnene kombinert er mye arbeid for en leser å gjøre på legg til… og faktisk, ikke bare på belastning, men helst DOM (eller CSSOM) er endret. Det er derfor mange web-utviklere som har en tendens til å delvis løse dette ved hjelp av noen form for frontend-rammeverket, for eksempel Reagerer som, bortsett fra mange andre fordeler, kan bidra til svært optimalisere endringer i DOM for å unngå unødvendig å beregne eller gjengivelse.

Du har kanskje hørt begreper som stat, komponent-gjengivelse, eller immutability. Alle av dem har noe å gjøre med optimalisering av DOM endringer, eller med andre ord, bare for å gjøre endringer til DOM når det er nødvendig.

For å gi et eksempel, staten av en web-applikasjon kan endre seg, og som ville føre til en endring i BRUKERGRENSESNITTET. Men enkelte (eller mange) komponenter er ikke påvirket av denne endringen. Hva Reagerer bidrar til å gjøre er å begrense skriftlig til DOM for elementer som faktisk er berørt av en endring i tilstand og til slutt begrense rendering til den minste delen av web-applikasjon mulig:

DOM/CSSOM → teikningar treet → layout → maleri

Imidlertid, nettleser maleriet er spesiell på sin egen måte, så kan det skje selv uten noen endringer til DOM og/eller CSSOM.

Eksempel på side resultatsammendrag

Diagrammet ovenfor ble generert ved hjelp av Chrome-ytelse-panelet i DevTools (mer om det senere), og det viser hvor mye tid som ble tatt av hver oppgave i nettleseren i den registrerte tiden (0-7.12 s) etter omlasting av en side. Som du kan se, maleri tar en betydelig del, og det er ikke automatisk en dårlig ting. I dette eksempelet, økt maleriet er forårsaket av en kombinasjon av animerte Gif-filer på siden og lerret tegning (på 60fps), hvor både ikke føre til noen endringer i den DOM eller stiler, mens de fortsatt utløser maleri.

Et annet godt eksempel på en funksjon som kan forårsake maleri uten noen utenfor intervensjon er CSS animasjon eiendom, og i forhold til animerte GIF-eller lerret, det er nok mer vanlig på internett. En animasjon er vanligvis utløst av brukerinndata, som holder, men takket være animasjon og @keyframes reglene, kan vi selv skape ganske komplekse animasjoner kjører hele tiden på siden uten mye innsats, noe som er ganske utrolig.

Hva noen kanskje ikke vet, er at de animasjoner kan lett komme ut av hånden og stadig utløse maleri, og det kan koste oss for mye prosessorkraft. Selvfølgelig, det er noen regler som kan brukes for å unngå å male. Det mest åpenbare er å begrense manipulering av elementer til CSS-transform og dekkevne egenskaper, som standard ikke utløse maling, med mindre noen spesielle omstendigheter er på plass, slik som å animere en SVG-banen.

Maling blinkende

Du sannsynligvis vet at Chrome har DevTools. Hva du kanskje ikke vet om er en liten snarvei (Shift+Cmd+S på Mac eller ctrl+Shift+P på PC-en) som kan brukes inne DevTools for å få opp et lite søk bar og kommando-menyen.

Kommando-Menyen

Jeg har begynt å grave rundt det, og bortsett fra mange andre nyttige og utrolig spennende valg, en render panelet fanget min oppmerksomhet.

Gjengi Panel

Ved første øyekast, kan du se noen interessante alternativer som kan være svært nyttig når det gjelder å debugging animasjon på nettet, som et FPS-måleren.

FPS meter

Lag grenser og maling blinkende er også interessant verktøy. Lag grenser er brukt for å vise grenser lag slik de er gjengitt av nettleseren, slik at noen omdanning eller endring i størrelse er lett gjenkjennelig. Maling blinkende tjener til å markere områder av nettsiden der leseren blir tvunget til å male.

Maling blinkende

Etter å oppdage maling blinker, det første jeg gjorde var å sjekke det ut på et prosjekt av meg. I de fleste steder, det var ingen problemer. For eksempel, enhver bevegelse utløst av bla på nettstedet ble drevet av CSS forvandle eiendommen, som vi dekket, kan ikke føre til maleriet. Maleriet var til stede der hvor man forventer at det skal være, for eksempel endringer i tekst farge på hold, men det er ikke noe som bør være mye av et problem på grunn av sitt område, og tilstedeværelse bare på hold av elementet. For å oppsummere det, kan du alltid finne noe å forbedre, selv om du har skrevet inn koden i går…

Men en ting var et slag i ansiktet.

Det spiller ingen rolle hvor erfaren eller forsiktig du er, du kan, og mest sannsynlig vil — gjøre en feil. Vi er bare mennesker, og noen vil hevde at å fikse din egen feil er det meste av jobben når det kommer til utvikling. Men for at en feil skal rettes opp, må vi være klar over det… og det er akkurat der gjengi panelet hjelper.

Case-studie

La oss ta en nærmere titt på det faktiske problemet. Design kom med anmodningen om en bråkete bakgrunn. Den slags effekt det gamle Tv-er hadde da var det ingen signal.

Det er kjent at Gif-filer har mange spørsmål, der ytelse er absolutt en av dem, så jeg definitivt ikke kunne bruke den som en hel side bakgrunnen. Hvis du ønsker å lese litt mer om hvorfor du bør unngå Gif, her er en god ressurs med en haug av årsaker.

Ved hjelp av JavaScript er definitivt et alternativ i denne saken. Vise eller skjule elementer med en litt flyttet bakgrunnen var den første som kom til mitt sinn, og ved hjelp av lerret kan også hjelpe. Men alt dette virket litt overkill for bare å ha en bakgrunn. Jeg bestemte meg for å gå for en CSS-kun tilnærming.

Min løsning var å ta en liten “støyende” PNG-bilde som bakgrunnsbilde, kan du aktivere background-repeat (gjenta) og kaste det over en ett-farget bakgrunn. Hvordan gjorde jeg oppnå støy effekt? Med uendelig CSS-animasjon! Ved å sette bakgrunnen-posisjon til en annen verdi over en periode på 200 millisekunder. Her er hvordan det slått ut:

Se Penn MXoddr av Georgy Martsjuk (@gmrchk) på CodePen.

Kan du gjette problemet? Det virket som en ganske en elegant løsning for meg, og jeg var spent på om min prestasjon av å gjøre det gjennom uten en crappy GIF og selv ikke en eneste linje med JavaScript. Bare enkle CSS som er optimalisert i nettlesere i disse dager.

Vel, maling blinkende viste noe helt annet. Laget av størrelsen på vinduet ble stadig male, uten at brukeren selv trenger å gjøre noe. Du kan se maling blinker i demo ovenfor hvis du aktiverer det i gjengi panel (legg merke til at maling blinkende ikke dukker opp i innebygd penn).

Uten maling blinker (venstre) vs. med maling blinker (høyre)

Som absolutt ikke å spille godt med resultatene til nettstedet og avløp laptop-batterier som det er ingen morgen.

CPU-bruken for animasjon gjort med bakgrunn-posisjon (øverst) og transform (nederst)

Alt dette CPU-bruk kunne ha vært unngått ved å erstatte endringer i bakgrunnen-posisjon ved hjelp av omdanne eller dekkevne.

Se Penn XYOYGm av Georgy Martsjuk (@gmrchk) på CodePen.

Problemet

Jeg har holdt på med web-utvikling en stund, og jeg visste godt at animert bakgrunn er aldri en god idé. Dette føltes som en rookie feil. Folk gjør feil… men det er ikke hele historien. Nettstedet var alle laggy og ubehagelig å navigere. Hvordan gjorde jeg gå glipp av det?

Noe som sikkert spiller en stor rolle er at jeg (og du kan være så godt) litt bortskjemt når det kommer til utvikling av utstyr. Jeg har en fin, kraftig datamaskin for arbeid og tilgang til rask internett. Med mindre vi skrive noen virkelig crappy kode, noe vi skriver går ganske greit i våre øyne. Men det er ikke alltid tilfelle for våre brukere.

Et lignende problem gjelder mange andre ting — som å vise størrelsen. Ved hjelp av en liten overdrivelse, mens vi utvikler på 27″ skjerm med 4K-oppløsning og få design først og fremst for 1920×1080, våre besøkende kommer i hovedsak fra 1366 x 768 bærbare datamaskiner og har en helt annen arbeidsflyt når det gjelder å bruke en datamaskin.

Konklusjon

Mens denne artikkelen startet som et stykke om å male, sin viktigste tema er egentlig mye mer om å være oppmerksom på virkningen vår kode er på maleriet prosessen eller ytelse generelt. Mens maleri tjener som et godt eksempel på noe som kan være problematisk og lett savnet, det er mer en frakobling mellom utvikler og bruker som er problemet.

Nettet er et sted for mange miljøer, der utvikleren miljøet er ofte langt annerledes enn de bruker. Mens det er ingen grunn til å endre våre måter, eller bytt til late datamaskiner, er det definitivt bidrar til å se arbeidet vårt slik det er sett av andre fra tid til annen. Mitt forslag er: når du kommer hjem fra jobb og har litt ledig tid, prøv å plukke opp din gamle datamaskin og sjekke arbeidet der, for å få en litt nærmere hva brukerne dine erfaringer.

Hvis du ikke har denne type datamaskin rundt, verktøy som gjengi panelet kan vise seg å være veldig praktisk.