Het meten van zachte navigaties

Barry Pollard
Michal Mocny

Gepubliceerd: 1 februari 2023, Laatst bijgewerkt: 24 juni 2026

Sinds de lancering streeft het Core Web Vitals-initiatief ernaar de daadwerkelijke gebruikerservaring van een website te meten, in plaats van de technische details over hoe een website is gemaakt of geladen. De drie Core Web Vitals-metrics zijn ontwikkeld als gebruikersgerichte metrics – een evolutie ten opzichte van bestaande technische metrics zoals DOMContentLoaded of load , die tijden maten die vaak niets te maken hadden met hoe gebruikers de prestaties van de pagina ervoeren. Hierdoor zou de technologie die gebruikt is om de site te bouwen geen invloed mogen hebben op de score, mits de site goed presteert.

De realiteit is altijd iets complexer dan het ideaal, en de populaire Single Page Application-architectuur is nooit volledig ondersteund door de Core Web Vitals-statistieken . In plaats van afzonderlijke webpagina's te laden wanneer de gebruiker door de site navigeert, gebruiken deze webapplicaties zogenaamde "soft navigation", waarbij de pagina-inhoud wordt gewijzigd door JavaScript. In deze applicaties wordt de illusie van een conventionele webpagina-architectuur in stand gehouden door de URL aan te passen en eerdere URL's in de browsergeschiedenis te bewaren, zodat de terug- en vooruitknoppen werken zoals de gebruiker zou verwachten.

Veel JavaScript-frameworks gebruiken dit model, maar elk op een andere manier. Omdat dit buiten het traditionele begrip van de browser als een "pagina" valt, is het meten hiervan altijd lastig geweest: waar ligt de grens tussen een interactie op de huidige pagina en het beschouwen van deze interactie als een nieuwe pagina?

Het Chrome-team buigt zich al enige tijd over deze uitdaging en streeft naar een standaarddefinitie van wat "soft-navigation" is en hoe de Core Web Vitals hiervoor gemeten kunnen worden – op een vergelijkbare manier als websites die zijn geïmplementeerd in de conventionele multi-page architectuur (MPA).

We hebben op basis van feedback van ontwikkelaars verschillende verbeteringen aan het voorstel aangebracht en streven ernaar om vanaf Chrome 151 twee nieuwe prestatie-API's uit te brengen om dit probleem op te lossen.

Wat is soft navigation?

We hebben de volgende definitie van soft navigation opgesteld:

  • De navigatie wordt gestart door een gebruikersactie.
  • De navigatie resulteert in een zichtbare URL-wijziging voor de gebruiker.
  • De interactie resulteert in zichtbare verf.

Voor sommige websites kan deze definitie leiden tot valse positieven (waarbij gebruikers niet echt een "navigatie" zouden beschouwen) of valse negatieven (waarbij de gebruiker wel een "navigatie" beschouwt, ondanks dat niet aan deze criteria wordt voldaan). We stellen feedback op prijs in de repository voor soft navigation-specificaties .

DevTools-ondersteuning voor soft navigation

We hebben ondersteuning voor soft navigations toegevoegd aan het DevTools Performance-paneel in de traceerweergave:

Een zachte navigatiemarkering in het Performance-paneel met een fragment van youtube.com.

Je ziet markeringen voor soft navigations en LCP, beide gemarkeerd met een * om ze te onderscheiden van de gebruikelijke hard navigation-items. Dit is standaard ingeschakeld en staat los van de API-wijzigingen voor prestatieverbetering die we hierna zullen bespreken. Het is een snelle manier om te testen of de detectie van soft navigations correct werkt voor jouw website.

Voorlopig worden in de traceweergave alleen de soft navigation en LCP-tijdstempels weergegeven. Andere statistieken (zoals LCP) en ondersteuning voor de Live Metrics- weergave worden later toegevoegd.

Hoe implementeert Chrome soft navigation voor webontwikkelaars?

