Google Pagespeed

[unset]

So oder so: Gewöhn dir mal an, nicht ständig selbstgespräche hier zu führen. Nicht umsonst haben wir einen schönen Edit-Knopf, der nur darauf wartet benutzt zu werden.

[piratos]

Bei einem aktuellen Projekt mit viel JavaScript macht das schon was aus in punkto Ladezeit (genauer: Zeit für die Übertragung).

Da sollte man überlegen ob man nicht pre gezipped anbietet.

Jquery, Prototype wie auch der Editor Xinha und Xajax laufen damit einwandfrei.
Man erspart dem Sever die ständige Arbeit das neu zippen zu müssen und entlastet den mächtig.

[piratos]

Gewöhn dir mal an, nicht ständig selbstgespräche hier zu führen.

Was ist das denn für eine unqualifizierte Bemerkung.

[AmicaNoctis]

Da sollte man überlegen ob man nicht pre gezipped anbietet.

Jquery, Prototype wie auch der Editor Xinha und Xajax laufen damit einwandfrei.

Danke für den Tipp! Werd ich machen, wenn die Entwicklung abgeschlossen und das alles deployed ist.

[wahsaga]

Zudem muss man per Script entscheiden ob man eine solche gerade anbieten kann oder nicht, denn Safari wie auch Chrome können aktuell nichts damit anfangen. Da reicht Accept-Encoding Headers nicht, denn das normale gezippe vom Server können die sehr wohl verarbeiten.

Was meinst du jetzt mit letzterem?
Können sie GZIP-gepackte Ressourcen verarbeiten, oder nicht?

Da sollte man überlegen ob man nicht pre gezipped anbietet.

Davon red' ich doch die ganze Zeit ...

Natürlich nicht jedes mal den Server on-the-fly komprimieren lassen, das wäre bei statischen Ressourcen ja blödsinnig.
Normale Version und ge-GZIP-te ablegen - und Content Negotiation entscheiden lassen, welche davon auszuliefern ist.

[unset]

Was ist das denn für eine unqualifizierte Bemerkung.

Soll das eine Frage sein? Gerne erkläre ich es dir nochmal: Statt drei Posts hintereinander zu abzusondern, kannst du auch den letzten nehmen und editieren.

[piratos]

Was meinst du jetzt mit letzterem?
Können sie GZIP-gepackte Ressourcen verarbeiten, oder nicht?

Safari und Chrome können keine Pre gezippte Dateien verarbeiten, da die Browser offenbar einen Bug haben.

Beide können aber vom Server gz gesendete Inhalte verarbeiten.

Deswegen reicht in einem Script die Prüfung von Accept-Encoding Headers nicht aus, man muss für die pre gezippten checken ob es sich um einen Safari handelt (Chrome enthält in der Kennung ebenfalls Safari).

[wahsaga]

Safari und Chrome können keine Pre gezippte Dateien verarbeiten, da die Browser offenbar einen Bug haben.

Beide können aber vom Server gz gesendete Inhalte verarbeiten.

Was soll denn da der Unterschied sein?

Verstehst du unter "pre gezippt" etwas deutlich anderes, als eine Ressource, deren Dateninhalt per Deflate-Algorithmus komprimiert wurde?
(Sonst ich dich nämlich nicht.)

[piratos]

Man nehme gzip und packe eine Datei und verwende diese Datei in einem Web , aus fertig ganz einfach.

Warum Safari und Chrome das nicht können, das andere aber doch interessiert mich nicht die Bohne, ist nicht mein Job deren Bugs zu beheben.

Aber Sie können es definitiv nicht , das muss man nur wissen und umgehen.

[wahsaga]

Aber Sie können es definitiv nicht , das muss man nur wissen und umgehen.

Und ersteres weiss "man", weil man es selber ausprobiert hat - oder...?


Ich vermute einfach mal (ins Blaue geschossen), dass die Angabe des Content-Types im Header nicht passt, wenn die Datei .css.gz heisst, und der Server nicht so konfiguriert ist, dass er "trotzdem" die richtige Angabe liefert.

[piratos]

Und ersteres weiss "man", weil man es selber ausprobiert hat - oder...?

Nicht nur ich sondern mehr als ein halbes dutzend meiner User .

Zudem , was diese beiden betrifft, ein endloses Thema im Netz, mehr als bekannt. Es ist einfach so da gibt es nichts zu tricksen.

[piratos]

Nachdem so einige Zeit verstrichen ist und Google angedeutet hat (
Google: Page Speed May Become a Ranking Factor in 2010 | WebProNews ), das möglicherweise die Leistung (Speed) einer Seite bereits 2010 als eine weitere Methode (von z.Z. über 200) das Ranking einer Trefferliste bestimmen könnte und Yahoo bereits Juli 2009 sich seine eigenen Methoden zum Thema patentieren ließ (
United States Patent Application: 0090187592

stellt sich die Frage wie denn die Firmen reagiert haben.

Wurden Bemühungen in dieser Hinsicht unternommen ?

Ja sie wurden in fast allen Fällen - die Firmen haben das Thema kapiert und reagiert.

Zum Vergleich habe ich mal die Liste aktualisiert und den aktuellen Yslow - Faktor notiert:

typo3.org 68 -> 83
cmsmadesimple.org 66 -> 90
cmsmadesimple.de 77 -> 98
joomla.org 74 -> 90
drupal.org 84 -> 89
bundestag.de 57 -> 67
spiegel.de 54 -> 69
focus.de 61 -> 70
heise.de 67 -> 75
arbeitsagentur.de 70 -> 85
cdu.de 69 -> 81
spd.de 64 -> 70
fdp.de 79 -> 93
gruene.de 76 -> 88
rtl.de 70 -> 66
ard.de 65 -> 72
zdf.de 67 -> 82
bmw.de 63 -> 80
volkswagen.de 65 -> 77
porsche.de 70 -> 79
deutsche-bank.de 63 -> 73
eon.com 65 -> 78
opel.de 62 -> 70
raedervogel.de 78 -> 98
otto.de 61 -> 67
ebay.de 78 -> 94
hood.de 64 -> 68
amazon.de 70 -> 89
seitwert.de 63 -> 77
sumo.de 77 -> 96
agentur-suchmaschinen-marketing.de 65 -> 78
seo-consulting.de 73 -> 90
abakus-internet-marketing.de 72 -> 90

Die Verbesserungen sind teils drastisch !!

Google hat ja in seinen Webmastertools die Möglichkeit die Website - Leistung sich anzeigen lassen zu können.
Obwohl relativ neu sind da bereits Werte aus den letzten drei Monaten erfasst.

Meine Empfehlung ist die Yslow und Pagespeed einzusetzen und zwar gleichzeitig.

Das optimale Werkzeug ist allerdings in Google Chrome enthalten und zwar in den Developertools - da wird sich so mancher erschrecken.

Wer mal eine Yslow 100 Seite sehen möchte der kann bei mir rein schauen.
Einer der Entwickler von Pagespeed hat mir zudem bestätigt, das meine Hauptsite einen enorm hohen Punktwert bezüglich Speed bei Google hat.
Das beweist - jeder kann das machen - auch wenn man sich einen shared Webserver mit reichlich Leuten teilt.

[TobiaZ]

Also ich habe das Thema (ansich und diesen Thread) noch nicht verfolgt. Aber deine Liste zeigt ausnahmslos nur Steigerungen der Werte. (Warum hast du die anderen Seiten nicht mehr mit gelistet?)

Liegt es da nicht nahe zu vermuten, dass gar nicht so massiv optimiert wurde, sondern vielmehr eine Veränderung der Bewertung stattgefunden hat. Jedenfalls würde ich das noch lange nicht als einen Beweis sehen, dass fast alle etwas unternommen haben.

[piratos]

Es hat keine Veränderung der Bewertung stattgefunden die Yahoo bekannt gegeben hat.

Echte Domains , gleiche Auswertung, unterschiedliche Verbesserungen mal mehr mal weniger) im Fall RTL sogar eine Verschlechterung.

