Artikelformat

Geschwindigkeit optimieren mit Adaptive Images

9 Kommentare

Schon zwei Monate vergangen seit ich am Blog geschraubt habe. Nachdem ich damals die Plugins Cachify, Crazy Lazy und Autoptimize neu eingesetzt habe, sind alle drei wieder rausgeflogen. Zwischendurch habe ich es wieder einmal mit W3 Total Cache probiert, aber dadurch wurde das Backend sehr zäh und ich hatte teilweise das Gefühl alles stockt. Vor etwa zwei Wochen habe ich von den Google Webmaster Tools öfters Mails bekommen, dass der Blog nicht erreicht werden konnte. Erst vermutete ich einen Fehler beim Server, aber inzwischen glaube ich, dass Cachify Schuld war. Während es für aktuelle Beiträge wunderbar funktionierte, führt es bei manchen älteren zu einem Fehler. Als ich mich selbst durchs Profil klickte wurde mir immer wieder eine leere Seite präsentiert.

Angeregt durch einen Austausch mit Martin Wolf auf Twitter habe ich mich gestern dran gemacht meine WordPress Installation weiter zu optimieren. Nachdem Code und Caching schon bisher gut liefen, blieben vor allem die Bilder, die bei mir bis zu 80% des Datenvolumen des Blogs ausmachten.

Bilddateien in der dem Display entsprechenden Größe: Adaptive Images

Bei responsive Designs frage ich mich immer wieder, wie weit sie neben dem Aussahen auch von der Funktion optimiert sind. Bei dem Theme Kiore Moana, das ich hier nutze werden Vorschaubilder genutzt, die über die gesamte Fenstergröße reichen. Ich lade meist direkt Bilder vom Lumia 1020 hoch, welche meist mehrere Megabyte groß sind. Diese werden dann auch auf mobilen Geräte geladen und per CSS auf vielleicht 10% ihrer Größe reduziert angezeigt. Doof. Lösungsversuche gibt es viele, oft muss man umständlich alle Bilder mehrfach hochladen und umständlich Regeln definieren.

Mit Adaptive Images von Matt Wilcox habe ich eine Lösung gefunden, die mir sinnvoll erscheint und relativ einfach umsetzbar ist. Der Server liefert je nach Endgerät (mobile im browser string) oder Cookie (Displaygröße) runtergerechnete Bilder aus, die für den nächsten Abruf am Server gecacht werden. Eine Anleitung dafür gibt es unter anderem bei elma Studio, an der ich mich neben dem readme orientiert habe.

Internal Server Error 500

adaptive-images.php auf den Server laden, ai-cache Ordner mit passenden Berechtigungen erstellen und JS einbinden war kein Problem. Aber als ich die .htaccess anpasste, gab es immer einen Internal Server Error 500. Da WP Supercache bereits zahlreiche Regeln in die .htaccess geschrieben hat, ging ich davon aus, dass es damit Probleme gibt. Diverse Suchen danach brachten leider kein Ergebnis. Erst als ich begann nach .htaccess Regeln rund um Bilder zu suchen, kam ich zu einer Lösung.

Die Rewrite Rules werden anscheinend so oft durchgegangen bis es kein Match mehr gibt. Das führt recht schnell zu Loops und das führt zu 500er Fehlern. Abhilfe schaffen Flags. [L] bedeutet Last und es wird danach nicht mehr erneut nach einem Match gesucht. [NC] sorgt dafür, dass das Match nicht case sensitiv gehandelt wird.

In meiner .htaccess steht nun folgender Block:
# BEGIN Adaptive Images
<IfModule mod_rewrite.c>
RewriteCond %{REQUEST_URI} !/images/ [NC]
RewriteRule .(png|gif|jpe?g)$ adaptive-images.php [L,NC]
</IfModule>
# END Adaptive Images

Größen der ausgelieferten Bilder

In adaptive-images.php habe ich zwei Zeilen angepasst. Fotos, die ich unbearbeitet vom Handy nehme, haben eine Auflösung von 3072 × 1728. Das ist für meinen Desktop mit 2560×1440 um einiges zu groß. Daher habe ich bei 2560 begonnen und bin dann die häufigsten Auflösungen des letzten halben Jahres in der Statistik durchgegangen. Das Ergebnis ist den vom Skript vorgeschlagenen Werten sehr ähnlich:
$resolutions = array(2560, 1920, 1366, 1024, 768, 480);
Außerdem habe ich die Zeit, die das Bild vom Browser gecacht werden soll von 7 Tagen auf 31 erhöht.
$browser_cache = 60*60*24*31;

Weiteres Aufräumen

