Hvordan jeg forbedret Lighthouse-ytelsen ved å legge til et bilde

Bilder og videoer er trege å laste, og de fleste bloggere og selskaper kommer etter hvert til den vanskelige avgjørelsen om de skal ta UI-toget og inkludere et heltebilde eller gå for ytelse og vinke farvel til helten. Min tur til nettstedet mitt var å gå begge veier!

I denne artikkelen

  1. Konsekvensen av å laste inn bilder
  2. Web Vitals – største innholdsrike maling
  3. Inkonsekvensen ved å få en stor, størst innholdsrik maling (LCP)-poengsum
  4. Hvordan jeg optimaliserte Largest Contentful Paint (LCP) med et bilde
  5. Velge mellom SVG, PNG og WebP
  6. Et forsøk på å bruke en SVG- og CSS-løsning
  7. Optimalisering av WebP-bildestørrelse
  8. Visning av bilder i passende størrelse
  9. Flotte bildeverktøy å bruke
  10. Tilbake til nettverksforsinkelse
  11. Konklusjon

Virkningen av å laste inn bilder

Et bilde er i gjennomsnitt tusen ganger så ødeleggende for ytelse som tusen ord. Det er ikke en spøk. Nettsteder er vanligvis kodet med UTF-8, som bruker 1-4 byte per tegn, bare 1 byte for standard ASCII-bokstaver. Gjennomsnittlig engelsk ord er omtrent 5 tegn, så tusen ord vil være omtrent 5 kB store. Et raskt google-søk på gjennomsnittlige bildestørrelser på nettet forteller oss at det er i omtrent samme størrelsesorden som de 5 kB med ord.

Husk at det bare er et gjennomsnittstall. Helte- og bannerbilder som er ment å dekke den halve eller hele visningsporten til et nettsted, er som oftest minst flere hundre ganger så store som det, kanskje til og med tusen hvis de er dårlig optimalisert.

Bildestørrelsen er ikke den eneste tidstyven når du laster bilder på nettet. Bilder hentes vanligvis av nettleseren i en egen nettverksforespørsel, noe som betyr at det vil være en ekstra serverforespørsel som medfører ekstra latens, og forespørselen kan til og med måtte stå i kø en tid av nettleseren. Som vi vil se senere i denne artikkelen, kan dette faktum ha en betydelig innvirkning.


Teslas 1,2 MB enorme monsterbanner

Som et eksempel er Teslas bannerbilde av deres Model 3 Tesla 1,2 MB stort og tar 364 ms å laste etter å ha ventet 2 sekunder på å starte nedlastingen på nettverket mitt med en ganske gammel MacBook Pro. Ifølge Google vil 53 % av brukerne forlate et mobilnettsted som tar mer enn 3 sekunder å laste. Bare lasting av bildet bruker en betydelig andel av den kvoten, og før det er ferdig gjengitt har det gått den tiden.


Lastetid for Tesla Model 3-bilder i Chrome-inspektør


Tesla Model 3 akselererer fra 0 til 100 km/t på 3,3 s, det er raskere enn det tar å laste inn bildet av den

Web Vitals – største innholdsrike maling

Det er mange måter å måle ytelse for et nettsted. Google har initiert Web Vitals, som er en haug med beregninger som Google mener er viktige for å betjene en god brukeropplevelse. En av beregningene er Largest Contentful Paint (LCP), som måler tiden før den største teksten eller bildet på siden er synlig.

Google har gitt ut et åpen kildekodeverktøy kalt Lighthouse som kan brukes til å måle nettvital og få score og retningslinjer. Den er innebygd i Chrome Dev Tools, men kan også brukes på PageSpeed ​​Insights. Beregningene som vises er ment å brukes som en veiledning og kan variere mellom hver test.

Selv om Lighthouse kun er til veiledning, brukes de fleste eller alle beregningene direkte eller indirekte av Google for å rangere nettstedet ditt når det blir indeksert av Google. Det er derfor ikke bare viktig for god UX, men også for SEO.


Største innholdsrike maling er en av beregningene en Lighthouse-test scorer deg på

Inkonsekvensen ved å få en stor, største innholdsrik maling (LCP)-poengsum

Mens jeg kjørte Lighthouse-hastighetstester på nettstedet mitt, la jeg merke til at jeg fikk veldig forskjellige poengsum på forskjellige sider. Min hovedside som viser artikler og en artikkelside scoret betydelig forskjellig på ytelsesmålingen, selv om begge sidene var bygget nesten på samme måte med et profilbilde, mye tekst og noen få bilder. På den tiden så sidene like ut som i dag, men de hadde ikke noe heltebilde den gang.

Synderen for det dårlige testresultatet på artikkelsiden var LCP-score. Lighthouse-testen gir et skjermbilde av LCP, som gjorde det klart hvorfor artikkelsiden fikk dårligere LCP-score.

