Avada muss nicht langsam sein. Speed up your WordPress

Menu:/Avada muss nicht langsam sein. Speed up your WordPress

Avada muss nicht langsam sein. Speed up your WordPress

Nach der Bereitstellung der neuen Website kam erst einmal die große Enttäuschung. Warum zum Teufel habe ich einen Insights Index von 69 und einen GTMetrix von C? Wie kann ich das lösen?
Ich hasse nichts so sehr, wie langsame Webseiten. Wenn sie nicht ZackZack in meinem Browser sind, so lese ich sie erst gar nicht. Es ist ja auch kein Wunder. Mehr Plugins, mehr „Blingbling“ verursachen so etwas. Und „Blingbling“ habe ich mit Avada ja auch gekauft. Aber das muss besser gehen.

Leider habe ich etliche Tutorials im Netz gefunden und keines der Tutorials passte auf meine Website. Und so schreibe ich hier etwas über WordPress und das wohl beliebteste Theme, Avada, und wie ich mit meinen ersten Avada-Gehversuchen von einem Insights Index von wirklich kläglichen Bildschirmfoto 2015-06-04 um 16.22.41

zu einer adäquaten Performance mit so vielen Features, mit diesem ganzen  „Blingbling“ gelangt bin.

Speed messen

Es gibt zwei Dienste, die man primär benutzt, um herauszubekommen, wie sehr man sich mit seinen Plugins daneben benommen hat. Der eine ist GTmetrix, jener einem einen schönen Überblick über das insgesamte Ladeverhalten der Website bietet. Ebenso gibt es eine Bewertung in „Grades“:

Besonders bei der Timeline kann man gut sehen, wo der Schuh drückt und ggf. an den Rädchen schrauben, sofern das möglich ist, oder man auf das Plugin nicht verzichten möchte. Hier wird die Ladezeit der JS und CSS gut sichtbar.
Der andere ist natürlich  PageSpeed Insights von Google. Da Google Google ist und wir ohne Google nicht leben können, und da Google prinzipiell immer Recht hat, kommen wir natürlich nicht umhin. Google macht das aber ganz ordentlich und spricht zumindest die problematischen Dinge an:


Auch hier sehe ich mein Problem, meine Aufgabe, sofern ich sie denn angehen möchte: CSS und JS.  Doch dazu später mehr.

Slider
Das größte Problem der Website sind immer noch die Slider selbst, z.B. auf der Frontpage. Wer Slider benutzt, sollte sich für einen Slider entscheiden, oder gar nur den Fusion Slider der Hersteller verwenden. Revolution Slider empfand ich persönlich als Sicherheitsrisiko und habe es deswegen nicht installiert. Ich bleibe bei Layerslide und lasse diesen aktiv.

Slider bewegen aufgrund Ihres Verhaltens einen Großteil des Insights Index in den Keller. Auch wenn auf dem eigenen iPhone die Website super aussieht, so interessiert das Google nicht. Das Problem ist, dass sie Bilder zwar vorladen, sie zunächst jedoch nicht anzeigen. Weiterhin haben sie riesige JS und CSS Files, die erst einmal heruntergeladen werden müssen. Und da liegt das eigentliche Problem. Man kann sich noch so sehr bemühen, auf einzelne Bestandteile des Sliders zu verzichten, die Codes werden dennoch geladen. In sofern macht es natürlich sinn, manche Slider erst gar nicht zu benutzen. Dennoch, soll es schön aussehen, so müsst Ihr in den sauren Apfel beißen. Chris Lema hat einen unheimlich guten Vergleichsartikel über Slider geschrieben, den Ihr Euch mal ansehen solltet: Link. Fazit: Schmeisst alle Slider raus bis auf einen, den Ihr benutzen wollt. So werdet Ihr das JS und CSS los, was Ihr nicht braucht. Weiterhin werdet Ihr auch um einige Angriffsrisiken ärmer, die Euch die Slider leidergottes auch mitliefern. Es hilft also nichts. Soll es cool ausschauen, so müsst Ihr zumindest bei Insights einige Punkte lassen.