Lazy Load habe ich entfernt, um jquery nicht mehr zu benötigen. Mithilfe von BWP Minify lasse ich den Großteil der JavaScripte und CSS gar nicht bis zum Browser durch indem ich ich sie auf ‚forget‘ gesetzt habe. Etwa das CSS vom Jetpack Subscribe Feature. Ich möchte, dass bereits angemeldete Personen weiterhin Beiträge per Mail bekommen, aber ich brauche das CSS nicht auf der Seite, weil ich es nirgends eingebunden habe.

In die .htaccess habe ich dann noch mehr gzip und browser caching gepackt. Hier dürfte sich vieles doppeln, weil die Plugins dies teilweise selbst übernehmen. Kann ich mich irgendwann einmal genauer damit auseinandersetzen. Für den Moment funktioniert es.

Speed nach Auflösung

Bisherige Größe mit Bildern in voller Auflösung: 3,5MB (alter Screenshot von gestern; für die restlichen habe ich den Browsercache abgedreht)
alt

2560px: 2,3MB
2560

1366px: 996KB
Luca Hammer schreibt und analysiert - Mozilla Firefox 2014-06-06 14.00.06

1024px: 927KB
Luca Hammer schreibt und analysiert - Mozilla Firefox 2014-06-06 14.03.11

480px: 306KB (musste etwas tricksen indem ich das Cookie manuell editierte, da ich die Bildschirmauflösung nicht weiter reduzieren konnte)
480


Für mobile Geräte sollter der Blog nun bis zu zehn Mal schneller laden. Aber auch Laptops und Tablets profitieren von den optimierten Bildern. Und ich muss mich in Zukunft nicht mehr darum kümmern, weil das Skript alles automatisch erledigt.

Nachteile

Dadurch dass die Bildgröße über die .htaccess auf einer niedrigen Ebene angepasst wird, haben Personen mit einem kleinem Display gar nicht die Möglichkeit größere Bilder anzufordern. Nicht einmal wenn sie die Bild-URL direkt im Browser aufrufen. Ich weiß auch noch nicht, wie die Google Bildersuche damit umgeht.

Edit: Auf Facebook wurde mir empfohlen als weitere Rewrite Condition den Google Image Bot einfach auszuschließen, damit dieser die Bilder weiterhin in voller Auflösung bekommt:
RewriteCond %{HTTP_USER_AGENT} !Googlebot-Image/1.0 [NC]

Die Bilder müssen für jede Größe angepasst werden, wenn sie nun noch nicht im Cache sind, kann das dazu führen, dass die Anfrage länger dauert, als wenn man die volle Größe geladen hätte. Da der Blog auf einem shared Webspace läuft, kann es auch passiern, dass das Skript in Zeit- oder Speicherbegrenzungen läuft und gar nichts ausgeliefert wird.

Edit: Wenn Bilder Probleme beim skalieren machen, kann man sie im WordPress Backend etwas skalieren, damit die Ausgangsdatei nicht mehr ganz so groß ist. Anschließend sollte das Skript es auch schaffen. Nicht ideal, aber je nach Limitierung des Servers eine Möglichkeit.

Veröffentlicht von

Ich studiere Medienwissenschaften an der Uni Paderborn, arbeite freiberuflich als Social Media Analyst und veröffentliche jährlich einen Blogbeitrag. | | | Newsletter

