Hallo Mathias!

<!--[if lt IE 9]>
<script>
'abbr article aside audio canvas details figcaption figure footer header main mark meter nav output progress section summary time video'.replace(/\w+/g,function(n){document.createElement(n)})
</script>
<![endif]-->

Ich weiß jetzt nicht, ob da sämtliche aktuellen und von dir verwendeten HTML5-Elemente drin sind. Dieses Script ermöglicht alten IEs, die besagten Tags korrekt in Elemente zu parsen – nicht mehr und nicht weniger.

Der aktuelle HTML5-Shiv geht da viel weiter und fixt auch gleich document.createElement, innerHTML usw. Es gibt einen zusätzlichen Print-Shiv. Siehe auch History of the HTML5 shiv.

Ob du das brauchst, musst du wissen. Ich brauche es i.d.R. nicht. jQuery bringt den innerShiv bereits mit sich, d.h. $('<section>') und $(…).html('<section>…</section>') funktioniert auch in älteren IEs.

Den Teil brauche ich nicht.
Und ich nutze den Conditional Comment, um einal jQuery 1.9.1 und einmal 2.0.0 zu laden.

Modernizr benutze ich ebenfalls i.d.R. nicht. Es ist lediglich eine Bibliothek für Feature-Abfragen. Wenn ich eine brauche, so entnehme ich Modernizr diese eine Zeile Code.

Ja, davon brauche ich aber eine ganze Menge.
Aber wenn ich dich richtig verstanden habe, dann macht es (mehr) Sinn, diesen Part auch eher ans Ende zu setzen, richtig?

Worum es mir u.a. geht, ist ja die Frage, ob die Vorteile der Nutzung eines CDN die Nachteile überwiegen?

Das kommt ganz darauf an, was die Umstände und Ziele sind. CDNs sind sinnvoll, wenn die Besucher über der Welt verstreut sind, Lastspitzen abgefangen werden müssen oder Traffic verbilligt werden soll. Wenn der Server z.B. in DE steht, so wird die Seite für US-Besucher höchstwahrscheinlich signifikant schneller geladen, wenn jQuery von einem CDN eingebunden wird. jQuery kostenlos von einem freien CDN einzubinden reduziert auch deinen Traffic.

Jetzt kommen wir der Sache schon näher ...! ;-)
Die Website wird hauptsächlich aus Deutschland besucht, der Server steht ebenfalls in Deutschland und der Traffic spielt keine Rolle.

Spricht also alles eher dafür,_kein_CDN zu verwenden und lieber alles in eine Datei zu packen, um Requests einzusparen.

Das ist doch mehr oder weniger von jeweiligen konkreten Fall abhängig, oder nicht?

Ja, definitiv. Du musst auf deiner konkreten Seite Performance-Daten sammeln. webpagetest.org und z.B. die Ladezeitmessung von Google Analytics können hier Aufschlüsse geben.

Na dann werde ich mir mal angucken, was GA so sagt nach einer gewissen Zeit.

Wirkt sich ein Request nicht bspw. bei einer "lahmen" GPRS Verbindung anders aus, als bei einer "schnellen" DSL Verbindung?

Ja, entscheidend ist hier die Latenz, nicht die bloße Geschwindigkeit. Bei Mobilzugängen sind i.d.R. wenige große HTTP-Requests von wenigen Domains besser als viele kleine von mehreren Domains. Manche gehen sogar soweit, CSS und JavaScript ins HTML einzubetten. Bei Breitbandzugängen mit geringer Latenz kann man eher parallele Requests von verschiedenen Domains öffnen, um Assets parallel zu laden.

Danke, Latenz war der Begriff, der mir eben nicht eingefallen ist ... ;-)

Und wenn Techniken wie SPDY dann mal mehr oder weniger "flächendeckend" zum Einsatz kommen, wie wirkt sich das dann ggf. auf die "Wahl der Variante" aus?

Das weiß ich nicht, denn aktuell spielt das m.W. noch keine Rolle.

Mehr Geschwindigkeit durch Datenkomprimierung

Vielen Dank für deine gewohnt kompetenten Ausführungen. Mich interessiert halt auch immer die Meinung, bzw. Ansichten von anderen Leuten. Oftmals "übersieht" man ja auch gerne mal etwas, oder bewertet eine Sache falsch.

Und nebenbei bemerkt reden wir hier nicht von einer "high traffic" Website. Die einzelnen Seiten haben im Schnitt max. 10 Requests und ein (komprimiertes) Volumen von deutlich unter 500 KB.

Aber trotzdem muss man ja nicht unnötig die Performance für den User verschlechtern ...!

Gruß Gunther