Images
Einer der Punkte für schlechtes Ranking ist nicht die Größe eines Bildes selbst, sondern dessen Kompression. Wir bekommen schlechte Noten für schlechte Kompression. Als ich meine Bilder hochgeladen habe, waren sie riesig. Das selbst (es ist ein JPEG) ist nicht sonderlich schlimm, doch es war aufgrund meiner fotografischen Leidenschaft selbst ein Problem, da ich verlustbehaftete Komprimierung einfach nicht mag. Hier muss ich jedoch umdenken. Mein Lightroom kann mir zwar eine Kompression anbieten, doch es wird sie niemals perfekt treffen können. Auf jedem Webserver, den Ihr anmietet, sind jedoch diverse Tools vorinstalliert, die eine bessere Komrpession der Bilder ermöglichen. Wenn Ihr jetzt schon eine riesige Mediendatenbank von WordPress habt, so wird Euch sicherlich ein kleiner Helfer Spaß machen, der Euch ohne Risiko mal eben die gesamte Mediendatenbank und sogar alle mitgelieferten Bilder Eures Themes komprimiert: Es ist der EWWW Image Optimizer. Zugegeben, es dauert, aber er ist einfach zu konfigurieren und auszuführen. Lasst ihn nur machen und Ihr werdet im Insights Ranking mindestens eine Schulnote besser.

Browser-Caching
Weiterhin ist das Verhalten von Cachedefinitionen auch eine Wissenschaft für sich. Logisch ist: Je weniger der Browser laden muss, weil er es schon hat, desto schneller ist die Ausführung der Website. Es gibt etliche Empfehlungen und Blogeinträge, wie man das Caching jetzt definieren soll, man wird es einfach nicht perfekt von Hand konfigurieren können, es sei denn, man hat wirklich Fachwissen und jede Menge Zeit parat. Auf IIS ist es quasi unmöglich, die Cacheperformance gut in den Griff zu bekommen, auf Apache macht das mit .htaccess schon mehr Sinn. Dennoch, man muss einfach jedes einzelne Verzeichnis manuell definieren und das kostet Zeit und Energie. Nach einiger Zeit habe ich aufgegeben und nach einem Plugin gesucht, was das für mich übernehmen kann, dazu im übernächsten Abschnitt mehr.

Kompression, Minify

Minify, Minifizierung ist ein Tool, welches am besten die Kompression von Daten für Euch übernehmen kann. Minify gibt es auf Eurem Linux Webhost in aller Regel. Das Problem ist die Konfiguration, denn manches lässt sich einfach nicht minifizieren, wie ich hier schon einmal geschrieben hatte. Es knallt, es sieht nicht schön aus, je nach Browsertype kommt da ein unschönes Ergebnis heraus. Wie das einfacher geht, erfahrt Ihr im nächsten Abschnitt.

W3 Total Cache
Bei quasi allen Problemen dockt W3 Total Cache an. Das Ding kümmert sich in Sachen Browser-Caching um jedes einzelne Verzeichnis und definiert die .htaccess so, wie man es im riesigen Konfigurationsmenü vordefiniert hat. Vorweg lässt sich sagen, dass eine Cachelaufzeit (cache with maxage) von 14 Tagen bei Google Insights Punkte bringt, alles kleinere wird bestraft. Das kann ich im Untermenü von „Browser Cache“ definieren.  Auch um minify macht es sich in ebenfalls jedem Verzeichnis Gedanken. Ihr müsst natürlich aufpassen, was und wie Ihr minifiziert, aber das hat Euch Themefusion schon abgenommen. Die Vorkonfiguration hier könnt Ihr bedenkenlos übernehmen. Im übrigen macht die Konfiguration auch für andere Themes Sinn, denn viele nutzen ähnliche Plugins und Snippets von Envato’s Codecanyon, die Konfiguration dürfte also für mehrere Themes passen.

CDN/Cloudflare
Mindestens 10 Punkte, maximal 30 Punkte nach oben gibt es für die Ladezeit der Website persé. Wenn der Hoster nichts kann, so bringt die  beste Optimierung nichts. Klar könnt Ihr zu Hetzner gehen, wenn Ihr das Geld dafür habt, doch für manche ist das zu teuer. Wenn der Hoster bleiben soll, Ihr aber die Ladezeit optimieren wollt, so solltet Ihr Euch um einen

CDN Anbieter kümmern. Es gibt hier z.B. den ziemlich teuren MaxCDN und Cloudflare. Wenn es jetzt dafür Kritik gibt: Ich persönlich nutze Cloudflare, und es hilft wirklich. Mit Verlaub – Es ist eine Website. Die ist öffentlich. Und das soll sie auch bleiben. Was ich öffentlich sage und denke, das soll auch jeder lesen können. Cloudflare hat übrigens noch weitere Vorteile, z.B. reduziert es deutlich die Spam-Kommentare und beugt SQL Injects vor. Es ist kein totaler Schutz vor Angriffen, d.h. Ihr müsst Euer WordPress weiterhin aktualisieren, aber es hilft zumindest schon einmal, den ein- oder anderen Eindringungsversuch abzuwehren.

Auch Cloudflare kann minify, und das m.E. etwas besser, als W3TotalCache. Ihr müsst aber weiterhin die beiden betreffenden Kandidaten aussortieren, die ich bereits oben angemerkt habe.

Avada
Auch in Avada kann man tunen. Man kann nicht benutzte CSS und JS einfach deaktivieren. Es fehlt natürlich etwas an Dokumentation und so wird es schwierig, herauszufinden, was man wirklich deaktivieren sollte, aber es geht. Irgendwann hast Du es geschafft. Hier siehst Du einen Ausschnitt von dem, was ich deaktiviert habe:

Bildschirmfoto 2015-06-04 um 16.15.17

Testen
Zum Schluss müsst Ihr natürlich nach jeder Einstellung immer wieder testen, ob auch wirklich jede Konfiguration Sinn macht und Euch einen Vorteil bringt. Ich habe das hinter mir. Es hat etwas gedauert, aber mehr will ich wirklich nicht und muss ich auch nicht haben. Hilfreich ist dabei der „Developer Modus“ von Cloudflare, indem Ihr das Caching deaktivieren könnt. Ein PurgeCache macht nach jeder Änderung bei W3 TotalCache und bei CloudFlare immer Sinn.

Fazit:
Wenn Ihr dann mit allem fertig seid, so bekommt Ihr doch ein halbwegs akzeptables Ergebnis bei Insights. Es ist nicht super, aber es ist akzeptabel. Jetzt könnt Ihr sagen, dass es nicht an Euch liegt.

Bildschirmfoto 2015-06-04 um 16.24.19
Bildschirmfoto 2015-06-04 um 16.27.42

 

Ist mehr drin? Ja, mein Gott. Es reicht. Mehr Zeit muss ich wirklich nicht investieren.

By | 2016-10-17T15:00:27+00:00 04.06.2015|0 Comments

About the Author:

John Lose

John Lose ist Informationstechnologe und Datenreisender. Manche mögen ihn als „Aluhut-Träger“ bezeichnen, denn er mag nur kleine Rechenzentren, die er selbst kennt. Public Clouds kommen für Ihn höchstens für Webseiten in Frage. John ist Katzenliebhaber, hat aber keine Katze, fährt gerne nach Südfrankreich und hört Tech-House. Mehr über John Lose erfährst Du in seiner Vita.  Wenn Dir dieser Beitrag gefallen hat, so kannst Du auch Danke sagen, wenn Du möchtest:  >> Dankeschön <<.