Google macht die Ladegeschwindigkeit zum Rankingfaktor

9. April 2010, 22:08

Nun ist es offiziell: Google hat die Ladegeschwindigkeit einer Webseite in den Algorithmus eingebaut. Als einer von rund 200 Rankingfaktoren wird in Zukunft auch die Zeitspanne, die eine Seite zum Laden braucht, in das Ranking einfließen. Bislang soll dies lediglich im englischsprachigen Raum auf Google.com passieren und bei weniger als ein Prozent der SEPRs zu Änderungen führen – aber wir können wohl davon ausgehen, dass Google diesen Faktor in absehbarer Zeit global ausrollen wird und die Änderung auch die deutschen SERPs betreffen wird.

Unter „Ladegeschwindigkeit“ werden aktuell zwei verschiedene Zeiten subsumiert. Zum einen ist da die reine Auslieferungszeit der HTML-Seite – also die Zeit, die zwischen der Anforderung der Seite durch den Googlebot und Auslieferung des letztes Bytes liegt. In den Google-Webmaster-Tools findet man diesen Wert unter Diagnose+Crawling-Statistiken:


Ein guter Wert sollte hier bei weniger als 500 Millisekunden liegen. Werte, die im Durchschnitt höher sind, können dazu führen, das Google die Seite nicht so intensiv und tiefgehend crawled, wie eigentlich vorgesehen. Der zweite Wert – und das ist der, der künftig in den Algorithmus einfließt – ist die Zeitspanne bis zur Auslieferung der kompletten Seite: inklusive Grafiken, JavaScript und AdServer-Geschichten. In den Webmaster-Tools finden sich Werte unter Google Labs+Website-Leistung:


Google gibt hier selber einen Wert von rund 1,5 als Schwelle zwischen „gut“ und „schlecht“ vor. Zusätzlich gibt es auf der Seite noch zahlreiche Tipps für die Verbesserung der Ladezeit. Diese Werte werden übrigens über die Google Toolbar ermittelt, sollten im Großen und Ganzen also stimmen.

Dieser Beitrag hat 55 Kommentare

 
  9. April 2010, 23:50

Das ist natürlich bitter für alle, die gerne und zurecht große Bilder benutzen, um die Texte anschaulich zu illustrieren – oder weil sie eben Bilder zeigen. Will Google zurück ins Internet-Mittelalter? Ich hätte nicht gedacht, dass Google diesen Quatsch in Zeiten von DSL tatsächlich durchzieht.

 
  10. April 2010, 00:13

Das wundert mich aber. Also ich hatte bisher den Eindruck, dass die Messergebniss unter Website-Leistung (der zweite Wert) noch sehr frühes Betastadium haben. Die ermittelten Lade-Zeiten sind nach meinem eigenen Erfahrungen viel zu hoch und wenn mir unter „Vorschläge von Page Speed“ als erstes vorgeschlagen wird, gzip zu aktivieren, dann muss ich mich doch schon etwas wundern, da dies schon aktiv ist.

 
bingfan
  10. April 2010, 00:29

Google hat doch kein Problem, etwas auszurollen, was noch beta * buggy ist. Den Schaden haben dann die Website-Betreiber. In den letzten Wochen hat Google einige Server so intensiv gecrawled, dass es schon nach einem Last-Test aussah. Vielleicht war es genau das. Nun weiß Google, was als Benchmark genommen werden kann.

 
Yeepeiyeah
  10. April 2010, 00:30