Zodra de functie voor zachte navigatie is ingeschakeld (hierover meer in het volgende gedeelte), zal Chrome de manier waarop het bepaalde prestatiegegevens rapporteert, wijzigen:

  • Na elke gedetecteerde soft soft-navigation navigatie wordt een PerformanceTiming gebeurtenis voor soft-navigatie uitgezonden.
  • Deze soft-navigation ingang bevat een navigationId , de nieuwe URL in het name attribuut, en een interactionId van de initiërende interactie.
  • Een of meer interaction-contentful-paint items worden gegenereerd na interacties die een contentful paint veroorzaken. Deze items bevatten een largestContentfulPaint item dat gebruikt kan worden om de Largest Contentful Paint (LCP) voor soft navigations te meten.
  • Het attribuut navigationId wordt toegevoegd aan elk van de prestatiemetingen ( first-paint , first-contentful-paint , largest-contentful-paint , interaction-contentful-paint , first-input-delay , event en layout-shift ). Dit komt overeen met het navigatie-item waaronder de gebeurtenis is gegenereerd. Houd er rekening mee dat wanneer deze items soft-navigaties omvatten, ze de vorige of volgende navigationId kunnen bevatten, afhankelijk van wanneer het item is gegenereerd. Meer hierover in de sectie ' Rapporteer de statistieken aan de hand van de juiste URL' .
  • De soft-navigation bevat een functie getLargestInteractionContentfulPaint() om de grootste interaction-contentful-paint waarde voor die navigatie op te halen. Deze waarde kan vervolgens worden gebruikt als de initiële LCP voor die navigatie, en die LCP kan vervolgens worden bijgewerkt naarmate er meer interaction-contentful-paint waarden voor die interactie worden waargenomen. Merk op dat dit een largestInteractionContentfulPaint -attribuut vervangt dat beschikbaar was in eerdere origin-tests.
  • Mogelijk hebben sommige interaction-contentful-paint items plaatsgevonden vóór de soft navigation (als de URL-update pas na die paints plaatsvindt). In deze gevallen voorkomt de functie getLargestInteractionContentfulPaint() dat oude items gebufferd en opnieuw bekeken hoeven te worden nadat een soft navigation is voltooid. Merk op dat het item dat door getLargestInteractionContentfulPaint() wordt geretourneerd een exacte kopie is van het grootste interaction-contentful-paint item op het moment dat het werd gegenereerd. Dat item kan dus de vorige navigationId hebben gebruikt, aangezien dat het moment was waarop de paint plaatsvond, maar deze paints moeten worden gemeten ten opzichte van de nieuwe navigationId .
  • De soft-navigation ingang zal ook paintTime en presentationTime als FCP voor die navigatie bevatten.
  • Houd er rekening mee dat interaction-contentful-paint items ook na verdere interacties worden gegenereerd, maar LCP voor een URL moet worden beperkt tot interaction-contentful-paint items die overeenkomen met de interactionId van de soft-navigatie om deze uit te sluiten, en ook alleen tot largestContentfulPaint -eigenschappen daarbinnen.

Deze wijzigingen maken het mogelijk om de Core Web Vitals – en enkele bijbehorende diagnostische statistieken – per paginanavigatie te meten, hoewel er enkele nuances zijn waarmee rekening moet worden gehouden.

Wat zijn de gevolgen van het inschakelen van soft navigation in Chrome?

Hieronder volgen enkele wijzigingen waarmee website-eigenaren rekening moeten houden na het inschakelen van deze functie:

  • Door de soft-navigation items te monitoren, kunnen de prestatie-items worden opgedeeld in afzonderlijke "navigatie-items".
  • CLS- en INP-statistieken kunnen al naar eigen inzicht worden opgesplitst in plaats van te worden gemeten over de gehele levenscyclus van de pagina, maar de Soft Navigation-functie biedt een gestandaardiseerde meting van wanneer dit gebeurt, ongeacht de gebruikte onderliggende technologie.
  • Het item largest-contentful-paint wordt pas definitief geladen na een interactie (wat nodig is om een ​​soft navigation te starten), dus het kan alleen worden gebruikt om de LCP (Lowest Contentful Paint) van de initiële "hard navigation" te meten. Dit betekent dat dit niet verandert wanneer soft navigations worden gemeten, zodat de LCP voor de initiële, harde navigation, paginalading kan worden gemeten zoals altijd.
  • De nieuwe entry interaction-contentful-paint die wordt gegenereerd door interacties, kan worden gebruikt om LCP voor soft navigations te meten door te kijken naar de largestContentfulPaint eigenschap daarin. Er zijn echter enkele aandachtspunten voor het gebruik van deze entry, die we in dit artikel zullen bespreken.
  • Houd er rekening mee dat niet alle gebruikers deze functie voor soft-navigatie ondersteunen, met name oudere Chrome-versies en gebruikers van andere browsers. Wees u ervan bewust dat sommige gebruikers mogelijk geen soft-navigatie-gebaseerde statistieken rapporteren, zelfs als ze wel Core Web Vitals-statistieken rapporteren.

Neem contact op met uw RUM-provider om te controleren of zij het meten van Core Web Vitals via soft navigation ondersteunen. Veel providers zijn van plan deze nieuwe standaard te testen en zullen daarbij rekening houden met de eerder genoemde overwegingen. In de tussentijd staan ​​sommige providers ook beperkte metingen van prestatiestatistieken toe op basis van hun eigen heuristieken.

Voor meer informatie over het meten van de statistieken voor soft navigations, zie het gedeelte 'Het meten van de belangrijkste webstatistieken per soft navigation' .

Hoe schakel ik soft navigation in Chrome in?

De functie voor soepele navigatie is bedoeld om standaard ingeschakeld te zijn in Chrome 151, maar kan al eerder getest worden door deze functie expliciet in te schakelen.

Ontwikkelaars kunnen dit inschakelen door de vlag aan te zetten op chrome://flags/#soft-navigation-heuristics . Als alternatief kan het worden ingeschakeld door het opdrachtregelargument --enable-features=SoftNavigationHeuristics te gebruiken bij het opstarten van Chrome. Het inschakelen van de vlag chrome://flags/#enable-experimental-web-platform-features activeert ook de soft navigations.

Sommige website-eigenaren hebben dit ook al vóór de lancering op hun sites ingeschakeld via het Origin-proefproces. Houd er rekening mee dat de API-structuur tijdens de ontwikkeling van de functie is gewijzigd en dat de uiteindelijke uitgebrachte functie verschilt van eerdere Origin-proeven, zoals beschreven in het wijzigingslogboek van Soft Navigations.

Functiedetectie Soft Navigations API-ondersteuning

Je kunt de volgende code gebruiken om te testen of de API wordt ondersteund:

if (PerformanceObserver.supportedEntryTypes.includes('soft-navigation')) {
  // Monitor Soft Navigations
}

Houd er rekening mee dat supportedEntryTypes bij het eerste gebruik bevroren is. Als ondersteuning voor soft navigations dynamisch wordt toegevoegd door een origin trial token dat in de pagina wordt geïnjecteerd, kan dit de oorspronkelijke waarde retourneren van vóórdat die functie werd geactiveerd.

In dit geval, zolang soft navigations nog niet standaard wordt ondersteund en zich in een overgangsfase bevindt, kan het volgende alternatief worden gebruikt:

if ('SoftNavigationEntry' in window) {
  // Monitor Soft Navigations
}

Hoe kan ik zachte navigatie meten?

Zodra de detectie van soft navigations is ingeschakeld, worden de statistieken gerapporteerd via de PerformanceObserver API, net als bij andere statistieken. Er zijn echter enkele extra aandachtspunten waarmee rekening moet worden gehouden bij deze statistieken.

Rapporteer zachte navigaties

Je kunt een PerformanceObserver gebruiken om soft navigations te observeren. Hieronder volgt een voorbeeldcodefragment dat soft navigation-vermeldingen naar de console logt, inclusief eerdere soft navigations op deze pagina met de buffered -optie:

const observer = new PerformanceObserver(console.log);
observer.observe({ type: "soft-navigation", buffered: true });

Dit kan worden gebruikt om de statistieken voor de volledige levensduur van de pagina voor de vorige navigatie af te ronden.

Rapporteer de statistieken aan de hand van de juiste URL.

Wanneer een soepele navigatie wordt gedetecteerd, moeten de Core Web Vitals van de vorige pagina worden voltooid en vervolgens gerapporteerd voor de vorige URL. Daarna moet een nieuwe monitoring worden gestart voor de nieuwe URL.

Het name van het betreffende soft-navigation -item bevat de nieuwe URL waarvoor statistieken moeten worden gerapporteerd, en de navigationId is de unieke referentie voor deze navigatie (aangezien dezelfde URL meerdere keren kan worden bezocht gedurende de levensduur van een single-page applicatie).

Dit moet worden ingesteld voor elke soft-navigation ingang en worden gebruikt om statistieken te rapporteren totdat de volgende soft-navigation ingang wordt ontvangen.

Rapporteer de juiste URL voor interaction-contentful-paint

Bij het berekenen van LCP op basis van interaction-contentful-paint items zijn extra aandachtspunten nodig, aangezien niet alle interaction-contentful-paint items moeten worden gekoppeld met behulp van de navigationId en gerapporteerd als LCP voor die URL:

  • Het eerste probleem is dat interaction-contentful-paint items mogelijk worden gegenereerd voordat de softnavigatie plaatsvindt, als er een paint-actie plaatsvindt vóór de URL-update. In deze gevallen zal de navigationId verwijzen naar de oude URL. Als de URL eerst wordt bijgewerkt, zal de paint-actie de softnavigatie voltooien en in dat geval zal het soft-navigation item eerst worden gegenereerd, en zal de interaction-contentful-paint de nieuwe URL bevatten.
  • Het tweede probleem is dat interaction-contentful-paint vermeldingen blijven worden gegenereerd voor nieuwere interacties, omdat de reikwijdte van deze prestatiemaatstaf verder reikt dan alleen LCP voor soft-navigaties. We willen alleen de paints voor de soft-navigatiebelasting voor LCP in overweging nemen en niet die voor daaropvolgende interacties.

Daarom moet de interactionId in plaats van de navigationId worden gebruikt om interaction-contentful-paint items te koppelen aan soft-navigation-entries om de juiste URL te verkrijgen. Dit lost het probleem op van items met oude navigationId 's en filtert tevens interaction-contentful-paint items eruit die niet voor LCP in aanmerking komen.

Daarnaast is het raadzaam om ook de functie getLargestInteractionContentfulPaint() van de soft-navigation items te verwerken, zodat interaction-contentful-paint items die plaatsvinden voordat de soft-navigation entries worden weergegeven, gemakkelijker kunnen worden afgehandeld.

De startTime van softnavigaties ophalen

Alle prestatietijden, inclusief die voor soft navigations, en de gegevens die worden gebruikt om de Core Web Vitals-statistieken te berekenen, worden gerapporteerd als een tijd vanaf het moment van de eerste "harde" paginanavigatie. Daarom moet de starttijd van de soft navigation worden afgetrokken van de laadtijden van soft navigation-statistieken (bijvoorbeeld LCP), om deze ten opzichte van de soft navigation-tijd te rapporteren.

De starttijd van de navigatie kan op een vergelijkbare manier worden verkregen door de juiste soft-navigation ingang op te zoeken en de bijbehorende startTime te gebruiken.

De startTime is het tijdstip van de eerste interactie (bijvoorbeeld een klik op een knop) die de soft navigation initieerde. Dit is iets anders dan bij "hard navigations", waarbij de "starttijd" het moment is waarop de nieuwe pagina in de browser wordt geladen en een deel van de event handler-code wordt uitgevoerd. Bij soft navigations is die event handler-code ook inbegrepen, omdat we meten vanaf het moment dat de interactie begint.

Meet de belangrijkste webprestaties per softnavigatie

Om Core Web Vitals te meten, luister je naar soft-navigation items en reset je de metrics wanneer je deze ontvangt. FCP kan worden gegenereerd op basis van de presentationTime en LCP kan worden geïnitialiseerd met de getLargestInteractionContentfulPaint() -waarde. INP en CLS moeten worden geïnitialiseerd op 0, zoals dat ook het geval zou zijn bij een paginalading.

De LCP, INP en CLS kunnen vervolgens zoals gebruikelijk worden gemeten en gemonitord (met uitzondering van het gebruik van interaction-contentful-paint voor LCP, mits de interactionId overeenkomt). De interactionId kan worden gebruikt om de items in een URL een naam te geven, zoals eerder besproken .

De timing wordt nog steeds geretourneerd ten opzichte van de oorspronkelijke starttijd van de "harde" navigatie. Om bijvoorbeeld de LCP voor een zachte navigatie te berekenen, moet u de timing van de interaction-contentful-paint nemen en daarvan de juiste starttijd van de zachte navigatie aftrekken, zoals eerder beschreven, om een ​​timing ten opzichte van de zachte navigatie te verkrijgen.

Sommige statistieken worden traditioneel gedurende de hele levensduur van de pagina gemeten: LCP kan bijvoorbeeld veranderen totdat er een interactie plaatsvindt. CLS en INP kunnen worden bijgewerkt totdat de pagina wordt verlaten, ongeacht eventuele interacties. Daarom moeten de statistieken van de vorige navigatie worden vastgelegd telkens wanneer er een nieuwe zachte navigatie plaatsvindt. Dit betekent dat de initiële statistieken van de "harde" navigatie mogelijk eerder dan gebruikelijk worden vastgelegd wanneer Core Web Vitals worden gemeten met zachte navigaties.

Op dezelfde manier moeten, bij het meten van de statistieken voor de nieuwe softnavigatie van deze lang bestaande statistieken, de statistieken worden "gereset" of "opnieuw geïnitialiseerd" en als nieuwe statistieken worden behandeld, zonder geheugen van de waarden die voor eerdere "pagina's" waren ingesteld. Dat wil zeggen dat het begrip van wat de "grootste" weergave, interactie naar de volgende weergave of lay-outverschuiving is, wordt gereset om opnieuw vanaf nul te kunnen meten.

Hoe moet content die bij elke navigatie hetzelfde blijft, worden behandeld?

LCP voor soft navigations (berekend op basis van interaction-contentful-paint ) meet alleen nieuwe paints, en alleen paints die geassocieerd zijn met de interactie die de navigatie heeft veroorzaakt. Dit kan resulteren in een andere LCP, bijvoorbeeld tussen een cold load van die soft navigation en een soft load.

Neem bijvoorbeeld een pagina met een grote banner die het LCP-element is, maar waarvan de tekst eronder verandert bij elke softnavigatie. Bij de eerste paginalading wordt de banner als het LCP-element aangemerkt en wordt de LCP-timing daarop gebaseerd. Bij volgende softnavigaties is de tekst eronder het grootste element dat na de softnavigatie wordt weergegeven en dus het nieuwe LCP-element. Als de pagina echter wordt geladen via een deeplink naar de softnavigatie-URL, wordt de banner opnieuw weergegeven en komt deze dus in aanmerking om als LCP-element te worden beschouwd.

Op dezelfde manier kan een animatie een deel van de pagina continu bijwerken, onafhankelijk van de softnavigatie. Nieuwe weergaven als gevolg van die achtergrondanimatie worden niet meegenomen in de LCP-berekening voor de nieuwe softnavigatie. Ze kunnen echter wel worden meegenomen in de LCP-berekening als de pagina opnieuw wordt geladen vanaf deze URL.

