Experimenteren met het meten van zachte navigatie

Barry Pollard

Yoav Weiss

Update augustus 2024: Het tweede herkomsttraject van Soft Navigations eindigde op 29 mei. Het Chrome-team neemt de tijd om de experimentfeedback te bekijken en de volgende stappen voor deze API te overwegen. We willen een aantal nauwkeurigheidsproblemen aanpakken en zijn van mening dat er nog een origin-proefversie nodig zal zijn voordat de functie klaar is om verder te gaan. In de tussentijd kunnen ontwikkelaars nog steeds met de functie experimenteren door chrome://flags/#enable-experimental-web-platform-features in te schakelen.

Sinds de lancering heeft het Core Web Vitals-initiatief geprobeerd de daadwerkelijke gebruikerservaring van een website te meten, in plaats van technische details achter hoe een website wordt gemaakt of geladen. De drie Core Web Vitals-statistieken zijn gemaakt als gebruikersgerichte statistieken - een evolutie ten opzichte van bestaande technische statistieken zoals DOMContentLoaded of load die timings maten die vaak geen verband hielden met hoe gebruikers de prestaties van de pagina waarnamen. Daarom zou de technologie die wordt gebruikt om de site te bouwen geen invloed moeten hebben op de score, op voorwaarde dat de site goed presteert.

De realiteit is altijd een beetje lastiger dan het ideaal, en de populaire Single Page Application-architectuur is nooit volledig ondersteund door de Core Web Vitals-statistieken . In plaats van afzonderlijke, individuele webpagina's te laden terwijl de gebruiker over de site navigeert, gebruiken deze webapplicaties zogenaamde "zachte navigatie", waarbij de pagina-inhoud in plaats daarvan wordt gewijzigd door JavaScript. In deze toepassingen 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 Vorige en Volgende werken zoals de gebruiker zou verwachten.

Veel JavaScript-frameworks gebruiken dit model, maar elk op een andere manier. Omdat dit buiten wat de browser traditioneel onder een "pagina" verstaat, is het meten hiervan altijd moeilijk geweest: waar moet de grens worden getrokken tussen een interactie op de huidige pagina, versus het beschouwen van dit als een nieuwe pagina?

Het Chrome-team houdt zich al een tijdje met deze uitdaging bezig en wil een definitie standaardiseren van wat 'zachte navigatie' is, en hoe de Core Web Vitals hiervoor kunnen worden gemeten, op een vergelijkbare manier als waarop websites dit implementeren. in de conventionele architectuur met meerdere pagina's (MPA) worden gemeten. Hoewel het team zich nog in de beginfase bevindt, is het nu klaar om wat al is geïmplementeerd breder beschikbaar te maken voor sites om mee te experimenteren. Hierdoor kunnen sites feedback geven over de aanpak tot nu toe.

Wat is een zachte navigatie?

We hebben de volgende definitie van zachte navigatie bedacht:

• De navigatie wordt geïnitieerd door een gebruikersactie.
• De navigatie resulteert in een zichtbare URL-wijziging voor de gebruiker en een geschiedeniswijziging.
• De navigatie resulteert in een DOM-wijziging.

Voor sommige sites kunnen deze heuristieken leiden tot valse positieven (waarbij gebruikers niet echt zouden overwegen dat er een "navigatie" heeft plaatsgevonden) of valse negatieven (waarbij de gebruiker wel van mening is dat er een "navigatie" heeft plaatsgevonden ondanks dat deze niet aan deze criteria voldoet). We verwelkomen feedback over de heuristieken in de soft-navigatiespecificatierepository .

Hoe implementeert Chrome zachte navigatie?

Zodra de zachte navigatieheuristieken zijn ingeschakeld (meer hierover in de volgende sectie), zal Chrome de manier veranderen waarop het bepaalde prestatiestatistieken rapporteert:

• Er wordt een PerformanceTiming soft-navigation verzonden nadat elke zachte navigatie is gedetecteerd.
• De prestatie-API biedt toegang tot een timinginvoer soft-navigation , zoals uitgezonden door de PerformanceTiming soft-navigation .
• De First Paint (FP) , First Contentful Paint (FCP) en Largest Contentful Paint (LCP) -statistieken worden opnieuw ingesteld en opnieuw verzonden bij de volgende geschikte gebeurtenis hiervan. (Opmerking: FP en FCP zijn niet geïmplementeerd.)
• Er wordt een navigationId attribuut toegevoegd aan elk van de prestatietimings ( first-paint , first-contentful-paint , largest-contentful-paint , first-input-delay , event en layout-shift ) die overeenkomt met de navigatie-invoer waarmee de gebeurtenis verband hield to, waardoor Cumulatieve Layout Shift (CLS) en Interaction to Next Paint (INP) kunnen worden berekend.

