N1 Nex1on

En snabbare webbplats på en kväll: 9 steg med mätning före och efter

Färdiga sidor, komprimering, bara de stilar sidan behöver, bilder, schemat och OPcache: varje steg har tre rader – vad du gör, hur du kontrollerar det med en siffra eller ett kommando och vad som händer om du hoppar över det. Med mätning före och efter.

En besökare väntar inte: om en sida öppnas långsamt lämnar hen den, och sökmotorer tar hänsyn till hastigheten. Den goda nyheten är att det på de flesta små webbplatser är samma saker som gör sidan långsam, och att du kan åtgärda dem på en kväll utan att byta tema eller webbhotell. Nedan finns nio steg. Varje steg har tre rader: vad du gör, hur du kontrollerar det (en skärm, ett kommando eller en siffra) och vad som händer om du hoppar över det. Vi börjar och slutar med en mätning så att du ser vad som hjälpte.

Stegen är oberoende av varandra, välj vilka du vill. En varning direkt: siffrorna nedan kommer från vår egen testmiljö, inte från din webbplats. Dina blir annorlunda – det är riktningen som räknas.

Din panel: ”Att förbättra” och ”Systemstatus” #

Öppna ”Webbplatshantering → SEO och tillgänglighet → Att förbättra” och välj fliken ”Hastighet”: där listas det som ännu inte är påslaget på din webbplats. Och i ”System → Diagnostik → Systemstatus” finns ett block ”Rekommendationer” längst ned: det ger tips om cachen, schemat och OPcache.
”Att förbättra”, fliken ”Hastighet”: motorn talar själv om vad som ännu inte är påslaget
”Att förbättra”, fliken ”Hastighet”: motorn talar själv om vad som ännu inte är påslaget

Steg 1. Mät först #

Vad du gör. Öppna PageSpeed Insights, klistra in adressen till din startsida och kör kontrollen för mobil. Eller i webbläsaren Chrome: utvecklarverktygen, fliken Lighthouse, ”Analyze page load”. Anteckna tre siffror: LCP (när sidans huvuddel visades), CLS (hur mycket sidan ”hoppar”) och INP (hur snabbt webbplatsen reagerar på ett tryck). Målen enligt web.dev: LCP högst 2,5 sekunder, INP högst 200 millisekunder, CLS högst 0,1 – och det för tre av fyra besökare (75:e percentilen). Så kontrollerar du. Du har tre antecknade siffror och datumet för mätningen. Om du hoppar över det. Du vet inte om ändringarna hjälpte. Kom ihåg två saker till. Lighthouse-resultatet varierar mellan körningarna: kör tre gånger och ta det mittersta. Och 100 poäng är inte målet: enligt Chromes dokumentation är det extremt svårt att nå och förväntas inte, och den gröna zonen börjar vid 90.

Steg 2. Färdiga sidor för gäster #

Vad du gör. Slå på ”Servera färdiga sidor till gäster” under ”Webbplatsinställningar → Hastighet och underhåll”. En sida som har byggts för en gäst serveras till de andra som den är, utan något arbete i databasen. Inloggade får sina egna sidor som vanligt, och cachen töms av sig själv vid varje ändring i panelen. ”Antal sekunder att spara” kan du låta vara: fem minuter (300) räcker. Så kontrollerar du. Begär startsidan två gånger:
Bash
curl -I https://example.com/
curl -I https://example.com/
Det andra svaret ska innehålla raden X-Nex1on-Cache: hit. I vår testmiljö serverades en nybyggd sida på 0,6–0,8 sekunder och en färdig på 0,12–0,17.
Inställningarna ”Hastighet och underhåll”: färdiga sidor, HTML-komprimering och bildtips
Inställningarna ”Hastighet och underhåll”: färdiga sidor, HTML-komprimering och bildtips

Om du hoppar över det. Varje gäst får servern att bygga sidan från databasen på nytt. På en välbesökt webbplats tar det här steget bort större delen av serverns arbete.

Steg 3. Komprimera HTML-koden #

Vad du gör. På samma ställe slår du på ”Komprimera HTML-sidor”: överflödiga mellanslag, radbrytningar och kommentarer försvinner från sidorna. Utseendet ändras inte, och adminpanelen berörs inte. Om en sida ser fel ut efter att du slagit på det, stäng av det. Så kontrollerar du. Jämför svarets storlek före och efter:
Bash
curl -s https://example.com/ | wc -c
På vår teststartsida krympte svaret från 157 till 138 KB, med ungefär 12 procent. HTML-komprimering gör mer nytta tillsammans med färdiga sidor (steg 2): utan dem komprimerar servern varje sida på nytt för varje gäst, och ”Systemstatus” påminner dig om det. Om du hoppar över det. Sidorna väger mer än de behöver. Ingenting går sönder, du betalar bara extra kilobyte för varje besökare.

Steg 4. Bara de stilar sidan behöver #

Vad du gör. Slå på ”Bara de stilar sidan behöver”: i stället för flera fullständiga stilmallar får sidan en enda, med bara de regler som kan gälla för den. Utseendet ändras inte. Så kontrollerar du. Öppna sidans källkod (Ctrl+U) och sök efter rel="stylesheet". I vår testmiljö ersattes tre stilmallar (cirka 634 KB okomprimerat) av en (157 KB). Om du hoppar över det. Mobilen laddar ned regler för sidor den inte har öppnat: startsidan öppnas märkbart långsammare, särskilt i mobilnätet.

Steg 5. Bilder #

