Experimenteren met het meten van zachte navigatie

Barry Pollard

Michal Mocny

Gepubliceerd: 1 februari 2023, Laatst bijgewerkt: 30 maart 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 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 gestandaardiseerde definitie 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 de API op basis van feedback van ontwikkelaars tijdens de laatste origin-testfase op verschillende manieren verbeterd en vragen ontwikkelaars nu om de nieuwste versie te testen en feedback te geven voordat deze wordt gelanceerd. We zijn er vrij zeker van hoe de API er na deze iteraties voor staat en streven ernaar de API later dit jaar te lanceren, afhankelijk van de feedback op deze laatste origin-testfase.

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 kunnen deze heuristieken leiden tot vals-positieven (waarbij gebruikers niet echt zouden denken dat er een "navigatie" heeft plaatsgevonden) of vals-negatieven (waarbij de gebruiker wel denkt dat er een "navigatie" heeft plaatsgevonden, ondanks dat niet aan de criteria is voldaan). We stellen feedback over de heuristieken op het gebied van soft navigation-specificaties zeer op prijs.

DevTools-ondersteuning voor soft navigation

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

Je ziet markeringen voor soft navigation 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 het experiment met soft navigation 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 heuristieken voor zachte navigatie zijn 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. Dit kan worden gebruikt om de Largest Contentful Paint (LCP) te meten voor soft navigations wanneer de interactie een soft navigation genereert.
• 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 largestInteractionContentfulPaint -item met daarin het grootste interaction-contentful-paint item dat als onderdeel van de navigatie wordt gegenereerd. Dit kan vervolgens worden gebruikt als het initiële LCP voor die navigatie, en dat LCP kan vervolgens worden bijgewerkt naarmate er meer interaction-contentful-paint items voor die interactie worden waargenomen.
• Mogelijk hebben sommige interaction-contentful-paint vermeldingen plaatsgevonden vóór de soft navigation (als de URL-update pas na die paints plaatsvindt). In deze gevallen voorkomt de grootste largestInteractionContentfulPaint vermelding dat er gebufferd en teruggekeken hoeft te worden naar oude vermeldingen. Merk op dat de largestInteractionContentfulPaint een exacte kopie is van de largest interaction-contentful-paint vermelding, waardoor die vermelding de vorige navigationId heeft gebruikt, aangezien dat het moment van de paint was. Deze paints moeten echter 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 navigation om deze uit te sluiten.

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 API biedt een gestandaardiseerde maatstaf voor wanneer dit gebeurt, ongeacht de gebruikte onderliggende technologie.
• Het item largest-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 en het laden van de pagina kan worden gemeten zoals altijd.
• De nieuwe entry interaction-contentful-paint die wordt gegenereerd door interacties kan worden gebruikt om LCP te meten voor zachte navigaties, maar er zijn enkele aandachtspunten voor het gebruik van deze entry die we in dit artikel zullen bespreken.
• Houd er rekening mee dat niet alle gebruikers deze soft-navigatie-API 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.
• Aangezien dit een experimentele nieuwe functie is die niet standaard is ingeschakeld, moeten websites deze functie testen op onbedoelde bijwerkingen.

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?

Zachte navigatie is niet standaard ingeschakeld in Chrome, maar kan worden uitgeprobeerd 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.

Voor websites die dit voor al hun bezoekers zichtbaar willen maken, is er een Origin-proefversie beschikbaar vanaf Chrome 147. Deze kan worden geactiveerd door je aan te melden voor de proefversie en een meta-element met het Origin-proeftoken in de HTML- of HTTP-header op te nemen. Zie het bericht ' Aan de slag met Origin-proeven ' voor meer informatie.

