nicht angemeldet
jQuery & Co. CDN vs. local file
Gunnar BittersmannHallo werte Selfgemeinde,
ich denke gerade über die jeweiligen Vor- & Nachteile der im Titel genannten Varianten nach, und würde gerne mal eure geschätzte Meinung, bzw. Vorgehensweise dazu hören - danke!
Einer der wohl unbestrittenen Grundsätze ist ja der, dass man die Anzahl der HTTP Requests einer Seite möglichst gering halten sollte.
Nun verwende ich auf meiner Site
- jQuery (2.0.0 / 1.9.1)
- Modernizr
- eigenes JS Skript
Hinzukommt noch der unterschiedliche "Ladezeitpunkt" der einzelnen Dateien/ Skripte/ Bibliotheken.
So wird ja "allgemein" empfohlen, die Javascript Dateien erst nach dem eigentlichen Seiteninhalt (also am Ende der jeweiligen Seite) zu laden, mit der Ausnahme von Modernizr, welches man bereits im <head> einbinden soll.
Ergo stehen einem jetzt quasi folgende Optionen zur Auswahl:
1. alle Dateien in eine "große" zusammenpacken (und dann an welcher Stelle einbinden?)
2. Modernizr im Head einbinden und alles anderen zusammenpacken und am Ende einbinden
Jetzt kommt aber noch ein weiterer Aspekt mit ins Spiel, und zwar der des CDN.
Für jQuery gibt es da ja gleich mehrere, wohingegen das für Modernizr nicht in Frage kommt.
Daraus folgert für mich eigentlich schon mal die Entscheidung, dass ich Modernizr einzeln im Head-Bereich (lokal) einbinde.
Jetzt könnte man aber immer noch zumindest einen Request einsparen, wenn man jQuery zusammen mit seinem eigenen JS in eine Datei packen würde.
Die Frage ist also: Was ist "vorteilhafter" - ein zusätzlicher Request (pro Seite) oder einmal die ca. 32 KB an mehr zu übertragenden Daten?
Mir geht es hier nicht darum, ob die eine oder Variante jetzt im Endeffekt vielleicht 1/10 Sekunde schneller ist oder nicht, sondern vielmehr um die "grundsätzliche" Frage, welche Variante quasi am "universellsten" einsetzbar ist. Vor- und Nachteile haben sie ja alle, ansonsten würden sich die Fragen ja gar nicht stellen.
Gruß Gunther
-
Hallo,
Daraus folgert für mich eigentlich schon mal die Entscheidung, dass ich Modernizr einzeln im Head-Bereich (lokal) einbinde.
Modernizr als externe JavaScript-Library ist ein großes Stück Code, das an dieser Stelle nicht geladen werden muss. Was vor dem body geladen werden muss, ist bloß der HTML5-Shim, Teil des Modernizrs. Diesen würde ich verknappen und als Inline-Script einbetten, damit kein blockender Request gemacht wird.
Mir geht es hier nicht darum, ob die eine oder Variante jetzt im Endeffekt vielleicht 1/10 Sekunde schneller ist oder nicht
Ähm, nicht? Wieso sollte man jQuery sonst von einem CDN laden? Um Traffic zu sparen?
sondern vielmehr um die "grundsätzliche" Frage, welche Variante quasi am "universellsten" einsetzbar ist.
Über die Performance kann man konkret diskutieren und auch Daten sammeln – aber was meinst du mit »universell einsetzbar«?
Mathias
-
Hallo Mathias!
Daraus folgert für mich eigentlich schon mal die Entscheidung, dass ich Modernizr einzeln im Head-Bereich (lokal) einbinde.
Modernizr als externe JavaScript-Library ist ein großes Stück Code, das an dieser Stelle nicht geladen werden muss. Was vor dem body geladen werden muss, ist bloß der HTML5-Shim, Teil des Modernizrs. Diesen würde ich verknappen und als Inline-Script einbetten, damit kein blockender Request gemacht wird.
Aaahhh ..., klingt sehr interessant (und vernünftig).
Über diese "Variante" bin ich bei meinen Recherchen noch gar nicht gestolpert ...! ;-)Du hast nicht "zufällig" den "verknappten Teil" irgendwo *in der Schublade* rumfliegen ...?
Mir geht es hier nicht darum, ob die eine oder Variante jetzt im Endeffekt vielleicht 1/10 Sekunde schneller ist oder nicht
Ähm, nicht? Wieso sollte man jQuery sonst von einem CDN laden? Um Traffic zu sparen?
sondern vielmehr um die "grundsätzliche" Frage, welche Variante quasi am "universellsten" einsetzbar ist.
Über die Performance kann man konkret diskutieren und auch Daten sammeln – aber was meinst du mit »universell einsetzbar«?
Ja, war vielleicht nicht ganz so "ideal" formuliert - ist aber auch gar nicht so einfach ...!
Also vergessen wir mal das mit dem "universell".
Worum es mir u.a. geht, ist ja die Frage, ob die Vorteile der Nutzung eines CDN die Nachteile überwiegen?
Alleine schon die Versionsvielfalt bei jQuery macht es zumindest im Laufe der Zeit immer "unwahrscheinlicher", dass der entsprechende User das Skript bereits in seinem Browsercache hat. Und wie wirkt sich dieser Request in der Praxis aus? Denn auch wenn die Datei bereits vorhanden ist, so muss ja doch jedes Mal ein Request gesendet werden.
Mir ist aber bspw. nicht ganz klar, wie man
Über die Performance kann man konkret diskutieren und auch Daten sammeln
können soll!?
Das ist doch mehr oder weniger von jeweiligen konkreten Fall abhängig, oder nicht?
Wirkt sich ein Request nicht bspw. bei einer "lahmen" GPRS Verbindung anders aus, als bei einer "schnellen" DSL Verbindung (mal von den ganzen anderen Faktoren wie z.B. dem Server mal abgesehen)? 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?Gruß Gunther
-
Hallo,
Du hast nicht "zufällig" den "verknappten Teil" irgendwo *in der Schublade* rumfliegen ...?
Naja, der einfachste HTML5-Shiv ist bekanntlich:
<!--[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.
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.
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.
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.
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.
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.
Mathias
-
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
-
@@molily:
nuqneH
Modernizr benutze ich ebenfalls i.d.R. nicht. Es ist lediglich eine Bibliothek für Feature-Abfragen.
Etwas mehr. Modernizr bringt einen Lazy-Loader mit. Und Yepnope.
Wenn ich eine brauche, so entnehme ich Modernizr diese eine Zeile Code.
Man kann (lies: sollte) Modernizr customizen, d.h. nur die Features in den Code einbinden, die man braucht.
Dasselbe gilt für jQuery 2.
Qapla'
--
„Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)-
Etwas mehr. Modernizr bringt einen Lazy-Loader mit. Und Yepnope.
Stimmt. Wobei Modernizr.load() ja nichts anderes als Yepnope ist.
Weil Modernizr verschiedene Scripte vereinigt, weiß meinem Eindruck nach niemand, was es wirklich ist. Viele glauben, es sei ein Über-Shim für alles mögliche. Dabei ist es mehr ein Werkzeugkasten für den Umgang mit Browserunterschieden: Feature-Abfragen, bedingtes Laden von Shims und eben der HTML5-Shim fürs Parsing und createElement/innerHTML. Mit Yepnope hat man sogar einen allgemein nutzbaren Script- und CSS-Loader.
Man kann (lies: sollte) Modernizr customizen, d.h. nur die Features in den Code einbinden, die man braucht.
Ja, nur bedarf es dazu genauen Wissens darüber, was die Teile von Modernizr tun und mitunter wie der HTML5Shim funktioniert.
Meiner Erfahrung nach ist selbst ein eigens konfigurierter Modernizr zumeist unnötige Komplexität.
Dasselbe gilt für jQuery 2.
Das Problem ist, dass es mangels vernünftiger Modularisierung (d.h. explizites Deklarieren von Dependencies) schwer herauszufinden ist, welche Features »man« braucht.
Herauszufinden, welche jQuery-Features ein jQuery-Plugin benötigt, ist bei entsprechender Komplexität quasi unmöglich. Man kann nur so lange jQuery-Module aktivieren, bis es keine »undefined is not a function«-Exceptions im Produktivbetrieb mehr gibt.
Mathias
-
-
-
-
-
Moin,
Mir geht es hier nicht darum, ob die eine oder Variante jetzt im Endeffekt vielleicht 1/10 Sekunde schneller ist oder nicht, sondern vielmehr um die "grundsätzliche" Frage, welche Variante quasi am "universellsten" einsetzbar ist. Vor- und Nachteile haben sie ja alle, ansonsten würden sich die Fragen ja gar nicht stellen.
Es gibt keine universelle Variante, wie oder wann man Skripte einbindet.
1. Skripte dort einbinden, wo und wann du sie benötigst bzw. die Skripte es erfordern.
2. Skripte "zusammenfassen", um Requests zu sparen, ist erstmal gut.
3. Skripte können sich gegenseitig beeinflussen, der Zeitpunkt des Einbindens kann hierbei eine Rolle spielen.Die Empfehlung, Skripte am Ende der Seite einzubinden, rührt ja daher, dass der Browser schonmal mit der Darstellung zwischendurch anfangen kann, da Skripte das Parsen unterbrechen, bislang. Irgendwann hat man ja das defer-Attribut eingeführt, um Skripte asynchron zu laden.
CDN gibt es auch nicht nur Zwecks Latenzen sondern auch in Hinblick der Verfügbarkeit und Sharings bzw. Zwischenspeicherung gemeinsamer Daten. Puffer sind allgemein gut, was die Performance anbelangt. Sie können aber auch negativ wirken, wenn dem Quellursprung clientseitig gar nicht vertraut wird, und somit das Laden verhindert wird.
-
Moin,
Jetzt kommt aber noch ein weiterer Aspekt mit ins Spiel, und zwar der des CDN.
Für jQuery gibt es da ja gleich mehrere, wohingegen das für Modernizr nicht in Frage kommt.
Wie sieht es denn eigentlich mit dem Datenschutz bei der Verwendung von CDNs (und diverser „Cloud“-Anbieter) aus? Das ist doch auch noch ein wichtiger Aspekt.
Viele Grüße,
Robert -
Hallo werte Selfgemeinde,
vielen Dank für eure hilfreichen Tipps, Anregungen und Meinungen. :-)
Auch Roberts Einwand bezüglich des Datenschutzes finde ich sehr wichtig (zumindest für gewerbliche Seiten) - da rollt bestimmt wieder eine Abmahnwelle durchs Land, wenn der erste RA erst mal dahintergekommen ist.
Ich habe mich jetzt erstmal gegen ein CDN, und stattdessen für folgende Variante entschieden:
- jQuery
- Modernizr
- eigenes Skript
alle minified in_eine_Datei gepackt (das macht nebenbei bemerkt mein Server) und wie folgt im <head> eingebunden:
<script> var js = document.createElement("script"); js.src = "js-files/js-scripts.min.js"; var head = document.getElementsByTagName("head")[0]; head.appendChild(js); </script>Dadurch hat das Skript keine blockende Wirkung und da alles in einer Datei steht, gibt es auch keine Probleme bezüglich Abhängigkeiten.
Hat diese Methode sonst irgendwelche "Nebenwirkungen", die mir entgangen sind?
Gruß Gunther
-
alle minified in_eine_Datei gepackt (das macht nebenbei bemerkt mein Server) und wie folgt im <head> eingebunden:
Warum nicht einfach vor </body>? »Put stylesheets at the top, scripts at the bottom« gilt immer noch. Ein asynchrones Laden ist dann nicht nötig, weil der Seiteninhalt schon übertragen wurde.
Hat diese Methode sonst irgendwelche "Nebenwirkungen", die mir entgangen sind?
Nö, das wird ja millionenfach so gemacht.
Habe ich schon von dem Speed Index erzählt? Das ist meiner Meinung nach der sinnvollste allgemeine Index zur Messung von Website-Performance. Er drückt aus, wie schnell sich die Site visuell aufbaut. Messen lässt sich das mit WebPagetest.
Mathias
-
Hi Mathias!
Habe ich schon von dem Speed Index erzählt? Das ist meiner Meinung nach der sinnvollste allgemeine Index zur Messung von Website-Performance. Er drückt aus, wie schnell sich die Site visuell aufbaut. Messen lässt sich das mit WebPagetest.
Oder auch nicht ...! ;-)
Ergebnis: "The test completed but there were no successful results."Zweimal probiert, beide Male mit demselben Ergebnis => nicht zu gebrauchen.
Und wenn ich die Geschichte mit dem 'Speed Index' richtig verstanden habe, dann ist der ja sowieso vom jeweiligen System, dessen Anbindung, Performance und dem verwendeten Browser abhängig.
Alles Dinge, die nicht mehr im Einflussbereich des Autors liegen, und somit imho mehr oder weniger irrelevant. Man kann sich ja schließlich im Prinzip nur für eine "allgemeine Variante" entscheiden, die für die zu erwartende Mehrheit der Besucher das Optimum darstellen sollte.
Google ist ja auch gerade dabei einen neuen "Hype" auszulösen mit ihrem PageSpeed Insights.
Gruß Gunther
-
Ergebnis: "The test completed but there were no successful results."
Zweimal probiert, beide Male mit demselben Ergebnis => nicht zu gebrauchen.
Dann machst du etwas falsch. Oder der Service hat irgendwelche Probleme. Das kommt vor bei dutzenden Testservern mit jeweils einer Handvoll Browsern. Das ändert nichts daran, dass WebPagetest das beste (kostenlose) Tool weit und breit ist.
Und wenn ich die Geschichte mit dem 'Speed Index' richtig verstanden habe, dann ist der ja sowieso vom jeweiligen System, dessen Anbindung, Performance und dem verwendeten Browser abhängig.
Ja, wie jeder normale Besuche auf deiner Seite auch. Deshalb kannst diese Parameter bei WebPagetest einstellen.
Alles Dinge, die nicht mehr im Einflussbereich des Autors liegen, und somit imho mehr oder weniger irrelevant.
Nur weil sie nicht im Einflussreich des Autors liegen, sind sie doch nicht irrelevant für Performance-Optimierung. Im Gegenteil. Es muss auf verschiedenen Anbindungen und Browsern getestet werden.
Mathias
-
Ergebnis: "The test completed but there were no successful results."
Zweimal probiert, beide Male mit demselben Ergebnis => nicht zu gebrauchen.
Dann machst du etwas falsch.
Na ja, also sehr viel kann man da wohl nicht falsch machen, zumal ich auf jedwede Extras verzichtet habe.
Oder der Service hat irgendwelche Probleme. Das kommt vor bei dutzenden Testservern mit jeweils einer Handvoll Browsern.
Dann wäre es nur hilfreich, wenn er dazu irgendwelche Infos ausspucken würde.
Das ändert nichts daran, dass WebPagetest das beste (kostenlose) Tool weit und breit ist.
Mag sein - kann ich halt nur wegen s.o. nicht beurteilen ...! :-P
Und wenn ich die Geschichte mit dem 'Speed Index' richtig verstanden habe, dann ist der ja sowieso vom jeweiligen System, dessen Anbindung, Performance und dem verwendeten Browser abhängig.
Ja, wie jeder normale Besuche auf deiner Seite auch. Deshalb kannst diese Parameter bei WebPagetest einstellen.
Alles Dinge, die nicht mehr im Einflussbereich des Autors liegen, und somit imho mehr oder weniger irrelevant.
Nur weil sie nicht im Einflussreich des Autors liegen, sind sie doch nicht irrelevant für Performance-Optimierung. Im Gegenteil. Es muss auf verschiedenen Anbindungen und Browsern getestet werden.
Ja, und was nützt das? Du kannst doch serverseitig nicht darauf reagieren, weil du nichts über die "Verbindung" weißt. Also muss man sich für eine "Optimierungs-Variante" entscheiden, und die ist dann für alle gleich.
Das ist imho insbesondere da von Nachteil, wo es bei einer DSL Verbindung bspw. eher vorteilhaft wäre, durchaus mehrere Requests mit jeweils kleineren Dateien zu haben, im Gegensatz zu GPRS Verbindungen, wo das Gegenteil optimaler wäre.
Deshalb ist es für mich mehr oder weniger "irrelevant", denn keiner weiß im Voraus, welche "Gruppe" häufiger auf die Seite zugreift. Und selbst wenn man es nach empirischen Studien entsprechend anpasst, garantiert ja keiner, dass es zukünftig auch so ist/ bleibt! ;-)
Gruß Gunther
-
-
-
-
Hallo werte Selfgemeinde,
kleine Zusatzfrage: Mir war so, als ob ich irgendwo mal gelesen habe, dass der Apache auch bei einem Request mehrere Dateien auf einmal raus schicken kann?
Ich kann aber bei Google nichts dazu finden, zumal bei den (vermeintlich) geeigneten Suchbegriffen immer andere Dinge im Vordergrund stehen.
Konkret es um folgendes:
Ich verwende u.a. 4 SVG Grafiken auf meiner Seite, die ich auch schon zu .svgz gepackt habe. Die Grafiken stehen aber nicht direkt im HTML Code, sondern werden von einem JS Skript bei Bedarf angefordert und in das DOM eingefügt.Gibt es hier noch irgendeine Optimierungs-Möglichkeit?
Gruß Gunther
-
Mir war so, als ob ich irgendwo mal gelesen habe, dass der Apache auch bei einem Request mehrere Dateien auf einmal raus schicken kann?
Ich verwende u.a. 4 SVG Grafiken auf meiner Seite, die ich auch schon zu .svgz gepackt habe. Die Grafiken stehen aber nicht direkt im HTML Code, sondern werden von einem JS Skript bei Bedarf angefordert und in das DOM eingefügt.
Gibt es hier noch irgendeine Optimierungs-Möglichkeit?
Optimierungsmöglichkeiten gibt es viele. Ob die jeweils sinnvoll sind, muss konkret untersucht werden. Die Infos, die du bietest, sind nicht genug.
Wenn die Grafiken mit großer Sicherheit angezeigt werden, so kannst du sie auch allesamt im HTML einbinden (eventuelle Browserprobleme mal außen vor).
Oder in *einer* SVG-Datei zusammenfassen.
Die kann u.U. als Data-URI in CSS eingebunden werden und als background-image verwendet werden.
Oder, oder, oder… Kommt ganz darauf an.Generell gilt für Performance-Optimierung: Premature optimization is the root of all evil. Performance-Optimierung muss sehr konkret und datengestützt erfolgen. Optimierungsmaßnahmen müssen sich empirisch bewähren, also die Site messbar in gegebenen Anwendungsfällen schneller machen.
Mathias
-
Hallo Mathias!
Nee, das ist ja etwas anderes ...! Da braucht es ja trotzdem für jede Datei einen eigenen Request.
Gibt es hier noch irgendeine Optimierungs-Möglichkeit?
Optimierungsmöglichkeiten gibt es viele. Ob die jeweils sinnvoll sind, muss konkret untersucht werden. Die Infos, die du bietest, sind nicht genug.
OK, ich reiche gerne die fehlenden Infos nach.
Wenn die Grafiken mit großer Sicherheit angezeigt werden, so kannst du sie auch allesamt im HTML einbinden (eventuelle Browserprobleme mal außen vor).
Letzteres ist allerdings genau der Grund dafür, warum ich das nicht gemacht habe. Denn die Variante mit dem "eingebauten Fallback", sprich <object>, hat den gravierenden Nachteil, dass jeweils beide Sourcen (also svg und jpg|gif|png) runtergeladen werden.
Oder in *einer* SVG-Datei zusammenfassen.
Das sind aber jeweils "richtige" Grafiken. Was ich sagen will ist, dass es sich nicht nur um ein paar Zeilen Code handelt.
Die kann u.U. als Data-URI in CSS eingebunden werden und als background-image verwendet werden.
AFAIK müsste das dann aber quasi unkrompimiert erfolgen und die Base 64 Kodierung produziert auch noch mal einen relativ großen Überhang. Das würde den Rahmen sprengen. Da sind selbst 3 Requests mehr mit Sicherheit performanter.
Oder, oder, oder… Kommt ganz darauf an.
Generell gilt für Performance-Optimierung: Premature optimization is the root of all evil. Performance-Optimierung muss sehr konkret und datengestützt erfolgen. Optimierungsmaßnahmen müssen sich empirisch bewähren, also die Site messbar in gegebenen Anwendungsfällen schneller machen.
Ja, ich "messe" ja schon ... ;-)
Gruß Gunther
-
Nee, das ist ja etwas anderes ...! Da braucht es ja trotzdem für jede Datei einen eigenen Request.
Achso, du meinst Server-Push:
http://en.wikipedia.org/wiki/Push_technology#HTTP_server_push
http://www.igvita.com/2013/06/12/innovating-with-http-2.0-server-push/
http://chimera.labs.oreilly.com/books/1230000000545/ch12.html#HTTP2_PUSHAls HTTP-1.1-Feature wird das m.W. nur von wenigen Browsern unterstützt, die Idee lebt aber in SPDY/HTTP 2.0 weiter.
AFAIK müsste das dann aber quasi unkrompimiert erfolgen und die Base 64 Kodierung produziert auch noch mal einen relativ großen Überhang. Das würde den Rahmen sprengen. Da sind selbst 3 Requests mehr mit Sicherheit performanter.
Natürlich produziert Base64 Overhead, aber pro GET-Request, der wegfällt, sparst du bis zu 1 KB HTTP-Overhead. Das HTML bzw. CSS mit der Data-URI kann und sollte GZip-komprimiert ausgeliefert werden.
Da sind selbst 3 Requests mehr mit Sicherheit performanter.
Was vorteilhafter ist, hängt natürlich von der Dateigröße und der Anzahl der Dateien ab. Das lässt sich errechnen und testen.
Mathias
-
-
-
Meine Herren,
kleine Zusatzfrage: Mir war so, als ob ich irgendwo mal gelesen habe, dass der Apache auch bei einem Request mehrere Dateien auf einmal raus schicken kann?
Da hast du vermutlich über SPDY gelesen, für Apache gibt es die Erweiterung mod_spdy. Habe damit selbst aber keine Erfahrungen.
-
Mein Herr!
Da hast du vermutlich über SPDY gelesen, für Apache gibt es die Erweiterung mod_spdy. Habe damit selbst aber keine Erfahrungen.
Ja, darüber habe ich auch gelesen (und irgendwo hier ja auch schon erwähnt), ist aber auch nicht das was ich meine.
Ich glaube, ich werde das aber mal testweise einrichten.
Hat hier zufällig schon irgendwer praktische Erfahrungen damit? ;-)
Gruß Gunther
-
-
-
Meine Herren,
ich habe mal an einer Webseite gearbeitet, die eigentlich öffentlich zugänglich war, aber von einem Teil des Mitarbeiterstamms des Kunden von einem Intranet aus besucht wurde. Das Intranet hat dabei externe Ressourcen nicht zugelassen und das hat dann dazu geführt, dass die Seite nur eingeschränkt nutzbar war. Auch das sollte man bei CDN-Lösungen bedenken.
-
Das Intranet hat dabei externe Ressourcen nicht zugelassen und das hat dann dazu geführt, dass die Seite nur eingeschränkt nutzbar war. Auch das sollte man bei CDN-Lösungen bedenken.
Guter Hinweis. Es zu bedenken, heißt folgendes Pattern anzuwenden:
<script src="http://cdn.example.com/jquery-x.x.x.js"></script> <script> [code lang=javascript]if (!window.jQuery) document.write('<script src="javascripts/jquery-x.x.x.js"><\/script>');</script>[/code]
Wenn das Script vom CDN-Host nicht geladen werden konnte, so wird es kurzerhand vom selben Host geladen.
Mathias
-