Unngå trege nettsider: – Jeg vil ha et ytelsesbudsjett!
– Neste gang noen ber om «bare én integrasjon til», bør svaret også inneholde hva den koster, og hvem som godkjenner den kostnaden, advarer Linas Brazauskas.
Publisert
Se for deg en lansering der designeren vil ha video, marked trenger sporing, og utvikleren velger et komponentbibliotek for å bli ferdig.
Hvert valg kan være fornuftig. Likevel kan summen bli en side som bruker for lang tid på å vise innhold og reagere på trykk.
Jeg mener problemet oppstår når vi godkjenner funksjonene hver for seg, men først vurderer kostnaden samlet rett før lansering.
Da er både forventningene og kontraktene på plass. Utvikleren får beskjed om å gjøre siden raskere, uten mandat til å fjerne noe.
Det holder ikke å laste asynkront
Et analyseskript kan være lite over nettverket og likevel gjøre mye arbeid i nettleseren.
async lar et eksternt skript lastes ned uten å blokkere HTML-parsingen under nedlastingen. Men det flytter ikke kjøringen til en bakgrunnstråd. Lange oppgaver på hovedtråden kan fortsatt forsinke responsen på brukerens neste klikk og bidra til dårlig INP.
Det samme gjelder en chat eller en videospiller. Funksjonen kan være verdifull, men trenger vi å starte hele integrasjonen før noen bruker den? Utsetter vi innlastingen til første klikk, må vi også undersøke ventetiden vi påfører akkurat den handlingen.
En test før samtykke kan dessuten overse arbeid fra analyse- og reklameskript som først starter etterpå.
Test den faktiske brukerreisen, også etter samtykke og når kunden åpner chatten. En grønn Lighthouse-rapport fra én innlasting sier ikke hvordan alle disse handlingene oppleves.
Optimalisering kan også gjøre siden tregere
Et stort toppbilde bør leveres i passende størrelse og format. Men hvis vi legger loading="lazy" på bildet som blir sidens LCP-element, utsetter vi innlastingen av nettopp det innholdet vi vil vise tidlig.
Færre byte hjelper ikke fullt ut hvis nettleseren begynner å hente dem for sent.
Heller ikke «fjern animasjonene» er en presis bestilling. En overgang med transform eller opacity kan ofte unngå layout og ny opptegning, mens animasjon av width eller left kan gi mer arbeid.
Vi må profilere implementasjonen, ikke dømme ut fra at noe beveger seg.
Antall WordPress-tillegg eller npm-pakker er like lite egnet som fasit. Det relevante er hva de faktisk laster og gjør, både på serveren og i nettleseren. Et bibliotek kan spare utviklingstid og gi viktig funksjonalitet. Kostnaden må vurderes mot den nytten, på sidene der biblioteket brukes.
Felles ansvar trenger beslutningsmyndighet
Jeg vil ha et ytelsesbudsjett før de første tunge valgene låses: Avtalte grenser for hva kritiske sider kan laste, og hvor raskt de skal vise innhold og reagere.
Grenser for JavaScript og bilder kan varsle vekst i byggløpet. Brukerdata for blant annet LCP og INP må vise hvordan løsningen fungerer ute hos folk. Målingene utfyller hverandre.
Men et budsjett uten noen som kan håndheve det, er bare dokumentasjon. Prosjektet trenger en navngitt ansvarlig med mandat til å kreve en vurdering når nye ønsker sprenger rammene. Utvikleren må synliggjøre kostnaden, designeren vurdere alternative uttrykk, og bestilleren prioritere verdien. Unntak må være bevisste beslutninger.
Det må også gjelde skript som legges til utenom kodebasen. En ny tagg bør ha en eier, et formål og en dato for ny vurdering. Hvem følger opp om verktøyet fortsatt brukes når kampanjen er over?
Vi kan godt velge en tyngre løsning. Men da må den ekstra ventetiden være med i beslutningen mens vi fortsatt kan velge annerledes.
Neste gang noen ber om «bare én integrasjon til», bør svaret også inneholde hva den koster, og hvem som godkjenner den kostnaden.
Foretrekk oss i Google Discover
Ved å legge oss til som foretrukket kilde i Google vil du blant annet få opp flere av sakene våre i Google Discover. Tusen takk for støtten!