@Mißfeldt, ich glaube, dass es aus googles Sicht durchaus Sinn macht. Dadurch, dass Seiten schneller geladen werden, vermindert sich die Rechenlast bei google bei der Bewertung von Seiten und so können bei „gleicher“ Auslastung (oder halt Ressourcen und Kosten schonender) mehr Seiten gespidert und indexiert werden. (sicherlich auch interessant bzgl. der universal search, noch schneller neue Inhalte (News etc.) zu indexieren.
Hinzu kommt die starke Zunahme von mobile-Abfragen und vielleicht daraus resultierend eine Verschmelzung des mobile-Index mit dem „normalen“-Index und der dann auch für Mobilegeräte schneller zu ladenden Seiten…
Hier werden die Bilder wohl eher ein Opfer sein, da google hiermit nicht den Hauptumsatz generiert und der Schwerpunkt auf der Weiterentwicklung des Hauptindexes und der damit verbundenen Techniken ist.
Aber es wird auch nur ein Faktor sein und bleiben und wie stark sich dieser auswirken wird, kann man ja auch noch nicht abschätzen.

 
Klaus
  10. April 2010, 01:17

Hi,
ich begrüße diese Umstellung.
Ich habe bisher alle meine Seiten auf, bestmögliche, Geschwindigkeit optimiert. Für alle die sich noch nicht so sehr mit Speed-Optimierung auseinandergesetzt habe, kann ich nur das FF-Plugin YSlow empfehlen. 😉
Und seitdem es Realtime-Ergebnisse in den SERPs gibt, kann ich google gut verstehen…jetzt mehr Wert auf die Geschwindigkeit zu legen. Hinzu kommt, dass es dem User vermutlich mehr Spaß macht, auf einer schnellen Seite zu stöbern, als auf einer langsamen. Und die 1,5 Sekunden bis die komplette Seite geladen ist…also mal ehrlich…das sollte für den Großteil der Webmaster zu schaffen sein.

 
kandora
  10. April 2010, 02:07

@mißfeld: das hat nichts mit mittelalter zu tun, sondern mit usability. danke google.

 
  10. April 2010, 03:23

Ich wollte nur mal flott in Runde werfen, dass Ihr Euch ganz viel Beschleunigungs-Arbeit sparen könnt, sofern Ihr PHP 5 einsetzt. Ich hab da nämlich eine feine Library zusammengebaut:
http://github.com/Schepp/CSS-JS-Booster

Alternativ gibt es das ganze auch fertig verpackt für WordPress als Plugin:
http://wordpress.org/extend/plugins/css-js-booster/

Viele Grüße

vom Schepp

 
ska
  10. April 2010, 04:57

minify ist auch eine Empfehlung wert
http://code.google.com/p/minify/

Und man sollte darauf achten, dass man nicht mit installierter Google Toolbar auf unoptimierte nicht öffentliche Backends zugreift. Diese Werte fliessen absurderweise auch in die Statistik ein und können die durchschnittliche Ladegeschwindigkeit negativ beeinflussen.

 
Jürgen
  10. April 2010, 07:43

1.5 Sekunden bis die Seite komplett geladen ist?
Was denkt sich Google dabei, nicht jeder will seinen Besuchern reine SEO-optimierte Textwüsten bieten.

 
  10. April 2010, 07:49

Das verspricht goldene Zeiten für Content Delivery Networks 😉

 
  10. April 2010, 09:55

Mit diesem Schritt unterstützt Google das, was auch für den Besucher einer Website wichtig ist: Keiner wartet gerne. Optimiert man seine Webseiten auf Performance, so stellt man nicht nur den G-Riesen, sondern auch Leser zufrieden.

Es gibt viele Ansätze zur Steigerung der Inhaltauslieferung, einige davon habe ich gründlich in einzelnen Beiträgen vorgestellt: http://playground.ebiene.de/category/performance/

 
Flat-Jack
  10. April 2010, 10:17

1,5 sec ist echt heftig für größere seiten. Wir betreiben eine große Community und sind nach viel Arbeit inzwischen runter auf 4,5 sec – mehr geht nicht!
Dabei sind unsere Seiten „gefühlt“ deutlich schneller als die meisten Seiten der Mitbewerber. Meiner Meinung reicht es ja auch, wenn die Seite aufgebaut, Bilder geladen und der Text lesbar ist. (Das dauert ca 1-2sec).
Wenn im Hintergrund dann noch 2 sec ein paar Javascripte ausgeführt werden (für Werbung etc), sollte das doch keinen User stören. Leider macht da die Toolbar natürlich keinen Unterschied…

 
Horst
  10. April 2010, 10:18

Die Werte, was Google als schnell und langsam ansieht, ändern sich aber bei mir öfter. Wobei ich einerseits froh bin, dass die Ladezeit eine Rolle spielt, das wird endlich WordPress endgültig den Garaus machen. 😎
Andererseits ist es nicht so leicht zu beurteilen. Wie oben schon erwähnt, gibt PageSpeed da schon seltsame Tipps. Mir wird empfohlen externe Scripte zu einem zusammenzufassen. Die gemeinten Scripte sind dabei Adsense und Analytics. Toller Tipp. Da frage ich mal Google ob die das für mich machen. Grafiken sind auch ein Problem. Aber die könnte man ja einfach ignorieren, wenn brav Breite und Höhe der Platzhalter definiert sind.
Wenn jemand intelligente Lösungen nutzt um wiederverwendbare Teile im Browser-Cache unterzubringen nutzt das vermutlich nichts. Insgesamt glaube ich, ist es zu schwierig automatisch die Geschwindigkeit wirklich festzulegen. Dazu kommt es zu sehr „darauf an“. Was geht ist die Grundsätzliche Geschwindigkeit des Servers und die Auslieferung des HTML-Codes. Aber das ist ja schonmal ein Anfang.

 
  10. April 2010, 10:20

Man sollte die ganze Diskussion vor dem Hintergrund sehen, dass Google ein starkes Interesse daran hat, weite Teile des täglichen Computergebrauchs ins Internet zu verlegen. Anwendungen wie Google Docs sind da ein Baustein, aber auch sowas wie Android, GoogleOS und Chrome wurden mit dem Hintergrund entwickelt. Ein weiterer Baustein ist nun, dass User nicht lange auf Ergebnisse/Seiten warten müssen und die Unterschiede zwischen Desktop und Internet weiter verschimmen.

 
  10. April 2010, 11:29

Die Leistungübersicht ist die mittlere Wert von dem Website Komplett. Aber jedes Url hat andere Ladegeschwindigkeit, was fließt eigentlich als Rankingfaktor.

 
Tom
  10. April 2010, 11:31

Alle, die das (kombinierte und komprimierte) Ausliefern von JS/CSS über ein PHP-Skript empfehlen, sollten mal ein paar Messungen anstellen. Je nach Server-Konfiguration kann der Overhead (auch bei serverseitigem Caching der generierten Datei!) sehr hoch sein und das ganze ad absurdum führen.

Lieber „echt“ statisch ohne PHP ausliefern.

 
  10. April 2010, 11:32

Wurde Zeit, dass PageSpeed für das Ranking relevant wird. Das Argument der „großen und vielen“ Bilder kann man wirklich nicht gelten lassen – auch hier lässt sich vieles optimieren … Manchmal dauert es eben seine Zeit, bis der eine oder andere Webmaster herausgefunden hat, was dieses ominöse „gzip“ eigentlich bedeuten soll 😉

 
  10. April 2010, 12:00

Letztendlich muss man das mit der Ladezeit als nachrangiges Merkmal sehen, wenn Google zwischen zwei inhaltlich gleichermaßen passenden Seiten das Ranking zu entscheiden hat. Eine Foto-Community muss da also überhaupt gar nicht mit dem Rest der Welt konkurrieren, sondern nur mit anderen Foto-Communities, die dieselben technischen Herausforderungen zu meistern haben.

@Karl Kratz
„GZIP“ ist im Zusammenhang mit Bildern leider das schlechtestdenkbare Stichwort. Wenn dann sollten hier Begriffe fallen wie „Sprites“ oder „Data URI“.

@Tom
Es kommt es auf die Art des Engpasses an, den man beim Ausspielen der Seite hat: Pfeift der Webserver auf dem letzten Loch, dann sollte man ihm nicht auch noch allzu hochgedrehtes Zippen aufbürden. Meist liegen die Engpässe aber ganz woanders: A) kein performant zusammengefügtes Frontend, und B) Unoptimierte oder unkluge Datenbankabfragen bzw. C) eine schlecht konfigurierte Datenbank.

