Critical rendering path beskriver den proces, browseren gennemfører fra den modtager HTML til siden bliver synlig på skærmen. Browseren parser HTML og opbygger DOM’en, henter og parser CSS til et CSSOM, kombinerer dem til et render tree, beregner layout og maler pixels. Før de første relevante pixels kan vises, skal browseren have nok information til at kende indholdets struktur og udseende.

Begrebet er centralt i performance-arbejde, fordi mange tilsyneladende små valg havner i samme kritiske kæde: langsom HTML fra serveren, flere omdirigeringer, store stylesheets, skrifttyper, hero-billeder og synkrone scripts. En forsinkelse tidligt i kæden flytter ofte både First Contentful Paint (FCP) og Largest Contentful Paint (LCP).

Hvad blokerer den første rendering?

CSS er render-blocking, fordi browseren ellers risikerer at male siden i forkert layout. JavaScript kan stoppe HTML-parseren, når et almindeligt <script> skal hentes og køres med det samme. Derudover kan JavaScript bruge hovedtråden så længe, at browseren ikke får tid til at tegne eller reagere på brugeren. Det er en af vejene til dårlig INP.

Ikke alle ressourcer er lige vigtige. Et cookie-script, en chat-widget og CSS til en skjult slider bør normalt ikke konkurrere med den synlige header, hero-tekst og LCP-elementet. God optimering handler derfor om at få de få nødvendige ressourcer gennem kæden tidligt og flytte resten ud af den.

WordPress-vinklen

I WordPress bliver ressourcer ofte tilføjet af temaet og hvert enkelt plugin. Et plugin kan indlæse sit stylesheet eller script på alle sider, selv om funktionen kun bruges på én skabelon. Page builders, WooCommerce, analytics og tredjepartstags er hyppige kilder til en lang kritisk sti.

  • Lever HTML hurtigt med server-cache, objektcache og et tema, der ikke udfører unødige forespørgsler før output.
  • Indsæt Critical CSS til den første synlige del, og reducer resten af CSS’en.
  • Brug defer til egne scripts, der behøver DOM’en, men ikke er nødvendige før første visning.
  • Brug async med omtanke til uafhængige scripts som visse analyse-tags.
  • Indlæs plugin-assets betinget, hvor de reelt bruges.

Sådan måler og forbedrer du kæden

Start med et vandfald i Chrome DevTools eller WebPageTest. Se først på tidspunktet, hvor HTML-dokumentet ankommer, og følg derefter de CSS-, font- og billedanmodninger, der ligger før LCP. Google PageSpeed Insights kan fremhæve render-blocking ressourcer, men et vandfald viser den konkrete rækkefølge og afhængighed.

Fjern ikke ressourcer blindt. Flyt en ressource ud af den kritiske kæde, test derefter navigering, formularer, checkout og mobilmenu. Prioritér først hurtig TTFB og det synlige indhold, derefter unødvendig CSS og JavaScript. Når den kritiske sti er kort, bliver siden både hurtigere at se og mere forudsigelig at arbejde med.