Performance bei IMG SRC Tag Aufruf
Daniel S.
- html
Angenommen ich habe eine Seite http://www.url.de
Nun möchte ich Bilder auf dieser Seite einfügen in diesen 2 Varianten
(1) <img src="bild.gif">
(2) <img src="http://www.url.de/bild.gif">
entsteht beim Aufrufen eines Bilder über die 2. Version (mal abgesehen vom Mehrtraffic, da die zweite Version länger ist) ein Performanceverlust für:
a) den Server / Nameserver
b) den Client/User (da die Domain nochmal aufgelöst wird), oder cachen die Browser/PC's die Domainauflösung
?
Von der Gescwingigkeit dürfte beides völlig gleich sein. Diese ~10 Bytes, die zusätzlich bei (2) entstehen sind mehr als vernachlässigbar.
Der Code ist allerdings bei der ertsen Variante sehr viel sauberer und auch deutlich vorzuziehen, da man so den Code zur not auch mal auf einen anderen Server oder in ein anderes Verzeichnis packen kann, ohne das man gleich die urls in allen Dokumenten ändern muss.
Hallo,
Von der Gescwingigkeit dürfte beides völlig gleich sein. Diese ~10 Bytes, die zusätzlich bei (2) entstehen sind mehr als vernachlässigbar.
Ich denke die zweite Variante sollte schneller sein, da man sich das neu zusammenbauen der URL aus der relativen Angabe erspart. Aber ob man diesen Geschwindigkeitsunterschied messen kann weiß ich nicht ;-)
Der Code ist allerdings bei der ertsen Variante sehr viel sauberer und auch deutlich vorzuziehen, da man so den Code zur not auch mal auf einen anderen Server oder in ein anderes Verzeichnis packen kann, ohne das man gleich die urls in allen Dokumenten ändern muss.
Andererseits, wenn man nur die HTML-Datei verschiebt, oder sie eigentlich nur generiert wird und man im voraus nicht weiß wo diese HTML-Datei (bzw. der HTML-Schnipsel) auftauchen wird, ist es nicht mehr soo vorteilhaft. Und da "Cool URLs don't change" auch für Bilder gilt, würde ich die zweite Variante vorziehen.
Grüße
Jeena Paradies
Hallo
Von der Gescwingigkeit dürfte beides völlig gleich sein. Diese ~10 Bytes, die zusätzlich bei (2) entstehen sind mehr als vernachlässigbar.
Ich denke die zweite Variante sollte schneller sein, da man sich das neu zusammenbauen der URL aus der relativen Angabe erspart. Aber ob man diesen Geschwindigkeitsunterschied messen kann weiß ich nicht ;-)
Sollte das nicht egal sein, da diese Aufgabe der Browser übernimmt? So beschäftigt, dass es da zu Wartezeiten kommt, ist ein Browser (im Normalfall) nicht.
Tschö, Auge
Beim Browser macht es vielleicht nicht viel aus, aber den Nameserver könnte es schon mehr belasten. Wenn er plötzlich 50 Anfragen pro Internetseite mehr auflösen muss.
Hallo
Beim Browser macht es vielleicht nicht viel aus, aber den Nameserver könnte es schon mehr belasten. Wenn er plötzlich 50 Anfragen pro Internetseite mehr auflösen muss.
Der Browser fordert nicht grafik/bild1.jpg
, sondern http://www.example.org/grafik/bild1.jpg
an. Wo soll denn, vom Browser aus gesehen, grafik/bild1.jpg
bitteschön sein? Er muss schon eine _vollständige_ URI senden, wenn er eine Ressource laden will/soll.
Tschö, Auge
Hi,
Beim Browser macht es vielleicht nicht viel aus, aber den Nameserver könnte es schon mehr belasten. Wenn er plötzlich 50 Anfragen pro Internetseite mehr auflösen muss.
DNS-Ergebnisse werden üblicherweise gecached.
Aber abgesehen davon, es gibt sowieso keinen Unterschied im Request für das Bild, egal ob eine relative oder absolute URL angegeben ist.
cu,
Andreas
Hi,
Ich denke die zweite Variante sollte schneller sein, da man sich das neu zusammenbauen der URL aus der relativen Angabe erspart.
tut man das? Woher weiß der Browser denn, dass es sich bereits um eine absolute URL handelt, bevor er versucht hat, eine solche zu erzeugen?
Aber ob man diesen Geschwindigkeitsunterschied messen kann weiß ich nicht ;-)
Wo ist doch gleich meine nanosekundengenaue Stoppuhr hin ...? ;-)
Cheatah
Hallo,
tut man das? Woher weiß der Browser denn, dass es sich bereits um eine absolute URL handelt, bevor er versucht hat, eine solche zu erzeugen?
Logo weiß er das, er prüft einfach als erstes ob es eine(n?) Scheme gibt [RFC 1738]:
; the scheme is in lower case; interpreters should use case-ignore
scheme = 1*[ lowalpha | digit | "+" | "-" | "." ]
Grüße
Jeena Paradies
Hi,
tut man das? Woher weiß der Browser denn, dass es sich bereits um eine absolute URL handelt, bevor er versucht hat, eine solche zu erzeugen?
Logo weiß er das, er prüft einfach als erstes ob es eine(n?) Scheme gibt
das tut er nicht, wenn sich erweist, dass diese Prüfung im Durchschnitt teurer ist als die "einfache" Erzeugung der absoluten URL. Man _kann_ so vorgehen, aber es gibt keinen _Zwang_, so vorzugehen. Und aus dem Vorhandensein einer Möglichkeit Rückschlüsse auf die Wahl derselben zu ziehen halte ich für, ähm, mutig ;-)
Cheatah
Hallo,
das tut er nicht, wenn [..]
ja, genau, wenn ;-)
sich erweist, dass diese Prüfung im Durchschnitt teurer ist als die "einfache" Erzeugung der absoluten URL. Man _kann_ so vorgehen, aber es gibt keinen _Zwang_, so vorzugehen.
Ich bin mir jetzt nicht ganz sicher, wer solche URLs eigentlich umformatieren muss, der Client, oder der Server?
"../foo/bar/../baz/blub/../../bajs/../hallo.txt"
Und aus dem Vorhandensein einer Möglichkeit Rückschlüsse auf die Wahl derselben zu ziehen halte ich für, ähm, mutig ;-)
Hey, ich bin ein Mann der mutigen Entscheidungen, und auch wenn ich ab und zu falsch entschieden habe, beeindruckte vor allem Arbeitgeber es mehr dass ich den Mut zur Entscheidung hatte, als umgekehrt, die anderen, die nur abgewartet haben und Zeit vertrödelten. ;-) Mut zur Lücke *g*
Grüße
Jeena Paradies
Hi,
Ich bin mir jetzt nicht ganz sicher, wer solche URLs eigentlich umformatieren muss, der Client, oder der Server?
"../foo/bar/../baz/blub/../../bajs/../hallo.txt"
so eingegeben der Client. Bei absoluter URL könnten sich Browser diese Arbeit sparen.
freundliche Grüße
Ingo
Hallo.
Diese ~10 Bytes, die zusätzlich bei (2) entstehen sind mehr als vernachlässigbar.
Eigentlich sind sie zu vernachlässigen.
MfG, at
Dazu mal noch ne Extrafrage. Ich verwende auf meiner Seite ein Set von ca. 25 Smilies zum Einfügen in z.B. Nachrichten, die jetzt alles einzelne Gif-Bilder sind.
Ist es aus Server-Performancegründen sinnvoll, aus den 25 Smilies ein einziges Bild zu machen, da dadurch nur eine Anfrage an den Server gesendet wird (und der damit nur einen Request beantworten muss) anstatt 25 Anfragen? (Server müsste ja dann auch nur eine Datei öffnen.)
Hallo Daniel
Ist es aus Server-Performancegründen sinnvoll, aus den 25 Smilies ein einziges Bild zu machen, da dadurch nur eine Anfrage an den Server gesendet wird (und der damit nur einen Request beantworten muss) anstatt 25 Anfragen? (Server müsste ja dann auch nur eine Datei öffnen.)
Nicht nur aus das, es spart auch Traffik.
Die 25 Smilies dürften jeweils relativ kleine Dateien sein.
Zum einen dürfte eine größere GIF-Datei die alle enthält kleiner sein als die Summe der 25, zum anderen muss für jede einzelne Resource eine extra Kommunikation zwischen Client und Server stattfinden, das bedeutet pro Grafik noch etwa ein KB zusätzlich.
Auf Wiederlesen
Detlef
Hallo
Ist es aus Server-Performancegründen sinnvoll, aus den 25 Smilies ein einziges Bild zu machen, da dadurch nur eine Anfrage an den Server gesendet wird (und der damit nur einen Request beantworten muss) anstatt 25 Anfragen? (Server müsste ja dann auch nur eine Datei öffnen.)
Nicht nur aus das, es spart auch Traffik.
Die 25 Smilies dürften jeweils relativ kleine Dateien sein.
Zum einen dürfte eine größere GIF-Datei die alle enthält kleiner sein als die Summe der 25, zum anderen muss für jede einzelne Resource eine extra Kommunikation zwischen Client und Server stattfinden, das bedeutet pro Grafik noch etwa ein KB zusätzlich.
Allerdings zuzüglich eines wesentlich umfangreicheren Stylesheets um an einer Stelle nur einen bestimmten Ausschnitt aus der großen Graphik darzustellen.
Woraus sich wiederum ergibt: in der HTML-Datei pro Smiley ein zusätzliches Element, dem die Graphik (mit dem Ausschnitt) als Hintergrundbild zugewiesen wird. Noch mehr Traffic.
Wobei noch nichtmal sichergestellt werden kann, ob das in jedem Browser so dargestellt wird, wie es gewünscht ist. Ich würde von solchen Experimenten die Finger lassen.
Tschö, Auge
Hi,
Woraus sich wiederum ergibt: in der HTML-Datei pro Smiley ein zusätzliches Element, dem die Graphik (mit dem Ausschnitt) als Hintergrundbild zugewiesen wird. Noch mehr Traffic.
<img src="laughing.png" alt=":-)"/>
<span class="laughing">:-)</span>
Pro Smiley zwei Byte gespart.
Wobei noch nichtmal sichergestellt werden kann, ob das in jedem Browser so dargestellt wird, wie es gewünscht ist.
So, kann es nicht?
Ich würde von solchen Experimenten die Finger lassen.
Ich nicht, im Gegenteil.
Cheatah
Hallo,
Wobei noch nichtmal sichergestellt werden kann, ob das in jedem Browser so dargestellt wird, wie es gewünscht ist.
So, kann es nicht?
Vor allem bei Druck-Browsern ist das bisher noch ein sehr schwieriges unterfangen. *auserfahrungsprech*
Grüße
Jeena Paradies
Hallo
Ist es aus Server-Performancegründen sinnvoll, aus den 25 Smilies ein einziges Bild zu machen, da dadurch nur eine Anfrage an den Server gesendet wird (und der damit nur einen Request beantworten muss) anstatt 25 Anfragen? (Server müsste ja dann auch nur eine Datei öffnen.)
Die aber, grob gerechnet, 25 mal so groß ist. und da du (höchstwahrscheinlich) nicht ständig alle 25 Smilies, die zudem eine relativ geringe Dateigröße haben dürften, verwendest, würde ich davon abraten, alle Smileys in einer Datei zu packen.
Zudem müsstest du für jedes Smiley ein Element erzeugen, in dem du die vollständige Graphik für jedes Smiley anders positionieren müsstest. Du willst ja jeweils nur _ein_ Smiley anzeigen.
Tschö, Auge
Hallo Auge.
Zudem müsstest du für jedes Smiley ein Element erzeugen, in dem du die vollständige Graphik für jedes Smiley anders positionieren müsstest.
Imagemap?
Einen schönen Sonntag noch.
Gruß, Ashura
Hallo
Zudem müsstest du für jedes Smiley ein Element erzeugen, in dem du die vollständige Graphik für jedes Smiley anders positionieren müsstest.
Imagemap?
Und mit der kannst du festlegen, welches der in der Graphik vorhandenen Smilies _ausschließlich_ angezeigt wird?
Tschö, Auge
Hallo Auge.
Zudem müsstest du für jedes Smiley ein Element erzeugen, in dem du die vollständige Graphik für jedes Smiley anders positionieren müsstest.
Imagemap?
Und mit der kannst du festlegen, welches der in der Graphik vorhandenen Smilies _ausschließlich_ angezeigt wird?
Wer will das? Der OP offenbar nicht.
Einen schönen Sonntag noch.
Gruß, Ashura
Hallo
Zudem müsstest du für jedes Smiley ein Element erzeugen, in dem du die vollständige Graphik für jedes Smiley anders positionieren müsstest.
Imagemap?
Und mit der kannst du festlegen, welches der in der Graphik vorhandenen Smilies _ausschließlich_ angezeigt wird?
Wer will das? Der OP offenbar nicht.
Wenn ich das konkrete Posting noch einmal lese, kommt es mir auch so vor. Ich ging davon aus, dass er in der resultierenden Newsseite, die Smilies aus _einer_ Graphik heraus darstellen wollte.
Tja, verlesen.
Tschö, Auge
Auf der resultierenden Seite hatte ich schon vor die Smilies als einzelnes Gif-Bild zu verwenden. Bei z.b. einem Gästebuch auf der Seite wo der User seine Nachricht einträgt aber, wird ja meist ein ganzes Set von Smilies angeboten, welches man als eine (1) Grafik verwenden könnten um Ressourcen zu sparen.
Relevant wird es z.B. auf Seiten wo sich User viele Private Nachrichten untereinander schreiben können, und jedes mal ein Smilies Set mit auf der Seite zum Einfügen in die Nachricht angeboten wird.
Hallo
Auf der resultierenden Seite hatte ich schon vor die Smilies als einzelnes Gif-Bild zu verwenden. Bei z.b. einem Gästebuch auf der Seite wo der User seine Nachricht einträgt aber, wird ja meist ein ganzes Set von Smilies angeboten, welches man als eine (1) Grafik verwenden könnten um Ressourcen zu sparen.
Nachdem mich ja Ashura auf mein (vollkommenes) Missverstehen deines Anliegens hingewiesen hat, kann ich nur sagen: richtig. Benutze also die Imagemap um einem Bild mehrere Verweise zuzuweisen.
Tschö, Auge
Hi,
Die aber, grob gerechnet, 25 mal so groß ist.
und, grob gesagt, 24 mal weniger HTTP- und Grafik-Overhead besitzt. Zudem stößt das ganze 21 mal weniger an die Beschränkung von HTTP/1.1, nie mehr als vier gleichzeitige Connections von einem Client zu einem Server offen zu halten[1]. Von der Zeit, die die Roundtrips an sich benötigen, will ich gar nicht erst reden. Der Geschwindigkeitsvorteil dürfte so groß sein, dass er bereits mit dem Auge sichtbar ist, wenn Du mir dieses Wortspiel erlaubst ;-)
und da du (höchstwahrscheinlich) nicht ständig alle 25 Smilies, die zudem eine relativ geringe Dateigröße haben dürften,
Ja, schätzungsweise je 200-400 Byte. Plus die ca. 2 Kilobyte HTTP-Overhead. Dieser einen Datei einen zweiten Smiley hinzuzufügen dürfte die Datei übrigens um ungefähr 100-200 Byte vergrößern, und im Gegenzug spart man nur einmal 2 KiB Overhead. Das rechnet sich in der Tat nicht.
würde ich davon abraten, alle Smileys in einer Datei zu packen.
Nach[2] näherer Betrachtung würde ich davon abraten, es nicht zu tun.
Zudem müsstest du für jedes Smiley ein Element erzeugen,
Ah, das ist natürlich ein Punkt. Mit 25 Grafiken spart man sich das, da man nur für jedes Smiley ein <img>-Element erzeugen muss.
in dem du die vollständige Graphik für jedes Smiley anders positionieren müsstest.
Ja, das ergibt bei 25 Smileys ganze 26 CSS-Zeilen, wenn man es effizient angeht.
Du willst ja jeweils nur _ein_ Smiley anzeigen.
Vermutlich, ja.
Cheatah
[1] Was in der Praxis so umgesetzt ist, dass für Grafiken u.ä. nur zwei parallele Requests durchgeführt werden, um noch etwas "Spielraum" zu haben.
[2] Streng genommen schon davor.
Hi,
Angenommen ich habe eine Seite http://www.url.de
Dann wärst Du die U.R.L. Gesellschaft fuer Informationsdesign mbH.
Für Beispieldomains keine real existierenden domains verwenden mit den 3 Ausnahmen, die extra für genau diesen Zweck existieren: example.net, example.org, example.com.
(1) <img src="bild.gif">
(2) <img src="http://www.url.de/bild.gif">
entsteht beim Aufrufen eines Bilder über die 2. Version (mal abgesehen vom Mehrtraffic, da die zweite Version länger ist) ein Performanceverlust für:
a) den Server / Nameserver
Nein, in beiden Fällen wird vom Browser exakt derselbe Request erzeugt [1].
b) den Client/User (da die Domain nochmal aufgelöst wird), oder cachen die Browser/PC's die Domainauflösung
Nein, in beiden Fällen wird vom Browser exakt derselbe Request erzeugt [1].
[1] Voraussetzung: es ist kein abweichendes <base href> gesetzt.
cu,
Andreas