Experimenteren met het meten van zachte navigatie

Barry Pollard
Michal Mocny

Gepubliceerd: 1 februari 2023, Laatst bijgewerkt: 22 juli 2025

Sinds de lancering heeft het Core Web Vitals-initiatief zich gericht op het meten van de daadwerkelijke gebruikerservaring van een website, in plaats van de technische details achter hoe een website wordt gemaakt of geladen. De drie Core Web Vitals-statistieken zijn ontwikkeld als gebruikersgerichte statistieken – een evolutie ten opzichte van bestaande technische statistieken zoals DOMContentLoaded of load , die timings 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 moeten hebben op de score, mits de site goed presteert.

De realiteit is altijd iets lastiger dan 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 terwijl 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 behouden door de URL te wijzigen en eerdere URL's in de browsergeschiedenis te pushen, zodat de knoppen 'vooruit' en 'terug' werken zoals de gebruiker zou verwachten.

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

Het Chrome-team houdt zich al een tijdje bezig met deze uitdaging en wil een standaarddefinitie opstellen voor 'soft-navigation' en hoe de Core Web Vitals hiervoor kunnen worden gemeten. Dit gebeurt op een vergelijkbare manier als websites die zijn geïmplementeerd in de conventionele multi-page-architectuur (MPA).

We hebben sinds de laatste proefperiode hard gewerkt aan het verbeteren van de API en vragen ontwikkelaars nu om de nieuwste versie uit te proberen en feedback te geven over de aanpak voordat deze wordt gelanceerd.

Wat is zachte navigatie?

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 en een wijziging in de geschiedenis.
  • De navigatie resulteert in een DOM-wijziging.

Voor sommige sites kunnen deze heuristieken leiden tot vals-positieve resultaten (waarbij gebruikers niet echt denken dat er sprake is van "navigatie") of vals-negatieve resultaten (waarbij de gebruiker wel denkt dat er sprake is van "navigatie", ondanks dat deze criteria niet worden gehaald). We stellen feedback over de heuristieken op prijs in de repository voor soft navigation-specificaties .

Hoe implementeert Chrome zachte navigatie?

Zodra de heuristiek voor zachte navigatie is ingeschakeld (meer hierover in de volgende sectie), verandert Chrome de manier waarop bepaalde prestatiegegevens worden gerapporteerd:

  • Er wordt een PerformanceTiming -gebeurtenis voor soft-navigation uitgezonden nadat elke zachte navigatie is gedetecteerd.
  • Een nieuwe interaction-contentful-paint wordt gegenereerd na interacties die een betekenisvolle paint veroorzaken. Dit kan worden gebruikt om de Largest Contentful Paint (LCP) voor soft navigations te meten wanneer een dergelijke paint een soft navigation omvat. Merk op dat de oorspronkelijke implementatie van deze reset de metriek voor de largest-contentful-paint mogelijk maakte, waardoor deze opnieuw kon worden gegenereerd. We hebben echter gekozen voor deze alternatieve aanpak voor de eenvoud en een breder toekomstperspectief.
  • Er wordt aan elk van de prestatietimings ( first-paint , first-contentful-paint , largest-contentful-paint , interaction-contentful-paint , first-input-delay , event en layout-shift ) toegevoegd die overeenkomt met het navigationId -item waaraan de gebeurtenis was gerelateerd. Hierdoor kunnen Largest Contentful Paint (LCP) , Cumulative Layout Shift (CLS) en Interaction to Next Paint (INP) worden berekend en aan de juiste URL worden toegeschreven.

Dankzij deze wijzigingen kunnen de Core Web Vitals en enkele bijbehorende diagnostische statistieken per paginanavigatie worden gemeten. Er zijn echter enkele nuances waar rekening mee moet worden gehouden.

Wat zijn de gevolgen van het inschakelen van zachte navigatie in Chrome?

