Render-blokerende ressourcer er filer, som en browser skal downloade og behandle, før den kan vise indhold. De er primært stylesheets, der refereres til i dokumenthovedet, og synkrone scripts, der opstår under parsing, og de er den mest almindelige årsag til, at en side tager længere tid om at vises, end indholdet berettiger.
Stylesheets blokerer af en forsvarlig grund. At male indhold, før stilarter er tilgængelige, ville producere et glimt af ustylet indhold efterfulgt af en forstyrrende reflow, så browsere venter. Problemet er ikke, at stylesheets blokerer, men at websteder typisk indlæser langt mere stil, end den oprindelige visning kræver, inklusive stilarter til komponenter længere nede på siden, til andre skabeloner og til funktioner, som den besøgende måske aldrig bruger, som alle skal ankomme, før noget vises.
Scripts blokeres, fordi et script, der stødes på under parsing, kan ændre dokumentet, så parseren stopper, indtil det er udført. De fleste scripts behøver ikke denne funktion: analyser, chatwidgets, personaliseringsværktøjer og det meste programkode kan udføres, efter at dokumentet er parset, uden tab af korrekthed. Tilføjelse af defer-attributten tillader parsningen at fortsætte og udfører dem i rækkefølge bagefter, mens async udfører dem, så snart de ankommer, uden rækkefølgegarantier.
Standardløsningen for stylesheets er at adskille de styles, der kræves til den oprindelige viewport, fra resten. Den kritiske del indlejres direkte i dokumentet, så der kræves ingen anmodning, og resten indlæses på en måde, der ikke blokerer. Dette er effektivt og øger byggekompleksiteten, da det kritiske sæt skal regenereres, når styles ændres, og forældet kritisk CSS producerer synlige defekter.
Tredjepartsressourcer er ofte de største bidragydere og de sværeste at kontrollere. Tag managers, samtykkeplatforme, fontudbydere, chatværktøjer og testframeworks tilføjes typisk til dokumenthovedet med blokeringsadfærd, der hver især kræver en forbindelse til en separat kilde. Den kumulative forsinkelse er betydelig, og fordi hver enkelt blev tilføjet af et andet team af en forsvarlig årsag, er ingen ansvarlige for det samlede beløb. Revision af de samlede omkostninger og tilskrivning af dem til den anmodende funktion er det, der synliggør afvejningen.
Skrifttyper kræver særlig håndtering, fordi de blokerer tekstgengivelse i stedet for sidestruktur. Afhængigt af visningsstrategien kan tekst være usynlig, mens en skrifttype downloades, hvilket betyder, at indhold, der er fuldt ankommet, bevidst tilbageholdes. Ved at vælge en strategi, der viser reservetekst med det samme og bytter, når skrifttypen ankommer, og ved at forudindlæse skrifttyper, der bruges over fold, forhindres den situation, hvor en side teknisk set gengives og fremstår tom.
Måling af de reelle omkostninger kræver omhu, fordi fjernelse af en blokerende ressource ikke altid giver den forventede besparelse. Ressourcer downloades parallelt, så eliminering af én kan blot lade en anden blive en begrænsning, og den observerede forbedring er ofte mindre end summen af de individuelle estimater. Verifikation ved måling efter hver ændring, i stedet for at stole på de forventede totaler, holder forventningerne nøjagtige.
Det er ligetil at identificere, hvad der rent faktisk blokerer, med standardværktøjer, som rapporterer blokerende ressourcer og estimerer besparelsen ved at adressere hver enkelt. Estimaterne bør behandles som vejledende snarere end præcise, da fjernelse af én blokerende ressource ofte afslører, at en anden var den reelle begrænsning, og forbedringer verificeres bedst ved måling snarere end antages ud fra rapporten.
Da de involverede ressourcer normalt tilføjes af flere teams over tid, kræver afhjælpning lige så meget styring som ingeniørarbejde. I praksis ligger revision og prioritering inden for web ydeevne arbejde, ændringerne i bygningen implementeres gennem produktudvikling, og beslutninger om hvilke tredjepartsværktøjer, der retfærdiggør deres blokeringsomkostninger, kræver aftale med de teams, der anmodede om dem, hvilket for de fleste websteder betyder digital marketingafdeling.