Zoals deze voorbeelden laten zien, kan het LCP-element voor de softnavigatie anders worden weergegeven, afhankelijk van hoe de pagina wordt geladen – net zoals het laden van een pagina met een ankerlink verderop in de pagina kan resulteren in een ander LCP-element voor harde navigatie.

Hoe meet je TTFB?

De Time to First Byte (TTFB) voor een conventionele paginalading geeft de tijd aan die nodig is voordat de eerste bytes van het oorspronkelijke verzoek worden geretourneerd.

Bij soft navigation is dit een lastigere vraag. Moeten we het eerste verzoek voor de nieuwe pagina meten? Wat als alle content al in de app aanwezig is en er geen verdere verzoeken zijn? Wat als dat verzoek vooraf wordt gedaan met een prefetch? Wat als het een verzoek is dat vanuit het perspectief van de gebruiker niets met soft navigation te maken heeft (bijvoorbeeld een analyseverzoek)?

Een eenvoudigere methode is om een ​​TTFB van 0 te rapporteren voor soft navigations – op een vergelijkbare manier als we aanbevelen voor back/forward cache restores. Dit is de methode die de web-vitals library gebruikt voor soft navigations en wat we momenteel aanbevelen voor deze metric.

Moet u Core Web Vitals met beide methoden meten?

Hoewel deze nieuwe API's alleen beschikbaar zijn voor browsers die op Chromium gebaseerd zijn, kunnen websites ervoor kiezen om zowel te filteren op basis van soft navigations als op basis van hard navigations. Dit maakt vergelijkingen tussen browsers mogelijk en biedt inzicht in historische trends.

Voor LCP betekent dit dat alleen largest-contentful-paint items voor de huidige methode in aanmerking worden genomen, en zowel largest-contentful-paint als interaction-contentful-paint items voor de nieuwe methode.

Voor CLS en INP betekent dit dat deze over de gehele levenscyclus van de pagina worden gemeten, zoals nu het geval is, en dat de tijdlijn afzonderlijk wordt opgesplitst per softnavigatie om afzonderlijke CLS- en INP-waarden voor de nieuwe methode te meten.

De meetwaarden zouden dan tweemaal via een baken moeten worden verzonden en opgeslagen voor analyse.

Gebruik de web-vitals bibliotheek om de Core Web Vitals voor soepele navigatie te meten.

De eenvoudigste manier om met alle nuances rekening te houden, is door de JavaScript-bibliotheek web-vitals te gebruiken. Deze biedt experimentele ondersteuning voor soft-navigatie in een aparte soft-navs branch (die ook beschikbaar is op npm en unpkg ). Dit kan als volgt worden gemeten (waarbij doTraditionalProcessing en doSoftNavProcessing naar behoefte worden vervangen):

import {
  onTTFB,
  onFCP,
  onLCP,
  onCLS,
  onINP,
} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';

function doTraditionalProcessing(callback) {
  ...
}

function doSoftNavProcessing(callback) {
  ...
}

onTTFB(doTraditionalProcessing);
onFCP(doTraditionalProcessing);
onLCP(doTraditionalProcessing);
onCLS(doTraditionalProcessing);
onINP(doTraditionalProcessing);

onTTFB(doSoftNavProcessing, {reportSoftNavs: true});
onFCP(doSoftNavProcessing, {reportSoftNavs: true});
onLCP(doSoftNavProcessing, {reportSoftNavs: true});
onCLS(doSoftNavProcessing, {reportSoftNavs: true});
onINP(doSoftNavProcessing, {reportSoftNavs: true});

De web-vitals bibliotheek zorgt er ook voor dat de statistieken worden gerapporteerd voor de juiste URL, zoals eerder vermeld , omdat zowel de navigationId als de navigationURL in de gegevens die aan de callback worden doorgegeven, zijn opgenomen.