@ska
Dieses minify ist auch cool, aber kann eine Sache nicht, die meine Library macht: ich bette alle Bilder direkt als HTPP-Request-losen „Data URI“-Datenstrom in die CSS-Anweisung ein, aus der heraus auf Bilder verlinkt wird. Siehe http://www.phpied.com/data-urls-what-are-they-and-how-to-use/

 
Tom
  10. April 2010, 12:09

@Schepp:

Darauf hatte ich mich nicht bezogen. Mir ging es um das mögliche Spawnen von PHP-Prozessen nur zum Ausliefern der kombinierten Dateien, weil der HTTP-Request nunmal auf das Skript gerouted wird. Ich ging sowieso schon davon aus, dass das verantwortliche PHP-Skript die fertig gebauten Dateien statisch ablegt, sodass die Kompression ohnehin nur 1x geschieht. Die benötigte CPU-Zeit ist also unproblematisch.

Was die anderen beiden Punkte von dir angeht, möchte ich aber zustimmen. Eine optimierte Auslieferung von statischen Dateien hilft kaum, wenn die Queries unter aller Sau sind 🙂

 
  10. April 2010, 12:16

@Tom Ah, so war das gemeint. Recht hast Du.

 
  10. April 2010, 12:40

Ich finde es tendenziell vollkommen richtig – es kommt eben nicht (oder immer weniger) auf Masse, Bling Bling und klotzig, sondern auf die Inhalte an. Vielleicht ermutigt dies die Webseitenbetreiber Ihre Angebote vermehrt auch auf das Wesentliche zu reduzieren.

