Warnung: file_put_contents(/home/www/web1/html/php_dev/test.txt) [function.file-put-contents]: failed to open stream: Permission denied in /home/www/web1/html/php_dev/sys/lib.activity.php (Zeile 58)
Google Pagespeed [Archiv] - PHP-Scripte PHP-Tutorials PHP-Jobs und vieles mehr

- Ad -
php-resource




Archiv verlassen und diese Seite im Standarddesign anzeigen :
Google Pagespeed


 
piratos
16-08-2009, 17:11 
 
Google bietet als Addon für den FF PageSpeed an, das widerum eine Erweiterung von Firebug ist.

Install Page Speed (http://code.google.com/intl/de-DE/speed/page-speed/download.html)

Using Page Speed (http://code.google.com/intl/de-DE/speed/page-speed/docs/using.html)

Ich habe die Empfehlungen mal alle lokal ausprobiert, weil ich da den vollen Serverzugriff habe - die bringen tatsächlich etwas.

Im Rahmen der Fummeleien, habe ich mal ausprobiert, wie es denn mit statischen Einheiten wie css oder Javascript ist, die man gleich einmalig mittels gzip komprimiert und so auch einbindet.

Das funzt allerdings nicht auf jedem Server, aber z.B. bei Strato.

<link rel="stylesheet" href="style.css.gz" type="text/css" media="screen" />
<!--[if IE 6]><link rel="stylesheet" href="style.ie6.css.gz" type="text/css" media="screen" /><![endif]-->
<!--[if IE 7]><link rel="stylesheet" href="style.ie7.css.gz" type="text/css" media="screen" /><![endif]-->
<script type="text/javascript" src="script.js.gz"></script>


Das habe ich mit einer Domain bei Strato ausprobiert die neu ist und praktisch keine Inhalte hat (bis auf Dummys) ( Home (http://www.marionsteddys.de/))

Das Caching über den Server direkt oder über Meta jedoch kann ich bei dynamischen Systemen nicht unbedingt empfehlen.

 
wahsaga
16-08-2009, 17:39 
 
Im Rahmen der Fummeleien, habe ich mal ausprobiert, wie es denn mit statischen Einheiten wie css oder Javascript ist, die man gleich einmalig mittels gzip komprimiert und so auch einbindet.
Da blicken bei der Umsetzung aber Browser in die Röhre, die das nicht unterstützen ...

Normalerweise überlässt man die Auswahl, ob komprimiert oder normal auszuliefern, der Content Negotiation - die sich dabei nach den Angaben des Clients richtet, was er versteht.

 
piratos
16-08-2009, 17:52 
 
Selbst der IE 4 und Opera 4 verarbeiten das direkt und ohne Probleme und die dürften nicht mehr auf dem Markt sein.

Ich selbst habe noch alle IE's ab V 5 und die machens problemfrei.

Das gilt sogar für den Textbrowser Lynx ab V 2.6 .

Da würde ich mir keine grauen Haare wachsen lassen, da Schnee von vorgestern.

 
wahsaga
16-08-2009, 18:06 
 
Nicht jeder Client kann sich direkt mit deinem Server verbinden - da sind Proxies zwischen, oder auch Firewalls, die teilweise etwas gegen komprimierte Daten haben könnten.

 
piratos
16-08-2009, 18:19 
 
Dann müssten die aber ziemlich seltsam eingestellt sein.

Da ich ebenfalls Zugriff auf solche habe kann ich aus der Erfahrung sagen - kein Thema.

Aber typisch hier - diesen gz Trick gibt es seit langem und der hat nur indirekt etwas mit Pagespeed zu tun.

Interessant wäre was andere von Pagespeed halten.

 
wahsaga
16-08-2009, 18:31 
 
Aber typisch hier -
Deine Einstellung hinsichtlich Verbesserungshinweisen?
diesen gz Trick gibt es seit langem
Content Negotiation auch.

 
PHP-Desaster
16-08-2009, 18:43 
 
Das Addon sieht aus wie YSlow (https://addons.mozilla.org/de/firefox/addon/5369)...
GZ-Dateien würde ich nicht so auf den Server packen, überlass das dem Webserver, zum Beispiel bei Apache mit dem mod_gzip.

 
piratos
16-08-2009, 18:56 
 
Das Addon sieht aus wie YSlow (https://addons.mozilla.org/de/firefox/addon/5369)...
GZ-Dateien würde ich nicht so auf den Server packen, überlass das dem Webserver, zum Beispiel bei Apache mit dem mod_gzip.

Der Charme an bei diesem Trick besteht darin da kein Servereingriff notwendig wäre und auch keine Zusatzlast durch Komprimierungsarbeiten des Servers entstehen.

Habe aber gerade gehört das Safari für Mac und Icab das nicht verarbeiten.

Für mich habe ich das Thema so gelöst, das ich einen Schalter über die index setze )da wird der Browser auf gzip abgefragt) und damit wahlweise über ein Miniplugin .css.gz oder .css setze und fertig ist der Salat.
Das hat zwar zur Folge das man diese Dateien 2 mal hat, aber da die im Prinzip statisch sind ist das egal, Hauptsache es wirkt.

 
piratos
17-08-2009, 20:11 
 
Ich für meinen Teil habe alle Empfehlungen von dem Teil durchgeackert und muss sagen - es bringt nicht nur etwas sondern eine ganze Menge.

Das waren mal gute Hinweise von Google.

 
piratos
19-08-2009, 14:57 
 
So weit es ging habe ich alle Empfehlungen bei mir auf der Hauptseite und Forumseite ausgeführt.

YSlow liefert einen Overall performance score ab wie auch einen Grade.

Der ist bei mir nun B bzw. 84.

de.yahoo.de hat auch nur 84 auf der Startseite.

Das aber beweist das es auch mit shared Webservern geht.

Hier mal zum Vergleich ein paar Werte zu Overall performance score anderer Websites:

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

Ohne die pre Komprimierung von CSS und JS erreicht man auf keinen Fall einen Wert über 80.
Google Page Speed wie auch Yahoo Slow empfehlen dieses !
Wer einen eigenen Server hat bzw. Möglichkeiten besitzt bestimmte Dateien auf "anderen" URL's halten zu können, der kann auch locker dicht an die 100% heran kommen.

 
TBT
19-08-2009, 15:36 
 
Ohne die pre Komprimierung von CSS und JS erreicht man auf keinen Fall einen Wert über 80.
Google Page Speed wie auch Yahoo Slow empfehlen dieses !

Blödsinn!

Die Wahl das den Server machen zu lassen ist immer besser, nicht jeder Client kann mit gz umgehen.

Nettes Spielzeug das Tool, und trotzdem hat meine Seite Outofthebox 85 Punkte OHNE pre Komprimierung :D:D:D

 
AmicaNoctis
19-08-2009, 15:39 
 
Die Wahl das den Server machen zu lassen ist immer besser, nicht jeder Client kann mit gz umgehen.

Von alleine wird der Server das wohl eher nicht machen. Und Clients, die es verarbeiten können (praktisch alle) schicken immer den Accept-Encoding-Header mit, den man leicht prüfen kann.

 
TBT
19-08-2009, 15:43 
 
warum sollte ich das prüfen,
das prüfen macht doch der Server alleine

 
AmicaNoctis
19-08-2009, 15:51 
 
Mein Apache liefert CSS und JS jedenfalls von alleine nicht GZipped aus. Das hab ich ihm per PHP aufgedrängt (inkl. der Prüfung des Accept-Encoding Headers). Bei einem aktuellen Projekt mit viel JavaScript macht das schon was aus in punkto Ladezeit (genauer: Zeit für die Übertragung).

(Bei mir läuft (aus anderen Gründen) CSS und JS sowieso über den PHP Interpreter.)

 
piratos
19-08-2009, 16:00 
 
Eine Seite fast ohne Inhalt ist locker sogar auf 100 zu bekommen ohne das man auch nur einen Finger dafür krumm macht.
Das ist überhaupt kein Thema. Home (http://power-blog.org/) wäre ein solch billiges Beispiel.

Ein Webserver ist nicht von selbst in der Lage pre - compilierte Dinge anzubieten.
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.

Genauso wenig kann der Webserver von allein AddType und Addencoding wie auch den Cache - Controll - Teil übernehmen, das muss man dem schon genau sagen und das richtet sich sicher nach den Inhalten die man anbieten will.

Eigentlich kann ich nur :D zeigt es mir doch das man sich nicht damit beschäftigt hat.

 
unset
19-08-2009, 16:03 
 
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
19-08-2009, 16:09 
 
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
19-08-2009, 16:13 
 
Gewöhn dir mal an, nicht ständig selbstgespräche hier zu führen.

Was ist das denn für eine unqualifizierte Bemerkung.

 
AmicaNoctis
19-08-2009, 16:13 
 
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
19-08-2009, 16:19 
 
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
19-08-2009, 16:26 
 
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
19-08-2009, 16:50 
 
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
19-08-2009, 17:01 
 
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
19-08-2009, 17:20 
 
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
19-08-2009, 17:27 
 
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
19-08-2009, 17:45 
 
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
23-12-2009, 14:33 
 
Nachdem so einige Zeit verstrichen ist und Google angedeutet hat (
Google: Page Speed May Become a Ranking Factor in 2010 | WebProNews (http://www.webpronews.com/topnews/2009/11/13/google-page-speed-may-be-a-ranking-factor-in-2010) ), 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 (http://appft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=%2Fnetahtml%2FPTO%2Fsearch-adv.html&r=1&p=1&f=G&l=50&d=PG01&S1=20090187592.PGNR.&OS=dn/20090187592&RS=DN/20090187592%29)

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
24-12-2009, 16:44 
 
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
24-12-2009, 18:04 
 
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
29-12-2009, 15:38 
 
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.

 
piratos
29-12-2009, 16:19 
 
Das Fehlverhalten betraf bereits vorkomprimierte Dateien und nicht die Fähigkeit von Chrome und Safari normale vom Server vorgenommene GZIP verarbeiten zu können - das konnten die schon immer sauber - das ist korrekt.

Headers wurden immer korrekt gesendet - alle anderen seinerzeit aktuellen Browser haben das prima verarbeitet.

Die damalige Versionen konnten die vorkomprimierte GZIP Datei nicht vollständig und sauber entpacken, sie hängten sich schlicht auf und nichts passierte mehr.

Die aktuelle Chromeversion jedoch kann es ohne jegliche Änderungen am Web selbst.

Damals war Safari Windows und Mac ebenfalls davon betroffen , die gleiches Verhalten zeigten (was auch diverse User berichteten). Man müsste mal checken ob die aktuelle Safari-Version sich dahingehend geändert haben.

 
TobiaZ
29-12-2009, 16:24 
 
Wo sollte für den Klient der Unterschied zwischen einer "vorkomprimierten" und einer "vom Server komprimierten" Datei liegen?

 
piratos
29-12-2009, 23:13 
 
Wo sollte für den Klient der Unterschied zwischen einer "vorkomprimierten" und einer "vom Server komprimierten" Datei liegen?
Für den Klient ? Da sollte es keinen Unterschied geben.

Auch wenn die Altversionen von Chrome und Safari(neuere müsste ich noch checken) damit nicht arbeiten können , gibt es keine Probleme beim IE (auch ältere Versionen), beim FF , Konquerer und noch ein paar, selbst integrierte Browser von Programmierungebungen verarbeiten das einwandfrei.

Warum Alt Chrome damit nicht funktionierte - das ist nicht meine Aufgabe Bugs in Fremdsoftware zu ermitteln. Es ist immer ein einwandfreier Bug wenn alle anderen Browser damit sauber arbeiten können und eben der eine oder andere nicht.

Bei vorkomprimierten erspart sich der Server lediglich die Arbeit eine Komprimierung vornehmen zu müssen und damit wird die Sache fixer und belastet den Server nicht weiter - das macht sich bei reichlich Besuchern ziemlich bemerkbar.

 
TobiaZ
29-12-2009, 23:26 
 
Für den Klient ? Da sollte es keinen Unterschied geben. Dann kann ich auch nicht nachvollziehen, warum die einen auf den alten Klients funktionieren sollen und die anderen nicht. ;)

 
fireweasel
30-12-2009, 13:01 
 
Das Fehlverhalten betraf bereits vorkomprimierte Dateien und nicht die Fähigkeit von Chrome und Safari normale vom Server vorgenommene GZIP verarbeiten zu können - das konnten die schon immer sauber - das ist korrekt.

Headers wurden immer korrekt gesendet - alle anderen seinerzeit aktuellen Browser haben das prima verarbeitet.


Wenn ich mich recht erinnere, ist das so, dass einige falsch konfigurierte Server oder serverseitige Scripts eben nicht sauber funktionierten und entweder die Request-Header des Clients nicht korrekt auswerteten oder die Response-Body-Daten in einem anderen Kompressionsformat schickten, als sie im Transfer-Encoding-Header angaben.

Wenn das vom Server benutzte Kompressions-Format "GZIP" ist, muss das der Client auch in seinem "Accept-Encoding"-Headern erlaubt haben. Üblich (weil im HTTP-Standard irgendwo definiert) ist das ZLIB-Deflate-Verfahren und nicht "GZIP". Die meisten Webbrowser sind aber so tolerant, einen falschen Response-Header zu ignorieren und "detektieren" das tatsächlich verwendete Kompressionsverfahren direkt aus den ersten "Magic-Bytes" im Body.

Lange Rede, kurzer Sinn: Ein Client (oder Browser), der "falsch" komprimierte Daten nicht entpackt verhält sich korrekt (a.k.a. strikt "standardkonform"). Ein Browser, der versucht, das tatsächlich verwendete Kompressionsformat zu erkennen, verhält sich dagegen tolerant (benutzerfreundlich), aber nicht korrekt.


Die damalige Versionen konnten die vorkomprimierte GZIP Datei nicht vollständig und sauber entpacken, sie hängten sich schlicht auf und nichts passierte mehr.

Aufhängen ist auch keine Lösung ...
... und natürlich auch kein korrektes Verhalten. ;)

 
piratos
30-12-2009, 14:26 
 
Ich habe eben mal den Safari 4.0.4 Windows getestet - der verarbeitet nun den damaligen Test ebenfalls einwandfrei.

Warte noch auf Rückmeldungen von Mac - Usern.

Für Pagespeed & Co. ist das allerdings absolut unwichtig.

Man muss eigentlich auch nicht weiter darüber diskutieren, denn Tatsache ist, das alle anderen Browser sofort damit klar gekommen sind, d.h. alles war korrekt in den Einstellungen, ansonsten hätten die wohl auch die Arbeit verweigert.

Wichtig ist das ein Webmaster umdenkt und sich überhaupt einmal mit den Möglichkeiten beschäftigt. Die Auswirkungen sind ja nicht nur messbar sondern auch klar zu sehen.

 
onemorenerd
30-12-2009, 15:37 
 
Warte noch auf Rückmeldungen von Mac - Usern.Ich bin Mac-User und ich schrieb ja bereits, dass es funktioniert.

Man muss eigentlich auch nicht weiter darüber diskutieren, denn Tatsache ist, das alle anderen Browser sofort damit klar gekommen sind, d.h. alles war korrekt in den Einstellungen, ansonsten hätten die wohl auch die Arbeit verweigert.
1. Korrektheit ist doch kein Mehrheitsentscheid! Es gibt Definitionen - in diesem Fall RFCs, die festlegen was korrekt ist und was nicht.
2. Der Schluß "funktioniert in x Browsern, also muss alles korrekt sein" ist falsch. Richtig wäre: "funktioniert in x Browsern NICHT, also KANN da was nicht korrekt sein".

 
piratos
30-12-2009, 17:13 
 
Das sehe ich anders , man kann es auch so sehen wie du würde dann aber nie zu Potte kommen:

Chrome no longer applies gzip filters to file names with gz/tgz/svgz extensions. (Issue: 8170)


und damit wären wir beim Bug.

 
wahsaga
30-12-2009, 17:20 
 
Wir reden doch hier über HTTP - also was soll das mit „file names” ...?

 
piratos
30-12-2009, 17:52 
 
Jede URL ist für einen Browser ein filename (was sonst) den er verarbeiten muss.
Chrome und Safari haben auf solche die gepackt sind einen Filter angewendet der dann die Sache zum crashen gebracht hat.

Was mich interessiert ist die Frage was diese Teildiskussion denn nun bezüglich Pagespeed und Yslow gebracht hat.
Ich meine nichts, da man das wegen der extrem kleinen Marktanteile von Chrome und Safari auch in den Papierkorb hätte schmeissen können.

Echte Pagespeed oder Yslow Fragen habe ich hier noch nicht gesehen, scheint ja allen klar zu sein was zu machen ist, damit wäre ich dann zufrieden.

 
wahsaga
30-12-2009, 17:55 
 
Jede URL ist für einen Browser ein filename (was sonst) den er verarbeiten muss.
:rolleyes:

/EOD

 
onemorenerd
30-12-2009, 22:54 
 
Es geht nicht um Safari und Chrome sondern Webkit (http://en.wikipedia.org/wiki/List_of_web_browsers#WebKit-based_browsers), vielleicht sogar KHTML und damit um so ziemlich alles außer Opera, Firefox und IE (http://en.wikipedia.org/wiki/Usage_share_of_web_browsers). Macht einen Marktanteil von circa 10 Prozent.

Über Pagespeed/Yslow gibt es nicht viel zu zu sagen. Man hat doch schon immer versucht, Webseiten möglichst schnell auszuliefern. Jetzt gibt es Tools, die einem zeigen wo man noch optimieren kann. Das ist keine große Sache.

Es lohnt sich viel mehr, über die konkreten Optimierungsmöglichkeiten zu sprechen. Kompression ist eine davon.

Kompression kann man in gängigen Webservern einfach zuschalten. Der Server komprimiert die Daten dann on-thy-fly beim Ausliefern. Damit er das nicht jedes mal erneut machen muss, kann man statische Dateien einmalig komprimieren. Aber dann muss man den Server auch so einstellen, dass er solche Dateien nicht erneut komprimiert und vor allem die richtigen HTTP-Header sendet.
Außerdem muss man zusätzlich die unkomprimierten Dateien vorhalten, falls ein Browser keine Komprimierung unterstützt.
Wenn man im Zuge der Performanceoptimierung auch einen Caching Proxy installiert, kann man den Webserver on-thy-fly komprimieren lassen und der Caching Proxy sorgt dafür, dass das nicht immer wieder geschehen muss.

 
piratos
31-12-2009, 12:08 
 
Man sollte sich davor hüten Browserbugs durch ständige Ausklammerung und Aktionen in seinen Scripten zu umgehen auch wenn man das könnte.
Bugs zu beseitigen ist immer eine Sache des eigentlichen Anbieters.
Es ist nicht die Aufgabe eines Webprogrammierers seine Ressourcen für diese Anbieter zu verschwenden um deren Bugs zu umgehen.

Es ist allein das Interesse des Browseranbieters mit seinem Produkt Marktanteile zu gewinnen und dann müssen die auch ran - so einfach ist es.

Man kann den am besten zu einer Korrektur zwingen wenn man das eben nicht macht und somit einen Anteil der User dieses Produktes dazu bringt zu meckern bzw. den Bug zu melden.
Kein User sieht Webkit der sieht Chrome oder Safari oder was auch immer und wird sich dann an seinen Anbieter halten.

Marktanteile werden zudem nicht nach der Verwendung von individuell geänderten Kits gemessen.

Die andere Seite der Medaille ist ständig Uraltbrowser unterstützen zu wollen nur weil die Netznutzer zu faul sind ein Update zu installieren (was auch aus Sicherheitsgründen äußerst bedenklich ist).

Auch da ist meine Meinung die - lasst diese Surfer in das Messer laufen.
Solange man darauf eingeht wird diese spezielle Gruppe nichts ändern, das machen sie erst dann wenn nichts mehr so richtig läuft.

über die konkreten Optimierungsmöglichkeiten zu sprechen. Kompression ist eine davon.

Das wäre der Ansatz - Kompression hilft ist aber bei vielen aber bei weitem nicht überall möglich, das ist das grundsätzliche Problem, wer kann sollte es machen.
(warum man hier allerdings Kompression nicht verwendet ??? )

Die nächste großartige Möglichkeit ist die einen Browsercache zu verwenden,wenn möglich .

Was jeder Webmaster machen kann ist und was sofort etwas bringt:

1. Backgroundimages in einem Sprite zusammenfassen.
2. die Regel "Use efficient CSSselectors" befolgen, das bringt richtig etwas
3. Keine CSS Elemente laden die man nicht benötigt
4. CSS vor JS laden
5. JS nach Möglichkeit in eine Datei fassen
6. JS nach Möglichkeit vor </body> laden und nicht im Meta - Teil
7. Alle Möglichkeiten prüfen um die Anzahl von HTTP Request's zu reduzieren
8. Abhängigkeiten von externen Inhaltseinbindungen auflösen, da man voll von denen abhängig wird.

Ich empfehle den FF mit Yslow und Pagespeed zu verwenden, Yslow ist die Sache für's grobe, Pagespeed für's feine.
Optimal dazu ist der DEV Teil vom Browser Chrome bei dem man an Hand der Timeline richtig gut sehen kann, wo das Rad gebremst wird.

Aber - man muss sich im klaren sein - alle Maßnahmen selbst wenn sie zu 100% Pagespeed und Yslow 100 sind liefern keine Garantie dafür das die Website Leistung laut Google Webmastertools besser als der Schnitt ist.

Sie helfen garantiert die Leistung zu verbessern, können aber die Generierungsprozesse langsamer Titel nicht ändern und sie können natürlich auch nicht lahmen Servern Flügel zu verleihen.
In der Praxis wird man allerdings eher auf lahme Generierungsprozesse stoßen als auf lahme Server.
In der Praxis werden die meisten Domains auf shared Webservern liegen, da besteht noch das Problem das man keine Ahnung hat wie der durch das Angebot und die Besucher der Nachbarn belastet werden - das kann enorm schwanken.

 
onemorenerd
31-12-2009, 14:18 
 
Man sollte sich davor hüten Browserbugs durch ständige Ausklammerung und Aktionen in seinen Scripten zu umgehen auch wenn man das könnte.
Bugs zu beseitigen ist immer eine Sache des eigentlichen Anbieters.
Es ist nicht die Aufgabe eines Webprogrammierers seine Ressourcen für diese Anbieter zu verschwenden um deren Bugs zu umgehen.
...
Die andere Seite der Medaille ist ständig Uraltbrowser unterstützen zu wollen nur weil die Netznutzer zu faul sind ein Update zu installieren (was auch aus Sicherheitsgründen äußerst bedenklich ist).

Selbstverständlich. Jeder vernünftige Mensch teilt diese Ansicht.
Aber in der Praxis steht im Anforderungskatalog, in welchen Browsern es laufen muss. Wenn ein Entwickler auf einen Browserbug stößt, muss er einen Workaround suchen. Er kann nicht einfach die Anforderung ignorieren, um so Druck auf den Browserhersteller auszuüben.

Wenn man sein eigenes Süppchen kocht, kann man so idealistisch sein.
Aber wenn man jemandem rechenschaftspflichtig ist, hat man nach seinen Anforderungen zu arbeiten. Die kann man bestenfalls mitbestimmen, aber am Ende zählt immer Wirtschaftlichkeit vor Idealismus.

 
unset
31-12-2009, 14:22 
 
The Guide is definitive. Reality is frequently inaccurate.

 
piratos
31-12-2009, 15:41 
 
Aber wenn man jemandem rechenschaftspflichtig ist, hat man nach seinen Anforderungen zu arbeiten.
Das ist eine andere Situation.
Ob das dann wirtschaftlich ist eine ganz andere Frage.
Man sollte lieber auf die Thematik zurück kommen.

Use efficient CSS selectors

Fast jeder kennt solche Konstruktionen wie diese hier:
ul.menu, ul.menu ul {
list-style-type:none;
margin: 0;
padding: 0;
width: 15em;

}


ul.menu a {
display: block;
text-decoration: none;
}


ul.menu li {
margin-top: 1px;
}


ul.menu li a {
background: #333;
color: #fff;
padding: 0.5em;
}


ul.menu li a:hover {
background: #000;
}


ul.menu li ul li a {
background: #ccc;
color: #000;
padding-left: 20px;
}


ul.menu li ul li a:hover {
background: #aaa;
border-left: 5px #000 solid;
padding-left: 15px;
}

das sind solch typischen CSS Konstruktionen für Menüs auf Listenbasis.

Diese CSS hat zwei Nachteile

1. schwer lesbar
2. extrem schlechte Effizienz

Eine Umsetzung nach den "Use efficient CSS selectors" - Regeln sieht so aus:

.menu{list-style-type:none;margin:0;padding:0;width:220px;}
.menu a{display:block;text-decoration:none;list-style-type:none;}
.menu-li{margin-top:1px;list-style-type:none;}
.menu-li-ul-li{margin-top:1px;list-style-type:none;}
.menu-li a{background:#9cc6ee;color:#000;padding:.75em;}
.menu-li a:hover{background:#fff;color:#a9121c;}
.menu-li-ul-li a{background:#d5f1fc;color:#000;padding-left:15px;}
.menu-li-ul-li a:hover{background:#fff;border-left:5px #a9121c
solid;padding-left:15px;}

Statt nun der CSS - Engine es zu überlassen die Regel zu finden reduziert sich der Einsatz mit der Übergabe eine simplen Klasse und damit reduziert sich der Zeitaufwand für das Rendern einer Seite deutlich sichtbar.

Solche verschachtelten Selektoren findet man eigentlich überall - da sollte man sich ran setzen und das zu einfachen Klassen machen - es wirkt.

 
unset
31-12-2009, 15:44 
 
Solche verschachtelten Selektoren findet man eigentlich überall
Weswegen es ja auch cascading style sheet heißt. Und das was du da beschreibst ist alles andere als Effizient: Du beschränkst die Klassen nicht auf bestimmte Elemente, der Rederer muss jede prüfen –*und lesbarer ist das nun wirklich nicht. Ich behaupte, oberes CSS ist wesentlich schneller, besser zu lesen –*und einfach richtig!

 
piratos
31-12-2009, 15:52 
 
Weswegen es ja auch cascading style sheet heißt. Ja klar aber die Frage ist Speed und Effizienz und das sind die verschachtelten eben nicht - darum geht es.

Und wenn man z.B. mal ein Menü umgesetzt hat sieht man es auch deutlich und sofort.

Ich hatte ja schon mal darauf hin gewiesen das "altbackene" Webmaster mit den Anforderungen so ihre "Problemchen" bekommen werden und tatsächlich muss man so ein paar "Kröten" schlucken, wenn man mit machen will (damit will ich nicht sagen das du ein"Altbackener" bist).

 
wahsaga
31-12-2009, 15:54 
 
Und wenn man z.B. mal ein Menü umgesetzt hat sieht man es auch deutlich und sofort.
Die Frage ist - wo sieht man das?

Als Besucher der Seite? Bei einer durchschnittlichen Seite bezweifle ich das eher.

Oder in irgendeinem der Tools, die Effizienz „messen”? Das ist fein, aber eigentlich total egal, wenn's der Besucher nicht wirklich mitbekommt.

 
unset
31-12-2009, 15:57 
 
Ich merke davon –*ohne zu messen –*nichts. Und wenn ich mit bloßem Auge nichts erkennen kann, dann ist es auch irrelevant. Halte ich darüber hinaus für Micro-Optimierung, und die hat sich –*was Webentwicklung angeht –*noch nie ausgezahlt.

Edit: wahsaga war schneller.

Edit2: Statt "altbacken" und "Problemchen" solltest du lieber mal "Anforderungen" in Anführungszeichen setzen. Denn wer fordert das ganze eigentlich? Google? Yahoo? Der liebe Gott? Du? Und ja, ich habe keinen Bock mich für so einen Hokuspokus durch den ganzen Thread zu ackern!

 
TobiaZ
31-12-2009, 16:09 
 
Sehe ich auch so. Ist einfach ein Unterschied zwischen dem was möglich ist und dem was für die Praxis relevant ist.

Wer zeit zum Spielen hat, naja soll er halt tun, das Wetter ist ja heut sowieos nicht so toll. :)

 
onemorenerd
31-12-2009, 16:14 
 
Schwer lesbar finde ich eher das reduzierte CSS und das nicht nur wegen der fehlenden Whitespaces.

Das Beispiel zeigt zwar schön, was gemeint ist und wie sich der Datenumfang reduziert. Aber was der Laie nicht sieht und was man deshalb mal erwähnen sollte: Die Semantik des reduzierten CSS unterscheidet sich signifikant! Das ursprüngliche CSS läßt sich nur auf DOM-Elemente in einer vorgegebenen Struktur anwenden.

Als Beispiel nehme ich mal den Selektor "ul.menu li ul li a". Der kann nur auf A-Tags angewendet werden, die Kind eines LI sind, das wiederum Kind einer UL ist, die Kind eines LI ist, die Kind einer UL mit der Klasse menu ist.
Im Vergleich dazu passt der Selektor ".menu-li-ul-li a" zu allen As, die Kind eines beliebigen Elements mit der Klasse menu-li-ul-li sind.

Mit derart reduziertem CSS ist es also möglich, Auszeichnungen für Elemente zu verwenden, für die sie nicht gedacht sind. Nicht nur möglich, sondern sogar naheliegend, würde doch das hinzufügen einer weiteren Deklaration mit der selben Wirkung das CSS unnötig aufblähen.
Der Programmierer wird sozusagen dazu verleitet, Deklarationen in Stellen zu verwenden, für die sie nicht gedacht waren. Weils halt grad passt.
Dumm nur, wenn später das Design von Links in verschachtelten Listen geändert werden soll. Man kann nicht dafür garantieren, dass sich dadurch nicht auch Links an anderer Stelle ändern.
Derlei reduziertes CSS zwingt also alle Entwickler, sich an die Konvention zu halten, CSS-Auszeichnungen nur auf Elemente anzuwenden, die man am Selektor ablesen kann. Bei nicht-reduziertem CSS wird das durch den Selektor selbst sichergestellt.

Kurzum: Diese Reduzierung beschneidet CSS um eines seiner Features, ist deswegen semantisch schwächer und zwingt zu bestimmten Konventionen.
Jeder muss selbst entscheiden, ob der Performancegewinn die Sache wert ist.


Übrigens hätte ich als Beispiel leiber den Selektor ".menu-li-ul-li" genommen, doch der hat gar keine Entsprechung im Original-CSS. ;)

 
piratos
31-12-2009, 16:56 
 
Sehen kann man es deutlich, wenn der Umfang ein normaler ist, ob man nun daran zweifelt oder nicht.
Messen kann man es auch.
Und - es ist auch eine Maßnahme von vielen die insgesamt echten Speed ausmachen.

Wer nicht mit machen will der lässt es sein, es zwingt ihn ja niemand.

Es geht auch gar nicht mehr um die Diskussion von für und wieder oder wenn und aber bei z.B. komplexen Selektoraufbau oder simple Klasse, denn das ist von Google und wie auch Yahoo in deren Labs längst probiert und bewertet worden (und es hat sich in Patenten bemerkbar gemacht), es geht schlicht darum wie man es macht.

Wer Interesse hat ein paar Punkte in der künftig von Google für 2010 geplanten Speedbewertung innerhalb der Trefferliste ergattern zu wollen oder auch nur um seinen Besuchern eine flottere Seite zu präsentieren, der macht es.

Diejenigen die da nichts dran machen wollen die lassen es ganz einfach.

Diejenigen die nicht verstehen wie man das im Detail macht die sollten ihre Fragen stellen.


Bei mir habe ich das durchgezogen und das Web ist radikal schneller geworden (und auch bewertet Pagespeed 100% - mehr nicht möglich, Yslow 100 - mehr nicht möglich , Aufwand eher gering, optische Veränderungen im Web Null, Google Webmastertools, Webseite-Leistung nun bei 98% aller von Google erfassten Webs (wobei der Satz weiter runter gehen wird, je mehr Leute das machen)).

Und - ich bin da garantiert nicht der erste und er einzige der das bemerkt hat, das es funzt.

 
onemorenerd
31-12-2009, 17:54 
 
Was für Patente sollen das sein? Imho ist das keine schützbare Idee, denn die CSS-Spezifikation gibt es eben her. Dass es weniger zu übertragende Daten bedeutet, ist nur ein Effekt der Idee und dass es in gängigen Browsern schneller gerendert wird, kann sich wenn überhaupt nur ein Browserhersteller patentieren lassen (genauer gesagt die Art, wie er das schafft). Hast du Links zu den Patenten?

Übrigens rendern Browser solch "flaches" CSS schneller, weil sie einerseits den CSS-Selektorenbaum schneller aufbauen können (klar, der ist eben flacher), weil es sich in einem flachen Baum schneller suchen lässt und der Suchvorgang ohne tiefe Prüfungen im DOM-Baum auskommt.

Wenn man diesen Gedanken weiter denkt, sollte man CSS-Deklarationen, die nur einmal verwendet werden, direkt inline am Element notieren. Außerdem sollte man den DOM-Baum ebenfalls so flach wie möglich halten.
Wendet man dieses Sparsamkeitsprinzip auch auf JS an, stellt sich schnell die Frage, ob man überhaupt Frameworks verwenden sollte bzw. ab wann das sinnvoller ist als rein handgeklöppelter Code.

Alles in allem sind die Optimierungsansätze, die sich direkt auf die Struktur des Codes und/oder die Arbeitsweise und Flexibilität beim Programmieren auswirken immer mit Vorsicht zu genießen. Ich würde bei Applikationen und Teams ab einer gewissen Größe und Komplexität lieber auf solche Optimierungen verzichten und den Leistungsschub durch Hardware und Setup holen (CDN, Load Balancer, Caches, ...). Wenn eine Applikation bis zum Gehtnichtmehr auf Speed getrimmt ist, kann man an ihr meist kaum mehr vernünftig arbeiten.

Als Beispiel sei hier noch einmal die CSS-Optimierung angeführt. Ich kenne keine Tools, die CSS und das zugehörige HTML derart umstricken können. Gäbe es so ein Tool, könnte man es in den Build-Prozess integrieren. Die Entwickler könnten "sauber" arbeiten und die Seite wäre trotzdem flott.
Ohne solch ein Tool wird entweder die Arbeit zur Qual oder man geht vorm Deployment per Hand drüber. Beides kostet Zeit und damit Geld, das man ab einer gewissen Projektgröße auch gleich für Hardware ausgeben kann.

Alles hat ein Pro und Kontra. Wer einfach nur macht was ein Tool rät, denkt zu kurz. Es gilt nicht nur Transfer- und Renderzeiten zu verkürzen, sondern das kosteneffizient zu machen.


Nachtrag: Imo wird mit diesem Pagespeed-Hype gerade mal wieder eine Sau durchs Dorf getrieben. Google mit seinen weltweit verteilten Datacenters und viel eigener Infrastruktur ist schneller als alle anderen. Von diesem hohen Ross herab möchten sie nun "das Web schneller machen". For what? Why now?
Sind die eigentlich an User Experience interessiert oder wollen sie nur den Googlebot entlasten?
</polemik>

 
unset
31-12-2009, 17:59 
 
Ich würde bei Applikationen und Teams ab einer gewissen Größe und Komplexität lieber auf solche Optimierungen verzichten und den Leistungsschub durch Hardware und Setup holen (CDN, Load Balancer, Caches, ...).
Genau so ist es. Ich hab es schon mehrfach gesagt und ich kann es nur immer Wiederholen: RAM kostet weniger als ein Entwickler. Das passt hier jetzt nicht wie Arsch auf Eimer, aber die Grundaussage bleibt die gleiche. Code muss wartbar sein, dann kommt erst mal lange nix.

 
piratos
31-12-2009, 19:27 
 
PatenteMal ein wenig lesen da gibt es einen Link.
Leistungsschub durch Hardware und Setup holen RAM kostet weniger als ein EntwicklerTolle Hardware ist immer gut, aber leider hat hier wohl niemand den Sinn und Zweck so richtig verstanden mit Sicherheit auch nicht die Hintergründe, ja ich würde sogar sagen, die meisten haben es noch nicht einmal probiert, reden auf blauen Dunst hin.

Sagen wir es einmal anders - eine Webseite die unter in 0,03s dynamisch erstellt wird, hat ohne jegliche Maßnahmen eine Renderzeit von 0,6 Sekunden, d.h sie liegt dann fix und fertig beim Besucher vor.

Eine Website die in 0,03s dynamisch erstellt wird liegt in dem Bereich 0,04s bis 0,23 Sekunden komplett gerendert vor, wenn alle Maßnahmen ergriffen sind - das sind gemessene Zeiten.
Die Schwankungen ergeben sich aus den unterschiedlichen Situationen (z.B. bereits gecachter Teil oder nicht).

Nach Pagespeed und Yslow behandelte Webs sind nachweisbar um ein vielfaches schneller als unbehandelte - genau um darum geht es.

Das bedeutet aber auch - tolle Hardware hin und her - sie würde hier nichts ändern.

Es kann auch nichts ändern da sämtliche Zeiten die nach der Generierung auftreten die gleichen bleiben, wenn man sein Web nicht mit diesen Methoden behandelt.

Diese Zeiten danach sind ein vielfaches von dem was eine Hardware - egal wie toll - benötigt um die Seite zu generieren.

 
onemorenerd
31-12-2009, 19:41 
 
Dass man mit Serverhardware die Zeit fürs Rendering nicht beeinflussen kann, ist wohl jedem hier klar. Sehr wohl aber kann man die Zeit vom Abschicken des Requests bis zur fertig gerenderten Seite verringern, indem man mit Hardware und Setup die Zeitspanne minimiert, die serverseitig verbraten wird oder die Anzahl der Requests, die tatsächlich bis zum Server durchschlagen.

Ich hab schon verstanden, dass du gerade nur über die Zeit zum Rendern sprechen willst. Aber warum sollen wir uns darauf beschränken? Deine Tools messen doch auch nicht nur die Zeit vom letzten empfangenen Byte bis zum DocumentReady. Deren Uhr beginnt zu ticken, wenn der Request raus geht.

Meinetwegen kannst du weiter über Einzelheiten sprechen. Hat aber nicht viel Sinn, solange keiner mitredet. :p

- -

Alle Zeitangaben in WEZ +2. Es ist jetzt 11:25 Uhr.