Soft navigations meten

Barry Pollard

Michal Mocny

Gepubliceerd: 1 februari 2023, laatst geüpdatet: 20 september 2026

Sinds de lancering is het initiatief Core Web Vitals bedoeld om de daadwerkelijke gebruikerservaring van een website te meten, in plaats van de technische details achter de manier waarop een website wordt gemaakt of geladen. De 3 statistieken voor Core Web Vitals zijn gemaakt als gebruikersgerichte statistieken. Dit is een evolutie van bestaande technische statistieken zoals DOMContentLoaded of load die tijden meten die vaak geen verband houden met hoe gebruikers de prestaties van de pagina ervaren. Daarom heeft de technologie die is gebruikt om de site te maken geen invloed op de score, mits de site goed presteert.

De realiteit is altijd een beetje lastiger dan het ideaal en de populaire architectuur van apps met één pagina is nooit volledig ondersteund door de Core Web Vitals-statistieken. In plaats van afzonderlijke webpagina's te laden terwijl de gebruiker op de site navigeert, gebruiken deze web-apps zogenaamde 'soft navigations', waarbij de paginacontent wordt gewijzigd door JavaScript. In deze apps wordt de illusie van een conventionele webpagina-architectuur in stand gehouden door de URL te wijzigen en eerdere URL's in de geschiedenis van de browser te pushen, zodat de knoppen Terug en Volgende werken zoals de gebruiker verwacht.

Veel JavaScript-frameworks gebruiken dit model, maar elk op een andere manier. Omdat dit buiten valt wat de browser traditioneel begrijpt als een 'pagina', is het altijd moeilijk geweest om dit te meten: waar ligt de grens tussen een interactie op de huidige pagina en het beschouwen van dit als een nieuwe pagina?

Het Chrome-team heeft deze uitdaging al een tijdje overwogen en wil een definitie standaardiseren van wat een 'zachte navigatie' is en hoe de Core Web Vitals hiervoor kunnen worden gemeten, op een vergelijkbare manier als websites die zijn geïmplementeerd in de conventionele architectuur met meerdere pagina's (MPA) worden gemeten.

We hebben verschillende verbeteringen aangebracht in het voorstel op basis van feedback van ontwikkelaars en hebben 2 nieuwe prestatie-API's gelanceerd om dit probleem op te lossen vanaf Chrome 151. Daarnaast hebben we de statistieken voor zachte navigatie beschikbaar gemaakt in het Chrome User Experience Report (CrUX) als experimentele statistieken.

Wat is een soft navigation?

We hebben de volgende definitie van een zachte navigatie bedacht:

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

Voor sommige sites kan deze definitie leiden tot valspositieven (waarbij gebruikers niet echt vinden dat er een 'navigatie' heeft plaatsgevonden) of valsnegatieven (waarbij de gebruiker wel vindt dat er een 'navigatie' heeft plaatsgevonden, ook al wordt niet aan deze criteria voldaan). We horen graag je feedback in de repository met specificaties voor zachte navigatie.

DevTools-ondersteuning voor soft navigations

We hebben ondersteuning voor soft navigations toegevoegd aan het deelvenster Prestaties van DevTools in de weergave Live statistieken en in de traceerweergave met ondersteuning voor Inzichten en markeringen:

Hoe implementeert Chrome zachte navigaties voor webontwikkelaars?

Nadat de functie voor zachte navigatie is aangezet (meer hierover in het volgende gedeelte), verandert Chrome de manier waarop bepaalde prestatiestatistieken worden gerapporteerd:

• Er wordt een soft-navigation PerformanceTiming-gebeurtenis gestuurd nadat elke soft-navigatie is waargenomen.
• Dit soft-navigation-item bevat een navigationId, de nieuwe URL in het kenmerk name en een interactionId van de initiërende interactie.
• Er worden een of meer interaction-contentful-paint-items gegenereerd na interacties die een contentful paint veroorzaken. Deze bevat een largestContentfulPaint-item dat kan worden gebruikt om de Largest Contentful Paint (LCP) voor zachte navigaties te meten.
• Het kenmerk navigationId wordt toegevoegd aan elk van de prestatietimings (first-paint, first-contentful-paint, largest-contentful-paint, interaction-contentful-paint, first-input-delay, event en layout-shift). Dit komt overeen met de navigatie-invoer waaronder de gebeurtenis is uitgevoerd. Als deze vermeldingen zachte navigaties omvatten, kunnen ze de vorige of volgende navigationId bevatten, afhankelijk van wanneer de vermelding is verzonden. Meer informatie hierover vind je in het gedeelte De statistieken rapporteren voor de juiste URL.
• De soft-navigation bevat een getLargestInteractionContentfulPaint()-functie om de grootste interaction-contentful-paint-vermelding voor die navigatie op te halen. Dit kan dan worden gebruikt als de eerste LCP voor die navigatie. Die LCP kan dan worden geüpdatet als er meer interaction-contentful-paint-items voor die interactie worden waargenomen. Dit vervangt een largestInteractionContentfulPaint-kenmerk dat beschikbaar was in eerdere origin trials.
• Mogelijk hebben er enkele interaction-contentful-paint-vermeldingen plaatsgevonden voordat de soft navigatie plaatsvindt (als de URL-update pas na die weergaven plaatsvindt). In deze gevallen voorkomt de functie getLargestInteractionContentfulPaint() dat je moet bufferen en oude vermeldingen moet terugkijken nadat een zachte navigatie is afgerond. De invoer die door getLargestInteractionContentfulPaint() wordt geretourneerd, is een exacte kopie van de grootste interaction-contentful-paint-invoer op het moment dat deze werd verzonden. Die invoer heeft misschien de vorige navigationId gebruikt, omdat de weergave toen plaatsvond, maar deze weergaven moeten worden gemeten aan de hand van de nieuwe navigationId.
• De invoer soft-navigation bevat ook paintTime en presentationTime als de FCP voor die navigatie.
• Houd er rekening mee dat interaction-contentful-paint-items ook worden verzonden na verdere interacties, maar dat de LCP voor een URL moet worden beperkt tot interaction-contentful-paint-items die overeenkomen met de zachte navigaties interactionId om deze uit te sluiten en ook alleen tot largestContentfulPaint-property's daarbinnen.

Met deze wijzigingen kunnen de Core Web Vitals (en sommige van de bijbehorende diagnostische statistieken) per paginanavigatie worden gemeten, hoewel er enkele nuances zijn waarmee je rekening moet houden.

Wat zijn de gevolgen als ik zachte navigaties aanzet in Chrome?

Dit zijn enkele wijzigingen waar site-eigenaren rekening mee moeten houden nadat ze deze functie hebben aangezet:

• Door de soft-navigation-items te monitoren, kunnen de prestatie-items worden opgesplitst in elke navigatie.
• CLS- en INP-statistieken kunnen al naar eigen goeddunken worden gesegmenteerd, in plaats van dat ze worden gemeten gedurende de hele levenscyclus van de pagina. De functie voor zachte navigatie biedt een gestandaardiseerde meting van wanneer dit gebeurt, ongeacht de onderliggende technologie die wordt gebruikt.
• De invoer largest-contentful-paint wordt afgerond bij een interactie (wat nodig is om een geleidelijke navigatie te starten). Deze kan dus alleen worden gebruikt om de LCP voor de eerste 'harde' navigatie te meten. Dit betekent dat dit niet verandert wanneer soft navigations worden gemeten, zodat de LCP voor de eerste, hard navigation, het laden van de pagina kan worden gemeten zoals altijd.
• De nieuwe interaction-contentful-paint-invoer die wordt gegenereerd door interacties, kan worden gebruikt om de LCP voor zachte navigaties te meten door naar de property largestContentfulPaint daarin te kijken. Er zijn wel enkele overwegingen voor het gebruik van deze invoer die we in dit artikel bespreken.
• Niet alle gebruikers ondersteunen deze functie voor zachte navigatie, vooral niet de gebruikers die andere browsers of versies van Chrome van vóór 151 gebruiken. Houd er rekening mee dat sommige gebruikers misschien geen statistieken op basis van zachte navigatie rapporteren, zelfs als ze statistieken voor Core Web Vitals rapporteren.

Vraag je RUM-provider of deze de meting van Core Web Vitals via zachte navigatie ondersteunt. Veel uitgevers zijn van plan deze nieuwe standaard te testen en houden rekening met de eerdere overwegingen. In de tussentijd staan sommige providers ook beperkte metingen van prestatiestatistieken toe op basis van hun eigen heuristiek.

Ga naar het gedeelte Core Web Vitals meten per zachte navigatie voor meer informatie over hoe je de statistieken voor zachte navigaties meet.

Hoe zet ik soft navigations aan in Chrome?

De functie voor zachte navigatie staat standaard aan vanaf Chrome 151.

Functie die ondersteuning voor de Soft Navigations API herkent

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

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

Of:

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

Hoe kan ik zachte navigaties meten?

Waar dit wordt ondersteund, kunnen de statistieken worden gerapporteerd met de PerformanceObserver API, net als andere statistieken. Er zijn echter enkele extra overwegingen waarmee u rekening moet houden voor deze statistieken.

