Ret "Avoid Chaining Critical Requests" i Lighthouse.

Hvordan downloadprioriteten bestemmes

Kritiske anmodninger er de ressourcer, der downloades med høj prioritet under den indledende sideindlæsning. Hvordan bestemmes denne prioritet?

Downloadprioriteten bestemmes af selve browseren. Browseren følger et sæt regler for at bestemme prioriteten af hvert aktiv. Hvilke elementer der i sidste ende får den højeste prioritet, afhænger af sidens struktur. De elementer, som din browser mener er nødvendige for den første rendering af siden, får den højeste prioritet.

Din browser laver i starten et kvalificeret gæt på, hvilke elementer der er vigtigst. Generelt set fungerer downloadprioriteten sådan: HTML har altid den højeste prioritet, derefter stylesheets, synkron JavaScript, skrifttyper, Ajax-anmodninger, billeder øverst på siden, billeder længere nede på siden og til sidst asynkrone JavaScripts.

Du kan selv se, hvilke kilder der får høj prioritet på din side. Åbn udviklerkonsollen med Ctrl + Shift + J. Naviger til netværksfanen, højreklik på kolonnenavnene og vælg 'Priority'

Hvordan påvirker Critical Request Chain sidens indlæsningstid?

Når en side indlæses, starter browseren i 'display blocking'-tilstand. I denne tilstand downloades de vigtigste kilder med høj prioritet. Det er de kritiske ressourcer.

En browser vil ikke (fuldt ud) begynde at rendere siden, før alle kritiske ressourcer er blevet downloadet. Enhver kritisk ressource kan derfor blokere den første rendering af en side.

Jo færre kritiske ressourcer en side har, jo mindre arbejde skal browseren udføre for at få det første indhold på skærmen, og jo mindre konkurrence er der om CPU'en og andre ressourcer.

Hvordan retter man "Avoid Chaining Critical Requests" i Lighthouse?

Du kan reducere effekten af kritiske anmodninger på tre måder:

1. Reducer antallet af kritiske ressourcer . Konverter kritiske ressourcer til ikke-kritiske ressourcer ved at fjerne eller udskyde dem.
2. Reducer antallet af kritiske bytes . Det er måske indlysende, men at reducere antallet af bytes i de kritiske sti-ressourcer får de kritiske ressourcer til at downloade hurtigere. For eksempel gennem gzip-komprimering, JavaScript tree shaking, billedoptimering eller font subsetting.
3. Forbedr downloadrækkefølgen af den kritiske sti . Brug resource hints som preloading til at springe ressourceopdagelse over og sikre, at de kritiske ressourcer downloades så hurtigt som muligt.

Der er mange muligheder. Hvilken mulighed der er den bedste, afhænger af ressourcens filtype:

1. HTML

HTML'en, som faktisk er den side, du besøger, downloades altid med den højeste prioritet. Selve siden er altid en del af Critical Request Chain. Derfor er selve siden det første, man bør overveje, når man optimerer Critical Request Chain.

Forsinket indlæsning af indhold: Mange store websites, som f.eks. Google selv, bruger denne teknik til at reducere Critical Request Chain. På søgeresultatsiden indlæses f.eks. dele af indholdet, som ikke er umiddelbart nødvendige, først senere via en AJAX-anmodning.

Minify: Mindre er altid hurtigere, brug HTML-minificering til at fjerne kommentarer, mellemrum og tomme linjer fra siden.

Komprimering : Endelig er det vigtigt at komprimere stylesheets korrekt med Brotli- eller GZIP-komprimering

2. Stylesheets

Stylesheets i sidens head er altid kritiske. Uden styles ved browseren ikke, hvordan siden skal se ud. Stylesheets er derfor en standarddel af Critical Request Chain i Lighthouse.

Critical CSS: Stylesheets kan gøres ikke-kritiske med et simpelt trick, hvor stylesheetet preloades via resource hints og tilføjes som stylesheet, efter at preloading er afsluttet.
Tilføj følgende kode på siden: Din browser vil nu downloade stylesheetet med en lavere prioritet og behandle CSS'en som ikke-renderblokerende. Den vil begynde at rendere uden at vente på CSS'en.

<link rel="preload"
      href="css.css"
      type="text/css"
      as="style"
      onload="this.onload=null;this.rel='stylesheet';"/>

Læg mærke til, at der nu sker noget mærkeligt på siden. Først vises siden, og først efter indlæsning af CSS'en anvendes stylingen. Alt indhold vil nu blinke fra ustylet indhold til stylet indhold. Vi kan løse dette med critical CSS.
Critical CSS er en samling af alle de CSS-regler, du har brug for til den synlige del af siden. Du kan selv generere critical CSS via NodeJS eller via en række online værktøjer. Placer denne critical CSS i sidens head, og indlæs resten af CSS'en med lavere prioritet.

Media queries : Indlæs kun styles til din enhed. Din side besøges ofte på mobil. Så du behøver faktisk ikke downloade styles til desktop og print. Det sparer tid og forkorter dermed Critical Request Chain i Lighthouse.

Brug media-attributten. Media-attributten sikrer, at et stylesheet kun downloades, hvis mediet fra attributten ikke matcher det medie, du bruger i øjeblikket.

<link href="all.css" rel="stylesheet" media="all">
<link href="print.css" rel="stylesheet" media="print">
<link href="desktop.css" rel="stylesheet" media="screen and (min-device-width: 1024px)">

