Eine andere Möglichkeit ist es, sich wiederholende Dinge zu automatisieren. Hey, wir sind doch Programmierer! Wir sollten das doch gut können!

Im ersten Teil möchte ich mal den Punkt “Setup erstellen” beleuchten:
Gut, wir könnten eine ellenlange Batch-Datei schreiben, die alle erforderlichen Schritte abarbeitet. Oliver hat das lange gemacht.
Oder wir könnten – eine Stufe höher – im Visual Studio die Schritte programmieren. Dies ist zwar ein bisschen schöner, aber im Prinzip immer noch genauso wie Variante 1. (Dies habe ich lange Jahre gemacht.)

In der Umstellung zu der .Net-Welt habe ich mir das Produkt Finalbuilder angesehen – und nach kurzer Zeit gekauft.

Für viele erforderliche Schritte sind vorgefertigte Bausteine verfügbar und man braucht sich nur auf das “Was” und nicht so sehr auf das “Wie” konzentrieren. Nach ein paar Stunden Finalbuilder-Skript bauen hat man zum Schluß nur noch ein Grinsen im Gesicht, wenn alle Schritte grün abgearbeitet werden.

Ich habe die Professional-Edition ausprobiert und kann diese alle mISVlern empfehlen.

Schon zum 19. Mal fand diese Veranstaltung statt. Hier treffen sich sogenannte mISV mit anderen mISV sowie mit Vertretern von anderen Unternehmen, die sich auf E-Commerce bzw. Online-Marketing spezialisiert haben.

Es wurden zahlreiche Themen in zwei parallelen Tracks von verschiedenen Seiten beleuchtet. Unter anderen hielt auch Patrick McKenzie einen Vortrag über Search Engine Optimization (SEO) und wie man Text-Verfasser und Grafiker im Internet finden kann. Patrick lebt in Japan. Das tolle an so einer Konferenz ist, dass man sich direkt mit Leuten unterhalten kann, die weit über den Erdball verstreut sind.

Auch Mode-Themen wie Social Networks oder das Entwickeln von Mobile Applications wurden besprochen. Die Vorträge von Dave Collins über Google Adwords waren wieder einmal sehr interessant. Ein echter Klassiker.
Einen guten Überblick findet man in dem Schedule der Konferenz. Es gibt auch Bilder und einen kleinen Film.

Leider fanden nur wenige Deutsche Software-Firmen zur Konferenz. So waren neben Oliver und mir nur noch iOpus und TuneUp vertreten.

Ich kann nur jedem empfehlen, die Kosten und Mühen für eine Konferenz auf sich zu nehmen. Nimmt man zum ersten Mal an solch einer Konferenz teil, so sind die Sessions das Interessanteste. Doch dann lernt man die anderen Teilnehmer kennen. Das nennt man dann Networking! Und dies ist ungeheuer wichtig. So kann man Erfahrungen austauschen und auch eigene Erlebnisse weitergeben.

Ich bin dieses Jahr insgesamt auf drei Konferenzen: SIC in Dallas/Texas, Business of Sofware Conference in Boston/Massachusetts und ESWC/Wien.

Mein letzter Tipp: Gleich anmelden!!

Heute möchte ich kurz ein etwas sachlicheres Problem bei der Veranstaltung solcher Rabattaktionen ansprechen. Denn auch bei der Wahl und beim Setup des Zahlungsdienstleisters gibt es hier einige Stolperfallen. Wer sich die Arbeit gemacht hat, einen eigenen Shopping Cart zu implementieren und Zahlungen sozusagen selbst abwickelt, hat es hier sich einfacher. Wer aber auf einen oder mehrere der zahllosen eCommerce-Dienstleister zurückgreift, sollte dringend weiterlesen.

Veranstaltet man eine 24h-Aktion nicht selbst, sondern mittels einer Website wie BitsDuJour, dann möchte dieser Partner in der Regel einen guten Teil vom Kuchen ab haben und als Affiliate für die hoffentlich zahlreichen Verkäufe agieren. Schlecht ist das nicht, denn mit einer erfolgsabhängigen Provision legt sich der Partner sicher mehr ins Zeug, wenn es um Präsentation und Bewerbung unserer Software geht.

Einige Zahlungsdienstleister bieten Affiliate-Systeme an, bei denen man sich selbst um praktisch nichts mehr kümmern muss. Affiliates legen dazu beim jeweiligen Dienstleister entsprechende Accounts an. Man selber muss die gewünschten Affiliates in der Regel zunächst freischalten und ihnen einen Provisionssatz zuweisen. Der Affiliate ruft dann die Checkout-Seite des Produkts zumeist über eine spezielle, mit seiner Affiliate-ID präparierte URL auf. Der Dienstleister zieht die Provision beim Hersteller ab und bucht sie auf das Konto des Affiliates. Auch die Auszahlung des Affiliates übernimmt der Dienstleister, was insbesondere bei Partnern im nichteuropäischen Ausland für unsereins recht hilfreich sein kann.

Diese Leistung übernehmen einige Zahlungsdienstleister gratis, andere lassen sich die Zusatzleistung jedoch auch bezahlen. Wer ohnehin mit verschiedenen Unternehmen zusammenarbeitet, tut also gut daran, sich über die Kosten vorab zu informieren, und dann ggf. nur den günstigsten Anbieter für die Rabattaktion zu wählen. Ich arbeite z.B. mit zwei Anbietern, wobei der eine Affiliate-Provisionen kostenlos abrechnet, der andere zusätzliche 2% des Produktpreises dafür abschlägt.

Ein weiteres Auswahlkriterium mag deren Preismodell sein. So mag Provider A mit 5% + $3 für den Originalpreis von $70 günstiger sein, Provider B mit 10% + $1 aber beim rabattierten Preis von $30 die bessere Wahl. Ich schalte beispielsweise bei meinem Provider für die Zeit solcher Aktionen bei bestimmten Produkten zum günstigeren Preismodell um. Solche Überlegungen mögen auf den ersten Blick nach “Ein Dollar mehr ist nicht die Welt” aussehen. Aber wenn man mit Rabattverkäufen Zahlen einiger hundert Käufe anvisiert, dann kann sich eine solche Überlegung schon auszahlen.

Ist der Anbieter gewählt, wird man der Rabatt am Einfachsten mittels eines Coupons gewähren. Der Affiliate (oder man selbst auf der eigenen Website) kann den Coupon wiederum unsichtbar in seine Kauf-Links einbauen. Von einem temporären Umsetzen der Produktpreise rate ich ab. Einerseits aus dem im vorangegangenen Artikel schon erwähnten Geiz-Phänomen (Ich möchte vermeiden, dass Kunden den Rabatt bekommen, die eigentlich von der Aktion gar nichts wussten, sondern einfach zufällig an diesem Tag die Bestellung abschicken). Andererseits können Coupons normalerweise ganz leicht konfiguriert und auch zeitlich eingeschränkt werden, sodass das Zurückstellen der Preise nicht erforderlich ist.

Den Coupon definiere ich mit Gültigkeit ab sofort (damit der Checkout-Prozess getestet werden kann, und mir Überraschungen erspart bleiben) bis 1-2 Tage über den geplanten Termin hinaus. Damit erspare ich mir die Überprüfung, in welcher Zeitzone mein eCommerce-Provider rechnet, und in welcher Zeitzone mein Sale beworben wurde. Denn, einen Coupon schon für ungültig zu erklären, wenn bei uns Mitternacht ist, wäre unschön, wenn nicht fatal, wenn man bedenkt, dass an der Ostküste dann erst früher Abend ist und an der Westküste gerade der Nachmittag anbricht.

Ausserdem habe ich mir angewöhnt, noch einen zweiten Coupon anzulegen, der noch etwa eine Woche länger gültig ist, und den ich aus Kulanz auch nach Ablauf der Aktion noch herausgeben kann. Denn keine Aktion verläuft ohne Nachzügler, die dann mit herzerwärmenden Geschichten auch Tage danach noch um den Rabatt bitten. Klar kann ich hier antworten, wenn das Angebot im lokalen Supermarkte weg ist, dann ist es eben weg, und so funktioniert auch mein Sale. Aber trotzdem können einige Begründungen auch mal plausibel klingen (allen voran technische Probleme beim Kauf, jaja…). Nicht zu vergessen ist auch die Frage, ob die Klientel, die bei Rabattaktionen zuschlägt, dann wirklich auch zum vollen Preis kaufen würde. Also: Etwas tolerant und spendabel sein, zwei zufriedene Kunden sind mehr Wert als ein unzufriedener!

Zu guter Letzt kann man noch überlegen, ob man für die Dauer der Aktion auch noch einen attraktiven Upsell oder Cross Sell anbietet. Mehr darüber folgt hier in Kürze…

Ich war kritsch? Wahrscheinlich habe ich mich einfach nur nicht getraut. Wollte doch jemand das erworbene Produkt zurückgeben, antwortete ich, er hätte doch die Gelegenheit gehabt, sich von der Funktionstüchtigkeit der Testversion zu überzeugen, und ein Widerrufsrecht stünde ihm bei Software, ähnlich wie bei Bananen im Supermarkt, ohnehin nicht zu. Schon wenn ich das heute schreibe, muss ich instinktiv mit dem Kopf schütteln…

Denn was kann überhaupt gegen eine Geld-Zurück-Garantie für das eigene Software-Produkt sprechen?

Der vermeintlich ehrliche Kunde ist gar kein solcher, sondern nur ein Schurke, der sich eine Lizenz erschleichen will.

Das geht natürlich gar nicht! Trotzdem kommt es vor. Jedoch bei weitem nicht so häufig, wie man oft befürchtet. Die Inanspruchnahmen meiner 60-Tage-Garantie in den vergangenen Jahren, bei denen der Kunde nicht auch eine plausible Erklärung mitgeliefert hat, kann ich an einer einzigen Hand abzählen. Die entsprechenden Lizenzschlüssel landen in der Sperrliste und funktionieren bei zukünftigen Updates nicht mehr. Thema erledigt. Energie kann wieder auf Anderes konzentriert werden.

Der Website-Besucher hat sich auf den guten ersten Eindruck der Produkt-Site zu einem Spontankauf hinreissen lassen, stellt aber später fest, dass er die Software doch eigentlich gar nicht benötigt.

Ja, aber was kann uns denn Besseres passieren, als viele Spontankäufer, die die Testversion links liegen lassen? Ich sehe es sogar als Ziel an, die Besucher meiner Produktseiten auf Anhieb so zu beeindrucken (und zu informieren), dass sie das Produkt lieber gleich kaufen. Eine funktionierende Website zeichnet das meiner Meinung nach aus. Es ist auch um ein Vielfaches unwahrscheinlicher, dass der Kunde vom Kauf zurücktritt, als dass er sich – mit oder ohne Download der Trial-Version – gar nicht erst zum Kauf entscheidet. Wenn ich also den Impuls zum Spontankauf mit der Garantie erhöhen kann, dann liebend gerne!

Der Kunde hat technische Probleme mit der Software.

Sieht unser Geschäftsmodell wirklich vor, eine unfertige Software auf den Markt zu werfen, und zu hoffen, dass möglichst viele darauf reinfallen? Na hoffentlich nicht. Klar könnte man das eine oder andere Problem im Dialog noch lösen, aber nicht jeder Kunde kann oder will die Zeit und Geduld dafür aufbringen. Lieber bleibe ich hier mit einer unkomplizierten Rückabwicklung in guter Erinnerung. In vielen Fällen bin ich sogar soweit gegangen, dem Kunden den Kaufbetrag zu erstatten, ihm aber ausdrücklich “zur Entschädigung für die Unannehmlichkeiten” die weitere Nutzung zu gestatten, in der Hoffnung eventuell doch noch die zur Fehlersuche erforderlichen Informationen zu erhalten. Eine kostengünstige Investition in die Produktqualität und gleichzeitig eine Chance, den Kunden doch noch zurückzugewinnen. Wir sprechen von Software – es gibt hier doch praktisch nichts zu verlieren!

Dem Kunden fehlen bestimmte Funktionen, oder ihm “gefällt” die Software auf Dauer einfach nicht.

Umtausch bei Nichtgefallen – wer von uns hat dieses freiwillige Zugeständnis vieler Händler nicht schon genutzt? Hätten wir genauer gemessen, hätten wir schon vorher wissen können, dass der Dübel zu kurz ist. Zum Baumarkt, Ware zurück, Geld wieder in der Tasche. Hätten wir genauer nachgedacht, wäre uns klar gewesen, dass das Geschenk in dieser Farbe oder Größe nicht gut ankommt. Ins Kaufhaus, Ware zurück, Geld wieder in der Tasche. Aber unseren eigenen Kunden gegenüber wollen wir keine Kulanz walten lassen? Die geringen Kosten, die uns eine solche Transaktion kostet ist doch eine Investition in die Kundenzufriedenheit. Zufriedene Kunden empfehlen unsere Produkte weiter. Davon lebt mein Geschäft zu nicht unerheblichem Teil!

Was steht also allen Einwänden entgegen? Vertrauensgewinn – Reduzierung der Hürde zum Spontankauf – Steigerung der Kundenzufriedenheit.

Nach meiner Rechnung zahlt sich das Zugeständnis der Geld-Zurück-Garantie in jedem Fall aus. Und nach meiner Erfahrung übrigens auch…

Rabatte freuen neue Kunden. Aber stoße ich damit nicht all meinen Kunden vor den Kopf, die zum regulären Preis gekauft haben?

Berechtigte Frage. Aber. Lehrt uns nicht die allgemeine Lebenserfahrung, dass es beim Bauhaus heute den gleichen Akkuschrauber im Angebot gibt, den wir gestern bei Obi zum Listenpreis gekauft haben? That’s life. Kommt vor. Wahrscheinlich gibt es sogar so ziemlich alles, was ich diese Woche erstanden habe, nächste Woche irgendwo günstiger. Nur, in der Regel bekomme ich davon gar nichts mit! Veranstaltet man einen Sale auf einer Discount-Website, so wird der bestehende Kundenstamm davon wahrscheinlich so gut wie nichts erfahren (wenn doch, dann hast Du *wirklich* gute PR gemacht).

Anders sieht es aus, wenn man beabsichtigt, die Bestandskunden über die bevorstehende Aktion zu informieren. Und dazu rate ich unbedingt. Denn eine (PR-)Lawine kann nur ins Rollen kommen, wenn man sie lostritt.

Tatsächlich kontaktieren mich bei jeder Rabattaktion einige verärgerte Nutzer, die meist erst wenige Tage vor Ankündigung einer Rabattaktion gekauft haben (nicht alle sind wirklich verärgert – einige sind tatsächlich im Stande freundlich anzufragen ob sie den Rabatt auch im Nachhinein noch erhalten können). Meinen teuer erstandenen Akkubohrer kann ich beispielsweise zu Obi zurücktragen, und mir mein Geld zurückgeben lassen. Und gleich beim Bauhaus den gleichen wieder kaufen. Ist aber mit etwas Aufwand verbunden.

Trotzdem hat das vielleicht auch unser Softwarekunde schon gemacht und so verweise ich ihn höflich auf unsere 60-tägige bedingungslose Geld-zurück-Garantie. Bei meiner letzten Aktion haben vielleicht ein Duzend Kunden angefragt und diese Antwort erhalten. Knapp die Hälfte hat dann die Erstattung in Anspruch genommen und zum Rabattpreis neu gekauft. Im Beispiel geht ja der Obi letztlich leer aus, in diesem Fall hat sich lediglich mein Gewinn für eine Hand voll Käufe reduziert – dafür sind die Kunden zufrieden gestellt worden!

Dennoch bin ich mittlerweile dazu übergegangen, Kunden, die erst vor bis zu etwa einer Woche gekauft haben beim Mailing zunächst auszusparen. Weil, verschenken muss man ja auch nichts.

In meinem nächsten Beitrag gehe ich darauf ein, was es bei Wahl und Konfiguration des eCommerce-Providers zu beachten gilt.

In den nächsten Artikeln möchte ich etwas Bericht erstatten, welche nach meiner Meinung die Faktoren sind, um Rabattaktionen erfolgreich zu machen:

Mein 1×1 für erfolgreiche 24h-Sales.

Zunächst möchte ich nochmals auf meinen vorangegangenen Artikel verweisen, der die Fragen Warum überhaupt eine Rabattaktion durchführen? und Warum gerade 24 Stunden? abhandelt. Danach wollen wir uns mit Hochprozentigem beschäftigen:

Prozente, Prozente – aber wie viele?

Kurzzeitige Rabatte leben davon, dass diese wirklich substanziell sind. Gerade habe ich erst wieder eine Aktion einer US-Softwareschmide in der Inbox gehabt, dort wurde zum Anlass des Firmengeburtstags ein Produkt für $74.95 statt $79.95 angeboten. Auf den ersten Blick habe ich da gar nicht gesehen, dass überhaupt etwas vom Grundpreis abgezogen war! Lächerlich – das war mein erster Gedanke, und der bleibt für’s Image dieses Ladens jetzt bei mir eingeprägt.

Nach meiner Ansicht liegt der ideale Rabatt für diese Art von Promotion bei 50%. Alles unterhalb von 30% halte ich für lachhaft. Alles oberhalb von 50% halte ich wiederum für ohne Not verschenkten Profit. Fünfzig Prozent, das heisst “Halber Preis”, das ist einfach zu verstehen und gut zu erfassen. Und spätestens beim halben Preis schalten bei mir alle Ampeln auf “kaufen”.

Bei meiner letzten Aktion habe ich mich dennoch breitschlagen lassen, mal einen geringeren Preispunkt auszuprobieren. $27.95 lautete der Vorschlag. Angeblich hätte man bei BitsDuJour die Erfahrung gemacht, dass die höhere Nachfrage bei geringerem Preis sich praktisch immer auszahle. Erst bei Preisen unter $10-$15 wird es aufgrund der meist fixen Processing-Gebühren unwirtschaftlich.

Das Experiment habe ich gerne mitgemacht, obwohl ich früher stets davor scheute, Sonderpreise unterhalb meines regulären Upgrade-Preises anzubieten. Für viele Kunden könnte das ein Signal sein, dass es sich nicht lohnt Upgrades zum normalen Preis zu kaufen, sondern günstiger ist, auf die nächste Preisaktion zu warten, und dann einfach eine neue Lizenz zu erwerben. Naja, diesmal habe ich meine Zweifel in den Wind geschossen.

Leider kann ich vom Ergebnis her keinen echten Vergleich zwischen meinen letzten Preispunkten $27.95 (60% Rabatt) und $34.95 (50% Rabatt) ziehen. Einfach zu viele weitere Parameter waren hier unterschiedlich. Nach meinem Bauchgefühl liest sich der $27.95 Preis sehr gut, und dürfte mehr Impulskäufe provozieren als der höhere Preis. Andererseits hat das Ergebnis meiner letzten Aktion die vorangegangene nicht so deutlich übertroffen, als dass ich den Verlust von immerhin $7 Differenz pro Verkauf wieder hereingeholt sehe. Ich denke, ich bleibe bei meiner “50% is enough”-Regel.

Anders mag dies bei Produkten jenseits der $100-Grenze sein. So glaube ich kaum, dass Preise über $100 noch Impulskäufe auslösen können, zumindest nicht bei der BitsDuJour-Klientel. Auf der anderen Seite sieht ein 75% Rabatt bei einem $399 Produkt schon sexy aus. $300 gespart! Dafür bekäme man ganze 46,15 kg Kitekat Jagdschmaus mit Soße!

Ach übrigens: Tatsächlich konfiguriere ich meine 24h-Sale-Rabatte nie auf prozentuelle Werte. Eigentlich ist es zwar unwahrscheinlich, dass Großkunden sich mit solchen Rabattangeboten abgeben. Trotzdem möchte ich vermeiden, dass eine Firma, die eventuell Wochen gebraucht hat um sich für den Kauf einer stattlichen Zahl von Lizenzen durchzuringen, dann an just dem Tag bestellt, an dem alles nur die Hälfte kostet. Meine 24h-Sales gelten also stets nur für die Einzellizenz. Beim Grundpreis von $69.95 erstelle ich einen Coupon über $35, der automatisch an den Warenkorb übertragen wird und so entsteht der Endpreis von $34.95. Möchte jemand mehrere Lizenzen zum Sonderpreis kaufen, kann er das gerne tun, muss aber eben jede Lizenz einzeln erwerben.

In meinem nächsten Beitrag soll es darum gehen, wie man trotz Rabatt seine bestehenden Kunden nicht enttäuscht.

Wovon spreche ich? Von Kunden-Emails.
Wenn man am Beginn seiner Karriere steht, so freut man sich wie wahnsinnig über die ersten verstreuten Emails, die ihren Weg in den Posteingang finden. Wenn aber über die Zeit diese Emails immer mehr werden, so sollte man darüber nachdenken, wie man am besten mit den Emails umgeht.

Es gibt verschiedene Kategorien von Kunden-Emails:

1. Fragen vor dem Kauf
2. Fragen nach dem Kauf
3. Fehlerbeschreibungen
4. Positive Emails
5. Beschwerde-Emails

Fragen vor dem Kauf

Diese Emails sind sehr wichtig, da der Kunde schon seinen Weg auf die Produktseite gefunden hat und das Thema sein Interesse geweckt hat. Will er nur herausfinden, dass es tatsächlich Dich als Firma gibt und er nicht sein Geld in ein schwarzes Loch wirft? Dann gut. Schreibe eine nette Antwort und versichere dem Kunden, dass Du ein richtiger Mensch bist, der sich um ihn kümmern wird.
Hat der Kunde eine Frage zu einer Funktion oder vermisst er eine Funktion?
Hier sollte man überlegen, ob man immer wieder die gleiche Antwort als Email schreiben muss. Spätestens dann sollte man diese Frage auf der Homepage beantworten.

Fragen nach dem Kauf

Nach dem Kauf wird der Kunde langsam sich intensiv mit der Software vertraut machen. Hier bietet sich ein ungeheures Potenzial an Ideen und Rückmeldung. Lese die Anfragen gut durch. Hat ein Kunde eine gute Idee, so sollte diese Idee in eine Art von “Wunschliste” aufgeführt werden. Am besten mit dem Datum und dem Kontakt. Der Kunde wird sich über eine Nachricht freuen, wenn seine Idee in einem Produkt umgesetzt wurde.

Fehlerbeschreibungen

Es gibt leider keine Software ohne Fehler. Es ist wissenschaftlich bewiesen, dass ab einer gewissen Zeilenanzahl dies nicht möglich ist. Aber wir können unsere Software stetig verbessern. Hier ist aber auch erstmal zu erfragen, ob dieser Fehler immer vorkommt oder nur gerade deswegen, weil gerade irgendetwas Außergewönliches passiert ist. Korrigiere – wenn möglich – schnell die Fehler und stelle eine verbesserte Version zur Verfügung. Meldet ein Kunde einen Fehler, so wird dieser Fehler auch bei anderen Kunden vorkommen.

Positive Emails

Solche Emails liest man natürlich am liebsten! Keine Frage. Doch neben dem Bedanken stellt sich hier gleich die Möglichkeit, um Erlaubnis zu bitten, diese Kundenstimme auf seiner Homepage zu präsentieren. Es gibt kaum etwas besseres als Rezensionen von anderen Kunden.

Beschwerde-Emails

Auch solche Mails gibt es. Versuche immer, nett und freundlich zu bleiben, auch wenn dies manchmal schwer fällt. Gehe auf den Kunden ein. Vielleicht kann ein Problem ja doch noch gelöst werden. Solche Kunden schwenken dann oft auf die “Fan”-Seite um. Kann ein Problem nicht gelöst werden, so gebe dem Kunden sein Geld wieder zurück. Er wird sich freuen und sein Vertrauen wird beim nächsten Kauf größer sein. Denke daran, dass gerade ein unzufriedener Kunde auch Freunde und Bekannte hat.

Wie und wann beantworte ich Emails?

Nun, viele sagen: “Beginn Deinen Tag nicht mit Emails beantworten”. Andere sagen: “Antworte frühestens nach 12 Stunden auf eine Email”.

Ich versetze mich gerne in die Lage des Kunden und versuche, zweimal am Tag alle Emails zu beantworten. Das ist nicht immer zu schaffen, aber meistens. Ein leerer Posteingang vermittelt ein gutes Gefühl.
Beim Beantworten von Emails muss man häufig immer wieder die gleichen Fragen beantworten. Daher bieten sich Textbausteine an. Ich selber verwende das Programm DirectAccess von Nagarsoft. Damit erspare ich mir jede Menge Tipperei und Zeit.

Nun möchte ich dem ASP.Net bzw. IIS Nutzer die richtigen Schritte zeigen, um den IIS 7.0 zu optimieren und gleichzeitig Google glücklich zu machen. (Eine kleine Bemerkung darf mir noch erlaubt sein. Wie kann man etliche Mannjahre auf der Welt beeinflussen? Nun ja: Google gibt irgendeine Zahl heraus, die man verbessern kann und schon versuchen Millionen von Webmastern eine möglichst gute Zahl zu erreichen.)

Aber nun kommen wir erstmal zur Optimierung der Compression:

1. Starte den IIS 7.0 Manager.
2. Wenn man alle vorhandenen Websites auf einmal konfigurieren möchte, dann wählt man den Server aus und klickt auf ‘Compression‘:
   
3. Der Dialog ist recht übersichtlich gestaltet:
   

   Hier wählt man die Option ‘Enable static content compression‘ an und nimmt am besten noch den Haken raus bei ‘Only compress files larger than (in bytes)’

4. Das war schon alles, um die Compression einzustellen

Nun widmen wir uns dem Browser-Cashing im IIS 7.0 zu:

1. Starte den IIS 7.0 Manager.
2. Möchte man wieder die Einstellungen für alle Web-Seiten auf einmal einstellen, dann wählt man den Server-Knoten aus und klickt dann auf den Eintrag ‘Output Caching‘.
   
3. Man kann das Caching-Verhalten von verschiedenen Datei-Endungen unterschiedlich behandeln. Deshalb wird zunächst eine Übersicht über alle vorhandenen Caching-Einträge angezeigt:
   
4. Nun klicke rechts auf ‘Add‘ um eine neue Regel hinzuzufügen.
5. Das Fenster für die neue Regel sieht so aus:
   

   In das erste Textfeld gibt man die Datei-Erweiterung an, für die diese Regel gelten soll.

6. Um das Caching zu aktivieren, muss der Haken bei ‘User-mode’ caching (alternativ geht auch ‘Kernel-mode caching’) gesetzt werden
7. Dann gibt man noch den Zeitintervall ein, wie lange der Browser-Client nicht nach einer neuen Version schauen soll.
   Entweder man gibt ‘Using file change notifications’ an. Dann wird die Datei solange gecacht, bis diese Datei aktualisiert wurde.
   Oder aber man gibt ein festes Zeitintervall ein. (z. B. 23:59:59 für einen Tag)
8. Das war’s auch schon bei dem Cashing.

Mit diesen Einstellungen wird das Browsen über eine Web-Seite auch mit einer langsamen Internetverbindung wieder zum Vergnügen. Ich wundere mich, dass ich solange nichts davon wußte.
Dabei geht’s so einfach.

Heute: Browser Caching

Als weiteren wichtigen Punkt erachten die Experten der Google-Labore den sinnvollen Einsatz des Browser-Caches. Webbrowser können geladene Inhalte zwischenspeichern, und müssen so die gleiche Ressource nicht mehrfach abrufen, falls sie öfter innerhalb einer Website (z.B. auf mehreren Seiten) gebraucht wird. Ebenfalls müssen zwischengespeicherte Grafiken, dann nicht erneut aufgerufen werden, wenn die gleiche Website nach einigen Tagen wieder besucht wird. Dazu benötigt der Browser aber die Information, welche Daten er wie lange zwischenspeichern darf. Denn am Webserver dynamisch erzeuge Inhalte beispielsweise können zwar stets den gleichen Namen und die gleiche Größe haben, ihr Inhalt kann trotzdem variieren. Weisen wir also die Browser unserer Besucher an, bestimmte statische Daten zu cachen, entlastet das unsere Webserver und führt gleichzeitig zu einer schnelleren Ladezeit bei wiederholten Besuchen oder beim Besuch mehrerer Seiten. Die Page Speed Analyse gibt uns wieder einige Tipps:

Sinn macht das Zwischenspeichern vor allem für Inhalte, die sich selten ändern, vor allem also für Grafiken. Auch CSS-Dateien und Javascripts kommen in Frage. Hier ist aber zu bedenken, dass bei häufigen Änderungen der Styles oder Skripte, diese Änderungen beim Besucher erst nach Ablauf der Cache-Zeit oder bei einem kompletten Refresh der Website sichtbar werden. In der Entwicklungsphase einer Site kann das hinderlich sein. Gleiches gilt für das Ändern von Grafiken.

Ich habe mich daher für ein eher defensives Caching entschieden – das aber immer noch besser ist als gar keines. Hier wieder der Code für die Apache 2 .htaccess-Datei:

ExpiresActive on
ExpiresByType image/png "access plus 1 day"
ExpiresByType image/gif "access plus 1 day"
ExpiresByType image/jpeg "access plus 1 day"
ExpiresByType text/css "access plus 1 day"
ExpiresByType text/javascript "access plus 1 day"
ExpiresByType application/javascript "access plus 1 day"
ExpiresByType application/x-javascript "access plus 1 day"

AddType image/vnd.microsoft.icon .ico
ExpiresByType image/vnd.microsoft.icon "access plus 1 day"

Wir definieren für alle Grafiken, CSS und JS-Dateien eine Lebensdauer von einem Tag. Außerdem definieren wir für Icon-Dateien eine solche Lebensdauer, damit auch die favicon.ico-Datei nicht unnötig häufig geladen wird.

Natürlich kann mit längeren Caching-Zyklen noch viel mehr erreicht werden, hier ist Experimentieren erlaubt.

Diese Konfiguration, wie auch die Konfiguration der HTTP Komprimierung, kann natürlich auch Host-weit in der hosts.conf vorgenommen werden.

Auch diese Konfiguration benötigt im Apache die Aktivierung eines zusätzlichen Moduls, nämlich mod_expires. Dies funktioniert wie im letzten Artikel, auf Debian Unix z.B. einfach durch das Anlegen eines Symlinks (Apache Neustart danach nicht vergessen):

cd /etc/apache2/mods-enabled
ln -s /etc/apache2/mods-available/expires.load
/etc/init.d/apache2 restart

Soviel für heute, im nächsten Teil werfen wir einen Blick auf die wichtigsten HTML-Optimierungen.

Einige Seiten sind natürlich so inhaltsüberfrachtet, da fällt die Ursache gleich ins Auge. Andererseits gibt es auch umfangreiche Websites, die trotzdem schnell laden. Oft mag hier veraltete oder durch Shared Hosting überanspruchte Hardware die Ursache sein, die am anderen Ende der Welt vielleicht gar über eine selbstgespannte Leitung ans Internet angeschlossen ist. Trifft dies jedoch nicht zu, so kann der langsame Seitenaufbau aber auch an der eigenen Webserver-Konfiguration, am Aufbau der Website oder an Mängeln am HTML liegen. Ursachen, denen teilweise mit einfachsten Mitteln auf den Leib gerückt werden kann. Optimieren ist angesagt.

Aber warum überhaupt die Ladezeit der eigenen Website optimieren? Neben dem Nervenkostüm des Besuchers (und wohl potentiellen Kunden), kann die Trägheit beim Seitenaufruf mittlerweile auch die Positionierung in Suchmaschinen strapazieren. Beispielsweise rechnet Google seit geraumer Zeit auch die Aufrufzeiten in sein Qualitäts-Ranking mit ein. Somit wird Optimieren ein Muss.

Nun weiss der geneigte Leser, dass – wo und was auch immer optimiert wird – es hier stets um ein Verbessern hin zum Idealwert geht, das Ideal selbst aber stets unerreichbar bleibt. Ein “Fertig!” gibt es nicht. Je näher man dem Idealwert kommt, umso aufwändiger werden auch die Maßnahmen. Hier droht also stets die Gefahr, dass Aufwand und Ertrag sich nicht mehr gegeneinander aufrechnen. Also ist Augenmaß gefragt, wann es der Optimierung genug ist. Trotzdem gibt es oft sehr einfache Ansatzpunkte, bei denen mit wenig Aufwand viel erreicht werden kann. Auf einige dieser Punkte möchte ich mich konzentrieren.

Einen guten Einstieg bietet das von Google bereitgestellte Page Speed Tool. Es besteht aus einem Firefox-AddIn, das sich in das Analyse-Tool Firebug einhängt. Nach der Installation des Page Speed AddIns ruft man einfach die eigene Website in Firefox auf und klappt mit einem Klick auf den kleinen Käfer rechts unten das FireBug-Fenster auf. Firebug enthält nun zwei weitere Menüpunkte “Page Speed” und “Page Speed Activity”. Ein Klick auf “Analyze Performance” unter “Page Speed” erstellt eine erste, leicht verständliche Übersicht über die drängendsten Performance-Probleme der Website.

Das Tool berechnet zunächst einen Score für die aufgerufene Website, der einen Vergleich mit anderen Seiten ermöglicht. Mein Tipp: Die Seiten der wichtigsten Mitbewerber aufrufen, und prüfen, wo man sich selbst mit diesem Score einreiht.

Der Page Speed Test listet nun eine Reihe von Best Practices auf, Empfehlungen zur Optimierung der Ladezeit. Das Tool zeigt diese Best Practices gleichzeitig gewichtet nach deren Wirksamkeit an und gibt beim Aufklappen der einzelnen Punkte weitere hilfreiche Informationen, bspw. welche Dateien in welchem Maße betroffen sind, oder optimiert werden können.

Wer die Best Practices wirklich von A bis Z durchackert, hat sich damit sicher eine Menge Fleißbildchen verdient, aber konzentrieren sollte man sich dennoch auf die wichtigsten Punkte, also allen voran die mit dem roten Ausrufezeichen gekennzeichneten. Auf genau diese Maßnahmen möchte ich in einer Reihe von Posts kurz eingehen.

Heute also: Enable Compression

Praktisch alle modernen Browser unterstützen die HTTP Komprimierung mittels gzip oder deflate - Kodierung. Dabei sendet der Browser mit seiner Anfrage einen Header wie z.B. Accept-Encoding: gzip,deflate und somit weiß der Webserver, dass er an diesen Client gerne komprimierte Daten senden kann. Anstatt eine HTML-Seite nun im Rohformat zu senden, komprimiert er diese mit gzip oder deflate (zweiteres ist ein weniger verbreitetes Komprimierungsformat, empfohlen wird gzip) und senden den komprimierten Stream zurück, wobei er im Header wiederum angibt, mit welchem Algorithmus komprimiert wurde (z.B. Content-Encoding: gzip). Diese Funktion ist in den gängigen Webservern integriert bzw. über Zusatzmodule verfügbar, muss in der Regel aber explizit aktiviert werden.

Für Apache 2 Webserver funktioniert die Aktivierung beispielsweise durch die folgenden Einträge in der .htaccess-Datei:

AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript application/x-javascript
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
Header append Vary User-Agent env=!dont-vary

In der ersten Zeile erklären wir, dass für alle HTML, Text, CSS und Javascript-Dateien die Komprimierung zu nutzen ist. Denn: Bilddateien oder EXE-Downloads möchten wir in keinem Fall komprimieren – die erneute Komprimierung bereits reduzierter JPEG oder PNG-Grafiken, sowie bereits gepackter Software-Installationen, würde in keinem weiteren Größengewinn resultieren, und wäre somit kontraproduktiv.

In den drei folgenden Zeilen behandeln wir einige Ausnahmen von Browsertypen, die die Komprimierung nicht oder fehlerhaft unterstützen.

In der letzten Zeile kümmern wir uns noch darum, dass auch Proxy-Server die komprimierten Datenströme nur an Clients weitergeben, die diese auch angefordert haben.

Näheres erklärt auch die Apache Dokumentation für das Deflate-Modul.

Zu beachten ist, dass o.g. Konfiguration die Apache-Module mod_deflate und mod_headers benötigt. Diese müssen i.d.R. nicht extra installiert, aber im Apache aktiviert werden. Wie dies funktioniert hängt stark von der verwendeten Plattform ab, auf Debian Unix erfolgt die Aktivierung z.B. einfach durch das Anlegen einiger Symlinks (Apache Neustart danach nicht vergessen):

cd /etc/apache2/mods-enabled
ln -s /etc/apache2/mods-available/deflate.load
ln -s /etc/apache2/mods-available/headers.load
/etc/init.d/apache2 restart

Somit ist mit einer einfachen Konfiguration bereits ein erster Performance-Boost erreicht. Sicher erfordert die Komprimierung nun etwas mehr Rechen-Ressourcen auf dem Webserver. Aber wenn der Server dem nicht standhält, wäre ohnehin ein Upgrade überfällig. Im nächsten Teil sehen wir uns das Browser Caching an.