Einige Punkte können durchaus wegen veränderter Inhalte gesprungen sein dennoch sind größere Sprünge nur mit Eingriffen der Webmaster zu machen.

Wer sich dafür interessiert sollte vielleicht mal seine eigene Hitliste aufmachen um zu sehen wie es sich da im Zeitraum X nach Y verhält.

Außerdem kann ja jeder selbst einen Check machen statt sich berieseln zu lassen.

Das würde ich auch empfehlen.

Manche die rein altbacken denken wird eine Denkweise in HTTP Request's nicht leicht fallen.
Ich sage da nur als Stichwort das 6 Bilder a 1 Byte schlimmer sind als 1 Bild mit 1 MB - das wollen sehr viele einfach nicht kapieren, die denken das eine sind insgesamt 6 Byte das andre mit 1 MB ein vielfaches von dem.
Hilfe bietet da Google Chrome mit seiner Timeline mit dessen Hilfe der AHA Effekt sofort vorhanden ist.

Wer nichts macht kann über kurz oder lang dann in die Röhre schauen, wenn Google & Co. tatsächlich ernst damit machen Seiten über Speed zu bewerten.

Und davon einmal abgesehen - die eigenen Besucher werden begeistert sein eine flinke Seite zu finden.

Ich kann immer nur empfehlen - beschäftigt euch in der Praxis damit.

-------------------

Die Google Webmastertools Website-Leistung hat z.Z. eine Mittelinie von 1,5 Sekunden, darüber geht eine Seite in Richtung langsamer darunter in Richtung schneller.

Meine Hauptsite liegt bei

Dies ist schneller als 96 % der Websites.

Im Schnitt gemessen wurden 0,5 Sekunden, die tatsächliche Leistung schwankt aber zwischen 0,04 und etwas über 0,5 Sekunden.

Und das ist schon erschreckend, bedeutet es doch im Klartext das sehr viele Websites extrem langsam sind , also deutlich über die 1,5 Sekunden hinaus gehen.

Damit ist übrigens die Endzeit gemeint , d.h. wenn eine Seite vollständig vorliegt und gerendert ist, also keineswegs zu verwechseln mit einer Generierungszeit oder der nackten Downloadzeit des HTML Codes.

Und - man muss keineswegs auf Komfort oder JS verzichten - ich verwende da z.B. jquery plus paar Addons zu jquery mit zusammen über 74KB.

Klar ist das Anwendungen die von Haus aus langsam sind Nachteile haben.

Aber so gut wie alle Scripte lassen sich aufpolieren - mein Forum ist z.B. SMF und hat überwiegend Yslow 100 und unter Pagespeed hervorragende Werte.

[onemorenerd]

Man nehme gzip und packe eine Datei und verwende diese Datei in einem Web , aus fertig ganz einfach.

Warum Safari und Chrome das nicht können, das andere aber doch interessiert mich nicht die Bohne, ist nicht mein Job deren Bugs zu beheben.

Aber Sie können es definitiv nicht , das muss man nur wissen und umgehen.

Falsch! Beide Browser, Safari und Chrome senden "Accept-Encoding: gzip,deflate" in der Anfrage und zwar nicht zum Spass. Sie können wirklich damit umgehen.

Du sendest ihnen nur nicht die richtige Antwort. Eine .css.gz musst du mit "Content-Type: text/css" und "Content-Encoding: gzip" ausliefern. Du überläßt es aber wahrscheinlich dem Server, die Header zu setzen. Der schaut sich nur die Dateiendung .gz an und sendet "Content-Type: application/x-gzip". Webkrit reagiert darauf völlig korrekt. Kein Bug.