Hieronder staan enkele wijzigingen waar site-eigenaren rekening mee moeten houden nadat ze deze functie hebben ingeschakeld:

  • CLS- en INP-statistieken kunnen worden opgesplitst per zachte navigatie-URL, in plaats van dat ze worden gemeten over de gehele levenscyclus van de pagina.
  • De invoer largest-contentul-paint is al definitief vastgelegd in een interactie en wordt daarom alleen gebruikt om de initiële 'harde' navigatie-LCP te meten. Er is dus geen aanvullende logica nodig om de manier waarop dat wordt gemeten te wijzigen.
  • De nieuwe interaction-contentful-paint metriek wordt gegenereerd vanuit interacties, wat kan worden gebruikt om LCP voor zachte navigaties te meten.
  • Om zachte navigatie aan de juiste URL toe te kunnen wijzen, moet u in uw toepassingscode mogelijk rekening houden met het nieuwe kenmerk navigationID in uw prestatie-invoer.
  • Niet alle gebruikers ondersteunen deze API voor softnavigatie, met name voor oudere Chrome-versies en gebruikers van andere browsers. Houd er rekening mee dat sommige gebruikers mogelijk geen softnavigatiestatistieken rapporteren, zelfs niet als ze Core Web Vitals-statistieken rapporteren.
  • Omdat het een experimentele nieuwe functie is die niet standaard is ingeschakeld, moeten sites deze functie testen op onbedoelde neveneffecten.

Neem contact op met uw RUM-provider of zij het meten van Core Web Vitals via soft navigation ondersteunen. Velen zijn van plan deze nieuwe standaard te testen en zullen rekening houden met de bovenstaande overwegingen. In de tussentijd staan sommige providers ook beperkte metingen van prestatiegegevens toe op basis van hun eigen heuristiek.

Voor meer informatie over het meten van de statistieken voor zachte navigatie raadpleegt u het gedeelte 'Kernwebvitals per zachte navigatie meten' .

Hoe schakel ik zachte navigatie in Chrome in?

Zachte navigatie is standaard niet ingeschakeld in Chrome, maar u kunt ermee experimenteren door deze functie expliciet in te schakelen.

Ontwikkelaars kunnen dit inschakelen door de vlag voor experimentele webplatformfuncties in te schakelen via chrome://flags/#soft-navigation-heuristics of door de opdrachtregelargumenten --enable-features=SoftNavigationHeuristics:mode/advanced_paint_attribution te gebruiken bij het starten van Chrome.

Websites die dit willen inschakelen zodat al hun bezoekers de impact kunnen zien, kunnen een proefversie van Origin inschakelen in Chrome 139. Deze kan worden ingeschakeld door zich aan te melden voor de proefversie en een meta-element met de proeftoken van Origin in de HTML- of HTTP-header op te nemen. Zie het bericht 'Aan de slag met proefversies van Origin' voor meer informatie.

Website-eigenaren kunnen ervoor kiezen om de origin trial op hun pagina's op te nemen voor alle gebruikers, of slechts voor een deel van de gebruikers. Houd rekening met de voorgaande implicaties voor de manier waarop dit de rapportage van uw statistieken beïnvloedt, vooral als u deze origin trial voor een groot deel van uw gebruikers inschakelt. Houd er rekening mee dat CrUX de statistieken op de bestaande manier blijft rapporteren, ongeacht deze soft navigation-instelling, en dus niet wordt beïnvloed door deze implicaties. Origin trials zijn ook beperkt tot het inschakelen van experimentele functies voor maximaal 0,5% van alle pagina's in Chrome, gemiddeld over 14 dagen. Dit zou echter alleen een probleem moeten zijn voor zeer grote websites.

Hoe kan ik zachte navigaties meten?

Zodra het experiment met zachte navigatie is ingeschakeld, worden de statistieken gerapporteerd via de PerformanceObserver API, net als andere statistieken. Er zijn echter enkele extra overwegingen waarmee rekening moet worden gehouden bij het gebruik van deze statistieken.

Zachte navigaties rapporteren

U kunt een PerformanceObserver gebruiken om zachte navigatie te observeren. Hieronder volgt een voorbeeld van een codefragment dat zachte navigatie-items registreert in de console, inclusief eerdere zachte navigaties op deze pagina met behulp van de buffered optie:

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