Vad du gör. Kontrollera tre saker under ”Webbplatsinställningar → Bilder och video”. För det första: ”Största bildbredd, pixlar” är 0 som standard, vilket betyder ingen gräns. Ange det värde du verkligen behöver (till exempel 2000): stora bilder skalas ned vid uppladdning med bibehållna proportioner. Ett foto som är sextusen punkter brett är för mycket för en kolumn som är tusen bred. För det andra: ”Bildkomprimering”: som standard är det ”Lokalt”, och ingenting lämnar webbplatsen; den externa tjänsten TinyPNG ger lättare filer, men din bild skickas då till någon annans server. För det tredje: slå på ”Bilder även som WebP”: webbplatsen sparar då också en lättare kopia och serverar den till de webbläsare som ber om den. Kopior skapas bara för nya uppladdningar; för redan uppladdade bilder kör du kommandot php nex1on media:webp på servern. Låt ”Bildtips till webbläsaren” vara påslaget: motorn lägger själv till storlekar, fördröjd inläsning nedanför första skärmen och prioritet för huvudbilden.
Inställningarna ”Bilder och video”: största bredd, komprimering och WebP
Inställningarna ”Bilder och video”: största bredd, komprimering och WebP

Så kontrollerar du. Se vad motorn har skrivit in i sidan:

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

Bilderna ska ha width och height (sidan hoppar inte under inläsningen), srcset och decoding="async". Huvudbilden på första skärmen har fetchpriority="high" och inget loading="lazy"; bilderna längre ned på sidan har loading="lazy". Det är avsiktligt: web.dev varnar uttryckligen för fördröjd inläsning av en bild som syns direkt, eftersom sidan då öppnas långsammare.
Om du hoppar över det. Bilder är oftast den tyngsta delen av en sida, och ett enda olämpligt foto kan väga mer än allt annat tillsammans.

Steg 6. Typsnitt #

Vad du gör. Temana som följer med motorn laddar inte typsnitt från någon server: texten använder de typsnitt som redan finns på besökarens enhet, så ingenting laddas ned. Om du ändå lägger till ett eget typsnitt, följ web.devs regler: formatet WOFF2, bara de stilar du behöver, font-display: swap (eller optional) och förladda inte allt. Så kontrollerar du. I utvecklarverktygen, fliken Network, filtret Font: för en webbplats utan inlästa typsnitt är listan tom. Om du hoppar över det. Varje tillagt typsnitt är en extra fil som blockerar texten eller får sidan att ”hoppa” när typsnittet byts in.

Steg 7. Schemat och OPcache #

Vad du gör. Öppna ”System → Diagnostik → Systemstatus” och titta på blocket ”Rekommendationer”. Om ”E-post skickas när besökare kommer in” står där, lägg till ett schema (cron) hos webbhotellet, en gång i minuten: rekommendationen visar själv det färdiga kommandot. Då behandlas e-post och bakgrundsjobb utan besökare, och sidorna väntar inte på e-posten. Om ”PHP OPcache är inte tillgängligt” står där, be webbhotellets support att slå på det: OPcache håller den tolkade PHP-koden i minnet, och servern behöver inte tolka samma filer vid varje besök. Så kontrollerar du. Motsvarande rader under ”Rekommendationer” försvinner. Om du hoppar över det. Webbplatsen gör extra arbete vid varje besök, och du märker det först vid toppbelastning.

Steg 8. Omedelbara sidbyten (valfritt) #

Vad du gör. Slå på ”Omedelbara sidbyten”: när en besökare för muspekaren över en länk hämtar webbläsaren (Chrome och liknande) sidan i förväg, och klicket öppnar den nästan direkt. Det fungerar för gäster och för sidor som redan finns i cachen för färdiga sidor, så slå på steg 2 först. Visningar och räknare ökar inte av förhämtningen. Adminpanelen, inloggningen, filnedladdningar, länkar för bekräftelse av e-post och adresser med frågetecken förhämtas aldrig. Så kontrollerar du. I utvecklarverktygen, fliken Network: när du för pekaren över en länk visas en förfrågan efter den sidan i listan. Om du hoppar över det. Inget farligt: det är en bonus, ingen nödvändighet.

Steg 9. Mät efteråt #

Vad du gör. Upprepa steg 1 och jämför de tre siffrorna. För att se på verkliga besökare i stället för labbdata, slå på ”Verklig hastighet hos besökare”: besökarens webbläsare mäter LCP, CLS och INP och skickar bara siffrorna när besökaren lämnar sidan. IP-adresser, cookies och uppgifter om webbläsaren sparas inte, robotar och personer som har slagit på ”spåra inte” räknas inte, och besökarens samtycke behövs oftast inte eftersom det inte finns några personuppgifter – men kontrollera med en jurist i ditt land. Resultaten visas under ”SEO och tillgänglighet → Hastighet”. Så kontrollerar du. Tre nya siffror bredvid de gamla. En labbmätning visar en enhet och ett nätverk, medan den verkliga bilden är det som dina besökare ser – så när de skiljer sig åt, lita på det senare. Om du hoppar över det. Du gissar i stället för att veta.

Vad den här listan inte gör #

Den tar bort onödigt arbete, men den kan inte göra snabbt det som är tungt till sin natur: ett mycket tungt tema, dussintals externa widgetar och räknare eller ett överbelastat webbhotell. Om webbplatsen fortfarande är långsam efter alla steg, titta på fliken Network efter vad som tar längst tid att läsa in och börja där.
Dela: Telegram WhatsApp

Läs också

Diskussion

Kommentarer

Ingen diskussion ännu

Ingen har kommenterat ännu. Bli först.

Anmäl det här inlägget