Minify: Fjern ubrugt CSS. Mange websites bruger CSS-biblioteker som bootstrap. Disse biblioteker er ofte overkomplette, og ikke alle style-deklarationer bruges.
Det er nemt at redigere disse biblioteker via en CSS-preprocessor (som SASS). Fjern simpelthen de ubrugte style-grupper ved at ændre, hvad der skal inkluderes, for at gøre dem meget mindre. Disse preprocessorer giver dig også muligheden for at minificere din CSS ved at fjerne alle mellemrum og linjeskift.\">

Komprimering : Endelig er det vigtigt at komprimere stylesheets korrekt med Brotli- eller GZIP-komprimering

3. Javascript

JavaScript-filer i sidens head downloades som standard med høj prioritet og blokerer renderingen af siden, mens de downloades og eksekveres. JavaScript er derfor en standarddel af Critical Request Chain.

Defer og Async : Juster prioriteten af JavaScript-filerne ved at indlæse dem asynkront via async- eller defer-attributten. Asynkrone scriptfiler downloades parallelt med en lavere prioritet. Udskudte JavaScript-filer indlæses også parallelt, og eksekveringen af JavaScript-filen udskydes, så JavaScript-eksekvering heller ikke blokerer den indledende indlæsning af siden.

// blocks loading and execution
<script src="normalscript.js">
// async does not block during load, but it does block during execution
<script  src="asyncscript.js">
// defer does not block both during load nor execution
<script  src="deferscript.js">

Code splitting og preloading: Hvis siden ikke tillader, at JavaScript indlæses asynkront, kan det være en god idé at opdele JavaScript i flere filer. Placer den del af JavaScript, der er kritisk under sideindlæsning, i en lille fil og preload denne fil. Placer den ikke-kritiske JavaScript i en anden fil og lad den indlæse og køre med defer eller async.

Minify : Reducer antallet af bytes på to måder via et Javascript Uglifier-værktøj. Dette er et smart værktøj, der analyserer JavaScript og gør det så lille som muligt. \">

Komprimering : Derudover kan du reducere antallet af bytes ved at komprimere JavaScript via Gzip eller Brotli.

4. WebFonts

Webskrifttyper er normalt de sidste filer i Critical Request Chain, der indlæses. Dette skyldes, at webskrifttyper afhænger af opdagelse. De indlæses kun, når browseren finder ud af, at de er nødvendige. Til dette skal browseren først analysere HTML'en og slå op i stylesheetet, hvilken skrifttype der bruges.

Preloading : Når du er sikker på, at du vil bruge en skrifttype, er det normalt hurtigere at preloade denne skrifttype. Skrifttypen downloades derefter så tidligt som muligt, hvilket minimerer indflydelsen på Critical Request Chain. Preload en skrifttype ved at tilføje denne kode så tidligt som muligt i sidens head

<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>

Skrifttypestrategi : Derudover er der mange andre måder at få skrifttyper til at indlæse hurtigere.

• Stol altid på lokale webskrifttyper og aldrig på eksternt hostede skrifttyper som Google Fonts.
• Reducer skrifttypens størrelse med font subsetting
• Indlæs ikke-kritiske skrifttyper via JavaScript <a href="https://developer.mozilla.org/en-US/docs/Web/API/FontFace">fontface interface</a>
• Brug display = swap for at undgå, at skrifttypen blokerer den indledende rendering
• Lad browsere generere deres egne skrifttypevarianter gennem font synthesis

Billeder

Billeder, der vises i det synlige viewport under sideindlæsning, kan også få høj prioritet og kan forstyrre den kritiske sti. Når du er sikker på, at et billede altid vil vises i den synlige del af websitet, kan det være nyttigt også at preloade dette billede.

<link rel="preload" as="image" href="important-image.webp">

For alle billeder, der ikke er umiddelbart synlige, bør du som udgangspunkt lazy loade disse billeder. Brug loading = "lazy" til at udskyde indlæsningen af billedet, indtil billedet er ved at blive synligt.

<img loading="lazy" src="lazy-image.webp" width="20" height="20" alt="...">

5. AJAX-anmodninger

AJAX-anmodninger tildeles altid høj prioritet. Udskyd derfor helst AJAX-anmodninger, indtil siden er færdig med at rendere. Vent, indtil siden har sendt "load"-eventet.

Hvis det ikke er muligt at udskyde AJAX-anmodningen, kan du sikre, at AJAX-anmodningen er tilgængelig for browseren ved at preloade den.

window.addEventListener('load', (event)=>{
  console.log('this is a good time for an AJAX request');
});

6. iframes

Iframes downloades normalt med høj prioritet. Fordi en iframe faktisk er en side inden i en side, kan en iframe forårsage en meget betydelig forsinkelse i sidens indlæsningstider. De ressourcer, som iframen kræver, kan også downloades med høj prioritet og danne sin egen Critical Request Chain. Brugen af iframes kan derfor påvirke din Lighthouse-score betydeligt.

Du kan forsinke indlæsningen af en iframe via loading = "lazy"-attributten. Det gør ofte en forskel, når iframen ikke er umiddelbart synlig under indlæsning. Det er ofte hurtigere at injicere iframen i siden via JavaScript. Dette giver dig mere kontrol over timingen, så du kan være sikker på, at den ikke ender i Critical Request Chain.