|
Und das in 3 einfachen Schritten (Für Wordpress ab Version 3.3). Was mir dabei wichtig ist: In der Kürze liegt die Würze. Neben zahlreichen Gründen aus SEO Sicht und Benutzer Zufriedenheit, gefällt es mir persönlich auch ganz gut, wenn die Site schnell ausgeliefert wird. Vor der Optimierung kann man z.B. mit den Pingdom-Tools messen, wie lange die Auslieferung dauert. Geht natürlich auch mit yslow google pagespeed und anderen Tools, aber pingdom speichert die Ergebnisse in einer Historie. So lässt sich später auch prüfen, ob die Ladezeit vielleicht vom Hoster, Server oder tageszeitabhängig beeinflusst wird.
Schritt 1: Auf unnötige Plugins verzichten Welche dabei unnötig sind, lässt sich einfach mit dem Plugin P3 (Plugin Performance Profiler) feststellen. Nach der Plugin Installation lässt sich über Tools / Werkzeuge ein Ladeprofil erstellen, welches die Ladezeit der auf dem Server ausgeführten php Skripte erfasst. Meiner Meinung nach sind alle Plugins unnötig, die einen schlechten Einfluss auf die Ladezeit haben. Es gibt nicht viele Zusatzfunktionen, die dem Besucher auf einer "langsamen" Website wieder ein Lächeln entlocken. Also: Alle Plugins die nicht zur Kernfunktionalität gehören und langsam sind zumindest zum Test deaktivieren, gegen schnellere mit gleicher Funktion austauschen, oder darauf verzichten. Schritt 2: Die Auslieferung von CSS und Javascript Dateien optimieren Das lässt sich sehr einfach mit dem Plugin Better WordPress Minify realisieren. Nach der Installation lässt sich unter Settings / Einstellungen - BWP Minify festlegen, wie CSS und Javascript Dateien zu behandeln sind. Schritt 3: Worpress um Cache Funktionalitäten "erweitern" Und dazu lässt sich z.B. einfacherweise das Plugin WP Super Cache verwenden. Nach der Installation lässt sich unter Settings/ Einstellungen - WP Super Cache festlegen, wie die Seiten zu cachen sind. Die Cache Funktionalität ist übrigens schon in Wordpress enthalten (ohne Persistenz, für die sorgt z.B. das Plugin) und ist hier beschrieben Class Reference/WP Object Cache. (define('WP_CACHE', true) in der wp-config.php einzutragen ist seit Version 2.6 unnötig, da diese Konfiguration nicht mehr zieht)
Noch nicht genug? Dann gibt es noch weitere Möglichkeiten
Schritt 4: Ein schnelles Template verwenden Nicht jedes Template ist leichtgewichtig und nicht jedes gut designed. Es lohnt sich auf jeden Fall ein paar Templates zu probieren und sich die Ladezeiten anzusehen.
Schritt 5: Bilder später laden Mit dem Plugin jQuery Image Lazy Load WP kann man erreichen, daß Bilder erst geladen werden, wenn sie im Viewport sichtbar sind, sprich, wenn der Besucher in der Seite soweit runter scrollt, daß das Bild angezeigt wird. Bringt aber nur was, wenn die Seite überhaupt Content in geeigneter Form darstellt. Schritt 6: Bilder optimieren
Mach ich größtenteils "manuell" mit der Hilfe von googles Pagespeed. Nach Analyse der Seite (z.B. über das Firefox Plugin) werden unter dem Punkt "Bilder optimieren" alle Bilder auf Einsparungspotential geprüft und gleich eine verbesserte Version des Bildes zum Download angeboten, welches sich prima zum Austausch des Originals eignet. Schritt 7: Die Datenbank sauber halten Das hat mir noch nichts gebracht, da meine Wordpress Instanzen zum einen nicht so viele Posts und Pages enthalten und sie auch noch recht neu sind. Es ist aber erstaunlich wie viele Revisions zusammen kommen, die man nicht benötigt und die gelöscht werden können. Dazu kann man sich des Plugins Delete-Revision bedienen, welches auf Knopfdruck unnötigen Ballast entfernt. Sinnvoll bei großen Sites oder langsamen mysql Installationen.
Schritt 8: Fehlerhafte Links suchen
Meine Meinung: Eine 404 Meldung ist die langsamste Form der Site Auslieferung: Der Besucher bekommt niemals zu Gesicht, was er sehen wollte. Mit dem Plugin Broken Link Checker kann man sich mühelos auf die Suche nach fehlerhaften Verweisen machen.
Schritt 9: Die weiteren Tipps aus z.B. google Pagespeed umsetzen Jetzt wird es nicht nur interessant sondern auch schwieriger. Nicht alle Potentiale lassen sich so ohne Weiteres ausschöpfen und die Umsetzung dauert zumindest länger oder ist z.T. garnicht möglich. Der Form halber gehe ich trotzdem kurz darauf ein.
- serverseitige Komprimierung aktivieren
- sorgt dafür, das Dateien komprimiert an den Client gesendet werden
- lässt sich bei shared Hosting Angeboten selten selbst am Server konfigurieren
- die Einstellungsmöglichkeiten in der .htaccess Datei werden je nach Server-Konfiguration und aktivierten Modulen ignoriert
- die Komprimierung per php Funktion ist serverlastig oder nicht möglich (und auch nicht zu empfehlen)
- nicht alle mobile devices unterstützen Komprimierung
- Bilder in CSS Sprites kombinieren
- dabei werden Bilder in einer Datei ausgeliefert und über CSS nur noch auf Teile der großen Datei zugegriffen, das vermindert die Anzahl Serverzugriffe
- viel Spaß beim Erstellen der Datei und dem Zugriff auf die Einzelelemente ; (nimm doch einen Generator http://de.spritegen.website-performance.org/)
- das Sprite muss manuell in das Theme / Template eingebaut werden
- Javascript später parsen (weiter unten im HTML referenzieren / einfügen)
- zuerst werden die sichtbaren Teile ( HTML / CSS / Bilder usw.) geladen und zur Anzeige gebracht, die javascript Dateien, die zuweilen auch sehr groß sein können (z.B. jquery), werden später geladen und Behindern so den Aufbau der Seite nicht
- nicht jedes Template unterstützt das, es kommt zu Fehlern in der Ausgabe (aufklappbare Menüs, dynamische Elemente)
- nicht jedes Plugin unterstützt das
- z.T. müssen das Template oder verwendete Plugins manuell editiert werden
- ein CDN verwenden
- Dateien der Präsenz werden auf "Contentproxys" weltweit verteilt und dort optimiert zu Verfügung erstellt
- he, dann verlier ich ja die volle Kontrolle ;)
- ist mir zu aufwendig
- siehe Update - Ausnahme jquery
- Browser caching aktivieren
- wird am Server konfiguriert und sorgt dafür, daß Dateien im Browser Cache bleiben
- muss in der Datei .htaccess oder Apache Konfiguration aktiviert werden
- steht bei den meisten Shared Hosting Angeboten nicht zu Verfügung
10. Plugin Lade-Reihenfolge verändern
Hierzu kann man sich eines Plugins bedienen, z.B. dem Plugin Organizer. Durch Änderung der Ladereihenfolge habe ich es geschafft, daß die dynamischen Twitter und Facebook Button nicht immer das Laden der Seite blockieren. Warum ist mir noch nicht ganz klar, zumindest stehen deren Javascript Elemente dadurch jetzt noch weiter am Ende der Seite. Mit Hilfe des Plugins lässt sich festlegen, auf welchen Seiten welches Plugin geladen wird. Das macht z.B. dann Sinn, wenn die Gallerie oder das Kontaktformular umfangreich Javascript und CSS lädt, deren Anzeige aber auf wenige Seiten beschränkt ist. Das dürfte mit den Javascript und CSS Optimierungen und dem Caching kollidieren, da ja dann unterschiedliche Dateien ausgeliefert werden. Getestet habe ich das noch nicht, da mir die Änderung der Ladereihenfolge den gewünschten Effekt gebracht hat.
Ich mach jetzt mal nen Punkt, die Möglichkeiten unter Punkt 9 habe ich getestet aber verworfen und komme mit den ersten 7 Tipps auf unter 3 Sekunden, das muss genügen. Fehlerhafte Links sind ein no go und somit ist Punkt 8 ein Muss, auch wenn man auf den korrekt verlinkten Seiten keinen Effekt spürt. UPDATE: Ein Dorn im Auge sind mir große Frameworks wie jquery. Da frage ich mich ständig, ob mein Shared Hosting Angebot für die Auslieferung optimal konfiguriert ist. Mit folgendem exemplarischen "Ersatz" lässt sich jquery auch direkt vom google Server laden: <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js"></script>
Dazu muss (meist im Template) die Quelle zu jquery getauscht werden. Im Template Code sollte man dazu "lokale Aufrufe" wie diesen hier "<script type=”text/javascript” src=”js/jquery-1.3.2.js”></script>" gegen den oben aufgeführten tauschen. Dabei kann man auch eine andere Version angeben. Außerdem ist es möglich, per AJAX und google Load jquery zu laden .... aber das sei hie nur als ergänzende Bemerkung aufgeführt, je mehr man sich von externen APIs abhängig macht, um so mehr Zeit verwendet man darauf, deren Einsatz, Funktion und Verfügbarkeit zu "überwachen". Das Einbinden von jquery von einem anderen Server wäre dann der erste Schritt ein "CDN - Content Delivery Network" zu nutzen. In Zusammenhang mit "Schritt 4 schnelles Template" möchte ich noch ergänzen, daß es Templates gibt (wie z.B. suffusion) die per Konfiguration den Einsatz der minified Version von jquery erlauben (wobei suffusion cool, aber selbst nicht so schnell ist). Dumm, wenn dann ein Plugin die große Version des Frameworks mitbringt und verwendet, also immer wachsam sein ;)
|
