Eric Portis slutter sig til mig for at grave ind i en verden af lydhøre billeder.
Vi starter med det grundlæggende. Responsive billeder er specifikt billeder i HTML og findes på grund af et ønske om bedre ydeevne. Billeder er sandsynligvis den største synder i den samlede vægt af websteder. Hvis vi kan undgå at sende for mange pixels over hele netværket, skal vi. Når alt kommer til alt, har en skærm, der kun er 720 pixels bred, ikke brug for et 2000 pixel bredt billede, selvom det er en 2x skærm.
Problemet er, browsere er virkelig aggressive med at downloade aktiver som billeder. Det er godt, da det er grunden til, at internettet (kan være) så hurtigt som det er. Men det betyder også, at vi er nødt til at give en masse information om vores billeder lige i HTML. Kan en browser ikke bare vide, hvor stort et billede er? Sikker på, at det kan, når det har downloadet det. Kan en browser ikke vide, hvor stort et billede skal vises på siden? Sikker på, at det kan, når det er downloadet hele CSS og udført layout. Den responsive billedsyntaks forsøger at komme foran alt dette ved at give disse oplysninger lige i syntaksen. At finde ud af, at syntaksen er vanskelig! Der er srcset, sizesog elementet, og der er et ton at pakke dit sind rundt der.
Det bliver stadig mere kompliceret.
Den syntaks, du har brug for at bygge, er baseret på at have flere kopier af det billede, hvor du kan opbygge syntaksen. Hvordan laver man dem? Hvor mange skal du tjene? Hvilken størrelse skal de have?
Heldigvis er der noget automatiseret værktøj, der dukker op omkring responsive billeder. WordPress var en tidlig spiller. Ud af kassen opretter WordPress flere versioner af de billeder, du uploader, og outputkoder srcsetsyntaks. Men du kan gøre meget bedre. Du kan levere en sizesattribut, der faktisk matcher, hvad dit tema laver, og hvordan det dimensionerer disse billeder.
WordPress bruger heller ikke nogen speciel intelligens til at oprette flere kopier af de billeder, du uploader. Men det kunne det. Et værktøj som den responsive billedbrydpunktsgenerator bruger en vis intelligens til at finde ud af, hvor mange forskellige billeder du kan lave, så du kan finde en balance mellem at have tæt på det perfekte billede til jobbet og ikke behøver at lave hundreder eller tusinder af kopier af det. Dette værktøj har en API!
Det bliver stadig mere kompliceret.
Forskellige browsere understøtter forskellige billedformater. For eksempel WebP. Der er ydeevnebesparelser at få ved at betjene det rigtige billedformat til den rigtige browser. Den responsive billedsyntaks kan hjælpe med det, men det komplicerer syntaksen. Mange billedformater har også en forestilling om kvalitet. Hvilken kvalitet gemmer du disse flere kopier til?
På dette tidspunkt er det et godt tidspunkt at nævne Cloudinary. Jeg har fået det integreret lige nu på CSS-Tricks, og det hjælper med mange af disse ting. Jeg skal nævne, at jeg er en betalende Cloudinary-kunde, og at denne screencast ikke blev sponsoreret, men Cloudinary har sponsoreret CSS-Tricks i form af to meget relaterede sponsorerede indlæg:
- Responsive billeder i WordPress med Cloudinary, del 1
- Responsive billeder i WordPress med Cloudinary, del 2
I en nøddeskal, her er hvordan det hele fungerer på CSS-Tricks nu:
- Jeg uploader billeder, ligesom jeg altid ville gøre med WordPress.
- I stedet for de
srcsetoplysninger, der genereres med WordPress, genereres de af denne smartere API. - Billedet uploades også til Cloudinary.
- Når WordPress filtrerer og outputter HTML til billederne, anvendes alle de gode
srcset(og brugerdefineredesizes) data. URL'en peger på Cloudinary URLs. - Cloudinary URL's gør brug af Cloudinary's evne til automatisk at justere både formatet og kvaliteten automatisk (ved hjælp af deres fancy teknologi) for at sikre, at tingene er de bedste, de kan være for den browser, der anmoder om billedet.
- Gamle billeder, der ikke blev uploadet til Cloudinary, nyder oprindeligt stadig al Cloudinary godhed. De har ikke så smarte af
srcsetdata, men de bruger stadig "hent" URL'er, hvilket betyder, at de kan drage fordel af automatisk formatering og automatisk kvalitet (hvilket alligevel sandsynligvis er en anstændig del af ydeevneforbedringen).
Kort sagt, ikke kun bruger jeg lydhøre billeder her på CSS-Tricks til at hjælpe med ydeevne, Cloudinary-integrationen øger det spil alvorligt.
Jeg er også glad for, at dette ikke er en hård afhængighed. Hvis Cloudinary-pluginet nogensinde er lukket, går alt bare tilbage til normale WordPress-responsive billeder.