NGINX und NGINX Plus liefern responsive Bilder ohne Kopfzerbrechen

NGINX | 29. September 2016

Liam CrillySenior Director, Produktmanagement

Mit dem Image-Filter-Modul und dem srcset-Attribut Bilder dynamisch skalieren

Responsives Webdesign ist zum Standard für moderne Websites und Webanwendungen geworden. Es sorgt auf einer Vielzahl von Geräten für ein einheitliches Nutzungserlebnis und optimiert zugleich die Darstellung für das jeweilige Gerät. Moderne Geräte unterscheiden sich jedoch nicht nur hinsichtlich der Bildschirmgröße, sondern auch der Pixeldichte. Das HTML5-img-Tag bietet eine Reihe von Funktionen, mit denen der Browser die am besten geeignete Ressource auswählen kann, sofern der Server mehrere Varianten bereitstellt. Stellt die Website dasselbe Bild in mehreren Größen bereit, kann der Webbrowser die für seine aktuelle Umgebung am besten geeignete Größe auswählen.

Responsive Bilder ermöglichen es dem Webbrowser somit, eine Darstellung zu erzeugen, die den Vorstellungen des Designers sehr nahekommt. Dies verbessert die Benutzererfahrung, bedeutet aber auch zusätzlichen Aufwand für die Entwicklungs- und Betriebsteams, die nun neben dem Standardbild zahlreiche Varianten der Bilddatei erstellen und bereitstellen müssen.

In diesem Blogbeitrag zeigen wir, wie Sie das Image-Filter-Modul für NGINX und NGINX Plus verwenden, um responsive Bilder bereitzustellen, ohne unzählige Varianten von Bilddateien erstellen und verwalten zu müssen. Stattdessen können Sie eine einzige „Quellversion“ jedes Bildes bereitstellen, deren Größe NGINX oder NGINX Plus dynamisch anpasst. Die Informationen in diesem Beitrag gelten sowohl für NGINX Open Source als auch für NGINX Plus (mit Ausnahme der separaten Anleitung unter Installieren des Image-Filter-Moduls); der Kürze halber verwenden wir im gesamten Beitrag die Bezeichnung NGINX Plus.

Das `srcset`-Attribut

Das wichtigste Werkzeug für die Bereitstellung responsiver Bilder ist das srcset-Attribut des HTML5-img-Tags. Damit können wir mehrere Bildvarianten für unterschiedliche Pixeldichten und Viewport-Größen angeben. Viewport ist ein allgemeiner Begriff für den dem Webbrowser zur Verfügung stehenden Anzeigebereich – unabhängig davon, ob es sich um ein Fenster auf einem Desktop-Computer oder eine Vollbild-App auf einem Mobilgerät handelt.

Im folgenden Beispiel definiert das Attribut „src“ ein Standardbild für Browser, die das Attribut „srcset“ nicht unterstützen, und das Attribut „srcset“ gibt zwei Varianten an – eine für Displays mit Standardpixeldichte (1x) und eine zweite für Displays mit doppelter Pixeldichte, etwa Apple Retina™ Displays und einige 4K-Monitore (2x).

<img src="/images/mylogo-default.png"  srcset="/images/mylogo-density1.png 1x, /images/mylogo-density2.png 2x">

Das folgende, komplexere Beispiel definiert mehrere Varianten eines Bild-Assets, die abhängig von der Breite des Viewports angezeigt werden. Das Attribut „sizes“ gibt an, dass der Browser ein Bild auf der Hälfte des Viewports darstellt, wenn der Viewport breiter als 10em ist, und andernfalls den gesamten Viewport verwendet. Der Browser ermittelt, wie viel Platz für das Bild verfügbar ist, und wählt die Variante des Bild-Assets aus, die am besten in den verfügbaren Platz passt. Dabei wird in der Regel auf die nächsthöhere Breite (Suffix „w“) aufgerundet und die Größe des Bildes intern so angepasst, dass es den Platz exakt ausfüllt.

<img src="/images/racecar-default.jpg"  sizes="(min-width: 10em) 50vw, 100vw"
  srcset="/images/racecar-100px.jpg 100w, /images/racecar-225px.jpg 225w, /images/racecar-450px.jpg 450w, /images/racecar-675px.jpg 675w">