De web-vitals bibliotheek rapporteert de volgende statistieken voor soft navigations:

Metrisch Details
TTFB Gerapporteerd als 0.
FCP Het tijdstip van de eerste inhoudelijke weergave, ten opzichte van het starttijdstip van de softnavigatie, gerekend vanaf de interactie die de softnavigatie activeerde. Bestaande weergaven van de vorige navigatie, of weergaven die niet aan de interactie zijn gekoppeld, worden niet meegenomen.
LCP De tijd van de grootste inhoudsweergave (LCP), ten opzichte van het startmoment van de softnavigatie, vanaf de interactie die de softnavigatie activeerde. Bestaande weergaven van de vorige navigatie die niet aan de interactie zijn gekoppeld, worden niet meegenomen. Zoals gebruikelijk kan dit continu worden bijgewerkt totdat de pagina (of de softnavigatie) wordt verlaten, aangezien de LCP pas dan definitief kan worden vastgesteld.
CLS Het grootste tijdsvenster voor verschuivingen tussen de navigatietijden. Zoals gebruikelijk kan dit blijven worden bijgewerkt totdat de pagina (of de softnavigatie) wordt verlaten, want pas dan kan de CLS worden afgerond.
INP De INP tussen de navigatiemomenten. Zoals gebruikelijk kan deze blijven worden bijgewerkt totdat de pagina (of de softnavigatie) wordt verlaten, aangezien de INP pas dan definitief kan worden vastgesteld. Een waarde van 0 wordt niet gerapporteerd als er geen interacties zijn.

Zullen deze wijzigingen onderdeel worden van de Core Web Vitals-metingen?

Het uiteindelijke doel is om een ​​manier te bieden om prestaties beter te meten op basis van de ervaringen van echte gebruikers. Het is dus inderdaad de bedoeling om deze gegevens op te nemen in de Core Web Vitals-metingen, die na de lancering van de API door alle tools beschikbaar worden gesteld.

We stellen de feedback van webontwikkelaars over de API en of deze de gebruikerservaring beter weergeeft zeer op prijs. De GitHub-repository voor soft navigation is de beste plek om die feedback te geven, maar individuele bugs in de Chrome-implementatie daarvan kunt u melden via de Chrome-probleemtracker .

Hoe worden soft navigations in CruX gerapporteerd?

Hoe soft navigations precies in Crux zullen worden weergegeven zodra de functie is gelanceerd, moet nog worden bepaald. We zullen de wijzigingen in Crux bekendmaken zodra we hier meer informatie over hebben.

Feedback

We vragen actief om feedback over deze API op de volgende plekken:

Maak je geen zorgen als je twijfelt, we horen de feedback liever op beide plekken en zullen de problemen op beide locaties met plezier beoordelen en doorverwijzen naar de juiste afdeling.

Wijzigingslogboek

Tijdens de ontwikkeling van deze API zijn er diverse wijzigingen doorgevoerd, meer dan bij stabiele API's. Raadpleeg de wijzigingslog van Soft Navigations voor meer details.

Conclusie

De Soft Navigations-functie is een veelbelovende benadering voor de verdere ontwikkeling van het Core Web Vitals-initiatief. Het doel is om een ​​veelvoorkomend patroon op het moderne web te meten dat momenteel ontbreekt in onze huidige statistieken. We hebben veel feedback ontvangen van de bredere webcommunity en we moedigen geïnteresseerden dan ook van harte aan om deze kans te grijpen en mee te denken over de API's. Zo zorgen we ervoor dat deze representatief zijn voor wat we hiermee hopen te kunnen meten.

Dankbetuigingen

Miniatuurafbeelding door Jordan Madrid op Unsplash

Dit werk is een voortzetting van het werk dat Yoav Weiss begon toen hij bij Google werkte. We danken Yoav voor zijn inzet voor deze API.