Dankzij deze veranderingen kunnen de Core Web Vitals (en enkele van de bijbehorende diagnostische statistieken) per paginanavigatie worden gemeten, hoewel er enkele nuances zijn waarmee rekening moet worden gehouden.

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

Hier volgen enkele van de wijzigingen waarmee site-eigenaren rekening moeten houden nadat ze deze functie hebben ingeschakeld:

• Voor zachte navigatie kunnen aanvullende FP-, FCP- en LCP-gebeurtenissen opnieuw worden uitgezonden. Het Chrome User Experience Report (CrUX) negeert deze aanvullende waarden, maar dit kan van invloed zijn op de Real User Measurement (RUM)-monitoring op uw site. Neem contact op met uw RUM-leverancier als u zich zorgen maakt of dit van invloed zal zijn op de metingen. Zie het gedeelte over het meten van Core Web Vitals voor zachte navigatie .
• Het nieuwe (en optionele) navigationID kenmerk in uw prestatie-items moet mogelijk worden meegenomen in uw applicatiecode die deze items gebruikt.
• Alleen Chromium-gebaseerde browsers ondersteunen deze nieuwe modus. Hoewel veel van de nieuwere statistieken alleen beschikbaar zijn in Chromium-gebaseerde browsers, zijn sommige (FCP, LCP) beschikbaar in de andere browsers, en niet iedereen heeft mogelijk een upgrade naar de nieuwste versie van Chromium-gebaseerde browsers uitgevoerd. Houd er dus rekening mee dat sommige gebruikers mogelijk geen statistieken voor zachte navigatie rapporteren.
• Omdat het een experimentele nieuwe functie is die niet standaard is ingeschakeld, moeten sites deze functie testen om er zeker van te zijn dat er geen andere onbedoelde bijwerkingen optreden.

Voor meer informatie over het meten van de statistieken voor zachte navigatie raadpleegt u de sectie Kernwebvitaliteit per zachte navigatie meten .

Hoe schakel ik zachte navigatie in Chrome in?

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

Voor ontwikkelaars kan dit worden ingeschakeld door de Experimental Web Platform-functiesvlag in te schakelen op chrome://flags/#enable-experimental-web-platform-features of door de opdrachtregel --enable-experimental-web-platform-features te gebruiken argument bij het starten van Chrome.

Hoe kan ik zachte navigatie meten?

Zodra het zachte navigatie-experiment is ingeschakeld, rapporteren de statistieken zoals gewoonlijk met behulp van de PerformanceObserver API. Er zijn echter enkele extra overwegingen waarmee rekening moet worden gehouden bij deze statistieken.

Opmerking: Opmerking: FP en FCP worden nog niet gerapporteerd voor zachte navigatie .

Rapporteer zachte navigatie

U kunt een PerformanceObserver gebruiken om zachte navigatie te observeren. Hieronder volgt een voorbeeldcodefragment dat zachte navigatie-items in de console registreert, inclusief eerdere zachte navigatie 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 af te ronden.

Rapporteer de statistieken via de juiste URL

Omdat zachte navigatie pas zichtbaar is nadat deze heeft plaatsgevonden, moeten sommige statistieken bij deze gebeurtenis worden afgerond en vervolgens worden gerapporteerd voor de vorige URL, omdat de huidige URL nu de bijgewerkte URL voor de nieuwe pagina weergeeft.

Het navigationId kenmerk van de juiste PerformanceEntry kan worden gebruikt om de gebeurtenis terug 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 op basis van de juiste URL, in plaats van de huidige URL die ze in het verleden mogelijk hebben gebruikt.

Aan de startTime van zachte navigatie

De starttijd van de navigatie kan op soortgelijke wijze 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 een klik op een knop) die de zachte navigatie in gang zette.

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 metrische laadtijden van de zachte navigatie (bijvoorbeeld LCP) te baseren, in plaats daarvan ten opzichte van deze zachte navigatietijd.

Meet Core Web Vitals per zachte navigatie

Als u metrische gegevens voor zachte navigatie wilt opnemen, moet u includeSoftNavigationObservations: true opnemen in de observe van uw prestatiewaarnemer.

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

