nicht angemeldet
Sinnvolle Projektgrösse ( KB,MB,GB?! :) ) im Zeitalter von DSL
suit
Der MartinHallo zusammen
Beim Erstellen eines Webauftritts und dem dabei anstehenden Entscheid über die Exportqualität der Grafiken aus meinem Entwurf, habe ich mir die folgende Frage gestellt:
Welche konkrete Gesamtgrösse darf eine neu zu ladende Seite heutzutage haben?
Klar ist, dass ich es mir eher leisten kann, eine 200KB-Grafik einzubeziehn, z.B. als Hintergrund, wenn diese dann immer wieder verwendet wird und nicht neu geladen werden muss. Aber was haltet ihr für eine zumutbare Gesamtgrösse? Maximal 200, 300, 500KB? Damit lässt sich ja dann schon seehr viel machen.
Gerade ja auch ein Frage, da seid Surfen mit mobilen Geräten in ist, auch wieder vermehrt Nutzer für Datenmengen zahlen und nicht mehr per Flatrate unterwegs sind. Wobei ja auch dies inzwischen bei vielen Angeboten wieder anders ist.
Eure Meinung ist gefragt!
Gruss aus der Schweiz
-
Eure Meinung ist gefragt!
Auch "DSL" garantiert nicht, dass die Seite flott ausgeliefert wird - wie groß die Infrastruktur am Server ist spielt keine Rolle, die Daraus resultierenden Dokumente sollen klein und kompakt sein. Visuelle Spielereien wie z.B. Schatten oder runde Ecken lassen sich mit CSS lösen, das spart HTTP-Requests und senkt die Ladezeit enorm.
Ob eine Grafik jetzt 100 oder 200 kB hat ist weniger tragisch "schlimm" sind idR. viele HTTP-Request. Das macht besonders Browser wie dem Internet Explorer oder dem Firefox Probleme.
Ob Mobilbenutzer zu deiner Zielgruppe gehören, muss du selbst beurteilen.
-
»»Visuelle Spielereien wie z.B. Schatten oder runde Ecken lassen sich mit CSS lösen, das spart HTTP-Requests und senkt die Ladezeit enorm.
Darf man border-radius wirklich schon so uneingeschränkt einsetzen? Ist diese Eigenschaft nicht noch schlicht zu neu und man vergrämt mit dem für viele Browser noch eckigen Design die Besucher?
Und wie willst du denn Schatten machen mit css?
-
Darf man border-radius wirklich schon so uneingeschränkt einsetzen? Ist diese Eigenschaft nicht noch schlicht zu neu und man vergrämt mit dem für viele Browser noch eckigen Design die Besucher?
Jemand der nicht weißt, dass es keine runden Ecken gibt, dem fällt es garnicht auf - alternativ gibts aber auch .htc-Files die diverse CSS3-Eigenschaften für den IE simulieren können.
Und wie willst du denn Schatten machen mit css?
box-shadow und text-shadow - wird von jedem relevanten Browser unterstützt (für Webkit und Gecko gibt es herstellerspezifische Eigenschaften, aber das spielt keine Rolle - die verhalten sich exakt wie das CSS3-Vorbild), für den IE gibt es proprietäre Filter die fast dasselbe bewirken.
-
Jemand der nicht weißt, dass es keine runden Ecken gibt, dem fällt es garnicht auf - alternativ gibts aber auch .htc-Files die diverse CSS3-Eigenschaften für den IE simulieren können.
Also ist sie doch noch zu neu. Deine Aussage mag für ganz banale Designs gelten. Aber wenn an anderen Stellen mit aufwändigeren (abgerundeten) Formen gearbeitet wird, die nicht per css realisierbar sind, dann werden Ecken doch sehr störend auffallen.
box-shadow und text-shadow - wird von jedem relevanten Browser unterstützt (für Webkit und Gecko gibt es herstellerspezifische Eigenschaften, aber das spielt keine Rolle - die verhalten sich exakt wie das CSS3-Vorbild), für den IE gibt es proprietäre Filter die fast dasselbe bewirken.
Aber auch hier wieder dasselbe Argument. Geh mal in der Schweiz an nen SBB Schalter: Ich hab letzten November nicht schlecht gestaunt, als ich was wollte, die gute Dame am Schalter die Funktion im Internet nicht gefunden hat und ich ihr helfen wollte. Die haben doch tatsächlich noch IE6... :)
CSS3 ist hammer, aber ich persönlich bin da immer vorsichtig dem implementieren. Ich meine, für deine persönlichen Blog oder ähnliches ist das natürlich ohne Einwände sofort verwendbar. Aber wenns ums Erstellen des Webauftritts irgend eines (professionellen) Angebots geht, dann würde ich da doch noch zögern und lieber nach altem Style die Ecken und Schatten mit Bildern zusammenbauen.
Gruss
-
Jemand der nicht weißt, dass es keine runden Ecken gibt, dem fällt es garnicht auf - alternativ gibts aber auch .htc-Files die diverse CSS3-Eigenschaften für den IE simulieren können.
Also ist sie doch noch zu neu. Deine Aussage mag für ganz banale Designs gelten. Aber wenn an anderen Stellen mit aufwändigeren (abgerundeten) Formen gearbeitet wird, die nicht per css realisierbar sind, dann werden Ecken doch sehr störend auffallen.Es ist sehr viel mit CSS realisierbar besonders was Rahmen und Hintergründe angeht: http://www.w3.org/TR/css3-background/
Sowas gehört unter anderem zu den Aufgaben eines guten Webdesigners, dass er die technischen Möglichkeiten und Einschränkungen der Browser kennt und dann für die entsprechende Zielgruppe und die Anforderungen abwägt, was er designen soll.
Aber geschätzt 98% der Leute die sich Webdesigner nennen können das nicht.
box-shadow und text-shadow - wird von jedem relevanten Browser unterstützt (für Webkit und Gecko gibt es herstellerspezifische Eigenschaften, aber das spielt keine Rolle - die verhalten sich exakt wie das CSS3-Vorbild), für den IE gibt es proprietäre Filter die fast dasselbe bewirken.
Aber auch hier wieder dasselbe Argument. Geh mal in der Schweiz an nen SBB Schalter: Ich hab letzten November nicht schlecht gestaunt, als ich was wollte, die gute Dame am Schalter die Funktion im Internet nicht gefunden hat und ich ihr helfen wollte. Die haben doch tatsächlich noch IE6... :)Wieso - die dafür notwenigen proprietären Filter werden afaik ab IE5 aufwärts unterstützt - es gibt keinen vernünftigen Grund sie nicht zu nutzen.
.foo {
-moz-box-shadow: 5px 5px 0 #333333;
-webkit-box-shadow: 5px 5px 0 #333333;
box-shadow: 5px 5px 0 #333333;
filter:progid:DXImageTransform.Microsoft.DropShadow(color='#333333',offX='5',offY='5');
}simples Beispiel und funktioniert einwandfrei in jedem relevanten Browser - erzeugt einen harten Schatten mit 5 Pixel Abstand nach links und unten in der genannten Farbe.
Geht natürlich auch mit weichen Schatten, das ist im IE aber etwas mehr spielerei.
Jedenfalls aber wesentlich einfacher als irgendwelche lustigen Konstrukte mit bis zu 9 unnützen Elementen zu erzeugen.
CSS3 ist hammer, aber ich persönlich bin da immer vorsichtig dem implementieren. Ich meine, für deine persönlichen Blog oder ähnliches ist das natürlich ohne Einwände sofort verwendbar. Aber wenns ums Erstellen des Webauftritts irgend eines (professionellen) Angebots geht, dann würde ich da doch noch zögern und lieber nach altem Style die Ecken und Schatten mit Bildern zusammenbauen.
Es ist auch in der Praxis problemlos einzusetzen - man muss halt nur nach ordentlichen Workarounds für den IE suchen.
-
Es ist sehr viel mit CSS realisierbar besonders was Rahmen und Hintergründe angeht: http://www.w3.org/TR/css3-background/
Wohl war, aber mit Grafiken ist man doch unbestreitbar noch freier. Ich freue mich daher am meisten über die Möglichkeit mehrerer Hintergründe in CSS3. So lässt sich dann endlich der (html-) Quellcode von den meisten rein für Designzwecken eingebauten div-Containern entschlacken.
Aber geschätzt 98% der Leute die sich Webdesigner nennen können das nicht.
Das dürfte daher kommen, dass das Wissen der meisten nur auf trial and error basiert.
Wieso - die dafür notwenigen proprietären Filter werden afaik ab IE5 aufwärts unterstützt - es gibt keinen vernünftigen Grund sie nicht zu nutzen.
Ja da hast du natürlich recht. Für jemanden, der mehr vom Grafischen her kommt, ist es aber ein grosser Schritt, das Design nicht mehr möglichst "fertig auszuliefern", sondern darauf zu vertrauen, dass der Browser das Ganze dann schon ganz hübsch macht hehe ;)
...Was ja auch sonst schon häufig etwas einer Lotterie gleichzukommen scheint. Beispielsweise hab' ich ne Page, die ich unter verschiedensten Systemen (Mac,Windows,Linux) ausprobiert habe mit verschiedensten Browsern. Hat immer alles tadellos so ausgesehen wie gewünscht. Und dann will ich diese einem neuen Kunden als Referenz zeigen und siehe da - es fehlt einfach mal so reproduzierbar eine "Fade-Grafik" im Hintergrund. Das Ganze unter Windows XP und dem neuesten Firefox, wo's überall sonst nicht den Hauch eines Problems gibt. Ich habe immer noch keine Ahnung, warum die Page auf diesem spezifischen Computer anders dargestellt wird.
-
Es ist sehr viel mit CSS realisierbar besonders was Rahmen und Hintergründe angeht: http://www.w3.org/TR/css3-background/
Wohl war, aber mit Grafiken ist man doch unbestreitbar noch freier.Man kann Grafiken verwenden - sowohl Rahmengrafiken alsauch mehrere Hintergrundgrafiken - sofern man die Freiheit braucht.
Ich behaupte aber spontan, dass man zu 95% der Fälle keine Grafiken braucht weil es ohnehin nur um Rahmenlinien, mehrfache Rahmen, Schatten, buntes leuchten, gebogene Rahmenlinien, usw geht.
Ich freue mich daher am meisten über die Möglichkeit mehrerer Hintergründe in CSS3.
Hallo? Ich hab dir gerade die beschreibung zum Background and Borders Module verlinkt. Da gehts um Hintergrund UND Rahmen und wie man beides sinnvoll in Kombination nutzen kann.
So lässt sich dann endlich der (html-) Quellcode von den meisten rein für Designzwecken eingebauten div-Containern entschlacken.
In den meisten Fällen mangelt es am Entwickler und nicht an der Technik - ein großteil der eingebauten div-Container ist bereits jetzt überflüssig da normalerweise genug andere Elemente vorhanden sind, wie man verwenden kann :)
Du glaubst nicht im ernst, es wird mit einer anderen Technik besser werden?
Aber geschätzt 98% der Leute die sich Webdesigner nennen können das nicht.
Das dürfte daher kommen, dass das Wissen der meisten nur auf trial and error basiert.Und trotzdem dürfen sie ein Gewerbe aufmachen und wild herumpfuschen - versuch das mal als Architekt oder Statiker.
Wieso - die dafür notwenigen proprietären Filter werden afaik ab IE5 aufwärts unterstützt - es gibt keinen vernünftigen Grund sie nicht zu nutzen.
Ja da hast du natürlich recht. Für jemanden, der mehr vom Grafischen her kommt, ist es aber ein grosser Schritt, das Design nicht mehr möglichst "fertig auszuliefern", sondern darauf zu vertrauen, dass der Browser das Ganze dann schon ganz hübsch macht hehe ;)Wie schon gesagt: ein guter Designer muss das Design den Gegebenheiten anpassen - wenn ich weiß, dass das ding am iPhone funktionieren soll, kann ich nicht 50 HTTP Requests nur durch lustige Grafiken verursachen die keinen mehrwert bringen - besonders dann nicht, wenn es nur um Runde Ecken oder Schatten geht, das kann Safari auch so und zudem dürfte es kaum jemandem auffallen, wenn die Glättung des Radius der Ecke nicht aus Fireworks oder Photoshop kommt sondern vom Browser selbst.
Ich habe immer noch keine Ahnung, warum die Page auf diesem spezifischen Computer anders dargestellt wird.
Konfiguration: Schriftgröße, irgend ein Toolbar, ein zusätzliches JavaScript - es kann verdammt viele Ursachen haben. Von dieser Vorstellung muß man sich zu allererst lösen: eine Webseite muss nicht in jedem Browser gleich aussehen.
Genausowenig sieht ein Film auf jedem Fernseher gleich aus - manche Fernseher haben etwas Overscan, manche genau anders rum, manche haben runde ecken, manche sind schwarz-weiss, es gibt 5:4, 4:3, 16:9 und 16:10 als häufig verbreitete Seiteverhältnisse. Von Kontrast und Farbe reden wir garnicht.
Man hat als Filmemacher also die Wahl ob man einen schwarz-weiß-Film dreht der sogar auf "alten Fernseher" halbwegs so aussieht wie auf neuen oder man dreht einen 3D-Film den Zuschauer ohne 3D-Fernseher halt nur in 2D zu sehen bekommen - aber regt sich deshalb jemand auf?
Kein Filmproduzent der Welt regt sich darauber auf, dass seine Mitarbeiter keinen 3D-Film machen der selbst auf einem Schwarz-Weiß-Fernseher in Farbe und 3D dargestellt wird.
Wenn man aber eine Website baut, mit runden Ecken, dann muss die in einem Schwarz-Weiß-Fernseher (IE6) trotzdem runde Ecken haben, koste es was es wolle.
Und bei Websites ist es so wie bei Computerspielen oder Filmen: eine bessere Technik kompensiert eine schlechte Handlung oder schlechten Inhalt meistens nicht (Ausnahmen bestätigen die Regel).
-
Ich behaupte aber spontan, dass man zu 95% der Fälle keine Grafiken braucht weil es ohnehin nur um Rahmenlinien, mehrfache Rahmen, Schatten, buntes leuchten, gebogene Rahmenlinien, usw geht.
Glaube ich sofort. Hat allerdings schon auch damit zu tun, dass die anzutreffenden Designs m.E. zunehmend einfacher und uniformer werden. Und gerade die seit "Web 2.0" überall anzutreffenden Fades kannn man natürlich problemlos als Schatteneffekte realisieren.
Hallo? Ich hab dir gerade die beschreibung zum Background and Borders Module verlinkt. Da gehts um Hintergrund UND Rahmen und wie man beides sinnvoll in Kombination nutzen kann.
Jup, ich habe nur angemerkt, was davon mich am meisten erfreut hat. Den Nutzen des restlichen Teils will ich damit überhaupt nicht in Abrede stellen. :)
So lässt sich dann endlich der (html-) Quellcode von den meisten rein für Designzwecken eingebauten div-Containern entschlacken.
In den meisten Fällen mangelt es am Entwickler und nicht an der Technik - ein großteil der eingebauten div-Container ist bereits jetzt überflüssig da normalerweise genug andere Elemente vorhanden sind, wie man verwenden kann :)
Jein, ich meine gerade bei dynamisch erstellten Seiten sind schon die Containerkonstrukte die grosse Konstante. Da kann man dann meist nicht darauf vertrauen, dass an einer bestimmten Stelle immer noch ein <a> Element oder sonst was aufzufinden ist.
Du glaubst nicht im ernst, es wird mit einer anderen Technik besser werden?
Die Technik ändert sich. Die meisten Leute bleiben beim Alten.
Und trotzdem dürfen sie ein Gewerbe aufmachen und wild herumpfuschen - versuch das mal als Architekt oder Statiker.
Das ist die Krux mit vielen Berufen. Beispielsweise auch als Musiker: Eine fundierte Ausbildung ist klar von Vorteil - Aber das ändert nichts daran, dass man dann durchaus harter Konkurrenz aus dem "Amateursektor" ausgesetzt ist. Und für den laienhaften Kunden ist der Unterschied häufig schwer zu erkennen.
Btw ist zumindest in der Schweiz soweit ich weiss der Titel "Architekt" immer noch nicht geschützt. So kann sich also eigentlich jeder nennen.
Wieso - die dafür notwenigen proprietären Filter werden afaik ab IE5 aufwärts unterstützt - es gibt keinen vernünftigen Grund sie nicht zu nutzen.
Ja da hast du natürlich recht. Für jemanden, der mehr vom Grafischen her kommt, ist es aber ein grosser Schritt, das Design nicht mehr möglichst "fertig auszuliefern", sondern darauf zu vertrauen, dass der Browser das Ganze dann schon ganz hübsch macht hehe ;)zudem dürfte es kaum jemandem auffallen, wenn die Glättung des Radius der Ecke nicht aus Fireworks oder Photoshop kommt sondern vom Browser selbst.
Hier bekommst du als Perfektionist so deine Probleme... :)
Genausowenig sieht ein Film auf jedem Fernseher gleich aus - manche Fernseher haben etwas Overscan, manche genau anders rum, manche haben runde ecken, manche sind schwarz-weiss, es gibt 5:4, 4:3, 16:9 und 16:10 als häufig verbreitete Seiteverhältnisse. Von Kontrast und Farbe reden wir garnicht.
Ja gerade an der Farbdarstellung kann ich mich persönlich immer mal wieder stören. Ich habe festgestellt, dass gerade Laptops häufiger zu sehr kalten Tönen tendieren.
Aber natürlich bringt es nichts sich zu sehr darüber aufzuregen.Apropo: In der Musikszene ist es beim Abmischen von Musik das klar vorgegebene Ziel, diese auf möglichst vielen Abhörvorrichtungen gut klingen zu lassen. Hast du schon einmal Farben auf unterschiedlichsten Bildschirmen verglichen, um so den optimalen Ton zu finden?
Wenn man aber eine Website baut, mit runden Ecken, dann muss die in einem Schwarz-Weiß-Fernseher (IE6) trotzdem runde Ecken haben, koste es was es wolle.
Gut, der IE6 ist natürlich sowieso das Extrembeispiel. Um dort noch optimale Resultate zu erreichen, müsste man schon auf verdammt viel verzichten. Ich beschränke mich da drauf, dass die Seite noch les- und navigierbar bleibt.
Und bei Websites ist es so wie bei Computerspielen oder Filmen: eine bessere Technik kompensiert eine schlechte Handlung oder schlechten Inhalt meistens nicht (Ausnahmen bestätigen die Regel).
Bessere Technik bügelt Fehler in der Semantik besser aus :P (allerdings natürlich in für den Ersteller nicht vorhersehbarer und in dem Sinne "zufälliger" Art und Weise)
-
Hast du schon einmal Farben auf unterschiedlichsten Bildschirmen verglichen, um so den optimalen Ton zu finden?
Nein - ich hab mehrere gute Grafiker die das Machen, ich selbst bin nur der Entwickler.
Wenn man aber eine Website baut, mit runden Ecken, dann muss die in einem Schwarz-Weiß-Fernseher (IE6) trotzdem runde Ecken haben, koste es was es wolle.
Gut, der IE6 ist natürlich sowieso das Extrembeispiel. Um dort noch optimale Resultate zu erreichen, müsste man schon auf verdammt viel verzichten. Ich beschränke mich da drauf, dass die Seite noch les- und navigierbar bleibt.Selbst banale Dinge sind in verschiedenen Browser problematisch - Gecko kann mit line-height in Formular-Elementen (besonders in input[type=submit]) nicht ordentlich umgehen. Jemanden der es nicht weiß wird es kaum stören, dass die Schrift mal 1 Pixel weiter unten ist als in anderen Browsern - es tut der Bedienung keinen Abbruch und es sieht ordentlich aus - aber es gibt dann in der Tat leute die meinen, das muss gefixt werden. Und dann sitzt du wegen derartigen Problemen stundenlang herum nur damit solche Winzigkeiten behoben werden - aber wenn du dann mal ein paar Stunden möchtest um Klasse X oder Modul Y mit ein paar neuen Funktionen zu erweiteren die wirklich notwendig wären, ist das natürlich nicht drin :)
-
nabend
Btw ist zumindest in der Schweiz soweit ich weiss der Titel "Architekt" immer noch nicht geschützt. So kann sich also eigentlich jeder nennen.
Dem ist leider so. Aber die anschliessende Ausbildungsbezeichnung schon. Jeder kann sich also Architekt nennen, aber nicht Architekt FH(neu B.A./M.A. früher HTL)/ETH SIA BSA STV usw.
Also immer drauf auf die Kürzel schauen dann gibts meist weniger Bauschäden.grüsse
-
-
-
-
-
-
-
-
Moin Moin!
Auch "DSL" garantiert nicht, dass die Seite flott ausgeliefert wird
Richtig, denn noch ist DSL länsgt nicht flächendeckend verfügbar, ebenso wenig wie Ersatztechniken. Wer nicht das Glück hat, in der Nähe eines DSLAM zu wohnen und eine relativ junge Amtsleitung zu haben, muß sich mit einem 56k-Modem oder ISDN (max. 2x 64 kBit/s) rumschlagen. UMTS ist in solchen Gebieten meistens auch nur theoretisch verfügbar, und Internet-Zugang per Satellit ist ein schlechter Witz. Wenn man da nicht jeden Monat den Gegenwert eines Gebrauchtwagens investieren will, ist per Satellit in der Praxis auch bei 64 kBit/s Schluß -- an guten Tagen. Papier ist geduldig, und selbst wenn der gesamte Downstream tatsächlich richtig breit ist, bleibt verteilt über viele Tausend Nutzer vom Strom nur noch ein Rinnsal pro Nutzer.
Und das ist nur die Situation in Deutschland, wo die Versorgung relativ gut ist.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".-
Auch "DSL" garantiert nicht, dass die Seite flott ausgeliefert wird
Richtig, denn noch ist DSL länsgt nicht flächendeckend verfügbar,
Das zielt aber ziemlich weit an suits' Argumentation vorbei. :)
Was ich dazu noch anmerken will ist, dass hier Deutschland beispielsweise der Schweiz hinterherzuhinken scheint - zumindest, wenn man kurz Wikipedia überfliegt. Soll heissen, zumindest für die Schweiz kann man DSL mit gutem Gewissen voraussetzen.
-
Soll heissen, zumindest für die Schweiz kann man DSL mit gutem Gewissen voraussetzen.
Wie schon gesagt: nur weil DU mit DSL ausgestattet bist, heißt das noch lange nicht dass das "Internet dazwischen" auch schnell ist. Sei es jetzt ein Ausländischer Server oder irgend eine kurze Störung - in solchen Fällen ist es von Vorteil, wenn trotz kurzfristig lahmer Verbindung die Inhalte schnell ausgeliefert werden können.
Die angesprochene Latenz-Sache kommt noch dazu - stellt dir vor es dauert 300 ms pro HTTP-Request bis du das File überhaupt ausgeliefert bekommst. Da kannst du gut und gerne mit 30 MBit surfen - jeder andere der mit 10 MBit und 25 ms Latenz daherkommt, wird über dich lachen.
Darum: HTTP-Requests sparen wo es geht, das sind die größten bremsen.
-
Moin Moin!
Auch "DSL" garantiert nicht, dass die Seite flott ausgeliefert wird
Richtig, denn noch ist DSL länsgt nicht flächendeckend verfügbar,
Das zielt aber ziemlich weit an suits' Argumentation vorbei. :)Was ich dazu noch anmerken will ist, dass hier Deutschland beispielsweise der Schweiz hinterherzuhinken scheint - zumindest, wenn man kurz Wikipedia überfliegt. Soll heissen, zumindest für die Schweiz kann man DSL mit gutem Gewissen voraussetzen.
Ach, haben die Schweizer an ihren Smartphones und Mobil-PCs etwa alle ein langes DSL-Kabel? ;-)
Gerade in gebirgigen Gegenden würde ich nicht unbedingt davon ausgehen, dass ich an jedem Ort einwandfreie Breitband-Netzabdeckung habe.
Du kannst schlicht und ergreifend nicht davon ausgehen, dass alle Besucher Deiner Website eine Mindestbandbreite zur Verfügung haben[1]. Im einfachsten Fall zuckst Du mit den Achseln und denkst Dir, dass die paar Landeier und Smartphone-Fans halt Pech gehabt haben, wenn sie eine halbe Stunde auf die Startseite Deiner Website warten müssen. Insbesondere, wenn Du mit Deiner Website kein Geld verdienen willst, funktioniert die Strategie ganz gut. Wenn Du um jeden Besucher kämpfen willst/mußt, mußt Du loggen, messen und benchmarken.
Wohin das führt, kannst Du z.B. bei Googles Startseite sehen. Die ist gnadenlos auf Ladegeschwindigkeit getrimmt. Valides HTML? Eingerückt? Fehlanzeige, stattdessen schneller ladende Tag-Suppe ohne ein überflüssiges Leerzeichen. Bilder? Exakt zwei: Eines mit (fast?) allen Deko-Grafiken (http://www.google.de/images/srpr/nav_logo35.png) und das große Google-Logo (http://www.google.de/intl/en_com/images/srpr/logo1w.png). Und bei der Suchergebnis-Seite wird nur noch das nav_logo35.png benutzt, dass schon im Browsercache liegt. Das HTML ist wieder nicht eingerückt, nicht valide, stattdessen wird um jedes Zeichen gekämpft. Für die Startseite brauchst Du exakt 3 HTTP-Requests, einen einzigen weiteren HTTP-Request für die Ergebnisseite. Stylesheets sind gleich ins HTML eingebettet, nicht schön, aber es spart einen weiteren HTTP-Request.
Mit vier HTTP-Requests kommst Du dagegen z.B. bei der Startseite von spiegel.de nicht weit, ich zähle aktuell 83 einzelne Bilder, die jeweils einen HTTP-Request benötigen, dazu das HTML-Dokument, zwei Javascript-Resourcen (die mein Browser gar nicht erst lädt), ein generisches Stylesheet und für diverse IEs noch jeweils ein weiteres. Spiegel.de kommt es ganz offensichtlich nicht so extrem auf die Ladezeit an wie Google, man setzt darauf, dem Benutzer zu jedem Thema irgendein "Appetithäppchen" unter die Nase zu halten. Valide sind weder HTML noch CSS, das macht vermutlich zu viel Mühe, dem CMS das beizubringen. Es funktioniert eben auch so gut genug. Und sollte sich jemand bei spiegel.de darüber beschweren, dass Spiegel.de in seinem antiken Exoten-Browser sch...e aussieht, wird man ihm vermutlich raten, den aktuellen IE, Firefox oder vielleicht noch Chrome zu benutzen. Schlimmstenfalls springt halt irgendein Querulant ab, auf den man tatsächlich schmerzfrei verzichten kann.
Alexander
[1] Ich nutze gerade ein DSL-6000. Das muß ich mir mit rund 100 Kollegen teilen, die zum Glück eher selten alle gleichzeitig ins WWW wollen. Würde das passieren, hätte ich rechnerisch gerade eben noch einfache ISDN-Geschwindigkeit zur Verfügung, trotz DSL-6000.
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".-
Gerade in gebirgigen Gegenden würde ich nicht unbedingt davon ausgehen, dass ich an jedem Ort einwandfreie Breitband-Netzabdeckung habe.
Süss wie ihr deutschen Flachländer euch das "Gebirge" vorstellt :) das sind keine Felsspalten wo man grade mal mit einem Pferd durchreiten kann (wie in einem schlechten Indianerfilm) :)
Du kannst schlicht und ergreifend nicht davon ausgehen, dass alle Besucher Deiner Website eine Mindestbandbreite zur Verfügung haben[1].
Das ist richtig - aber das hat mit dem Gebirge nix zu tun :D
Wohin das führt, kannst Du z.B. bei Googles Startseite sehen. Die ist gnadenlos auf Ladegeschwindigkeit getrimmt. Valides HTML? Eingerückt? Fehlanzeige, stattdessen schneller ladende Tag-Suppe ohne ein überflüssiges Leerzeichen.
Google ist aber ein Spezialfall - bei dem Traffic den Google hat ist selbst 1 eingespartes Byte viel Wert (bzw. ein einzelner HTTP-Request noch mehr). Ich finde grade keine aktuellen Zahlen - aber Google hat vor ein paar Jahren die "3.8 Millarden Suchanfragen pro Monat"-Schwelle in den USA durchbrochen.
1 Byte bedeutet im Monat also 3,8 GiB Traffic - bei dem von mir angesprochenen Beispiel mit den Sprites und dem angenommenen Overhead von 18 KiB nur für die Grafiken sind das nur beim dem optimieren dieser Grafiken zu einem Sprites und einer zusätzlichen Grafik 64.400.000.000.000.000 Byte also 64,4 PiB (natürlich sind hier jetzt Faktoren wie z.B. das chaching nicht beachtet).
Die Geschichte mit den paar Milliarden eingesparten HTTP-Requests die nicht mehr auf der Serverlandschaft aufschlagen lassen wir jetzt mal :)
-
Hallo suit,
Ich finde grade keine aktuellen Zahlen - aber Google hat vor ein paar Jahren die "3.8 Millarden Suchanfragen pro Monat"-Schwelle in den USA durchbrochen.
1 Byte bedeutet im Monat also 3,8 GiB Traffic - bei
na, eher 3,8 MB Traffic (ja M, ja ohne i).
Freundliche Grüße
Vinzenz
-
Ich finde grade keine aktuellen Zahlen - aber Google hat vor ein paar Jahren die "3.8 Millarden Suchanfragen pro Monat"-Schwelle in den USA durchbrochen.
1 Byte bedeutet im Monat also 3,8 GiB Traffic - bei
na, eher 3,8 MB Traffic (ja M, ja ohne i).
3,8 Milliarden Byte sind
Milliarden = giga
Millionen = mega
Tausend = kilo-
Hallo,
Ich finde grade keine aktuellen Zahlen - aber Google hat vor ein paar Jahren die "3.8 Millarden Suchanfragen pro Monat"-Schwelle in den USA durchbrochen.
1 Byte bedeutet im Monat also 3,8 GiB Traffic - bei
na, eher 3,8 MB Traffic (ja M, ja ohne i).
3,8 Milliarden Byte sindich sollte morgens nicht so früh antworten. Einigen wir uns auf GB :-)
Freundliche Grüße
Vinzenz
-
ich sollte morgens nicht so früh antworten. Einigen wir uns auf GB :-)
Das ist genehmigt, denn es sind in der Tat 3,8 GB und nicht 3,8 GiB - das war mein Fehler ;) es sind nur ~3,54 GiB aber eben 3,8 GB.
-
-
-
-
-
-
-
-
Ob eine Grafik jetzt 100 oder 200 kB hat ist weniger tragisch "schlimm" sind idR. viele HTTP-Request. Das macht besonders Browser wie dem Internet Explorer oder dem Firefox Probleme.
Versteh' ich das richtig, dass man also eher darauf achten sollte, möglichst wenige Grafiken einzubeziehen, anstatt diese möglichst klein zu halten?
-
Ob eine Grafik jetzt 100 oder 200 kB hat ist weniger tragisch "schlimm" sind idR. viele HTTP-Request. Das macht besonders Browser wie dem Internet Explorer oder dem Firefox Probleme.
Versteh' ich das richtig, dass man also eher darauf achten sollte, möglichst wenige Grafiken einzubeziehen, anstatt diese möglichst klein zu halten?
Wieviel Overhead fordert so n'HTTP-Request denn im Mittel?
-
Ob eine Grafik jetzt 100 oder 200 kB hat ist weniger tragisch "schlimm" sind idR. viele HTTP-Request. Das macht besonders Browser wie dem Internet Explorer oder dem Firefox Probleme.
Versteh' ich das richtig, dass man also eher darauf achten sollte, möglichst wenige Grafiken einzubeziehen, anstatt diese möglichst klein zu halten?
Wieviel Overhead fordert so n'HTTP-Request denn im Mittel?
Das ist verschieden - es hängt von der Browserkonfiguration ab (was er denn so in den Request-Headern mitschickt) und was der Server Antwortet (da ist oft ziemlich viel Mist dabei wo dir lang und breit erklärt wird, welche PHP-Version denn nun drauf ist usw).
Ein Beispiel hier im Forum:
diese Grafik ist 81 Byte groß.Der Request-Header den mein Opera schickt um diese Datei anzufordern ist 682 Byte groß, der Response-Header des Servers (304 Not Modified) hat 252 Byte - zusammen sind das 934 Byte, in Summe mit dem zu übertragenden Bild also 1015 Byte, also rund 1 KiB. Also benötigt allein der HTTP-Verkehr (ohne die Zeit jetzt zu rechnen) 92% des gesamten Datenaufkommens.
Und von dieser Sorte Grafiken (vornhemlich Icons) gibt auch hier im Forum mehr - solche Grafiken fasst man sinnvollerweise in Sprites zusammen (sagte Martin ja schon).
Wenn du z.B. 20 Icons hast, wären das 20 KiB die zu übertragen wären - zusammengefasst in eine einzelne Grafik sind es dann aber nur noch rund 2 KiB.
Das hört sich zwar jetzt vom Datenvolumen nich viel an - ist es auch nicht, denn ein ordentliches Foto hat schon rund 500 KiB aufwärts - aber die Anzahl der HTTP-Requests ist das, was die Sache langsam macht.
Der HTTP-Stack unter Windows kann (wenn ich mich recht erinnere) nur 8 requests gleichezeitig absetzen (bzw. 10, aber 2 davon sind reserviert - z.B. für das Windows Update) - wenn du also jetzt 20 Grafiken anforderst, müssen die ersten 8 HTTP-Requests beantwortet werden, dann nochmal 8 und dann die restlichen 4 (oder halt verschränkt).
Der HTTP-Request dauert bei oben genannten Bild bei mir im Schnitt 50 ms - macht bei 20 Einzelgrafiken bereits (wenn man von 8 parallelen Requests ausgeht) rund 150 ms Wartezeit. Und das ist meistens nicht alles - da hat man noch ein paar JavaScript-Files die geladen und ausgeführt werden müssen, ein paar größere Bilder die einen der möglichen Request länger blockieren - und schon ist man selbst bei einer einfach anmutenden Seite mit nur ein paar Verzierungsbildchen auf einer beachtlichen Anzahl an Sekunden die es dauert, bis wirklich alles geladen ist.
Beispielsweise die Runde-Ecken-Sache die ich im anderen Ast erwähnt habe: ohne Sprites braucht man für eine Runde-Ecken-Lösung 8 Einzelgrafiken - dann hat man z.B. noch 5 verschiedene Rahmenfarben - das braucht auch jeweils 8 Grafiken. Schon sind wir bei 40 Grafiken nur für ein paar kleine Rahmen die sich auch mit CSS machen lassen.
-
-
Hallo,
Ob eine Grafik jetzt 100 oder 200 kB hat ist weniger tragisch "schlimm" sind idR. viele HTTP-Request. Das macht besonders Browser wie dem Internet Explorer oder dem Firefox Probleme.
Versteh' ich das richtig, dass man also eher darauf achten sollte, möglichst wenige Grafiken einzubeziehen, anstatt diese möglichst klein zu halten?genau das: Halte die Zahl der Ressourcen möglichst gering. Jeder HTTP-Request bedeutet durch die Request- und Response-Header einen Overhead, der locker 1kB pro Ressource erreichen kann. Außerdem fällt für jeden Request eine gewisse Reaktionszeit (Latency) an, die einige Zehntelsekunden betragen kann und von der Bandbreite der Internet-Verbindung nahezu unabhängig ist.
Anstatt für 20 Elemente jeweils ein kleines Hintergrundbild zu laden, ist es daher vorteilhaft, eine Collage aus diesen 20 Bilder zu machen und jedem Element einen anderen Ausschnitt desselben Bildes als Hintergrund zu geben (CSS-Sprites).
So long,
Martin--
Warum können wir heute so sicher sagen, dass Gott keine Frau sein kann?
Weil dann nach "Es werde Licht" der nächste Satz "Wie sieht denn das hier aus?!" gewesen wäre.
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
-
-
Ob Mobilbenutzer zu deiner Zielgruppe gehören, muss du selbst beurteilen.
Hier wäre dann noch zu unterscheiden ob ein Mobilbenutzer eine Seite auf einem Smartphone o.ä. ansehen will und die Seite darauf evtl. nicht unbedingt laden wird, oder ob man per Surfstick im Internet ist und die Seite wie gewohnt auf einem Laptop nutzen will.
-
