Et raskere nettsted på én kveld: 9 trinn med måling før og etter

En besøkende venter ikke: åpnes en side sakte, forsvinner de, og søkemotorer tar hensyn til hastighet. Den gode nyheten er at det på de fleste små nettsteder er de samme tingene som gjør siden treg, og du kan rette dem på én kveld uten å bytte tema eller webhotell. Nedenfor finner du ni trinn. Hvert har tre linjer: hva du gjør, hvordan du sjekker (et skjermbilde, en kommando eller et tall) og hva som skjer hvis du hopper over det. Vi begynner og slutter med en måling, så du ser hva som hjalp.

Trinnene er uavhengige av hverandre, ta hvilke du vil. Én advarsel med en gang: tallene nedenfor kommer fra vårt eget testmiljø, ikke fra ditt nettsted. Dine vil være annerledes, det er retningen som teller.

Panelet ditt: «Hva kan forbedres» og «Systemtilstand» #

Åpne «Administrasjon av nettstedet → SEO og tilgjengelighet → Hva kan forbedres» og velg fanen «Hastighet»: den viser hva som ennå ikke er slått på på nettstedet ditt. Og i «System → Diagnostikk → Systemtilstand» finnes en blokk «Anbefalinger» nederst: den gir tips om hurtigbufferen, tidsplanen og OPcache.

Trinn 1. Mål først #

Hva du gjør. Åpne PageSpeed Insights, lim inn adressen til forsiden din og kjør sjekken for telefon. Eller i Chrome: utviklerverktøyene, fanen Lighthouse, «Analyser sideinnlasting». Skriv ned tre tall: LCP (når hoveddelen av siden kom til syne), CLS (hvor mye siden «hopper») og INP (hvor raskt nettstedet svarer på et trykk). Målene ifølge web.dev: LCP høyst 2,5 sekunder, INP høyst 200 millisekunder, CLS høyst 0,1, og dette for tre av fire besøkende (75. persentil). Slik sjekker du. Du har tre nedskrevne tall og datoen for målingen. Hvis du hopper over det. Du vet ikke om endringene hjalp. Husk to ting til. Resultatet fra Lighthouse varierer fra kjøring til kjøring: kjør det tre ganger og ta det midterste. Og en poengsum på 100 er ikke målet: Chrome-dokumentasjonen sier at den er svært vanskelig å nå og ikke forventet, og den grønne sonen begynner på 90.

Trinn 2. Ferdige sider til gjester #

Hva du gjør. I «Nettstedinnstillinger → Hastighet og vedlikehold» slår du på «Server ferdige sider til gjester». En side som er bygget for én gjest, serveres til de andre som den er, uten arbeid i databasen. Innloggede får sine egne sider som vanlig, og hurtigbufferen tømmer seg selv ved enhver endring i panelet. «Hvor mange sekunder de beholdes» kan du la være: fem minutter (300) er nok. Slik sjekker du. Be om forsiden to ganger:

curl -I https://example.com/
curl -I https://example.com/

Det andre svaret skal inneholde linjen X-Nex1on-Cache: hit. I testmiljøet vårt ble en side som ble bygget på nytt, levert på 0,6–0,8 sekunder, og en ferdig side på 0,12–0,17.

Hvis du hopper over det. Hver gjest får serveren til å bygge siden fra databasen på nytt. På et travelt nettsted fjerner dette trinnet mesteparten av arbeidet fra serveren.

Trinn 3. Komprimer HTML-en #

Hva du gjør. Samme sted slår du på «Komprimer HTML-sider»: overflødige mellomrom, linjeskift og kommentarer forsvinner fra sidene. Utseendet endres ikke, og administrasjonspanelet berøres ikke. Hvis en side ser feil ut etter at du har slått det på, slår du det av. Slik sjekker du. Sammenlign størrelsen på svaret før og etter:

curl -s https://example.com/ | wc -c

På testforsiden vår krympet svaret fra 157 til 138 KB, med omtrent 12 prosent. HTML-komprimering er mer nyttig sammen med ferdige sider (trinn 2): uten dem komprimerer serveren hver side på nytt for hver gjest, og «Systemtilstand» vil minne deg på det. Hvis du hopper over det. Sidene veier mer enn de trenger. Ingenting går i stykker, du betaler bare ekstra kilobyte for hver besøkende.

Trinn 4. Bare stilene siden trenger #

Hva du gjør. Slå på «Bare stilene siden trenger»: i stedet for flere fullstendige stilark får siden ett, med bare reglene som kan gjelde for den. Utseendet endres ikke. Slik sjekker du. Åpne sidekilden (Ctrl+U) og finn rel="stylesheet". I testmiljøet vårt ble tre stilark (omtrent 634 KB ukomprimert) erstattet av ett (157 KB). Hvis du hopper over det. Telefonen laster ned regler for sider den ikke har åpnet: forsiden åpnes merkbart tregere, særlig på mobilnett.

Trinn 5. Bilder #