Dieser Ansatz zur Bereitstellung responsiver Bilder, bei dem verschiedene Varianten einer Bilddatei angegeben werden, ist einfach zu programmieren und äußerst effektiv. Allerdings bringt er Herausforderungen bei der Erstellung und Verwaltung der Bildvarianten mit sich. Vor der Veröffentlichung müssen zahlreiche Bilder in ihrer Größe angepasst und wesentlich mehr Dateien auf dem Server bereitgestellt werden. Die optimale Anzahl und Größe der einzelnen Varianten genau abzustimmen, kann zeitaufwendig sein. Dadurch wird es auch schwieriger zu überprüfen, ob jede Variante der Bilddatei zugänglich ist.

Weitere Informationen zum srcset-Attribut und zu anderen Techniken für responsive Bilder finden Sie in diesem hervorragenden Blogbeitrag.

Installieren des Bildfiltermoduls

Das Verfahren zum Beziehen des Image-Filter-Moduls unterscheidet sich bei NGINX Plus und NGINX.

Installieren des Image-Filter-Moduls für NGINX Plus

Das Image‑Filter-Modul steht NGINX Plus-Abonnenten als kostenloses dynamisches Modul zur Verfügung.

Installieren Sie das Modul aus dem NGINX Plus-Repository. Für Ubuntu- und Debian-Systeme:

$ sudo apt-get install nginx-plus-module-image-filter

Für Red Hat-, CentOS- und Oracle Linux-Systeme:

$ sudo yum install nginx-plus-module-image-filter

Aktivieren Sie das Modul, indem Sie eine load_module-Direktive dafür in den übergeordneten („main“-)Kontext der Konfigurationsdatei nginx.conf aufnehmen (also nicht in die Kontexte http oder stream).

load_module modules/ngx_http_image_filter_module.so;

Laden Sie NGINX Plus neu, um das Image‑Filter-Modul in die laufende Instanz zu laden.

$ sudo nginx -s reload>

Installieren des Image-Filter-Moduls für NGINX Open Source

Am einfachsten lässt sich das Image-Filter-Modul aus dem offiziellen NGINX-Repository installieren. Befolgen Sie diese Anleitung, um Ihr System für den Zugriff auf das offizielle NGINX-Repository zu konfigurieren, und installieren Sie das Modul anschließend mit dem Paketmanager Ihres Betriebssystems.

Für Ubuntu- und Debian-Systeme:

$ sudo apt-get install nginx-module-image-filter

Für Red Hat-, CentOS- und Oracle Linux-Systeme:

$ sudo yum install nginx-module-image-filter

Folgen Sie nach der Installation den Schritten 2 und 3 unter „Installieren des Image-Filter-Moduls für NGINX Plus“, um NGINX zu konfigurieren und neu zu laden.

Das Image-Filter-Modul kann auch aus dem Quellcode kompiliert und entweder als statisch kompiliertes oder als dynamisches Modul geladen werden. Weitere Informationen finden Sie im Administratorhandbuch zu NGINX Plus.

Bildgröße an die Pixeldichte anpassen

Mit dem Image-Filter-Modul können wir von jedem Bild eine einzige „Quellversion“ erstellen und bereitstellen. NGINX Plus passt deren Größe dann dynamisch an, um alle vom Browser angeforderten Größenvarianten auszuliefern. Responsive Webseiten und Bilder lassen sich vollständig im HTML-Quelltext optimieren, ohne dass wir Bilder manuell skalieren und auf unserem Webserver bereitstellen müssen.

In dieser HTML-Beispieldatei definieren wir vier Bildvarianten für Geräte mit unterschiedlichen Pixeldichten.

<!DOCTYPE html><html>
<head>
<title>Responsive Logo</title>
</head>
<body>
 
<h2>Logo selection based on pixel density</h2>

<img src="/img400/mylogo.png"
  srcset="/img400/mylogo.png 1x, /img800/mylogo.png 2x, /img1200/mylogo.png 3x, /img1600/mylogo.png 4x">
 
</body>
</html>

Die Verzeichnisse „/img400“, „/img800“, „/img1200“ und „/img1600“ sind nicht tatsächlich vorhanden. Stattdessen gleicht die folgende NGINX Plus-Konfiguration Anfragen nach Ressourcen ab, denen „/img“ vorangestellt ist, und wandelt sie in Anfragen zur Größenänderung des Bildes mit dem ursprünglichen Dateinamen um (zum Beispiel „mylogo.png“ im vorangehenden HTML-Code).

server {    listen 80;
    root /var/www/public_html;
 
    location ~ ^/img([0-9]+)(?:/(.*))?$ {
        alias /var/www/source_images/$2;
        image_filter_buffer 10M;
        image_filter resize $1 -;
    }
}