Verrückt machen lassen sollte man sich davon nicht, aber anerkennen dass es ja schon dem Nutzer zu Gute kommt wenn er nur das findet was er sucht, und nur ausgeliefert wird was nötig ist, und das technisch so schnell und schlank wie möglich.

 
  10. April 2010, 13:03

@Schepp Danke dir 🙂 Ich teste das mal gerade bei uns. Über zig Jahre hinweg ist so viel Kraut und Rüben an Code dazugekommen… da wundert es mich nicht, dass das unsere Performance runterzieht. Bin gespannt. Gruss, OAK

 
  10. April 2010, 13:07

@oak Jau, mach mal. Wenn es irgendwo klemmt: geb Bescheid (am liebsten via Twitter: @derSchepp)

 
  10. April 2010, 13:17

Ein schwieriger Punkt für größere Fotogalerien wie der meinen.

 
  10. April 2010, 13:21

@Christian: Schau mal wie schnell diese Bildergalerie lädt:
http://www.sky-fun.de/fallschirmspringen-fotos-bilder.php

Alle Bilder sofort da. Dank Data URI mit GZIP (Ausnahme: IE < 8)

 
  10. April 2010, 15:48

@Flat-Jack:

Wenn du von 4,5 Sekunden für eine Community sprichst, sprichst du dann von anonymen Traffic? Google und irgendwelche User, die über die SERPs kommen, sind schließlich nicht bei euch eingeloggt. Anonymer Traffic lässt sich entsprechend auch bei feature-rich Websites gut cachen und entsprechend flott ausliefern.

Im Idealfall braucht es dann keine einzige Datenbankabfrage und der Content wird direkt aus einem Reverse Proxy geliefert, ggf. unterstützt durch ein CDN.

 
  10. April 2010, 19:22

Ich teste & benutze seit einem halben Jahr das kommerzielle Tool WEBO Site SpeedUp in der Premiumversion und bin mehr als zufrieden mit dieser Komplettlösung. Die vielfältigen Möglichkeiten lassen sich optimal auf die jeweilige Serverumgebung einstellen. Optimierungs Know-How sollte man trotzdem mitbringen.

Home: http://www.webogroup.com/
Doku: http://code.google.com/p/web-optimizator/w/list
Beschleunigung für verschiedene Systeme: http://www.webogroup.com/hosting/site-speedup/efficiency/

 
  10. April 2010, 19:40

Interessant, darauf hab ich gewartet.
Gut, dass ich gerade mein Portfolio optimiert hab und yslow mir ein A gibt. Ja gut, es ist nur eine HTML-Seite, aber man muss ja mal alles testen 😀

Artikel ist gebookmarked, hab ich noch was, was ich meinen Vorgesetzten präsentieren kann. Danke!

 
  10. April 2010, 20:33

@Schepp
Whow! Alle Bilder „inline“ reinkodiert? Uff. Ich bin nicht sicher ob das der richtige Weg ist. Natürlich sparst Du einiges an HTTP-Requests, ABER du killst ja jegliches Caching für Bilder die mehr als einmal bzw auf mehr als einer Seite verwendet werden. Die „Userexperience“ leidet darunter auf Seiten mit vielen Bildern doch auch, weil Bilder außerhalb des sichtbaren Bereiches quasi nicht mehr im Hintergrund geladen werden.

Allgemein zum Thema:
Bei mir bemängelt Google externe Bibliotheken. In erster Linie die von Google :-/
Sehr kompliziert finde ich auch, dass Optimierung für CSS und Javascript der Quadratur des Kreises ähneln: Entweder man lädt nur das nötigste, dann aber auch jeder Seite ggf. unterschiedliches und zerstört damit das Caching.
Oder aber man lädt fast alles, dafür bekommt man dann in Pagespeed schlechte Noten weil nur ein Bruchteil des Javascript und CSS verwendet werden.

Zum „Zippen“ von Content noch etwas: Ich habe es wirklich auf Webservern ausprobiert die ziemlich unter Feuer stehen: Die zusätzlich Belastung durch das „Zippen“ ist VIEL geringer als die höhere Auslastung der Webserverprozesse durch längeres Senden, wenn man es nicht macht.
Die Last auf meinen Servern ist nur 30% im Vergleich zu der „ohne Komprimierung“.

 
Rob
  10. April 2010, 22:20

Ich finde es nicht gut. Wer seine Kunden auch emotional ansprechen will, kommt um Bilder nicht herum. Diese Entscheidung Googles wird einen Trend zu langweiligen, bilderlosen und austauschbaren Webseiten einläuten. Schade, dabei gibt es vor allem in den USA immer mehr wunderschön gestaltete Webseiten. Und mit CSS alleine ist das nur schwer möglich.

 
  11. April 2010, 00:49

@Rob: Das Problem mit den Bildern lässt sich doch lösen…
Bei einer Domain generiert man subdomains, und verteilt dann die requests für die Bilder darauf, so dass der Browser möglichst viele parallel laden kann. Bei vielen großen Seiten ein gängiges Szenario. Hat man mehr Server zur Verfügung ist das gleich noch einfacher. Dadurch ist die Seite für google dann trotz vieler Bilder immer noch schnell.

Des Weiteren verbraten viele Seiten schon requests mit Hintergrundgrafiken im CSS, diese lassen sich mit CSS-Sprites einfach reduzieren. Meist sind die gesamten Grafiken in einem Sprite kleiner als alle Grafiken einzeln. Ok, es lässt sich nicht immer alles in ein Sprite packen, aber es reduziert die Sache schon sehr.

 
  11. April 2010, 14:39

Finde ich sehr gut da langsame Seiten für den Besucher einfach nur grausam sind. Das Geschwindigkeit nun ein Rankingfaktor ist kommt mir gerade recht. Für technische Optimierungen wird sowieso schon zu wenig Zeit eingeplant, da ist es schön das man nun einen weiteren Argumentationspunkt hat.

:thumbsup

 
  11. April 2010, 17:27

@Schepp: GZIP, Sprites, die ganze Palette halt (War ja nur ein Beispiel): http://tiny.cc/morepagespeed . Vor allem der Beitrag „Yahoo BPA“ bringt einen Haufen KnowHow rüber.

 
  11. April 2010, 19:35

Ha – Die sprechen mir wirklich aus der Seele! Wenn ich an diese ganzen Möchtegern-Webdesigner denke, die Stein und Bein auf ihr ach so tolles Kann-HTML-Speichern-Programm („Word“) schwören, ohne einen Funken Ahnung von den wahren Abläufen zu haben. Das ist wie Autofahren-Wollen ohne in die Fahrschule zu müssen.