De extra vlag includeSoftNavigationObservations op de observe is nodig naast het inschakelen van de zachte navigatiefunctie in Chrome . Deze expliciete opt-in op het niveau van prestatiewaarnemers is om ervoor te zorgen dat bestaande prestatiewaarnemers niet verrast worden door deze extra vermeldingen , aangezien er met enkele aanvullende overwegingen rekening moet worden gehouden bij pogingen om Core Web Vitals te meten voor zachte navigatie.

De tijden worden nog steeds geretourneerd met betrekking tot de oorspronkelijke "harde" starttijd van de navigatie. Om bijvoorbeeld het LCP voor zachte navigatie te berekenen, moet u de LCP-timing nemen en de juiste starttijd van de zachte navigatie aftrekken, zoals eerder beschreven, om een ​​timing te krijgen die relatief is aan de zachte navigatie. Voor LCP bijvoorbeeld:

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: 'largest-contentful-paint', buffered: true, includeSoftNavigationObservations: true});

Sommige statistieken worden traditioneel gemeten gedurende de hele 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 zijn dat elke "navigatie" (inclusief de originele navigatie) de statistieken van de vorige pagina moet finaliseren bij elke nieuwe zachte navigatie. Dit betekent dat de initiële 'harde' navigatiestatistieken eerder dan gebruikelijk kunnen worden afgerond.

Op dezelfde manier zullen de statistieken, wanneer men begint met het meten van de statistieken voor de nieuwe zachte navigatie van deze langlevende statistieken, moeten worden "gereset" of "opnieuw geïnitialiseerd" en behandeld als nieuwe statistieken, zonder geheugen voor de waarden die waren ingesteld voor de vorige " pagina's".

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

FP, FCP en LCP voor zachte navigatie meten alleen nieuwe verven. Dit kan resulteren in een ander LCP, bijvoorbeeld van een koude belasting van die zachte navigatie naar een zachte belasting.

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 zachte navigatie zal de onderstaande tekst het grootste element zijn dat na de zachte navigatie wordt geschilderd en zal dit het nieuwe LCP-element zijn. Als er echter een nieuwe pagina wordt geladen met een deep link naar de zachte navigatie-URL, krijgt de bannerafbeelding een nieuwe kleur en komt daarom in aanmerking om als het 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, net zoals het laden van een pagina met een ankerlink verderop op de pagina kan resulteren in een ander LCP-element.

Hoe TTFB meten?

Time to First Byte (TTFB) voor het laden van conventionele pagina's vertegenwoordigt de tijd waarop de eerste bytes van het oorspronkelijke verzoek worden geretourneerd.

Voor een zachte navigatie is dit een lastigere vraag. Moeten we het eerste verzoek voor de nieuwe pagina meten? Wat moet ik doen als alle inhoud al in de app bestaat en er geen aanvullende verzoeken zijn? Wat als dat verzoek vooraf wordt gedaan met een prefetch? Wat moet ik doen als een verzoek vanuit gebruikersperspectief geen verband houdt met de zachte navigatie (het is bijvoorbeeld een analyseverzoek)?

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

In de toekomst kunnen we preciezere manieren ondersteunen om te weten welk verzoek het "navigatieverzoek" van de zachte navigatie is, en zullen we nauwkeurigere TTFB-metingen kunnen uitvoeren. Maar dat maakt geen deel uit van het huidige experiment.

Hoe oud en nieuw meten?

Tijdens dit experiment wordt aanbevolen om uw Core Web Vitals op de huidige manier te blijven meten, op basis van "harde" paginanavigatie om overeen te komen met wat CrUX zal meten en rapporteren als de officiële dataset van het Core Web Vitals-initiatief.

Daarnaast moet zachte navigatie worden gemeten, zodat u kunt zien hoe deze in de toekomst kunnen worden gemeten en om u de mogelijkheid te geven feedback te geven aan het Chrome-team over hoe deze implementatie in de praktijk werkt. Dit zal jou en het Chrome-team helpen de API in de toekomst vorm te geven.

Om beide te meten, moet u op de hoogte zijn van de nieuwe gebeurtenissen die kunnen optreden in de zachte navigatiemodus (bijvoorbeeld meerdere FCP- en aanvullende LCP-gebeurtenissen) en deze op de juiste manier afhandelen door deze statistieken op het juiste moment af te ronden, terwijl u ook toekomstige gebeurtenissen negeert. gebeurtenissen die alleen van toepassing zijn op zachte navigatie.

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