Der server-Block legt fest, wie NGINX Plus eingehende HTTP-Anfragen verarbeitet. Die listen-Direktive weist NGINX Plus an, Port 80 abzuhören – den Standardport für HTTP-Datenverkehr. Die root-Direktive gibt den Speicherort dieser Website auf dem Datenträger an. In diesem einfachen Beispiel verwenden wir eine von NGINX Plus bereitgestellte statische Website. NGINX Plus wird jedoch häufig auch als Reverseproxy für dynamische Inhalte oder als Anwendungs-Connector wie FastCGI eingesetzt. Bei all diesen Anwendungsfällen kann das Image-Filter-Modul wie hier beschrieben genutzt werden, indem die Quellbilder auf dem NGINX Plus-Server bereitgestellt werden.

Der location-Block verwendet einen regulären Ausdruck, um Anfragen nach Ressourcen abzugleichen, die in einem beliebigen Verzeichnis gespeichert sind, dessen Name mit /img beginnt, gefolgt von einer oder mehreren Ziffern. Die Ziffern werden in der Variablen $1 und der darauf folgende Dateiname in der Variablen $2 erfasst. Anschließend verwenden wir die alias-Direktive, um diese Anfrage aus dem Verzeichnis auf dem Datenträger zu bedienen, das unsere Quellbilder enthält. Beachten Sie, dass sich dieses Verzeichnis nicht unter dem root-Pfad befindet, sodass Clients die Quellbilder nicht direkt anfordern können.

Da unsere Quellbilder wahrscheinlich sehr groß sind und möglicherweise mehrere Tausend Pixel breit sein können, müssen wir sicherstellen, dass das Image-Filter-Modul genügend Arbeitsspeicher zum Laden und Skalieren der Bilder reserviert. In diesem Beispiel verwenden wir die image_filter_buffer-Direktive, um Bilddateien mit einer Größe von bis zu 10 MB zu unterstützen.

Schließlich weist die image_filter-Direktive das Image-Filter-Modul an, die Größe des Quellbilds auf die Breite anzupassen, die aus dem Suffix des Verzeichnisnamens /img erfasst wurde. Der Bindestrich (‑) weist NGINX Plus an, das Seitenverhältnis des Quellbilds beizubehalten.

Überlegungen für den Produktionseinsatz

Die unter „Anpassen der Bildgröße an die Pixeldichte“ beschriebene Konfiguration kann je nach dem Verzeichnisnamen, über den das Bild angefordert wird, jede beliebige Größenvariante eines Bildes bereitstellen. In einer Produktionsumgebung möchten wir jedoch nicht darauf warten, dass der Webserver die Größe der Bilder bei jeder Anfrage anpasst. Dies wirkt sich negativ auf die Gesamtlatenz aus und kann zudem eine erhebliche CPU-Last verursachen.

Die effektivste Lösung besteht darin, die Varianten unserer skalierten Bilder zwischenzuspeichern, sodass nachfolgende Anfragen für die jeweilige Variante aus dem Cache bedient werden, ohne das Image‑Filter-Modul zu durchlaufen. Dies lässt sich mit einer NGINX Plus-Konfiguration erreichen, indem ein separater virtueller Server definiert wird, der die Bildskalierung übernimmt und an den Anfragen nur dann per Proxy weitergeleitet werden, wenn die angeforderte Bildgröße noch nicht im Cache vorhanden ist. Diesen bezeichnen wir als Server für responsive Bilder.

Abbildung 1. Produktionskonfiguration eines Servers für responsive Bilder mit aktiviertem Caching auf dem Frontend-Webserver

Wir müssen auch die Sicherheitsrisiken berücksichtigen, die entstehen, wenn beliebige Anfragen Bildgrößenänderungen ausführen dürfen. Ein konfigurierter Cache hilft nicht, wenn ein Angreifer in schneller Folge eindeutige Varianten von Bildressourcen anfordert, beispielsweise /img1001/mylogo.png, /img1002/mylogo.png, /img1003/mylogo.png und so weiter. Selbst bei einem relativ geringen Anfragevolumen können solche Angriffe aufgrund übermäßiger CPU-Auslastung zu einer Dienstverweigerung (Denial of Service, DoS) führen. Um dies zu verhindern, begrenzen wir die Anfragerate für den Server für responsive Bilder, nicht jedoch für den Frontend-Server, auf dem sich die zwischengespeicherten Varianten befinden. Die folgende Konfiguration erweitert die Konfiguration aus Anpassen der Bildgröße an die Pixeldichte, indem sie Caching und eine Begrenzung der Anfragerate auf das Image-Filter-Modul anwendet.