Es gibt übrigens ein Browser-AddOn namens Yslow (z.B.), das eine ganze Reihe von guten Vorschlägen macht. Aber AddOn hin, Tool her – es gibt einfache Regeln: Einfache lineare Dokumentstruktur aus Überschriften und Absätzen, externe CSS und Scripts (nur notwendiges in wenigen Dateien) am ENDE des Dokuments einbinden, externe Dateien wie Images von 1 zusätzlichen Domain oder Subdomain laden. Und Ajax ist auch ne feine Sache. Aber PHP… ist kein Allheilmittel, wenn man erst einen Riesenbatzen an Alleskönn-Klassen zu laden hat!

 
  11. April 2010, 23:25

@Karl: CSS Sprites and data:URI can be easiliy automated (with mentioned WEBO Site Speedup or CSS-JS-Booster). And this gives additional speedup and conversion increase to the website.

 
Emanuel Schneider
  12. April 2010, 14:47

Aus Usability-Sicht ist dieser Schritt bestimmt sinnvoll, wobei lange Wartezeiten heutzutage eh relativ selten sind. Mich würde interessieren, welche Auswirkungen dies auf Webseiten hat, die naturgemäß längere Ladezeiten haben (bspw. YouTube oder maxdome)? Gibt es hierzu Meinungen?

 
seo-admin
  12. April 2010, 15:49

Mich wundert, warum die Größe der Seite nicht in Betracht gezogen wird, ist schließlich für die Auslieferungszeit ja auch nicht ganz unwesentlich…

Ich wollte aber auch noch einen Hinweis für die Performance-Optimierung geben: Die WWT zeigen in den angeblich an Pagespeed angelehnten Optimierungsvorschlägen offensichtlich auch falsche Hinweise an!
Mir wurde erklärt,ich möge meine CSS-Inhalte zippen (gzip) was aber definitiv schon passiert!
Ich habe keine Erklärung dafür gefunden… erst die Überprüfung über das PageSpeedtool lässt vermuten, was gemeint war: Diesselben Ressourcen wurden hier als Kandidaten für Minfiying gelistet … sehr interessant!

 
  13. April 2010, 12:22

@Horst Ich glaube nicht das Du dich wirklich mit WordPress auskennst. Ich nutze auch WordPress und ich denke eine Ladezeit von 1,4 bei Google und 0,9 bei Pingdom sind durchaus gute Werte.

 
  13. April 2010, 16:44

Hallo Leute,

so aus unserer Erfahrung (resultieren aus den Ladezeiten von 135000 datenbankgestützen Webseiten) ist der Zusammenbau des html-Quellcodes schon für viele Seiten der erste Flaschenhals. Das sollte aus unserer Sicht im Millisekundenbereich möglich sein, unbeschreibliche Systeme wie Joomla! haben über rund 50 000 Installationen einen Schnitt von 1,4 Sekunden. Ohne Bilder, ohne sonstige wie auch immer referenzierten Dateien. Das ist unterirdisch, und da ist noch unglaublich viel Optimierungspotenzial, bevor man an Dinge wie jpg-Qualität, gzip, Cookiemanagment oder ähnliche Dinge herangeht.

Uns spielt es jedenfalls in die Hände, die Performance war und ist bei uns immer schon Thema gewesen.

Viele Grüße,

Klaus (hlag)

 
AR
  14. April 2010, 09:32

Auf lange Sicht war das klar und sinnvoll. Dass die Seitengeschwindigkeit ein Kriterium ist war schon lange kein Geheimnis mehr, oder?

Zumal sich hier auch die Spreu vom Weizen trennt, ich erschrecke mich immer noch wenn Seiten ein 2 MB großes JPG einbinden und dass dann auf Briefmarkengröße verkleinern.

Usability und Performance gehören auch mit zum Webdesign und der Profi investiert auch in seinen Webspace und Performance und optimiert seine Seite dementsprechend. Ich behaupte mal dass nicht jeder so ins Detail gehen kann und will bzw. dort investiert.

 
  15. April 2010, 08:44

