100 poäng i PageSpeed: vad vi ändrade för det

Utgångsvärdet var 58 av 100 på mobilen. Det är inget dåligt värde för en webbplats med 3D-effekt i toppområdet, men ett värde som Google bestraffar märkbart i den mobila sökningen. Till slut stod det 100 poäng på datorn och 98 på mobilen, med likaså 100 för tillgänglighet.

Det som följer är ingen allmän checklista, utan det faktiska förloppet – inklusive de ställen där vi tog fel.

Utgångsläget

De fem ingrepp som verkligen räknades

1. Ersätt biblioteket, optimera det inte

Toppområdet visar ett partikelmoln i 3D. För det kördes ett känt grafikbibliotek – 458 KB efter förminskning. Mätningen visade att 51 KB av det aldrig ens kördes.

Den avgörande blicken var frågan om hur mycket vi faktiskt behöver. Det var elva byggstenar: renderare, scen, kamera, geometri, material och några hjälpklasser. Allt det går att programmera direkt mot webbläsarens grafikgränssnitt.

Resultat: 458 KB blev 6 KB. Framställningen är identisk – vi tog över samma shaders.

2. Komprimeringen var bara halvt påslagen

I serverkonfigurationen stod komprimeringen på «på» – men raden om vilka filtyper som ska komprimeras var bortkommenterad. Det är förinställningen i många distributioner. Resultat: enbart HTML komprimerades.

Grafikbiblioteket gick alltså okomprimerat över ledningen. Efter påslaget: 1243 KB blev 251 KB. Dessutom lägger vi nu de komprimerade versionerna förberäknade bredvid, så att servern inte räknar om vid varje anrop.

Insats: två rader konfiguration. Verkan: knappt en megabyte per första anrop.

3. Ta bort animationsbiblioteket helt

För intoningar vid skrollning kördes ytterligare ett bibliotek, 114 KB. Mätningen pekade dessutom ut det som orsak till framtvingade layoutomräkningar – det frågade efter geometri under skrollningen och tvingade webbläsaren att räkna om layouten mitt i rörelsen.

Ersatt av en IntersectionObserver som enbart sätter en klass. Själva rörelsen sköter CSS. 114 KB mindre, inga omräkningar längre, runt 40 rader egen kod.

4. Ikonen var 205 KB stor

En småsak med förvånande verkan, eftersom den laddas mycket tidigt. Ersatt av en SVG-fil på 6 KB, framställd ur den befintliga logotypen.

5. Fråga efter geometri i animationsbilden

Ett skript läste ut dokumentets totalhöjd vid varje skrollhändelse. Den egenskapen kan webbläsaren inte besvara ur minnet – den måste räkna om hela sidans layout för det, mitt i skrollningen.

Regeln som följer av det och som gäller överallt: läs i händelsen, skriv i bilden därefter. Aldrig tvärtom. Sedan dess mäts sidhöjden en gång och sparas, i stället för att frågas på nytt sextio gånger i sekunden.

Felet som kostade 24 poäng

Vad som gav lite

För fullständighetens skull de åtgärder som står i varje guide och som hos oss knappt var mätbara:

Bildformat. Vår startsida har knappt några bilder – logotypen är en SVG-fil. Där bilder förekommer lönar sig omvandlingen förstås; som huvudhävstång duger den bara på bildtunga sidor.

Förminska typsnitten ytterligare. Vi driftar två typsnittsfamiljer själva och förladdar de som behövs i det synliga området. Ytterligare optimering vore möjlig men rör inte värdet.

Serverplats. Ofta rekommenderat, i vårt fall irrelevant: tiden till första byten låg redan på 20 millisekunder. Den som redan ligger bra där vinner ingenting på ett distributionsnät.

Tillvägagångssättet att göra efter

1. Mät innan något som helst ändras. Mobilt och dator var för sig, notera värdena.
2. Sök den största överförda filen. Nästan alltid är det JavaScript. Frågan är inte hur man förminskar den, utan om man behöver den.
3. Kontrollera komprimeringen. Inte om den är påslagen, utan för vilka filtyper.
4. Räkna de blockerande förfrågningarna. Varje stilmallsfil i toppområdet håller upp den första bilduppbyggnaden.
5. Kontrollera layouthopp utan broms. Det enda test som saknades hos oss.
6. Mät på nytt efter varje ändring. Annars vet man till slut inte vad som verkade.

Hjälp mig att översätta min sidas PageSpeed-rapport till en
ordningsföljd. Var sträng; beröm ingenting.

Mina mätvärden:
- Mobilt: [poäng], dator: [poäng]
- LCP, TBT, CLS per enhet: [värden]
- Största överförda filer med storlek: [lista]
- Renderingsblockerande förfrågningar: [lista]
- Meddelanden ur rapporten: [klistra in text]

Om sidan:
- Hur den är byggd: [CMS / statisk / byggverktyg]
- Behövs JavaScript för det synliga innehållet? [ja/nej]
- Hur levereras CSS? [externt / i förväg / delvis i förväg]

Uppgifter:
1. Koppla varje meddelande till en orsak och säg vilket nyckeltal
   det påverkar – LCP, TBT eller CLS.
2. Sortera åtgärderna efter verkan per insats. Ange vid
   varje hur många poäng den realistiskt rör och varför.
3. Ange de åtgärder ur rapporten som med min byggnadstyp
   praktiskt taget inte ger något – och motivera i stället för
   att bara utelämna dem.
4. Fråga vid varje stor JavaScript-fil först om den
   behövs, innan du föreslår förminskning.
5. Påpeka om CSS bara delvis levereras i förväg,
   och förklara varför det kan vara sämre för CLS
   än att inte göra det alls.
6. Ange vad jag bör mäta på nytt efter varje ändring.

Hitta inte på några mätvärden.

Slutsats

Poängen i sig är inte målet – den är ett mätvärde, inte ett affärsresultat. Det som räknas är erfarenheten bakom: en sida som är läsbar efter 1,4 sekunder läses av fler människor än en som behöver sex sekunder. Hos mobila besökare över mobilnät är skillnaden större än någon textoptimering.

Vägen dit gick i vårt fall via en enda återkommande fråga: behöver vi det här? Fem av sex ingrepp bestod i att ta bort något, inte i att lägga till något.

Vanliga frågor