Sie existieren nicht. Aber wäre das nicht schön?
Nehmen wir zum Beispiel die Markup-Struktur die diskutiert wird für das
<picture alt="A giant stone face at The Bayon temple in Angkor Thom, Cambodia">
<!-- Default -->
<source src="small.jpg">
<!-- Alternative if media query matches -->
<source src="medium.jpg" media="(min-width: 400px)"> -->
<!-- Alternative if media query matches -->
<source src="large.jpg" media="(min-width: 800px)">
<!-- Fallback -->
<img src="small.jpg" alt="A giant stone face at The Bayon temple in Angkor Thom, Cambodia">
</picture>
Ich unterstütze diese Idee zu 100 %. Lasst uns Bilder servieren, die wir unter den von uns festgelegten Bedingungen wollen. Aber ist die Bildschirmbreite hier die richtige Metrik? Vielleicht ist sie das, warum sollte ein Bildschirm mit 400 Pixel Breite jemals ein Bild benötigen, das größer als 400 Pixel breit ist? Nun, ich denke, die Retina-Displays auf bestimmten neuen Geräten beantworten diese Frage für uns. Diese Geräte reagieren vielleicht auf bestimmte Breiten-Media-Queries, haben aber tatsächlich doppelt so viele verfügbare Pixel und können viel schärfere Bilder anzeigen. Ja, wir haben dafür auch device-pixel-ratio Media-Queries, aber ich denke immer noch, wir tanzen um das eigentliche Problem.
Das Problem ist: Bandbreite. Wenn ich mich an einem Ort / auf einem Gerät befinde, das eine super langsame Internetverbindung hat, würde ich mir wünschen, eine sehr leichte Webseite serviert zu bekommen, damit das Surfen trotzdem akzeptabel schnell ist. Wenn ich mich an einem Ort / auf einem Gerät befinde, das eine super schnelle Internetverbindung hat, dann legt bitte los und liefert mir mehr.
So etwas wie
/* Fair warning: these aren't "real" */
@media (min-bandwidth: 25Mbps) {
/* High bandwidth, bring it on! */
}
@media (max-bandwidth: 10Mbps) {
/* This is only for the viewers with currently slow internet connection speed */
}
Das bedeutet nicht, die Bildschirmgröße zu ignorieren. Das ist offensichtlich relevant, wenn es um das Layout geht. Diese Erweiterung von Media-Queries würde uns ein passenderes Werkzeug für Medien in einer Welt geben, in der die Größe deines Geräts zunehmend unabhängig von seiner Bandbreite ist.
Ich frage mich also: Ist das möglich?
Das wäre irgendwie nett. Das eigentliche Problem wäre immer noch die Benutzererfahrung. Weil ich eine viel langsamere Verbindung habe, bedeutet das, dass ich ein Bild mit viel geringerer Auflösung, vielleicht sogar pixeliges Bild sehe? Deine Website zuerst für mobile Geräte zu optimieren, kann ein sicherer Weg sein.
„langsame Verbindung“ ist hier der wichtige Teil. Ich könnte die Seite von einem iPad3 aus ansehen, auf dem Gipfel des Kilimandscharo. Somit wäre die **Auflösung** / ppi hoch, die Bandbreite niedrig.
Daher hätte ich lieber etwas Ähnliches wie **progressive JPEGs**, bei denen der Browser nach mehr Details fragt, wenn möglich, und dabei so viel wie möglich anzeigt.
Dies könnte auch der Zeitpunkt sein, an dem wir über die Messung von Dimensionen sprechen, nicht in px, sondern vielleicht in em (mm?!)
Ich sehe nicht, wie die Angabe von Bildgrößen in em anders sein könnte als das, was wir bereits tun können. Das Problem ist, da sie Bitmap sind – das Skalieren führt zu Qualitätsverlust und das Herunterskalieren führt zu verschwendeter Bandbreite (da die Dateigröße immer noch dieselbe ist). Sie können Bilder bereits auf diese Weise mit CSS-Media-Queries skalieren, indem Sie % und min/max-width verwenden...
1. Titel lesen
2. Reaktion „MEIN LEBEN WIRD SICH VERÄNDERN.“
3. Erste Zeile lesen: http://rle.me/x/ohman-sad.gif
Das ist eine erstaunlich großartige Idee. Bitte macht es wahr. Danke.
Haha. Ich hatte die gleiche Reaktion... Es sieht so aus, als gäbe es mit HTML5 etwas Hoffnung.
haha, ich hatte genau die gleiche Reaktion... Manchmal denke ich, Chris ist Yoda und HTML5 sind nur unsere Jedi-Fähigkeiten.
Für einen Moment war ich so glücklich, weil ich den Artikel nicht mit der ersten Zeile begonnen hatte zu lesen.
Ich habe jedoch festgestellt, dass sie dies in den HTML5-Standard integrieren: http://dvcs.w3.org/hg/dap/raw-file/tip/network-api/index.html#introduction
wow, danke dafür. Ich hatte noch nicht gesehen, dass Bandbreite zur Network API hinzugefügt wurde.
Sicherlich eine gute Idee, obwohl wir sicherstellen müssten, dass wir wissen, welche Geschwindigkeiten die Leute tatsächlich erreichen. Zum Beispiel bin ich heute mit 26 MBit/s unterwegs, am Wochenende war ich mit 75 MBit/s unterwegs und meine Mutter hat 0,3 MBit/s!
G-R-O-S-S-A-R-T-I-G-E Idee! \o/
Ich bin sicher, dass ein Skript erstellt werden kann, um Ihre Bandbreite zu „messen“. So etwas wie das Senden eines Zeitstempels vom Backend und dann die Verwendung von JS, um ihn mit dem Datum zu vergleichen, an dem das Dokument und alle seine Assets geladen wurden. Ich würde sagen, das würde Ihnen eine gute Schätzung geben (und da es JS berechnet, können Sie danach einen Callback basierend auf den Ergebnissen durchführen).
Ich stimme zu, dass wir eine Mischung aus Bildschirmgröße, Bildschirmauflösung und Bandbreite benötigen.
Aber die Bandbreite – insbesondere in mobilen Bedingungen – ist wirklich nicht stabil genug, um solche Kriterien zuzulassen. Während einer einzigen Surfsitzung auf meinem iPhone kann ich von GPRS zu WLAN/ADSL und zurück zu GPRS wechseln. Wann und wie würde das Betriebssystem/der Browser entscheiden, was meine Bandbreite ist?
Es wurden Experimente mit Yahoo!s Boomerang gemacht, zum Beispiel, aber es ist nicht genau genug, um nützlich zu sein.
Die Latenz ist für mobiles Surfen oft noch wichtiger als die Bandbreite.
Wirklich kein einfaches Thema.
Stimme Nicolas vollkommen zu.
Darüber hinaus ist max-bandwidth != verfügbare Bandbreite. Wie oft hat Ihr Telefon 5 Balken 3G (oder AT&T „4G“) angezeigt und konnte aufgrund von Verbindungsabbrüchen keine einzige Webseite laden? Außerdem, wenn Sie ein Massenupdate von Apps durchführen, sinkt Ihre verfügbare Bandbreite erheblich, auch wenn Sie immer noch Multitasking betreiben und im Web surfen.
Während die Möglichkeit, noch mehr reaktionsschnelle Schnittstellen in CSS zu erstellen, willkommen wäre, erwarte ich, dass jede kurz- bis mittelfristige Lösung für dieses Problem JS-gesteuert wäre – nicht CSS-gesteuert –, da das Problem zu komplex ist, um es deklarativ anzugehen. Darüber hinaus ist die Reaktion auf Bandbreite mehr als nur ein Darstellungsproblem – herauszufinden, welche Skripte/Assets geladen werden sollen, sollte der primäre Anwendungsfall sein.
Übrigens, wie Eric Taylor oben erwähnt hat, ist das, was wir dem offiziellen Ansatz am nächsten haben, das Bandbreitenattribut in der Network Information API (http://dvcs.w3.org/hg/dap/raw-file/tip/network-api/index.html#introduction).
Wenn (nicht wenn) wir zu einer robusteren Lösung gelangen, um unsere Benutzeroberflächen auf Bandbreite reagieren zu lassen, müssen wir neu untersuchen, wie wir die Erwartungen der Benutzer verwalten.
– Welche Art von Endbenutzererfahrung ergibt sich daraus, dass unterschiedliche Medieninhalte basierend auf der Bandbreite bereitgestellt werden?
– Wird der Benutzer erwarten, dass eine schnellere Verbindung höher aufgelöste Medieninhalte liefert, auf Kosten einer Verbesserung der Seitenladezeit?
„10 MBit/s /* Dies ist nur für Zuschauer mit derzeit langsamer Internetverbindungsgeschwindigkeit */“
Ich habe in meinem ganzen Leben noch nie 10 MBit/s gehabt, ich habe 5 MBit/s und denke, das ist ziemlich schnell... : (
Diese Art von Kommentar beunruhigt mich – mit einem immer globaleren Internet müssen wir daran denken, dass für manche Leute das, was als normal gilt, weit mehr ist, als in ihrer Region überhaupt angeboten wird.
Die Bild-Markup-Struktur und -webkit-image-set werden immer wichtiger und müssen bald implementiert werden – wenn Ihre Website zum Beispiel viele US-Besucher hat, dann wird das Bereitstellen von Inhalten mit niedriger Auflösung/vereinfachtem Inhalt immer wichtiger.
Ich stimme MMM zu, ich habe 0,6 MBit/s, und es stört mich eigentlich nie.
Ich schätze, wenn man die andere Seite nie gesehen hat, kann das Gras dort nicht grüner sein.
Hier genauso, meine Leitung schafft maximal 6 MBit/s. Die Vorstellung, dass 10 MBit/s langsam sind, ist verrückt.
Bandbreitentests sind aus vielen offensichtlichen Gründen gefährlich. Ich habe das vor einiger Zeit geschrieben – „Ich könnte Geschwindigkeitstests für Verbindungen täuschen“ (http://www.welcomebrand.co.uk/thoughts/i-could-fool-connection-speed-tests/), wegen des begrenzten Dienstes, den ich dort habe, wo ich lebe.
Ich hätte gerne die Option von mehr verfügbaren Werkzeugen wie diesem, aber mir ist bewusst, dass viele Leute sie verwenden würden, um grundlegendere Probleme mit ihren Websites zu vertuschen.
J.
Ich stelle mir vor, dass ich unter diesem System in bestimmten Fällen viele Bilder weglassen würde. Wenn ich auf meinem iPhone bin und nur eine EDGE-Verbindung bekommen kann, bin ich nicht mehr daran interessiert, schöne Bilder zu sehen, als daran, die gesuchten Informationen zu erhalten. Obwohl ich Design liebe, ist zu einem bestimmten Zeitpunkt mein Interesse daran, die Seite tatsächlich geladen zu sehen, weitaus größer als mein Interesse daran, wie sie aussieht. Es ist Zugänglichkeit vor Design; wenn jemand Ihre Website nicht sehen kann, ist sie ihm egal, wie schön sie ist.
Ich frage mich, ob es einen javascriptgesteuerten Weg gibt, dies zu tun. Könnte man einen Ajax-Aufruf verwenden, um die Ladezeit einer Seite auf der Benutzerseite zu messen, dann das html-Tag mit einer Klasse wie: <html class="25Mbps"> markieren? Könnte man diese Methode verwenden, um dann tatsächlich Bilder nicht zu laden, bis man die Verbindungsgeschwindigkeit identifizieren kann, dann entweder große Bilder laden, kleine Bilder laden oder warten, bis keine Bilder geladen werden, bis der Inhalt geladen ist, und dann JavaScript verwenden, um die Bild-src nach dem Inhalt zu laden? Vielleicht könnte das ein jQuery-Plugin sein.
Tolle Einsicht! Wie wäre es mit einem Skript, das die Seitenladezeit relativ zur Seite selbst misst? Das Skript wird im Head ausgelöst und misst die Zeit von da an, bis die gesamte Seite einschließlich der Bilder geladen ist. Es speichert dann einen 1-Stunden-Cookie mit einem Geschwindigkeitswert. Dieser Wert kann dann für den Rest der Zeit, die der Benutzer auf der Website verbringt, entsprechende Bilder etc. servieren.
Das ist eine gute Idee, Ash! Das würde bedeuten, noch weniger Ladezeit für den Benutzer und weniger HTTP-Anfragen. Ich würde vorschlagen, dass dieser Cookie eine kürzere Dauer hat und häufig neu geprüft wird für Benutzer, die durch verschiedene Verbindungszonen wandern.
Eine ähnliche Idee, die ich hatte, war die Verwendung von JavaScript, um einen Cookie zu setzen, der angibt, ob JavaScript aktiviert ist oder nicht. Auf diese Weise könnten Sie eine serverseitige If-Anweisung verwenden, um nur Teile des Inhalts und der Bilder zu laden, wenn JavaScript nicht aktiviert ist, und dann AJAX-Aufrufe verwenden, um nicht geladene Inhalte stattdessen zu füllen. Ein Ableger dieser Idee war der Versuch, viele Websites dazu zu bringen, nach diesem Cookie zu suchen und ihn zu setzen, damit er beim ersten Besuch einer Website durch einen Benutzer geladen werden könnte. Vielleicht könnten Sie durch die Kombination dieser Ideen ein Informationspaket wie dieses Crowdsourcing betreiben. Sie könnten ein Plugin verteilen, das nach diesem Cookie sucht und ihn dann setzt, und dann könnten viele verschiedene Websites es verwenden. Jede Website könnte jeder anderen Website helfen, den Cookie des Benutzers für alle seine aktuellen Browserinformationen auf dem neuesten Stand zu halten.
Das ist genau so, wie RetinaSwitch funktioniert. Jede Website, die es unterstützt, wenn ihre Seite geladen wird, macht eine Tunnelanfrage an RetinaSwitch, um den „Cookie“ (es ist eigentlich eine LocalStorage-Variable) zu überprüfen, ob sie Retina-Bilder deaktiviert haben. Im Wesentlichen ist diese Variable für alle global und in Bezug auf das Gerät, das den Schalter umgelegt hat.
Die gleiche Idee könnte sich auf die allgemeine Annahme von Geschwindigkeitsdrosselung stützen, anstatt nur auf Retina-Bilder.
Daran ist definitiv etwas dran. Das Problem ist, etwas zu schaffen, das nicht zu viele HTTP-Anfragen erfordert und nicht zu viele Dinge auf einmal passieren lässt lol
Ich stimme dir nicht zu. Ich surfe viel über das mobile Internet in Deutschland und in Berlin habe ich eine schnelle Verbindung (schnell im deutschen mobilen Internet bedeutet 1 MBit/s :D), aber einen SEHR langsamen Ping. Wenn mein Browser ein Bild anfordert, dauert es lange, die Server-IP aufzulösen und die HTTP-Anfrage zu stellen, aber danach wird das Bild schnell geladen. Wenn ich die Verbindungsgeschwindigkeit mit Ajax auf die von Ihnen vorgeschlagene Weise messen würde, würde das Ergebnis stark von der Ping-Zeit beeinflusst. Meiner Meinung nach kann JavaScript die Verbindungsgeschwindigkeit nicht genau genug messen.
Ich denke, der Browser/das Betriebssystem müsste die Geschwindigkeit messen, das ist die einzige Chance, eine präzise Geschwindigkeitsmessung durchzuführen. Während eines Seitenaufrufs berechnet der Browser die durchschnittliche Ladezeit FÜR JEDE DOMAIN/IP (achten Sie auf langsame Server) und speichert sie dann irgendwo. Und es wäre schön, wenn die Seite mit einer winzigen JavaScript-API auf diese Informationen zugreifen könnte.
Eine ganz andere Lösung wäre eine Technik, die HTML-Attribute verwendet. Vielleicht mit der kommenden Version von HTML oder mit einer neuen Spezifikation des W3C könnte dies implementiert werden. Meiner Meinung nach wäre dies besser als die JavaScript-Lösung, da der Browser/Client entscheiden könnte, ob er entweder das große oder das kleine Bild lädt. Ich würde dem HTML img-Tag ein neues Attribut namens „smallres“ (mit einer zweiten Bildquelle) hinzufügen, das in eine HTML-Seite integriert werden könnte. Und während der Browser das HTML parst, erkennt er, dass es eine kleine Version gibt und könnte diese je nach Verbindung laden. Der Browser könnte den Benutzer sogar danach fragen.
Was denkst du über meine Ideen?
Jannis R,
Ich denke, alle Ihre Vorschläge und Gründe dafür sind gut. Mein Vorschlag war eher eine Art: „Experimentell, wie können wir das jetzt richtig machen?“ Natürlich ist die Prämisse dieses Beitrags, dass es schön wäre, wenn der Browser uns diese Informationen auf sehr zuverlässige Weise zur Verfügung stellen würde.
Von Ihren Vorschlägen gefällt mir die Attributidee besser als die JavaScript-API-Idee. Ich bin immer noch vorsichtig bei allem, was JavaScript verwendet, wo es nicht unbedingt benötigt wird. Ich würde eine Methode bevorzugen, die nicht so viel Markup benötigt wie die Attributidee, obwohl. In jedem Fall wäre es schön, wenn der Browser uns diese Informationen naiv zur Verfügung stellen würde. Ich frage mich nur, was der Fallback für Browser sein müsste, die ihn nicht unterstützen. Würden wir einfach auf die langsamste Verbindung zurückfallen? Was ist mit der schnellsten Verbindung? Gäbe es einen Standardwert, den wir annehmen könnten, wo wir gar nichts dagegen tun, wie wir es jetzt tun?
Ich würde als Fallback den Benutzer fragen, ob er die volle Bandbreite nutzen möchte
Das gibt es bereits in JS, und es wird darüber gesprochen, dass es in MQ's aufgenommen wird.
Wir hatten praktisch genau das. Früher konnte man ein lowsrc-Attribut zu einem Bild hinzufügen – kombinieren Sie das entweder mit einer Benutzereinstellung („nur Download von geringer Qualität, wenn verfügbar“) oder automatischen Heuristiken („Ich bin mit einer schrecklichen Verbindung unterwegs, also lasse ich riesige JPGs aus“) und Sie hatten praktisch bandbreitensensitive Bilder.
Aus irgendeinem Grund verschwand es aus HTML.
Lowsrc war nicht das, was Sie denken. http://vimeo.com/38947881 4m 55s, spricht darüber.
PS: Ich habe dies vor ein paar Wochen der Responsive Images WG erwähnt und keine Antwort erhalten
http://www.w3.org/community/respimg/2012/03/07/14/#comment-115
Dieses Skript prüft, ob das Gerät einen Hi-Res-Bildschirm hat, und prüft dann auch die Verbindungsgeschwindigkeit. Ich weiß es nicht genau, aber es könnte einen Blick wert sein.
Die Geschwindigkeit der Verbindung ist ein guter Maßstab, aber was ist mit den KOSTEN dieser Daten? Ein Benutzer könnte in absehbarer Zeit eine Hochgeschwindigkeitsverbindung von einem Mobilfunknetz mit einem niedrigen Datenlimit haben! Ich möchte nicht, dass eine Website mir größere Dateien sendet, weil das Gerät, das ich benutze, schnell ist – besonders wenn es mich doppelt kostet.
Das Problem ist, dass dies automatisiert werden muss. Wir können dem Benutzer keine Vielzahl von Optionen geben: „knappe Kappe“, „Ressourcenfresser“, „blitzschnell“.
Wir müssen in der Lage sein, ihnen das zu servieren, was im Allgemeinen am besten ist. Nicht unbedingt GENAU das Beste. Wenn wir den Benutzer wahllos mit zu vielen Optionen überfluten, sind wir nicht iOS, wir sind Android lol.
Mir gefällt der von Ihnen angesprochene Punkt, da die meisten „erschwinglichen“ mobilen Datentarife es Ihnen in Deutschland ermöglichen, 200-300 MB mit 3G herunterzuladen, und dann wird Ihre Verbindungsgeschwindigkeit auf GPRS reduziert.
Der folgende Punkt ist vielleicht etwas weit hergeholt, aber was ist mit der Kapazität des Mobilfunknetzes? Sollten Leute dazu verleitet werden, hohen Datenverkehr zu erzeugen, nur weil sie es sich leisten können? Ich schätze, man kann jemanden kaum verbieten, HD-Filme auf seinem Mobilgerät zu streamen, aber vielleicht Websites optimieren, um unabhängig von der verfügbaren Verbindungsgeschwindigkeit schnell zu laden.
@media (min-monthly-data-limit: 2000Mb) {
/* Mittlere Sachen, her damit! */
}
Amen!
Ich würde das auch gerne sehen.
In der Zwischenzeit,
Sie könnten auch einen Geo-IP-Lookup-Service verwenden, um die mit der IP-Adresse verbundene Verbindungsgeschwindigkeit zu ermitteln. Sie sind sicherlich nicht 100 % genau, aber es ist besser als nichts...
Wir haben einen „kostenlosen“ API-Aufruf, der Ihnen die Geschwindigkeit der anfragenden IP-Adresse liefert.
Sie können es hier testen
http://geo.opentracker.net/GeoIpEngine/?connection
Es dauert ein paar Millisekunden, bis der Wert zurückgegeben wird, was schnell genug ist, um ihn zu verwenden und Ihr Bild basierend auf dem Ergebnis zu servieren.
Sie können dies gerne für Ihre (kleineren) Websites nutzen, für größere Websites kontaktieren Sie uns bitte.
Unverwandt, aber das wäre auch schön
@media (max-distance-to-other-people-in-public:1m) { * {device-volume: 0;} }:D
Das wäre brillant. Oder so etwas
Das wäre ziemlich cool.
Hier ist meine Idee dazu, sie ist nicht sehr solide, da sie erfordern würde, dass jeder Browserhersteller mitmacht
Immer wenn Sie aktiv im Web surfen, misst das Gerät die Downloadgeschwindigkeit bestimmter Anfragen im Verhältnis zu ihrer Größe. Eine globale „Konstante“ wird ständig aktualisiert und kann in JS verwendet werden (platform.currentBandwidth).
JS kann CSS-Klassen anhängen (.mediumBandwidth/.highBandwidth).
Für Abwärtskompatibilität müssen Coder natürlich zuerst prüfen, ob platform.currentBandwidth existiert.
Diese Lösung tut nichts für reguläre img-Elemente.
Ich bin mir ziemlich sicher, dass Sie dies serverseitig tun müssten und es Zugriff auf Netzwerkfunktionen auf niedriger Ebene erfordern würde. Wenn Sie die durchschnittliche Downloadgeschwindigkeit einer Sitzung berechnen, könnte die Webanwendung reagieren und Inhalte mit höherer/niedrigerer Auflösung bereitstellen. Node.js wäre dafür wahrscheinlich eine gute Lösung!
Ich stimme Chris hier zu. Es wäre nützlich, Media-Queries zu verwenden, um verschiedene Bilder zu servieren, aber es wäre viel besser, dies irgendwie serverseitig zu tun.
Meine Überlegung ist, dass es entweder einen Ping durchführen und bestimmen würde, welches Bild serviert werden soll (entweder auflösungsabhängig oder jpg-Qualität), oder dass es sich so progressiv wie möglich lädt und nach einer bestimmten Zeit stoppt.
Ich denke, wir kommen langsam an den Punkt, an dem mehr Frontend-Entwickler an die Leistung denken. Wir müssen auch bestimmen, was mit HTML+CSS+JS und was mit Server-Scripting gemacht wird.
Erinnern Sie sich an die alten Zeiten, wir hatten Splash-Seiten mit Links zu verschiedenen Versionen der Website für unterschiedliche Bandbreiten? Vielleicht müssen wir das wieder tun.
Die meisten Websites machen das bereits, aber ohne die Splash-Seite. Die meisten Websites haben eine mobile Version, die normalerweise leichter ist.
Das könnte mich wirklich nerven – sagen wir, wenn eine Website auf einem langsamen Rechner bei der Arbeit und auf meinem Mac zu Hause anders aussieht. Es müsste mit Bedacht eingesetzt werden, sagen wir, um GIF-Bilder mit geringerer Qualität zu liefern, wenn die Bandbreite geringer ist, aber zwangsläufig würden die Leute es verwenden, um die Menge oder das Aussehen von Inhalten zu ändern, und das ist dann nicht fair.
Das ist eine **fantastische** Idee, Chris. Wie einige oben gesagt haben, ist es komplizierter als die „maximale“ (oder sogar „aktuelle“, was auch immer „aktuelle“ sein würde) Übertragungsgeschwindigkeit, es geht um Latenz, Verbindungsabbrüche usw. usw., also muss noch mehr Arbeit geleistet werden. Aber Sie haben absolut Recht damit, dass die Bildschirmgröße ein ziemlich ungenauer Indikator für die Verbindungsgeschwindigkeit ist.
Ich denke, die Datenkappe und die Kosten sind weitaus nützlicher als die Geschwindigkeitstests. Und ich denke, einige der Kappen würden Sie auch überraschen. Zum Beispiel in Kanada, als ich das letzte Mal nach einem Handyplan gesucht habe, war die durchschnittliche Datenoption ein halbes Gigabyte Daten für 25 $.
Was wäre, wenn es einfach eine Media-Query gäbe, die eine Präferenz im Browser prüft?
Ich weiß, dass ich, selbst wenn ich einen 2-Gig-Plan wie in Martijns Beispiel hätte, immer noch nicht „verschwenden“ wollte, die Daten für höher aufgelöste Bilder auszugeben.
Vielleicht sollte es eine Version desselben Bildes in leichtem, normalem und schwerem Gewicht geben. Wie bereits erwähnt, definiert die Geschwindigkeit der Verbindung nicht die Benutzererfahrung. Die Geschwindigkeit einer Website hängt von Bandbreite, Latenz, Anzahl der zu ladenden Ressourcen, Anzahl der gleichzeitig herunterladenden Threads usw. ab. Außerdem können Sie auf vielen Tabs gleichzeitig surfen.
Deshalb denke ich, es wäre besser, alternative Quellen mit einer Beschreibung wie: leicht/normal/schwer zu geben. Der Browser könnte dann das Gewicht auswählen, das er mit der besten Strategie möchte.
* Das Netzwerk ist kostenlos und antwortet korrekt
* Netzwerk ist ok, aber viele Tabs müssen geladen werden
* Download langsam, dann Download des schweren Bildes, wenn der Benutzer zum Bild scrollt.
* Vom Benutzer definierte Strategie, um nicht zu viel Datenkontingent zu verschwenden.
Und schließlich ist diese Beschreibung immer korrekt, anstatt einer Bandbreitenmessung. Sie können heute nicht wissen, was die verfügbaren Bandbreiten in Zukunft sein werden. Sie können heute nicht definieren, was die reale Messung sein wird, die immer die Geschwindigkeit der Verbindung definiert. Vielleicht wird es morgen einen Next-Generation-Proxy geben, der den Download der hochauflösenden Version ohne Kosten ermöglicht, auch wenn die Bandbreite niedrig ist (es klingt etwas seltsam, aber warum nicht?).
Ich stimme Mike zu. Plus, ich würde hinzufügen, dass Bandbreite ein schwieriges Maß wäre; Flaschenhälse treten auf, die außerhalb der Hardware liegen und zu fehlerhaften Werten führen können. Ich meine, denken Sie an jemanden mit einem 4G-Gerät in einem schlechten Empfangsbereich, einem überlasteten Router, der mehrere Downloads durchführt usw. Man könnte sich vorstellen, dass ein Durchsatztest regelmäßig durchgeführt werden könnte – aber das scheint eine Art erzwungene Angelegenheit zu sein.
Was ist, wenn der Benutzer immer noch die höchste Auflösung sehen möchte?
Ein weiterer unerforschter Bereich ist die Wiederverwendung von etwas, das wir schon lange haben: progressives Laden. Was wäre, wenn man das Bild in niedriger Auflösung laden und dann weiter laden könnte, bis man die volle Auflösung hat? Gibt es Aspekte des progressiven Ladens, die wir überdenken können, um es praktischer zu machen?
Chris, ist es möglich, Geschwindigkeitstests mit JavaScript durchzuführen? Ich habe vor einiger Zeit davon gelesen, ein einfaches Bild zu hosten und dann den Download oder ähnliches über JS zu timen.
Wenn das der Fall ist, wäre es dann praktisch, wenn jemand ein Tool entwickeln würde, das diese einfache Prüfung durchführt und dann Inhalte auf diese Weise lädt?
Das Problem ist, dass der Download, um genau genug zu sein, gut 400 KB groß sein muss. Man könnte etwas Ähnliches wie http://www.retinaswitch.com haben, aber für Bandbreite. Probleme entstehen jedoch bei Mobilgeräten, wenn der Benutzer auf hohe Geschwindigkeit getestet wird und dann immer noch Websites mit hoher Geschwindigkeit geladen werden, obwohl er sich in einem Bereich mit geringer Empfangsqualität befindet.
Ich habe manchmal das Gefühl, dass meine Gedanken gelesen werden, wenn ich diese Seite besuche.
Ich habe vor ein paar Wochen darüber nachgedacht und dachte: „Wie viel einfacher wäre das Leben, wenn…“
Bandbreite war eines der Dinge, nach denen man abfragen könnte. Das Problem wäre, wie man sie bestimmt, ohne selbst viel Bandbreite zu verbrauchen oder eine JavaScript/Bibliothek zu verwenden, die wahrscheinlich eine nicht unerhebliche Menge an Kilobytes misst (und davon abhängt, dass JS aktiviert ist).
Wie genau wäre/könnte das sein? Wir wissen, dass ein „Bildschirm“ ein Bildschirm ist. Die Breite/Höhe sind tendenziell feste Größen, können aber leicht erkannt werden, wenn sie sich zu einer anderen festgelegten Größe ändern. Die Bandbreite schwankt ständig und kann meiner Meinung nach nicht so schnell „on the fly“ ermittelt werden.
Es ist auch interessant, warum die Debatte stattfindet und was die potenziellen Anwendungen sind. Ich sehe Anwendungsfälle für echte Bilder, die nützlichen Inhalt darstellen. Oder um ein HD-Video anstelle eines SD-Videos bereitzustellen. Wenn es als Ausrede verwendet wird, um aufgeblähte Designs mit vielen Bildern und Hintergründen bereitzustellen oder nicht bereitzustellen, ist das als Anwendung weit weniger beeindruckend.
Ich würde gerne sehen, wie Ihre Idee Realität wird. Es gibt keinen Grund, warum dies keine völlig praktikable Option sein könnte. Ich habe versucht, dieses Problem selbst mit http://www.RetinaSwitch.com zu lösen, aber es ist durch diejenigen eingeschränkt, die die API auf ihrer Website verwenden. Es würde funktionieren, wenn es übernommen würde, aber es sollte eine elegantere Lösung für uns geben.
Wow, das wäre cool und nützlich!
Die Überprüfung der verfügbaren Bandbreite ist in Ordnung, aber sie sollte die Benutzererfahrung nicht diktieren. Ich denke, die jetzige Funktionsweise ist in Ordnung, wobei die Bildschirmgröße des Geräts erkannt und dann das entsprechend dimensionierte Bild bereitgestellt wird. Man könnte diese Bilder weiter optimieren, um sicherzustellen, dass beim Bereitstellen eines 320-Pixel-Bildes im Vergleich zu einem 1000-Pixel-Bild nicht übermäßig viele Daten verbraucht werden.
Wie wäre es mit einem aggregierten Netzwerk-Performance-Score (ähnlich dem Windows Experience Index): einer Kombination aus Latenz, deklariertem Limit, Netzwerkfähigkeit des Geräts, aktueller Verbindungsbandbreite (gleitender Durchschnitt)?
Verdammt, man könnte das erweitern, um Geräte-CPU- und Speicher-Metriken einzubeziehen und daraus einen umfassenden Geräte-Performance-Score zu machen.
Ich denke, es ist wichtiger, ein neues Bildformat zu erstellen, PNG, JPEG, GIF sind so alt…
Und wie der Video-Tag bietet man einen Fallback für ältere Browser. Und natürlich sollte man den Benutzer seine Präferenzen konfigurieren lassen.
HERAUSFORDERUNG ANGENOMMEN!
:)
Vielleicht ist es besser, den Browser das am besten passende Bild auswählen zu lassen, indem man ihm Hinweise für die auszuwählenden Bilder gibt.
Ich denke, das ist besser, als komplexe Media-Queries für Bildschirmgröße, Pixeldichte und Bandbreite zu definieren :)
Wow, es gibt viele positive Reaktionen darauf. Persönlich bin ich nicht so begeistert. Vielleicht habe ich zu viel darüber nachgedacht!
Ich würde es hassen, zu einer schnelleren Verbindung zu wechseln, nur um festzustellen, dass Websites mehr davon verbrauchen, was jeden Vorteil zunichtemachen könnte. Es scheint, je schneller die Technologie, desto mehr leidet sie unter Bloat/Missbrauch. Ich kann mir vorstellen, dass viele Websites erkennen, dass ich über eine bescheidene Bandbreite verfüge, und sich daher entscheiden, mich mit ihren uninteressanten oder unnötigen Marketing-Videomaterialien zu bombardieren. Ich meine, „hohe Qualität“ ist ein subjektiver Begriff.
Natürlich ist die Netzwerkbandbreite nur ein Hinweis auf das maximale Potenzial. Das Gerät des Benutzers ist möglicherweise nicht in der Lage, die zusätzlichen Daten zu verarbeiten (es könnte wenig Speicher haben, einen langsamen Prozessor usw.), oder die Netzwerkbandbreite wird mit vielen Geräten geteilt (was in meinem Haushalt normalerweise der Fall ist).
Ich sehe nicht, wie ein Browser die optimale Geschwindigkeit entscheiden kann, da diese auch von Website zu Website stark variiert, sodass sie kontinuierlich gemessen werden müsste.
Es wäre großartig, eine „Lite“-Version einer Website für sehr geringe Bandbreite anzubieten, aber warum sollte man sie mit Media-Queries abfragen? Einfach lite.css-tricks.com haben, damit es auch Leute mit schnellen Verbindungen nutzen können, wenn sie möchten. Das Problem bei der automatischen Auswahl im Namen des Benutzers ist, dass die Wahl keine Benutzerpräferenz ist. Ein Benutzer mit geringer Bandbreite ist möglicherweise nicht so stark von einem Website-Besuch betroffen, der für hohe Bandbreiten konzipiert ist, insbesondere wenn das Client-seitige Caching effektiv ist.
Noch ein Beitrag mit Demo
http://themousepotatowebsite.co.za/the-responsive-image-problem/
Das ist eine sehr gute Idee, ich stimme dafür!
(auch wenn es am Ende ein ziemlicher Albtraum sein wird, alle verschachtelten Media-Query-Parameter zu handhaben)
Wie würde es also funktionieren? JavaScript, um die Bandbreite zu testen und dann entsprechende Ressourcen bereitzustellen?
Mag die Syntax nicht, aber die allgemeine Idee (warum Bild und nicht image). Ich denke, viele Dinge wie verschachtelte Media-Queries, Browserversion-Media-Queries und bedingte Tags sollten zuerst kommen.
Ich verstehe nicht, wie das Bandbreiten-Tag nützlich sein könnte – sicherlich schwankt die Bandbreite bei Mobilgeräten ständig. Muss man also die Bandbreite bei jedem Seitenaufruf messen? Außerdem widerspricht es nicht dem Sinn einer Media-Query, sich dann auf zusätzliche Skripte zur Bandbreitenberechnung verlassen zu müssen?
Sollte es wirklich einem Webentwickler überlassen bleiben, zu entscheiden, welche Bildgröße geeignet ist. Wäre es nicht gut, ein Bildformat zu haben, das mehrere Versionen des Bildes erlaubt (wie .ico) und dann einfach den Browser entscheiden zu lassen, welche Version er für am besten hält? Denke nur laut nach.
Das kann man mit etwas JavaScript mit dem
navigator-Objekt machen. Hier ist ein kleiner Ausschnitt.Und jetzt kann man das in seinem CSS machen:
Das Problem ist, dass nur Android (seit 2.2) es unterstützt (naja, keine Dokumentation auf MDN und caniuse, also bin ich mir bei Firefox Mobile und Opera Mini/Mobile nicht sicher, aber iOS unterstützt es nicht).
Ich denke, das würde dem Web helfen, globaler zu werden. Es gibt viele Entwickler aus der ersten Welt, die Seiten schreiben, die mit der Breitbandverbindung der ersten Welt funktionieren, und indem wir auf langsame Verbindungen reagieren, könnten wir Seiten für mehr Menschen zugänglich machen.
Ich denke nicht nur daran, Bilder mit geringerer Auflösung zu liefern, sondern wie wäre es, das riesige Hintergrundbild zugunsten einer einfachen Hintergrundfarbe aufzugeben, wenn man „Dial-up“ oder das Fehlen der riesigen JavaScript-Bibliothek erkennt. Man kann es für mehr verwenden, als man zunächst denkt.
Faire Idee, Chris.
Aber ich habe ein paar Kommentare dazu.
#1
Um die Bandbreite vom Browser zu identifizieren, ist es besser, das große oder aktuelle Bild herunterzuladen. Die Bandbreite ist nicht immer identisch mit dem System; dies erfordert eine Überprüfung bei jeder HTTP-Anfrage (andernfalls kann es falsch sein). Die Zeit zur Identifizierung der Bandbreite ist kürzer als die Zeit für eine HTTP-Anfrage.
#2
Die Bereitstellung der Funktion „min-bandwidth“ in @media reicht nicht aus. Hier sollte CSS auch verschachtelte Stile unterstützen, was wir heute nicht haben.
Beispiel
@media(min-bandwidth:10kbps) {
.small-img img {
background : url(small-img);
}
}
Wie auch immer, ich bin ein großer Fan Ihrer Ideen. Machen Sie weiter mit dem Posten. Danke.
Es war faszinierend, dieses Thema und die Gedanken der Leute dazu zu erkunden.
Ich schwankte zwischen dem Wunsch, die Benutzererfahrung je nach Bandbreite festlegen zu können, und dem Gefühl, dass es letztendlich die Entscheidung des Benutzers sein muss.
Ich stimme Lee Kowalkowski bis zu einem gewissen Grad zu, dass, wenn wir diese Technologie öffnen, die meisten Entwickler sie wahrscheinlich weise nutzen werden, aber sie öffnet auch eine Büchse der Pandora für diejenigen, die nicht so ethisch sind, Ihr Seherlebnis mit viel unnötigem Inhalt (d. h. Werbung) zu verstopfen.
Ich denke, wir brauchen einen gesunden Mittelweg.
Es wäre schön, die Möglichkeit zu haben, für Benutzer zu wählen, die nicht versiert genug sind, um selbst zu wählen, aber es wäre auch schön, etwas in Ihrem Browser einzustellen, das sagt: „Entweder sende meine Geschwindigkeit als…“ oder „Ich bevorzuge leichte Websites“.
Letztendlich müssen diejenigen, die wählen wollen, die Möglichkeit dazu haben. Ich glaube jedoch nicht, dass dies die Entwicklung eines Standards verlangsamen sollte, der es Entwicklern ermöglicht, diese Informationen einfach und zuverlässig zu finden.
Sie scheinen hier bereits einen Teil der Lösung zu haben?
Gibt es einen Grund, warum Bilder nicht basierend auf dem Rendering wie diesem geliefert werden sollten?
würden „sie“ es uns so leicht machen…?
Einfach. Beginnen Sie mit dem Low-Bandwidth-Stylesheet. Starten Sie einen JS-Timer im Body, und messen Sie dann die Zeit, bis das Page-Loaded-Ereignis ausgelöst wird. Die Zeit sagt Ihnen, wie lange es gedauert hat, diesen Inhalt zu laden (und Sie kennen die Größe), also kennen Sie die Bandbreite. Wechseln Sie dann zum entsprechenden Medium- oder High-Bandwidth-Stylesheet oder fügen Sie „High-Res“-Klassen hinzu.
Während wir dabei sind, wäre eine Media-Query-Klasse oder -ID schön. Wer möchte
media="(min-width: 400px)"für jedes img-Tag schreiben? Es sollte seinmediaclass="landscape-phone"@media.landscape-phone (min-width: 400px)) {...}oder etwas Ähnliches. Dann könnten wir die Bildquelle in eine Kaskade verwandeln, die automatisch nach oben geht, auch bei Größenänderung. Ich glaube nicht, dass Sie jemals die kleinere Version laden möchten, sobald Sie die größere Version bereits geladen haben.
Eine Browser-API, die beim Seitenaufruf überprüft wird, wäre großartig. Wenn ein Benutzer standardmäßig auf niedrige Qualität eingestellt werden könnte und dann in die Einstellungen geht, um sie zu erhöhen, wenn er möchte. Ich würde es hassen, jede Webseite dazu zu zwingen, einen Testdatensatz zu laden, um die Verbindung auf einer mobilen Verbindung zu testen.
Vielleicht könnten wir ein PHP-Skript erstellen, das uns das ermöglicht?
Ich mag das Konzept, weil wir zunehmend den Kontext des Benutzers verstehen müssen (unterwegs vs. auf der Couch), um responsive Websites zu erstellen. Bandbreite mag instabil sein, aber es wäre schön, eine Abfrage für den Netzwerktyp zu haben.
z.B.
Passen einige Videoplayer die Videoqualität nicht an die Bandbreite des Benutzers an?
Ich kann bei einer schnellen Suche kein gutes Beispiel finden, aber ich bin mir ziemlich sicher, dass ich mir bei der letzten Weltmeisterschaft angesehen habe, und die Qualität würde sich entsprechend einem „Bandbreiten“-Balken am unteren Rand des Players anpassen.
Sicher, aber dann wähle ich es für das spezifische Video. Das für die gesamte Seite (nicht nur ein Video, wir sprechen von allen Bildern) zu tun, dann sind wir wieder beim alten „Wähle, welchen Browser du benutzt“- oder „Wähle deine Auflösung“-Links auf einer Splashpage…
Ich denke, die beste Idee wäre, eine Einstellung über alle Browser hinweg zu haben, die der Benutzer ändern kann, oder der Browser kann irgendwie erkennen, ob sie mit einem einzigen festgelegten Namen variabel ist.
Wenn es auf 100% oder maximal eingestellt ist, bedeutet dies, dass der hohe Datenverbrauch eintritt, und 1% oder minimal bedeutet, dass es mir leid tut, aber ich habe Dial-up, und 50% oder halb wäre „durchschnittliche Datengeschwindigkeit in einem entwickelten Land“.
und es würde sich prozentual skalieren, wenn sich Geräte zwischen Netzwerken bewegen.
Es wäre eine Benutzereinstellung wie font-size:12px; und wir würden das Bandbreitengewicht des Inhalts wie eine Schriftgröße bearbeiten.
Das einzige Problem, das ich hier sehe, ist, dass Bandbreite eine Messung über die Zeit ist, wenn vom Client aus getestet wird. Daher müssen Sie die Zeit berücksichtigen, die tatsächlich benötigt wird, um die Verbindung zu testen, um die Bandbreite zu ermitteln, sowie die tatsächliche Zeit zum Laden der Seite. Diese Informationen könnten im HTML5-Speicher oder auf dem Server für zukünftige Besuche gespeichert werden, aber das widerspricht dem Zweck, da es jedes Mal neu gemessen werden müsste, wenn sich Ihre Verbindungsgeschwindigkeit ändert. Ich überschätze das vielleicht, da es sich um eine vernachlässigbare Zeitmenge handeln könnte, aber es ist nur ein Gedanke.
Eine weitere Media-Query, die großartig wäre.
Was wäre, wenn…
a) Wir bieten eine Lo-Fi-Version an, der Benutzer stellt die Option mit einem Schalter (Symbol, Link, Schaltfläche, Flagge) ein und wir setzen einen Cookie,
b) Wir erkennen die Bandbreite, setzen einen Cookie und bieten eine Option an
… und dann…
a) Wir haben ein serverseitiges Skript, das kleinere (Größe/Gewicht) Bilder mit GD oder ImageMagick erstellen kann, je nach gesetztem Cookie.
b) Wir setzen die Optionen (Mobile First?) mit dem data-Attribut. Ein JavaScript entscheidet, was je nach Cookie auf dem Bildschirm angezeigt wird.
Wir könnten entweder dynamisch CSS serverseitig generieren oder die verwendete CSS-Datei per AJAX ändern.
Dann könnten wir natürlich einfach die Regeln für Lo-Fi-Sachen in dieselbe CSS-Datei schreiben und sie einfach an eine Body-ID anhängen, damit wir die Regeln einfach ändern und alles handhaben können, indem wir die Body-ID hinzufügen (oder ändern), basierend auf der Bandbreitenerkennung oder der Benutzerauswahl… Was angekündigt werden kann, wenn die gleiche Seite erkennt: „Oh je, diese Seite dauert etwas zu lange“ (ähnlich wie Gmail die einfachere HTML-Version anbietet, wenn das Laden zu lange dauert).
Ich glaube nicht einmal, dass Sie die Bandbreite erkennen/messen müssen, geben Sie der Seite einfach x Sekunden Zeit, um vollständig geladen zu werden. Wenn nicht, bieten Sie die Lite-Option an.
Ich bin mir nicht sicher, ob das CSS dynamisch/responsiv generiert werden muss, und die Verwendung von AJAX könnte auch den Zweck verfehlen. Ich denke, es wäre sauberer, einfach einen Cookie zu setzen oder eine alternative URI anzubieten, z. B. lite.website.com, und URL-Rewriting (z. B. Apache mod_rewrite) zu verwenden, um leichte Ressourcen auszuwählen.
Wenn Sie wirklich eine Art Bandbreiten-Media-Query emulieren wollten, könnten Sie standardmäßig Bilder mit geringer Dateigröße bereitstellen und dann ein paar verschiedene AJAX-Aufrufe durchführen, um die höherwertigen Bilder anzufordern. Setzen Sie einen niedrigen Timeout-Wert für die AJAX-Aufrufe, und wenn der Aufrufer ausfällt, ist es wohl sicher anzunehmen, dass er eine niedrige Bandbreite hat. Dies würde zu einem seltsamen Effekt führen, bei dem die Website mit Bildern geringer Qualität übersät ist und die Bilder dann „magisch“ besser werden… und einige Front-End-Entwickler könnten mit der Menge an JavaScript, die involviert ist, nicht zurechtkommen. Dies wäre auch bei einer bildlastigen Website umständlich, es sei denn, die img/div-Tags hätten eine Namenskonvention, die sich innerhalb der .gif/.png/.jpg-Dateien selbst befände… es gibt wahrscheinlich eine Handvoll Möglichkeiten, den Prozess zu verfeinern… aber immer noch etwas mühsam.
Vielleicht könnten Sie auch Optionen/Einstellungen für den Benutzer anbieten, um standardmäßig höherwertige Bilder anzufordern und seine Präferenzen für zukünftige Besuche in einem Cookie zu speichern.
Ziemlich genial! Wurde das jemals der CSS3-Arbeitsgruppe vorgeschlagen?
Ich würde ein stark komprimiertes Bild als Standard bereitstellen, dann würde ich JavaScript verwenden, um ein höherwertiges Bild zu laden, wenn die Seite vollständig geladen ist.
Sie haben meine Hoffnungen geweckt und ich dachte für einen Moment, es sei der Himmel.
Das wäre absolut genial und erscheint mir ziemlich logisch. Die Möglichkeit, eine Seite basierend auf der Bandbreite bereitzustellen, wäre ein Segen für die vielen Benutzer, die immer noch keinen Zugang zu den blendend schnellen Verbindungsgeschwindigkeiten haben, die in Europa und den USA üblich sind.
Abgesehen davon bin ich mir nicht sicher, ob wir das bald sehen werden… was mich traurig macht. Gibt es jemanden bei der W3C, dem wir 5 Dollar zustecken können, um das zu beschleunigen? ;)
Das wäre ziemlich verdammt süß. Ich bin dafür.
Hier ist eine Diskussion aus der Mailingliste von WHATWG über Bandbreiten-Media-Queries. Obwohl theoretisch eine großartige Idee, glaube ich nicht, dass diese jemals nativ implementiert werden.
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/035964.html
Ich glaube, es steckt mehr dahinter, als CSS bewältigen kann. Meine Website hat Inhalte, die von vielen verschiedenen Servern im Internet stammen. Einige Inhalte werden von meiner 100-MBit/s-Verbindung geliefert, einige von YouTube, Vimeo, Facebook, Rackspace, Akamai, Amazon S3 und so weiter.
Was wird CSS tun, wenn die Verbindung des Benutzers schnell ist, aber die Geschwindigkeit eines der Server langsam ist? Wenn beispielsweise Amazon oder Vimeo wieder Probleme haben, ist es möglich, dass eine Seite im Durchschnitt langsam geladen wird, obwohl der Rest der Inhalte mit 100 MBit/s+ Geschwindigkeiten geliefert werden mag. Was passiert, wenn einige Inhalte über einen transparenten Proxy mit viel höheren Geschwindigkeiten als die verfügbare Internetbandbreite geliefert werden?
Ich denke, es wäre besser, Inhalte serverseitig zu optimieren. Lassen Sie Apache und IIS die Bilder und Inhalte dynamisch neu formatieren. Lassen Sie uns eine Option auf dem Server haben, mit der wir unser HTML, CSS und JS dynamisch minimieren können, wenn sie syntaktisch korrekt sind. Natürlich sollte der Webserver diese Minimierungen cachen. Lassen Sie Apache und IIS Bilder dynamisch in progressive Downloads umwandeln. Lassen Sie mich ein unkomprimiertes Bild auf meinem Webserver speichern und mich darauf verlassen, dass der Webserver es dynamisch neu skaliert und es progressiv macht, wie es der Server für angemessen hält.
In unterschiedlichem Maße existiert dies mit CloudFlare, Metacdn.com, Amazon und Rackspace Load Balancern, Citrix Netscaler ADC und so weiter. AOL Dialup hatte serverseitige Bildrekompression.
Das wäre eine großartige Idee, selbst wenn es nur darum ginge, ob die Verbindung WLAN war oder nicht. Ich denke immer an die Umstände, wenn das Drehen von Hoch- zu Querformat ein neues Set von „breiteren“ Bildern zum Download auslöst.