SEO-Maßnahmen für nicosteiner.de
Google hat nicht alle Artikel meines Blogs indiziert. Das könnte eventuell an der Linkstruktur liegen. Ältere Artikel sind nur über die Blätter-Funktion verfügbar - fast 20 Links, um bis zu den ältesten Einträgen zu gelangen. Um dies zu verbessern, habe ich fehlende Kategorien für alle Artikel ergänzt. Weiterhin werden jetzt am Ende der Seite die monatlichen Archive der letzten 2 Jahre direkt verlinkt. Diese Maßnahmen sollten zu einer besseren Indizierung innerhalb der nächsten Wochen führen. Ich bin gespannt, ob sich das an den Suchmaschinen-Keywords und der Anzahl der Visits bemerkbar macht.
?!?
Aha... Na dann hoffen wir mal das Beste 
SEO vs. SEM
Bisher nahm ich an, dass Traffic, welcher über die natürliche Suche von Google generiert wird, besser konvertiert als z. B. bezahlter Traffic über Google Adwords. Einfach weil das des öfteren in SEO-Blogs so kommuniziert wurde, und weil ich als Entwickler von SenSEO auch gerne an so etwas glauben möchte. Im YOUmoz-Blog wurde der Artikel True or False: Organic Traffic Converts Better than PPC veröffentlicht, der mich an meiner Annahme zweifeln ließ.
Um diesem Artikel nun Paroli zu bieten, kommen hier Zahlen aus einem mir bekannten Projekt, welches ich nach ähnlichen Kriterien, wie sie der YOUmoz-Artikel vorgibt, ausgewertet habe. Leider konnte ich keine passenden Keywords für die Vergleiche finden, weshalb ich die Gesamtzahlen betrachtet habe.
| Traffic-Source | Visits | Conversion Rate |
| Paid Traffic (Content targeting) | 6504 | 6,07 |
| Paid Traffic (Adwords) | 8138 | 6,23 |
| Paid Traffic (all) | 14642 | 6,15 |
| Direct | 3802 | 5,34 |
| Organic | 2501 | 12,12 |
| Referring Sites | 1868 | 7,28 |
Im Falle dieses Projekts wäre es durchaus sinnvoll, einen Teil des Budgets aus dem bezahlten Traffic abzuziehen und in Suchmaschinen-Optimierung zu investieren. Alternativ könnten die Keywords, welche über die natürliche Suche besonders gut konvertieren, zusammen mit deren Landing Pages in die Adwords-Kampagne aufgenommen werden, um die Conversion Rate des bezahlten Traffic zu verbessern.
Vielleicht abschließend noch eines meiner eigenen Projekte - diesmal allerdings ohne bezahlten Traffic.
| Traffic-Source | Visits | Conversion Rate |
| Organic | 266782 | 30,76 |
| Direct | 18083 | 42,37 |
| Referring Sites | 16144 | 25,60 |
Diesmal sind die direkten Aufrufe ganz vorn. Das ist nicht weiter verwunderlich, handelt es sich doch bei dem Projekt um einen kostenlosen Service, der wohl gerne mündlich weiterempfohlen wird. Solch eine Empfehlung wirkt sich in diesem Fall traumhaft auf die Conversion aus.
Es sieht so aus, als müsse man die Beziehung von der Conversion Rate zur Quelle des Traffic für jedes Projekt individuell analysieren (so wie es auch in dem YOUmoz-Artikel angedeutet wurde). Das sich solch eine Analyse und die daraus gezogenen Schlüsse durchaus rechnen können, zeigen die großen Unterschieden zwischen den verschiedenen Zahlen recht deutlich.
Jasmin-Servlet mit Versionierung und Far Future Expires Headern
Die Far Future Expires Header kommunizieren dem Browser wie hier beschrieben, dass sich die ausgelieferten Ressourcen für einen sehr langen Zeitraum nicht verändern werden. Dies verhindert, dass der Browser bei jedem neuen Anfordern der Ressource beim Server erfragt, ob sich die Ressource zwischenzeitlich verändert hat. Statt dessen stellen diese Header sicher, dass der Browser die Stylesheets und Scripte ab dem 2. Request wenn möglich immer aus dem Cache bezieht.
Es könnte sich hierbei die Frage stellen, wie ein erneutes Laden bei Veränderungen dieser Ressourcen erzwungen werden kann.
An dieser Stelle kommt das zweite neue Feature - die Versionierung - zum Zuge. Eine Ressource wird von Browsern anhand ihres URLs identifiziert. Eine Ressource mit einem veränderten URL wird immer neu vom Server geladen, sofern diese unter dem veränderten URL nicht im Cache gefunden wird. Bei jedem Onlinegang eines Projekts wird deshalb ein Zeitstempel erzeugt, welcher bis zum nächsten Onlinegang unverändert in jeden Jasmin-Request integriert wird. Dabei wird der Zeitpunkt des Onlinegangs als Referenz verwendet. Dies ist der einzige Moment, an dem sich Änderungen an den Jasmin-Ressourcen ergeben können und an dem sichergestellt sein muss, dass alle Scripte und Styles einmalig neu vom Servlet an alle Clients ausgeliefert werden.
Das Jasmin-Servlet zur Auslieferung der CSS- und JavaScript-Ressourcen nähert sich mit diesen neuen Features einem finalen Stand.
Im Zuge dieser neuen Version habe ich testweise eine Umstellung der Integration der JavaScripte vorgenommen. Wo bisher am Ende der Seite ein klassisches HTML Script-Tag verwendet wurde, kommt jetzt die sogenannte Managed XHR Technik zur Anwendung. Geprägt hat diesen Begriff Steve Souders in seinem Buch Even Faster Web Sites. Dabei erwiesen sich die schon vorher notwendig gewordenen Umstellungen für das Laden der Scripte am Ende der Seite als äußerst nützliche Vorarbeit. Nach einem ersten Eindruck führt diese Umstellung besonders in den Internet Explorern zu einer deutlich schnelleren Anzeige der Seiten.
SenSEO 1.0 veröffentlicht
Am 21. Oktober 2008 habe ich die Firefox-Extension SenSEO veröffentlicht. Nach einem Jahr Entwicklungzeit ist seit ein paar Minuten Version 1.0 von SenSEO bei den Mozilla Add-Ons (vorerst) experimentell verfügbar.
In dieser Version kamen keine neuen Features hinzu. Statt dessen gibt es am Ende der SenSEO-Analyse einen Hinweis auf die Möglichkeit einer PayPal-Spende. Jetzt kann der Rubel rollen
Ansätze für den Umgang mit Tracking-Pixeln
Ein Tracking-Pixel ist ein für gewöhnlich 1x1 Pixel großes Gif, welches von einem Server mit Hilfe eines IMG-Tags abgerufen wird. Interessant ist dabei, dass mit dem Request Tracking-Daten übermittelt werden, welche auf dem Pixel-Server geloggt werden. Die Grafik ist dabei nur eine Krücke, da in den Anfängen dieser Idee eine Technik wie AJAX zur Übermittlung von Daten aus einer Seite heraus noch nicht bekannt war und diese Lösung auch ohne JavaScript implementiert werden konnte.
Doch Tracking-Pixel haben ihre Nachteile. Zum einen tendiert diese Technik zum Ausufern. Sind viele Systeme an einer Website beteiligt, bringen diese oft auch eigene Implementierungen solcher Pixel mit. Denn einen Standard für Tracking-Pixel gibt es nicht. Noch dazu werden Tracking-Pixel fast immer von Servern mit eigenen Domains abgerufen, was zu einer Häufung von DNS Lookups führt. Nicht zuletzt integrieren sich diese Server mit ihrem Response-Verhalten in das eigene Frontend - geraten sie unter zu große Last oder fallen sie gar ganz aus, hat das direkten Einfluß auf die eigenen Seiten.
Um diese Probleme in den Griff zu bekommen, gäbe es zwei Ansätze.
Der erste, relativ einfach zu implementierende Ansatz, wäre eine Umstellung der Requests von einem IMG-Tag auf einen asynchronen AJAX-Call. Dies hätte den Vorteil, dass das Response-Verhalten fremder Server sehr viel weniger kritisch wäre. Die Daten würden asynchron außerhalb des Kontext des eigentlichen Ladens und Renderns der Seite abgerufen. Dabei sollte es egal sein, ob das zurückgelieferte Pixel tatsächlich in die Seite eingebettet wird - es zählt ja einzig der Request. Eventuelle Verzögerungen oder Server-Ausfälle würden keinen direkten Einfluß mehr auf die eigene Website haben. Leider muß man bei dieser Lösung im Frontend immer noch auf die unterschiedlichen Implementierungen der Anbieter Rücksicht nehmen.
Um zumindest im Frontend von den unterschiedlichen Implementierungen der Tracking-Pixel-Anbieter wegzukommen, gäbe es einen zweiten Ansatz. Man würde einem auf dem eigenen Server befindlichen Script alle nötigen Daten mit genau einem Tracking-Request übergeben. Das Script würde diese Daten dann auf die unterschiedlichen Tracking-Pixel-Requests mappen, und die Grafiken dann direkt vom Server aus abrufen. Die Logik zur Behandlung unterschiedlicher Pixel würde also komplett von einem Tracking-Script übernommen werden. Damit wären zumindest aus Frontend-Sicht alle Probleme gelöst.
1&1 DSL - Performance-Optimierungen
Das DSL-Projekt ging letzte Woche mit dem neuen Jasmin-Servlet 2.1 online. An diesem Beispiel möchte ich zeigen, wie eine weitere Optimierung dieses Projekts aussehen könnte.
Der erste Request
In der nachfolgenden Grafik sind sämtliche Requests in Form ihrer Bestandteile, Downloadzeiten und Latenzen beim ersten Aufruf der DSL-Startseite zu sehen. Die Latenzen werden dabei von der Software simuliert, stimmen aber in ihren Relationen zueinander.
Gleich die ersten Requests (1) wären Kandidaten für eine Optimierung. Das Pustefix-Framework macht ihr diverse Redirects, bevor es die eigentlichen Inhalte ausliefert. Ideal wäre natürlich wenn dies bereits mit dem ersten Request geschehen würde. Somit könnte die Zeit bis zum ersten Rendern der Seite (die grüne, vertikale Linie) deutlich verkürzt werden. Auch die mit (2) gekennzeichneten Requests beeinflussen den Zeitpunkt des ersten Renderns negativ. Diese Requests fordern die Stylesheets des Dokuments an. Die Platzierung der Requests ist optimal, je eher die Stylesheets geladen werden, desto besser. Allerdings ist die Größe der Daten ein Problem. Dies beeinflußt nicht nur die Downloadzeit sondern auch die Zeit der Interpretation der Stylesheets (3). Insgesamt dauert es in dieser Simulation mehr als eine Sekunde, diesen Prozess abzuschließen. Das ist immerhin 1/7 der Zeit, die der Browser mit der kompletten Darstellung des Dokuments beschäftigt ist. Zukünftig wird es dank des PMT möglich sein, diverse veraltete Selektoren aus den Stylesheets zu entfernen, was an dieser Stelle eine deutliche Verbesserung bringen sollte.
Im Anschluß an die Stylesheets werden die Grafiken der Startseite angefordert. Hier lassen sich für den ersten Request kaum Optimierungen finden. Eventuell sind einige weitere Hintergrundgrafiken Kandidaten für CSS-Sprites.
Interessant wird es wieder bei den JavaScript-Requests (4). Auch hier wird deutlich, dass der Umfang der Scripte recht groß ist, was wiederum zusätzlich zu einer Verzögerung bei der Interpretation des JavaScript-Codes (5) führt. Hier werden wir in Zukunft auf eine asynchrones Laden der Scripte mit einem Managed XHR setzen. Wem das nichts sagt, dem sei das Buch Even Faster Web Sites von Steve Souders empfohlen. Den Teil zum asynchronen Laden von JavaScript finde ich in diesem Buch neben den JavaScript-Code-Optimierungen am interessantesten.
Den Abschluß bilden jede Menge Tracking-Pixel-Requests. Diese stellen eine Besondere herausforderung dar, da sie nicht Teil der eigenen Infrastruktuer sind, sondern oftmals von fremden Servern, mit all den Nachteilen die so etwas hat, bezogen werden. Gerade heute morgen hatte ich eine Idee, wie wir dieses Problem mit einer zentralisierten Lösung für solche Requests in den Griff bekommen könnten - mal sehen, was mein Chef dazu meint 
Der zweite Request
Dieser Request wird maßgeblich davon beeinflußt, dass der Browser bestimmte Daten bereits im Cache zwischengespeichert hat. Nur unter gewissen Umständen fordert dieser Daten erneut vom Server an.
Hier wirken sich die Redirects bis zur Auslieferung des HTML-Codes (1) in Relation noch massiver aus. Ein wesentlicher Teil der zeit bis zum ersten Rendern der Seite wird dafür beansprucht.
Ein viel größeres Problem wird durch die Bereiche (2), (3) und (4) sichtbar. Diese Bereich stellen sogeannte Conditional GET-Requests dar. Dabei wird beim Server erfragt, ob sich die bereits beim ersten Request abgerufenen Daten in der Zwischenzeit verändert haben. Bei den hier dargestellten Daten handelt es sich ausschließlich um Grafiken. Da sich das System, welches Grafiken zentral ausliefert und diese nur bei Veränderungen entsprechend neu versioniert, noch in der Planung befindet, müssen wir mit diesem Problem leider noch eine Weile leben.
Als Fazit kann man sagen, dass wir mit unseren bisherigen Bemühungen schon große Schritte in Richtung eines performanten Frontends gegangen sind. Die hier beschriebenen Ansätze werden noch einmal eine deutliche Verbesserung bringen. Mit dem Ende dieser zweiten Phase wird das Thema Performance-Optimierung architektonisch abgehakt sein. Natürlich müssen wir während des Entwicklungsprozess bestehender und neuer Projekte darauf achten, Optimierungen am JavaScript-Code und an dem Umfang der ausgelieferten Ressourcen nicht aus dem Auge zu verlieren und als kontinuierlichen Teil unserer Arbeit zu sehen.
Die komplette Analyse ist bei webpagetest.org zu finden.
Verhindern von Focus-Rahmen - Teil 2
Ich hatte vor einer ganzen Weile hier im Blog einen Vorschlag gemacht, wie sich mit Hilfe von JavaScript der Focus-Rahmen beim Klicken eines Elementes mit der Maus verhindern läßt. Gerade eben bin ich auf einen Artikel gestoßen, der eine viel simplere Lösung beschreibt, welche den gleichen Effekt erzielen soll. Better CSS outline suppression schlägt vor, den Rahmen lediglich mit der Pseudo-Klasse :active auszublenden. Klingt wirklich einfach, ich werde mir das die nächsten Tage mal genauer ansehen. Dieser Test ist Teil der Keyboard Accessibility Presentation von Patrick Lauke.
Archive
- Februar 2010 (10)
- Januar 2010 (11)
- Dezember 2009 (8)
- November 2009 (6)
- Oktober 2009 (10)
- September 2009 (9)
- August 2009 (12)
- Juli 2009 (16)
- Juni 2009 (17)
- Mai 2009 (8)
- April 2009 (12)
- März 2009 (8)
- Februar 2009 (10)
- Januar 2009 (9)
- Dezember 2008 (2)
- November 2008 (8)
- Oktober 2008 (13)
- September 2008 (3)
- August 2008 (5)
- Juli 2008 (9)
- Juni 2008 (5)
- Mai 2008 (5)
- April 2008 (7)
- März 2008 (2)
- Januar 2008 (3)
- September 2007 (4)
- Das Neueste ...
- Älteres ...
