Speculatieregels kunnen worden gebruikt om de volgende paginanavigatie vooraf op te halen en weer te geven, zoals beschreven in het vorige bericht . Dit kan leiden tot veel snellere – of zelfs directe – laadtijden van pagina's, waardoor de Core Web Vitals voor deze extra paginanavigaties aanzienlijk verbeteren.
Het debuggen van speculatieregels kan lastig zijn. Dit geldt met name voor vooraf gerenderde pagina's, omdat deze pagina's in een aparte renderer worden weergegeven – een soort verborgen achtergrondtabblad dat het huidige tabblad vervangt wanneer het wordt geactiveerd. Daarom kunnen de gebruikelijke DevTools-opties niet altijd worden gebruikt om problemen op te sporen.
Het Chrome-team heeft hard gewerkt aan het verbeteren van de ondersteuning van DevTools voor het debuggen van speculatieregels. In dit bericht zie je alle verschillende manieren om deze tools te gebruiken om de speculatieregels van een pagina te begrijpen, waarom ze mogelijk niet werken en wanneer ontwikkelaars de meer vertrouwde DevTools-opties kunnen gebruiken – en wanneer niet.
Uitleg van de term "voor"
Er zijn veel termen met "voor" die verwarrend kunnen zijn, dus we beginnen met een uitleg hiervan:
- Prefetch : het vooraf ophalen van een bron of document om de toekomstige prestaties te verbeteren. In dit artikel wordt het prefetchen van documenten met behulp van de Speculation Rules API behandeld, in plaats van de vergelijkbare, maar oudere
<link rel="prefetch">optie die vaak wordt gebruikt voor het prefetchen van subbronnen. - Prerender : dit gaat een stap verder dan prefetching en rendert de hele pagina alsof de gebruiker ernaartoe is genavigeerd, maar houdt deze in een verborgen achtergrondrenderproces klaar voor gebruik als de gebruiker er daadwerkelijk naartoe navigeert. Nogmaals, dit document behandelt de nieuwere versie van deze functie in de Speculation Rules API, in plaats van de oudere optie
<link rel="prerender">(die geen volledige prerender meer uitvoert ). - Speculatieve navigatie : de verzamelnaam voor de nieuwe prefetch- en prerender-opties die worden geactiveerd door speculatieregels.
- Preload : een term met meerdere betekenissen die kan verwijzen naar een aantal technologieën en processen, waaronder
<link rel="preload">, de preload-scanner en preloads voor navigatie van service workers . Deze items worden hier niet behandeld, maar de term is opgenomen om ze duidelijk te onderscheiden van de term "speculatieve navigaties".
Speculatieregels voor prefetch
Speculatieregels kunnen worden gebruikt om het document voor de volgende navigatiestap vooraf op te halen. Bijvoorbeeld, wanneer de volgende JSON in een pagina wordt ingevoegd, worden next.html en next2.html vooraf geladen:
<script type="speculationrules">
{
"prefetch": [
{
"source": "list",
"urls": ["next.html", "next2.html"],
"tag": "rule-set-tag-1"
}
]
}
</script>
Het gebruik van speculatieregels voor navigatie-prefetches heeft een aantal voordelen ten opzichte van de oudere <link rel="prefetch"> syntaxis, zoals een expressievere API en het feit dat de resultaten in de geheugencache worden opgeslagen in plaats van in de HTTP-schijfcache.
Foutopsporingsregels prefetch -speculatie
Prefetches die worden geactiveerd door speculatieregels zijn in het netwerkpaneel op dezelfde manier te zien als andere fetches:
De twee verzoeken die rood zijn gemarkeerd, zijn de vooraf opgehaalde bronnen, zoals te zien is in de kolom 'Type' . Deze worden opgehaald met de Lowest prioriteit, omdat ze bedoeld zijn voor toekomstige navigaties en Chrome prioriteit geeft aan de bronnen van de huidige pagina.
Als je op een van de rijen klikt, wordt ook de HTTP-header Sec-Purpose: prefetch weergegeven. Hiermee kunnen deze verzoeken aan de serverzijde worden geïdentificeerd.
Debug prefetch met de tabbladen voor speculatief laden.
In het paneel Toepassingen van Chrome DevTools is een nieuwe sectie 'Speculatieve laadprocessen' toegevoegd, onder het gedeelte 'Achtergrondservices ', om het debuggen van speculatieregels te vergemakkelijken.
In dit gedeelte zijn drie tabbladen beschikbaar:
- Speculatieve laadtijden geven de vooraf geladen status van de huidige pagina weer.
- Regels die een lijst bevatten van alle regelsets die op de huidige pagina zijn gevonden, aangeduid als URL's of regeltags , indien aanwezig.
- Speculaties die alle vooraf opgehaalde en gerenderde URL's uit de regelsets opsommen.
Het tabblad 'Speculaties ' wordt weergegeven in de vorige schermafbeelding. We zien dat deze voorbeeldpagina één set speculatieregels heeft voor het vooraf ophalen van 3 pagina's. Twee van deze vooraf opgehaalde pagina's zijn succesvol opgehaald en één is mislukt. U kunt op het pictogram naast de regelset klikken om naar de bron van de regelset in het paneel ' Elementen ' te gaan. U kunt ook op de link 'Status' klikken om naar het tabblad 'Speculaties' te gaan, gefilterd op die specifieke regelset.
Op het tabblad 'Speculaties' worden alle doel-URL's weergegeven, samen met de actie (prefetch of prerender), de regelset waar ze vandaan komen (aangezien er meerdere op een pagina kunnen zijn) en de status van elke speculatie:
Boven de URL's bevindt zich een keuzemenu waarmee u URL's uit alle regelsets kunt weergeven, of alleen URL's uit een specifieke regelset. Daaronder worden alle URL's in een lijst weergegeven. Door op een URL te klikken, krijgt u meer gedetailleerde informatie.
In deze schermafbeelding zien we de reden voor de fout bij de pagina next3.html (deze bestaat niet en geeft daarom een 404-foutmelding, wat een HTTP-statuscode is die niet uit de 2xx-reeks bestaat).
Het tabblad 'Samenvatting', 'Speculatieve laadtijden ', toont een rapport over de status van de speculatieve laadtijd voor deze pagina, waarin wordt aangegeven of er voor deze pagina gebruik is gemaakt van prefetch of prerender.
Bij een vooraf geladen pagina zou u een succesbericht moeten zien wanneer u naar die pagina navigeert:
Ongeëvenaarde speculaties
Wanneer er vanaf een pagina met speculatieregels wordt genavigeerd en er geen prefetch of prerender wordt uitgevoerd, verschijnt er een extra gedeelte in het tabblad met meer details over waarom de URL niet overeenkomt met een van de speculatie-URL's. Dit is handig om typefouten in uw speculatieregels op te sporen.
We zijn bijvoorbeeld naar next4.html gegaan, maar alleen next.html , next2.html of next3.html worden vooraf geladen. Dit voldoet dus niet helemaal aan een van die drie regels.
De tabbladen voor speculatieve belasting zijn erg handig voor het debuggen van de speculatieregels zelf en het vinden van syntaxfouten in de JSON.
Wat de prefetch-processen zelf betreft, is het netwerkpaneel waarschijnlijk een meer vertrouwde plek. Voor het voorbeeld van een mislukte prefetch kunt u de 404-foutmelding hier bekijken:
De tabbladen voor speculatieve laadprocessen blijken echter veel nuttiger te zijn voor het vooraf renderen van speculatieregels, die hierna aan bod komen.
Speculatieregels voor prerender
Speculatieregels voor prerendering volgen dezelfde syntaxis als speculatieregels voor prefetching. Bijvoorbeeld:
<script type="speculationrules">
{
"prerender": [
{
"source": "list",
"urls": ["next.html", "next2.html"],
"tag": "rule-set-tag-1"
}
]
}
</script>
Deze regelset zorgt ervoor dat de opgegeven pagina's volledig worden geladen en weergegeven (onder voorbehoud van bepaalde beperkingen). Dit kan een snelle laadervaring opleveren, zij het met extra resourcekosten.
In tegenstelling tot prefetches zijn deze echter niet zichtbaar in het netwerkpaneel , omdat ze in een apart renderingproces in Chrome worden opgehaald en weergegeven. Dit maakt de tabbladen voor speculatieve laadprocessen des te belangrijker voor het debuggen van regels voor speculatie bij prerendering.
Debug prerender met de tabbladen voor speculatieve laadprocessen.
Dezelfde speculatieve laadschermen kunnen worden gebruikt voor regels voor speculatie voorafgaand aan het laden, zoals gedemonstreerd met een vergelijkbare demopagina die probeert de drie pagina's vooraf te laden in plaats van ze vooraf op te halen:
Hier zien we opnieuw dat een van de drie URL's niet vooraf geladen kon worden. Ontwikkelaars kunnen de details per URL bekijken in het tabblad 'Speculaties ' door op de link ' 2 Klaar, 1 Mislukt' te klikken.
In Chrome 121 hebben we ondersteuning voor documentregels geïntroduceerd . Hierdoor kan de browser deze regels herkennen aan links van dezelfde oorsprong op de pagina, in plaats van een specifieke set URL's op te sommen:
<script type="speculationrules">
{
"prerender": [
{
"source": "document",
"where": {
"and": [
{"href_matches": "/*"},
{"not": { "href_matches": "/not-safe-to-prerender/*"}}
]
},
"eagerness": "moderate"
}
]
}
</script>
Dit voorbeeld selecteert alle links van dezelfde oorsprong, behalve die welke beginnen met /not-safe-to-prerender als kandidaten voor prerendering.
Het stelt ook de prerender eagerness in op moderate , wat betekent dat de navigatie-elementen worden voorgeladen wanneer de muis over de link beweegt (op desktop), op basis van de viewport (op mobiel) of wanneer erop wordt geklikt.
Er zijn vergelijkbare regels te vinden op de demo-site voor speculatieve regels , en het gebruik van de nieuwe sectie 'Speculatieve laadtijden ' op deze site laat het nut van dit nieuwe tabblad zien, aangezien alle in aanmerking komende URL's die de browser op de pagina heeft gevonden, worden weergegeven:
De status wordt niet geactiveerd omdat het prerenderingproces hiervoor nog niet is gestart. Echter, wanneer we de muiswijzer boven de links houden, zien we de status veranderen zodra elke URL wordt geprerenderd:
Chrome heeft limieten ingesteld voor prerenders , waaronder een maximum van 2 prerenders voor moderate eagerness. Als we daarom met de muis over de derde link bewegen, zien we de reden waarom die URL niet werkt:
Debug prerender met de andere DevTools-panelen
In tegenstelling tot prefetching worden vooraf gerenderde pagina's niet weergegeven in de huidige renderingprocessen in DevTools-panelen zoals het Netwerk- paneel, omdat ze worden gerenderd door een eigen, op de achtergrond werkende renderer.
Het is nu echter mogelijk om de renderer die door de DevTools-panelen wordt gebruikt te wijzigen via het vervolgkeuzemenu rechtsboven, of door een URL in het bovenste gedeelte van het paneel te selecteren en 'Inspecteren' te kiezen.
Deze vervolgkeuzelijst (en de geselecteerde waarde) wordt ook gedeeld met alle andere panelen, zoals het netwerkpaneel , waar u kunt zien dat de opgevraagde pagina de vooraf gerenderde pagina is:
Als we naar de HTTP-headers voor deze resources kijken, zien we dat ze allemaal zijn ingesteld met de header Sec-Purpose: prefetch;prerender :
Of het paneel Elementen , waar je de pagina-inhoud kunt zien, zoals in de volgende schermafbeelding waar we zien dat het <h1> -element voor de vooraf gerenderde pagina is:
Of het Console-paneel , waar u de consolelogs kunt zien die door de vooraf gerenderde pagina worden gegenereerd:
Foutopsporingsregels voor speculatie op de vooraf gerenderde pagina
In de voorgaande secties is besproken hoe je vooraf gerenderde pagina's kunt debuggen op de pagina die het vooraf renderen initieert. Het is echter ook mogelijk dat de vooraf gerenderde pagina's zelf debug-informatie leveren, bijvoorbeeld door analytics-aanroepen te doen of door naar de console te loggen (wat zichtbaar is zoals beschreven in de vorige sectie).
Zodra een vooraf gerenderde pagina door de gebruiker wordt geopend, toont het tabblad 'Speculatieve laadtijden' de status en of de pagina succesvol is geladen. Indien het laden niet is gelukt, wordt een uitleg gegeven waarom dit niet het geval was.
Daarnaast zal , net als bij prefetches , wanneer je navigeert vanaf een pagina met speculatieregels die niet overeenkomen met de huidige pagina, in het tabblad 'Speculatieve laadtijden' proberen uit te leggen waarom de URL's niet overeenkomen met de URL's die in de speculatieregels van de vorige pagina zijn opgenomen.
Conclusie
In dit bericht hebben we de verschillende manieren laten zien waarop ontwikkelaars speculatieregels voor prefetch en prerender kunnen debuggen. Het team werkt nog steeds aan tools voor speculatieregels en we horen graag suggesties van ontwikkelaars over andere manieren die nuttig zouden zijn voor het debuggen van deze spannende nieuwe API. We moedigen ontwikkelaars aan om eventuele functieverzoeken of gevonden bugs te melden via de Chrome-probleemtracker .
Dankbetuigingen
Miniatuurafbeelding door Nubelson Fernandes op Unsplash .