Geleidelijke navigaties rapporteren

Je kunt een PerformanceObserver gebruiken om zachte navigaties te observeren. Hieronder staat een voorbeeld van een codefragment dat soft-navigatie-items registreert in de console, waaronder eerdere soft-navigaties op deze pagina met de optie buffered:

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

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

Rapporteer de statistieken voor de juiste URL

Als er een zachte navigatie wordt waargenomen, moeten de Core Web Vitals van de vorige pagina worden afgerond en daarna worden gerapporteerd voor de vorige URL. Er moet dan een nieuwe controle worden gestart voor de nieuwe URL.

Het kenmerk name van de juiste soft-navigation-vermelding bevat de nieuwe URL waarvoor statistieken moeten worden gerapporteerd en de navigationId is de unieke referentie voor deze navigatie (omdat dezelfde URL meerdere keren kan worden bezocht tijdens de levensduur van een app met één pagina).

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

Meld de juiste URL voor interaction-contentful-paint

Er zijn extra overwegingen nodig om de LCP te berekenen op basis van interaction-contentful-paint-items, omdat niet alle interaction-contentful-paint-items moeten worden toegewezen met de navigationId en gerapporteerd als LCP voor die URL:

• Het eerste probleem is dat interaction-contentful-paint-items kunnen worden verzonden voordat de zachte navigatie plaatsvindt als er een weergave plaatsvindt vóór de URL-update. In deze gevallen is de navigationId voor de oude URL. Als de URL eerst wordt geüpdatet, voltooit de weergave de zachte navigatie. In dat geval wordt de invoer soft-navigation eerst verstuurd en heeft de interaction-contentful-paint de nieuwe URL.
• Het 2e probleem is dat interaction-contentful-paint-items worden blijven gegenereerd voor nieuwere interacties, omdat het bereik van deze prestatiestatistiek verder gaat dan alleen LCP voor zachte navigaties. We willen alleen rekening houden met de weergaven voor het laden van de zachte navigatie voor LCP en niet met de weergaven voor latere interacties.

Gebruik daarom de interactionId in plaats van de navigationId om interaction-contentful-paint-items toe te wijzen aan soft-navigation-entries om de juiste URL te krijgen. Hiermee worden alle vermeldingen met oude navigationId's verwerkt en worden alle interaction-contentful-paint-vermeldingen gefilterd die niet in aanmerking komen voor LCP.

Verwerk ook eerst de functie getLargestInteractionContentfulPaint() van de vermeldingen soft-navigation om vermeldingen interaction-contentful-paint te verwerken die plaatsvonden voordat de soft-navigation entries werd verzonden.

De startTime van soft navigations ophalen

Alle prestatietimings, waaronder die voor soft navigations, en de vermeldingen die worden gebruikt om de Core Web Vitals-statistieken te berekenen, worden gerapporteerd als een tijd vanaf de eerste harde paginanavigatietijd. Daarom moet de begintijd van de geleidelijke navigatie worden afgetrokken van de laadstatistieken voor geleidelijke navigatie (bijvoorbeeld LCP) om ze te rapporteren ten opzichte van deze tijd voor geleidelijke navigatie.

De begintijd van de navigatie kan op een vergelijkbare manier worden verkregen door deze toe te wijzen aan de juiste soft-navigation-vermelding en de startTime te gebruiken.

De startTime is de tijd van de eerste interactie (bijvoorbeeld een klik op een knop) die de zachte navigatie heeft gestart. Dit is iets anders dan harde navigaties, waarbij de begintijd is wanneer de nieuwe pagina wordt vastgelegd in de browser en nadat een deel van de code van de gebeurtenishandler is uitgevoerd. De begintijden van geleidelijke navigatie omvatten ook die gebeurtenis-handlerafhandelingscode, omdat we meten vanaf de begintijd van de interactie.

Core Web Vitals meten per geleidelijke navigatie

Als je Core Web Vitals wilt meten, luister je naar soft-navigation-items en reset je de statistieken als je deze krijgt. FCP kan worden verzonden op basis van de presentationTime en LCP kan worden geïnitialiseerd voor de invoer getLargestInteractionContentfulPaint(). INP en CLS moeten worden geïnitialiseerd op 0, zoals ze zouden zijn voor het laden van een pagina.

De LCP, INP en CLS kunnen dan zoals gewoonlijk worden gemeten en gecontroleerd (met uitzondering van het gebruik van interaction-contentful-paint voor LCP, op voorwaarde dat de interactionId overeenkomt). De interactionId kan worden gebruikt om de items een naam te geven voor een URL, zoals eerder besproken.

