Lange habe ich nichts mehr geschrieben – es gab einfach andere Prioritäten (Familie / Beruf). Ich hoffe, dass ich jetzt in der Sommerzeit wieder einmal Muße und Zeit finde den ein oder anderer Blogeintrag zu erstellen.
Neues von mir als Gastautor findet sich hier:
http://t3n.de/news/e-commerce-speed-sells-webshop-performance-275306/
Gestern war es mal wieder soweit. Gleich zwei Seiten – in der Presse (Heise / Spiegel) genannt – waren nicht erreichbar.
Betroffen waren: Jako (gleich mit mehreren Domains) und der Bundeswettbewerb Informatik.
In der Heise Community ist dieses Phänomen schon länger bekannt und wurde “Geheist” getauft. Selbst einen Eintrag in Wikipedia gibt es zu dieser Wortschöpfung.
Sicher ist, sobald eine Webseite von den Medien genannt wird (im Guten wie im Schlechten), wird der Anbieter mit deutlich erhöhtem Traffic rechnen müssen.
Zwei Gründe führen in der Regel (es gibt deutlich mehr, aber die genannten sind die häufigsten) dazu, dass die Server in die Knie gehen:
Jako war gestern sicher härter getroffen, da zum Zeitpunkt des “Überlaufs” (rien ne va plus) über die Webseite keine Bestellungen getätigt werden konnten (lost revenue) oder schlichtweg keine Angebote anzeigen lassen konnten (risked revenue).
Wie das von außen betrachtet aussieht zeigt der folgende Chart. Eine Stunde nach der Veröffentlichung des Artikels habe ich die Webseite gemessen: Ergebnis: Über Stunden Ausfall des Servers – bis man vermutlich um 0:00Uhr einmal rebootet hat. Selbst heute noch steht das Angebot auf wackeligen Beinen.
Wie kann man sich nun aber als Webseiten-Anbieter vor solchen Problemen schützen?
Eine 100% Sicherheit kann natürlich nichts versprechen – aber ein dediziertes Monitoring könnte verwendet werden, um z. B. bei einer gewissen Anzahl von “gleichzeitigen Sessions” oder bei einer gewissen Bandbreitenauslastung Alarm zu schlagen.
Sicher denken jetzt viele: Ah, das haben wir auch – und trotzdem passiert es.
Vermutlich wurde in einem solchen Fall nicht darüber nachgedacht, was nach einem solchen Alarm passieren soll. In den meisten Fällen die ich kenne, gab es keine definierten Prozesse was denn nun im Alarmfall zu tun sei:
Seitengrößenminimierung, Ersatzseite, Umleitung, dynamische Rechenkapazitätserweiterung etc. etc.?
In vielen Fällen wird häufig gedacht: Ich stelle mir zwei Server hin, die ich im Fall des Falles dazuschalte. Meiner Meinung nach ist das herausgeschmissenes Geld: 2 Server für vielleicht 2 Stunden im Jahr ? (Wartung, Update, Aktualisierung, Test, Hardware)
Hand aufs Herz: Wer hat schon einmal mit einer dynamischen Kapazitätserweiterung (Bandbreite/Rechenleistung) auseinandergesetzt ? Wer hat schon einmal über einen Last-Test seine Kapazitätsgrenzen ermittelt ? Wer hat ein Szenario entwickelt, welches Last-Alarme sinnvoll macht (Prozess) ? Wer hat diesen Prozess schon einmal real durchgespielt ?
Wenn jemand diese 5 Fragen mit “ich” beantworten kann, dann ist er wirklich gut und das Risiko geheist und gespiegelt zu werden ist minimiert!
Wie ich bereits im Teil Zwei der Serie “Der neue Bundestag Internetauftritt” bemerkte, ist die Ladezeit für User mit mäßiger Internetanbindung äußerst lang. Als Grund nannte ich unter Anderem das außergewöhnlich hohe Seitengewicht (in kb).
Ich wurde unterdessen von einem Freund gefragt, was ich denn in solch einem Fall tun würde. Und meine erste Idee war: Überprüfen, ob die Grafiken optimiert werden können.
Das einfachste Mittel für eine solche Schnellüberprüfung lieferte mir das Browserplugin “YSlow”, welches für jeden Webseitenentwickler heutzutage ein “MUSS” sein sollte. Integriert in YSlow befindet sich ein Service der sich “Smush.it” nennt und Grafiken auf Optimierbarkeit OHNE Qualitätsverlust überprüft.
Genau diese Überprüfung habe ich mit der Webseite (www.bundestag.de) einmal durchgeführt.
Siehe da: Über 500 Kb lassen sich so einfachst optimieren.
Den Bildern sieht man keinen Qualtätsverlust an – der User wird es allerdings an der deutlich verbesserten Ladezeit dennoch bemerken.
49% an Daten gespart ! in Downloadzeit für einen Modem-User bedeutet das eine maximale Beschleunigung der Ladezeit von ca. 68 Sekunden.
Komprimiert man nun noch Javascript (derzeit 275 kb) und CSS Dateien (derzeit 147 kb), dann könnte die Webseite rasch nur noch halb so groß sein wie bisher und faktisch doppelt so schnell laden wie derzeit.
Ich wiederhole deshalb die alte Leier gerne:
Insgesamt also Unsummen an Geldern (Steuerzahler ?) sparen.
Die Energieleistung, die für das Hosting der Datenmenge, den Transport der Datenmenge und den Abruf der Datenmenge verwendet wird könnte ohne weiteres eine 100Watt Glühlampe (zwinker zwinker) für eine längere Zeit zum Glühen bringen.
Spiegel online in einem neuen Gewand und doch bei der Technik alles beim alten.
Wie schon vor dem Relaunch hat es der Spiegel-Online nicht so mit “Green IT” oder auch ressourcensparendes Agieren – eine Anfrage an die Marketingabteilung des Spiegels blieb leider damals (vor c.a.2 Monaten) unbeantwortet.
Nun wurde der Spiegel neu gelauncht und ich hoffte, dass sich nun etwas ändert.
Fehlanzeige.
Deutschland meistbesuchte Nachrichtenseite (Besucher insgesamt) missachtet durch zwei einfache Konfigurationsmaßnahmen die Regeln des “Grünen” IT-Betriebs – was zudem die Transportwege (Datenautobahnen) verstopft und die User frustriert (lange Ladezeiten).
Man sollte doch annehmen, dass die Jungs und Mädels vom Spiegel das drauf hätten oder ?
Meine Haupt-Kritikpunkte:
Das viele andere Dinge (Bilder, Videos) nicht im Cache landen können oder sollen, könnte und kann ich noch nachvollziehen, aber gerade CSS und Javascript Dateien ändern sich selten und sollten im Cache des Browsers um beim weiteren Browsen durch die Seite NICHT nochmal vom Server angefragt werden zu müssen.
Ein einfacher Blick mit der Firefox Extension Firebug beweist meine Behauptung – Dabei habe ich die Seite genau einmal geladen und danach den refresh Knopf gedrückt:
Cache Einstellung = sofort (mit dem Laden) abgelaufen - Seite wurde um exakt die im Expires Header angegebene Zeit geladen - Wäre die Datei aus dem Cache geladen, wäre der HTTP Response eine 304 (anstelle der 200); Kompression verwendet? Nein
Eine Kalkulation macht das (für mein Verständnis) dramatische Ausmaß verständlich.
Die drei Skripte zusammen ergeben: 188 kb an Daten, die bei JEDEM Aufruf eines Users geladen werden.
Laut IVW (Veröffentlichte Zahlen) waren das im Juli 672.822.499 Seitenaufrufe.
Nun mal gerechnet:
672822499 User*188kb = 126.490.629.812 Kb
126490629812 kb = 123526005,68 MB = 123526 GB = 124 Terabyte
124 Terabyte nur Javascript und CSS ! Wow. Pro Monat !
Content-Kompression durch Gzip oder mod_deflate könnten bis zu 80 % davon einsparen !
Eingesetztes effektives Caching würde bedeuten, dass das Javascript per Visit (Unique User der weitere Seiten anklickt) nur einmal geladen wird.
Caching könnte also schon mal eine Menge Datenfluss minimieren:
Bei den aktuellen Zahlen 672822499 PI / 113005581 Visits kommen wir auf ca. 6 Klicks pro User (= 6 mal laden von Javascript und CSS)
Würden jeweils JS und CSS Dateien nur einmal geladen (und dann aus dem Cache gezogen) werden wären es gesamt nur: 124 TB / 6 = 20, 7 TB Monatlich (“nur” hahaha…)
Angenommen, nun würde noch für die Dateien vom Typ CSS und JS die Kompression mit Gzip oder mod_deflate aktiviert könnten von der Datenmenge im günstigsten Fall nochmal 80% abgezogen werden = Bleibt eine fast schon lächerlich geringe Datenmenge von irgendwas zwischen 4 und 5 Terabyte pro Monat.
Drei Fliegen ließen sich so mit einer Klappe schlagen:
Vielleicht ließt ja ein Spiegelredakteur diesen Blog und wundert sich, dass zwei der einfachsten Regeln des Performance Managements nicht beachtet wurden !!
Ich vermute, dass eine Argumentation von Seiten des Spiegels schwer fallen wird. Wo sie sich selber doch so sehr für Green IT engagieren: http://www.spiegel.de/netzwelt/tech/0,1518,539506,00.html
Stille ! So könnte man die Performance des neuen Bundestages für all diejenigen bezeichen, die in Deutschland mit einer Internetanbindung von unter 256 kbit/s leben müssen (privilegiert sind z. B. in Bayern in etwa 25% aller Haushalte – sprich 75% aller Haushalte müssen – oder wollen – mit einer Bandbreite von unter 256kbit/s Leben. Quelle: http://breitband.bayern.de).
Es ist kein Wunder, dass sich die Ladezeit so extrem hinzieht. Einen Grund dafür habe ich bereits im ersten Teil genannt: Die extreme Menge an Daten. Mit derzeit immer noch über ca. 1150 KB ist die Webseite ein wahrer Bandbreitenkiller. Und liegt damit deutlich über dem durchschnittlichen Seitengewicht (kb) aller von Gomez gemessenen Webseiten (ca. 750 kb).
Rein rechnerisch (ohne internettypische Latenzzeiten) benötigt ein Modem Benutzer (11% aller Deutschen Internetanschlüsse) geschlagene 144 Sekunden. Rechnet man hier noch die Latenzzeit für die jeweilige Verbindungserstellung und die möglicherweise dauernde Serverantwort hinzu, dann sind die User ingesamt schnell mit über 3 Minuten Wartezeit dabei.
3 Minuten – das muss man sich mal auf der Zunge zergehen lassen !
Der privilegierte Internetuser, mit mehr als 512 kbit/s, wartet immerhin insgesamt 10 Sekunden (durchschnittlich) bis die Webseite geladen ist. Ca. die Hälfte dieser Zeit starrt er auf einen Bildschirm bei dem sich, außer in der Statusleiste, nichts tut (weil ja erst Unmengen an Javascript geladen werden müssen).
Die ersten 3 Messtage zeigt sich folgendes Performancebild:
Die Messungen von echten Desktop-PCs zeigen: Modem-Nutzer bekommen kaum die Webseite innerhalb von 120 Sekunden angezeigt. Die wenigen erfolgreichen Messungen ergeben sich daher, dass die Messungen mit höherer Bandbreite begonnen wurden und mit niedrigerer Bandbreite beendet wurden (Reklassifizierung der Messagenten zu Dial Up Usern).
Wie sich die Anordnung der Javascripte beim Laden in einem Browser darstellen zeigt die folgende Grafik. Während CSS und Javascripte geladen werden passiert im Browser gar nichts (außer in der Statusleiste)
Es vergehen in diesem Fall immerhin 6,5 Sekunden bis das erste Bildchen zu sehen ist. Davor passiert das, was Steve Souders als white screen Symptom bezeichnet
300.000 € hat das neue Gewand des Bundestages den Steuerzahler gekostet. Und – soviel sei schon mal versprochen – es wird noch viel teurer. Darf ich als Steuerzahler mehr erwarten was die Repräsentation unserer Legislativen angeht ?
Über das Design und die Funktionalität möchte ich mich (jetzt) gar nicht auslassen, aber die Webseite kommt daher als 1,25 Megabyte schwerer Dinosaurier, der so ziemlich jeden User, der keine 1A Internetanbindung hat (und das sind verdammt viele) zum verzweifeln bringen wird.
Wie schon das Internet Politbarometer zeigt, interessiert sich die Politik (dort die einzelnen Parteien) kaum für den User. Der neue Internet-Auftritt beweist zudem, wie mit Ressourcen herumgeschleudert wird.
Umweltschutz ? Fehlanzeige.
0,5 MB Skript/CSS unkomprimiert ! WOW
Durch Kompression, könnte extrem viel Serverpower gespart werden, der User müsste nicht so lange sein Modem laufen lassen etc.. Das Kostet Geld und wird die benötigte Bandbreite der Server nur belasten.
Qualitativ lässt die Umsetzung des Designs deutliche Wünsche offen. Das Design nicht sauber X-Browser-Kompatibel umgesetzt. Da wird wohl nochmal nachgebessert werden müssen.
Beim Opera bricht die Suche aus der Navigation aus, Das Große Plenarsaalbild hat eine unschöne Ecke unten. (Klicken zur Detailansicht)
Windows Mobile User haben extrem viel Spaß:
Wo bin ich ?
Mit einem aktuellen Safari-Browser wurde vermutlich auch nicht geschaut, ansonsten würden solche “Lücken” im Design nicht entstehen.
Geballte Internet-Kompetenz ?
Wenn der Auftritt repräsentativ sein soll, dann muss wohl nochmal nachgebessert werden. Vermutlich war eine X-Browser-Kompatiblität nicht Bestandteil des Projekts und muss nachberechnet werden.
Wer hat das Projekt abgenommen und geprüft ? Oder wurde es “durchgewinkt” wie eines der vielen kontrovers diskutierten Internetthemen ? Fragen über Fragen.
Kopfschüttelnd nehme ich das zur Kenntnis und Frage mich, was Babiel als Agentur sich da für eine Referenz geschaffen hat.
In Teil 2 werde ich mich die Tage mit der Performance beschäftigen….das wird auch nochmal spannend.
In der Presse wird gerade über die Performance von Twitter berichtet.
Ursache dafür ist wohl ein massiver Trafficzuwachs durch Spam-Mails provoziert – und nicht wie gestern noch angenommen eine Hackattacke.
Betrachtet man nun die Ladezeit von Twitter über einen längeren Zeitraum, stellt man deutlich fest, dass Twitters Performance sich deutlich verbessert hat und selbst der Hackangriff die Startseiten Ladezeit nur minimal beeinflusst hat. Der Server war für wenige Stunden nicht erreichbar, aber wenn er da war war er schneller als vergleichsweise 1 1/2 Wochen zuvor.
Twitters Ladezeit über die letzten 14 Tage. Seit einer Woche ist die Ladezeit rasend schnell im Vergleich zu vorher.
Aus der Sicht der Verfügbarkeit wird das Problem dann schon eher deutlich:
Deutlich zu sehen, trotz extrem schlechter Ladezeiten war die Verfügbarkeit von 2 Wochen deutlich besser als die letzten 24 Stunden
Gemessen wurde pro Stunde 1 x aus den folgenden Backbone Netzwerken:
CA: Santa Clara – SAVVIS
IL: Chicago – Level3
NJ: Newark – Qwest
TX: Houston – InterNap
VA: Reston – SAVVIS
WA: Seattle – InterNap
CANADA: Vancouver – Rogers Allstream
CHINA: Beijing – China Netcom
DENMARK: Copenhagen – LambdaNet
GERMANY: Munich – Telefonica
UNITED KINGDOM: London – Global Crossing
(Messplattform: www.gomez.com), gemessen wurde nur die Startseite
Was genau sich verbessert hat in der Performance sieht man hier (für die Techniker):
Das Hauptproblem waren die initalen Verbindungen und die lange First Byte Zeit. Das Problem scheint definitiv beseitigt zu sein.
Drastischer Abfall der Linken bei der Erreichbarkeit. Ladezeiten der FDP haben sich auf den Backbones drastisch verschlechtert.
Auch bei den Usern mit schneller Internetanbindung deutlich zu sehen. Sowohl die Linken als auch die FDP muss dramatische Einbußen bei Geschwindigkeit und Verfügbarkeit hinnehmen. Die Grünen konnten als einzige etwas Boden bei der Ladezeit gut machen.
Bei der Ladezeit konnet sich die CDU/CSU dezent verbessern. Fällt aber weiterhin zusammen mit den Linken bei den Usern mit DSL-Light (< 512 kbit/s) deutlich in der Verfügbarkeit ab. Jeder 10te Aufruf konnte gar nicht oder nicht schneller als 120 Sekunden ausgeführt werden. Einzig die SPD konnte sich leicht verbessern.
Bei den Ladezeiten fast durchweg Verbesserungen. SPD und Grüne verschlechtern sich hier gegen den Trend. Mit 40 Sekunden und mehr wird allerdings die Geduld der User arg strapaziert. Bei der Verfügbarkeit beim Modemnutzer konnten SPD und Grüne weiter zulegen. Die FDP ist ganz klar und mehr als deutlich Sieger, während die CDU den positiven Trend nicht halten konnte. Lediglich 28,4% aller Zugriffe war erfolgreich. Mit diesem Ergebnis dürfte es eng werden für die CDU, die gerade bei der konservativen Bevölkerung auf dem Land punkten will.
Die Messergebnisse zum Download: ergebnisse_messungen_juni
Nachdem ich es trotz verzweifelter Bemühungen nicht geschafft habe, die Studie über Cloudcomputing in Deutschland von der IDC Marktforschung zu erhalten, wollte ich erst gar nicht zu dem Theam bloggen. Schade, dass ich mich dort nicht mit meinen Argumenten platzieren konnte.
Interessant insbesondere, weil dort scheinbar nur durch kurzen Augenschein überprüft wird ob man (das anfragende Unternehmen) nun Cloud-Anwender ist oder nicht. Hätten die Damen und Herren sich dort wirklich mit meinem Arbeitgeber beschäftigt, dann hätten diese sicherlich festgestellt, dass wir sogar ein ganzes Produkt über Cloud computing aufgebaut haben. Aber – es hilft jetzt auch kein mosern und weinen – ist halt so. Ich bin und bleibe studienlos.
Der Spiegel Artikel über das Thema ließ mir jedoch keine Ruhe.
Dort stolpert man nämlich schon im ersten Satz über die Todschreibung von Cloudcomputing: “Cloud Computing war einer der heißesten IT-Modebegriffe der letzten zwei Jahre“. Oha….”war” – Rest in piece.
Wie falsch der Spiegel Redakteur liegt, zeigt sich wenn man (leider nur) die Kurzfassung der Studie liest.
Immerhin 7% der befragten Unternehmen setzen die virtuelle Rechen- und Speicherkapazität ein. 7 weitere Prozent planen deren Nutzung. Das sind immerhin 14% – eine nicht geringe Menge wenn man die Probleme betrachtet, die die Studie dagegenhält:
- Kaum oder keine Referenzen
- Schwierige Implementierung
- Mangelnde Praxistauglichkeit (??)
- Mangelnde Compliance Richtlinien
Von allen 4 Hauptargumenten die genannt wurden, würde ich nur eines gelten lassen – nämlich das Argument “Compliance”. Solange es keine haltbaren SLA’s gibt, solange wird es (nicht nur in Deutschland) niemand oder nur wenige wagen, wirklich geschäftskritische Anwendungen in die Cloud zu verlegen. Gewinner wird der Anbieter sein, der es als erster wagt, verbindliche Qualitätsmerkmale anzubieten – auch schriftlich.
Das Argument “mangelnde Praxistauglichkeit” ist absolut hahnebüchend. Das kann nur jemand gesagt haben, der sich bislang noch nicht mit dem Thema beschäftigt hat (immerhin 75%) oder zu den 4% gehört, die einen Einsatz kategorisch ausschließen. Aber praxistauglich ist es auf jeden Fall – da könnte ich eine Reihe Beispiele nennen, wo es sich so dermaßen empfiehlt auf die Cloud zu setzen wie nur was. Sei es als einfacher Datenspeicher (Videoteaser zu einem neuen – vermutlich erfolgreichem Kinofilm) oder als zusätzliche Applikationsrechenpower (Online Gewinnspiel bei einer Halbzeitpause eines Championsleague Spiels, Lotto Jackpot jenseits von gut und böse).
Schwierige Implemetierung kann ich auch nicht gelten lassen – Entweder man hat keine Zeit oder keine Lust sich mit der Thematik tatsächlich auseinanderzusetzen oder man hat einfach den Bedarf nicht. Schwierig ist die Implementierung auf keinen Fall – wenn sogar ich es schaffe mit minimalem Aufwand (<1 Tag) mir eine funktionierende Webseite in der Cloud zu basteln.
Kaum oder keine Referenzen lasse ich als Argument für die sehr konservativ ausgerichteten IT-Abteilungen gelten. Diese sind selten “Ahead of the curve” und setzen nur getestete Systeme ein. 7% in Deutschland sind jedoch Vorreiter und vertrauen auf eine Technologie, die noch nicht mit Referenzen um sich schmeißen kann.
Was die Studie offen lässt, ist der Grad der Zufriedenheit, mit dem die 7% Nutzer die Cloudtechnologie nutzen. Ich vermute, dass hier ein “überragend” zu hören ist (Erfahrungswerte).
Wie lassen sich jedoch die berechtigten Compliance-Ängste beheben? Das geht relativ einfach, indem man solche Technologien testet.
Moderne Lasttestverfahren von außerhalb der Firewall erlauben hohe Lastzahlen und können so “erwartete Peaks” simulieren. Also ein probates Mittel um eine erwartete Lastspitze (welche durch Cloud computing abgedeckt werden soll) zu simulieren und das Verhalten der Cloudservices zu testen.
Allerdings kann ich aus meinen bisherigen Tests mit den Services von Amazon und Goolge sagen, dass man nicht erwarten kann, dass die Performance dann auch der Performance von Google oder Amazon entspricht – jedenfalls nicht aus der globalen Perspektive. Zu sehr ist der Standort der virtuellen Umgebung beeinflussend. Wähle ich z. B. die Cloud stationiert in London, dann habe ich die gleichen Latenzprobleme in den USA, als wäre mein Server in Deutschland stationiert. Dort gilt es genau zu evaluieren (!!) welchen Service ich wähle und wo dieser lokalisiert ist.
Eine Frage (gerichtet an die 75% “noch nicht damit beschäftigt”) hätte ich dann doch noch: Wie viele von Ihnen nutzen “Sales Force” oder andere Software-as-a-Service-Lösungen ?
Ich vermute, einige nutzen diese Technologie bereits. Eigentlich nichts anderes als “Cloud computing”!
Es ging durch die News, dass Google’s services teilweise nicht zur Verfügung standen. Der Spiegel schreibt dazu lapidar:
“Weil Google seine Anwendungen und Rechennetze auch anderen Firmen zur Verfügung stellt, waren auch weitere Websites zeitweise nicht erreichbar.”
Der unwissende Leser denkt und glaubt: War ja nicht so schlimm. Da konnten einige ihre Emails nicht lesen – die Suche war langsamer. Was sich aber hinter “weitere Websites” verbirgt bleibt auch im Verborgenen.
Wenn man nun weiß, dass Google Services sehr umfangreich sind und wirklich häufig genutzt werden (auch hier im Blog – dieses eine Banner rechts), dann wird die Sache schon etwas “dramatischer”. Google Services sind z. B. Bannerlieferung durch Doubleclick, Bannerlieferung durch Googlesyndication und noch deutlich häufiger genutzt: Google Analytics.
Gemeinsamkeit bei allen diesen Services: Einbindung durch ein kleines Javascript welches von Google bereitgestellte Inhalte nachlädt.
Welche Einflüsse Javascript auf die Ladezeit hat, habe ich im Eintrag: Percieved Rendertime oder gefühlte Ladezeit beschrieben. Javascript verhindert, dass eine Webseite weiter geladen wird. Glück als für diejenigen, die Google Analytics als letztes Element im Quelltext einbunden haben. Die Webseite wurde fertig geladen nur auf Google wurde erfolglos gewartet. Der User hatte das Gefühl die Webseite sei fertig.
(Klicken zum Vergrößern
Pech dagegen, wer wie Bild.de schon im Header auf Google Services verwiesen hat. Da wurde dann mitunter die Webseite für bis zu 90 Sekunden nicht weitergeladen. Der normale Internetnutzer weiß nicht, dass er gerade Opfer von Google’s Ausfall wurde, sondern denkt vielleicht: “Boah, Bild geht ja heute gar nicht!”
Bei Bild ist Google schon im Header eingbunden.
Deutlich zu sehen ist, wie das Google Problem zum Bild Problem wurde. Zu dem Zeitpunkt war noch nicht ein einziges Bild im Browser geladen. Der User wartete und wartete….bis er vermutlich keine Lust mehr hatte und zu einer anderen Seite wechselte. Für Bild bedeutet das: Weniger Aufrufe, Klickrate sinkt, Umsätze sinken.
Für Webseiten, die richtig umsatzstark sind (Retailer) bedeutet solch ein Ausfall also mitunter richtig Geschäftseinbußen.
Tests haben bewiesen, dass Ausfälle wie dieser dazu führen, dass die Besucherzahl sich nur relativ langsam wieder normalisieren.
Dieser Chart zeigt einen Ausriss aus den Amerikanischen Top 30 Portalen: Namen wie Lycos und Myspace sind nicht gerade selten besuchte Webseiten, welche unter dem Fehler litten.
Bekannte US-Amerikanische Portale litten unter dem Google Ausfall. Glück, wer wie Lycos erst am Ende des Quelltextes Google eingebunden hat.