Eric Portis går med mig för att gräva in i responsiva bilder.
Vi börjar med grunderna. Responsiva bilder är specifikt bilder i HTML och finns på grund av en önskan om bättre prestanda. Bilder är förmodligen den största gärningsmannen i webbplatsernas totala vikt. Om vi kan undvika att skicka för många pixlar över nätverket, borde vi göra det. När allt kommer omkring behöver en skärm som bara är 720 pixlar bred inte en bild på 2000 pixlar, även om det är en 2x skärm.
Problemet är att webbläsare är riktigt aggressiva när det gäller att ladda ner tillgångar som bilder. Det är bra, eftersom det är därför nätet (kan vara) så snabbt som det är. Men det betyder också att vi måste tillhandahålla en massa information om våra bilder direkt i HTML-koden. Kan inte en webbläsare bara veta hur stor en bild är? Visst att det kan, efter att det har laddat ner det. Kan inte en webbläsare veta hur stor en bild kommer att visas på sidan? Visst kan det, efter att ha laddat ner all CSS och utförd layout. Syntaxen för responsiva bilder försöker komma framför allt genom att tillhandahålla den informationen direkt i syntaxen. Att räkna ut att syntax är knepigt! Det finns srcset, sizesoch elementet, och det finns massor att sätta ditt sinne runt där.
Det blir fortfarande mer komplicerat.
Syntaxen du behöver bygga baseras på att ha flera kopior av den bilden där du kan bygga syntaxen. Hur gör du dem? Hur många ska du tjäna? Vilken storlek ska de ha?
Lyckligtvis finns det några automatiserade verktyg som dyker upp kring responsiva bilder. WordPress var en tidig spelare. Utanför lådan skapar WordPress flera versioner av bilderna du laddar upp och matar ut srcsetsyntax. Men du kan göra mycket bättre. Du kan tillhandahålla ett sizesattribut som faktiskt matchar vad ditt tema gör och hur det dimensionerar dessa bilder.
WordPress använder inte heller någon speciell intelligens för att skapa flera kopior av bilderna du laddar upp. Men det kunde det. Ett verktyg som den responsiva bildbrytpunktgeneratorn använder viss intelligens för att ta reda på hur många olika bilder du kan göra, så att du kan hitta en balans mellan att ha nära till den perfekta bilden för jobbet och att du inte behöver göra hundratals eller tusentals kopior av den. Det verktyget har ett API!
Det blir fortfarande mer komplicerat.
Olika webbläsare stöder olika bildformat. Till exempel WebP. Det finns prestandabesparingar genom att skicka rätt bildformat till rätt webbläsare. Den responsiva bildsyntaxen kan hjälpa till med det, men det komplicerar syntaxen. Många bildformat har också en uppfattning om kvalitet. Vilken kvalitet sparar du dessa flera kopior på?
Vid denna tidpunkt är det en bra tid att nämna Cloudinary. Jag har integrerat det just nu på CSS-Tricks, och det hjälper till med mycket av det här. Jag bör nämna att jag är en betalande Cloudinary-kund, och denna screencast var inte sponsrad, men Cloudinary har sponsrat CSS-Tricks i form av två mycket relaterade sponsrade inlägg:
- Responsiva bilder i WordPress med Cloudinary, del 1
- Responsiva bilder i WordPress med Cloudinary, del 2
I ett nötskal så här fungerar allt på CSS-Tricks nu:
- Jag laddar upp bilder precis som jag alltid skulle göra med WordPress.
- I stället för
srcsetinformationen som genereras med WordPress genereras den av detta smartare API. - Bilden laddas också upp till Cloudinary.
- När WordPress filtrerar och matar ut HTML för bilderna, tillämpas all den goda
srcset(och anpassadesizes) informationen. URL: en pekar på molnära URL: er. - Cloudinary URL: n använder Cloudinary: s förmåga att automatiskt justera både formatet och kvaliteten automatiskt (med sin snygga teknik) för att se till att saker och ting är det bästa de kan vara för den webbläsare som begär bilden.
- Gamla bilder som inte laddades upp till Cloudinary har ursprungligen fortfarande nytta av all Cloudinary godhet. De har inte lika smarta
srcsetdata, men de använder fortfarande "hämta" URL: er, vilket betyder att de kan dra nytta av automatisk formatering och automatisk kvalitet (vilket antagligen är en anständig del av prestandaförbättringen).
Kort sagt, inte bara använder jag lyhörda bilder här på CSS-Tricks för att hjälpa till med prestanda, Cloudinary-integrationen ökar det spelet allvarligt.
Jag är också glad att detta inte är ett svårt beroende. Om Cloudinary-pluginet någonsin stängs av går allt tillbaka till vanliga WordPress-responsiva bilder.