Dit kan worden gebruikt om de volledige paginastatistieken voor de vorige navigatie vast te leggen.

Rapporteer de statistieken tegen de juiste URL

Omdat zachte navigatie pas zichtbaar is nadat deze heeft plaatsgevonden, moeten sommige statistieken na deze gebeurtenis definitief worden gemaakt en vervolgens worden gerapporteerd voor de vorige URL. De huidige URL weerspiegelt nu namelijk de bijgewerkte URL voor de nieuwe pagina.

Het kenmerk navigationId van de betreffende PerformanceEntry kan worden gebruikt om de gebeurtenis te koppelen aan de juiste URL. Dit kan worden opgezocht met de PerformanceEntry API :

const softNavEntry =
  performance.getEntriesByType('soft-navigation').filter(
    (entry) => entry.navigationId === navigationId
  )[0];
const hardNavEntry = performance.getEntriesByType('navigation')[0];
const navEntry = softNavEntry || hardNavEntry;
const pageUrl = navEntry?.name;

Deze pageUrl moet worden gebruikt om de statistieken te rapporteren voor de juiste URL, in plaats van de huidige URL die in het verleden is gebruikt.

De startTime van zachte navigatie verkrijgen

De starttijd van de navigatie kan op een soortgelijke manier worden verkregen:

const softNavEntry =
  performance.getEntriesByType('soft-navigation').filter(
    (entry) => entry.navigationId === navigationId
  )[0];
const hardNavEntry = performance.getEntriesByType('navigation')[0];
const navEntry = softNavEntry || hardNavEntry;
const startTime = navEntry?.startTime;

De startTime is het tijdstip van de eerste interactie (bijvoorbeeld het klikken op een knop) die de zachte navigatie start.

Alle prestatietimings, inclusief die voor zachte navigatie, worden gerapporteerd als een tijd vanaf de initiële "harde" paginanavigatietijd. Daarom is de starttijd van de zachte navigatie nodig om de laadtijden van de zachte navigatie (bijvoorbeeld LCP) te baseren, relatief ten opzichte van deze zachte navigatietijd.

Meet Core Web Vitals per zachte navigatie

Om zachte navigatiemetrische gegevens op te nemen, moet u includeSoftNavigationObservations: true opnemen in de observe van uw prestatieobservator.

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('Layout Shift time:', entry);
  }
}).observe({type: 'layout-shift', buffered: true, includeSoftNavigationObservations: true});

Met de laatste wijzigingen in de API is de vlag includeSoftNavigationObservations niet langer nodig en deze wordt waarschijnlijk in de toekomst verwijderd. Voorlopig is deze expliciete opt-in op het niveau van de prestatie-observator echter nodig naast het inschakelen van de functie voor zachte navigatie in Chrome .

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 interaction-contentful-paint nemen en de bijbehorende starttijd van de zachte navigatie aftrekken, zoals eerder beschreven, om een timing te krijgen die relatief is aan de zachte navigatie. Bijvoorbeeld, voor LCP:

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    const softNavEntry =
      performance.getEntriesByType('soft-navigation').filter(
        (navEntry) => navEntry.navigationId === entry.navigationId
      )[0];
    const hardNavEntry = performance.getEntriesByType('navigation')[0];
    const navEntry = softNavEntry || hardNavEntry;
    const startTime = navEntry?.startTime;
    console.log('LCP time:', entry.startTime - startTime);
  }
}).observe({type: 'interaction-contentful-paint', buffered: true, includeSoftNavigationObservations: true});

Sommige statistieken worden traditioneel gemeten gedurende de gehele levensduur van de pagina: LCP kan bijvoorbeeld veranderen totdat er een interactie plaatsvindt. CLS en INP kunnen worden bijgewerkt totdat de pagina wordt verlaten. Daarom kan het nodig zijn dat elke "navigatie" (inclusief de oorspronkelijke navigatie) de statistieken van de vorige pagina finaliseert bij elke nieuwe zachte navigatie. Dit betekent dat de initiële "harde" navigatiestatistieken mogelijk eerder dan gebruikelijk worden gefinaliseerd.

