100 poeng på PageSpeed: Hva vi endret for å komme dit

Utgangsverdien var 58 av 100 på mobil. Det er ingen dårlig verdi for et nettsted med 3D-effekt i toppområdet, men en verdi Google straffer merkbart i mobilsøket. Til slutt sto det 100 poeng på datamaskin og 98 på mobil, med likeledes 100 for universell utforming.

Det som følger, er ingen allmenn sjekkliste, men det faktiske forløpet – inkludert stedene der vi tok feil.

Utgangspunktet

De fem inngrepene som virkelig telte

1. Erstatt biblioteket, ikke optimaliser det

Toppområdet viser en partikkelsky i 3D. Til det kjørte et kjent grafikkbibliotek – 458 KB etter forminskingen. Målingen viste at 51 KB av det aldri i det hele tatt ble kjørt.

Det avgjørende blikket var spørsmålet om hvor mye vi faktisk trenger. Det var elleve byggeklosser: renderer, scene, kamera, geometri, materiale og noen hjelpeklasser. Alt sammen lar seg programmere direkte mot nettleserens grafikkgrensesnitt.

Resultat: 458 KB ble til 6 KB. Framstillingen er identisk – vi overtok de samme shaderne.

2. Komprimeringen var bare halvveis slått på

I serverkonfigurasjonen sto komprimeringen på «på» – men linjen om hvilke filtyper som skulle komprimeres, var kommentert ut. Det er standardinnstillingen i mange distribusjoner. Resultat: det ble utelukkende komprimert HTML.

Grafikkbiblioteket gikk altså ukomprimert over ledningen. Etter påslaget: 1243 KB ble til 251 KB. I tillegg legger vi nå de komprimerte versjonene ferdig beregnet ved siden av, slik at serveren ikke regner på nytt ved hvert kall.

Innsats: to linjer konfigurasjon. Virkning: knapt en megabyte per førstegangskall.

3. Fjern animasjonsbiblioteket helt

Til innblendinger ved rulling kjørte enda et bibliotek, 114 KB. Målingen pekte det i tillegg ut som årsak til framtvungne layoutomberegninger – det spurte etter geometri under rullingen og tvang nettleseren til å regne ut layoutet på nytt midt i bevegelsen.

Erstattet med en IntersectionObserver som utelukkende setter en klasse. Selve bevegelsen gjør CSS. 114 KB mindre, ingen omberegninger lenger, rundt 40 linjer egen kode.

4. Faviconet var 205 KB stort

En bagatell med forbausende virkning, fordi den lastes svært tidlig. Erstattet med en SVG-fil på 6 KB, laget ut fra den eksisterende logoen.

5. Spør etter geometri i animasjonsbildet

Et skript leste ut dokumentets samlede høyde ved hver rullehendelse. Denne egenskapen kan nettleseren ikke besvare fra hukommelsen – den må regne gjennom layoutet for hele siden på nytt, midt i rullingen.

Regelen som følger av det, og som gjelder overalt: les i hendelsen, skriv i bildet etterpå. Aldri omvendt. Siden har sidehøyden blitt målt én gang og husket, i stedet for etterspurt seksti ganger i sekundet.

Feilen som kostet 24 poeng

Hva som ga lite

For fullstendighetens skyld tiltakene som står i enhver veiledning og hos oss knapt var målbare:

Bildeformater. Forsiden vår har knapt bilder – logoen er en SVG-fil. Der bilder forekommer, lønner omgjøringen seg selvsagt; som hovedspak duger den bare på bildetunge sider.

Forminske skriftene ytterligere. Vi drifter to skriftfamilier selv og forhåndslaster dem som trengs i det synlige området. Ytterligere optimalisering ville vært mulig, men beveger ikke verdien.

Serverplassering. Ofte anbefalt, i vårt tilfelle irrelevant: tiden til første byte lå allerede på 20 millisekunder. Den som allerede ligger godt an der, vinner ingenting på et distribusjonsnett.

Framgangsmåten til å gjenta selv

1. Mål før noe som helst endres. Mobil og skrivebord hver for seg, noter verdiene.
2. Let opp den største overførte filen. Nesten alltid er det JavaScript. Spørsmålet er ikke hvordan man forminsker den, men om man trenger den.
3. Kontroller komprimeringen. Ikke om den er slått på, men for hvilke filtyper.
4. Tell blokkerende forespørsler. Hver stilarkfil i toppområdet holder tilbake den første bildeoppbyggingen.
5. Kontroller layouthopp uten brems. Den ene testen som manglet hos oss.
6. Mål på nytt etter hver endring. Ellers vet man til slutt ikke hva som virket.

Hjelp meg å oversette PageSpeed-rapporten for siden min til
en rekkefølge. Vær streng; ikke ros noe.

Måleverdiene mine:
- Mobil: [poengsum], skrivebord: [poengsum]
- LCP, TBT, CLS per enhet: [verdier]
- Største overførte filer med størrelse: [liste]
- Render-blokkerende forespørsler: [liste]
- Meldinger fra rapporten: [lim inn tekst]

Om siden:
- Hvordan den er bygd: [CMS / statisk / byggekasse]
- Trengs JavaScript for det synlige innholdet? [ja/nei]
- Hvordan leveres CSS? [eksternt / på forhånd / delvis på forhånd]

Oppgaver:
1. Knytt hver melding til en årsak og si hvilket nøkkeltall
   den påvirker – LCP, TBT eller CLS.
2. Sorter tiltakene etter virkning per innsats. Oppgi for
   hvert av dem hvor mange poeng det realistisk beveger og hvorfor.
3. Nevn tiltakene fra rapporten som praktisk talt ikke gir noe
   ved min byggemåte – og begrunn det, i stedet for bare å
   utelate dem.
4. Spør ved hver stor JavaScript-fil først om den trengs,
   før du foreslår å forminske den.
5. Påpek det hvis CSS bare leveres delvis på forhånd,
   og forklar hvorfor det kan være dårligere for CLS
   enn ikke i det hele tatt.
6. Nevn hva jeg bør måle på nytt etter hver endring.

Ikke finn på måleverdier.

Konklusjon

Selve poengsummen er ikke målet – den er en måleverdi, ikke et forretningsresultat. Det som teller, er erfaringen bak: en side som er lesbar etter 1,4 sekunder, blir lest av flere mennesker enn en som bruker seks sekunder. Hos mobile besøkende over mobilnett er forskjellen større enn enhver tekstoptimalisering.

Veien dit gikk i vårt tilfelle gjennom ett eneste tilbakevendende spørsmål: trenger vi dette? Fem av seks inngrep besto i å fjerne noe, ikke i å legge til noe.

Vanlige spørsmål