De eenvoudigste manier om met alle nuances rekening te houden, is door de web-vitals JavaScript-bibliotheek te gebruiken die experimentele ondersteuning biedt voor zachte navigatie 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):

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 via de juiste URL, zoals eerder vermeld .

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 inhoudsvolle verf, relatief aan de starttijd van de zachte navigatie. Er wordt geen rekening gehouden met bestaande verven uit de vorige navigatie. Daarom zal het LCP >= 0 zijn. Zoals gebruikelijk wordt dit gerapporteerd bij een interactie of wanneer de pagina op de achtergrond staat, omdat alleen dan het LCP kan worden afgerond.
CLS	Het grootste venster met verschuivingen tussen de navigatietijden. Zoals gebruikelijk gebeurt dit wanneer de pagina op de achtergrond staat, want alleen dan kan de CLS worden afgerond. Indien er geen verschuivingen plaatsvinden, wordt een 0-waarde gerapporteerd.
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 het INP kan worden afgerond. Als er geen interacties zijn, wordt er geen 0-waarde gerapporteerd.

Waarschuwing: de web-vitals -implementatie wordt actief ontwikkeld en kan worden gewijzigd wanneer er nieuwe wijzigingen in die branche worden gepubliceerd. Het ondersteunt geen FCP op zachte navigatie, omdat daarvoor meer onderliggend werk in Chrome vereist is. Degenen die de web-vitals JavaScript-bibliotheek gebruiken, moeten zich hiervan bewust zijn als ze deze bibliotheek op productiesites willen gebruiken, en moeten een lokale kopie nemen en die versie testen, en de branch controleren op wijzigingen.

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

Dit zachte navigatie-experiment is precies dat: een experiment. We willen de heuristieken evalueren en kijken of ze de gebruikerservaring nauwkeuriger weerspiegelen voordat we een beslissing nemen over de vraag of dit zal worden geïntegreerd in het Core Web Vitals-initiatief. We zijn erg enthousiast over de mogelijkheid van dit experiment, maar kunnen geen garanties geven of en wanneer dit de huidige metingen zal vervangen.

We waarderen de feedback van webontwikkelaars over het experiment, de gebruikte heuristieken en of u vindt dat deze de ervaring nauwkeuriger weergeeft. De GitHub-repository voor zachte navigatie is de beste plaats om die feedback te geven, hoewel individuele bugs in de implementatie van Chrome hiervan aan de orde zouden moeten komen in de Chrome issue tracker .

Hoe worden zachte navigatie gerapporteerd in Crux?

Hoe zachte navigatie precies in CrUX zal worden gerapporteerd, mocht dit experiment succesvol zijn, moet ook nog worden bepaald. Het is niet noodzakelijkerwijs een gegeven dat ze op dezelfde manier zullen worden behandeld als de huidige "harde" navigatie.

Op sommige webpagina's zijn zachte navigatie bijna identiek aan het laden van volledige pagina's, voor zover het de gebruiker betreft, en het gebruik van Single Page Application-technologie is slechts een implementatiedetail. In andere gevallen lijken ze misschien meer op een gedeeltelijke lading extra inhoud.

Daarom kunnen we besluiten deze zachte navigatie afzonderlijk in Crux te rapporteren, of ze misschien mee te wegen bij het berekenen van de Core Web Vitals voor een bepaalde pagina of groep pagina's. We kunnen mogelijk ook zachte navigatie met gedeeltelijke belasting volledig uitsluiten, naarmate de heuristiek evolueert.

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

Feedback

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

• De zachte navigatieheuristiek en standaardisatie .
• Chrome-implementatieproblemen met deze heuristieken.
• Algemene feedback over webvitalen op [e-mail] .

Wijzigingslog

Omdat er met deze API wordt geëxperimenteerd, gebeuren er een aantal veranderingen, meer nog dan bij stabiele API's. U kunt de Soft Navigation Heuristics Changelog raadplegen voor meer details.

Conclusie

Het zachte navigatie-experiment is een opwindende benadering van hoe het Core Web Vitals-initiatief zou kunnen evolueren om een ​​gemeenschappelijk patroon op het moderne internet te meten dat in onze statistieken ontbreekt. Hoewel dit experiment nog in de kinderschoenen staat – en er nog veel moet gebeuren – is het een belangrijke stap om de tot nu toe geboekte vooruitgang beschikbaar te maken voor de bredere webgemeenschap om mee te experimenteren. Het verzamelen van de feedback van dit experiment is een ander cruciaal onderdeel van het experiment, dus we moedigen degenen die geïnteresseerd zijn in deze ontwikkeling ten zeerste aan om van deze gelegenheid gebruik te maken om de API vorm te geven, zodat deze representatief is voor wat we hiermee hopen te kunnen meten.

Dankbetuigingen

Miniatuurafbeelding van Jordan Madrid op Unsplash