Wie Google kürzlich offiziell berichtete wird zukünftig die Zeit, die eine Webseite zum Download benötigt, in den Algorithmus der Ranking-Berechnung einfließen… Wie allerdings geht Google damit um, dass die Funktion Website-Leistung eher im Beta Stadium ist als völlig asgereift? Wie wird sich der neue Ranking Faktor auf die SERPS auswirken?

 
  19. April 2010, 16:13

Wie gemein!

Das ist natürlich ein K.O.-Kriterium für alle Fotografen, deren Dienstleistung meist in erster Linie nach der Qualität der im Netz verfügbaren Bilder zu beurteilen ist. Dabei ist es schon schlimm genug, dass der ein Bild umschließende Text ebenso relevant ist, man jedoch als Fotograf die Bilder selbst sprechen lässt und diese in einer Galerie keiner Texte bedürfen.

Nicht sehr fair …

 
  21. April 2010, 10:53

Meine Seite gehört (mit 4,3 Sekunden) sicher mit zu den langsamen, und das weiß ich auch.
Und es ist mir völlig egal. Schließlich mache ich Webseiten für Menschen und nicht für Google. Für Google mögen 2 oder 3 Sekunden schon langsam sein (!?), für einen Menschen sicherlich nicht.
Und was SEO angeht: dann geht eben einer der 200 Punkte um 10% nach unten, was solls. Aber ich sehe schon die vielen Hobbyschrauber, die jetzt ihre Bilder bis zum Mosaik komprimieren und in der style.css die Leerzeichen entfernen.

Mal die Kirche im Dorf lassen, schlage ich vor.

 
  28. April 2010, 12:57

Ich bastel gerade an nem Relaunch, von alter, per Dreamweaver gecodeten statischen html Seite hin zu Typo3 und stelle schon fest, dass sich das lohnt. Viel Codesalat verschwindet, aber da ich eben neue Funktionalitäten drinhaben will wie facebook connect, Google translate api und man um Tracking-Scripte und Javascript-Ads ja auch nicht herumkommt wenn man Geld verdienen will finde ich es dann fast lustig wenn Google solche Tips raushaut und ich beim Checken mit Yslow immer wieder feststelle dass die Google Scripts genau die sind, die am langsamsten laden. Habe mal getestet und ohne Adsense, Analytics und Google Translate lädt die Seite um die Hälfte schneller ; )

 
  3. Mai 2010, 21:29

Hm… Ein heikles Thema. Zum einen finde ich es prima, dass ich durch diesen Wert wohl weniger scheintote Links antreffen werde. Auf der anderen Seite sind da die Websites, die hier schon erwähnt wurden: Seiten mit größeren Bildern. Und Bilder machen teilweile eine Menge aus; fangt doch nur mal bei Fotografen an. Für solche Leute eher schlecht, diese Neuerung…

 
  5. Mai 2010, 11:30

Wo soll das Problem bei Fotografen sein? Nehmen wir an alle Fotografen-Sites sind vergleichsweise schwer unterwegs, dann herrschen doch innerhalb desselben Marktsegments gleiche Bedingungen. Wenn alle lahm sind, gewinnt keiner durch den neuen Ranking-Faktor gegenüber dem anderen.

 
  7. Mai 2010, 23:33

Angesichtes der nicht ganz so überraschenden mobilen Herausforderung ist es nur logisch einmal mehr wieder auf die Qualität von Webangeboten zu setzen. Ich begrüße den Google Schritt in dieser Hinsicht.

Ich würde es ebenso begrüßen, auf Webseiten weniger Scrollen zu müssen – weder am Bildschirm noch auf einem mobilen Gerät.
Weniger Marketing – dafür mehr Information. Diese Seiten dürfen dann auch gerne weiter vorne platziert sein.

Wie bin ich die Webseiten leid, deren jeweiliger Seiten-Ausdruck das Einlegen von Endlospapier erfordern würde!

UND es ist immer wieder gut über eine ausgewogene interne Navigations- und Linkstruktur nachzudenken!

Wie wäre es mal damit:
html, html * {overflow:hidden !important;}

😛

— nein – nur ein Spass.

 
  3. Juni 2010, 16:56

