von der Schnecke zum Sprinter, ein Performance Fallbeispiel

Performance verbessern ein Fallbeispiel Hajosiewer.de läuft seit gut vier Jahren mit WordPress. Damals 2008 stand ein Redesign und ein Relaunch an, den ich machen durfte.

Dieser Tage wurde ich kontaktet, weil ein Plugin WP Postratings einfach nicht funktionierte und die örtliche Werbeagentur feststellte, dass sie dies nicht lösen können. Was war passiert… .

WP hausinterne Hooks unbrauchbar machen und die Folgen

In vier Jahren ändert sich manches an einer Website. Features kamen auch bei Hajosiewer dazu. Die Anzahl der JavaScripts stieg ins unermessliche, unterschiedliche Libraries waren auch vorhanden und irgendwann vertrugen die sich nicht mehr.

2008 war es noch sehr wichtig, dass die linke Navigation auch für den IE 6 funktioniert. Daher wurde dies hochkomplex aufgebaut und tat lange Jahre ihren guten Dienst. Irgendwann entschied man sich, es wäre doch einfacher, wenn neue Seiten automatisch in der Navigation auftauchten und es wurde eine .js Lösung gefunden.

Damit diese aber funktinierte wurden die WP Hooks wp_head und wp_footer unbrauchbar gemacht. JSScripte “hart” im html Header verlinkt – das kostete Performance und dies nicht zu knapp ;)

Außerdem wurden Plugins, die genau diese Hooks brauchen damit unbrauchbar und daher funktioniete WP Postrating nicht.

1.Schritt => Lösung des Plugin Problems

1.

Die linke Navigation wird mit WP hauseigenen Mittel nun geliefert – sie ist ein benutzerdefiniertes Menü.

Seiten können derzeit nicht automatisch hinzugefügt werden, doch das Menü zu befüllen ist in WordPress sehr, sehr einfach und geht rasch.

Weggefallen sind nun etliche JavaScripts und vorallem konnte ich die Hooks wp_head und wp_footer wieder aktivieren.

mit 70 von 100 begann die Arbeit

Erster Erfolg
Nun funktionierte WP Postratings einwandfrei. Aber die Website war immer noch langsam.


ausmisten und Performance steigern konnte beginnen

Vorneweg: Der Browser bekommt die Anweisung eine Seite zu öffnen. Nun guggt er was ihm da geliefert wird ;)

Hat man einen Mischmisch zwischen CSS und ScriptDateien, zeigt der Browser die Seite erst an, wenn er alle Scripte abgearbeitet hat => dies macht eine Seite langsam einfach.

Daher ist es sinnvoll, zuerst alle CSS Dateien in den HTML Header anzugeben und wenn geht alle Scripte in den HTML Footer, dazwischen liegt ja immer das HTML an sich und das braucht ja auch Zeit.

1.
Das verwendete Lighbox Plugin brauchte mehrere JavaScripte im Header, es wurde ausgetauscht gegen ein modernes,leichtes Lightbox Plugin => ich entschied mich schlussendlich für Shutter Reloaded, weil es wenig Scripte braucht, weil es einfach nutzbar ist und weil ich damit auch sehr gute Erfahrung bei einem responsiv Design machen konnte. Und wer weiß, ob Hajosiewer.de nicht mal auch responsiv wird ;)

2.
Das Plugin “send to a friend” wurde ersatzlos gestrichen, weil es sowieso kaum genutzt wurde. => wieder fielen etliche JS Scripte weg.

3.
Die Buchungsseite bietet einen Kalender, dessen Datapicker.js wird jetzt per conditional comments nur mehr auf genau dieser Unterseite ausgeliefert. Keine andere Seite oder Artikel braucht diese Scripte, also wozu sitewide liefern. Und außerdem verlink ich diese Scripte im html Footer und nicht mehr im html Header.

4.
Die CSS Dateien diverser Plugins wurden soweit leicht möglich in die style.css vom Theme gepackt und somit wurden acht http Header Aufrufe eingespart.

5.
Via functions.php schicke ich zwar alle Scripte in den html Footer, aber das Newsletterplugin nutzt diesen Hook nicht und daher holt es jQuery immer noch in den HTML Header => doch alle anderen Scripte halten sich an diese Anweisungen und wandern wie durch Zauberhand in den HTML Footer.

6.

Das Plugin Cachify installiert und es macht die Seite einfach schneller – mehr gibt es da nicht zu sagen ;)

es freut einfach …

Diesen Artikel zu tippen brauchte mehr Zeit für mich als die Arbeiten an der Seite ;) einfach, weil ich WordPress gut kenne und daher weiß was es braucht, damit es verdammt schnell sein kann.

In diesem großen Screenshot von pagespeed.de zeige ich mal das Ergebnis von 95/100 und auch wenn sicher noch einiges drin wäre an Performanche => ich freu mich über diesen raschen Erfolg.


die Analyse vom Tool Pagespeed.de nach Ende meiner Arbeiten
Analyse der Performance am Ende meiner Arbeiten.
Der große Screenshot öffnet sich in einer Lightbox => einfach anklicken.

Die Links aus dem Artikel

Shutter Reloaded, Cachify , das Tool Pagespeed.de und natürlich www. Hajosiewer.de .

Ich bedanke mich für das Vertrauen, das mir von Hajosiewer entgegengebracht wurde und es ist immer wieder eine Freud, wenn Erfolg sich einstellt. mts

12 Kommentare zu “von der Schnecke zum Sprinter, ein Performance Fallbeispiel

  1. Andreas

    ..und schon macht mein Pagespeed-Experiment Spass. Toller Artikel und DEIN Erfolg gibt meinem Tool recht, Danke :-)
    Darf ich diesen Artikel verlinken unter z.B. “Erfolgsstories”?

  2. hansen

    “…und auch wenn sicher noch einiges drin wäre an Performance”
    Im CSS-Bereich wäre noch einiges Potential, nur ist da der Aufwand größer, als der Nutzen.
    “=> ich freu mich über diesen raschen Erfolg”
    Das kannst Du auch, die Steigerung der Performance ist schon sehr beachtlich.

    Gruß
    hansen

  3. mts

    ja hansen,
    meist ist bei einer CSS Optimierung der Lust am Optimieren höher als der Gewinn an Schnelligkeit

    lg

  4. Klaus

    Jetzt würde mich natürlich ernsthaft interessieren wie lange das Ganze gedauert hat – wenn der Artikel länger gebraucht hat ?!

    Gruss Klaus

  5. mts

    Klaus deck mich doch nicht soo auf ;)

    ich brauchte genau 3.5 Stunden inclusive aller Tests => davon 30Min bis ich den Fehler hatte
    und mir sicher war, dass es dieser Fehler ist

    und daher braucht ich für diesen Artikel länger ;) ,

    weil was ich dann zu tun hatte war mir schlagartig klar

  6. Ole

    Was soll ich sagen…mal wieder eine großartige Arbeit Monika! Vielen Dank!! :-)

    Ich bin gespannt, ob google was merkt (in den GWTs) oder unsere Besucher es vllt mit mehr PIs würdigen.

    Ich halte dich auf dem Laufenden!

  7. mts

    Grüß Dich Ole
    danke für dein nun auch öffentl. Lob ;)

    ich habe da eine Idee für noch mehr PIs,die mag ich aber hier nicht schreiben ;)

    lg

  8. Dieter

    Du hast meinen großen Respekt für diese Geschwindigkeitsoptimierung, Deine Geschwindigkeit bei der Optimierung und diesen sehr lesenswerten Artikel dazu.

    Ich komme bei meinen WordPress-Webseiten nur auf Performancewerte von 85 bis 93/100 bei Pagespeed.de. Bei meinen Seiten ist der wesentliche Schwachpunkt wohl shared Hosting, aber bei kleinen privaten Websites scheue ich die Investition in schnelleres, aber auch teueres Hosting. Ich habe übrigens noch meine erste PHP-Website ohne WordPress getestet, die eine ganz schlechte Performance von 55/100 hat. Man(n) (Frau auch ;-) ) kann also aus WordPress einiges an Performance herausholen und auch ohne WordPress einiges in Sachen Performance falsch machen. :-(

    Bin übrigens darüber auf diesen Artikel gekommen.

    LG Dieter
    PS: Die Auswahlentscheidung bei WordPress-Plugins sollte – wie Du auch schon demonstriert hast – insbesondere unter Performance-Gesichtspunkten erfolgen.

  9. mts

    Hallo Dieter danke für deine nette Rückmeldung :-)

    hach das freut mich echt

    schnelles Hosting und absolut leistbar bietet
    http://uberspace.de/tech

    nebst offenem Ohr für NonServerFreaks und mehr ;)

    @Plugins,
    ja das auch, vorallem sind manche Plugins stur => bis man da die style.css in den header und die js Scripte in den Footer bringt muss man sie arg oft überlisten ;)