Core/Dash Dimensio: LOAF

Dimensio: Long Animation Frames (lurl)

LOAF-dimensio tuo esiin niiden skriptien URL-osoitteet, jotka aiheuttivat Long Animation Frame -tapahtumat käyttäjiesi istuntojen aikana. Jokainen arvo on skriptin URL: oman koodisi paketti, kolmannen osapuolen analytiikkatagi, chat-widget, suostumusten hallinta tai mikä tahansa muu, joka suoritettiin tarpeeksi kauan estääkseen renderöinnin. Tämä on attribuutio lähdetasolla, ei pelkkä pinotulostus, joka sinun täytyy rekonstruoida DevToolsissa.

CoreDash kerää tämän datan käyttäen Long Animation Frames API:a (LoAF), jonka Chrome tarjoaa vanhemman Long Tasks API:n korvaajana. Siinä missä Long Tasks kertoi, että kehys kesti liian kauan, LoAF kertoo, mitkä skriptit suoritettiin kehyksen sisällä ja mitkä niiden URL-osoitteet olivat. Tämä ero tekee tästä dimensiosta hyödyllisen tuotannossa.

Miksi Long Tasks ei riittänyt

Long Tasks API (saatavilla vuodesta 2017) merkitsi jokaisen 50ms ylittävän pääsäikeen tehtävän, mutta antoi lähes nollaa attribuutiota. Näit, että esto tapahtui; et nähnyt, mikä sen aiheutti. Kehittäjät käyttivät tunteja korreloiden tehtävien aikaleimoja verkkovesiputouksiin yrittäen arvata, mikä skripti oli vastuussa.

LoAF API muuttaa tämän. Se raportoi PerformanceLongAnimationFrameEntry-objekteja, joista jokainen sisältää scripts-taulukon. Jokaisella taulukon merkinnällä on invokerType, sourceURL ja duration. CoreDash lukee sourceURL:n jokaiselle skriptille, joka suoritettiin pitkän kehyksen aikana, ja tallentaa sen LOAF-dimension arvoksi. Tuloksena on järjestetty lista skripti-URL:ista sen mukaan, kuinka usein ne esiintyvät käyttäjiesi pitkissä kehyksissä.

Miten CoreDash käyttää LoAF-dataa

Joka kerta kun käyttäjän vuorovaikutus käynnistää pitkän animaatiokehyksen, CoreDash tallentaa myötävaikuttavat skripti-URL:t INP-havainnon rinnalle. Tämä tarkoittaa, että voit suodattaa INP-datasi LOAF-URL:n mukaan ja nähdä, mikä skripti on vastuussa pahimmista vuorovaikutuksistasi. Dimensio ryhmittelee URL:n mukaan, joten näet laskennan siitä, kuinka monessa istunnossa kyseinen skripti aiheutti pitkän kehyksen.

Tyypillisiä merkintöjä, joita näet LOAF-dimensiossa:

• https://www.googletagmanager.com/gtm.js (Google Tag Manager -säilö)
• https://cdn.cookielaw.org/consent/... (OneTrust tai vastaava suostumusalusta)
• https://js.intercomcdn.com/... (chat-widget)
• /static/js/app.bundle.js (oma sovelluskoodisi)
• https://connect.facebook.net/en_US/fbevents.js (Meta Pixel)

CoreDash-datassa kolmannen osapuolen skriptit aiheuttavat pitkiä animaatiokehyksiä noin 60–70 %:lla sivustoista. Pelkät taginhallintajärjestelmät myötävaikuttavat pitkiin kehyksiin noin 45 %:lla seuratuista kohteista. Omat paketit hallitsevat loppuosaa, yleensä React-uudelleenrenderöinnin tai optimoimattomien tapahtumankäsittelijöiden vuoksi.

INP-attribuutio LoAF:n kautta

