Core/Dash-ulottuvuus: LOAF

Löydä tarkat komentosarjojen URL-osoitteet, jotka tukkivat pääsäiettäsi ja heikentävät INP-arvoa yhdistämällä Long Animation Frames -tapahtumat niiden lähteeseen.

Ilmainen kokeilu

Trusted by market leaders · Client results

nina carewhowhatwearworkivamarktplaatsebayfotocasahappyhorizonnestleerasmusmcmonarchperionloopearplugssnvsaturncomparevpnharvardadevintaaleteiakpndpg mediamy work featured on web.dev

Ulottuvuus: Long Animation Frames (lurl)

LOAF-ulottuvuus tuo esiin komentosarjojen URL-osoitteet, jotka aiheuttivat Long Animation Frames -tapahtumia käyttäjiesi istuntojen aikana. Jokainen arvo on komentosarjan URL-osoite: ensimmäisen osapuolen paketti, kolmannen osapuolen analytiikkatagi, chat-widget, suostumustenhallinta tai mikä tahansa muu, joka suoritettiin tarpeeksi kauan renderöinnin estämiseksi. Tämä on lähteen tason attribuutio, ei pelkkä pinovedos, joka sinun on rakennettava uudelleen DevToolsissa.

CoreDash kerää nämä tiedot käyttämällä Long Animation Frames API (LoAF) -rajapintaa, jonka Chrome tarjoaa korvaamaan vanhemman Long Tasks API:n. Siinä missä Long Tasks kertoi sinulle, että kehyksen kesto oli liian pitkä, LoAF kertoo, mitkä komentosarjat suoritettiin tuon kehyksen sisällä ja mitkä niiden URL-osoitteet olivat. Tämä ero tekee tästä ulottuvuudesta hyödyllisen tuotannossa.

coredash loaf scripts

Miksi Long Tasks ei riittänyt

Long Tasks API (saatavilla vuodesta 2017) liputti minkä tahansa yli 50 ms kestävän pääsäikeen tehtävän, mutta se ei antanut lähes mitään attribuutiota. Pystyit näkemään, että esto tapahtui; et pystynyt näkemään, mikä sen aiheutti. Kehittäjät viettivät tunteja korreloimalla tehtävien aikaleimoja verkkolatausputousnäkymien kanssa arvaillen, mikä komentosarja oli vastuussa.

LoAF API muuttaa tämän. Se raportoi PerformanceLongAnimationFrameEntry -objekteja, joista jokainen sisältää scripts -taulukon. Jokaisella tämän taulukon merkinnällä on invokerType, sourceURL ja duration. CoreDash lukee sourceURL -arvon jokaiselle pitkän kehyksen aikana suoritetulle komentosarjalle ja tallentaa sen LOAF-ulottuvuuden arvona. Tuloksena on luokiteltu luettelo komentosarjojen URL-osoitteista järjestettynä sen mukaan, kuinka usein ne esiintyvät käyttäjiesi pitkissä kehyksissä.

Kuinka CoreDash käyttää LoAF-tietoja

Aina kun käyttäjän vuorovaikutus laukaisee pitkän animaatiokehyksen, CoreDash tallentaa myötävaikuttavien komentosarjojen URL-osoitteet INP-havainnon ohella. Tämä tarkoittaa, että voit suodattaa INP-tietojasi LOAF URL -osoitteen perusteella ja nähdä, mikä komentosarja on vastuussa huonoimmista vuorovaikutuksistasi. Ulottuvuus ryhmitellään URL-osoitteen mukaan, joten näet määrän siitä, kuinka monessa istunnossa kyseinen komentosarja aiheutti pitkän kehyksen.

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

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

CoreDash-tiedoissa kolmannen osapuolen komentosarjat vastaavat pitkistä animaatiokehyksistä noin 60–70 %:ssa sivustoista. Pelkät tag managerit vaikuttavat pitkiin kehyksiin noin 45 %:ssa valvotuista ominaisuuksista. Ensimmäisen osapuolen paketit hallitsevat loppuosaa, yleensä Reactin uudelleenrenderöintien tai optimoimattomien tapahtumankäsittelijöiden vuoksi.