Siden hovedsiden hadde noen ekstra brikkekomponenter under profilbildet, var profilbildet den største innholdsrike malingen på den siden. Ingen av de dynamiske bloggartiklene ble noen gang inkludert i visningsporten på en mobilenhet.


LCP på landingssiden min er profilbildet

I mellomtiden, på artikkelsiden, ble den første delen av bloggartikkelen inkludert i den mobile visningsporten, noe som betyr at Lighthouse lette etter LCP i det området også. Konsekvensen var at hver gang en artikkel begynte med et bilde, ble det bildet behandlet som LCP, siden det var et større bilde enn mitt profilbilde. Hvis bildet ble utelatt, ble profilbildet oppdaget som LCP.


LCP på en artikkelside med et bilde var artikkelbildet

Hvordan jeg optimaliserte Largest Contentful Paint (LCP) med et bilde

Jeg visste at jeg ikke kunne fortsette med en upålitelig LCP-score, og det var ingen god løsning å aldri starte en artikkel med et bilde. Jeg måtte finne en måte å få en forutsigbar poengsum på uavhengig av hvilket innhold jeg inkluderte i selve artikkelen.

Med det i tankene bestemte jeg meg for å legge til et bilde som er større enn noe potensielt artikkelbilde, jeg bestemte meg for å legge til et heltebilde. På den måten kunne jeg i det minste få kontroll over hvilket bilde som var størst og dermed ta kontroll over LCP-score.

For at dette skulle være effektivt, måtte jeg bruke et heltebilde som var raskt å laste. Ingenting ville noen gang vært bedre hvis jeg gjorde som Tesla har gjort, og la til et gigantisk banner på størrelsen 1,2 MB. Jeg måtte bruke et lite optimalisert bilde som kunne fylle halve visningsporten, et som ikke skrek dårlig oppløsning.


Ved å legge til et heltebilde kunne jeg kontrollere hvilket bilde jeg ville være LCP

Velg mellom SVG, PNG og WebP

Vel, jeg har egentlig aldri vurdert å bruke et PNG-bilde for heltebildet, det er ikke måten å optimalisere nettbilder på. Selv om jeg alltid har en PNG-kopi rundt for andre bruksområder. For eksempel, når du legger ut artikler på DEV-forumet, støtter de ikke WebP-bilder som skal lastes opp som heltebilder.

Det var vanskeligere å velge mellom SVG og WebP. SVG-bilder kan være veldig små hvis bildet består av et repeterende mønster eller et abstrakt mønster som bruker bare noen få farger og former, bare fordi de består av vektorer som kan skaleres til en hvilken som helst oppløsning. På den annen side vil de vokse seg latterlig store for grafisk-tunge bilder med mange farger og skygger, på grunn av det høye antallet vektorer som kreves for å representere bildet.

Tvert imot kan WebP komprimere bilder effektivt ved å forutsi og gjenbruke piksler, noe som gjør det overlegent PNG- og JPEG-formater. Så avgjørelsen måtte være mellom et minimalt abstrakt heltebilde i SVG-format eller et realistisk fotografi i WebP-format.

Et forsøk på å bruke en SVG- og CSS-løsning

Som du kan se på nettstedet mitt, har jeg en murvegg som heltebilde (så lenge du ikke endrer temaet til mørk modus). Det bildet er i WebP-format, men mitt første forsøk var faktisk å bruke et SVG-bilde. Murveggen jeg prøvde med da var mindre realistisk og mer tegneserieaktig, som ble servert perfekt i SVG-format.

For å bli kvitt den ekstra nettverksforsinkelsen ved å hente et bilde fra en server, innebygde jeg bildet som en CSS-bakgrunn i en data-URI, noe som egentlig bare bør gjøres når det er snakk om små bilder på grunn av cache- og parsing-årsaker.

Virket det? Nei, det gjorde den ikke, CSS-bakgrunnen ble ikke oppdaget som LCP. Tross alt er det verken et vanlig bilde eller en tekst, så det samsvarer med Googles beskrivelse av LCP.


Googles største innholdsrike malingsdefinisjon

Selv om en CSS-løsning ikke fungerte som forventet, fungerte det å bruke SVG-bildet i et vanlig HTML-bildeelement (eller for å være nøyaktig, Next.js Image-komponent i mitt tilfelle). Den eneste grunnen til at jeg forkastet den løsningen var fordi jeg ikke var fornøyd med den tegneserieaktige stilen til murveggen, jeg følte at jeg ønsket en mer realistisk murvegg.

Optimalisering av WebP-bildestørrelse

Etter å ha bestemt seg for å bruke et fotografi av en murvegg som heltebilde, var det på tide å optimere størrelsen på den uten å miste for mye kvalitet. Jeg følte at jeg ikke trengte et piksel-perfekt fotografi, det var greit for meg å ofre kvalitet for lastehastighet. Det første bildet var et JPEG-monster på 18,1 MB og en oppløsning på 6000 x 4000, så det kunne optimaliseres mye.


