3 praktiska förbättringar för en snabbare webbplats

Optimering av webbprestanda börjar ofta med det sidan laddar ner, snarare än med ett nytt ramverk. En restaurangmeny, en produktlista och en företagssida kan alla innehålla onödig bilddata, bibliotekskod och inbäddade widgetar.

Börja med en viktig sida på mobil och dator. Spara ett utgångsvärde och gå sedan igenom de tre kontrollerna nedan. Målet är att minska onödigt arbete för webbläsaren och samtidigt behålla sidans innehåll, funktion och utseende.

1. Gör vanliga bilder lättare

En liten bild kan ändå vara en stor nedladdning. Ett frilagt PNG-motiv, en kampanjbanner eller en bakgrundsdekoration kan innehålla mer data än uppgiften kräver. Flera sådana filer kan tillsammans bli tunga även när ingen ser särskilt stor ut.

Matmenyn på Five Guys startsida är ett användbart exempel. Fem nedladdningsbara PNG-källfiler som avsnittet hänvisar till väger tillsammans 1,29 MB. I ett lokalt kodningsexperiment konverterade jag källfilerna till WebP med kvalitet 80 och behöll mått och transparens. Resultatet väger ungefär 194 kB. Five Guys levererar redan WebP till webbläsaren; minskningen på 84,9% nedan gäller källfiler i ett lokalt experiment.

Lokalt experiment med källfiler: 1,29 MB PNG → 193,7 kB WebP, eller 84,9% mindre.

Five Guys meny, fångad den 19 oktober 2026. Källa: Five Guys.

Visa mätningar och källfiler

Nedladdade PNG-filer: totalt 1 286 664 byte. Sharp 0.35.5, WebP-kvalitet 80: 193 748 byte. Ingen ändrad upplösning; alfakanalerna behålls. Pommes frites-bilden ensam minskar från 438 779 till 57 414 byte. Jämför utseendet vid verklig visningsstorlek, särskilt kanter och små detaljer.

Enskilda filstorlekar; kB anges med decimala enheter.

Öppna det optimerade pommes frites-exemplet

Hitta tunga förfrågningar och välj format

Öppna DevTools → Network, stäng av cache, ladda om och filtrera på bilder. Sortera efter överförd storlek. Kontrollera filen som webbläsaren faktiskt hämtar: ett stort original i mediebiblioteket är inget problem om responsiv kod redan levererar en mindre version.

Bildförfrågningar från Five Guys, sorterade efter storlek. Vissa .png-adresser levererar WebP.

Öppna Network-bilden i full storlek

Anpassa fotons upplösning till visningsstorlek och pixeltäthet före komprimering. Ett 400 pixlar brett kort på en 2×-skärm kan behöva en 800-pixelsbild, snarare än en uppladdning på 4000 pixlar. Prova WebP eller AVIF där det stöds. Transparens betyder inte i sig att filen måste vara PNG. Granska resultatet i stället för att blint välja lägsta kvalitet.

För några enstaka filer är TinyPNG en praktisk början. För hela webbplatsen använder du bildhanteringen i ditt CMS eller CDN. I Next.js skapar next/image responsiva varianter, och korrekta sizes hjälper webbläsaren att välja rätt. Principen är densamma på alla plattformar: leverera den version skärmen behöver.

Kontrollera resultatet

Jämför original och resultat vid samma visningsstorlek. Kontrollera förfrågningar på mobil och dator, behåll width och height och se till att viktiga detaljer inte går förlorade. Ladda huvudbilden direkt och bilder längre ner senare. Mindre filer och en stabil layout löser olika problem, så kontrollera båda.

2. Granska kostnaden för äldre beroenden

Ett beroende som lades till för flera år sedan kan finnas kvar i webbläsarpaketet långt efter det ursprungliga beslutet. Uppdateringar av stödda paket är värda att granska, men ett högre versionsnummer garanterar inte en snabbare sida. Ingångspunkter, språkfiler, dubbla beroenden och oanvända funktioner påverkar också vad som skickas.

Moment.js visar varför det är värt att granska paketversioner. Den 19 oktober 2026 visade Bundlephobia 75,4 kB minifierat + gzip för 2.30.1 och 19,8 kB för 2.31.0, ungefär 74% mindre i tjänstens bygge. Utvecklarnas versionsanteckningar bekräftar den nya versionen och dess ändringar.

