Webbutveckling 1 · område 7 · guide

Optimering: bilder, filer och laddtid

Alla exempel och alla siffror är hämtade ur referensprojekt/ – Vikstadssajten i två versioner. Den optimerade heter diskret/, den ooptimerade hardkodad/. Du kan öppna båda och mäta själv; det är meningen.

Det här området handlar inte om att lägga till något. Det handlar om att ta bort: kilobyte, filer och väntan. Sajten ska se likadan ut efteråt – den ska bara komma fram fortare.

Vad du kan efter guiden

• Säga vilket bildformat som passar till vad, och varför.
• Spara samma bild i flera format och storlekar och jämföra filstorlekarna.
• Skriva srcset och sizes så att en telefon hämtar en liten bild.
• Skriva picture så att den som kan AVIF får AVIF och alla andra får JPEG.
• Sätta width och height på varje bild och förklara vad det löser.
• Skjuta upp bilder som ligger långt ned med loading="lazy".
• Öppna nätverksfliken, läsa antal requests och total vikt, och mäta om efteråt.
• Köra Lighthouse på din publicerade sajt och förstå de fyra siffrorna.
• Svara på frågan "hur mycket väger min startsida?" med ett tal.

1. Varför vikten spelar roll

Din sajt ligger på GitHub Pages och öppnas på skolans wifi. Den känns snabb. Det säger ingenting om hur den känns på en telefon med två streck täckning utanför Vikstad.

En sida som väger 1 MB tar ungefär tio sekunder att ladda på en dålig mobiluppkoppling. Samma sida på 50 kB tar under en sekund. Skillnaden mellan de två är oftast en enda bild.

Så här ser reservatets startsida ut i de två versionerna, mätt vid 1280 pixlars bredd:

Tjugotre gånger tyngre. HTML:en, CSS:en och skripten är i praktiken lika stora i båda – det är bilden som bär hela skillnaden, och det är därför den här guiden lägger nio av fjorton avsnitt på bilder.

Det finns en andra anledning. Den som sitter på mobildata betalar för varje megabyte. En sajt som skickar en bild på 1 MB när 11 kB hade räckt har inte bara gjort besökaren otålig, den har gjort av med hens pengar.

2. De fyra bildformaten

Samma foto, samma bredd på 800 pixlar, sparat fyra gånger:

PNG är fyrtiotvå gånger större än AVIF på det här motivet. Det är inte för att PNG är dåligt – det är för att PNG är gjort för fel sorts bild.

Varför skillnaden är så stor

PNG sparar varje pixel exakt. Det kallas förlustfri kompression: öppnar du filen får du tillbaka precis det du sparade. På en skärmdump av en meny, eller en logotyp med fem färger, är det både litet och rätt.

JPEG, WebP och AVIF sparar ungefär rätt. Det kallas förstörande kompression: de kastar bort detaljer som ögat ändå inte ser – små färgskiftningar i en himmel, till exempel. På ett foto, där nästan varje pixel är lite annorlunda än sin granne, blir vinsten enorm. På en logotyp blir resultatet suddiga kanter.

Vilket ska du välja

Prova själv

Öppna referensprojekt/diskret/bilder/ i utforskaren och sortera på storlek. Jämför mossen-800.png med mossen-800.avif. Öppna båda i webbläsaren och titta efter skillnaden. Du hittar den inte.

3. Komprimering: kvalitet mot kilobyte

När du sparar en JPEG, WebP eller AVIF får du välja kvalitet, oftast på en skala 0–100. Det är inte en skala från "dålig" till "bra" – det är en skala från "litet" till "stort".

Bilderna i referensprojektet är sparade med kvalitet 72 för JPEG och WebP, och 50 för AVIF. AVIF:s skala är inte samma skala: 50 där motsvarar ungefär 75 i JPEG.

Regeln som fungerar: börja på 75. Titta på bilden i full storlek. Ser du inget fel, gå ner till 65 och titta igen. Den punkt där du börjar se fyrkantiga fält i mjuka ytor – himmel, hud, dimma – är för långt. Gå tillbaka ett steg.

De fält du ser när du gått för långt kallas artefakter. De syns först i ytor med mjuka övergångar, sist i ytor med mycket detaljer.

Vad du komprimerar med

Du behöver inget program. Två vägar räcker för den här kursen:

Squoosh räknar om filstorleken medan du drar. Det är det snabbaste sättet att få känsla för var gränsen går.

Spara aldrig om en JPEG många gånger. Varje sparning kastar bort mer. Utgå från originalet varje gång du gör en ny version.

4. Rätt dimensioner

Det här är den vanligaste och dyraste missen, och den syns inte på skärmen.

En bild från en telefonkamera är ungefär 4000 pixlar bred. Lägger du in den på en sajt där den visas 640 pixlar bred kommer webbläsaren att skala ner den – efter att ha hämtat hela filen. Besökaren har betalat för 4000 pixlar och fått se 640.

Den hårdkodade versionen gör exakt det:

<img src="bilder/mossen-original.jpg" style="width: 100%"
     alt="Näckrosmossen strax före soluppgången.">

Filen är 2400 pixlar bred och väger 1 125 kB. Rutan den visas i är 640 pixlar. style="width: 100%" gör att det ser rätt ut – och det är därför felet lever vidare i så många sajter.

Skala ner bilden till den storlek den faktiskt visas i, innan du lägger in den. Är du osäker på vilken storlek det är: se avsnitt 11, nätverksfliken säger det.

Behöver du bilden i flera storlekar för att sajten är responsiv, ska du inte välja en – då är srcset svaret, och det står i avsnitt 6.

Prova själv

Öppna hardkodad/index.html, högerklicka på fotot och välj Öppna bild i ny flik. Titta på hur stor den är. Gör samma sak i diskret/index.html.

5. width och height – texten som hoppar

Du har sett det: du börjar läsa, en bild laddas in ovanför, och texten hoppar nedåt så att du tappar raden. Det heter layout shift och beror på att webbläsaren inte visste hur hög bilden skulle bli.

Lösningen är två attribut:

<img src="bilder/karta.svg" width="640" height="400"
     alt="Karta över reservatet.">

width och height är inte storleken bilden visas i – CSS bestämmer den. De är bildens proportioner, och de räcker för att webbläsaren ska kunna räkna ut hur hög rutan blir vid vilken bredd som helst. Rutan reserveras direkt, och ingenting hoppar.

Talen skrivs utan enhet. width="640px" är fel och gör att validatorn klagar.

I stilmallen hör de här två raderna ihop med attributen:

.foto img {
  width: 100%;
  height: auto;
}

width: 100% gör att bilden fyller sin ruta, height: auto att proportionerna behålls. Utan height: auto sträcks bilden ut.

Referensprojektet lägger till en tredje rad som gör samma jobb ännu tydligare:

.foto img {
  aspect-ratio: 3 / 2;
}

Den säger rakt ut vilket förhållande rutan har, oavsett vad som ligger i den.

6. srcset och sizes

Nu kommer det som gör skillnad på riktigt. En telefon ska hämta en liten bild, en stor skärm en stor. Samma HTML, olika filer.

<img src="bilder/mossen-800.jpg"
     srcset="bilder/mossen-400.jpg 400w,
             bilder/mossen-800.jpg 800w,
             bilder/mossen-1600.jpg 1600w"
     sizes="(min-width: 60rem) 640px, 94vw"
     width="1600" height="1067"
     alt="Näckrosmossen strax före soluppgången.">

Fyra saker händer här:

srcset säger vad som finns. sizes säger vad som behövs. Webbläsaren väljer.

sizes är ett löfte du måste hålla

sizes="(min-width: 60rem) 640px, 94vw" läses så här: är fönstret minst 60rem brett blir bilden 640 pixlar, annars 94 % av fönsterbredden.

Det är inte något webbläsaren kontrollerar – det är något du lovar. Och det måste stämma med din CSS:

.foto {
  max-width: 40rem;
}

40rem är 640 pixlar. Ändrar du den raden utan att ändra sizes hämtar webbläsaren fel storlek, och hela poängen är borta.

Kontrollera att löftet håller: öppna sidan, högerklicka på bilden, Inspektera, och titta på Rendered size i rutan som kommer upp. Den ska vara samma tal som sizes lovade.

Vid 1280 pixlars fönsterbredd väljer webbläsaren mossen-800 ur exemplet ovan – det minsta alternativet som är minst 640 pixlar brett – och lägger ut det på exakt 640 pixlar. Vid 400 pixlars bredd tas mossen-400.

Varför inte bara den största

Därför att den väger 83 kB och den lilla 9 kB, och telefonen ser ingen skillnad.

7. picture – flera format

srcset löser storleken. picture löser formatet: den som kan AVIF ska få AVIF, och alla andra ska få något som fungerar.

<picture>
  <source type="image/avif"
          srcset="bilder/mossen-800.avif 800w,
                  bilder/mossen-1600.avif 1600w"
          sizes="(min-width: 60rem) 640px, 94vw">
  <source type="image/webp"
          srcset="bilder/mossen-800.webp 800w,
                  bilder/mossen-1600.webp 1600w"
          sizes="(min-width: 60rem) 640px, 94vw">
  <img src="bilder/mossen-800.jpg"
       srcset="bilder/mossen-800.jpg 800w,
               bilder/mossen-1600.jpg 1600w"
       sizes="(min-width: 60rem) 640px, 94vw"
       width="1600" height="1067" decoding="async"
       alt="Näckrosmossen strax före soluppgången.">
</picture>

Regeln: webbläsaren tar första source den förstår, uppifrån och ner. Därför står AVIF först och WebP sedan. Förstår den ingen av dem, eller är det en gammal webbläsare som inte kan picture alls, landar den på img längst ned.

Tre saker att hålla reda på:

1. img är obligatorisk och ska ligga sist. alt, width och height skrivs på den, inte på source.
2. Ordningen är avgörande. Står JPEG först får ingen någonsin AVIF.
3. sizes upprepas på varje rad. Det är tjatigt och det ska det vara.

När du inte behöver picture

Har du bara ett format – och JPEG räcker långt – hoppa över picture och skriv bara img med srcset, som i avsnitt 6. Det är bättre att göra storlekarna rätt och strunta i formaten än tvärtom: vinsten i avsnitt 6 är större.

8. SVG när det passar

Reservatets karta är en SVG på 3,1 kB. Samma karta som PNG i den bredd den visas skulle väga runt 60 kB, och bli suddig på en skärm med hög upplösning.

SVG är ritinstruktioner, inte pixlar. Filen säger "en linje härifrån dit, ett fält i den här gröna" och webbläsaren ritar upp den i den storlek som behövs. Därför är en SVG lika skarp på en telefon som på en 4K-skärm, och därför behöver den varken srcset eller flera storlekar.

Du har redan gjort SVG:er i område 2. Det som är nytt här är att veta när det är rätt val – och att en SVG med tusen detaljer kan väga mer än ett foto.

width och height gäller för SVG också, av samma skäl som i avsnitt 5.

9. loading="lazy"

En bild långt ned på sidan behöver inte hämtas förrän någon skrollar dit.

<img src="bilder/trana.svg" width="480" height="360" loading="lazy"
     alt="En trana i profil.">

Ett attribut. Webbläsaren gör resten, och gör det bra.

Men inte på den översta bilden. Den som syns direkt när sidan öppnas ska hämtas direkt. loading="lazy" på den gör tvärtom vad du vill: den kommer senare, och det är just den bilden besökaren väntar på.

Regeln i referensprojektet är därför:

decoding="async" står på fotot i exemplet. Den säger att webbläsaren får rita upp resten av sidan medan bilden packas upp. Den är liten, ofarlig och sällan avgörande – ta med den om du vill, hoppa över den om den förvirrar.

10. Antal filer

Vikten är den ena halvan. Den andra är hur många gånger webbläsaren måste fråga servern om något. Varje fil är en request, och varje request kostar tid även om filen är liten.

Reservatets startsida hämtar fem filer: HTML, CSS, två skript och en bild. Det är lite. En sajt med ett CSS-ramverk, tre typsnitt, ett ikonbibliotek och fem skript kan hämta femtio.

Vad du kan göra i den här kursen:

Det du inte ska göra: klistra ihop dina moduler till en enda fil för att spara requests. Vinsten är några hundradelar, och du förlorar det som gör dem läsbara. Riktiga sajter gör det med ett byggsteg som skriver ihop filerna automatiskt – och byggsteg är inte den här kursen.

11. Mät själv: nätverksfliken

Allt ovanför är gissningar tills du mätt. Nätverksfliken i webbläsaren säger exakt vad din sajt skickar.

1. Öppna din publicerade sajt.
2. Högerklicka, Inspektera. Välj fliken Nätverk (Network).
3. Ladda om sidan med fliken öppen. Det här steget glöms alltid bort – utan det är listan tom.
4. Läs raden längst ned: antal requests och överförd mängd data.

Två inställningar som ändrar vad du ser

Disable cache (kryssrutan överst) tvingar webbläsaren att hämta allt på nytt. Utan den mäter du en sida som redan ligger i din egen dator, och siffrorna blir orimligt bra. Kryssa i den när du mäter.

Strypningen (rullgardinen som står på No throttling) låtsas att du sitter på en långsam uppkoppling. Välj Slow 4G och ladda om. Det är i den vyn skillnaden mellan 51 kB och 1 163 kB blir något du känner, inte något du läser.

Sortera på storlek

Klicka på Size-rubriken. Den tyngsta filen hamnar överst, och det är nästan alltid en bild. Den raden är din uppgift.

Prova själv

Mät din egen publicerade sajt, med Disable cache i och Slow 4G valt. Skriv ner antal requests, total vikt och tid. Det är den mätningen Projekt 6 vill se, och den du ska kunna jämföra med i mars.

Exempelsajten går inte att mäta så här, och det är i sig värt att veta: en sida som du öppnar från en mapp är inte hämtad över nätet. Storlekarna blir filstorlekar, strypningen gör ingenting och Lighthouse vägrar köra. Skillnaden mellan de två versionerna ser du i stället på filstorlekarna i bilder/, som i avsnitt 2 – eller genom att starta en liten server i mappen:

python -m http.server 8000

Då ligger sajten på http://localhost:8000/ och beter sig som en riktig sajt.

12. Lighthouse

Lighthouse är ett verktyg som är inbyggt i Chrome och Edge. Det laddar din sida, mäter, och ger fyra betyg på 0–100.

1. Inspektera, fliken Lighthouse.
2. Välj Mobile, kryssa i alla fyra kategorierna.
3. Analyze page load. Det tar ungefär en halv minut.

Kör det på den publicerade adressen, inte på filen i Codespaces. En sida som öppnas från en mapp beter sig inte som en sida på en server.

Läs listan, inte siffran

Under betyget står Opportunities och Diagnostics. Där står vad som är fel, med hur många kilobyte eller millisekunder det kostar. De vanligaste för en sajt i den här kursen:

Jaga inte 100. En statisk sajt på GitHub Pages med optimerade bilder landar normalt på 90–100 i Performance, och de sista poängen kostar mer än de smakar. Det som betyder något är att listan över Opportunities är tom på de fem raderna ovan.

13. Typsnitt

Ett typsnitt är en fil som ska hämtas som vilken annan fil som helst. Tre teckensnittsvikter från Google Fonts är tre filer på omkring 20–40 kB var, och de hämtas innan texten kan ritas ut.

Reservatets stilmall använder systemtypsnitt: de som redan finns i besökarens dator eller telefon. De kostar noll kilobyte och noll väntan.

