Ich habe vor ein paar Wochen den Speed meines Reise-Blogs mächtig erhöhen können. Dabei hat mir das kostenlose Analysetool Pingdom sehr geholfen.

In verschiedenen Gesprächen, in diversen Facebook-Guppen, wurde danach mehrfach der Wunsch an mich heran getragen, einen Beitrag über die getroffenen Maßnahmen zu schreiben. Das möchten ocj hiermit machen und zeigen, wie man in Pingdom die Bremsen beim Seitenaufbau erkennen kann. Im Zuge der Diskussionen haben ich mir die Ladezeiten einiger Seiten ansehen können. Dabei sind mir oft die gleichen Ursachen aufgefallen, welche auf vielen Seiten die Ladezeiten in den Keller ziehen. Auch diese fassen wir in diesem Artikel mal zusammen.

Warum soll die Blog Geschwindigkeit eigentlich optimiert werden?

Im Grund gibt es zwei Gründe, die für eine Optimierung der Ladezeit des eigenen Blogs spricht:

Kurze Ladezeiten erfreuen Deine Leser!

Deine Leser werden es dankbar zur Kenntnis nehmen, wenn die Seite schnell geladen und angezeigt wird. Keiner will ernsthaft 3 Sekunden oder länger warten, bis die Seite angezeigt wird. Da nützen auch keine lustigen Wartebildchen was, die man vereinzelt auf verschieden Seiten sieht. Da drehen sich Kreise oder andere Symbole lustig im Kreis rum, Ladebalken wandern über den Bildschirm oder es passiert einfach lange nichts, gar nichts.

Das will kein Besucher sehen und viele verlassen die Seite nach 2 Sekunden Wartezeit. Es ist belegt, dass die Schmerzgrenze schnell erreicht ist und die Besucher flüchten. Zusätzlich muss bedacht werden, dass viele Besucher eben nicht über eine Powerleitung ins Netz verfügen oder mit ihrem mobilen Geräten ein begrenztes Datenvolumen besitzen. Wo eine Seite mit einer schnellen DSL-Leitung schon mehrere Sekunden lädt, dauert es mit einer ISDN- oder UMTS-Verbindung noch um einiges länger.

Daher sollte neben dem Speed auch die Seitengröße im Auge behalten werden. Natürlich, die Zeit wo eine komplette Webseite 200 Kilobyte groß war, die ist vorbei. Aber 10 Megabyte müssen es auch nicht zwingend sein, selbst auf Fotografie-Seiten, wie unsere eine ist.

Pagespeed ist ein Ranking Faktor bei Google

Google nutzt zum festlegen des Rankings über 200 Faktoren, die bei der Bewertung einer Seite eine Rolle spielen. Ein Bereich davon ist die Usability der Seite, wozu auch der Pagespeed gehört. Wir stark das wirklich bewertet wird, weiß wenn überhaupt nur Google selber. Aber, einige Seitenbetreiber haben unseren Eindruck bestätigt, dass ein paar Tage nach einer Speedoptimierung die Zugriffe auf die Webseite über Google spürbar angestiegen sind.

Natürlich bring es nichts, wenn die Inhalte der Seite wegen anderer Mängel (schlechter Content, schlechte Keywords usw.) gar nicht erst im Ranking sind. Da bringt auch die beste Speedoptimierung nichts. Die Grundlagen des Blogs sollten schon stimmen. Und die Optimierung der Ladezeit sollte nach dem Erstellen von guten Content nur eine „Nebenrolle“ spielen und einen zusätzlichen Effekt bringen.

Es muss keine Maximaloptimierung sein, sondern einfach nur eine schnelle Webseite

Ich möchte noch darauf hinweisen, dass alle nachfolgenden Tipps und Einschätzungen meine persönliche Meinung und Erfahrung als ganz normale Blogger darstellen. Einige Technik-Freaks werden vielleicht die Hände über dem Kopf zusammen schlagen. Für mich steht einfach die gute Erreichbarkeit unserer Seite, gepaart mit einer noch lesbaren Seite – die auch noch ansprechend aussieht – im Vordergrund. Ich willen keine Preise für die beste Optimierung auf 100% in allen Ebenen bekommen.

Pingdom oder Google Page Speed?

Häufig habe ich in den letzten Tagen gelesen, dass versucht wurde den Speed seiner Webseite mit Google Page Speed zu optimieren. Das ist, unserer bescheidenen Meinung nach, der völlig falsche Weg. Google Page Speed beurteilt die Performance und misst nicht die Geschwindigkeit einer Webseite.

Es zeigt Verbesserungspotential an und bewertet die Umsetzung mit Prozenten/Punkten. So kann es vorkommen, dass eine Seite bei Google Page Speed hervorragend bewertet ist aber grottenlangsam ist oder umgekehrt rasend schnell lädt und trotzdem keine guten Werte bei Google Page Speed bekommt.

Mehr über den Sinn von Google Page Speed hat Ernesto Ruge auf seinem Blog binary-butterfly sehr informativ und lesenswert zusammengefasst.

Pingdom dagegen misst wirklich die echte Ladezeit einer Seite und gibt einem viele Informationen darüber, wo man ansetzen kann um die Ladezeit zu minimieren.

Es gibt noch weitere brauchbare Tools, um die echte Geschwindigkeit eines Blogs zu messen:

Alle drei Anbieter messen die echte Ladezeit Deines Blogs und liefern dazu mehr oder weniger detaillierte Informationen. In diesem Artikel beschränke ich mich auf Pingdom. Da werden die Ergebnisse schön kompakt auf einer Seite dargestellt. Für eine grundsätzliche Messung und Optimierung reicht das vollkommen aus.

Pingdom – Einstellungen und Ergebnisse

Pingdom findest Du im Netz unter der folgenden Adresse: https://tools.pingdom.com Nach dem Start der Seite, siehst Du oben den Bereich zur Eingabe der URL und kannst den Testserver auswählen.

Test bei Pingdom starten

Pingdom Startmaske

Wichtig ist es, hier einen Testserver in Europa auszuwählen. Ein Test über einen US-Server wird immer langsamer sein und liefert Dir keine passenden Werte um die wirkliche Geschwindigkeit zu beurteilen.

Zusammenfassung der Ergebnisse

Nachdem Du auf Start Test geklickt hast, startet der Speed Test für die eingegebene URL. Die Ergebnisse werden Dir nach Ablauf des Tests im oberen Bereich als Zusammenfassung angezeigt. Starte diesen Test ruhig 2-3 mal hintereinander. Gerade beim ersten Lauf kann es passieren, dass eine nicht gecachte Seite erwischt wird und die Werte schlechter sind. Ab dem 2. Durchlauf sollten diese dann aber halbwegs stabil sein. Sollten die Ergebnisse bei vielen Durchläufen immer sehr stark schwanken, dann hast Du schon ein erstes Problem entdeckt.

Pingdom Speed Test - Ergebnis

Was bedeuten nun die einzelnen Werte?

Performance Grade: Das ist eine Bewertung, ähnlich wie bei Google Page Speed, wo alle möglichen Parameter in Notenform bewertet werden. Über die wirkliche Geschwindigkeit sagt dieser Wert nichts aus!

Load Time: Das ist der wirklich gemessene Wert, die Ladezeit Deiner Seite. Diesen solltest Du auch bei Optimierungen im Auge haben. Bei mir lag der Wert, vor der Optimierung, bei ca. 1,8 Sekunden. Ab zwei Sekunden und weniger, so sagt man, lächelt Google immerhin schon wohlwollend. Richtig erfreut ist Google aber wohl erst bei Werten unter einer Sekunde. Inwieweit diese Gerüchte jetzt stimmen, das lasse ich mal dahingestellt. Fakt ist auf jeden Fall, je schneller, desto besser.

Faster than: Das ist ein total unwichtiger Wert, eine Art Längenvergleich unter Webmastern. Oder sehe es als virtuellen Schulterklopfer.

Page Size: Das ist die Menge an Daten, die geladen werden um Deine Seite darzustellen. Diesen sollte man so niedrig wie möglich halten ohne dabei die Optik seines Blogs zu zerstören. Ich konnte diesen Wert mit auf meinem Blog sehr stark reduzieren. Aber als Blog mit einem Schwerpunkt auf Fotos werde ich niemals die Seitengröße eines reinen textbasierten Blogs erreichen. Versuche aber mit diesem Wert in einem vernünftigen Bereichen zu bleiben. 10 MB sind definitiv zu groß, von mehr will ich gar nicht reden. Fakt ist, jedes gesammelte MB will geladen werde und wirkt sich somit direkt auf die Load Time aus.

Requests: Hm, einfach erklärt: Wie viele „Puzzleteile“ müssen geladen werden, damit die Seite am Ende komplett dargestellt wird. Bei meiner Startseite setzt sich das aus 60 Bildern (Fotoblog halt), 8 Scripten, 3 CSS-Dateien, 1 HTML-Datei und 4 sonstigen Elementen zusammen, das ergibt dann den Wert 76. Einen idealen Wert gibt es für die Requests nicht. Je niedriger der Wert ist, desto weniger Datenanfragen müssen gestellt werden und umso weniger Daten müssen übertragen werden.

Sollte Dein Server html/2 einsetzen, dann sind viele Requests vielleicht sogar ein Vorteil. Bei html/2 ist es möglich, mehrere Requests parallel abzuarbeiten. Dann kann es schneller sein, viele kleinere Anfragen zu bedienen wie eine Große.

Perfomance Insights

Performance TippsIm nächsten Abschnitt findest Du die einzelnen Bereiche, woraus sich der Performance Grade aus der Zusammenfassung errechnet.

Wenn hier alles grün ist, so erfreue Dich an dem Anblick. Sollten dabei die Werte trotz grüner Anzeige nicht auf 100% stehen, so lohnt sich ein Klick auf den Pfeil rechts. In dem Slide-Down werden Dir Dinge angezeigt, die noch nicht optimal in diesem Bewertungsbereich sind und Tipps, wie das zu beheben ist.

In dem Beispiel hier im Screenshot sieht man, dass da noch Kleinigkeiten angemeckert werden. Nur, diese „Schwachstellen“ zu beseitigen ist nicht ganz trivial und solange die Gesamtbewertung stimmt und der Speed auch noch schnell ist, ist es auch gar nicht mein Bestreben an dieser Stelle überall die 100% zu erreichen.

Sollte Dir Teile dieser Auswertung orange oder rot angezeigt werden, dann solltest Du über eine Optimierung der einzelnen Punkte nachdenken. Viele Dinge sind dabei aber einfach mit wenigen Klicks im hoffentlich vorhandenen Caching-Plugin zu beseitigen.

Response Codes

Response Codes

In diesem Bereich werden Dir Fehlermeldungen angezeigt, wenn einzelne Puzzleteile der Seite nicht erreichbar sind. Sollten dort 4XX oder 5XX Meldungen auftauchen, solltest Du Dich dringend darum kümmern. Denn dann sind einzelne Komponenten Deiner Seite nicht erreichbar.

Informationen zum Content Type

Content Type

In diesem Bereich bekommst Du Informationen über die Größe und die Anzahl der einzelnen Inhaltstypen, die auf Deiner Webseite geladen werden. Bei mir sind natürlich Bilder ein wesentlicher Bestandteil der Seite, sowohl was die Datenmenge angeht als auch bei der Anzahl.

Diese Anzeige ist sicherlich interessant um mal einen Einblick zu bekommen, welche Datenmangen von welchen Modularten geladen werden. Viel interessanter ist aber der nächste Abschnitt.

Informationen zum Content by Domains

Content by Domains

In dieser Ansicht kannst Du sehen, von welchen Domains beim Aufbau Deiner Seite Daten geladen werden. Ganz oben in den Listen sollte natürlich Deine eigene Domain stehen. Bei mir tauchen dann noch externe Domains auf, von denen z.B. Schriften geladen werden oder Daten für die Statistik übertragen werden. (Anmerkung: Mittlerweile tauchen da keine externen Ressourcen mehr auf. Nach Einführung der DSGVO habe ich die alle abgeschaltet.)

Diese externen Domainzugriffe sollten so weit wie möglich minimiert werden, denn die fressen Ladezeit. Gerade das Laden von irgendwelchen Boxen oder Bannern dauert oft viel zu lange und kann nicht wirklich optimiert werden.

Ein paar Dinge, wie zum Beispiel die Einbindung von Analysetools wie Google Analytics oder Piwik (jetzt Matomo) sind nun mal wichtig. Natürlich kann man diese Scripte, ebenso wie Schriftarten, auch auf dem eigenen Server zur Verfügung stellen. Nur stellt sich dann die Frage, wie weit will man bei der Optimierung gehen? Welchen Aufwand will man betreiben. So könnte man z.B. die Javascript-Datei von Google Analytics auf den eigenen Webserver legen, das ist schnell gemacht und es müsste nur ein Pfad im Trackingcode geändert werden. Nur, das Script wird ja gelegentlich mal aktualisiert. Wenn dann das aktuelle Script nicht auf dem eigenen Server liegt, funktioniert vielleicht die Statistik nicht mehr.

Daher gilt es hier einen Kompromiss zu finden, zwischen Aufwand für die Optimierung und Nutzen. Und nur so nebenbei, die zwei Fonts und das bisschen Statistik sind das kleinste Problem. Andere externe Dienste versauen einem viel mehr den Pagespeed. Dazu aber später mehr.

Der Wassefall in Pingdom

Pingdom WasserfallDie oben genannten Bereiche in der Auswertung sind alle nett um sich einen Überblick zu verschaffen. Richtig wertvoll ist aber der sogenannte Wasserfall, der nun auf der Seite folgt.

Hier kannst Du detailliert sehen, welches Puzzleteil (Request) wann geladen wird und wie lange das Laden dauert. Mithilfe dieser Ansicht lassen sich Geschwindigkeitsbremsen am besten erkennen.

Kurze Regel: Je länger ein Balken ist, desto böse!

Dummerweise sind die Balken oft verzerrt, wenn ein extrem langer Balken im Spiel ist. Ist dieser dann beseitigt, erscheinen 5 neue lange Balken. Da musst Du durch.

Neben den Ladezeiten werden Dir die Dateigrößen angezeigt und unter dem Namen des Elements noch die Quelle als Pfad auf Deinem Blog oder eine externe Domain.

Aus all diesen Einzelwerten, bzw. Puzzleteilen, werden die oben beschriebenen Gesamtwerte errechnet. Wenn Du also die Gesamtbewertung, die Gesamtladezeit oder die Anzahl der Requests reduzieren willst, so kannst Du in diesem Wasserfall nachschauen, wo es sich lohnt anzusetzen.

Nicht nur die Startseite testen!

Bevor wir uns nun die verschiedenen Fehlerquellen anschauen, noch einen wichtigen Tipp. Teste während der Analyse und der Optimierung nicht nur Deine Startseite vom Blog. Eine Fehlerquellen sind da oft gar nicht zu sehen. Teste stichprobenartig auch mal ein paar Beitragsseiten oder statische Seiten. Oft tauchen da noch ganz andere Probleme auf, die auf der Startseite gar nicht bemerkt werden (Kommentarfunktion, Sharing, Autorenbox usw.).

Häufige Geschwindigkeitsbremsen

Neben den Optimierungen in den letzten Wochen haben ich mir zahlreiche Speedwerte von anderen Blogs angeschaut. Das waren meistens Reiseblogs, wobei das eigentlich nichts zur Sache tut. Die üblichen Bremsklötze sind über verschiedene Blogsparten vermutlich sehr ähnlich.

An dieser Stelle ist ein Satz sehr wichtig:

Speedoptimierung auf dem Blog kann sehr schmerzhaft sein!

Langsamer Server oder fehlerhaftes / kein Caching

Einen langsamen Server, ein fehlerhaftes oder nicht vorhandenes Caching erkennt man meist am ersten geladenen Balken im Wasserfall, also die Zeile, wo vorne einfach Eure URL steht. Wenn diese länger als 0,2-0,5 Sekunden ist, dann besteht da Verbesserungsbedarf.

Bevor Du nun fluchtartig den Provider wechselt, schaut erstmal nach einem vernünftigen Caching.

Beim Caching werden die Seiten nicht mehr als einzelne Bausteine ausgeliefert, sondern vorbereitet als fertige Seiten, eben aus dem Cachespeicher (Das war jetzt gaaaanz einfach erklärt). Dabei entfällt das Zusammensammeln der einzelnen Puzzleteile und dieser erste Ladevorgang geht deutlich schneller. Erst wenn ein gutes Caching keine deutliche Besserung bringt, solltest Du das Problem beim Server suchen.

Was ist denn ein gutes Cache-Plugin? Auch diese Frage erreichte mich in den letzten Tagen öfters.

Ich habe in den letzten Monaten einige ausprobiert. Am Ende bin ich auf dem Reiseblog bei WP-Rocket hängen geblieben. Das macht vom ersten Moment an, was es tun soll, die Seite klein und schnell. Selbst mit den Standardeinstellungen nach der Installation war die Seite bereits deutlich schneller. Wenn man die Einstellungen noch ein wenig verfeinern und optimieren will, ist die Konfiguration schlank und übersichtlich. Nachteil von WP-Rocket, es kostet Geld. Ich bin aber der Meinung, gute Arbeit muss auch honoriert werde und ich habe bis heute keinen Cent für das Plugin bereut.

Andere Caching Plugins müssen aber nicht schlechter sein. Bei mir haben diese aber zum Teil für merkwürdige Phänomene auf dem Blog gesorgt, waren zu kompliziert oder haben einfach keine Verbesserung  bei der Ladezeit gebracht.

Hier aber mal ein paar kostenlose Caching-Plugins, die Du testen kannst:

Zum Thema Caching und die verschiedenen Techniken könnte man wohl ganze Blogs füllen. Gerade eben ist dazu aber ein toller Artikel bei Ernesto auf seinem Blog Binary Butterfly erschienen, wo das Ganze wirklich sehr gut erklärt wird. Ja, ich verlinke immer wieder mal Richtung Ernesto – er ist absoluter Profi und kann trotzdem für Einsteiger erklären – also hat er es auch verdient. Wer also ein wenig mehr rund um das Thema Caching lernen will, ist dort gut aufgehoben.

Schlecht programmierte Themes

Ein weiteres Manko sind oft schlecht programmierte Themes. Dabei meine ich schlecht in Bezug auf unnötigen Krempel, welchen diese Themes mitbringen. Da werden oft zahlreiche Funktionen integriert um alle möglichen Dinge zu erledigen oder darstellen zu können. Dumm ist es in dem Moment, wenn man diese Funktionen gar nicht benötigt und sie nicht deaktiviert werden können.

Ein gutes, performantes Themes kann auch viele Funktionen haben. Nur werden diese entweder als zusätzliche Plugins angeboten oder man kann sie deaktivieren, wenn sie nicht benötigt werden.

Plugins als Bremsklotz

Ein häufiger Bremsklotz bei Blogs sind schlecht programmierte Plugins.

Ich möchte dabei auch mal mit dem weit verbreiteten Vorurteil aufräumen, dass viele Plugins eine Installation automatisch langsamer machen. Das stimmt so pauschal nicht! Ein einziges Plugin kann die Performance massiv in den Keller ziehen. Viele Plugins in Summe müssen das nicht unbedingt machen.

Schlechte Plugin, im Sinne der Ladezeit kann man am besten durch Testen herausfinden.

Ich habe dazu einfach alle Plugins auf meinem Blog deaktiviert und dann den Speedtest gestartet. Danach habe ich ein Plugin wieder aktiviert und wieder den Speed gemessen und auch die Anzahl der Requests und die Seitengröße im Auge gehabt. Das habe ich dann für jedes Plugin einzeln wiederholt. So hatten ich am Ende 3 Plugins identifiziert, die sich extrem negativ auf die Ladezeit ausgewirkt haben.

Dummerweise waren das drei Plugins, die ich eigentlich sehr ins Herz geschlossen hatte. Trotzdem sind diese dann runter geflogen, 2 Ersatzlos und eines wurde durch ein performanteres Plugin eines anderen Anbieters ersetzt. Das sind wir wieder bei dem Punkt, dass eine Optimierung schmerzhaft sein kann.

Ganz besonders negativ waren zwei Plugins, welche die admin-ajax.php beim Seitenaufbau geladen haben. Diese Datei lässt sich nicht cachen und hat die Ladezeit um eine gute halbe Sekunde in den Keller gezogen.

Viele Plugins laden auch andere Scripte von externen Quellen nach. Auch diese kannst Du im Wasserfall identifizieren und dann nachschauen, ob Du die damit verbunden Funktionen benötigst oder diese ggf. in den Einstellungen deaktivieren kannst.

Wenn ich jetzt neue Plugins installiere, dann testen ich vor und nach der Installation die Seitengeschwindigkeit. Sollte die sich massiv negativ verändern, fliegt das Plugin direkt wieder runter.

Ein Hinweis noch: Viele Plugins sind nicht unbedingt ein Problem bei der Seitengeschwindigkeit. Jedes installierte Plugin ist aber primär ein Sicherheitsrisiko für den Blog. Das sollten sich auch Spielkinder, wie ich es bin, immer vor Augen halten und abwägen, ob man bereit ist das Risiko einzugehen.

Facebook-Like-Boxen

Sehr häufig sind mir auf verschiedenen Blogs diese Facebook-Like-Boxen in den Sidebars oder im Footer aufgefallen. Mal abgesehen davon, dass die aus Datenschutzgründen als hochgradig bedenklich anzusehen sind, ziehen sie auch die Ladezeit wunderbar in den Keller.

Facebook Widget

12 Elemente werden in diesem Beispiel von Facebook geladen um diese Like-Box anzuzeigen. Jedes einzelne davon benötigt zwischen 0,2 und 0,8 Sekunden. Und vom Start des ersten Element bis zum Ende der Skala verstreicht eine Gesamtzeit von 1,7 Sekunden. Um diese Zeit ist Dein Blog dann langsamer. Oben hatte ich geschrieben, dass 2 Sekunden der Maximalwert bei der Ladezeit sein sollte. Die sind somit, nur durch die Facebook Like Box, schon fast aufgebraucht.

Schmeiß das Teil vom Blog. Setzte irgendwo ein paar Links zu Deinen Social Media Profilen, die der Besucher anklicken kann, wenn er Dir folgen will.

Und jetzt bitte nicht sagen, die Box bringt mir doch sooo viele Likes. Das glauben ich nicht, Punkt.

Instagram Bilder eingebettet

Total gerne werden auch die aktuellen Bilder aus dem eigenen Instagram Profil in einem Banner oder einem Widget eingeblendet. Das ist genau so eine Geschwindigkeitsbremse, wie diese Facebook Box. Auch bei der Instagrameinbindung bremst jedes einzelne Bild die Ladezeit Eures schönen Blogs aus. Und auch hier kommt noch das Problem mit dem Datenschutz dazu.

Warum machst Du nicht schnell eine Collage Deiner letzten oder besonders schönen Bilder bei Instagram, ladest diese als Bilddatei auf Deinen Blog und setzt dann einfach den Link zu Deinem Instagram Profil da drauf? Ok, macht mehr Arbeit, aber die Ladezeit wird es Dir danken.

Pinterest Box

Hier gilt das Gleiche wir für die Facebook- oder die Instagram-Einbindung. Muss man das Teil haben? Bringt es was, dass im Blog einzubetten?

Bild an WP ausgelagert

Jetpack bietet eine Funktion namens Photon an, mit der man Bilder bei WordPress auf deren Server spiegeln kann, sodass sie von dort geladen werden. Das soll einen Performacegewinn bringen, sagt WordPress. Schmarrn! Das einzig vorteilhafte dabei ist, dass die Daten parallel von mehreren Quellen geladen werden, dass kann Sinn machen, wenn denn der andere Server schnell ist und in Europa steht. Das nennt sich dann CDN, würde aber den Rahmen hier sprengen. Schauen wir doch lieber mal, was mit einem einfach Bild passiert, wenn es von WordPress geladen wird.

Bild bei WP gespeichert

In diesem Beispiel beträgt die Ladezeit, für ein 67,7 kB großes Bild, sage und schreibe 1,38 Sekunden!!!einself!! Wow.

Du erkennst die von Extern geladenen Bilder an der Adresszeile unter dem Bildnamen, welche mit i0, i1, i2 usw. anfängt.

Schalte diese Funktion ab, lass die Bilder bei Euch im Webspace liegen und erfreut euch an kurzen Ladezeiten. Und wenn Dein Server html/2 unterstützt, umso besser. Denn dabei können auch mehrere Fotos parallel geladen werden.

Sonstige Banner oder Widgets

Ein weitere große Bremse sind viele Widgets oder Banner, die Inhalte von externen Quellen laden. Besonders die nachfolgenden sind mir immer wieder ins Auge gefallen:

  • Travelbook oder andere Banner aus diesem Hause (im Waterfall an der Domain widgets.boomads zu erkennen). Da habe ich Ladezeiten bis zu 1,irgendwas Sekunden gesehen, offensichtlich ganz nach Auslastung des boomads-Servers.
  • Amazon Widgets
  • Bloglovin Widgets
  • Newslettersysteme (vor allem so manches Mailchimp-Plugin)
  • usw.

Du siehst, das sind alles Widgets, die Inhalte von ihren eigenen Servern nachladen.

Der einfachste Weg, das zu optimieren, ist es, die Logos oder andere Bannerinhalte als Datei auf den eigenen Webspace hochzuladen und dann einfach den Link manuell draufzusetzen. Bei Amazon und Bloglovin ist das problemlos machbar. Und ja, bei Amazon geht das auch als Affiliate Link.

Travelbook stellt sich wohl immer noch quer, die bestehen auf ihren Code. Das ist einer der Gründe, warum ich da nicht mitspiele.

Gravatar Bilder

Wir mögen sie alle, die Gravatar Bildchen bei den Kommentaren. So bekommen die Besucher ein Gesicht und die Kommentarbereiche gleichen keinen Textwüsten mehr. Dummerweise werden die Gravatare bei jedem Laden der Seite neu von dem Dienst geladen und können nicht vom Cache gespeichert werden.

Abhilfe schafft hier ein kleines Plugin mit dem Namen Harrys Gravatar Cache, welches die Avatare auf Deinen Server kopiert und diese dann von dort geladen werden. Diese Funktion bieten auch einige Caching-Plugins. Der Vorteil ist nicht nur das die Ladezeit geringer wird, die Bilder werden auch vom Browsercache mit abgedeckt, was zusätzliche Pluspunkte gibt. In dem Plugin kannst Du auch einstellen, wie groß die Avatare gespeichert werden solle und wie lange die im Speicher bleiben, bevor sie aktualisiert werden.

Allerdings ist die Nutzung der Gravatare mit Einführung der DSGVO eigentlich gestorben. Grund dafür ist, dass beim Abruf der Gravatare Daten des Seitenbesuchers an den Dienst übermittelt werden. Und das ist datenschutzrechtlich sehr bedenklich.

Anzahl der angezeigten Kommentare

Viele Kommentare sind toll, das Ziel eines jeden Bloggers. Und wenn viele Kommentare zu einem Artikel gegeben werden, umso besser. Aber, viele Kommentare bedeutet auch viele Gravatar-Bildchen, egal ob mit oder ohne Nutzung des Caches, und somit viele Requests. In den Einstellungen zu den Kommentaren kann ein Umbruch eingestellt werden. Dann werden nur noch 20-25 Kommentare auf einmal angezeigt werden und die weiteren können über eine Pagnation im Kommentarbereich angezeigt werden, wenn Dein Theme das unterstützt (was in der Regel der Fall sein sollte).

Wenn Du auf Gravatare verzichtest, dann ist die Anzahl der Kommentare unter dem Beitrag eher eine eher kleinere Bremse für den Seitenaufbau.

Bilder

Eine weitere große Geschwindigkeitsbremse sind zu große Bilder.

Hier jetzt einen Richtwert zu geben, wie groß ein Bild maximal sein darf, bezogen auf die Dateigröße, ist nicht einfach.

Sagen wir es mal so, eine Bilddatei mit 2, 3 oder noch mehr Megabyte Größe ist definitiv zu groß. Ich persönlich empfinde eine Maximalgröße von 200 KB als angemessen, auf meinem eigenen Blog. Ich betreibe aber auch einen Fotoblog und habe gerne die Exif-Daten in die Bilder eingebettet und arbeite auch gerne mit größeren Auflösungen zum Nachladen auf großen Monitoren.

Ich exportiere die Bilder für meinen Blog meistens aus Lightroom. Dabei wählen ich jpg als Dateiformat und setzen die Qualität auf 60%. Damit komme ich meistens auf Dateigrößen von 150-200 KB. Für die Darstellung im Web reicht das völlig aus. Andere Stimmen sagen, nicht zu Unrecht, dass 100 KB für ein Bild im Netz völlig ausreichend sind.

Bilder, die in Widgets auftauchen, besonders wenn sie auf jeder Seite auftauchen, versuche ich auf eine Größe von ca. 20 KB zu bekommen.

Trotzdem haben ich meine Bilder noch weiter optimiert. In den letzten Wochen habe ich über den Dienst von ShortPixel alle Bilder auf meinem Reiseblog nochmals optimiert. Das waren ein paar tausend Fotos, in alle möglichen Auflösungen meines Themes. Aber es hat sich gelohnt, die Seite ist nochmals ein wenig schneller geworden und die Datenmenge spürbar weniger.

Optimierung durchführen

Wie soll so eine Optimierung nun ablaufen? Ich beschreibe das mal, wie ich das gemacht habe.

  • Erster Speedtest – damit hast Du einen Ausgangswert.
  • Suche Dir eines guten Caching-Plugins
  • Aktiviere des Caching
  • Speedtest
  • Lokalisierung der „Bremsen“ mit Hilfe von Pingdom
  • Plugins alle deaktivieren
  • Ein Plugin nach dem anderen wieder aktivieren und nach jeden einmal den Speedtest laufen lassen
  • Schmerzhaftes Trennen von „bösen“ Plugins
  • Ersatz durch neue Plugins mit besserer Performance (testen)
  • Den Nutzen von Bremsen wie Facebook Box, Instagram, Pinterest Box usw. zumindest mal überdenken. (Dabei an den Datenschutz denken)
  • Optimierung der Bilder in Widgets und im Header
  • Vorschläge aus dem Bereich Perfomance Insights von Pingdom umgesetzt. (Scripts im Footer laden lassen, Browsercaching, Komprimierung der CSS und JS Dateien, usw – alles beispielsweise über WP-Rocket machbar)
  • Jetzt kann ein Blick auf die Google Page Speed Messung geworfen werden – und sich wundern, dass da immer noch bescheidene Werte erscheinen.
  • Überlegen, ob einige der Vorschläge von Google Page Speed noch umgesetzt werden können (Aufwand/Nutzen).

Am Ende hört sich das jetzt wahnsinnig aufwändig an. Wirklich intensiv haben ich da nur zwei Abende dran gesessen. Allerdings ist es sinnvoll, so einen Test regelmäßig zu wiederholen.

Bei allen Optimierungen sollten Aufwand/Nutzen gegeneinander abgewogen werden. Ein paar Schwachstellen finde ich auch bei uns noch. Nach einiger Recherche ist uns aber der Aufwand zu groß, diese zu beseitigen. Und das, um am Ende bei den Perfomance Insights einen Wert von 97 auf 98% zu steigern.

Auch der Faktor „Unbedingt-haben-wollen“ spielt eine Rolle. Wenn Du Dich von einem Tool einfach nicht trennen willst, dann bleibt es halt auf dem Blog. Dann musst Du aber auch bereit sein mit dem Performance Nachteil zu leben.

Und, ganz wichtig – vergesse vor lauter Optimierung nicht den eigentlichen Sinn Deines Blogs. Schreibe zwischendurch auch mal wieder schöne Artikel.

Mein Angebot für Dich – ich schaue mir Deine Blog Geschwindigkeit an.

Ich biete Dir an, einen Blick auf den Pagespeed Deiner zu werfen. Du bekommst dann ein paar Tipps, wo Du bei der Ladezeit einsparen kannst. Und das alles für einen kleinen, annehmbaren Preis. Wenn Du das möchtest, dann schreibe mir einfach eine Nachricht über das Kontaktformular.

Wie ist Deine Erfahrung mit solchen Optimierungen? Hast Du das schonmal gemacht? Oder ist Dir der Speed Deiner Seite egal? Fragen über Fragen, wie gemalt für einen tollen Kommentar hier unten auf der Seite.