Op dezelfde manier moeten bij het meten van de statistieken voor de nieuwe zachte navigatie van deze lang bestaande statistieken de statistieken worden 'gereset' of 'opnieuw geïnitialiseerd' en behandeld als nieuwe statistieken, zonder dat de waarden die zijn ingesteld voor eerdere 'pagina's' worden onthouden.

Hoe moet inhoud die tussen navigaties hetzelfde blijft, worden behandeld?

De LCP voor zachte navigatie (berekend vanuit interaction-contentful-paint ) meet alleen nieuwe verfsoorten. Dit kan resulteren in een andere LCP, bijvoorbeeld van een koude lading van die zachte navigatie naar een zachte lading.

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

Zoals dit voorbeeld laat zien, kan het LCP-element voor de zachte navigatie anders worden gerapporteerd, afhankelijk van hoe de pagina wordt geladen. Dit is vergelijkbaar met het laden van een pagina met een ankerkoppeling verderop op de pagina, wat kan resulteren in een ander LCP-element.

Hoe meet je TTFB?

De tijd tot de eerste byte (TTFB) voor het laden van een conventionele pagina is de tijd waarop de eerste bytes van de oorspronkelijke aanvraag worden geretourneerd.

Voor zachte navigatie is dit een lastigere vraag. Moeten we het eerste verzoek voor de nieuwe pagina meten? Wat als alle content al in de app staat en er geen aanvullende verzoeken zijn? Wat als dat verzoek vooraf wordt gedaan met een prefetch? Wat als een verzoek vanuit gebruikersperspectief niets met de zachte navigatie te maken heeft (bijvoorbeeld een analytics-verzoek)?

Een eenvoudigere methode is om een TTFB van 0 te rapporteren voor zachte navigatie, op een vergelijkbare manier als we aanbevelen voor back-forward cache -herstel. Dit is de methode die de web-vitals bibliotheek gebruikt voor zachte navigatie.

In de toekomst ondersteunen we mogelijk nauwkeurigere manieren om te bepalen welk verzoek het "navigatieverzoek" van de soft navigation is en kunnen we nauwkeurigere TTFB-metingen uitvoeren. Maar dat maakt geen deel uit van de huidige implementatie.

Hoe meet je zowel oud als nieuw?

Tijdens dit experiment wordt aanbevolen om uw Core Web Vitals op de huidige manier te blijven meten, op basis van 'harde' paginanavigaties, zodat deze overeenkomen met wat CrUX meet en rapporteert als de officiële dataset van het Core Web Vitals-initiatief.

Daarnaast moeten ook zachte navigaties worden gemeten, zodat u kunt zien hoe deze in de toekomst gemeten kunnen worden en om u de mogelijkheid te geven feedback te geven aan het Chrome-team over hoe deze implementatie in de praktijk werkt. Dit helpt u en het Chrome-team bij het vormgeven van de API in de toekomst.

Voor LCP betekent dit dat alleen de items largest-contentful-paint voor de oude manier worden meegenomen, en dat voor de nieuwe manier zowel de items largest-contentful-paint als de items interaction-contentful-paint .

Voor CLS en INP betekent dit dat deze worden gemeten over de gehele levenscyclus van de pagina, zoals ook op de oude manier het geval was. Vervolgens wordt de tijdlijn afzonderlijk opgesplitst door middel van zachte navigatie, zodat voor de nieuwe manier afzonderlijke CLS- en INP-waarden worden gemeten.

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

De eenvoudigste manier om rekening te houden met alle nuances is door gebruik te maken van de web-vitals JavaScript-bibliotheek, die experimentele ondersteuning biedt voor soft navigation in een aparte soft-navs branch (die ook beschikbaar is op npm en unpkg ). Dit kan op de volgende manier worden gemeten (waarbij doTraditionalProcessing en doSoftNavProcessing worden vervangen, indien van toepassing):

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

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});

Zorg ervoor dat de statistieken worden gerapporteerd voor de juiste URL , zoals eerder aangegeven .

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