Hva du gjør. I «Nettstedinnstillinger → Bilder og video» sjekker du tre ting. For det første: «Største bildebredde, piksler» er 0 som standard, som betyr ingen grense. Sett tallet du faktisk trenger (for eksempel 2000): store bilder skaleres ned ved opplasting med samme proporsjoner. Et bilde som er seks tusen punkter bredt, er for mye for en kolonne som er tusen bred. For det andre: «Bildekomprimering»: som standard står den på «Lokalt», og ingenting forlater nettstedet; den eksterne tjenesten TinyPNG gir lettere filer, men da sendes bildet ditt til en annens server. For det tredje: slå på «Bilder også som WebP»: nettstedet beholder også en lettere kopi og serverer den til nettleserne som ber om den. Kopier lages bare for nye opplastinger; for bilder som allerede er lastet opp, kjører du kommandoen php nex1on media:webp på serveren. La «Bildehint til nettleseren» stå på: motoren legger selv til størrelser, utsatt lasting under første skjermbilde og prioritet for hovedbildet.

Slik sjekker du. Se hva motoren har skrevet inn på siden:

curl -s https://example.com/ | grep -o '<img[^>]*>' | head -3

Bildene skal ha width og height (siden hopper ikke under innlasting), srcset og decoding="async". Hovedbildet på første skjermbilde har fetchpriority="high" og ingen loading="lazy"; de lenger ned på siden har loading="lazy". Slik er det ment: web.dev advarer uttrykkelig mot utsatt lasting av et bilde som er synlig med en gang, ellers åpnes siden tregere.
Hvis du hopper over det. Bilder er som regel den tyngste delen av en side, og ett uegnet bilde kan veie mer enn alt det andre til sammen.

Trinn 6. Skrifter #

Hva du gjør. Temaene som følger med motoren, laster ikke skrifter fra en server: teksten bruker skriftene som allerede finnes på den besøkendes enhet, så ingenting lastes ned. Legger du likevel til en egen skrift, følger du reglene fra web.dev: formatet WOFF2, bare stilene du trenger, font-display: swap (eller optional) og ikke forhåndslast alt. Slik sjekker du. I utviklerverktøyene, fanen Network, filteret Font: for et nettsted uten nedlastede skrifter er listen tom. Hvis du hopper over det. Hver ekstra skrift er en ekstra fil som blokkerer teksten eller får siden til å «hoppe» når skriften byttes inn.

Trinn 7. Tidsplanen og OPcache #

Hva du gjør. Åpne «System → Diagnostikk → Systemtilstand» og se på blokken «Anbefalinger». Står «E-post sendes når besøkende kommer inn» der, legger du til en tidsplan (cron) hos webhotellet, én gang i minuttet: anbefalingen viser selv den ferdige kommandoen. Da behandles e-post og bakgrunnsjobber uten besøkende, og sidene venter ikke på e-posten. Står «PHP OPcache er ikke tilgjengelig» der, ber du kundestøtten hos webhotellet om å slå det på: OPcache holder ferdig tolket PHP i minnet, og serveren tolker ikke de samme filene ved hvert besøk. Slik sjekker du. De tilsvarende radene i «Anbefalinger» forsvinner. Hvis du hopper over det. Nettstedet gjør ekstra arbeid ved hvert besøk, og du merker det først i rushtiden.

Trinn 8. Umiddelbare sideoverganger (valgfritt) #

Hva du gjør. Slå på «Umiddelbare sideoverganger»: når en besøkende holder pekeren over en lenke, henter nettleseren (Chrome og lignende) siden på forhånd, og klikket åpner den nesten umiddelbart. Det virker for gjester og for sider som allerede ligger i hurtigbufferen for ferdige sider, så slå på trinn 2 først. Visninger og tellere øker ikke av forhåndslastingen. Administrasjonspanelet, innlogging, filnedlastinger, lenker for bekreftelse av e-post og adresser med spørsmålstegn forhåndslastes aldri. Slik sjekker du. I utviklerverktøyene, fanen Network: når du holder pekeren over en lenke, dukker en forespørsel etter den siden opp i listen. Hvis du hopper over det. Ikke noe farlig: det er en bonus, ikke en nødvendighet.

Trinn 9. Mål etterpå #

Hva du gjør. Gjenta trinn 1 og sammenlign de tre tallene. Vil du se på ekte besøkende og ikke på laboratoriedata, slår du på «Faktisk hastighet hos besøkende»: den besøkendes nettleser måler LCP, CLS og INP og sender bare tallene når de forlater siden. IP-adresser, informasjonskapsler og opplysninger om nettleseren lagres ikke, roboter og folk som har slått på «ikke spor» telles ikke med, samtykke fra besøkende trengs vanligvis ikke fordi det ikke finnes personopplysninger, men sjekk med en jurist i ditt land. Resultatene vises i «SEO og tilgjengelighet → Hastighet». Slik sjekker du. Tre nye tall ved siden av de gamle. En laboratoriemåling viser én enhet og ett nettverk, mens det virkelige bildet er det de besøkende ser, så når de spriker, stoler du på det siste. Hvis du hopper over det. Du gjetter i stedet for å vite.

Hva denne listen ikke gjør #

Den fjerner overflødig arbeid, men den gjør ikke raskt det som er tungt av natur: et svært tungt tema, dusinvis av eksterne moduler og tellere eller et overbelastet webhotell. Er nettstedet fortsatt tregt etter alle trinnene, ser du i fanen Network etter hva som tar lengst tid å laste, og begynner der.