Optimering af JavaScript-prioritet for hurtigere sideindlæsning

Lær hvordan du effektivt prioriterer scripts for at forbedre Core Web Vitals.

Arjen Karel - linkedin

Last update: 2024-12-12

Håndtering af JavaScript-prioriteter for bedre webperformance

Én ting har altid været klart: ikke al JavaScript er skabt lige. Nogle scripts håndterer kritiske interaktioner som 'menuinteraktion' eller 'tilføj til kurv', mens andre scripts er langt mindre vigtige. Tag for eksempel dit 'exit intent' popup-script, der inviterer besøgende, som er ved at forlade din side, til at udfylde et spørgeskema. Jeg er sikker på, at vi alle kunne leve uden de sidste, men det ville være virkelig svært at navigere på en hjemmeside uden de første.

Alligevel, på 'den gennemsnitlige hjemmeside' på et teknisk niveau bliver denne skelnen næsten aldrig foretaget. Al JavaScript bliver 'bare tilføjet' til siden, og browseren må selv finde ud af det. Det er et problem, fordi din browser ingen idé har om, hvad der er vigtigt, og hvad der ikke er. Vi, som udviklere, har. Så lad os fikse det!

Hvordan JavaScript-prioritet kan påvirke Core Web Vitals

Bare at tilføje scripts til siden uden de rette overvejelser kan påvirke alle 3 Core Web Vitals. Largest Contentful Paint, Interaction to Next Paint og Cumulative Layout Shift.

javascript lcp impact example

Eksempel: LCP-netværksressourcen forsinkes af renderblokerende JavaScripts

Largest Contentful Paint er udsat for båndbredde- og CPU-konkurrence. Når for mange scripts kæmper om tidlige netværksressourcer, vil det forsinke Largest Contentful Paint-netværksressourcen, og tidligt CPU-arbejde vil forsinke LCP ved at blokere hovedtråden.

Interaction to Next Paint kan påvirkes af scripts, der udføres lige før en interaktion. Når scripts udføres, blokerer de hovedtråden og forsinker enhver interaktion i den udførelsestid.

Scripts kan også forårsage et Cumulative Layout Shift hvis scripts 'ændrer, hvordan siden ser ud'. Annonce-scripts, der injicerer bannere på siden, og slidere er berygtede for at gøre dette.

5 typer JavaScript-prioriteter

Jeg kan godt lide at skelne mellem 5 typer JavaScript-prioriteter. Lad os hurtigt gennemgå dem, før vi dykker ned.

Render Critical: disse scripts er blandt de værste at have. De ændrer layoutet af siden, og uden at indlæse disse scripts vil layoutet være helt anderledes. Eksempel: nogle slider-scripts eller en A/B-test.
Critical Scripts: Disse scripts håndterer kritisk sidefunktionalitet, og uden disse scripts er kritiske opgaver som at tilføje et produkt til en kurv, søgning på siden eller navigation ikke mulige.
Important scripts. Disse scripts håndterer vigtig (forretnings)logik, og din side afhænger af dem. For eksempel: Analytics
Nice to have scripts. Disse scripts er rare at have, men når det kommer til stykket, har vi ikke rigtig brug for dem, for at siden kan fungere. For eksempel en chat-widget eller et exit intent
Future Scripts. Disse scripts kan være kritiske eller rare at have, men vi har ikke brug for dem lige nu, fordi 'andre trin' skal tages, før vi rent faktisk kan bruge disse scripts. For eksempel et flertrinnet checkout-script.

Nu hvor vi har en idé om script-prioriteter, lad os bryde det ned!

1. Render-Critical Scripts

Disse er de mest forstyrrende scripts, da de direkte påvirker, hvordan siden vises. Uden dem kan layoutet gå i stykker eller se drastisk anderledes ud end det tilsigtede design. Eksempler inkluderer scripts til slidere eller A/B-testframeworks, der ændrer layoutet tidligt i indlæsningsprocessen.

Problemet med denne type scripts er, at de ikke kan udskydes eller forsinkes. Enhver forsinkelse vil få sidens layout til at skifte, hvilket forårsager en dårlig UX og får Core Web Vitals til at fejle.

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8" />
    <title>Page Title</title>
    <link href="styles.css" rel="stylesheet" />
    <script src="render-critical.js"></script>
  </head>
  <body></body>
</html>

Bedste praksis:

Undgå render-kritiske scripts som disse, når det er muligt. Omskriv din kode for at undgå afhængighed af denne type scripts.
Hvis det ikke kan undgås, inline eller indlæs kun de absolut nødvendige dele af disse scripts.
Brug ikke defer eller async på disse scripts, og placer dem øverst i head for at udløse en 'så tidligt som muligt' download.

2. Critical Scripts

Disse scripts muliggør grundlæggende interaktioner. Uden dem bliver kritiske opgaver som sitenavigation, tilføjelse af varer til en kurv, cookiemeddelelse eller søgning umulige. De er uundværlige for sidens kernefunktionalitet.

Disse scripts bør placeres i head af siden med enten async- eller defer-attributten.

<script defer src="critical.js"></script>
<script async src="critical.js"></script>

Bedste praksis:

Hold scripts som disse på et minimum, og kombiner ikke denne funktionalitet med anden, mindre kritisk funktionalitet.
Indlæs disse scripts tidligt ved hjælp af async eller defer, afhængigt af deres afhængigheder.
Brug RUM-værktøjer (Real User Monitoring), som Coredash, til at identificere flaskehalse i udførelsen og sikre, at deres performance stemmer overens med brugernes behov.

3. Important Scripts