Bundlephobias uppskattade gzip-storlekar: Moment.js 2.30.1 · 2.31.0

Jämför samma ingångspunkt och nödvändiga språkfiler i ditt eget produktionsbygge. Den faktiska besparingen beror på vilken kod programmet skickar.

Uppdatera med eftertanke och skicka använd kod

Börja med de största skripten sidan laddar. Läs ändringsloggen, kontrollera kompatibiliteten, uppdatera låsfilen och bygg igen. Testa sedan funktionerna som använder paketet: formulär, datum, diagram eller navigering.

Granska även importerna. En sida som formaterar ett datum behöver inte automatiskt skicka alla språkfiler. Moments språkguide förklarar hur de kan begränsas. För enkla datumetiketter kan webbläsarens Intl.DateTimeFormat räcka. Använd dokumenterade modulära importer i andra bibliotek och ladda en tung redigerare eller ett diagram på sidorna som behöver det.

I WordPress och andra sidbyggare är motsvarande kontroll ofta listan med tillägg. Ta bort en oanvänd bildslider, ett socialt flöde eller dubbla analysintegrationer. Att stänga av en synlig funktion tar inte alltid bort dess skript, så kontrollera förfrågningarna efter ändringen.

Kontrollera resultatet

Jämför JavaScript som den byggda sidan laddar ner med samma komprimering och cacheinställningar. Använd inte storleken på node_modules eller npm-arkivet som ersättning. En paketanalys kan avslöja dubbla bibliotek och onödiga språkfiler, medan Network-panelen bekräftar vad besökarna faktiskt får.

3. Låt videor och widgetar vänta på sin tur

En videospelare, karta eller chatt kan hämta skript, stilmallar och öppna extra anslutningar innan någon använder den. På en restaurangs kontaktsida kanske besökaren bara behöver adress och öppettider. Att genast starta en hel interaktiv karta kan då innebära onödigt arbete.

Googles råd om tredjepartsinnehåll ger en användbar referens: senare inläsning av YouTube kan undvika ungefär 500 kB vid första laddningen.

Använd senare inläsning eller en förhandsbild som öppnas vid klick

För en iframe långt under den första skärmbilden börjar du med loading="lazy" eller motsvarande CMS-inställning. Reservera bredd och höjd så att texten runt den inte flyttas när innehållet visas. Den här lilla HTML-ändringen fungerar oberoende av frontendramverk.

<iframe
  src="https://www.youtube.com/embed/aKydtOXW8mI"
  title="YouTube-video"
  loading="lazy"
  width="560"
  height="315"
  allowfullscreen
></iframe>

Om spelaren ligger nära sidans topp kan senare inläsning hämta den nästan direkt. En statisk förhandsbild med en riktig uppspelningsknapp ger större kontroll och laddar spelaren först vid klick. Håll förhandsbilden lätt, ge knappen ett tillgängligt namn och kontrollera att videon går att starta med tangentbordet.

Tänk likadant för andra integrationer. En adress och en länk till vägbeskrivning kan räcka innan kartan öppnas. En chattknapp kan ladda hela widgeten på begäran. Låt den viktiga informationen finnas direkt och vänta med det kompletterande gränssnittet.

Kontrollera resultatet

Ladda om utan cache och granska tredjepartsförfrågningar innan du rullar eller klickar. Inbyggd senare inläsning börjar nära visningsområdet, så en iframe kan laddas innan den syns. Inläsning vid klick ska vänta på interaktion. Testa sedan videon, kartan eller chatten: färre förfrågningar är bara användbart om funktionen fungerar.

Ändra en sak och mät igen

Använd samma adress, enhetsprofil och testförhållanden före och efter varje ändring. Gör flera tester så att normal variation inte misstas för en förbättring. Jämför överförda byte tillsammans med laddningsmått: mindre bilder bevisar inte att en långsam server eller ett långkörande skript har åtgärdats. Behåll ändringar som förbättrar den uppmätta sidan utan att skada innehållet.

Kör ett gratis hastighetstest med NEKTIQA och granska Lighthouse-diagnostiken. Jämför en ny körning efter förbättringen och använd schemalagda tester och prestandahistorik för att se om resultatet håller efter kommande releaser.

Kör ett gratis hastighetstest · Utforska Lighthouse-övervakning