Wenn Sie das hier lesen, sind Sie wahrscheinlich bereits mit responsiven Bildern vertraut. Dennoch kann es hilfreich sein, ein wenig Hintergrundwissen zu haben. (Dann kommen wir zum WordPress-Teil und wie man sie mit Cloudinary noch besser machen kann.) Fast während der gesamten Existenz des Webs war es so, wenn Sie ein Bild auf einer Webseite einfügen wollten, erstellten Sie Markup, das so aussah:
<img src="/path/to/my/image.jpg" alt="a very nice image">
In diesem Beispiel verweist das <img>-Element auf eine einzelne Bilddatei namens `image.jpg`, die sich auf einem Server unter `/path/to/my` befindet. Dieses Markup ist unkompliziert, da es dem Browser mitteilt, eine bestimmte Bilddatei, auf die über das src-Element verwiesen wird, herunterzuladen und auf der Webseite darzustellen.
Diese Anordnung war in Ordnung bis 2010, als Ethan Marcotte seinen wegweisenden Artikel Responsive Web Design veröffentlichte, der die Technik der Verwendung von Cascading Style Sheet Media Queries zur Modifizierung des Layouts von Webseiten populär machte, um sich an die jeweilige Gerätegröße anzupassen, die ein Nutzer verwendet. Responsive Web Design erhöhte auch das Interesse an der Optimierung der Leistung von Websites basierend auf der Bildschirmgröße. Dieser Fokus machte deutlich, wie groß der Schwachpunkt Bilder für die Leistung darstellt, da sie den Großteil der Byte auf jeder Webseite ausmachen. Mit responsivem Design begannen Entwickler, Bildern, die auf großen Desktop-Displays schön aussehen, an alle Nutzer zu senden, was dazu führte, dass zusätzliche Byte an kleinere mobile Geräte gesendet wurden, wodurch das mobile Surferlebnis langsamer als nötig wurde.

Eine unerschrockene Gruppe von Webentwicklern, bekannt als die Responsive Issues Community Group (RICG), machte sich daran, dieses Problem zu lösen, indem sie neues HTML einführte, damit Entwickler verschiedene Bildquellen für eine Webseite basierend auf kontextbezogenen Informationen wie der Bildschirmgröße identifizieren konnten. Hier ist ein Beispiel für eines der neuen Markup-Muster:
<img src="small.jpg"
srcset="large.jpg 1024w, medium.jpg 640w, small.jpg 320w"
sizes="(min-width: 36em) 33.3vw, 100vw"
alt="A rad wolf">
In diesem Beispiel enthält das <img>-Markup nun zwei neue Attribute: ein srcset, das eine Liste von Bilddateien und ihre entsprechenden Pixelbreiten enthält, und sizes, das dem Browser eine Schätzung der beabsichtigten Layoutgröße des Bildes gibt, abhängig von bestimmten Media-Query-Bedingungen. Das src-Attribut ist als Fallback für ältere Browser enthalten, die die neuen srcset- und sizes-Attribute nicht unterstützen.

