Den nye Prerender Until Script Speculation Rule

Et dypere blikk på den nye Prerender Until Script Speculation Rule for å oppnå umiddelbar lasting uten analytikkforurensning

Arjen Karel Core Web Vitals Consultant
Arjen Karel - linkedin
Last update: 2026-01-24

Origin Trial Status: Denne funksjonen er for øyeblikket en Origin Trial. For å implementere den må du registrere deg for et Origin Trial-token eller aktivere den lokalt via chrome://flags. Til tross for den eksperimentelle naturen, indikerer tidlige tilbakemeldinger fra ingeniørmiljøet eksepsjonell stabilitet og  ytelsesforbedringer.

Prerender Until Script: Den nye modusen for Speculative Loading

Latens er flaskehalsen. Jeg har sagt dette i årevis, og det forblir det største enkeltstående problemet innen web-ytelse. Uansett hvor mye vi optimaliserer vår Critical Rendering Path eller barberer kilobyte fra våre bundles, er vi til syvende og sist bundet av fysikkens lover og nettverkets rundturstid (RTT).

I lang tid har vi forsøkt å jukse med disse lovene ved å bruke Speculative Loading: gjette hvor brukeren vil gå neste gang og laste det på forhånd. Frem til nå har vi hatt to hovedverktøy, og ingen av dem var perfekte:

  • prefetch: Trygt og lettvektig, men det henter bare HTML. Nettleseren må fortsatt parse, bygge DOM-en og oppdage underressurser (CSS, bilder) etter at brukeren klikker. Det løser nettverksventingen, men ikke gjengivelsesarbeidet.
  • prerender: Det nukleære alternativet. Det laster alt, kjører JavaScript, og gjengir siden i en skjult bakgrunnsfane. Det er umiddelbart, men det er dyrt. Det spiser båndbredde, bruker minne, og verst av alt utløser det «bivirkninger»—fyrer av analytikkpiksler og kjører kode for sider brukeren kanskje aldri faktisk ser.

Vi trengte åpenbart en mellomting. Vi trengte den visuelle beredskapen til en prerender uten beregningskostnaden og risikoen ved å kjøre applikasjonslogikk.

prerender_until_script.

Det geniale med prerender_until_script ligger i hvordan det kobler fra parsing og kjøring.Når du bruker denne spesifikke Speculation Rule, instruerer du nettleseren til å:

  • Hente dokumentet (som en prefetch).
  • Parse HTML-strømmen og bygge DOM-en.
  • Kjøre Preload Scanner. Dette er den kritiske delen. Nettleseren oppdager og laster ned underressurser som høy-prioritets CSS og LCP-bildet.

Men i det øyeblikket parseren møter et JavaScript-kjøringspunkt kan 2 ting skje:

  • Synchronous Scripts: Parseren stopper umiddelbart.
  • Async/Defer Scripts: De lastes ned og legges i kø, men kjøres ikke.

Nettleseren bygger det visuelle «skallet» av siden: Layouten, typografien, bildene—men lar applikasjonslogikken fryses. Siden sitter i minnet, kjemisk stabil, og venter på at brukeren skal klikke.

Når klikket skjer, byttes siden inn umiddelbart, og den «pausede» tilstanden oppheves. JavaScript kjøres, hendelseshåndtererne kobles til, og analytikken din fyres av nøyaktig når den skal.

Implementeringen

Vi implementerer dette ved å bruke Speculation Rules API. Fordi prerender_until_script er en eksperimentell funksjon (som lander i Chrome 144), må vi sikre bakoverkompatibilitet.

Nettlesere som ikke gjenkjenner prerender_until_script-nøkkelen vil ignorere den. Derfor definerer en ansvarlig implementering en prefetch-fallback for det samme settet med URL-er. Chrome vil automatisk deduplisere disse reglene og anvende den mest kapable handlingen som er tilgjengelig.

Her er JSON-strukturen for en produksjonsklar implementering::

<script type="speculationrules">
{
  "prerender_until_script": [
    {
      "source": "document",
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "href_matches": "/logout" } },
          { "not": { "href_matches": "/cart" } }
        ]
      },
      "eagerness": "moderate"
    }
  ]
}
</script>

Tips: hvis du raskt vil generere ditt eget tilpassede sett med speculation rules kan du bruke speculation rules-generatoren

Hensyn

Eagerness: Jeg anbefaler nesten utelukkende moderate. Dette utløser spekulasjonen ved hover (spesifikt når pekeren dveler i 200ms). immediate er for aggressivt for de fleste implementeringer og risikerer å sløse med brukerens båndbredde på mobilforbindelser.

Exclusions: Du må være disiplinert her. Spekuler aldri på tilstandsendrende URL-er som /logout eller /add-to-cart. Selv om prerender_until_script beskytter mot skriptkjøring, tilsier god arkitektur at vi ikke engang bør hente disse endepunktene unødvendig.

Weakness (Parser Blocking): Parseren stopper umiddelbart når den møter en synkron <script>-tag. Dette nuller ut forbedringer som <script>loadWhileIdle(chat.js)</script> hvis de dukker opp tidlig i DOM-en. Du må kanskje refaktorere eksisterende kode for å plassere disse skriptene nederst på siden.

Inline Handlers: Merk at prerender_until_script bare pauser <script>-elementer. Inline hendelseshåndterere på andre elementer (f.eks. <img onload="track()">) vil fortsatt kjøres hvis parseren når dem før et blokkerende skript. Sørg for at analytikkpikslene og sporingslogikken din ikke utløses av disse inline-håndtererne under spekulasjonsfasen.


Performance is a Feature.

Treating speed as an afterthought fails. Build a performance culture with a dedicated 2-sprint optimization overhaul.

Initialize Project >>

  • 2-Sprint Overhaul
  • Culture Building
  • Sustainable Speed
Den nye Prerender Until Script Speculation RuleCore Web Vitals Den nye Prerender Until Script Speculation Rule