javascript - Angular 2 hvordan forbedre DOM-renderingstid på Internet Explorer 11

Finnes det noen spesielle triks for å forbedre ytelsen til Angular 2-appen på Internet Explorer 11?

Nettstedet vårt fungerer bra i både Chrome og Firefox, men DOM-en gjengis merkbart saktere på IE 11. Jeg forstår at noe av dette er en begrensning i nettlesermotoren, men når en enkelt endringsdeteksjonssyklus forårsaker 30-40 ms på DOM-maling i IE 11, føler jeg at det er noe annet som kan gjøres i implementeringen vår. For ordens skyld tar det aldri mer enn 1 ms for Chrome å male DOM-en, så IE oppfører seg omtrent 30 til 40 ganger tregere enn sin motpart.

Her er et IE11-øyeblikksbilde av ytelsesovervåking tatt på vår localhost-instans for DOM-hendelsen (scroll).

Sammenlign dette med nettsteder som The Guardian, som også bruker Angular 2. Nettstedets håndtering av DOM-hendelser er nesten alltid under 2 ms, og det de viser på DOM er mye mer komplekst enn vårt.

Dette får meg til å tenke at det finnes noen optimaliseringsteknikker som er spesielt egnet for IE 11. Her er en liste over ting vi har prøvd så langt:

1. Migrerte fra SystemJS til Webpack. Hjalp med initial lastetid, men ingen forskjell i DOM-renderingstid.
2. Vi bruker core-js i stedet for es6-shim
3. Bruke rene rør for formatering og unngå alle funksjonskall fra malen.

Enhver forslag ville vært velkomment.

Svar #1

Dessverre er det ikke bare én ting Angular gjør som forårsaker problemer med IE. Angular jobber tungt med manipulering av DOM-treet og sporing av barne-/foreldrenoder, og IEs DOM-tre er egentlig ikke et tre. Mange av ytelsesproblemene for Angular på IE og Edge kommer fra endringsdeteksjonssykluser - noe som gjorde Angular 1.X veldig kult, men også ga det rykte for å bli klønete når det vokste i størrelse.

Angular 2+ gjorde mye for å fikse dette, inkludert å gi utviklere mange alternativer for å endre denne deteksjonsstrategien for best å passe situasjonen.

Endringsdeteksjonsstrategi

Her er en flott ressurs for å utforske dette. Å endre ChangeDetectorRef-tjenestens deteksjonsstrategi til `ChangeDetectionStrategy.OnPush` vil få Angular til kun å kjøre endringsdeteksjon på komponentens inputs. Hvis du har mye statisk informasjon i dypt nestede komponenter uten hendelser som bobler opp fra de dypt nestede komponentene, kan dette gi en stor hastighetsforbedring - men du må manuelt justere endringsdeteksjonen når det trengs eller manuelt kalle på en endringsdeteksjon når det er nødvendig - ikke så ille som det høres ut, og det vil gi en ytelsesforbedring for alle plattformer.

Frakobling av endringsdetektoren

En enda større ytelsesøkning ville være å helt frakoble endringsdetektoren når brukere gjør ting som utløser mange unødvendige runder med endringsdeteksjon, som å klikke og dra. Dette kan brukes strategisk for å gi ganske store ytelsesforbedringer, men hvordan du implementerer det vil være ganske spesifikt for applikasjonen.

Kjør utenfor Angular

Dette vil sannsynligvis virke kjent, men hvis du har mange beregningsmessig tunge oppgaver som påvirker UI, kan du bruke NgZone for å kjøre logikk utenfor Angulars 'zone'. Det har sannsynligvis ikke mye effekt på IE spesielt, men det er god praksis uansett.

NgFor sporing

NgFor er betydelig mer ytelseseffektiv enn den gamle ng-repeat, men den er fortsatt ikke perfekt, spesielt når det kommer til repainting (host IE host). Dette kan ha stor innvirkning på ytelsen i IE spesielt, på grunn av hvordan DOM-treet ikke egentlig er et tre. Som standard river NgFor ned hele DOM-treet for repetisjonen og bygger det opp igjen for enhver liten endring som gjøres i dataene. Å gi NgFor en trackBy-funksjon gjør at den kun oppdaterer DOM der endringer er nødvendige, noe som forbedrer hastigheten (spesielt hvis du har komplekse/mange elementer som blir gjentatt).

AOT-kompilering

Mer en generell forbedring enn noe som er spesifikt for en plattform, men definitivt en god idé uansett. Å konfigurere appen din for forhåndskompilering (ahead-of-time) fjerner Angular-kompilatoren fra byggeapplikasjonen og gjengir malene fullstendig ved byggetidspunktet. Det kan redusere lastetid og rendringstid betydelig, og kan være enda mer effektivt hvis du har store, kompliserte maler som kan bygges med minimalt ekstern data. Det er tungvint å gjøre med Webpack eller SystemJS (i motsetning til CLI), men det er verdt det. Se de offisielle dokumentene her

Andre

Det er mulig at problemene dine ikke har noe med Angular å gjøre i det hele tatt - IE har ytelsesproblemer med ting som tabellgjengivelse og visse stilsettingssituasjoner (som å beregne dynamisk bredde for elementer etter at en side er gjengitt). Sørg for å undersøke eventuelle problemer med det appen din implementerer.

Lykke til!