Nieuwe Soft Navigations oorsprongsproef

Barry Pollard
Michal Mocny

Gepubliceerd: 31 juli 2025

Chrome introduceert vanaf versie 139 een nieuwe origin trial voor de Soft Navigations API, waarmee we eerder al experimenteerden . Deze origin trial stelt websites in staat de API op hun site te testen met echte gebruikers, zodat ze de API in de praktijk kunnen testen en feedback aan het Chrome-team kunnen geven.

Wat zijn soft navigations?

Bij soft navigation onderschept JavaScript een navigatie (bijvoorbeeld een klik op een link) en werkt de inhoud van de bestaande pagina bij, in plaats van een nieuwe pagina te laden en vervolgens de URL in de adresbalk aan te passen (met een geschiedenisstatus om soft navigations heen en weer mogelijk te maken). Voor de gebruiker ziet dit er hetzelfde uit als conventionele navigatie, maar voor de browser blijft het dezelfde pagina.

Waarom de Soft Navigation API nodig is

De Soft Navigations API is een voorgestelde API voor het op heuristiek detecteren van zogenaamde "soft navigations" zoals die worden gebruikt door Single Page Application (SPA)-websites. Omdat er bij een soft navigation geen daadwerkelijke paginanavigatie plaatsvindt, moeten bepaalde acties die normaal gesproken bij een navigatie zouden plaatsvinden, handmatig worden afgehandeld met JavaScript. Sommige acties, zoals het beheren 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 navigations te observeren. Hoewel de JavaScript-code die de soft navigation initieert (meestal een JavaScript-framework) weet wanneer een navigatie plaatsvindt, zijn andere JavaScript-code en de browser zelf zich daar niet van bewust.

Kernwebgegevens en SPA's

