Interaction to Next Paint - esitysviive

Esitysviiveestä johtuvat Interaction to Next Paint (INP) -ongelmat

Aiemmassa artikkelisarjassamme käsittelimme Interaction to Next Paint -mittaria ja sitä, miten Interaction to Next Paint -ongelmat tunnistetaan. Jos haluat kerrata perusasiat, tämä on loistava paikka aloittaa!

Tässä artikkelissa keskityn esitysviiveeseen (presentation delay). Miten se vaikuttaa Interaction to Next Paint -mittariin ja kuinka esitysviivettä voidaan optimoida Interaction to Next Paint -tuloksen parantamiseksi!

Lyhyesti: Interaction to Next Paint (INP) mittaa, kuinka kauan kestää, ennen kuin käyttäjä näkee visuaalisen muutoksen sivulla vuorovaikutuksen jälkeen. Tämä INP voidaan jakaa kolmeen osaan: 'input delay', 'processing time' ja 'presentation delay'. Esitysviive on suurin yksittäinen tekijä kokonais-INP:ssä, muodostaen keskimäärin noin 42 % input delay -ajasta.  Tämä tarkoittaa, että esityksen optimointi ja HTML:n yksinkertaistaminen voivat merkittävästi vaikuttaa verkkosivustosi INP-tulokseen.

Presentation Delay: Oletko koskaan napsauttanut painiketta ja ihmetellyt, miksi tuloksen näkeminen kesti sekunnin murto-osan liian kauan? Siinä on Interaction to Next Paint (INP) toiminnassa. Esitysviive on vuorovaikutusprosessin viimeinen vaihe — se alkaa sen jälkeen, kun napsautuksesi on käsitelty, mutta ennen kuin näet visuaalisia muutoksia. 

Esitysviiveen ymmärtäminen

Esitys on vuorovaikutuksen viimeinen vaihe, ja esitysviive edustaa aikaa, joka selaimelta kuluu vuorovaikutusta seuraavien visuaalisten päivitysten renderöintiin. Esitysviive alkaa, kun vuorovaikutuksen tapahtumankäsittelijät ovat suoritettu loppuun, ja päättyy, kun seuraava kehys (joka sisältää visuaaliset muutokset) on piirretty. Esitysviiveeseen voivat vaikuttaa useat tekijät, kuten asettelun monimutkaisuus, DOM:n koko ja tarvittavan renderöintityön määrä.

Interaction to Next Paint (INP) voidaan jakaa kolmeen osaan: 'Input Delay', 'Processing Time' ja 'Presentation Delay'

Esitysviive ja INP

Esitys on INP:n viimeinen vaihe. Keskimäärin esitysviive muodostaa noin 42 % kokonais-INP-ajasta.

CoreDashissa keräämme miljoonia Core Web Vitals -datapisteitä tunnissa. Tämän datan perusteella esitysviive muodostaa 42 % Interaction to Next Paint -ajasta. 

Esitysviive: Kuvittele, että selaat puhelimellasi verkkokauppaa etsien uusia kenkiä. Napautat tuotekuvaa nähdäksesi lisätietoja. Puhelimesi on kuitenkin hieman vanhempi eikä pysy mukana. Tässä tilanteessa saatat kokea huonon Interaction to Next Paint (INP) -arvon. Tässä on mitä tapahtuu: Napautat kuvaa (vuorovaikutus). Puhelin käyttää aikaa pyynnön käsittelyyn ja näytön päivittämiseen (Processing Time). Verkkosivuston täytyy hakea lisätiedot tuotteesta ja renderöidä uusi sivu suuremmalla kuvalla ja yksityiskohdilla (Tämä voi olla hitaampaa hitaan internetyhteyden tai monimutkaisen tuotesivun vuoksi). Lopulta uusien tuotetietojen ja kuvan ilmestyminen näytöllesi kestää huomattavan kauan (esitysviive). Tämä INP-viive voi olla turhauttavaa käyttäjille, ja siksi sen korjaaminen on tärkeää.

Esitysviiveen vähentäminen

Esitysviiveen minimointi on usein välttämätöntä Interaction to Next Paint (INP) -mittarin läpäisemiseksi ja sivun responsiivisuuden ylläpitämiseksi. Yksi tehokas strategia on Document Object Model (DOM) -rakenteen koon minimointi. Pienempi DOM johtaa yleensä nopeampiin renderöintiaikoihin, koska selaimella on vähemmän sisältöä käsiteltävänä ja päivitettävänä. Kehittäjien tulisi pyrkiä pitämään DOM pienenä ja yksinkertaisena käyttämällä tekniikoita kuten näkymän ulkopuolisen sisällön laiskalatausta content-visibility-ominaisuudella. Lisäksi on tärkeää huomioida vuorovaikutuksen aiheuttaman asettelutyön määrä. Liiallinen asettelutyö voi merkittävästi kasvattaa esitysviivettä, mikä johtaa vähemmän responsiiviseen user experience -kokemukseen.

Asiakaspuolen HTML-renderöinti voi myös vaikuttaa esitysviiveeseen, erityisesti Single Page Application (SPA) -sovelluksissa. Kun HTML:ää luodaan dynaamisesti asiakaspuolella JavaScript:llä, se voi aiheuttaa pitkiä tehtäviä, jotka blokkaavat pääsäiettä ja mahdollisesti viivästyttävät seuraavan kehyksen esitystä. Kehittäjien tulisi harkita huolellisesti asiakaspuolen renderöinnin suorituskykyvaikutuksia ja pyrkiä minimoimaan dynaamisesti luodun HTML:n määrää.

Pitkien esitysviiveiden tunnistaminen

Pitkien esitysviiveiden tunnistamiseen voit käyttää Chromen suorituskykyprofiilaajaa. Avaa devtools (Ctrl-shift-i), siirry Performance-välilehdelle, aloita tallennus ja vuorovaikuta sivun kanssa.

Voit nyt analysoida vuorovaikutuksen aikajanan ja visualisoida eri vaiheet, mukaan lukien esitysviiveen. Tutkimalla renderöintipäivityksiä, jotka tapahtuvat tapahtumankäsittelijöiden suorituksen jälkeen, voit paikantaa mahdolliset pullonkaulat, jotka aiheuttavat pitkän esitysviiveen. 

Esitysviiveen tunnistaminen RUM-datalla

Lisänäkemyksiä esitysviiveen syistä Long Animation Frames -rajapinnalla

Long Animation Frames (LoAF) API tarjoaa yksityiskohtaisia näkemyksiä renderöintiviiveiden syistä, mukaan lukien käyttäjän vuorovaikutusten aikana tapahtuvat viiveet. Tämä API tarjoaa ajoituksia ja muuta dataa, joka auttaa kehittäjiä paikantamaan hitaiden vuorovaikutusten syitä ja optimoimaan koodiaan. RUM-työkalut kuten CoreDash tarjoavat tuen LoAF:lle ja lisänäkemyksiä pitkistä animaatiokehyksistä, kuten skriptin attribuutiotietoja. Nämä työkalut auttavat kehittäjiä ymmärtämään, mitkä skriptit aiheuttavat renderöintiviiveitä, ja optimoimaan koodipohjaansa paremman responsiivisuuden saavuttamiseksi.