Hvorfor dine billeder hører hjemme på et CDN (og hvad et billede CDN tilføjer)
Billeder er normalt den tungeste ting, du sender, og den nemmeste store gevinst, du ikke tager. Hvad en CDN løser, og de fire ting et billede CDN gør, at en almindelig ikke gør.
Åbn DevTools på næsten alle sider, sorter netværkspanelet efter størrelse, og se på de ti øverste rækker. På langt de fleste hjemmesider vil de alle være billeder, og den første vil være flere gange større end noget andet.
Det er virkelig gode nyheder, fordi det betyder, at den største løftestang til rådighed for dig også er en af de nemmeste at trække - og i modsætning til JavaScript kan billeder optimeres helt uden at røre din applikationskode.
To forskellige problemer
Billeder er langsomme af to årsager, som ikke har noget at gøre med hinanden, og det er derfor, folk bliver skuffede over halve tiltag.
De er langt væk: Et foto på 400 kB, der serveres fra en oprindelse, tager lige så lang tid at nå Sydney som alle andre 400 kB, hvilket er et stykke tid. Og de er for store: De forkerte dimensioner, det forkerte format, de forkerte kvalitetsindstillinger, som ingen har valgt.
En almindelig CDN løser det første problem fuldstændigt og det andet slet ikke. Det vil levere dit unødvendigt enorme billede meget hurtigt. Det er værd at have - men det er halvdelen af den tilgængelige gevinst, og normalt den mindre halvdel.
De fire ting, som et billede CDN tilføjer
1. Størrelsesændring pr. anmodning
Den største enkeltbesparelse, og den mindst glamourøse. Et billede på 3000 pixels, der vises på et 400 pixel-kort, indeholder ca. 56 gange så mange pixeldata, som der vises. ndring af størrelsen til det, der faktisk vises - omkring to gange CSS-dimensionerne, for høj-DPI-skærme - fjerner rutinemæssigt 70 til 90 procent af bytene, før nogen formatkonvertering overvejes.
2. Formatforhandling
Browsere annoncerer, hvilke billedformater de accepterer på hver anmodning. Et billede CDN læser denne header og tjener AVIF til klienter, der understøtter det, WebP til dem, der ikke gør det, og originalen til noget ældre - beslutter pr. Forespørgsel, uden <picture> element, der skal vedligeholdes, og intet byggetrin, der skal synkroniseres.
3. Transformerer drevet af URL'en
Det er den del, der ændrer måden, du arbejder på. I stedet for at generere varianter på forhånd, anmoder du om den ønskede variant som en del af URL-adressen – en bredde, en beskæring, en kvalitetsindstilling, en formattilsidesættelse. Kanten producerer det på første anmodning og cacher resultatet, så efterfølgende anmodninger om den samme variant er almindelige cache-hits.
Den praktiske effekt er, at dit mediebibliotek indeholder én original i høj kvalitet pr. billede og intet andet. Ingen miniaturegendannelse, ingen genopbygning, når en designer ændrer en kortbredde, og ingen forældreløse afledte filer samles i årevis. En layoutændring bliver til en ændring af et tal i en webadresse.
4. Levering fra nærliggende steder, hvor alt er cachelagret
Det transformerede resultat cachelagres som ethvert andet objekt, så konverteringsomkostningerne betales én gang pr. variant i stedet for pr. anmodning.
Hvorfor dette slår en byggetidspipeline
Generering af billedvarianter på build time virker, og fungerer godt, lige indtil det opfylder et CMS.
Bygge pipelines nedbrydes, fordi indholdet ikke er bygget. Nogen uploader et produktfoto på 4000 pixels via administrationspanelet på en fredag eftermiddag, og der køres ingen byggeprocesser. En designer ændrer et gitter fra tre kolonner til fire, og hver forudgenereret bredde er nu forkert. Der kommer en ny enhedskategori, og der er ingen variant til den. Hver er individuelt håndterbar og samlet grunden til, at de fleste websteders billedoptimering roligt stopper med at arbejde inden for ca. atten måneder efter at være oprettet.
Transformation efter behov har ikke denne fejltilstand, fordi der ikke er noget at holde synkroniseret. Den korrekte variant er, hvad end URL'en beder om.
Dette er normalt den hurtigste tilgængelige rute til en bedre Største Contentful Paint, fordi LCP-elementet på de fleste sider er et stort heltebillede. Optimering af, at et billede ofte flytter en Core Web Vital fra rød til grøn om eftermiddagen - hvilket ikke er noget, du kan sige om mange præstationsændringer.
De tre ting, du skal gøre rigtigt i din HTML
Kanten håndterer bytes; et par markup detaljer afgøre, om browseren gør god brug af dem.
- Brug srcset og størrelser, så en telefon anmoder om et billede i telefonstørrelse i stedet for at downloade skrivebordet og skalere det ned. Uden dette hjælper ændring af størrelsen kun de besøgende, der tilfældigvis er på små skærme.
- IAngiv attributter for bredde og højde på alle billeder. Det koster ingenting og forhindrer det layoutskift, der sker, mens filen stadig ankommer.
- Lad aldrig LCP-billedet være dovent. En let indlæsning under folden er en ægte besparelse; hvis du anvender den på dit heltebillede, forsinkes det nøjagtige element, som Google måler. Tjek, at dit CMS ikke tilføjer noget
loading="lazy"Alting uden forskel.
Ofte stillede spørgsmål
Hvad er et billede CDN?
Et billede CDN er et indhold levering netværk, der også omdanner billeder på anmodning ændre størrelse på dem, konvertere dem til moderne formater som WebP eller AVIF, justere kvalitet og beskæring og cachelagrer resultaterne på kant. Du gemmer en original udgave af høj kvalitet, og hver besøgende modtager en version, der passer til deres browser og det rum, billedet optager.
Skal jeg sætte mine billeder på et CDN?
Ja, for næsten ethvert websted med besøgende uden for din servers umiddelbare region. Billeder tegner sig typisk for det meste af en sides samlede vægt, så betjener dem fra en nærliggende kant producerer den største enkelt forbedring i load tid til rådighed. Tilføjelse på farten resizing og format konvertering forbindelser det, da afstand og filstørrelse er separate problemer og en almindelig CDN kun adresserer den første.
Hvor meget kan billedoptimering reducere sidens vægt?
Ofte med 80 til 90 procent for selve billederne. Et 2,4 MB fotografi, der er ændret til dets viste dimensioner, kan falde til omkring 900 KB, og konvertering til AVIF kan tage det under 200 KB. ndringen af størrelsen udgør normalt mere af besparelserne end formatændringen, da overdimensionerede billeder er ekstremt almindelige.
Er et billede CDN bedre end at generere billeder på byggetidspunktet?
For websteder med indhold, der styres via et CMS, er det generelt ja. Byg rørledninger kræver, at alle nødvendige varianter er kendt og regenereret på forhånd, hvilket bryder, når nogen uploader et overdimensioneret billede uden for en build eller en designer ændrer en layoutbredde. Transformation efter behov har intet at holde synkroniseret – den ønskede variant er uanset, hvad URL-adressen anmoder om, og den genereres én gang og cachelagres derefter.
Skal jeg stadig bruge srcset, hvis jeg bruger et billed-CDN?
Ja, ja. CDN kan producere enhver størrelse, du anmoder om, men kun browseren kender visningen, enhedens pixelforhold og layout. srcset og størrelser er, hvordan browseren fortæller CDN, hvilken størrelse den faktisk har brug for. Uden dem kræver alle enheder det samme billede, uanset skærmstørrelse, og meget af fordelene ved at ændre størrelsen efter behov bliver ubrugt.
Billeder er den tungeste del af de fleste sider og derfor den største tilgængelige gevinst. Et CDN løser afstanden; et billede CDN løser også størrelsen ved at ændre størrelsen og konvertere pr. anmodning og cachelagre resultatet. Upload en original version, anmod om varianter efter URL, brug srcset, så browsere beder om den rigtige, og hold dit heltebillede ude af doven indlæsning.
Se, hvordan NordicCDN gør dette for dit websted:
Mads har arbejdet med IT – mest som vært – siden han var 16. Han tog tidligt ejerskab i en SaaS-virksomhed og var med til at udvide den til Visma, har opbygget og drevet datacenternetværk og fungeret som CTO for et dansk datacenter. Han startede NordicCDN for at gøre hurtig og sikker infrastruktur enkel at bruge.