De timing wordt nog steeds geretourneerd ten opzichte van de oorspronkelijke 'harde' begintijd van de navigatie. Als je bijvoorbeeld de LCP voor een geleidelijke navigatie wilt berekenen, neem je de timing van interaction-contentful-paint en trek je de juiste begintijd van de geleidelijke navigatie af, zoals eerder beschreven, om een timing te krijgen die relatief is aan de geleidelijke navigatie.

Sommige statistieken worden van oudsher gemeten gedurende de levensduur van de pagina. LCP kan bijvoorbeeld veranderen totdat er een interactie plaatsvindt. CLS en INP kunnen worden geüpdatet totdat de gebruiker de pagina verlaat, ongeacht de interacties. Daarom moeten de statistieken van de vorige navigatie worden afgerond als er een nieuwe zachte navigatie plaatsvindt. Dit betekent dat de eerste 'harde' navigatiestatistieken misschien eerder dan normaal worden afgerond als je Core Web Vitals meet met zachte navigaties.

Als je de statistieken voor de nieuwe zachte navigatie van deze langdurige statistieken gaat meten, moeten de statistieken ook worden gereset of opnieuw worden geïnitialiseerd en worden behandeld als nieuwe statistieken, zonder geheugen van de waarden die zijn ingesteld voor eerdere pagina's. Dit betekent dat het begrip van wat de 'grootste' weergave, interactie tot volgende weergave of verschuiving van de indeling is, wordt gereset, zodat je opnieuw kunt meten.

Hoe moet content die hetzelfde blijft tussen navigaties worden behandeld?

LCP voor zachte navigaties (berekend op basis van interaction-contentful-paint) meet alleen nieuwe weergaven en alleen weergaven die zijn gekoppeld aan de interactie die de navigatie heeft veroorzaakt. Dit kan leiden tot een andere LCP van een koud laden van die zachte navigatie naar een zacht laden.

Neem bijvoorbeeld een pagina met een grote bannerafbeelding die het LCP-element is, maar de tekst eronder verandert bij elke zachte navigatie. Bij het eerste laden van de pagina wordt de bannerafbeelding gemarkeerd als het LCP-element en wordt de LCP-timing daarop gebaseerd. Voor volgende soft navigations is de tekst eronder het grootste element dat na de soft navigation wordt getekend en is dit het nieuwe LCP-element. Als de pagina wordt geladen met een deep link naar de URL voor zachte navigatie, is de bannerafbeelding een nieuwe weergave en komt deze in aanmerking om te worden beschouwd als het LCP-element.

Op dezelfde manier kan een animatie een deel van de pagina voortdurend updaten, onafhankelijk van een zachte navigatie die plaatsvindt. Nieuwe weergaven vanwege die achtergrondanimatie worden niet meegewogen voor de LCP voor de nieuwe zachte navigatie. Ze kunnen wel worden overwogen voor LCP als de pagina opnieuw is geladen via deze URL.

Zoals deze voorbeelden laten zien, kan het LCP-element voor de zachte navigatie anders worden gerapporteerd, afhankelijk van hoe de pagina wordt geladen. Op dezelfde manier kan het laden van een pagina met een ankerlink verderop op de pagina leiden tot een ander LCP-element voor harde navigaties.

Hoe meet je de TTFB?

Time to First Byte (TTFB) voor een conventionele pagina die wordt geladen, staat voor de tijd waarin de eerste bytes van het oorspronkelijke verzoek worden geretourneerd.

Voor een 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 bestaat en er geen aanvullende verzoeken zijn? Wat als dat verzoek van tevoren wordt gedaan met een prefetch? Wat als een verzoek vanuit het perspectief van de gebruiker niet gerelateerd is aan de zachte navigatie (bijvoorbeeld een analytisch verzoek)?

Een eenvoudigere methode is om een TTFB van 0 te rapporteren voor zachte navigaties, op een vergelijkbare manier als we aanbevelen voor herstel van de Back-Forward Cache. Dit is de methode die de web-vitals-bibliotheek gebruikt voor zachte navigaties en wat we op dit moment aanbevelen voor deze statistiek.

Moet je Core Web Vitals met beide methodologieën meten?

Hoewel deze nieuwe API's beperkt zijn tot Chromium-browsers, willen sites misschien beide meten door te segmenteren op zachte navigaties en door te blijven segmenteren op harde navigaties. Zo kunnen vergelijkingen tussen browsers en historische trends worden gemaakt.

Voor LCP betekent dit dat we alleen largest-contentful-paint-items overwegen voor de huidige manier en zowel largest-contentful-paint- als interaction-contentful-paint-items voor de nieuwe manier.

