
Die Aufgabe, die uns gestellt wurde: Mehr Speicherplatz auf dem Server schaffen. Ungenutzte Bildformate in WordPress entfernen. Das Portal optimieren.
Die Arbeit am Portal begannen wir nach den Beratungsgesprächen mit der Redaktion von WhiteMad. Das vom Hosting gemeldete Problem mit dem Portal wies auf eine zu große Speichermenge hin, die die Grafikdateien des WordPress-Templates belegten.
Ein zusätzliches Problem war das Template 15zine, da jedes Bild, das in die WordPress-Mediathek hochgeladen wurde, über 20 verschiedene Formate erzeugte, die auf dem Portal nicht verwendet wurden.
Wir begannen damit, die im Template verwendeten Bildgrößen zu überprüfen. Es stellte sich heraus, dass wir über 15 zusätzliche Größen hatten (zusätzlich zu den Standardgrößen von WordPress), darunter einige größere (über 1024px).
Die Bilder in diesen größeren Formaten wogen oft etwa 300-500 kB pro Stück, was bei über 100.000 hochgeladenen Bildern zusätzlich über 50 GB an Dateien ergab.
Die erste Idee war, die ungenutzten Bildgrößen zu deaktivieren, doch nach Durchsicht der Website stellte sich heraus, dass praktisch jede davon an verschiedenen Stellen der Website verwendet wird (hauptsächlich im Artikelraster). Realistisch betrachtet hätten sich vielleicht 3-4 Größen deaktivieren lassen, was keine großen Vorteile gebracht hätte.
Sehen Sie sich unsere Leistung WordPress-Betreuung und Optimierung von WordPress-Websites an.
Wir entschieden uns für einen anderen Ansatz: Mit dem Plugin „Fly Dynamic Image Resizer“ lässt sich die Erzeugung alternativer Bildgrößen durch WordPress beim Hochladen von Bildern in die Mediathek deaktivieren.
Stattdessen werden die Bilder erst dann erzeugt, wenn sie im Frontend benötigt werden. In unserem Fall verringert ein solches Vorgehen die FTP-Speicherbelegung erheblich, da alle in den Artikelrastern verwendeten Bildgrößen nur das Hauptbild des Beitrags betreffen und nicht die Bilder aus dessen Inhalt. Insgesamt werden also nur etwa 10 % aller Bilder generierte alternative Größen besitzen, während die übrigen 90 % nur in einigen wenigen Standardversionen vorkommen werden.
Das bloße Aktivieren des Plugins reicht jedoch nicht aus, da es das Standardverhalten des WordPress-Größengenerators nicht ersetzt. Das Plugin erwartet, dass wir bei der Registrierung von Größen im Template statt des standardmäßigen „add_image_size()“ die Funktion „fly_add_image_size()“ verwenden, und bei der Anzeige von Bildern statt „wp_get_attachment_image()“ und „wp_get_attachment_image_src()“ entsprechend „fly_get_attachment_image()“ und „fly_get_attachment_image_src()“.
Das Webportal, an dem wir arbeiteten, verwendete ein fertiges WordPress-Template 15zine, daher war es nicht möglich, diese Funktionen direkt im Code des Templates auszutauschen. Stattdessen war es nötig, die zuvor registrierten Größen manuell mit „remove_image_size()“ zu entfernen und sich anschließend in den Filter „wp_get_attachment_image“ einzuklinken und die Logik dieser Funktion so anzupassen, dass sie die Bilder automatisch über „fly_get_attachment_image()“ abruft.
Nach dem gesamten Vorgang mussten noch alle zuvor erzeugten Bildgrößen entfernt werden, um Speicherplatz auf dem FTP freizugeben.
Der einzige Nachteil der Verwendung des Plugins „Fly Dynamic Image Resizer“ ist die Tatsache, dass die Ladezeit für die erste Person, die die Seite nach dem Hinzufügen neuer Bilder besucht, etwas länger ausfällt (vor der Anzeige müssen die benötigten Bildgrößen erst generiert werden). Bei der traditionellen Lösung wird dieser Vorgang vom Administrator bereits beim Hochladen neuer Bilder in die Mediathek ausgeführt.
Sehen Sie auch: