Eric Portis blir med meg for å grave inn i en verden av responsive bilder.
Vi begynner med det grunnleggende. Responsive bilder er spesifikt bilder i HTML og eksisterer på grunn av et ønske om bedre ytelse. Bilder er trolig den største synderen i nettsteds samlede vekt. Hvis vi kan unngå å sende for mange piksler over nettverket, burde vi gjøre det. Tross alt trenger en skjerm som bare er 720 piksler bred, ikke et 2000 piksler bredt bilde, selv om det er en 2x skjerm.
Problemet er at nettlesere er veldig aggressive med å laste ned eiendeler som bilder. Det er bra, fordi det er grunnen til at nettet (kan være) så raskt som det er. Men det betyr også at vi trenger å gi en mengde informasjon om bildene våre rett i HTML-en. Kan ikke en nettleser bare vite hvor stort et bilde er? Klart det kan, etter at det har lastet det ned. Kan ikke en nettleser vite hvor stort et bilde skal vises på siden? Klart det kan, etter at det er lastet ned hele CSS og utført layout. Syntaksen for responsive bilder prøver å komme foran alt dette ved å gi den informasjonen rett i syntaksen. Å finne ut at syntaksen er vanskelig! Det er srcset, sizesog elementet, og det er massevis å vikle tankene dine der.
Det blir mer komplisert fremdeles.
Syntaksen du trenger å bygge, er basert på å ha flere kopier av det bildet du skal bygge syntaksen rundt. Hvordan lager du dem? Hvor mange skal du tjene? Hvilken størrelse skal de ha?
Heldigvis er det noen automatiserte verktøy som dukker opp rundt responsive bilder. WordPress var en tidlig spiller. Ut av boksen vil WordPress lage flere versjoner av bildene du laster opp og sende ut srcsetsyntaks. Men du kan gjøre mye bedre. Du kan gi et sizesattributt som faktisk samsvarer med hva temaet ditt gjør, og hvordan det er størrelsen på bildene.
WordPress bruker heller ingen spesiell intelligens for å lage flere kopier av bildene du laster opp. Men det kunne det. Et verktøy som den responsive bildebruddpunktgeneratoren bruker litt intelligens for å finne ut hvor mange forskjellige bilder du kan lage, slik at du kan finne en balanse mellom å ha nær det perfekte bildet for jobben og ikke trenger å lage hundrevis eller tusenvis av eksemplarer av den. Dette verktøyet har en API!
Det blir mer komplisert fremdeles.
Ulike nettlesere støtter forskjellige bildeformater. For eksempel WebP. Det er ytelsesbesparelser å få ved å servere riktig bildeformat til riktig nettleser. Syntaksen for responsive bilder kan hjelpe med det, men det kompliserer syntaksen. Mange bildeformater har også en forestilling om kvalitet. Hvilken kvalitet lagrer du disse flere eksemplarene til?
På dette tidspunktet er det en god tid å nevne Cloudinary. Jeg har integrert den akkurat nå på CSS-Tricks, og det hjelper med mye av dette. Jeg bør nevne at jeg er en betalende Cloudinary-kunde, og denne screencast ble ikke sponset, men Cloudinary har sponset CSS-Tricks i form av to høyt relaterte sponsede innlegg:
- Responsive bilder i WordPress med Cloudinary, del 1
- Responsive bilder i WordPress med Cloudinary, del 2
I et nøtteskall, her er hvordan alt fungerer på CSS-Tricks nå:
- Jeg laster opp bilder akkurat som jeg alltid ville gjort med WordPress.
- I stedet for
srcsetinformasjonen som genereres med WordPress, genereres den av denne smartere API-en. - Bildet lastes også opp til Cloudinary.
- Når WordPress filtrerer og leverer HTML for bildene, brukes alle de gode
srcset(og egendefinertesizes) dataene. URL-en peker på Cloudinary URLer. - Cloudinary URL bruker Cloudinarys evne til automatisk å justere både formatet og kvaliteten automatisk (ved hjelp av deres fancy teknologi) for å sikre at ting er best de kan være for nettleseren som ber om bildet.
- Gamle bilder som ikke ble lastet opp til Cloudinary, nyter opprinnelig fortsatt all Cloudinary-godhet. De har ikke like smarte
srcsetdata, men de bruker fortsatt "hent" URL-er, noe som betyr at de kan dra nytte av automatisk formatering og automatisk kvalitet (som uansett er en anstendig del av ytelsesforbedringen).
Kort sagt, ikke bare bruker jeg responsive bilder her på CSS-Tricks for å hjelpe med ytelse, Cloudinary-integrasjonen øker det spillet seriøst.
Jeg er også glad for at dette ikke er en hard avhengighet. Hvis Cloudinary-pluginet noen gang er slått av, går alt bare tilbake til vanlige WordPress-responsive bilder.