Voor CLS en INP betekent dit dat deze worden gemeten gedurende de hele levenscyclus van de pagina, zoals nu het geval is, en dat de tijdlijn afzonderlijk wordt opgesplitst door zachte navigaties om afzonderlijke CLS- en INP-waarden voor de nieuwe te meten.

De statistieken moeten dan 2 keer worden verzonden en opgeslagen voor analyse.

Gebruik de web-vitals-bibliotheek om de Core Web Vitals voor zachte navigaties te meten

De makkelijkste manier om rekening te houden met alle nuances is de JavaScript-bibliotheek web-vitals te gebruiken, die vanaf v6.0.0 ondersteuning biedt voor zachte navigaties. Dit kan op de volgende manier worden gemeten (vervang doTraditionalProcessing en doSoftNavProcessing waar nodig):

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 je de statistieken rapporteert voor de juiste URL, zoals eerder vermeld, omdat ze zowel de navigationId als een navigationURL bevatten in de vermeldingen die aan de callback worden geleverd.

De web-vitals-bibliotheek rapporteert de volgende statistieken voor zachte navigaties:

Worden deze wijzigingen onderdeel van de Core Web Vitals-metingen?

Het uiteindelijke doel is om een manier te bieden om de prestaties beter te meten, zoals echte gebruikers die ervaren. Het doel is dus om deze op te nemen in de metingen van Core Web Vitals, zoals die door alle tools worden getoond nadat de API is gelanceerd.

Hoe worden soft navigations gerapporteerd in CrUX?

We hebben experimentele versies van de Core Web Vitals-statistieken gelanceerd in CrUX. Deze beëindigen de CLS en INP voor harde navigatie na de eerste zachte navigatie en bevatten ook aanvullende LCP-, CLS- en INP-metingen voor elke zachte navigatie. We zijn van plan deze experimentele statistieken in mei 2027 te upgraden naar stabiele statistieken. Ga voor meer informatie naar de blogpost Experimentele statistieken voor zachte navigatie nu beschikbaar in CrUX.

Hoe ga je om met zachte navigaties in andere browsers?

Zachte navigaties zijn moeilijk programmatisch te detecteren in browsers die de API niet ondersteunen. Dat is precies de reden waarom we aan deze API hebben gewerkt.

Je kunt de Navigation API gebruiken om te controleren op URL-wijzigingen, waardoor INP per URL kan worden gesegmenteerd (en CLS op dezelfde manier, hoewel dit op dit moment alleen voor Chromium geldt en dus niet wordt gemeten). Dit geldt niet voor de weergavestatistieken (FCP en LCP), die alleen kunnen worden geschat.

Tegelijkertijd vinden we de inzichten die deze API biedt te waardevol om te negeren, zowel bij het meten van de timing van zachte navigaties als bij het toewijzen van de statistieken aan de juiste navigatie. We raden u aan deze nieuwe API te gebruiken, ondanks het gebrek aan ondersteuning voor meerdere browsers op dit moment. Net als bij de lancering van Core Web Vitals hebben de vastgestelde problemen en prestatieoplossingen waarschijnlijk invloed op alle browsers, ook al is de zichtbaarheid op dit moment beperkt tot op Chromium gebaseerde browsers.

We blijven werken aan het standaardisatieproces en gaan in gesprek met de andere browserleveranciers om het belang van deze API aan te tonen.

Feedback

We zijn actief op zoek naar feedback over deze API op de volgende plaatsen:

• Feedback over de API moet worden ingediend als problemen op GitHub.
• Bugs in de Chromium-implementatie moeten worden gemeld in de Issue Tracker van Chrome, als dit nog niet een van de bekende problemen is.
• Algemene feedback over Site-vitaliteit kun je delen via web-vitals-feedback@googlegroups.com.

Maak je geen zorgen als je twijfelt. We horen de feedback liever op een van beide plaatsen en zullen de problemen op beide plaatsen graag beoordelen en doorsturen naar de juiste locatie.

Wijzigingslogboek

Tijdens de ontwikkeling van deze API zijn er een aantal wijzigingen in aangebracht, meer dan bij stabiele API's. Ga naar de changelog voor zachte navigaties voor meer informatie.

Conclusie

De functie Soft Navigations is een interessante benadering van hoe het initiatief Core Web Vitals zich kan ontwikkelen om een veelvoorkomend patroon op het moderne web te meten dat ontbreekt in onze statistieken. We hebben veel feedback verzameld van de bredere webcommunity en zijn enthousiast over het potentieel van deze API.

Erkenning

Thumbnailafbeelding door Jordan Madrid op Unsplash

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