Selvom de ikke er direkte knyttet til sidens brugbarhed, understøtter important scripts vigtige forretningsfunktioner. Analytics-scripts leverer for eksempel vigtige data, men behøver ikke at indlæses før vigtigere visuelle elementer. Naturligvis kan skelnen mellem critical og important scripts være et diskussionspunkt, så sørg for at tale med alle interessenter, før du fastsætter denne prioritet!

Der er 3 måder at sænke script-prioriteten for denne type scripts.

<html>
<head>
<!-- method 1: low fetchpriority -->
<script fetchpriority="low" defer src="important.js"></script>

<!-- method 2: inject after DOMContentLoaded -->
<script>
  document.addEventListener('DOMContentLoaded', function() {
    var script = document.createElement('script');
    script.src = 'important.js';
    document.body.appendChild(script);
  });
</script>
</head>
<body>

<!-- method 3: place at the bottom of the page -->
<script defer src="important.js"></script>
</body>
</html>

1. Lav fetchpriority.

Indstilling af fetchpriority vil sænke den relative prioritet af scriptet. Andre deferred eller asynced scripts vil sandsynligvis blive sat i kø med en høj prioritet, mens scripts med fetchprioriy="low" vil blive sat i kø med en lav prioritet. Afhængigt af din side (eller din rendering-sti) kan dette være nok til at prioritere andre ressourcer som dit Largest Contentful Paint-billede og vigtige skrifttyper.

2: Injicer efter DOMContentLoaded

Ved at injicere scriptet efter DOMContentLoaded-eventet sikrer du, at scriptet begynder at downloade direkte efter, at HTML'en er blevet fuldt parset. Dette giver opdagelige ressourcer, som billeder og skrifttyper, mulighed for at få forrang. Denne metode giver en balance: scriptet begynder at indlæses tidligt nok til at undgå forsinkelser i funktionalitet, men konkurrerer ikke med tidlige ressourcer, der er afgørende for den indledende siderendering.

3: placer i bunden af siden

Denne klassiske teknik udskyder script-indlæsning, indtil browseren har behandlet hele dokumentet og opnår omtrent det samme resultat som teknikken. Den eneste forskel er, at teknik 2 springer din browsers preload scanner over, mens denne teknik ikke gør. Preload scanneren er en let, hurtig scanner, som din browser bruger til hurtigt at identificere og sætte kritiske ressourcer i kø. At springe preload scanneren over kan være en god idé, hvis der er mulighed for lazy-loadede billeder i viewporten, mens brug af preload scanneren vil fremskynde indlæsningen af dette script.

4. Nice-to-Have Scripts

Disse scripts forbedrer user experience, men er ikke nødvendige for, at siden kan fungere. Eksempler inkluderer chat-widgets, kundefeedback-popups eller valgfrie animationer. Selvom de er gavnlige, bør de ikke forstyrre den primære user experience.

Disse scripts er en ideel kandidat til at indlæse med et mønster kaldet 'lazy on load'. Det betyder, at man venter på sidens load-event og derefter, i inaktiv tid, injicerer scriptet. At vente på load-eventet sikrer, at scriptet ikke konkurrerer om båndbredde og CPU med vigtigere tidlige ressourcer. At vente på et inaktivt øjeblik sikrer, at browseren ikke håndterer vigtigere opgaver som brugerinput.

Her er et fungerende eksempel:

window.addEventListener("load", () => {
  window.requestIdleCallback(() => {
    const script = document.createElement("script");
    script.src = "/path/to/script.js";
    document.head.appendChild(script);
  });
});

Bedste praksis:

Lazy-load disse scripts, efter siden er indlæst, og vent på et inaktivt øjeblik.
Forstå, at scripts indlæst med dette mønster ikke er garanteret at indlæse hurtigt

5. Future Scripts

Future scripts er dem, der ikke er nødvendige, før specifikke betingelser er opfyldt. For eksempel bliver et flertrinnet checkout-script først relevant, efter en bruger har tilføjet varer til sin kurv. Disse scripts kan ofte vente til meget senere i brugerens rejse.

Tag et kig på dette eksempel. Det bruger intersection observer til kun at indlæse den JavaScript-logik, der kræves til tilmeldings-scriptet, når formularen er i den synlige viewport.

<!DOCTYPE html>
<html>
  <head>
    <script>
      document.addEventListener("DOMContentLoaded", function () {
        const form = document.querySelector("form");
        const observer = new IntersectionObserver(function (entries) {
          entries.forEach((entry) => {
            if (entry.isIntersecting) {
              const script = document.createElement("script");
              script.src = "/sign-up.js";
              document.head.appendChild(script);
              observer.unobserve(form);
            }
          });
        });
        observer.observe(form);
      });
    </script>
  </head>
  <body>
    <form action="/sign-up" method="post">
      <label for="email">Email:</label>
      <input type="email" id="email" name="email" required />
      <button type="submit">Sign Up</button>
    </form>
  </body>
</html>

Bedste praksis:

Indlæs disse scripts on demand, udløst af brugerhandlinger.
Brug code-splitting-teknikker til kun at levere de dele, der kræves ved hvert trin.
Injicer dem dynamisk kun, når det er nødvendigt, for eksempel når en bruger scroller til en bestemt sektion.

Compare your segments.

Is iOS slower than Android? Is the checkout route failing INP? Filter by device, route, and connection type.

Analyze Segments >>

Device filtering
Route Analysis
Connection Types

Optimering af JavaScript-prioritet for hurtigere sideindlæsning

Core Web Vitals Optimering af JavaScript-prioritet for hurtigere sideindlæsning