Een van de belangrijkste drijfveren achter de Soft Navigation API is het meten van essentiële webstatistieken voor single-page applications (SPA's). Deze essentiële webstatistieken worden gemeten door zowel de browser (en weergegeven in tools zoals het Chrome User Experience Report ) als door Real User Monitoring (RUM) JavaScript-bibliotheken.

JavaScript-frameworks kunnen bepaalde 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 elke tijdsperiode kunnen worden gemeten om de INP- en CLS-waarden te berekenen. Omdat de browser echter Largest Contentful Paint (LCP) rapporteert en definitief vaststelt op basis van paginanavigatie en interacties, hebben JavaScript-frameworks geen inzicht in iets anders dan de initiële laadprestaties van SPA's.

Hoe de Soft Navigation API het mogelijk maakt om essentiële webstatistieken voor SPA's te meten.

De eerste versie van de Soft Navigation API koppelde de heuristieken voor softnavigatie aan het resetten van LCP. Na de reset kan LCP opnieuw worden gebruikt voor softnavigatie bij het laden van nieuwe content, waardoor deze parameter voor softnavigatie kan worden gemeten.

Deze nieuwste versie hanteert een andere aanpak en scheidt deze concepten in de Soft Navigation API en een nieuwe prestatie-indicator voor interactie naar contentful paint. De indicator interaction-contentful-paint meet de "contentful paint" na interacties. Momenteel wordt dit alleen voor soft navigations gebruikt, maar als deze indicator voor alle interacties wordt ingeschakeld, opent dit andere potentiële gebruiksscenario's naast LCP.

De API heeft ook de prestatiegegevens voor largest-contentful-paint , interaction-contentful-paint , event-timing en layout-shift uitgebreid met een identificatiecode voor de navigatie waar de meting betrekking op heeft. Prestatiegegevens worden gegenereerd na de gebeurtenis die ze meten, meestal tijdens inactiviteit. Dit betekent dat de URL vaak al is gewijzigd tegen de tijd dat de prestatiegegevens worden gegenereerd. Door de navigatie aan de meting toe te voegen, wordt het veel eenvoudiger om Core Web Vitals voor de betreffende URL te meten zonder de tijden van de prestatiegegevens te hoeven afstemmen op de tijden van de soft-navigatiegegevens.

Waarom een ​​heuristiek?

De Soft Navigation API beschouwt een soft navigation als aan de volgende voorwaarden is voldaan:

  • Er vindt een gebruikersinteractie plaats (URL-updates zonder gebruikersinteractie tellen niet mee).
  • … wat resulteert in een DOM-wijziging en een paint-actie.
  • … en er vindt een URL-update plaats
  • URL-update, inclusief wijziging van de geschiedenis.

De API hanteert deze heuristische aanpak in plaats van een JavaScript-framework toe te staan ​​een 'soft navigation' te 'genereren' of voort te bouwen op de Navigation API. Dit zorgt voor een consistent begrip van wat een soft navigation inhoudt, ongeacht het framework of hoe een ontwikkelaar het gebruikt.

Frameworks of ontwikkelaars kunnen de URL voor een soft navigation bijwerken, zelfs zonder gebruikersinteractie of een DOM-update die wij als navigatie zouden beschouwen. Ze kunnen de URL ook op verschillende momenten bijwerken: aan het begin van de interactie, pas aan het einde wanneer deze is voltooid, 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 canonieke 'heuristieken' (met uw feedback uit deze oorspronkelijke proef) waarmee we Core Web Vitals voor zachte navigatie op grote schaal kunnen meten en dergelijke metingen op grote schaal vergelijkbaar kunnen maken.

Frameworks en ontwikkelaars kunnen de heuristieken van de Soft Navigations API negeren en de onderliggende Event Timing, Layout Instability en Interaction to Contentful Paint API's gebruiken om naar eigen inzicht aanvullende prestatiemetingen uit te voeren. Wij raden echter aan om Core Web Vitals te gebruiken in combinatie met de heuristiek, zodat metingen over meerdere websites mogelijk zijn.

Hulp nodig bij het testen van de Soft Navigation API

We hebben hulp nodig bij het testen van de Soft Navigations API om te controleren of de heuristiek correct overeenkomt met uw verwachtingen over wanneer er sprake is van een soft navigation. Zijn er gevallen waarin de API geen soft navigations rapporteert, terwijl u die wel als zodanig beschouwt? Of, omgekeerd, rapporteert de API te vaak navigaties die u niet als soft navigations beschouwt?

Voorbeelden van situaties die problemen kunnen veroorzaken, zijn onder andere het bijwerken van een URL met replaceState in plaats van het toevoegen van een geschiedenis, of navigatie die niet door de gebruiker is geïnitieerd (bijvoorbeeld uitloggen na een time-out). Beide gevallen worden verklaard doordat ze niet overeenkomen met de heuristieken. Het Chrome-team vindt het prima om deze gevallen niet te implementeren, maar we willen graag van webontwikkelaars horen of zij het hiermee eens zijn. We zijn met name geïnteresseerd in gevallen waarin de heuristieken wel lijken te worden voldaan, maar de API de soft navigation toch niet herkent.

Daarnaast willen we onderzoeken of deze API, en de nieuwe primitieve 'Interaction to Contentful Paint', tegemoetkomt aan de primaire use case, namelijk het meten van de Core Web Vitals voor SPA's.

We willen dat de API zo nuttig mogelijk is, en dat is veel gemakkelijker te bereiken voordat deze gelanceerd is en websites afhankelijk worden van een implementatie. Daarom vragen we SPA-ontwikkelaars en iedereen die geïnteresseerd is in het meten van webprestaties voor deze sites om deze API uit te proberen en ons te laten weten wat hun ervaringen ermee zijn.

Hoe te testen

De API kan lokaal worden getest met Chrome-vlaggen of commandoregelopties . 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 over hoe u de Core Web Vitals kunt meten . Daarnaast is er een experimentele versie van de web-vitals-bibliotheek met soft navigation beschikbaar.

Feedback

We vragen actief om feedback op dit experiment 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.