Dieses neue Markup ermöglicht es Browsern, das am besten geeignete Bild zu ermitteln und herunterzuladen, wodurch Byte (und Zeit) für die Nutzer eingespart werden. Für einen tieferen Einblick in dieses und andere responsive Bild-Markup-Muster empfehle ich dringend, Jason Grigsbys Serie Responsive Images 101 zu lesen.
Responsive Bilder in WordPress
Ende 2015 brachte WordPress in Zusammenarbeit mit Mitgliedern der RICG die Version 4.4 heraus, die native Unterstützung für responsive Bilder enthielt. WordPress 4.4+ generiert automatisch srcset- und sizes-Attribute für Bilder, die in einen Beitrag oder eine Seite eingefügt werden. Die WordPress-Implementierung nutzt die bereits verfügbare Funktionalität zur Größenänderung von Bildern, um diese Aufgabe zu erfüllen. Vor Version 4.4 erstellte WordPress bereits mehrere kleinere Versionen jedes Bildes, das in Ihre Mediathek hochgeladen wurde. Seit Version 4.4 verwendet WordPress diese zusätzlichen Größen, um srcset-Attribute zu erstellen, damit Besucher Ihrer Website davon profitieren können, indem sie eine Bilddatei herunterladen, die nicht größer ist als das, was sie benötigen.
Diese Implementierung funktioniert "out of the box" gut, hat aber einige Einschränkungen. Zum Beispiel erstellt WordPress Bildgrößenvariationen zum Zeitpunkt des Hochladens des Originals, was bedeutet, dass nur zu diesem Zeitpunkt definierte Bildgrößen in srcset-Attributen verfügbar sind. Darüber hinaus kann die Bildverarbeitung die auf vielen Shared-Hosting-Plänen verfügbaren Ressourcen überlasten, weshalb WordPress sparsam damit umgehen muss, wie viele Variationen jedes Bildes standardmäßig erstellt werden.
Idealerweise könnten Sie dynamisch Bildgrößen erstellen, wenn sie für Ihre Layouts benötigt werden, und die Verarbeitung an einen externen Bilderdienst auslagern. Glücklicherweise gibt es Dienste wie Cloudinary, die genau das tun. Ich war beeindruckt von der Arbeit, die Cloudinary im Bereich des Bildmanagements leistet, und wollte daher sehen, wie ich den Dienst nutzen kann, um die standardmäßige Implementierung responsiver Bilder in WordPress zu erweitern.
Cloudinary zur Erweiterung von WordPress nutzen
Cloudinary bietet Tools zur Durchführung verschiedener Bildtransformationen über einfache Größenänderungen hinaus und hat ein eigenes WordPress-Plugin im WordPress.org-Plugin-Repository veröffentlicht. Das Plugin unterstützt responsive Bilder noch nicht "out of the box", daher wollte ich sehen, ob ich mit seiner Image Upload Application Programming Interface ein schlankeres Plugin erstellen kann. Mein Ziel war es, Bilder aus meiner Mediathek mit Cloudinarys Dienst zu synchronisieren und Cloudinary automatisch die benötigten Bildgrößen erstellen zu lassen, um responsive Bilder von seinem Content Delivery Network (CDN) auszuliefern.
Ich habe ein Demo-Plugin erstellt, das ich auf GitHub veröffentlicht habe, damit Sie es sich ansehen können. In einem Folgeartikel werde ich mehr über die technischen Details und Designentscheidungen des Plugins erklären, aber vorerst beschreibe ich auf hoher Ebene, was das Plugin tut.

Erstens, wenn Sie ein Bild zu Ihrer WordPress-Mediathek hinzufügen, verwendet WordPress Cloudinarys PHP-Integrationsbibliothek, um dieses Bild an Cloudinary hochzuladen und seinen Dienst mit der Erstellung alternativer Bildgrößen zu beauftragen, die im srcset-Attribut verwendet werden sollen. Interessant ist hierbei, dass Cloudinary eine einzigartige Responsive Image Breakpoint-Lösung entwickelt hat, die automatisch die optimalen Bildgrößen berechnet, die auf dem Inhalt Ihres Bildes basieren.