Website-eigenaren kunnen ervoor kiezen om de Origin-proefversie op hun pagina's voor alle gebruikers of slechts voor een subset van gebruikers in te schakelen. Houd rekening met de implicaties in het voorgaande gedeelte over hoe dit de rapportage van uw statistieken beïnvloedt, met name als u deze Origin-proefversie voor een groot deel van uw gebruikers inschakelt. CruX blijft de statistieken op de bestaande manier rapporteren, ongeacht deze soft navigation-instelling, en wordt dus niet beïnvloed door deze implicaties. Het is ook belangrijk om te weten dat Origin-proeven beperkt zijn tot het inschakelen van experimentele functies op maximaal 0,5% van alle Chrome-paginaweergaven (gemiddeld over 14 dagen), maar dit zou alleen een probleem moeten zijn voor zeer grote websites.

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 het experiment met soft navigations is ingeschakeld, worden de meetwaarden gerapporteerd via de PerformanceObserver API, net als bij andere meetwaarden. Er zijn echter enkele extra aandachtspunten waarmee rekening moet worden gehouden bij deze meetwaarden.

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 attribuut van de betreffende soft-navigation -ingang 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). Deze referentie 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;

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 largestInteractionContentfulPaint -vermelding van de soft-navigation vermeldingen te verwerken, zodat interaction-contentful-paint vermeldingen 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 de belangrijkste webstatistieken te meten, luister je naar soft-navigation items en reset je de statistieken zodra deze binnenkomen. FCP kan worden gegenereerd op basis van de presentationTime en LCP kan worden geïnitialiseerd op de largestInteractionContentfulPaint . 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 en navigationId kunnen 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?

Tijdens dit experiment wordt aanbevolen om uw Core Web Vitals op de huidige manier te blijven meten, gebaseerd op "harde" paginanavigatie, aangezien de nieuwe implementatie mogelijk problemen of wijzigingen kan vertonen voordat deze definitief wordt uitgebracht. Dit komt ook overeen met wat CruUX momenteel meet (hierover later meer).

Naast deze aspecten moeten ook soft navigation-functies worden gemeten, zodat u kunt zien hoe deze in de toekomst gemeten zouden kunnen worden en u de mogelijkheid krijgt om feedback te geven aan het Chrome-team over hoe deze implementatie in de praktijk werkt. Dit zal u en het Chrome-team helpen om de API in de toekomst vorm te geven.

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.

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:

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

We willen de heuristieken evalueren en kijken of ze de gebruikerservaring nauwkeuriger weergeven voordat we een beslissing nemen over de integratie ervan in het Core Web Vitals-initiatief. Het uiteindelijke doel is om een ​​manier te bieden om prestaties beter te meten aan de hand van de ervaringen van echte gebruikers. Dus ja, het is de bedoeling om deze op te nemen in de Core Web Vitals-metingen, zoals weergegeven door alle tools, mocht dit experiment succesvol blijken.

We stellen de feedback van webontwikkelaars over het experiment, de gebruikte heuristieken en de vraag of het 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 zachte navigaties precies in CruX zullen worden gerapporteerd, mocht dit experiment succesvol zijn, moet nog worden bepaald. Het is niet vanzelfsprekend dat ze op dezelfde manier zullen worden behandeld als de huidige "harde" navigaties.

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

Daarom kunnen we ervoor kiezen om deze soft navigations apart te rapporteren in CruX, of ze wellicht een gewicht toe te kennen bij het berekenen van de Core Web Vitals voor een bepaalde pagina of groep pagina's. Naarmate de heuristiek zich verder ontwikkelt, kunnen we soft navigations met gedeeltelijke laadtijden mogelijk zelfs volledig uitsluiten.

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

Feedback

We vragen actief om feedback op dit experiment op de volgende plekken:

• Feedback over de API kan als issues op GitHub worden gemeld.
• Eventuele bugs in de Chromium-implementatie moeten worden gemeld op de bugtracker van Chrome , tenzij dit al een van de bekende problemen is.
• Algemene feedback over Web Vitals kan worden gedeeld via web-vitals-feedback@googlegroups.com .

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

Omdat deze API zich nog in de experimentele fase bevindt, worden er meer wijzigingen in aangebracht dan bij stabiele API's. Raadpleeg de changelog van Soft Navigation Heuristics voor meer informatie.

Conclusie

Het experiment met soft navigations is een veelbelovende benadering van hoe het Core Web Vitals-initiatief zich zou kunnen ontwikkelen om een ​​veelvoorkomend patroon op het moderne web te meten dat momenteel ontbreekt in onze statistieken. Hoewel dit experiment zich nog in een vroeg stadium bevindt – en er nog veel werk aan de winkel is – is het een belangrijke stap om de tot nu toe behaalde resultaten beschikbaar te stellen aan de bredere webgemeenschap om mee te experimenteren. Het verzamelen van feedback is een ander cruciaal onderdeel van dit experiment. Daarom moedigen we geïnteresseerden ten zeerste aan om deze kans te grijpen en mee te denken over de API, zodat deze representatief is 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.