INP-attribuutio LoAF:n kautta

INP mittaa aikaa käyttäjän vuorovaikutuksesta seuraavaan kehyksen piirtoon. Jos tämä väli ylittää 200 ms, Google luokittelee kokemuksen tilaan "kaipaa parannusta". LoAF-tiedot kertovat sinulle, mikä komentosarja suoritettiin tuon välin aikana. 280 ms:n INP, josta 210 ms jäljitetään suostumustenhallinnan komentosarjaan, on täysin eri ongelma kuin 280 ms:n INP, josta 190 ms jäljitetään omaan kassakä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 reitittää ongelman välittömästi oikealle henkilölle.

Vianmäärityksen työnkulku

  1. Avaa LOAF-ulottuvuus CoreDashissa: Lajittele taajuuden mukaan (kuinka monessa istunnossa tämä URL-osoite näkyi pitkässä kehyksessä). Ylin merkintä on korkeimman prioriteetin kohteesi.
  2. Ristiinsuodata INP:n kanssa: Käytä LOAF-suodatinta INP-mittarinäkymässäsi. Tarkista, muuttuuko INP:n p75-arvo, kun eristät istunnot, joissa kyseinen komentosarja suoritettiin. Yli 30 ms:n lisäys vahvistaa, että komentosarja myötävaikuttaa INP:n heikkenemiseen tuotannossa.
  3. Luokittele ensimmäisen osapuolen tai kolmannen osapuolen mukaan: Oma verkkotunnuksesi URL-osoitteessa tarkoittaa, että hallitset korjausta. Kolmannen osapuolen CDN URL -osoite tarkoittaa, että sinun on joko poistettava, viivästettävä tai korvattava toimittajan komentosarja.
  4. Käytä korjausta ja vahvista: Kolmannen osapuolen komentosarjojen kohdalla lykkää latausta ensimmäisen käyttäjän vuorovaikutuksen jälkeiseen aikaan käyttämällä fasadia (facade) tai viivästettyä alustusta. Ensimmäisen osapuolen koodin osalta profiloi tietty funktio Chrome DevToolsissa asettamalla CPU:n rajoitus arvoon 4x. Ota muutos käyttöön ja seuraa LOAF-ulottuvuuden päivittymistä 24–48 tunnin sisällä todellisesta käyttäjäliikenteestä.

Insinöörin nyrkkisääntö

  • Mikä tahansa yksittäinen komentosarjan URL-osoite, joka esiintyy pitkissä kehyksissä yli 5 %:ssa istunnoista, on tutkimisen arvoinen. Sillä tahdilla se vaikuttaa mitattavissa olevaan osaan todellisista käyttäjistä kuukauden aikana.
  • Kolmannen osapuolen komentosarjojen ei tulisi suorittua vuorovaikutusten käsittelijöiden aikana. Jos tag manager laukeaa synkronisesti klikkaustapahtumassa, se on määritysongelma, ei selaimen rajoitus.
  • Yli 200 ms:n pitkän kehyksen kesto yhdelle komentosarjalle on selkeä signaali. LoAF API raportoi komentosarjakohtaisen keston kehyksen sisällä. Mikä tahansa komentosarja, joka kuluttaa 200 ms tai enemmän kehyksestä, on ensisijainen syy mihin tahansa seuraavaan INP-arvoon.
  • Ensimmäisen osapuolen komentosarjat LOAF-luettelossa viittaavat usein sovelluskehyksen aiheuttamaan kuormitukseen. React, Vue ja Angular voivat kaikki tuottaa pitkiä kehyksiä tilapäivitysten aikana. LoAF URL on oma pakettisi. Profiloi komponenttipuu, älä pelkkää verkkoa.

LOAF-ulottuvuus antaa sinulle jotain, mitä mikään synteettinen testi ei voi: todisteen siitä, mitkä komentosarjat estävät todellisia käyttäjiä tuotannossa, luokiteltuna todellisen maailman esiintymistiheyden mukaan. Suodata sen perusteella, ristiinviittaa INP-tietoihisi, ja sinulla on priorisoitu luettelo siitä, mitä tarkalleen pitää korjata ja missä järjestyksessä.