Nieuwe Soft Navigations oorsprongsproef

Barry Pollard
Michal Mocny

Gepubliceerd: 31 juli 2025

Chrome lanceert een nieuwe proefversie van Chrome 139 voor de Soft Navigations API waarmee we eerder hebben geëxperimenteerd . Deze proefversie stelt sites in staat de API op hun site uit te proberen met echte gebruikers om de API in de praktijk te testen en het Chrome-team feedback te geven.

Wat zijn zachte navigaties?

Zachte navigatie is wanneer JavaScript een navigatie onderschept (bijvoorbeeld het klikken op een link) en de inhoud van de bestaande pagina bijwerkt, in plaats van een nieuwe pagina te laden en vervolgens de URL in de adresbalk bij te werken (met een historische status om zachte navigatie heen en weer te kunnen gebruiken). Voor de gebruiker zien deze er hetzelfde uit als conventionele navigaties, maar voor de browser is de pagina nog steeds de originele pagina.

Waarom de Soft Navigation API nodig is

De Soft Navigations API is een voorgestelde API die heuristiekgebaseerde detectie van zogenaamde "soft navigations" mogelijk maakt, zoals gebruikt door Single Page Application (SPA)-sites. Omdat er geen daadwerkelijke paginanavigatie plaatsvindt bij soft navigation, betekent dit dat bepaalde acties die normaal gesproken bij een navigatie zouden plaatsvinden, handmatig moeten worden beheerd met JavaScript. Sommige acties, zoals het beheer van de navigatiegeschiedenis, zijn mogelijk met de huidige API's. Andere acties, zoals het meten van Core Web Vitals , zijn echter niet mogelijk voor deze navigaties.

De Soft Navigation API maakt het mogelijk om soft navigation te observeren. De JavaScript-code die de soft navigation initieert (meestal een JavaScript-framework) weet wanneer er een navigatie plaatsvindt, maar andere JavaScript-code en de browser zelf weten dat niet.

Core Web Vitals en SPA's

Een van de belangrijkste drijfveren van de Soft Navigation API is het meten van Core Web Vitals voor SPA's. Core Web Vitals worden gemeten door zowel de browser (om zichtbaar te worden in tools zoals het Chrome User Experience Report ) als door Real User Monitoring (RUM) JavaScript-bibliotheken.

JavaScript-frameworks kunnen sommige aspecten van de Core Web Vitals meten. Met name Interaction to Next Paint (INP) en Cumulative Layout Shift (CLS) zijn gebaseerd op primitieven (respectievelijk de Event Timing API en de Layout Instability API ) die over een willekeurige tijdsperiode kunnen worden gemeten om de INP- en CLS-metrieken te berekenen. Andere metrieken, zoals Largest Contentful Paint (LCP), worden echter alleen door de browser gegenereerd op basis van paginanavigatie en worden definitief gemaakt na interactie .

Hoe de Soft Navigation API het meten van Core Web Vitals voor SPA's mogelijk maakt

De eerste iteratie van de Soft Navigation API koppelde de heuristiek voor soft navigation aan een reset van de LCP. Na het resetten kan de LCP opnieuw worden uitgezonden voor soft navigations voor nieuwe contentful paint, waardoor deze metriek voor soft navigations kan worden gemeten.

Deze nieuwste versie hanteert een andere aanpak en koppelt deze concepten los in de Soft Navigation API en een nieuwe prestatie-item Interaction to Contentful Paint. Het interaction-contentful-paint meet de "contentful paint" na interacties. Voorlopig wordt dit alleen weergegeven voor soft navigation, maar dit opent andere potentiële use cases dan alleen LCP indien ingeschakeld voor alle interacties.

De API heeft ook elk van de prestatie-items largest-contentful-paint , interaction-contentful-paint , event-timing en layout-shift uitgebreid met een identificatiecode voor de navigatie waarop het item betrekking heeft. Prestatie-items worden gegenereerd na de gebeurtenis die ze meten, meestal tijdens inactiviteit. Dit betekent dat de URL vaak al is gewijzigd tegen de tijd dat het prestatie-item wordt gegenereerd. Door de navigatie aan het item toe te voegen, wordt het veel eenvoudiger om Core Web Vitals voor de gegeven URL te meten zonder de tijden van prestatie-items te hoeven vergelijken met de tijden van soft navigation.

