Hur vi sänkte en webbplats’ laddtid till under en sekund
Hastighet är inte ett ytligt mätetal — det påverkar rankning och intäkter. Här är det exakta prestandaarbete vi kör på varje bygge, i den ordning som betyder mest.
De flesta långsamma webbplatser är inte långsamma av mystiska skäl. De är långsamma på grund av en handfull förutsägbara problem som staplats på varandra — och de åtgärdas i en förutsägbar ordning. När en kund kommer till oss med en laddtid på tre sekunder behöver vi sällan ta till några exotiska knep. Vi behöver disciplin.
Det här är samma checklista som vi går igenom vid varje prestandauppdrag, ungefär i prioritetsordning. Varje steg är billigt i förhållande till sin effekt, och de flesta sajter känns dramatiskt snabbare redan efter de tre första.
Mät innan du rör någonting
Du kan inte förbättra det du inte mäter, och du kan definitivt inte bevisa en förbättring utan en baslinje. Vi startar varje uppdrag med fältdata, inte bara labbresultat.
- Labb — Lighthouse och WebPageTest för en kontrollerad, repeterbar ögonblicksbild.
- Fält — mätetal för verkliga användare (CrUX / RUM) för vad folk faktiskt upplever.
- Budget — ett hårt tak per rutt, så att prestandaförsämringar fångas upp i CI, inte i produktion.
Ett labbresultat på 100 betyder ingenting om dina verkliga användare sitter på mellanklassmobiler och instabila nätverk. Optimera för fältet.
Eliminera renderingsblockerande resurser
Den enskilt största vinsten på de flesta webbplatser är att flytta bort CSS och JavaScript från den kritiska renderingssökvägen. Webbläsaren kan inte rita upp sidan förrän den har parsat klart renderingsblockerande resurser — så ju färre de är, desto snabbare visas något.
// skjut upp allt som inte är kritiskt
const load = () => import('./analytics.js');
if ('requestIdleCallback' in window)
requestIdleCallback(load);
else setTimeout(load, 2000);Bädda in den lilla mängd CSS som behövs för den första skärmvyn, och ladda sedan resten asynkront. Skjut upp icke-kritiska skript. Målet är en första rendering (first paint) som inte väntar på något den inte absolut behöver.
Hantera bilder som en budget
Bilder är oftast det tyngsta på en sida, och det som är lättast att göra fel med. Tre regler täcker nittio procent av fallen:
- Leverera moderna format — AVIF eller WebP — med en fallback.
- Anpassa bildernas storlek till deras faktiska visningsdimensioner; leverera aldrig en hero-bild på 3000px till en yta på 600px.
- Använd lazy-loading för allt under skärmkanten, och reservera utrymme för att undvika layoutförskjutningar.
Cacha vid nätverkskanten (edge)
När väl sidan är slimmad är nästa fråga hur snabbt byten når användaren. En CDN med vettiga cache-headers förvandlar en 600 ms resa till ursprungsservern till en 30 ms edge-träff. För dynamiskt innehåll ger stale-while-revalidate dig omedelbara svar samtidigt som det uppdateras i bakgrunden.
Prestanda är en funktion. Vi budgeterar för det på samma sätt som vi budgeterar för alla andra delar av bygget.
Resultatet
I projektet som inspirerade till den här artikeln gick startsidan från en largest contentful paint på 3,1s till 0,9s, och de organiska konverteringarna ökade märkbart inom en månad. Inget av det var magi — bara checklistan ovan, tillämpad i rätt ordning.
Om din sajt känns trög och du inte är säker på var du ska börja, hör av dig — en snabb granskning brukar visa de två eller tre ändringar som gör störst skillnad.