Rådgiveren min beklager på mine vegne for et veldig dårlig ordspill

Nå, komprimering av bilder er slett ikke det jeg er god til, jeg er sikker på at kompresjonsfanatikere ville ha slått meg med komprimeringsbibelen sin hvis de ikke allerede hadde komprimert den til et hellig skrift på noen få kilobyte. Men jeg lyktes med å komprimere bildet mye, og komprimere det til et 2560 x 1707 WebP-bilde på 37 kB. Det er klart at jeg mistet en enorm mengde kvalitet, det må nevnes.


Jeg ble så redd av å se ham at jeg lukket munnen min

Tilnærmingen jeg brukte for å komprimere bildet mitt var å bruke en online kopi av Photoshop kalt Photopea. Det eneste jeg gjorde var å endre størrelsen på bildet og lagre det i et annet format, og velge å senke kvaliteten mens du lagrer.


Photopeas lagringsdialog lar deg forhåndsvise bildekvalitet og bildestørrelse samtidig

Visning av bilder i passende størrelse

Et heltebilde med 2K-oppløsning er greit for en 4K-skjerm, men å vise et 2K-bilde til en mobilenhet er ikke optimalt. Små enheter bør serveres små bilder. Det kan oppnås ved å bruke et HTML-bildeelement med et srcset.

I mitt tilfelle trengte jeg ikke å håndtere det, fordi nettstedet mitt er skrevet med Next.js. De har en innebygd bildekomponent som kan brukes til å optimalisere bildelasting. På bloggen min kan du finne en veiledning for implementering av et heltebilde med den bildekomponenten, den forklarer også fordelene ved å bruke den.

Bildekomponenten Next.js tilbyr serverer ikke bare bilder i forskjellige størrelser. De støtter også å spesifisere en kvalitet på bildet slik at de kan komprimere det for deg. I mitt tilfelle komprimerte det ikke bildet nok, jeg opplevde bedre resultater ved å komprimere det selv med Photopea.

Flotte bildeverktøy å bruke

Når du jobber med bilder, må du ofte manipulere bilder på bestemte måter. For å gjøre det enklere, foreslår jeg at du sjekker listen over gratis bildeverktøy. Disse verktøyene kan brukes til å endre størrelse og formatere bilder og til å generere bilder og bakgrunner. Den presenterer også nettsteder som tilbyr royaltyfrie bilder.

Tilbake til nettverksforsinkelse

Som jeg lovet i begynnelsen av denne artikkelen, ville vi se på hvordan nettverksforespørsler kan være flaskehalsen når du optimerer bildelastingstider. Se på bildet nedenfor. Den viser nettverkstiming-fanen som er tilgjengelig i Chrome Dev Tools for heltebildet jeg bruker på nettstedet mitt. Vi kan se at det tar like lang tid å få svar fra serveren som det tar å laste ned bildet.


Det tar 32 ms å få svar når jeg besøker min egen nettside

Men Dennis, sier du, bildet ditt er veldig lite, bare 37 kB. 32 ms er ikke veldig lang tid. Ja, det er riktig. Det er ikke noe å bry seg om. Eller det ville i det minste ikke vært det hvis det ikke var fordi jeg hadde lastet inn siden min på nytt flere ganger for å få det skjermbildet.

Ved å laste inn siden på nytt kan serveren bufre bildet og vise det raskt neste gang det blir bedt om det. Når jeg besøker nettstedet mitt under en kaldoppstart på timer har jeg ikke mye trafikk til nettstedet fra Sverige, det kan ta 5, 10 eller kanskje 15 ganger så lang tid å få svar fra serveren. Når det skjer, er nedlastingstiden på 32 ms for bildet ubetydelig sammenlignet med serverens responstid.


Uten en nylig cache av heltebildet tar serverrespons mye mer tid

Konklusjon

Det vi lærte i denne artikkelen var at å legge til et stort bilde på et nettsted faktisk kan forbedre Lighthouse-ytelsestester. Vi lærte hva Largest Contentful Paint (LCP) er og hvordan man kan optimalisere et bilde for å maksimere LCP-poengsummen.

Vi tok også en titt på når du skal bruke SVG-bilder og når du skal bruke WebP-bilder. Jeg ga deg en liste over gratis bildeverktøy som for eksempel kan brukes til å formatere bilder på forskjellige måter, og forklarte viktigheten av å holde bildestørrelsen lav når du bruker bilder på et nettsted.

Til slutt så vi et eksempel på hvordan serverresponstid kan være flaskehalsen for nettbildeytelse når selve bildene har blitt komprimert godt nok til å være svært små.

Dennis Persson

Jeg er en tidligere lærer som skriver artikler om programvareutvikling og alt rundt det. Min ambisjon er å gi mennesker over hele verden gratis utdanning og humoristisk lesing.