Metrisch Details
TTFB Gerapporteerd als 0.
FCP Alleen de eerste FCP voor de pagina wordt gerapporteerd.
LCP Het tijdstip van de volgende grootste contentvolle paint, relatief ten opzichte van de starttijd van de softnavigatie. Bestaande paints van de vorige navigatie worden niet meegenomen. Daarom is de LCP >= 0. Zoals gebruikelijk wordt dit gerapporteerd bij een interactie of wanneer de pagina op de achtergrond staat, omdat alleen dan de LCP kan worden gefinaliseerd.
CLS Het grootste venster met verschuivingen tussen de navigatietijden. Zoals gebruikelijk gebeurt dit wanneer de pagina op de achtergrond staat, omdat de CLS dan pas kan worden afgerond. Een waarde van 0 wordt gerapporteerd als er geen verschuivingen zijn.
INP De INP tussen de navigatietijden. Zoals gebruikelijk wordt dit gerapporteerd bij een interactie of wanneer de pagina op de achtergrond staat, omdat alleen dan de INP kan worden gefinaliseerd. Een waarde van 0 wordt niet gerapporteerd als er geen interacties zijn.

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

Dit soft navigation-experiment is precies dat: een experiment. We willen de heuristiek evalueren en kijken of deze de gebruikerservaring beter weerspiegelt voordat we beslissen of dit wordt geïntegreerd in het Core Web Vitals-initiatief. We zijn erg enthousiast over de mogelijkheid van dit experiment, maar kunnen geen garanties bieden of en wanneer dit de huidige metingen zal vervangen.

We waarderen de feedback van webontwikkelaars over het experiment, de gebruikte heuristiek en of u vindt dat dit de ervaring beter weerspiegelt. De GitHub-repository voor soft navigation is de beste plek om die feedback te geven, maar individuele bugs in de implementatie hiervan door Chrome moeten worden gemeld in de Chrome Issue Tracker .

Hoe worden zachte navigaties gerapporteerd in CrUX?

Hoe zachte navigaties precies in CrUX zullen worden gerapporteerd, mocht dit experiment slagen, moet nog worden bepaald. Het is niet per se vanzelfsprekend dat ze op dezelfde manier worden behandeld als de huidige "harde" navigaties.

Op sommige webpagina's zijn soft navigations vrijwel identiek aan het laden van een volledige pagina voor de gebruiker en is het gebruik van Single Page Application-technologie slechts een implementatiedetail. Op andere pagina's lijken ze meer op het gedeeltelijk laden van extra content.

Daarom kunnen we ervoor kiezen om deze soft navigations apart te rapporteren in CrUX, of ze te wegen bij het berekenen van de Core Web Vitals voor een bepaalde pagina of groep pagina's. We kunnen soft navigation die gedeeltelijk geladen is mogelijk ook volledig uitsluiten, naarmate de heuristiek zich verder ontwikkelt.

Het team concentreert zich op de heuristische en technische implementatie, waarmee we het succes van dit experiment kunnen beoordelen. Daarom is er op deze fronten nog geen beslissing genomen.

Feedback

We zijn op zoek naar feedback over dit experiment op de volgende plekken:

Wijzigingslogboek

Omdat deze API nog in de experimentele fase zit, worden er een aantal wijzigingen doorgevoerd, meer dan bij stabiele API's. Raadpleeg het changelog van de Soft Navigation Heuristics voor meer informatie.

Conclusie

Het experiment met soft navigation is een veelbelovende manier om te zien hoe het Core Web Vitals-initiatief zich zou kunnen ontwikkelen om een gemeenschappelijk patroon op het moderne web te meten dat in onze statistieken ontbreekt. Hoewel dit experiment nog in de kinderschoenen staat – en er nog veel te doen is – is het een belangrijke stap om de tot nu toe geboekte vooruitgang beschikbaar te stellen aan de bredere webcommunity om ermee te experimenteren. Het verzamelen van feedback is een ander cruciaal onderdeel van het experiment. Daarom moedigen we geïnteresseerden in deze ontwikkeling van harte aan om deze kans te grijpen om de API vorm te geven en ervoor te zorgen dat deze representatief is voor wat we 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 inspanningen aan deze API.