Ich habe mich mit dem Thema intensiv auseinandergesetzt (und unter anderem das Referenzwerk gelesen: High Performance Websites - http://tinyurl.com... ) und entsprechend eine dezidierte Meinung:

1) Schnelle Ladezeiten sind äußerst wichtig und - wie in allen von dir verlinkten Artikeln postuliert - auch auf Teufel komm raus anzustreben.
2) Die Zeitangaben sind nicht besonders realistisch, wenn die Site einigermaßen umfangreich ist und kein sechsstelliges Budget hinter der Site steckt. Das hängt zusammen mit folgenden Punkten:
---- Ein CDN (Content Delivery Network) kann man sich nur leisten, wenn man Kohle und Manpower hat, das umzusetzen. Braucht man aber, um wirklich konkurrenzfähige Speeds erzeugen zu können.
---- Die Einbindung von Fremdskripten hat massive Auswirkungen auf die Ladezeiten: Google Analytics, Adsense, Plus-Button, DFP; Facebook Likebox, Like-Button, Login; Twitterstream etc. - das sind extreme Performance-Killer, nicht nur weil sie ihre Zeit brauchen und Request erzeugen, sondern auch weil sie gegen elementare Regeln verstoßen (z.B. Bilder nur mit Spezifikation der Dimensionen auszuliefern - macht die Facebook-Likebox nicht; damit hast du gleich mal 3 oder 6 Gesichtsbildchen + Miniaturbild, deren Größe im Browser berechnet werden muss). Ich verweise hierauf: http://schnellze.it...
Natürlich müssen auch große Player solchen Kram einbinden; sie können aber wesentlich sparsamer damit umgehen, evtl. Sonderdeals schließen (ist jetzt nur eine Vermutung) - und haben natürlich ganz andere Partner aus der Oberliga. Adsense wird man auf den Top-10-Sites kaum finden, auch keine 08-15-Skript-Adserver usw.

Die Beispiele sind nicht wirklich realistisch, weil viel zu minimalistisch. Nielsens http://www.useit.com... lädt natürlich schnell, auch die von dir zitierte Some Random Dude ( http://somerandomdude.com... ). Letztere lädt wirklich atemberaubend schnell, hat aber auch fast keine Bilder. Er hat sich auch irrsinnig ins Zeug gelegt, was die Frontendoptimierung betrifft (Pagespeed-/YSlow-Report zu Some Random Dude bei GTmetrix: http://gtmetrix.com... ). Übrigens: Je kleiner die Site, desto einfacher (und billiger - siehe oben) die Optimierung.

Das Tool der Wahl ist - ich erwähnte es schon - GTmetrix: http://gtmetrix.com... - hat auch ein geiles Bookmarklet, da klickst du drauf und er analysiert die aktuelle Seite.

Wir schneiden übrigens - immerhin völlig unoptimiert - nicht so gut ab ( http://gtmetrix.com... ):

> Keep-Alive ist im Shared Hosting nicht sinnvoll einsetzbar.

Aus Sicht der Hoster!
Ein Vertreter von Alfahosting sagt das explizit so ( https://forum.alfahosting.de... ):



Das interpretiere ich so: Wenn wir dir keep-alive gönnen, können wir weniger Kunden auf einen Server stopfen. Und natürlich geht die Bandweite runter, wenn 1000e offene Verbindungen rumhängen.

Wenn du in deine (aschlemmer.net) Header schaust, siehst du, dass dein Server die Verbindung nach jedem Objekt schließt (Connection: close).

Nils Dornblut schreibt in dem df-Blogbeitrag: "Außerdem bringt es [keep-alive] nur minimale Verbesserungen in bestimmten Anwendungsfällen." Ich habe keinen Zweifel, dass er sich wesentlich besser in der Materie auskennt als ich. Aber ich weiß auch, dass keep-alive höchst wichtig ist, weil es den Overhead massiv reduziert. Wenn die Verbindung nach jedem geholten Objekt geschlossen wird, musst du sie für jedes Objekt neu aufbauen, und das kostet jedes Mal einen HTTP-Request + Antwort. Nicht umsonst ist DER zentrale Punkt der Frontendoptimierung die Reduzierung der HTTP-Anfragen.

Ich finde, abseits aller Details, dass es grundsätzlich einmal wichtig ist zu kapieren, dass Frontendoptimierung in vielen (den allermeisten?) Fällen wichtiger ist als Serverpower. Schau gleich aus dem ersten Kommentar zu deinem df-Interview-Link:



Die Frontend-Dimension wird als "sowie" erwähnt.

Was DEINEN LADEZEITENTEST angeht: Ich finde ihn sehr interessant. Meine Anmerkungen dazu:

Schick mir gerne mal die Site, dann lade ich sie hoch und schicke dir den Link, dann kannst du vergleichen. (Oder ich gebe dir die FTP-Zugangsdaten, dann kannst du da selber immer die aktuelle hochladen). Dann siehst du genau, wie sehr die Performance von der Hardware/Anbindung abhängt.

Ich minifye CSS und JS mit einem Expressionengine-Plugin. Das kombiniert übrigens gleich noch mehrere JS und CSS zu jeweils einem. HTML minifye ich aus diversen Gründen nicht, das halte ich aber auch für eher zweitrangig. Vielleicht gibt's für dein CMS ein Plugin? Wordpress z.B. "WP Minify" ( http://www.manuel-evers.de... ), keine Ahnung, ob das was taugt. Dann gibt's noch einen Trick mit Plugin-Code, den man an das WP-Template hängt: http://www.intert3chmedia.net...

Es gibt auch Apps ( http://smallerapp.com... sieht gut aus, aber kostenpflichtig ) und online-Tools wie das von dir erwähnte.

Ich würde das nicht zu hoch hängen. Sehr sinnvoll ist es sicher, aus mehreren JS/CSS-Dateien jeweils eine zu machen (Anzahl HTTP-Requests minimieren). Die Kommentare … nun ja. Du überträgst dann halt 20 Bytes zu viel. Die kannst du lieber durch ein um eine Stufe mehr komprimiertes Headerbild rauspressen.

Sobald du Objekte in deine Seite einbaust, wird PageSpeed aber rumheulen, denn dann entstehen neue, vermeidbare HTTP-Requests. Was einen richtigen Wums bringt, ist eine ordentliche htaccess-Konfiguration. Die relevanten Passagen bei meiner aktuell:

Hab mal das Datum adjustiert, dass dieser aktuelle Thread oben ist.
Code-Tags funktionieren noch nicht so gut, Zusendung des htaccess-Codes kann jeder gerne bei mir beantragen :)