De fleste trege HubSpot-nettsider er trege av de samme grunnene: for mange stilark som blokkerer visningen, fonter fra Google, skjemaer som får siden til å hoppe, og skript som ingen bruker. Da vi rettet disse fire tingene på nettstedet til en kunde i rekruttering i oktober 2026, gikk mobilscoren i Lighthouse fra 60 til 90 på forsiden, fra 77 til 98 på kontaktsiden og fra 68 til 95 på artikkeloversikten. Her er grepene i den rekkefølgen de ga effekt.
1. Ett stilark per modul blokkerer visningen
HubSpot skriver ut ett eget stilark for hver modul som brukes på siden, og nettleseren venter på alle før den viser noe. Ti små filer kostet 0,8 til 1,7 sekunder på en simulert mobil. Løsningen er å la modulene som aldri ligger i første skjermbilde, laste stilarket sitt etter at siden er vist. Bunntekst, skjemaer, spørsmål og svar og kundesitater trenger ikke være klare før den besøkende har scrollet.
På et annet prosjekt i november gikk antallet blokkerende stilark på forsiden fra 14 til 5 med samme grep. Sammen med de andre endringene gikk mobilscoren i PageSpeed Insights fra 78 til 94.
2. Fonter fra Google er en ekstra omvei
Når fontene hentes fra Googles servere, må nettleseren først laste et stilark fra et annet domene, og deretter selve fontfilene. Det blokkerer visningen. Legg fontfilene i temaet i stedet, bruk bare vektene designet trenger, og sjekk hva som faktisk lastes ned.
Det siste er viktigere enn det høres ut. På ett prosjekt lastet siden den samme fontfilen tre ganger, én gang for hver vekt, fordi Google leverer én variabel fil for alle vektene under tre forskjellige navn. På et annet ble begge fontene lastet to ganger fordi forhåndslastingen pekte på en annen adresse enn stilarket.
3. Skjemaet får siden til å hoppe
Et HubSpot-skjema tegnes først når skjemaskriptet er lastet. Alt under skjemaet flytter seg da nedover, og det gir dårlig CLS. Ved å sette av plass til skjemaet før det er tegnet, gikk CLS på kontaktsiden fra 0,24 til 0. Høyden måles for hvert skjema på mobil og desktop.
4. Skript som ingen bruker
Bloggen lastet skript fra LinkedIn, Facebook og Twitter, til sammen rundt 270 KB, fordi delingsknappene var slått på i bloggens innstillinger. Designet brukte dem ikke. Å slå av innstillingene fjernet skriptene fra alle innlegg og oversiktssider.
Vi har den samme feilen på vår egen bloggforside. Lighthouse viser at LinkedIns skript blokkerer visningen i 1,4 sekunder, og at bildet øverst på siden venter i over 4 sekunder før det begynner å laste. Bildet som blir det største elementet på siden, skal lastes med en gang og med høy prioritet. Begge deler står på listen vår.
Det som ikke hjalp
Bildestørrelsene var allerede riktige, så å justere dem ga ingenting. Google Tag Manager, Google Analytics og HubSpots egne skript er faste kostnader som de fleste nettsteder har. Og poengsummen for god praksis stopper på rundt 79 på HubSpot-sider fordi HubSpot setter egne informasjonskapsler.
Mål riktig, ellers lyver tallene
En enkelt Lighthouse-kjøring kan svinge 10 til 20 poeng. Vi kjører derfor fem ganger per side og bruker medianen. Sammenlign også før og etter i samme økt. En gang målte vi alle sidene 5 til 15 poeng dårligere en time etter en forbedring, men det var maskinen og serveren, ikke endringen. Svartiden fra serveren varierte fra 0,1 til 1,4 sekunder for den samme adressen.
Sjekkliste for en raskere HubSpot-side
- La moduler under første skjermbilde laste stilarket etter visningen.
- Legg fontene i temaet, og bruk bare vektene designet trenger.
- Sjekk at ingen fontfil lastes to ganger.
- Sett av plass til skjemaer og bannere før de tegnes.
- Slå av delingsskript og andre tredjepartsskript som ikke brukes.
- Last det største bildet i første skjermbilde med en gang og med høy prioritet.
- Bruk HubSpots bildeskalering, så mobilen får en mindre fil.
- Mål fem ganger, og sammenlign i samme økt.
Spørsmål og svar
Hva er en god score i Lighthouse på mobil?
Over 90 er godt. Men det er feltdataene i Search Console, fra ekte besøkende, som teller i Google. Les mer i artikkelen om Core Web Vitals.
Er HubSpot tregere enn andre plattformer?
Nei, men HubSpot har noen egne feller, som ett stilark per modul og skript som slås på i innstillingene. Når de er håndtert, oppnår HubSpot-sider over 90 på mobil. Forsiden vår får 96, og det står mer om hvordan i casen om nye springagency.com.
Gjelder dette også WordPress?
Fremgangsmåten er den samme, men årsakene er ofte andre: mange utvidelser som laster hvert sitt skript, tunge sidebyggere og manglende hurtigbuffer. Mål først, finn det som blokkerer visningen, og fjern det som ikke brukes.
Hvor mye tid tar det å gjøre en side raskere?
Grepene over tar som regel noen dager på et eksisterende tema. Det meste er innstillinger og små endringer i modulene, ikke et nytt design.
Slik gjør vi det for kundene
Vi bygger fart inn fra første modul: Stilark, fonter og bilder settes opp etter reglene over, og hver side måles på mobil før lansering. Har dere en nettside som allerede er treg, starter vi med en måling og en liste over hva som gir mest effekt. Les mer om hvordan vi bygger nettsider.
Kilder
- web.dev: Web Vitals (lest 7. november 2026)
- Springs egne målinger med Lighthouse 12 i kundeprosjekter, oktober og november 2026, og på springagency.com 7. november 2026
