100 point i PageSpeed: Hvad vi ændrede for at nå det

Udgangsværdien var 58 ud af 100 på mobilen. Det er ikke en dårlig værdi for et website med 3D-effekt i toppen, men en værdi, som Google straffer mærkbart i den mobile søgning. Til sidst stod der 100 point på computeren og 98 på mobilen, med ligeledes 100 for tilgængelighed.

Det, der følger, er ikke en almen tjekliste, men det faktiske forløb – inklusive de steder, hvor vi tog fejl.

Udgangspunktet

De fem indgreb, der virkelig talte

1. Erstat biblioteket, optimér det ikke

Topområdet viser en partikelsky i 3D. Til det kørte et kendt grafikbibliotek – 458 KB efter formindskelse. Målingen viste, at 51 KB af det aldrig overhovedet blev udført.

Det afgørende blik var spørgsmålet om, hvor meget vi faktisk har brug for. Det var elleve byggesten: renderer, scene, kamera, geometri, materiale og et par hjælpeklasser. Alt det kan programmeres direkte mod browserens grafikgrænseflade.

Resultat: 458 KB blev til 6 KB. Fremstillingen er identisk – vi overtog de samme shaders.

2. Komprimeringen var kun halvt slået til

I serverkonfigurationen stod komprimeringen på «til» – men den linje, der angiver, hvilke filtyper der skal komprimeres, var kommenteret ud. Det er standardindstillingen i mange distributioner. Resultat: der blev udelukkende komprimeret HTML.

Grafikbiblioteket gik altså ukomprimeret over ledningen. Efter at det blev slået til: 1243 KB blev til 251 KB. Derudover lægger vi nu de komprimerede udgaver forudberegnet ved siden af, så serveren ikke regner forfra ved hvert kald.

Indsats: to linjer konfiguration. Virkning: knap en megabyte per førstegangskald.

3. Fjern animationsbiblioteket helt

Til indtoninger ved scroll kørte endnu et bibliotek, 114 KB. Målingen udpegede det derudover som årsag til fremtvungne layoutombrud – det spurgte til geometri under scrollingen og tvang browseren til at genberegne layoutet midt i bevægelsen.

Erstattet af en IntersectionObserver, der blot sætter en klasse. Selve bevægelsen laver CSS. 114 KB mindre, ingen ombrud mere, omkring 40 linjer egen kode.

4. Faviconet var 205 KB stort

En bagatel med forbløffende virkning, fordi den indlæses meget tidligt. Erstattet af en SVG-fil på 6 KB, dannet ud fra det eksisterende logo.

5. Spørg til geometri i animationsbilledet

Et script læste dokumentets samlede højde ved hver scroll-hændelse. Den egenskab kan browseren ikke besvare fra hukommelsen – den skal genberegne hele sidens layout for at gøre det, midt i scrollingen.

Reglen, der følger af det, og som gælder overalt: læs i hændelsen, skriv i billedet derefter. Aldrig omvendt. Siden da måles sidehøjden én gang og huskes i stedet for at blive spurgt om på ny tres gange i sekundet.

Fejlen, der kostede 24 point

Hvad der gav lidt

For fuldstændighedens skyld de tiltag, der står i enhver vejledning og hos os næppe var målbare:

Billedformater. Vores forside har næppe billeder – logoet er en SVG-fil. Hvor der forekommer billeder, kan konverteringen naturligvis betale sig; som hovedløftestang duer den kun ved billedtunge sider.

Formindske skrifter yderligere. Vi hoster selv to skriftfamilier og indlæser dem, der er nødvendige i det synlige område, på forhånd. Yderligere optimering ville være mulig, men rykker ikke værdien.

Serverplacering. Ofte anbefalet, i vores tilfælde irrelevant: tiden til den første byte lå allerede på 20 millisekunder. Den, der allerede ligger godt der, vinder intet ved et distributionsnet.

Fremgangsmåden til at gøre efter

1. Mål, før der ændres noget som helst. Mobil og desktop hver for sig, notér værdierne.
2. Find den største overførte fil. Næsten altid er det JavaScript. Spørgsmålet er ikke, hvordan man formindsker den, men om man har brug for den.
3. Kontrollér komprimeringen. Ikke om den er slået til, men for hvilke filtyper.
4. Tæl de blokerende forespørgsler. Hver stylesheet-fil i toppen holder den første billedopbygning tilbage.
5. Kontrollér for layoutspring uden bremse. Den ene test, der manglede hos os.
6. Mål på ny efter hver ændring. Ellers ved man til sidst ikke, hvad der virkede.

Hjælp mig med at oversætte min sides PageSpeed-rapport til en
rækkefølge. Vær streng; ros ingenting.

Mine måleværdier:
- Mobil: [pointtal], desktop: [pointtal]
- LCP, TBT, CLS pr. enhed: [værdier]
- Største overførte filer med størrelse: [liste]
- Render-blokerende forespørgsler: [liste]
- Meldinger fra rapporten: [indsæt tekst]

Om siden:
- Hvordan den er bygget: [CMS / statisk / byggesystem]
- Er JavaScript nødvendigt for det synlige indhold? [ja/nej]
- Hvordan leveres CSS? [eksternt / på forhånd / delvis på forhånd]

Opgaver:
1. Knyt hver melding til en årsag, og sig, hvilket nøgletal
   den påvirker – LCP, TBT eller CLS.
2. Sortér tiltagene efter virkning pr. indsats. Nævn ved
   hvert enkelt, hvor mange point det realistisk rykker og hvorfor.
3. Nævn de tiltag fra rapporten, der ved min byggemåde
   praktisk talt intet giver – og begrund det i stedet for
   bare at udelade dem.
4. Spørg ved hver stor JavaScript-fil først, om der er brug
   for den, før du foreslår at formindske den.
5. Gør opmærksom på det, hvis CSS kun leveres delvis på
   forhånd, og forklar, hvorfor det kan være værre for CLS
   end slet ikke.
6. Nævn, hvad jeg bør måle på ny efter hver ændring.

Opfind ingen måleværdier.

Konklusion

Pointtallet i sig selv er ikke målet – det er en måleværdi, ikke et forretningsresultat. Det, der tæller, er erfaringen bagved: en side, der er læsbar efter 1,4 sekunder, bliver læst af flere mennesker end en, der bruger seks sekunder. Hos mobile besøgende over mobilnet er forskellen større end nogen tekstoptimering.

Vejen dertil gik i vores tilfælde gennem et enkelt tilbagevendende spørgsmål: har vi brug for det? Fem ud af seks indgreb bestod i at fjerne noget, ikke i at tilføje noget.

Ofte stillede spørgsmål