9 Kommentare An der Unterhaltung teilnehmen

  1. Also wenn du mich fragst, rauft sich dein Webhoster gerade die Haare weil dieses Script die Rechenkapazität des Servers bei jedem Aufruf extra belastet, oder? Und normalerweise sollte WordPress doch bei jedem Upload die Bilder automatisch croppen – warum nimmt nicht dein Theme zB. die so entstandenen 1024px Varianten für Desktopuser und streched das Bild mit CSS bissl größer, wie es ja auch bei Fullsize Bildergalerien üblich ist. Die bisschen reduzierte Qualität sollte kaum wem auffallen

    Antworten

    • Das Skript macht genau das, nur etwas eleganter. Die skalierten Versionen werden wie von WordPress auf dem Server gespeichert und, wenn bereits eine skalierte Größe vorhanden ist, wird diese ausgeliefert. Mehraufwand für den Server ist dann minimal. Der hat bei mir sowieso fast nichts zu tun, weil der Blog über Supercache Preload statisch vorliegt.

      WordPress ist limitiert, weil es nur 3 Größen erstellen kann. Und dies ohne zusätzliche Plugins auch immer nur beim Upload und nicht nachträglich. Zumindest Vorschau und eine Größe (Artikelspaltenbreite) nutze ich im Beitrag. Bleiben theoretisch nur 2 Größen für alle Geräte. Außerdem müsste man sich anschauen wie man die Bilder ersetzt. Das Skript setzt viel tiefer an, kann jederzeit angepasst werden und ist unabhängig von WordPress und seinen Änderungen.

      Gehen würde es aber auch. Weitere Möglichkeiten: http://www.smashingmagazine.com/2012/06/14/responsive-images-with-wordress-featured-images/

      Antworten

      • auf der Suche nach adaptiven Bildlösungen fand ich diesen Beitrag hier von dir:
        Ich zitiere dich:“WordPress ist limitiert, weil es nur 3 Größen erstellen kann. “
        Das ist ein Irrtum. Ein großer sogar.
        mit add_theme_support( ‚post-thumbnails‘ ) kannst du dies in jeder functions.php aktivieren und mit add_image_size kannst du dir zig Bildgrößen beim Upload erstellen lassen wie du sie grad brauchst.
        daher kannst du via WP jede Bildgröße für jede gewünschte Bildschirmgröße erzeugen lassen
        und nutzt du dabei das Plugin Optimus, werden auch diese extra Bildgrößen verlustfrei optimiert.

        jede Erneuerung der Thumbnails macht das vorherige verlustfreie Komprimieren allerdings hinfällig.

        Antworten

        • Danke für den Hinweis. War mir bisher nicht bekannt und bin ich bei meiner Recherche damals nicht drübergestolpert. Würde das auch für bisher hochgeladene Bilder funktionieren oder nur für alle zukünftig hochgeladenen?

          Antworten

  2. Also, ich bin gerade ziemlich froh, dass bei Blogger vieles voreingestellt ist. Auch wenn ich mir große Mühe gegeben habe zu kapieren, was du da geschrieben hast. Ich muss gestehen, dass es für mich Böhmische Dörfer sind und ich kaum etwas kapiert habe. Null Ahnung von nix….. ach herrje….!
    Viele liebe Grüße!!!!

    Antworten

  3. Das Thema Bilder wird in der Tat immer wichtiger – beim Google Speed API spielt die Bildgröße eine enorm wichtige Rolle, weniger die Kompression. Bilder sollten im Browser via img-Tag keinesfalls verkleinert werden, sondern immer exakte 1:1 Größen haben für eine gute Bewertung. Ich bin recht zufrieden mit der Kombination aus custom image sizes (in der Functions.php) und dem EWWW Image Optimizer.

    Antworten

  4. Pingback: Nachlese | Web-Logbuch zum Blogger-Kommentiertag Österreich 2014 | datenschmutz Blog | Ritchie Pettauer | By Ritchie Blogfried Pettauer

  5. Hi,

    ich habe die Anleitung bei elmastudio befolgt, welches du hier auch verlinkt hattest, doch ist der Support dort im Kommentarbereich ja etwas träge.

    Wie dem auch sei… Ich hatte kein Erfolg bei der Installation und bin wirklich etwas ratlos. Vielleicht hast du ja eine Idee was ich noch probieren kann…

    Mein Ergebnis sieht derzeit so aus, dass ich sofort nachdem ich die htacess fertig gemacht habe, alle Bilder im Blog ausgeblendet werden. Es erscheint nur noch der Platzhalter für ein fehlendes Bild.

    Das Problem vermute ich darin, dass meine htaccess nicht direkt im wordpress-verzeichnis liegt wo auch die adaptive-images.php und der ai-cache liegt, sondern die Datei liegt eine eben höher im Serververzeichnis.
    Aus Sicherheitsgründen habe ich diese Technik genutzt, damit mögliche Angreifer nicht sofort das Installationsverzeichnis von WordPress finden können. Eine Funktion die WordPress so von Hause aus ja ermöglicht und z.B. auch Reibungslos mit der Permalink-Struktur arbeitet.

    Zum verdeutlichen ein Beispiel (ich hoffe beim Absenden wird die Gliederung nicht zerschossen)

    root verzeichnis
    #wp_blog
    -wp-includes
    -wp-content
    -wp-admin
    -….
    #index.php
    #.htaccess

    Hast du vielleicht einen Tipp parat wo ich noch nachsehen könnte? Ggf. gerne auch per Mail.

    Antworten

  6. Hallo Luca,

    klasse Tutorial, sehr verständlich. Vielen Dank! Ich habe noch einige Fragen:

    1. Hast du innerhalb der htaccess den Adaptive Images Block in die WordPress-Anweisungen integriert oder davor/dahinter platziert? Macht das einen Unterschied? Ich frage, weil du die Bedingung in deinem Snippet noch einmal gesondert aufführst, obwohl sie schon für WordPress angefragt wird.

    2. In meinem Blog werden die Bilder standardmäßig im Ordner /wp-content/uploads/ abgespeichert. Bedeutet das, dass ich die Zeile

    RewriteCond %{REQUEST_URI} !/images/ [NC]

    in

    RewriteCond %{REQUEST_URI} !/uploads/ [NC]

    ändern muss?

    3. Wie kann ich testen, ob die Bilder tatsächlich von Adaptive Images verkleinert werden, die Funktion also aktiv ist?

    Viele Grüße
    Nick

    Antworten

Schreibe eine Antwort

Pflichtfelder sind mit * markiert.