Hi,

>Der zweite Wert – und das ist der, der künftig in den Algorithmus einfließt
Warum fließt nur dieser ins Ranking?

Ich halte die Aussage für nicht vollständig. Ich würde eher sagen, dass der zweite neuerdings ebenfalls ins Ranking einfließt und der erste schon immer eingeflossen ist.

Warum? Nun der erste Wert bestimmt wie schnell der Crawler neue Seiten indexieren darf. Insbesondere bei Server-Upgrades / großartigen Performance-Verbesserungen konnten wir feststellen, dass der Crawler seinen Intervall schrittweise erhöht und immer mehr Seiten aufnimmt bis vermutlich die Server entweder signifikant langsamer antworteten oder das mögliche Maximum erreicht wurde. Wer schneller indexiert wird, erreicht die ersten Besucher in den SERPs und dank der Klickratenauswertung innerhalb der SERPs baut man bereits seinen Vorsprung aus, noch bevor der Mitstreiter seine Klicks sammeln kann. Das gilt insbesondere für Newsseiten.

Ich würde also sagen, dass der erste Wert schon immer als Subfaktor der Klickrate galt.

Übrigens kann man die Zeiten, die Google ermittelt ziemlich gut fälschen, in dem man wiederkehrenden Besuchern / Langzeitnutzern unter der gleichen URL andere Inhalte ausgibt als Gästen. D.h. man könnte Stammnutzer z.B. damit belohnen, in dem man ihnen keine Werbung anzeigt. Auf unseren Seiten konnten wir beobachten das 90% der Ladezeit durch Werbeanbieter zu stande kommt.

Es ist übrigens nicht nur ein Rankingfaktor, sondern wird auch dazu führen, dass Publisher Google Adsense bevorzugen. Wenn man nämlich die Werbeanbieter untereinander vergleicht stellt man fest, dass Googles Werbecodes viel schneller laden und wenn man dann noch überlegt, dass das ein Rankingfaktor ist. Vielleicht baut man dann lieber doch keine lahmen Anbieter ein.

Zuletzt eher eine Frage:
Weiß jemand wie die Toolbar die Zeiten ermittelt. Also ist mit onload Schluss oder geht die Analyse auch darüber hinaus? Wir haben nämlich eine URL gefunden, die eine utoptische Ladezeit aufwies und wir können uns das im Moment nur durch das anschließende Abspielen eines Youtube-Videos erklären.

Gruß
Marc

 
Peter
  26. Juni 2012, 00:58

Ich starte eine Seite übers Fallschirmspringen. Wie relavant ist es für mein Ranking tatsächlich, dass die Seite schnell lädt? Ich habe das Gefühl, dass es kaum Auswirkungen hat. Hauptsache die kommt!

 
hans.dieter.penis@googlemail.com
  26. Juni 2012, 01:00

Ich starte eine Seite übers Fallschirmspringen: http://tandemfallschirmsprung.com . Wie relavant ist es für mein Ranking tatsächlich, dass die Seite schnell lädt? Ich habe das Gefühl, dass es kaum Auswirkungen hat. Hauptsache die kommt!

 
Klaus
  12. November 2012, 17:32
 
  23. März 2013, 14:18

There are many factors and twists to ranking a webiste high in the search engines. It can be intimidating at times.

 

[…] sinkt weiter, die Internetverbindungen der Nutzer werden schneller, Zeit ist Geld und damit knapp. Google gibt eine Ladezeit von 1,5 Sekunden als annehmbar an. Höchste Eisenbahn sich näher mit dem Thema auseinanderzusetzen, wenn nicht bereits […]

 
  8. Oktober 2013, 19:45

[…] Geschwindigkeit ist wichtig, weil Google schnell ausliefernde Website besser findet. Hier ist die weltweit größte Suchmaschine ähnlich veranlagt wie die User: Wer wartet schon gern? Warten ist langweilig und im Internet ist die Konkurrenz immer nur einen Klick entfernt. […]

 

Kommentare geschlossen

Die Kommentarfunktion wird 30 Tage nach der Veröffentlichung des Beitrags deaktiviert.