Waarom een heuristiek?

De Soft Navigation API beschouwt zachte navigatie wanneer het volgende gebeurt:

  • Er vindt een interactie plaats op basis van de gebruiker (URL-updates zonder gebruikersinteractie tellen niet mee)
  • … wat resulteert in een DOM-modificatie en een verflaag
  • … en er vindt een URL-update plaats
  • URL-update, inclusief een wijziging in de geschiedenis.

De API hanteert deze heuristische benadering in plaats van een JavaScript-framework toe te staan een zachte navigatie 'uit te zenden' of te bouwen op de Navigatie-API. Dit zorgt namelijk voor een consistent begrip van wat een zachte navigatie is, ongeacht het framework of hoe een ontwikkelaar het gebruikt.

Frameworks of ontwikkelaars kunnen de URL voor een zachte navigatie zelfs bijwerken zonder gebruikersinteractie of een DOM-update die we beschouwen als wat een gebruiker als navigatie zou zien. Ze kunnen de URL ook op verschillende tijdstippen bijwerken: aan het begin van de interactie of pas aan het einde wanneer deze voltooid is, of in elke tussenliggende fase.

In plaats van te vertrouwen op frameworkkeuzes, zorgt het inbouwen van de detectie van zachte navigatie in de browser voor het vaststellen van canonieke 'heuristieken' (met uw feedback uit deze oorspronkelijke proef). Hiermee kunnen we Core Web Vitals voor zachte navigatie op grote schaal meten en dergelijke metingen op grote schaal vergelijkbaar maken.

Frameworks en ontwikkelaars kunnen de heuristiek van de Soft Navigations API ook negeren en de onderliggende Event Timing, Layout Instability en Interaction to Contentful Paint API's gebruiken om desgewenst aanvullende prestatiegegevens te meten. Wij raden echter aan dat Core Web Vitals de heuristiek gebruikt om metingen over meerdere sites heen mogelijk te maken.

Hulp nodig bij het testen van de Soft Navigation API

We hebben hulp nodig bij het testen van de Soft Navigations API om te testen of de heuristiek correct overeenkomt met uw verwachtingen over wanneer een soft navigation heeft plaatsgevonden. Zijn er gevallen waarin de API geen soft navigations rapporteert terwijl u denkt dat ze wel hebben plaatsgevonden? Of herhaalt de API juist navigaties die u niet als soft navigations beschouwt?

Voorbeelden die we hebben gezien die problemen veroorzaken, zijn onder andere wanneer een URL wordt bijgewerkt met replaceState in plaats van een geschiedenis toe te voegen, of wanneer er een navigatie plaatsvindt die niet door de gebruiker is geïnitieerd (bijvoorbeeld een uitlog na een time-out). Beide gevallen worden verklaard door het feit dat de heuristiek niet overeenkomt en het Chrome-team vindt het prima om deze niet op te nemen, maar we horen graag van webontwikkelaars of ze hiermee akkoord gaan. En we willen vooral graag horen over gevallen waarin de heuristiek wel lijkt te voldoen, maar de API de soft navigation nog steeds niet herkent.

Daarnaast willen we onderzoeken of deze API en de nieuwe Interaction to Contentful Paint-primitive voldoen aan het primaire gebruiksscenario van het meten van Core Web Vitals voor SPA's.

We willen dat de API zo nuttig mogelijk is en dat is veel gemakkelijker te realiseren voordat deze wordt gelanceerd en sites afhankelijk worden van een implementatie. Daarom vragen we SPA-ontwikkelaars en geïnteresseerden in het meten van de webprestaties van deze sites om deze API uit te proberen en ons te laten weten hoe deze voor u werkt.

Hoe te testen

De API kan lokaal worden getest met Chrome-vlaggen of opdrachtregelopties . Daarnaast kan deze in het veld worden getest met de Origin Trial .

Raadpleeg onze documentatie of de GitHub-repository voor meer technische details over de API, en met name hoe u de Core Web Vitals kunt meten . Daarnaast is er een experimentele softnavigatieversie van de webvitals-bibliotheek beschikbaar.

Feedback

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

Als u twijfelt, hoeft u zich geen zorgen te maken. We horen liever de feedback van beide kanten en zullen de problemen op beide plekken onderzoeken en doorverwijzen naar de juiste locatie.