INP mittaa ajan käyttäjän vuorovaikutuksesta seuraavaan kehyspiirtoon. Jos tämä väli ylittää 200ms, Google luokittelee kokemuksen tilaan "tarvitsee parannusta". LoAF-data kertoo, mikä skripti suoritettiin tuon välin aikana. 280ms:n INP, jossa 210ms jäljittyy suostumuksenhallinnan skriptiin, on täysin eri ongelma kuin 280ms:n INP, jossa 190ms jäljittyy omaan kassankäsittelijääsi. Korjaus on erilainen. Vastuussa oleva tiimi on erilainen. Kiireellisyys on erilainen.

Ilman LoAF-attribuutiota molemmat näyttävät identtisiltä INP-histogrammissasi. Sen avulla voit ohjata ongelman oikealle henkilölle välittömästi.

Vianetsintätyönkulku

1. Avaa LOAF-dimensio CoreDashissa: Järjestä esiintymistiheyden mukaan (kuinka monessa istunnossa tämä URL näkyi pitkässä kehyksessä). Ylin merkintä on ensisijainen kohteesi.
2. Ristiinsuodata INP:n kanssa: Käytä LOAF-suodatinta INP-mittarinäkymääsi. Tarkista, muuttuuko INP p75, kun eristät istunnot, joissa kyseinen skripti suoritettiin. Yli 30ms:n kasvu vahvistaa, että skripti myötävaikuttaa INP:n heikkenemiseen tuotannossa.
3. Luokittele omaksi tai kolmannen osapuolen skriptiksi: Oma verkkotunnuksesi URL:ssa tarkoittaa, että hallitset korjauksen. Kolmannen osapuolen CDN-URL tarkoittaa, että sinun täytyy joko poistaa, viivästyttää tai korvata toimittajan skripti.
4. Tee korjaus ja varmista: Kolmannen osapuolen skripteille viivästytä latausta ensimmäisen käyttäjävuorovaikutuksen jälkeiseksi käyttäen fasadia tai viivästettyä alustusta. Omalle koodille profiloi tietty funktio Chrome DevToolsissa CPU-rajoituksella 4x. Ota muutos käyttöön ja seuraa LOAF-dimension päivitystä 24–48 tunnin kuluessa todellisesta käyttäjäliikenteestä.

Tekninen nyrkkisääntö

• Mikä tahansa yksittäinen skripti-URL, joka esiintyy pitkissä kehyksissä yli 5 %:ssa istunnoista, on tutkimisen arvoinen. Tällä tahdilla se vaikuttaa mitattavaan osaan todellisista käyttäjistä kuukauden aikana.
• Kolmannen osapuolen skriptien ei pitäisi suorittua vuorovaikutuskäsittelijöiden aikana. Jos taginhallintajärjestelmä laukeaa synkronisesti klikkaustapahtumassa, kyse on konfiguraatio-ongelmasta, ei selaimen rajoituksesta.
• Yli 200ms:n pitkän kehyksen kesto yksittäiselle skriptille on selvä signaali. LoAF API raportoi skriptikohtaisen keston kehyksen sisällä. Mikä tahansa skripti, joka kuluttaa 200ms tai enemmän kehyksestä, on seuraavan INP:n ensisijainen aiheuttaja.
• Omat skriptit LOAF-listassa viittaavat usein sovelluskehyksen ylikuormitukseen. React, Vue ja Angular voivat kaikki tuottaa pitkiä kehyksiä tilapäivitysten aikana. LoAF-URL on oma pakettisi. Profiloi komponenttipuu, älä pelkästään verkkoa.

LOAF-dimensio antaa sinulle jotain, mitä mikään synteettinen testi ei voi: todisteen siitä, mitkä skriptit estävät todellisia käyttäjiä tuotannossa, järjestettynä reaalimaailman esiintymistiheyden mukaan. Suodata sen mukaan, ristiinviittaa INP-datasi kanssa, ja sinulla on priorisoitu lista siitä, mitä korjata ja missä järjestyksessä.