Sobald das Bild an Cloudinary hochgeladen ist, gibt der Dienst Daten zurück, die mit den neu erstellten Bildgrößen verbunden sind, an Ihre WordPress-Website. Durch die Nutzung von WordPress-Filtern können wir diese Daten verwenden, um srcset-Attribute für unsere Bilder zu erstellen, die auf die Dateien vom Cloudinary CDN verweisen und nicht auf lokal gehostete Bilder.
Zusammenfassung
Durch die Kombination der Einfachheit der nativen responsiven Bildfunktionalität von WordPress mit den Bildmanagement-Tools, die Cloudinary bietet, können Sie Ihre Inhalte genau so verwalten, wie Sie es möchten, und gleichzeitig Besuchern Ihrer Website Bilder zur Verfügung stellen, die automatisch für die Fähigkeiten ihres Geräts optimiert sind, ohne sich um jedes einzelne Bild kümmern zu müssen, das zu Ihrer Website hinzugefügt wird. In meinem nächsten Artikel werde ich auf die spezifischen Code-Details eingehen, die ich für mein Plugin entwickelt habe. Vorerst hoffe ich, dass Sie sehen können, wie leistungsfähig die Kombination von WordPress mit Diensten wie Cloudinary sein kann.
Dieser Beitrag (und das Plugin!) wurde von Joe McGill geschrieben.
Artikelserie
- Eine Einführung in Responsive Images und WordPress (Sie sind hier!)
- Ein WordPress-Plugin, das Cloudinary und Responsive Images integriert
Cloudinary kann bei responsiven Bildern im Web eine große Hilfe sein! Sie können nicht nur die verschiedenen Bildgrößen erstellen, die benötigt werden, um die bestmögliche Größe zu liefern, sondern sie können sie im richtigen Format liefern und den Prozess sogar für jede Anwendung vollständig automatisieren.
Wir arbeiten daran, Cloudinary hier auf CSS-Tricks zu integrieren. Ich bin ziemlich begeistert davon, da es eine gute Leistungssteigerung bringen sollte (die wir sorgfältig verfolgen). Um es auf den Punkt zu bringen, so wird es eine Verbesserung gegenüber den responsiven Bildern sein, die WordPress bereits leistet:
sizes-Attribut, das auf diese genaue Website und Situation zugeschnitten ist.Spitzentechnologie. Danke!
Ich bin nur neugierig, ob ich den Kern dessen richtig verstanden habe. Ich bin hauptsächlich ein Anfänger in Bezug auf Bildsteuerung und würde es gerne (korrekt) mit anderen teilen...
Erstens, ich habe verstanden, dass das CDN selbst unsere WP-Websites schneller laden lässt. Mehr noch als die neue WP-Funktionalität, die srcset mit Dateien auf dem WP-Host selbst macht. Zweitens, ich habe verstanden, dass Ihr Plugin-Code darauf abzielt, mehr Möglichkeiten/Entscheidungspunkte/Bilddateien zu erstellen. Diese Daten werden nicht auf dem WP-Server gespeichert, sondern auf einem separaten Bild-Hosting-CDN (oder denke ich an AWS S3?). Ich sehe, dass der Durchbruch passiert, wenn diese Kopplung besser mit den Bedürfnigen des Endgeräts zusammenarbeitet (anstatt dass das Endgerät begrenzte, fest verbaute WP-Srcsets nutzt). Es entlastet auch WordPress enorm, wenn alle Quellen auf dem WP-Server wären (deshalb generiert WP nicht zu viele Möglichkeiten, wie Sie oben sagten).
Habe ich es richtig verstanden? Wenn Sie antworten, danke im Voraus. Ich mache mich jetzt daran, dieses Juwel zum Laufen zu bringen...
Ist Cloudinary mit diesem Plugin besser als Jetpack Photon?
Hallo Rosmen,
Ich habe während der Arbeit daran keine Side-by-Side-Vergleiche durchgeführt. Wenn Sie das ausprobieren und berichten möchten, wäre es interessant.
Es wäre großartig, einen Folgeartikel zu sehen, Chris, über alle Probleme, auf die Sie gestoßen sind. Ich habe angefangen, dasselbe zu tun, fand aber, dass ein Großteil meiner Arbeit auf der Website das Pendeln von und zur Arbeit auf meinem lokalen Computer war.
Alle Tipps... oder Tricks, wenn Sie so wollen... um einen lokalen Satz von Bildern für die lokale Entwicklung und Cloudinary für die Produktion zu behalten, wären sehr willkommen :)
Abgesehen davon fand ich es eine großartige Ergänzung für die Website und die Website-Performance.
Schöne Abdeckung. Also, wird Ihre nächste Episode die Implementierung vollständig behandeln? Danke.
Ich bin überrascht, dass es keine Überlegung gibt, diese Arbeit an den Client (d. h. Browser/JS) auszulagern, um die Bildgrößenänderung durchzuführen und diese dann an Ihren Server weiterzugeben. (d. h. keine Arbeit durch WP oder Ihren eigenen Server erforderlich).
Zweitens verstehe ich, dass ein CDN hauptsächlich nützlich ist, weil ein Besucher Ihrer Website eine Ressource (von Ihrer Website) von einem CDN lädt, die er möglicherweise bereits im Cache hat.
Daher, wenn der Inhalt (d. h. die fraglichen responsiven Bilder) für einen Beitrag/eine Website nicht von einem anderen Ort geladen wird, sehe ich nicht, wie ein CDN die Leistung verbessern würde.
Kann mir jemand den Nutzen eines CDN oder eines Drittanbieters erklären?
Ein großer Vorteil eines CDN ist, dass es lokalisierte Rechenzentren bietet, die näher am Benutzer sind und zu schnelleren Downloads führen.
Wirklich nett. Ich benutze Cloudinary seit vielen Jahren als CDN. Funktioniert das auch mit den bereits hochgeladenen Bildern bei Cloudinary?
btw, habe einen Hack gemacht, indem ich animierte GIFs in Video umgewandelt habe: https://gist.github.com/soderlind/f0e0981a9ece9b41144f8fe22db23a6f