--typsnitt: "Segoe UI", system-ui, -apple-system, sans-serif;

Vill du ha ett eget typsnitt ändå – och det är ett rimligt designval – håll dig till reglerna:

14. Cache, kort

När webbläsaren hämtat en fil sparar den den lokalt ett tag. Nästa sida på samma sajt som använder samma stil.css hämtar inte om den – den tar sin kopia. Det är därför en sajts andra sida alltid känns snabbare än den första.

Tre konsekvenser som gäller dig:

1. En delad stilmall är billigare än stil i varje sida. Den hämtas en gång och används på alla sidorna. Det är ytterligare ett skäl till regeln från område 3.
2. Du kan inte lita på din egen webbläsare när du mäter. Kryssa i Disable cache, annars mäter du din cache och inte din sajt.
3. Du styr inte cachen på GitHub Pages. Servern bestämmer hur länge filerna sparas. Byter du ut en bild men behåller filnamnet kan besökare få den gamla ett tag. Nytt innehåll, nytt filnamn är den enkla lösningen.

Det räcker för den här kursen. Cache-styrning på riktigt är serverkonfiguration, och det ligger i nästa kurs.

15. Ta det längre

För dig som vill mot C och A.

Mät före och efter, och skriv ner det

Projekt 6 vill ha en mätning före och en efter. Gör den i nätverksfliken med Disable cache i, på den publicerade adressen, på samma sida båda gångerna. Skriv i README.md:

Startsidan, mätt med Disable cache och Slow 4G:
  Före:  14 requests, 2,1 MB, 9,8 s
  Efter:  9 requests, 180 kB, 1,4 s
Största posten före: hero.jpg, 1,8 MB (4032 px bred, visas i 640 px)

Tre rader som säger mer än en sida text. Det som bedöms är att du kan förklara varför siffran ändrades, inte att den ändrades mycket.

Kontrollera att sizes stämmer på riktigt

Öppna nätverksfliken, sätt fönstret smalt, ladda om, och titta på vilken av dina filer som faktiskt hämtades. Dra ut fönstret brett, ladda om, titta igen. Hämtas samma fil båda gångerna stämmer inte sizes med din CSS.

Bildens förhållande i två storlekar

Behöver din bild vara stående på telefon och liggande på desktop är picture med media svaret – två olika beskärningar, inte bara två storlekar:

<picture>
  <source media="(max-width: 40rem)"
          srcset="bilder/hero-staende.jpg">
  <img src="bilder/hero-liggande.jpg" width="1600" height="900"
       alt="...">
</picture>

Det kallas art direction och är det enda fallet där media hör hemma i picture. För vanlig storleksväxling är det sizes som gäller.

Ett ord om verktyg som gör det åt dig

Riktiga sajter genererar sina bildstorlekar automatiskt vid bygget. Det referensprojektet gör med verktyg/gor-bilder.py är samma idé i liten skala: ett skript, en källbild, elva filer ut. Titta gärna i det – det är bara två sidor Python, och kvalitetsvärdena du läste om i avsnitt 3 står överst.

16. Felsökning

17. Snabbreferens

Bild med flera storlekar

<img src="bild-800.jpg"
     srcset="bild-400.jpg 400w,
             bild-800.jpg 800w,
             bild-1600.jpg 1600w"
     sizes="(min-width: 60rem) 640px, 94vw"
     width="1600" height="1067" alt="Beskrivning">

Bild med flera format

<picture>
  <source type="image/avif" srcset="bild-800.avif">
  <source type="image/webp" srcset="bild-800.webp">
  <img src="bild-800.jpg" width="800" height="533"
       alt="Beskrivning">
</picture>

Bild långt ned på sidan

<img src="bild.jpg" width="480" height="360" loading="lazy"
     alt="Beskrivning">

Rutan som inte hoppar

.foto img {
  width: 100%;
  height: auto;
  aspect-ratio: 3 / 2;
}

Formaten

Mätningen

18. Ordlista