Eric Portis voegt zich bij me om in de wereld van responsieve beelden te graven.
We beginnen bij de basis. Responsieve afbeeldingen zijn specifiek afbeeldingen in HTML en bestaan uit een verlangen naar betere prestaties. Afbeeldingen zijn waarschijnlijk de grootste boosdoener in het totale gewicht van websites. Als we kunnen voorkomen dat te veel pixels over het netwerk worden verzonden, zouden we dat moeten doen. Een scherm dat slechts 720 pixels breed is, heeft immers geen 2000 pixel breed beeld nodig, ook al is het een 2x scherm.
Het probleem is dat browsers erg agressief zijn in het downloaden van items zoals afbeeldingen. Dat is goed, want daarom (kan) het web zo snel (kan) zijn als het is. Maar het betekent ook dat we een heleboel informatie over onze afbeeldingen rechtstreeks in de HTML moeten verstrekken. Kan een browser niet gewoon weten hoe groot een afbeelding is? Natuurlijk kan het, nadat het het heeft gedownload. Kan een browser niet weten hoe groot een afbeelding op de pagina wordt weergegeven? Zeker, nadat het alle CSS en uitgevoerde lay-out heeft gedownload. De syntaxis van responsieve afbeeldingen probeert dat allemaal voor te zijn door die informatie rechtstreeks in de syntaxis te verstrekken. Het uitzoeken van die syntaxis is lastig! Er is srcset, sizesen het element, en er is een ton om je geest daar omheen te wikkelen.
Het wordt nog ingewikkelder.
De syntaxis die u moet bouwen, is gebaseerd op het hebben van meerdere kopieën van die afbeelding waarin u de syntaxis kunt bouwen. Hoe maak je ze? Hoeveel moet je maken? Hoe groot moeten ze zijn?
Gelukkig duiken er enkele geautomatiseerde tools op rond responsieve afbeeldingen. WordPress was een vroege speler. WordPress maakt standaard meerdere versies van de afbeeldingen die u uploadt en voert srcsetsyntaxis. Maar je kunt veel beter doen. U kunt een sizeskenmerk opgeven dat overeenkomt met wat uw thema doet en hoe het die afbeeldingen schaalt.
WordPress gebruikt ook geen speciale intelligentie voor het maken van meerdere kopieën van de afbeeldingen die u uploadt. Maar het zou kunnen. Een tool als de responsive image breakpoint generator gebruikt enige intelligentie om uit te zoeken hoeveel verschillende afbeeldingen je kunt maken, zodat je een balans kunt vinden tussen het hebben van bijna de perfecte afbeelding voor de klus en het niet nodig hebben van honderden of duizenden kopieën van het. Die tool heeft een API!
Het wordt nog ingewikkelder.
Verschillende browsers ondersteunen verschillende afbeeldingsindelingen. Bijvoorbeeld WebP. Er zijn prestatiebesparingen te behalen door het juiste afbeeldingsformaat aan de juiste browser te leveren. De responsieve syntaxis van afbeeldingen kan daarbij helpen, maar het compliceert de syntaxis. Veel afbeeldingsformaten hebben ook een notie van kwaliteit. Met welke kwaliteit bewaart u deze meerdere exemplaren?
Op dit punt is het een goed moment om Cloudinary te noemen. Ik heb het nu geïntegreerd in CSS-Tricks, en het helpt bij veel van dit soort dingen. Ik moet vermelden dat ik een betalende Cloudinary-klant ben en dat deze screencast niet werd gesponsord, maar Cloudinary heeft CSS-Tricks gesponsord in de vorm van twee zeer gerelateerde gesponsorde berichten:
- Responsieve afbeeldingen in WordPress met Cloudinary, deel 1
- Responsieve afbeeldingen in WordPress met Cloudinary, deel 2
In een notendop, hier is hoe het nu allemaal werkt op CSS-Tricks:
- Ik upload afbeeldingen zoals ik altijd zou doen met WordPress.
- In plaats van dat de
srcsetinformatie wordt gegenereerd met WordPress, wordt deze gegenereerd door deze slimmere API. - De afbeelding wordt ook geüpload naar Cloudinary.
- Wanneer WordPress de HTML voor de afbeeldingen filtert en uitvoert, worden al die goede
srcset(en aangepastesizes) gegevens toegepast. De URL's verwijzen naar Cloudinary-URL's. - De Cloudinary-URL's maken gebruik van de mogelijkheid van Cloudinary om automatisch zowel het formaat als de kwaliteit automatisch aan te passen (met behulp van hun fraaie technologie) om ervoor te zorgen dat de dingen zo goed mogelijk zijn voor de specifieke browser die de afbeelding aanvraagt.
- Oude afbeeldingen die oorspronkelijk niet naar Cloudinary waren geüpload, profiteren nog steeds van al het goede van Cloudinary. Ze hebben niet zo'n slimme
srcsetgegevens, maar ze gebruiken nog steeds 'fetch'-URL's, wat betekent dat ze kunnen profiteren van automatische opmaak en automatische kwaliteit (wat in ieder geval waarschijnlijk een behoorlijk deel van de prestatieverbetering is).
Kortom, ik gebruik niet alleen responsieve afbeeldingen hier op CSS-Tricks om te helpen met de prestaties, de Cloudinary-integratie verhoogt dat spel serieus.
Ik ben ook blij dat dit geen harde afhankelijkheid is. Als de Cloudinary-plug-in ooit wordt uitgeschakeld, gaat alles gewoon terug naar normale WordPress-responsieve afbeeldingen.