proxy_cache_path /var/www/imgcache levels=1 keys_zone=resized:1m max_size=256m;
server {
    listen 80;
    root /var/www/public_html;

    location ~ ^/img([0-9]+)(?:/(.*))?$ {
        proxy_pass        http://127.0.0.1:9001;
        proxy_cache       resized;
        proxy_cache_valid 180m;
    }
}

limit_req_zone "1" zone=2persec:32k rate=2r/s;

server {
    listen 9001;
    allow 127.0.0.1;
    deny all;
    limit_req zone=2persec burst=10;

    location ~ ^/img([0-9]+)(?:/(.*))?$ {
        alias /var/www/source_images/$2;
        image_filter_buffer 10M;
        image_filter resize $1 -;
    }
}

Zunächst definieren wir mit der Direktive proxy_cache_path den Speicherort unserer zwischengespeicherten Bilder. Der Parameter keys_zone definiert eine Shared-Memory-Zone für den Cache-Index (mit dem Namen resized) und weist ihr 1 MB zu, was für etwa 8.000 skalierte Bilder ausreicht. Der Parameter max_size legt fest, ab welcher Größe NGINX Plus beginnt, die am längsten nicht mehr angeforderten Bilder aus dem Cache zu entfernen, um Platz für neue Cache-Inhalte zu schaffen.

Die location-Direktive für den Frontend-Webserver (der Port 80 überwacht) verwendet die proxy_pass-Direktive, um Anfragen mit dem Präfix /img an den intern gehosteten Server für responsive Bilder (127.0.0.1:9001) weiterzuleiten. Die proxy_cache-Direktive aktiviert das Caching für diesen Speicherort, indem sie den Namen des Caches (resized) angibt, in dem die Antworten des Servers für responsive Bilder gespeichert werden sollen. Die proxy_cache_valid-Direktive stellt sicher, dass skalierte Bilder mindestens 180 Minuten lang im Cache verbleiben (es sei denn, der Cache hat max_size überschritten und sie gehören zu den am längsten nicht mehr angeforderten Bildern) und dass fehlerhafte Antworten des Servers für responsive Bilder nicht zwischengespeichert werden.

Eine ausführliche Beschreibung des Cachings finden Sie unter „Leitfaden zum Caching mit NGINX und NGINX Plus“.

Bevor wir den Server für responsive Bilder selbst definieren, legen wir mit der limit_req_zone-Direktive eine Ratenbegrenzung fest. Die Direktive setzt selbst keine Ratenbegrenzung durch, sondern definiert eine Begrenzung auf zwei Anfragen pro Sekunde, die anschließend auf den Server für responsive Bilder angewendet wird, indem die limit_req-Direktive in dessen server-Block eingefügt wird (siehe nächster Absatz). Normalerweise wird eine Ratenbegrenzung anhand eines Attributs der Anfrage zugeordnet. In diesem Fall geben wir jedoch den statischen Schlüsselwert "1" an, sodass die Begrenzung für alle Anfragenden gilt. Wir setzen die Größe der Shared-Memory-Zone auf den kleinstmöglichen Wert von 3 KB, da unser Schlüssel eine feste Kardinalität von eins hat.

Der server-Block für den Server für responsive Bilder lauscht auf Port 9001. Mit den Direktiven allow und deny legen wir fest, dass nur localhost (der Frontend-Webserver) eine Verbindung zum Server für responsive Bilder herstellen kann. Anschließend wenden wir die zuvor definierte Ratenbegrenzung an, indem wir die Direktive limit_req einbinden. Der Parameter burst lässt 10 gleichzeitige Anfragen zu, bevor die Ratenbegrenzung durchgesetzt wird. Sobald die Ratenbegrenzung greift, werden darüber hinausgehende Anfragen verzögert, bis sie innerhalb des Limits verarbeitet werden können.

Der location-Block ist identisch mit dem unter Anpassen der Bildgröße an die Pixeldichte beschriebenen Block, wird jetzt jedoch nur ausgeführt, wenn sich das angeforderte Bild nicht im Cache befindet und das Ratenlimit noch nicht überschritten wurde.

In dieser Basiskonfiguration fungiert eine einzelne NGINX Plus-Instanz sowohl als Frontend-Webserver als auch als Server für responsive Bilder. Die Bildverarbeitung kann sehr rechenintensiv sein, was potenziell zu einer extrem hohen Auslastung führt und NGINX Plus anfällig für DoS-Angriffe macht. Um zu verhindern, dass der Frontend-Webserver neue Anfragen nicht sofort annehmen kann, weil alle Worker-Prozesse mit Anfragen zur Größenanpassung von Bildern beschäftigt sind, empfehlen wir, eine separate, ausschließlich für die Bildverarbeitung vorgesehene NGINX Plus-Instanz auszuführen. Dadurch werden die Worker-Prozesse des Frontend-Webservers von den Prozessen für die Bildverarbeitung isoliert. Um eine separate NGINX Plus-Instanz auf demselben Host auszuführen, geben Sie in der Befehlszeile eine andere Konfigurationsdatei an:

$ sudo nginx -c /etc/nginx/resize-server.conf

Responsive Bilder in Aktion

Am besten lässt sich die Funktionsweise responsiver Bilder nachvollziehen, indem man beobachtet, wie ein Browser bei Änderungen der Viewport-Größe entscheidet, welche srcset-Bildvariante verwendet werden soll. Hier ist der HTML-Quellcode einer einfachen Bildergalerie. Beachten Sie, dass sich die Größenvarianten zu Demonstrationszwecken bei jedem Bild geringfügig unterscheiden. Dadurch entstehen viele mögliche „Breakpoints“, an denen der Browser eine andere Variante auswählen kann.

<!DOCTYPE html>
<html>
<head>
<title>Responsive Image Gallery</title>
</head>
<body>
 
<h2>Responsive Image Gallery</h2>

<img src="/img100/1-dominos.jpg" sizes="(min-width: 20em) 40vw, 100vw"
  srcset="/img110/1-dominos.jpg 110w, /img210/1-dominos.jpg 210w, /img310/1-dominos.jpg 310w, /img410/1-dominos.jpg 410w, /img510/1-dominos.jpg 510w, /img610/1-dominos.jpg 610w">

<img src="/img100/2-sign.jpg" sizes="(min-width: 20em) 40vw, 100vw"
  srcset="/img120/2-sign.jpg 120w, /img220/2-sign.jpg 220w, /img330/2-sign.jpg 330w, /img420/2-sign.jpg 420w, /img520/2-sign.jpg 520w, /img620/2-sign.jpg 620w">

<img src="/img100/3-thruppence.jpg" sizes="(min-width: 20em) 40vw, 100vw"
  srcset="/img130/3-thruppence.jpg 130w, /img230/3-thruppence.jpg 230w, /img330/3-thruppence.jpg 330w, /img440/3-thruppence.jpg 440w, /img550/3-thruppence.jpg 550w, /img660/3-thruppence.jpg 660w">

<img src="/img100/4-aces.jpg" sizes="(min-width: 20em) 40vw, 100vw"
  srcset="/img140/4-aces.jpg 140w, /img240/4-aces.jpg 240w, /img340/4-aces.jpg 340w, /img440/4-aces.jpg 440w, /img540/4-aces.jpg 540w, /img640/4-aces.jpg 640w">

</body>
</html>

Die folgenden Screenshots zeigen den Inhalt dieser Webseite in einem Chrome-Browser, wobei die Entwicklertools auf der Registerkarte „Netzwerk“ geöffnet sind. In der Spalte „Name“ wird der Pfad jeder vom Server angeforderten Bildvariante angezeigt. So können wir die ausgewählte Größe erkennen, ohne die Protokolle auf dem Webserver überprüfen zu müssen.

Bei dem schmalen Darstellungsbereich in Abbildung 2 hat der Browser Bilder mit einer Breite zwischen 220 und 310 Pixeln ausgewählt (die numerischen Suffixe der Verzeichnisnamen unter /img in der Spalte Name liegen zwischen diesen Werten).

Abbildung 2. Responsive Bildergalerie bei schmalem Ansichtsbereich

Wenn wir das Browserfenster in Abbildung 3 vergrößern, wählt der Browser Bilder mit einer Breite zwischen 440 und 540 Pixeln aus (die letzten vier aufgeführten Bilder). Für diese Bilder steht in der Spalte „Initiator“ der Wert „Other“.

Abbildung 3. Responsive Bildergalerie bei breiterem Darstellungsbereich

Fazit

Mit NGINX Plus und dem Image-Filter-Modul können wir die optimale Bildgröße für die aktuellen Browserbedingungen bereitstellen. Und das ganz ohne vorherige Größenanpassung der Bilder, Stapelverarbeitung oder die Verwaltung Hunderter Varianten von Bilddateien auf dem Datenträger. Eine weitere Möglichkeit, wie NGINX Plus Sie bei der reibungslosen Bereitstellung von Anwendungen unterstützt.

Testen Sie responsive Bilder mit NGINX Plus selbst – starten Sie noch heute Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen.