Bild nachladen

[Jürgen]

Hi, (wie) ist es möglich beim Überfahren eines kleinen Bildes die dazugehörige speicherfressende Großversion des Bildes anzuzeigen, aber so, dass das große Bild erst nach dem Aufruf geladen wird? Und geht dies mit CSS und ohne Javascript? Grüße Jürgen

[Gunnar Bittersmann]

@@Jürgen

(wie) ist es möglich beim Überfahren eines kleinen Bildes die dazugehörige speicherfressende Großversion des Bildes anzuzeigen, aber so, dass das große Bild erst nach dem Aufruf geladen wird?

Was ist das für eine user experience, wenn beim Überfahren nichts passiert, sondern erst Sekunden später?

Der richtige Zeitpunkt, das große Bild zu laden, wäre vielleicht eher nach dem Rendern der Seite, ohne das dieses dadurch blockiert würde – aber bevor der Nutzer über das Vorschaubild fährt.

Wobei „groß“ nicht groß sein sollte, sondern fürs Web optimiert. Am besten responsive images, also verschiedene Bilddateien für verschiedene Viewportgrößen und Displayauflösungen.

Und geht dies mit CSS und ohne Javascript?

Ja, sollte gehen. Müsste aber auch erst nachlesen, welches Element dazu display: none verpasst bekommen müsste. IIRC nicht das img, sondern ein Vorfahrenelement.

Nachtrag: Ich glaube, Jake Archibald hatte dazu mal was geschrieben.

LLAP

[Jürgen]

Danke Gunnar,

Was ist das für eine user experience, wenn beim Überfahren nichts passiert, sondern erst Sekunden später?

Das ist wohl wahr-habe ich nicht bedacht.

Der richtige Zeitpunkt, das große Bild zu laden, wäre vielleicht eher nach dem Rendern der Seite, ohne das dieses dadurch blockiert würde – aber bevor der Nutzer über das Vorschaubild fährt.

Wie kann ich den Zeitpunkt des Ladens steuern?

Nachtrag: Ich glaube, Jake Archibald hatte dazu mal was geschrieben.

Einige seiner Artikel habe ich gefunden, aber noch nicht den richtigen. Ich werde jetzt auch außerhalb von Selfhtml nach ihm suchen. Grüße Jürgen

[Gunnar Bittersmann]

@@Jürgen

Wie kann ich den Zeitpunkt des Ladens steuern?

Mit JavaScript.

Nachtrag: Ich glaube, Jake Archibald hatte dazu mal was geschrieben. Einige seiner Artikel habe ich gefunden, aber noch nicht den richtigen.

Vielleicht war’s auch wer anders. Chris Coyier (CSS-Tricks)?

Irgendwer hatte mal untersucht, ob ein Bild <div><img src="…" alt="…"/></div> geladen wird, wenn
a) img { display: none }
b) div { display: none }

Oder einfach mal selbst testen.

LLAP

[1unitedpower]

Irgendwer hatte mal untersucht, ob ein Bild <div><img src="…" alt="…"/></div> geladen wird, wenn
a) img { display: none }
b) div { display: none }

Ja, das hatte ich auch mal gelesen. Das Problem mit diesem Hack ist, dass er von der Implementierung des Browsers abhängt, also können Unterschiede Browsern und Versionsnummern auftreten.

Der sichere Weg wäre das <link>-Element zu benutzen:

<link rel="prefetch" href="ultrasaurus-4k-uncompressed.png">

Auf diese Weise wird das Bild so früh wie möglich geladen, blockiert aber andererseits nicht die Rendering-Pipeline.

[Gunnar Bittersmann]

@@1unitedpower

<link rel="prefetch" href="ultrasaurus-4k-uncompressed.png">

Auf diese Weise wird das Bild so früh wie möglich geladen,

Hm, das Bild.

Aber nicht eins aus mehreren. Das verträgt sich nicht mit responsive images (picture, srcset).

LLAP

[1unitedpower]

<link rel="prefetch" href="ultrasaurus-4k-uncompressed.png">

Auf diese Weise wird das Bild so früh wie möglich geladen,

Hm, das Bild.

Aber nicht eins aus mehreren. Das verträgt sich nicht mit responsive images (picture, srcset).

Ich sehe da kein Problem. Initial kann der Browser selbstverständlich weiterhin frei aus den Bildern, die im srcset notiert sind, wählen. Die vergrößerte Ansicht gibt es dann auf Anfrage, das ist dann das hochauflösendste/detailsreichste Bild, das wir mit link[prefetch] vorladen wollen.

[Gunnar Bittersmann]

@@1unitedpower

Ich sehe da kein Problem. Initial kann der Browser selbstverständlich weiterhin frei aus den Bildern, die im srcset notiert sind, wählen.

Für das Vorschaubild ist das aber nicht unbedingt notwendig, sondern für das große Bild.

Die vergrößerte Ansicht gibt es dann auf Anfrage, das ist dann das hochauflösendste/detailsreichste Bild, das wir mit link[prefetch] vorladen wollen.

Und dann wurde evtl. ein für dieses Display unnötig großes Bild vorgeladen.

LLAP

[1unitedpower]

Ich sehe da kein Problem. Initial kann der Browser selbstverständlich weiterhin frei aus den Bildern, die im srcset notiert sind, wählen.

Für das Vorschaubild ist das aber nicht unbedingt notwendig, sondern für das große Bild.

Ah, ich glaube wir haben bis jetzt aneinander vorbei geredet. Ich bin bisher von der Sitation ausgegangen, dass die Vorschaubilder auf die Endgeräte der Benutzer zugeschnitten sind, und auf Anfrage gibt es dann die maximale Version des Bildes mit allen Details, unabhänig vom Endgerät des Nutzers. Du gehst offenbar von der umgekehrten Situation aus, dass die vergrößerte Version auf das Endgerät abgestimmt wird. Verstehe ich dich jetzt richtig? Jürgen, selbe Frage.

[Gunnar Bittersmann]

@@1unitedpower

Ah, ich glaube wir haben bis jetzt aneinander vorbei geredet. Ich bin bisher von der Sitation ausgegangen, dass die Vorschaubilder auf die Endgeräte der Benutzer zugeschnitten sind, und auf Anfrage gibt es dann die maximale Version des Bildes mit allen Details, unabhänig vom Endgerät des Nutzers. Du gehst offenbar von der umgekehrten Situation aus, dass die vergrößerte Version auf das Endgerät abgestimmt wird. Verstehe ich dich jetzt richtig?

Ja. Beim Vorschaubild ist es noch recht egal, ob da nun 5 kB oder 50 kB übertragen werden. Beim großen Bild machen 50 kB vs. 500 kB den Unterschied.

LLAP

[1unitedpower]

Ja. Beim Vorschaubild ist es noch recht egal, ob da nun 5 kB oder 50 kB übertragen werden. Beim großen Bild machen 50 kB vs. 500 kB den Unterschied.

Aber wenn es einfach nur Sinn der Übung ist, dem Nutzer Zugriff auf die detailreichste Fassung zu geben, dann wäre das Ziel verfehlt, wenn man ihm auch in der Großfassung wieder nur eine abgespeckte anbietet. Beide Szenarien sind für mich vorstellbar.

Btw. Download-Volumen ist ein billiges Gut. Viel schlimmer ist es, wenn man ein Bild nicht unmittelbar anzeigen kann, wenn es gebraucht wird.

[Gunnar Bittersmann]

@@1unitedpower

Download-Volumen ist ein billiges Gut.

Sagte der Mobilfunk-Surfer, als sein monatliches Datenvolumen („Flatrate“ genannt) aufgebraucht war.

LLAP

[1unitedpower]

@@1unitedpower

Download-Volumen ist ein billiges Gut.

Sagte der Mobilfunk-Surfer, als sein monatliches Datenvolumen („Flatrate“ genannt) aufgebraucht war.

Ich sag ja nicht, dass man die Leitung des Nutzers unnötig belasten sollte. Ich sage nur, dass man keine Tradeoffs zu Gunsten des Download-Volumens eingehen sollte, wenn darunter andere, wichtige Funktionen zu leiden hätten, schnelle Reaktionszeit zähle ich dazu. Im übrigen kannst du eh nicht vorherbestimmen, ob der Nutzer mit Mobilfunk auf deiner Seite surft oder doch aus dem heimischen WLAN-Netzwerk, mit so einem Tradeoff würdest du also auch die User Experience derjenigen verschelchtern, die eine Leitung ohne Volumenbegrenzung zur Verfügung haben.

[Jürgen]

@@you both danke für Euer Engagement. Ich habe Eure Beiträge genau gelesen, aber als rel. Neuling kann ich daraus nicht entnehmen, wie ich vorgehen muss. Grüße Jürgen

[suit]

Ja, sollte gehen. Müsste aber auch erst nachlesen, welches Element dazu display: none verpasst bekommen müsste. IIRC nicht das img, sondern ein Vorfahrenelement.

Warum überhaupt ein einzelnes "das" img-Element und nicht ein picture-Element mit mehren source-Kindern und als "Fallback" ein img-Element mit dem Bild in pervers großer Originalgröße?

Die Logik, nur das Bild zu render, was wirklich gebraucht wird, obliegt dann dem Browser - und auf Benutzerinteraktion hin, kann dann das durch den Browser unterdrückte Bild nachgeladen werden.

Dass das aus UX-Sicht nicht unbedingt der Knaller ist, mag schon stimmen - nur habe ich es z.B. nicht gerne, wenn im Hintergrund Daten geladen werden, weil jemand meint, dass es für die UX gut ist, wenn er die "riesigen Vorschaubilder" nachläd.

Das ist dann zwar komfortabel, aber ich hab' mal gehört, dass bei euch in Deutschland das Datenvolumen bei Mobilfunkverträgen noch mit Gold aufgewogen wird - wenn da unnötigerweise eine Hand voll Vorschaubilder mit ein paar MB geladen werden, sind da die 50 MB monatlich schnell weg :p

[1unitedpower]

Dass das aus UX-Sicht nicht unbedingt der Knaller ist, mag schon stimmen - nur habe ich es z.B. nicht gerne, wenn im Hintergrund Daten geladen werden, weil jemand meint, dass es für die UX gut ist, wenn er die "riesigen Vorschaubilder" nachläd.

Das sehe ich anders, denn was die meisten User viel mehr stören dürfte ist, das detailreiche Bild gar nicht oder erst verzögert zu Gesicht zu bekommen, wenn sie es wirklich sehen möchten. Das könnte zum Beispiel passieren, wenn die Verbindung vor dem Zeitpunkt, an dem die Großfassung vom Nutzer explizit angefragt wird, getrennt wird (Funkloch? Grenzübergang?). Deshalb ist es gut, das Bild so früh wie möglich zu laden und nicht so spät wie nötig. Oder es könnte passieren, dass das Absetzen der Anfrage so lange dauert, dass es vom Nutzer gänzlich unbemerkt bleibt, dann erhält er vermutlich nur den Eindruck, dass mit der Seite irgendetwas nicht stimmt.

Ein Bild, welches vorgeladen und dann vom Nutzer nie explizit angefordert wird, ist natürlich Verschwendung, aber einerseits landet das Bild im Cache und steht damit auf Abruf bereit und andererseits bleibt diese Verhalten vom Nutzer unbemerkt, er wird es der Seite also auch nicht negativ anlasten. Zudem gibt es ja für Technik-Geeks die Möglichkeit das optimistische Vorladen per Browser-Einstellung zu unterbinden. Man hat also eine Wahlmöglichkeit, aber per Default versucht man es der technisch weniger versierten Gruppe so angenehm wie möglich zu machen.

Das ist dann zwar komfortabel, aber ich hab' mal gehört, dass bei euch in Deutschland das Datenvolumen bei Mobilfunkverträgen noch mit Gold aufgewogen wird - wenn da unnötigerweise eine Hand voll Vorschaubilder mit ein paar MB geladen werden, sind da die 50 MB monatlich schnell weg :p

50MB Tarife sind 2015 auch nicht mehr der Stand der Dinge. Außerdem werden die Nutzer, deren Datenvolumen tatsächlich überschritten wird, wohl als aller erstes genervt auf ihren Provider reagieren, der ihnen das Paket als Flatrate verkauft hat, und nicht sofort deine Webseite verdächtigen. Die skeptischen User werden sich vielleicht noch eine Statistik über die Traffic-Verbraucher zu Rate nehmen und dann nüchtern feststellen, dass der Flaschenhals wirklich ganz woanders liegt und ihr Frust richtet sich dann auch nicht gegen die Webseite.

Auf der anderen Seite, reagieren Nutzer natürlich zurecht genervt darauf, wenn eine Internetseite langsam lädt oder verzögert reagiert, auch wenn sie sich mit ihrem Smartphone oder Tablet im heimischen WLAN-Netzwerk befinden. Den Punkt hatte ich bereits angesprochen, es ist eben technisch nicht möglich die Volumenbegrenzung, mit der ein Nutzer die Webseite betritt, vorherzusagen, wieso also pessimistisch vorgehen und auch jenen Nutzern eine schlechtere UX bieten, die eigentlich eine unbeschränkte Leitung zur Verfügung haben?

[suit]

Das sehe ich anders, denn was die meisten User viel mehr stören dürfte ist, das detailreiche Bild gar nicht oder erst verzögert zu Gesicht zu bekommen, wenn sie es wirklich sehen möchten.

Glaube ich nicht, die meisten Benutzer sind daran gewöhnt, dass im "Internet" etwas "laden" muss.

Das könnte zum Beispiel passieren, wenn die Verbindung vor dem Zeitpunkt, an dem die Großfassung vom Nutzer explizit angefragt wird, getrennt wird (Funkloch? Grenzübergang?).

Was passiert, wenn die Verbindung abreisst, bevor das Bild vorab gelanden werden kann?

Deshalb ist es gut, das Bild so früh wie möglich zu laden und nicht so spät wie nötig. Oder es könnte passieren, dass das Absetzen der Anfrage so lange dauert, dass es vom Nutzer gänzlich unbemerkt bleibt, dann erhält er vermutlich nur den Eindruck, dass mit der Seite irgendetwas nicht stimmt.

Nein, dann sagt dir der Browser idR., dass keine Internetverbindung besteht :)

Ein Bild, welches vorgeladen und dann vom Nutzer nie explizit angefordert wird, ist natürlich Verschwendung,

Ja, das ist mein primäres Argument.

aber einerseits landet das Bild im Cache und steht damit auf Abruf bereit und andererseits bleibt diese Verhalten vom Nutzer unbemerkt, er wird es der Seite also auch nicht negativ anlasten.

Da hast du einen Denkfehler - warum soll man den Cache "zumüllen", wenn das Bild nicht gebraucht wird, wenn er es nie braucht? Wenn ich unterwegs einen Wikipedia-Artikel lese, weil ich schnell was nachlesen will, reichen mir die "Briefmarken" und ich muss sie nicht vergrößern - obwohl das Datenvolumen nicht mein Problem ist.

Zudem gibt es ja für Technik-Geeks die Möglichkeit das optimistische Vorladen per Browser-Einstellung zu unterbinden.

Das ist die Standardeinstellung so ziemlich jedes Browsers: unsichtbare Ressourcen werden nicht geladen :) wenn man das Preloading dann z.B. per JavaScript umgeht, hat man keine (einfache) Möglichkeit mehr, das zu umgehen - auf Mobilgeräten ist das nicht so einfach wie am Desktop, selbst für "Geeks"

Man hat also eine Wahlmöglichkeit, aber per Default versucht man es der technisch weniger versierten Gruppe so angenehm wie möglich zu machen.

Das halte ich für den falschen Weg - wie z.B. das hinzufügen von "Drucken"-Buttons, die die Browsereigene Druckfunktion auslösen, genau derselbe Blödsinn.

50MB Tarife sind 2015 auch nicht mehr der Stand der Dinge.

Ich habe das in meiner blauäugigen Art und weise mit Tarifen in Österreich verglichen :) und das schnell mal jetzt mit O2 gegengecheckt:

500 MB Datenvolumen um rund 20 Euro monatlich, 1 GB um 30 Euro und weitere 100 MB kosten dann je 2 Euro, bei 21 MBit/s - mag schon sein, dass das für euch in Deutschland billig klingt, aber für mich als Österreicher wirkt das fast wie Beutelschneiderei. Bei uns bekommst du für einen 10er im Monat 2 bis 3 GB Datenvolumen mit voller Bandbreite und dann wird dir entweder ohne Zusatzkosten die Verbindungsgeschwindigkeit gedrosselt oder du zahlst für weitere 100 MB je rund 90 Cent.

Ich bin nicht bereit für Telefonie/Datendienste so viel Geld auszugeben - und viele andere aufgrund der Tarifsituation und den großzügigen Volumina auch nicht - und trotzdem kann man das Datenvolumen nicht einfach verschwenden, ein paar GB sind schnell weg - ein bisschen Musik streamen, ein bisschen Video schauen, ein paar Nachrichten im Messenger schicken - und wenn du dann mit bereits aufgebrauchtem Datenvolumen auf eine Website gehst, dir dir für einen Aufruf quasi 25 Cent abknöpft, weil sie dir rund 10 MB Bilder im Hintergrund runterläd, wirst du dir nachher gut überlegen, ob du das nochmal machst.

Außerdem werden die Nutzer, deren Datenvolumen tatsächlich überschritten wird, wohl als aller erstes genervt auf ihren Provider reagieren, der ihnen das Paket als Flatrate verkauft hat, und nicht sofort deine Webseite verdächtigen. Die skeptischen User werden sich vielleicht noch eine Statistik über die Traffic-Verbraucher zu Rate nehmen und dann nüchtern feststellen, dass der Flaschenhals wirklich ganz woanders liegt und ihr Frust richtet sich dann auch nicht gegen die Webseite.

wieso also pessimistisch vorgehen und auch jenen Nutzern eine schlechtere UX bieten, die eigentlich eine unbeschränkte Leitung zur Verfügung haben?

Weil es das Standardverhalten darstellt und erwartungskonform ist?

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

ich geb Dir 10, weil fünf nicht geht:

Was ich eigentlich noch einwerfen wollte: Es ist selten das Datenvolumen, das kneift, sondern die Verbindungsgeschwindigkeit die nicht zur Verfügung steht. Wie lange soll ich denn warten, bis die Seite fertig ist und ich weitermachen kann?

Ich habe das in meiner blauäugigen Art und weise mit Tarifen in Österreich verglichen :) und das schnell mal jetzt mit O2 gegengecheckt:

500 MB Datenvolumen um rund 20 Euro monatlich, 1 GB um 30 Euro und weitere 100 MB kosten dann je 2 Euro, bei 21 MBit/s - mag schon sein, dass das für euch in Deutschland billig klingt, aber für mich als Österreicher wirkt das fast wie Beutelschneiderei. Bei uns bekommst du für einen 10er im Monat 2 bis 3 GB Datenvolumen mit voller Bandbreite und dann wird dir entweder ohne Zusatzkosten die Verbindungsgeschwindigkeit gedrosselt oder du zahlst für weitere 100 MB je rund 90 Cent.

Deshalb hätte ich nur fünf gegeben.
Auch in DE kann man für 9,99 bei namhaften Anbietern 3GB im Monat bekommen bei hsdpa+ oder sogar lte. Und man kann dann mit seinem Tablet oder Smartphone auch telefonieren (na sowas!), manchmal sogar mit Kontingent an Freiminuten oder sogar Flatrate in alle deutsche Netze. Muss man eben aufpasssen.

Ich bin nicht bereit für Telefonie/Datendienste so viel Geld auszugeben -

Das ist das Problem. Man schließt einen "rundum-sorglos-Vertrag" ab und muss dann nachher feststellen, dass die 45€, die ursprünglich mal Vertragswert waren (für Home-Anschluss und Mobile zusammen), dann doch durch viele viele klitzekleine Zusatzkosten auf das Doppelte steigen können. ALleine der unbdachte Anruf bei einer Auskunft (ohne Weitervermittlung) kostet schon 5,50€. Das wird dann erst einen Monat später abgerechnet unter einen anderen Kundennummer und man wundert sich, wofür da mal wieder 'was berechnet wird.

Spirituelle Grüße
Euer Robert
[e-mail]

[suit]

Was ich eigentlich noch einwerfen wollte: Es ist selten das Datenvolumen, das kneift, sondern die Verbindungsgeschwindigkeit die nicht zur Verfügung steht. Wie lange soll ich denn warten, bis die Seite fertig ist und ich weitermachen kann?

Aus dem Grund ist es wichtig, die Vorschaubilder so klein wie möglich zu machen :) dass man für das "Bild in voller Auflösung" dann warten muss, ist einem durchschnittlichen Benutzer klar.

Das ist aber technisch dann kein Problem mehr, denn die Verbindungsgeschwindigkeit ist, im Gegensatz zum Datenvolumen, serverseitig messbar - CDN-Anbieter wie z.B. Akamai stellen hier sogar Frameworks bereit, die dem Client dann entsprechend komprimierte Bilder abhängig von Standort und Geschwindigkeit ausliefern.

Deshalb hätte ich nur fünf gegeben.
Auch in DE kann man für 9,99 bei namhaften Anbietern 3GB im Monat bekommen bei hsdpa+ oder sogar lte. Und man kann dann mit seinem Tablet oder Smartphone auch telefonieren (na sowas!), manchmal sogar mit Kontingent an Freiminuten oder sogar Flatrate in alle deutsche Netze. Muss man eben aufpasssen.

Als "unwissender" muss man sich hier leider auf die Werbung der "großen" verlassen - und wenn man das mit der Werbung der "großen" in Österreich vergleicht, ist die Kluft zwischen den Tarifen sehr groß.

Hast du hier ggf. ein Beispiel für mich? Einer meiner Kollegen hat einen deutschen Vertrag und bezahlt einen 10er im Monat für 100 MB Datenvolumen :)

Ich bin nicht bereit für Telefonie/Datendienste so viel Geld auszugeben -

Das ist das Problem. Man schließt einen "rundum-sorglos-Vertrag" ab und muss dann nachher feststellen, dass die 45€, die ursprünglich mal Vertragswert waren (für Home-Anschluss und Mobile zusammen), dann doch durch viele viele klitzekleine Zusatzkosten auf das Doppelte steigen können. ALleine der unbdachte Anruf bei einer Auskunft (ohne Weitervermittlung) kostet schon 5,50€. Das wird dann erst einen Monat später abgerechnet unter einen anderen Kundennummer und man wundert sich, wofür da mal wieder 'was berechnet wird.

Das "Kleingedruckte" mit versteckten Zusatzkosten ist in Deutschland deutlich länger als in Österreich - wir haben im internationalen Vergleich so ziemlich die günstigsten Telefonie-Kosten.

Dass sich das in Zukunft annähern wird, ist aber klar - breits 15 sind für EU-Weites Roaming grenzen gesetzt worden und in ein paar Jahren soll es gar keine Roaming-Kosten mehr geben: mit anderen Worten, Telefonieren wird bei euch billiger und bei uns teuerer :)

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

Das ist aber technisch dann kein Problem mehr, denn die Verbindungsgeschwindigkeit ist, im Gegensatz zum Datenvolumen, serverseitig messbar - CDN-Anbieter wie z.B. Akamai stellen hier sogar Frameworks bereit, die dem Client dann entsprechend komprimierte Bilder abhängig von Standort und Geschwindigkeit ausliefern.

Das interessiert mich sehr. Kann ich das auf einem simplen Apache-Server mit PHP usw. irgendwie einfach umsetzen? Wir liefern die Bilder wegen rechtlicher Beschränkungen ohnehin alle per Skript aus. Da würde ein Stückchen mehr Skript vermutlich auch nicht mehr ins Gewicht fallen. Ich kann mir nun nur nicht vorstellen, wie man da während des Runterladens noch die Kompression des Bildes ändern will?

Außerdem schwankt die Übertragungsgüte im ländlichen Bereich auch sehr. Liegt wohl am Sonnenstand ;-) Mal hast Du gerade mal EDGE, einen Moment später steht HSDPA+ zur Verfügung. Und dann ist das ja auch nur die theoretische Geschwindigkeit. Wenn viele Teilnehmer in der Zelle untrwegs sind, bricht das auch noch zusammen.

Spirituelle Grüße
Euer Robert
[e-mail]

[suit]

Das ist aber technisch dann kein Problem mehr, denn die Verbindungsgeschwindigkeit ist, im Gegensatz zum Datenvolumen, serverseitig messbar - CDN-Anbieter wie z.B. Akamai stellen hier sogar Frameworks bereit, die dem Client dann entsprechend komprimierte Bilder abhängig von Standort und Geschwindigkeit ausliefern.

"Kein Problem" war eine überspitzte Formulierung, eine Lösung lässt sich schnell basteln, eine "funktionierende" Lösung zu finden ist ungleich schwieriger.

Das hat das W3C ebenfalls festgestellt, als es dazu Pläne gab eine Art "Media Queries" für die Verbindungsgeschwindigkeit zu erstellen: http://www.w3.org/TR/netinfo-api/

Das interessiert mich sehr. Kann ich das auf einem simplen Apache-Server mit PHP usw. irgendwie einfach umsetzen?

"Ja - aber ..." :)

Im Prinzip musst du "nur" nach "jedem" Response messen, wie lange es gedauert hat :) eine einfache Lösung ist es z.B. ein eine kleine Datei, z.B. ein Bild irgendwo ins Dokument zu hängen und mit JavaScript wird gemessen, wie lange es vom Request bis zum load-Event dauert, diese Information wird dann zum Server geschickt und in der Session des Benutzers abgelegt.

Das Problem daran ist, dass sich die Verbindungsgeschwindigkeit ändern kann - grade kann das Gerät der Browser etwas hängen und die Ladezeit ist deshalb langsam - dann wieder hängt der Benutzer im WLAN und geht kurz aufs Klo wo der Access-Point keinen Empfang hat und er muss mit Edge weiter surfen.

Du kannst also erst nachher wissen, was er gebraucht hat und daher möglichst "schlecht" raten.

Wir liefern die Bilder wegen rechtlicher Beschränkungen ohnehin alle per Skript aus. Da würde ein Stückchen mehr Skript vermutlich auch nicht mehr ins Gewicht fallen. Ich kann mir nun nur nicht vorstellen, wie man da während des Runterladens noch die Kompression des Bildes ändern will?

Eben nicht während, sondern davor - beim ersten Bild wird es getestet und der Server muss dann on the fly bei allen Requests die noch nicht beantwortet sind anders reagieren - dafür braucht man aber auch die entsprechende Leistung um die Bilder in Echtzeit herunterzurechnen.

Daher gibts für sowas bereits "fertige" im Browser implementierte Lösungen die der Nutzer bewusst steuern kann - der Opera-Offroad-Modus tut das z.B.

Außerdem schwankt die Übertragungsgüte im ländlichen Bereich auch sehr. Liegt wohl am Sonnenstand ;-) Mal hast Du gerade mal EDGE, einen Moment später steht HSDPA+ zur Verfügung. Und dann ist das ja auch nur die theoretische Geschwindigkeit. Wenn viele Teilnehmer in der Zelle untrwegs sind, bricht das auch noch zusammen.

Korrekt :)

[Gunnar Bittersmann]

@@suit

der Server muss dann on the fly bei allen Requests die noch nicht beantwortet sind anders reagieren - dafür braucht man aber auch die entsprechende Leistung um die Bilder in Echtzeit herunterzurechnen.

Vermutlich ist Speicherplatz billiger als Rechenleistung. Der Server wird also alle bereits berechneten Varianten eines Bildes speichern und bei einer Anfrage prüfen, ob es schon eine passende Datei gibt und nur andernfalls rechnen.

LLAP

[suit]

der Server muss dann on the fly bei allen Requests die noch nicht beantwortet sind anders reagieren - dafür braucht man aber auch die entsprechende Leistung um die Bilder in Echtzeit herunterzurechnen.

Vermutlich ist Speicherplatz billiger als Rechenleistung. Der Server wird also alle bereits berechneten Varianten eines Bildes speichern und bei einer Anfrage prüfen, ob es schon eine passende Datei gibt und nur andernfalls rechnen.

Das ist richtig - meine Gedanke war nur, dass man keine eigene Routine braucht um den Cache der generierten Bildversionen zu erzeugen sondern eben schaut ob es eine bestimmte Größe schon gibt und wenn nicht, wird sie erzeugt.

Aber ja, wenn es tatsächlich um eine möglichst sinnvolle Lösung geht, erzeugt man alle Bilder vorab in bestimmten Schritten und nicht wirklich exakt spezifisch auf die Anforderungen hin.

[Gunnar Bittersmann]

@@robertroth

Was ich eigentlich noch einwerfen wollte: Es ist selten das Datenvolumen, das kneift,

Doch. Genau darum geht es hier: die Abwägung der Folgen für den Nutzer von false positive (Bild wird vorgeladen, obwohl es nicht benötigt wird) gegenüber false negative (Bild wird nicht vorgeladen; schlechte UX, wenn es doch benötigt wird).

Und bei dieser Abwägung ist das begrenzte Datenvolumen der sogenannten „Flatrates“ ein entscheidender Punkt. In einer idealen Welt gäbe es auch dafür einen Media-Query, sodass man die Entscheidung nicht als Seitenautor treffen muss, sondern der Nutzer sie in der Hand hat (Einstellung im Browser, evtl. dynamische Anpassung nahand des schon verbrauchten Datenvolumens).

sondern die Verbindungsgeschwindigkeit die nicht zur Verfügung steht. Wie lange soll ich denn warten, bis die Seite fertig ist und ich weitermachen kann?

Gar nicht. Das Vorladen evtl. benötigter zusätzlicher Ressourcen beginnt natürlich erst nach dem Rendern der Seite und steht der Nutzerinteraktion nicht im Wege.

LLAP

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

Was ich eigentlich noch einwerfen wollte: Es ist selten das Datenvolumen, das kneift,

Doch. Genau darum geht es hier: die Abwägung der Folgen für den Nutzer von false positive (Bild wird vorgeladen, obwohl es nicht benötigt wird) gegenüber false negative (Bild wird nicht vorgeladen; schlechte UX, wenn es doch benötigt wird).

Und bei dieser Abwägung ist das begrenzte Datenvolumen der sogenannten „Flatrates“ ein entscheidender Punkt. In einer idealen Welt gäbe es auch dafür einen Media-Query, sodass man die Entscheidung nicht als Seitenautor treffen muss, sondern der Nutzer sie in der Hand hat (Einstellung im Browser, evtl. dynamische Anpassung nahand des schon verbrauchten Datenvolumens).

sondern die Verbindungsgeschwindigkeit die nicht zur Verfügung steht. Wie lange soll ich denn warten, bis die Seite fertig ist und ich weitermachen kann?

Gar nicht. Das Vorladen evtl. benötigter zusätzlicher Ressourcen beginnt natürlich erst nach dem Rendern der Seite und steht der Nutzerinteraktion nicht im Wege.

Der Browser ist nicht blockiert solange?

Wenn er denn nach dem Schema "letzte Bedienungshandlung gilt" arbeiten würde, wäre das ja achon mal super. Aber solange ein Download (im Hintergrund) läuft, reagiert das Teil meistens gar nicht auf Benutzerhandlungen. Ein User Abort ist da wohl nicht vorgesehen.

Spirituelle Grüße
Euer Robert
[e-mail]

[1unitedpower]

Der Browser ist nicht blockiert solange?

Nein. Lies die FAQ, die hier schon zwei Mal verlinkt habe.

Wenn er denn nach dem Schema "letzte Bedienungshandlung gilt" arbeiten würde, wäre das ja achon mal super. Aber solange ein Download (im Hintergrund) läuft, reagiert das Teil meistens gar nicht auf Benutzerhandlungen. Ein User Abort ist da wohl nicht vorgesehen.

Zumindest objektiv betrachtet, liegst du hier falsch. Blockierende Anfragen gibt es in natura nur beim intialen Seiteaufbau, da können Stylesheets und Skriptdateien, die nicht mit [async] oder [defer] ausgezeichnet sind, und die sich nicht am Ende des Bodys befinden, das Rendering blockieren. In allen anderen Fällen, werden Netzwerk-Operationen von deinem Browser immer nicht-blockierend ausgeführt, du müsstest ihn schon mit Gewalt dazu zwingen, das Gegenteil zu tun, zum Beispiel indem du einen XMLHttpRequest ausdrücklich synchron auslöst, das ist aber ein Fall, den man immer vermeiden kann. Deine subjektive Wahrnehmung kann davon natürlich abweichen, insbesondere wenn du mit schwächerer Hardware hantierst, kannst du zu dem Eindruck gelangen, dass ein Download dein User-Interface blockiert, aber dann nimmst du vermutlich auch ganz andere Probleme mit der Performanz deines Gerätes wahr. Wenn dich das Thema interessiert, informier dich mal über den Event-Loop, dabei handelt es sich um den wesentlichen Baustein, der asynchronen Kontrollfluss in deinem Browser ermöglicht.

[1unitedpower]

Zur Erinnerung, ich habe keine Lösung mit JavaScript angestrebt, sondern eine Lösung basierend auf dem <link>-Element, mit rel="prefetch"-Attribut. Das ist eine Möglichkeit auf reiner HTML-Basis, dem Browser einen Hinweis darauf zu geben, dass die verlinkte Ressource mit hoher Wahrscheinlichkeit benötigt wird. Es obliegt dann dem Browser zu entscheiden, ob er die Ressouce optimistisch herunterlädt, oder ob er den Hinweis ignoriert. Die Standard-Einstellung der Browser ist es optimistisch zu sein und die Dateien herunterzuladen, man kann es aber explizit unterdrücken, wenn das ungewünscht. Ich wiederhole das nochmal, weil einige deiner Kritikpunkte offenbar auf der Missannahme beruhen, ich strebe eine Lösung mit JavaScript an.

Das sehe ich anders, denn was die meisten User viel mehr stören dürfte ist, das detailreiche Bild gar nicht oder erst verzögert zu Gesicht zu bekommen, wenn sie es wirklich sehen möchten.

Glaube ich nicht, die meisten Benutzer sind daran gewöhnt, dass im "Internet" etwas "laden" muss.

"Nur weil man sich so dran gewöhnt hat, ist es nicht, noch lange nicht, egal" - Kettcar Ein gutes Design agiert subtil im Hintergrund und macht sich eben nicht bemerkbar, mehr will ich dazu nicht sagen.

Das könnte zum Beispiel passieren, wenn die Verbindung vor dem Zeitpunkt, an dem die Großfassung vom Nutzer explizit angefragt wird, getrennt wird (Funkloch? Grenzübergang?).

Was passiert, wenn die Verbindung abreisst, bevor das Bild vorab gelanden werden kann?

Vorab laden bedeutet bei der <link>-Lösung, das Bild nach allen anderen wichtigen Dateien zu laden, die für das intiale Rendering benötigt werden. Die Rendering-Pipeline wird also nicht blockiert. Wenn das geschehen ist, wird das Bild so schnell wie möglich geladen, also nach Möglichkeit, bevor der Nutzer es ausdrücklich anfordert. Das ist ein Vorgang der im Hintergrund geschieht, der Browser kann deswegen auf Netzwerk-Fehler reagieren, und das Bild ggf. erneut anfordern, wenn wieder eine Internet-Verbindung besteht.

Deshalb ist es gut, das Bild so früh wie möglich zu laden und nicht so spät wie nötig. Oder es könnte passieren, dass das Absetzen der Anfrage so lange dauert, dass es vom Nutzer gänzlich unbemerkt bleibt, dann erhält er vermutlich nur den Eindruck, dass mit der Seite irgendetwas nicht stimmt.

Nein, dann sagt dir der Browser idR., dass keine Internetverbindung besteht :)

Sollte die Antwort vielleicht auch einen Absatz weiter oben stehen? Auf jeden Fall gilt auch hier meine Maxime, ein gutes UI lässt es erst gar nicht so weit kommen, ein weniger gutes Interface benachrichtigt den User zumindest über den Fehler und ein schlechtes Interface bemerkt den Fehler selber nicht.

Ein Bild, welches vorgeladen und dann vom Nutzer nie explizit angefordert wird, ist natürlich Verschwendung,

Ja, das ist mein primäres Argument.

aber einerseits landet das Bild im Cache und steht damit auf Abruf bereit und andererseits bleibt diese Verhalten vom Nutzer unbemerkt, er wird es der Seite also auch nicht negativ anlasten.

Da hast du einen Denkfehler - warum soll man den Cache "zumüllen", wenn das Bild nicht gebraucht wird, wenn er es nie braucht? Wenn ich unterwegs einen Wikipedia-Artikel lese, weil ich schnell was nachlesen will, reichen mir die "Briefmarken" und ich muss sie nicht vergrößern - obwohl das Datenvolumen nicht mein Problem ist.

Ich wollte nur daran erinnern, dass es zwischen "Jetzt oder nie" auch noch die Fälle: "Jetzt oder später" gibt. Cache zumüllen lasse ich nicht als Kontra-Argument gelten, jeder Browser weiß, wie er seinen Cache sinnvoll verwaltet, das tangiert den Nutzer nicht im Geringsten.

Zudem gibt es ja für Technik-Geeks die Möglichkeit das optimistische Vorladen per Browser-Einstellung zu unterbinden.

Das ist die Standardeinstellung so ziemlich jedes Browsers: unsichtbare Ressourcen werden nicht geladen :) wenn man das Preloading dann z.B. per JavaScript umgeht, hat man keine (einfache) Möglichkeit mehr, das zu umgehen - auf Mobilgeräten ist das nicht so einfach wie am Desktop, selbst für "Geeks"

Wie bereits erwähnt, spreche ich nicht von einem JavaScript- oder CSS-Hack, sondern von einer Lösung basierend auf reinem HTML. Genau für diesen Fall bieten Browser eine Option an, um das optimistische Vorladen zu deaktivieren.

Ich bin nicht bereit für Telefonie/Datendienste so viel Geld auszugeben - und viele andere aufgrund der Tarifsituation und den großzügigen Volumina auch nicht - und trotzdem kann man das Datenvolumen nicht einfach verschwenden, ein paar GB sind schnell weg - ein bisschen Musik streamen, ein bisschen Video schauen, ein paar Nachrichten im Messenger schicken - und wenn du dann mit bereits aufgebrauchtem Datenvolumen auf eine Website gehst, dir dir für einen Aufruf quasi 25 Cent abknöpft, weil sie dir rund 10 MB Bilder im Hintergrund runterläd, wirst du dir nachher gut überlegen, ob du das nochmal machst.

Aber der Flaschenhals sind hier doch ganz klar die gestreamten Videos und die Musik und nicht die paar Bilder, die eine Webseite mit sich bringt. Und wie gesagt, es gibt immer noch die Möglichkeit, das optimistische Vorladen durch eine Einstellung zu unterbindne.

wieso also pessimistisch vorgehen und auch jenen Nutzern eine schlechtere UX bieten, die eigentlich eine unbeschränkte Leitung zur Verfügung haben?

Weil es das Standardverhalten darstellt und erwartungskonform ist?

Ich erwarte von einer Webseite schnelle Reaktionszeiten, sie soll responsiv im eigentlichen Wortsinn sein, Wartezeiten passen da nicht ins Schema. Und Standardverhalten ist link[prefetch] wohl auch.

[suit]

Zur Erinnerung, ich habe keine Lösung mit JavaScript angestrebt, sondern eine Lösung basierend auf dem <link>-Element, mit rel="prefetch"-Attribut.

Das ist mir schon klar - nur wie stellt das der Geek in seinem Browser ein? Wo finde ich diese option z.B. unter Opera auf Android? :)

Unter Opera 12.x hatte man noch halbwegs kontrolle über die Prefetching-Funktionalitäten, aber in aktuellen Browser siehts da auch eher schlecht aus.

Vorab laden bedeutet bei der <link>-Lösung, das Bild nach allen anderen wichtigen Dateien zu laden, die für das intiale Rendering benötigt werden. Die Rendering-Pipeline wird also nicht blockiert.

Das ist mir klar, nur was passiert, wenn die Verbindung schon vorher abreisst, bevor die "anderen wichtigen Daten" geladen wurden? Dann ist der Benutzer auch unzufrieden - wo ist das Argument?

Sollte die Antwort vielleicht auch einen Absatz weiter oben stehen?

Möglicherweise, die Themen greifen ineinander :)

Auf jeden Fall gilt auch hier meine Maxime, ein gutes UI lässt es erst gar nicht so weit kommen, ein weniger gutes Interface benachrichtigt den User zumindest über den Fehler und ein schlechtes Interface bemerkt den Fehler selber nicht.

Unterschiede zwischen einer Website und einer "Web-App", deren User-Interface nach dem Initialen laden theoretisch ohne weiteren Datenverkehr auskommen muss. Bei einer App ist die UX deutlich wichtiger als bei einer Website, die "nur" Informationen transportiert.

Ich wollte nur daran erinnern, dass es zwischen "Jetzt oder nie" auch noch die Fälle: "Jetzt oder später" gibt. Cache zumüllen lasse ich nicht als Kontra-Argument gelten, jeder Browser weiß, wie er seinen Cache sinnvoll verwaltet, das tangiert den Nutzer nicht im Geringsten.

Das ist richtig, war ein schlechtes Argument.

Wie bereits erwähnt, spreche ich nicht von einem JavaScript- oder CSS-Hack, sondern von einer Lösung basierend auf reinem HTML. Genau für diesen Fall bieten Browser eine Option an, um das optimistische Vorladen zu deaktivieren.

Auf die man, wie oben erwähnt, de facto keinen Einfluss hat.

Aber der Flaschenhals sind hier doch ganz klar die gestreamten Videos und die Musik und nicht die paar Bilder, die eine Webseite mit sich bringt. Und wie gesagt, es gibt immer noch die Möglichkeit, das optimistische Vorladen durch eine Einstellung zu unterbindne.

Der Flaschenhals entsteht dann, wenn das Limit ausgeschöpft ist und man sich dann aufgrund der langsamen Verbindung oder den zusätzlichen Kosten überhaupt noch anschauen kann. Und dann eher eine Datenintensive Website meiden wird und auf die eines sparsameren Mitbewerbers geht.

Ich erwarte von einer Webseite schnelle Reaktionszeiten, sie soll responsiv im eigentlichen Wortsinn sein, Wartezeiten passen da nicht ins Schema. Und Standardverhalten ist link[prefetch] wohl auch.

Dafür gibt es Tonneweise andere Optimierungsmöglichkeiten - und eine Ressouren die man in Erwartungshaltung erst explizit anfordert per prefetch zu ziehen ist imho nicht im Sinne der Erfindung. Mozilla hat sich das aus den Fingern gesaugt um dem Benutzer Kontrolle über das Prefetching zu geben, damit es für den Benutzer transparent ist, was passiert.

Das jetzt als Freibrief für "ich kann eh alles nachladen, weil der Nutzer ja die Kontrolle hat" zu verstehen ist nicht weit genug gedacht, denn genau an den Stellen wo das ein Problem darstellt, lässt sich das Prefetching eben nicht (leicht) unterbinden.

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

Dass das aus UX-Sicht nicht unbedingt der Knaller ist, mag schon stimmen - nur habe ich es z.B. nicht gerne, wenn im Hintergrund Daten geladen werden, weil jemand meint, dass es für die UX gut ist, wenn er die "riesigen Vorschaubilder" nachläd.

Das sehe ich auch so. Die Systeme machen schon viel zu viel im Hintergrund, was wir nicht wissen und wenn wir es wüssten, auch nicht wollen würden.

Das sehe ich anders, [...]

Ich nehme das hier mal raus, weil das Posting sonst zu lang wird. Aber ich postuliere hier mal, dass Du selten in empfangsschwachen Gebieten unterwegs bist, in denen man sich freuen kann, wenn man überhaupt Internet per GSM hat. Ich bringe hier nochmal die gängigen Standards für mobiles Internet in Erinnerung.

Ich arbeite mit in einer "Studiengruppe für die touristische Vernetzung des Gebietes vom Rennsteig bis zum Harz". Da wird ein Geo-Spiel entwickelt. Ich bin häufig mit dem Tablet in der Natur unterwegs. Lappi ist mir im Rucksack zu schwer. Und wenn ich dann wieder mal einen interessanten Punkt für die Verdatung entdeckt habe, muss ich meistens kämpfen, den online in unsere Karten reinzubekommen (der Punkt muss später für das Spiel Onlinezugang haben!). Oft funktioniert noch nicht einmal das GPS-Modul (also quasi-offline arbeiten), weil die Satelliten irgendwie verdeckt sind durch Wald oder Berge.

Wenn ich hier jedes Mal das Nachladen von Bildern aufs Auge gedrückt bekommen würde, könnte ich den Versuch eines Verbindungsaufbaus zum Server gleich vergessen. Dann wäre die Verbindung nämlich sofort unbrauchbar.

Ich plädiere daher dafür, dass in der Titelleiste (oder an anderer Stelle, wo sowieso Eingabeelemente sitzen) eine Checkbox steht "[ ] alle Inhalte vorladen". Das ist bisher von den Machern der Studiengruppe inclusive der beiden Profs auch so akzeptiert worden, nachdem sie dann mal selber einen Tag draußen waren.

Ich wage deshalb danach zu fragen: Hast Du für deine Aussage überhaupt genügend eigene "User eXperience"?

Woran machst Du deine Aussagen fest? An städtischer Erfahrung?

Spirituelle Grüße
Euer Robert
[e-mail]

[1unitedpower]

Ich plädiere daher dafür, dass in der Titelleiste (oder an anderer Stelle, wo sowieso Eingabeelemente sitzen) eine Checkbox steht "[ ] alle Inhalte vorladen". Das ist bisher von den Machern der Studiengruppe inclusive der beiden Profs auch so akzeptiert worden, nachdem sie dann mal selber einen Tag draußen waren.

Du willst also einen redundanten, metaphorischen Druck-Button schaffen? Die Option, das link-prefetching zu deaktivieren, steckt nämlich bereits in deinem Browser.

Ich wage deshalb danach zu fragen: Hast Du für deine Aussage überhaupt genügend eigene "User eXperience"?

Und die Frage kotzt mich an. Diskutiere mit mir bitte inhaltlich und nicht ad-hominem.

[Tabellenkalk]

Hallo,

Diskutiere mit mir bitte inhaltlich und nicht ad-hominem.

Warum die Einschränkung "mit mir"?

Gruß
Kalk

[Camping_RIDER]

Aloha ;)

Ich möchte zu bedenken geben...

Ich plädiere daher dafür, dass in der Titelleiste (oder an anderer Stelle, wo sowieso Eingabeelemente sitzen) eine Checkbox steht "[ ] alle Inhalte vorladen". Das ist bisher von den Machern der Studiengruppe inclusive der beiden Profs auch so akzeptiert worden, nachdem sie dann mal selber einen Tag draußen waren.

Du willst also einen redundanten, metaphorischen Druck-Button schaffen? Die Option, das link-prefetching zu deaktivieren, steckt nämlich bereits in deinem Browser.

...dass es sich unter Umständen lohnt, eine gewisse Redundanz zu schaffen. Gerade dann, wenn die meisten Benutzer diese Einstellung nicht kennen oder sie nicht einfach erreichen können (siehe dazu suits Aussagen zu Opera/Android) ist eine solche Redundanz nicht unbedingt verkehrt.

Natürlich ist sowas eigentlich nicht Kerngeschäft des Webentwicklers - sondern, wie du schreibst, eigentlich eine Frage für den Browserhersteller.

Wenn die aber partout nicht mitziehen (lies: diese Operation nicht prominent genug anbieten) und ich meine User trotzdem nicht mit möglicherweise unerwünschtem Traffic belasten will, ist es mMn schon sinnvoll, so etwas vorsorglich abzufragen.

Es mag eine Zeit kommen, da das wieder überflüssig wird - aber im Moment bedeutet Mobil-Browser vor allem abgespeckter Browser - besonders was Einstellmöglichkeiten angeht.

Grüße,

RIDER

[1unitedpower]

...dass es sich unter Umständen lohnt, eine gewisse Redundanz zu schaffen. Gerade dann, wenn die meisten Benutzer diese Einstellung nicht kennen oder sie nicht einfach erreichen können (siehe dazu suits Aussagen zu Opera/Android) ist eine solche Redundanz nicht unbedingt verkehrt.

+1. Nach der persönlichen Attacke, habe ich den kühlen Kopf verloren. Der Hinweis auf den Druckbutton war dann billige Polemik meinerseits, weil suit ihn zuvor ins Gespräch hatte und der Vergleich so naheliegend war. Mit nüchternem Kopf, hätte ich es nun auch besser gefunden, ich hätte sachlich darauf aufmerksam gemacht, dass die Einstellungs-Möglichkeit bereits besteht, denn eigentlich teile ich deine differenzierte Meinung in diesem Punkt.

[Auge]

Hallo

Das sehe ich anders, denn was die meisten User viel mehr stören dürfte ist, das detailreiche Bild gar nicht oder erst verzögert zu Gesicht zu bekommen, wenn sie es wirklich sehen möchten. Das könnte zum Beispiel passieren, wenn die Verbindung vor dem Zeitpunkt, an dem die Großfassung vom Nutzer explizit angefragt wird, getrennt wird (Funkloch? Grenzübergang?). Deshalb ist es gut, das Bild so früh wie möglich zu laden und nicht so spät wie nötig. Oder es könnte passieren, dass das Absetzen der Anfrage so lange dauert, dass es vom Nutzer gänzlich unbemerkt bleibt, dann erhält er vermutlich nur den Eindruck, dass mit der Seite irgendetwas nicht stimmt.

1. Die Verbindung kann auch während des Vorladens abbrechen. Das ist also kein Argument dafür oder dagegen.
2. Dass größere Inhalte nicht unmittelbar zur Verfügung stehen, sondern nur mit etwas Verzögerung, ist ein dem Nutzer bekanntes Phänomen. Das mag stören, aber es wird im Allgemeinen „für normal“ gehalten.

Ein Bild, welches vorgeladen und dann vom Nutzer nie explizit angefordert wird, ist natürlich Verschwendung, aber einerseits landet das Bild im Cache und steht damit auf Abruf bereit …

Der Abruf der eventuell nie erfolgt, da er schon bei Besuch der Seite nicht erfolgte?

… und andererseits bleibt diese Verhalten vom Nutzer unbemerkt, er wird es der Seite also auch nicht negativ anlasten.

Wenn die 500-MB-„Flatrate“ schon lange vor Ende des Monats alle ist, mag das nicht der einzelnen Seite angelastet werden. Dort ist aber, wenn alle deiner Logik folgen, eine der Ursachen zu suchen. Unbemerkt bleibt das Verhalten, bzw. dessen Folgen, aber keineswegs.

Zudem gibt es ja für Technik-Geeks die Möglichkeit das optimistische Vorladen per Browser-Einstellung zu unterbinden. Man hat also eine Wahlmöglichkeit, aber per Default versucht man es der technisch weniger versierten Gruppe so angenehm wie möglich zu machen.

Mich als Nutzer grämt die Drosselung nach Verbrauch meiner Pseudo-Flatrate. Ich kenne, gerade wenn ich Nicht-Technik-Geek bin, die Einstellungsmöglichkeit nicht. Erst recht weiß ich nicht, dass Seitenautoren die mir nicht bekannte Einstellung umgehen können und nicht erwünschten und bei mir Mehrkosten erzeugenden Traffic verursachen. Was also dem „Technik-Geek“ zumindest teilweise möglich ist, nämlich das Unterbinden dieses für Mobilverbindungen nicht erwünschten Verhaltens, willst du mir, als nicht dieser Gruppe angehörendem Besucher deiner Seite, aufbürden?

Nette Logik.

50MB Tarife sind 2015 auch nicht mehr der Stand der Dinge. Außerdem werden die Nutzer, deren Datenvolumen tatsächlich überschritten wird, wohl als aller erstes genervt auf ihren Provider reagieren, der ihnen das Paket als Flatrate verkauft hat, und nicht sofort deine Webseite verdächtigen.

Der Benutzer mag nicht die Seite verdächtigen, aber wird er stattdessen den Provider nerven? Ich glaube nicht daran, dass er das tun wird. Bestenfalls nervt er den Provider mit dem Verlangen nach einem größeren Tarif.

Die skeptischen User werden sich vielleicht noch eine Statistik über die Traffic-Verbraucher zu Rate nehmen und dann nüchtern feststellen, dass der Flaschenhals wirklich ganz woanders liegt und ihr Frust richtet sich dann auch nicht gegen die Webseite.

Wieso? Deine Seite, die Daten lädt, die ich nicht nutzen wollte, ist der Flaschenhals. Wir können lange darüber diskutieren, dass uns die Mobilfunkprovider „Flatrates“ verkaufen, die keine sind, obwohl es da genaugenommen keiner Diskussionsbedarf gibt. Jeder Nutzer weiß aber, dass er einen Volumentarif mit z.B. 500MB, 1GB oder 3GB hat und danach die Datenrate einbricht oder weitere Datenpakete dazugekauft werden müssen. Dem musst du nicht noch Vorschub leisten, indem du dem Nutzer Daten überhilfst, die er nicht anfordert, die er mit einiger Wahrscheinlichkeit auch nicht haben will.

Auf der anderen Seite, reagieren Nutzer natürlich zurecht genervt darauf, wenn eine Internetseite langsam lädt oder verzögert reagiert, auch wenn sie sich mit ihrem Smartphone oder Tablet im heimischen WLAN-Netzwerk befinden. Den Punkt hatte ich bereits angesprochen, es ist eben technisch nicht möglich die Volumenbegrenzung, mit der ein Nutzer die Webseite betritt, vorherzusagen, wieso also pessimistisch vorgehen und auch jenen Nutzern eine schlechtere UX bieten, die eigentlich eine unbeschränkte Leitung zur Verfügung haben?

Wenn deine Seite bei bestehender WLAN-Verbindung langsam lädt oder verzögert reagiert – eine Stelle, an der ich über den Seitenaufgbau an sich nachdenken würde –, willst du optimistischerweise noch weitere Daten dazuschieben, die diesen Zustand der Langsamkeit und Verzögerungen weiter konservieren?

Jeder weiß, dass das Laden eine Webseite etwas dauert und sie bei Anforderung nicht unmittelbar da ist und erst verzögerungsfrei funktioniert, wenn sie vollständig geladen ist. Mein Bestreben wäre, diesen Zustand so schnell als möglich zu erreichen. Jedes unnötige Laden weiterer Daten ist meiner Meinung nach in dieser Hinsicht kontraproduktiv.

Tschö, Auge

[Der Martin]

Hi,

50MB Tarife sind 2015 auch nicht mehr der Stand der Dinge. Außerdem werden die Nutzer, deren Datenvolumen tatsächlich überschritten wird, wohl als aller erstes genervt auf ihren Provider reagieren, der ihnen das Paket als Flatrate verkauft hat, und nicht sofort deine Webseite verdächtigen.

Der Benutzer mag nicht die Seite verdächtigen, aber wird er stattdessen den Provider nerven?

das hoffe ich doch stark. Allerdings sollte er sich vorher nochmal seinen Vertrag ansehen, damit die netten Damen oder Herren an der Hotline ihm nicht gleich mit der ersten Gegenfrage den Wind aus den Segeln nehmen.

Ich glaube nicht daran, dass er das tun wird. Bestenfalls nervt er den Provider mit dem Verlangen nach einem größeren Tarif.

Eher mit dem Verlangen, dass das, was versprochen wurde, auch eingelöst wird.

Wieso? Deine Seite, die Daten lädt, die ich nicht nutzen wollte, ist der Flaschenhals. Wir können lange darüber diskutieren, dass uns die Mobilfunkprovider „Flatrates“ verkaufen, die keine sind, obwohl es da genaugenommen keiner Diskussionsbedarf gibt. Jeder Nutzer weiß aber, dass er einen Volumentarif mit z.B. 500MB, 1GB oder 3GB hat ...

Nein, das weiß eben nicht jeder. Und solange die Mobilfunkanbieter ihre Volumenpakete immer noch vollmundig als Flatrates bewerben, und die Volumenbegrenzung erst im Kleingedruckten verraten, ist das in meinen Augen arglistige Täuschung.

Ich musste, als ich vor etwa zwei Jahren die sogenannte "Notebook-Flat" bei 1&1 gebucht habe, sehr lange suchen, bis ich endlich irgendwo den Hinweis auf eine Volumenbegrenzung von 1GB/Monat gefunden habe. Die hatte ich nämlich erwartet, sie wurde aber damals nicht im Angebot erwähnt, sondern erst bei Vertragsabschluss.

Inzwischen haben die meisten Anbieter aber wohl gelernt und geben die Beschränkungen etwas freizügiger an.

Jeder weiß, dass das Laden eine Webseite etwas dauert und sie bei Anforderung nicht unmittelbar da ist und erst verzögerungsfrei funktioniert, wenn sie vollständig geladen ist. Mein Bestreben wäre, diesen Zustand so schnell als möglich zu erreichen. Jedes unnötige Laden weiterer Daten ist meiner Meinung nach in dieser Hinsicht kontraproduktiv.

ACK.

So long,
 Martin

[Auge]

Hallo

Der Benutzer mag nicht die Seite verdächtigen, aber wird er stattdessen den Provider nerven?

das hoffe ich doch stark. Allerdings sollte er sich vorher nochmal seinen Vertrag ansehen, damit die netten Damen oder Herren an der Hotline ihm nicht gleich mit der ersten Gegenfrage den Wind aus den Segeln nehmen.

Wie du unten schreibst, kann mittlerweile jeder sein Datenvolumen kennen.

Ich glaube nicht daran, dass er das tun wird. Bestenfalls nervt er den Provider mit dem Verlangen nach einem größeren Tarif.

Eher mit dem Verlangen, dass das, was versprochen wurde, auch eingelöst wird.

Wie du unten schreibst, kann mittlerweile jeder sein Datenvolumen kennen.

Wieso? Deine Seite, die Daten lädt, die ich nicht nutzen wollte, ist der Flaschenhals. Wir können lange darüber diskutieren, dass uns die Mobilfunkprovider „Flatrates“ verkaufen, die keine sind, obwohl es da genaugenommen keiner Diskussionsbedarf gibt. Jeder Nutzer weiß aber, dass er einen Volumentarif mit z.B. 500MB, 1GB oder 3GB hat ...

Nein, das weiß eben nicht jeder. Und solange die Mobilfunkanbieter ihre Volumenpakete immer noch vollmundig als Flatrates bewerben, und die Volumenbegrenzung erst im Kleingedruckten verraten, ist das in meinen Augen arglistige Täuschung.

Wie du unten schreibst, kann mittlerweile jeder sein Datenvolumen kennen.

Ich musste, als ich vor etwa zwei Jahren die sogenannte "Notebook-Flat" bei 1&1 gebucht habe, sehr lange suchen, bis ich endlich irgendwo den Hinweis auf eine Volumenbegrenzung von 1GB/Monat gefunden habe. Die hatte ich nämlich erwartet, sie wurde aber damals nicht im Angebot erwähnt, sondern erst bei Vertragsabschluss.

Inzwischen haben die meisten Anbieter aber wohl gelernt und geben die Beschränkungen etwas freizügiger an.

Ach, eben noch arglistige Täuschung, nun freizügige Angabe? Mobilfunkverträge werden typischerweise alle zwei Jahre neu verhandelt. Wie du selbst schreibst, wird mittlerweile auch die Volumenbegrenzung offen angegeben. Das heißt, dass sie (mit einiger zeitlicher Verzögerung) jeder Betroffene kennen kann. Was dazu geführt hat, ob öffentlicher Druck (hahaha) oder Gerichtsurteile (erscheint mir wahrscheinlicher), sei dahingestellt.

Der Anruf beim Provider in einer Situation, die hier Thema ist, wird mMn deshalb in den allermeisten Fällen zum Abschluss von Zusatzpaketen oder der Erweiterung des Vertrags führen.

Tschö, Auge

[1unitedpower]

Ich beginne mal von hinten auf deinen Beitrag, denn dann kann ich hoffentlich ein großes Missverständis direkt ausräumen.

Wenn deine Seite bei bestehender WLAN-Verbindung langsam lädt oder verzögert reagiert – eine Stelle, an der ich über den Seitenaufgbau an sich nachdenken würde –, willst du optimistischerweise noch weitere Daten dazuschieben, die diesen Zustand der Langsamkeit und Verzögerungen weiter konservieren?

Nein, genau das will ich nicht. Ich will, dass das intiale Rendern der Seite so schnell wie möglich geschieht, deshalb will ich die Leitung nicht mit Dateien belasten, die erst später gebraucht werden. Diese Dateien, sollen aber später auf Abruf so schnell wie möglich bereit stehen und nicht wieder Ladezeiten benötigen, deshalb teile ich dem Browser mit, er möge die Ressourcen dann laden, wenn er Zeit dafür hat, weil er gerade sowieso im Leerlauf-Modus läuft und die Netzwerk-Verbindung ungenutzt ist. Auch wenn ich mich wiederhole, bitte lies die FAQ von Mozilla zu link prefetching.

Das WLAN-Beispiel wollte ich eigentlich als Beispiel für eine schnelle und stabile Leitung gebrauchen. Im Heimnetzwerk sind Volumenflatrates nun wirklich nicht mehr die Regel, und diese Nutzer sind dann nur an schnellen Rekationszeiten interessiert, Download-Volumen spielt dann keine Rolle.

Das sehe ich anders, denn was die meisten User viel mehr stören dürfte ist, das detailreiche Bild gar nicht oder erst verzögert zu Gesicht zu bekommen, wenn sie es wirklich sehen möchten. Das könnte zum Beispiel passieren, wenn die Verbindung vor dem Zeitpunkt, an dem die Großfassung vom Nutzer explizit angefragt wird, getrennt wird (Funkloch? Grenzübergang?). Deshalb ist es gut, das Bild so früh wie möglich zu laden und nicht so spät wie nötig. Oder es könnte passieren, dass das Absetzen der Anfrage so lange dauert, dass es vom Nutzer gänzlich unbemerkt bleibt, dann erhält er vermutlich nur den Eindruck, dass mit der Seite irgendetwas nicht stimmt.

1. Die Verbindung kann auch während des Vorladens abbrechen. Das ist also kein Argument dafür oder dagegen.

Ja, aber das Vorladen geschieht im Hintergrund, unbemekrt vom Benutzer, nur der Browser erkennt den Fehler und kann den Download sofort neustarten, sobald die Verbindung wieder besteht.

2. Dass größere Inhalte nicht unmittelbar zur Verfügung stehen, sondern nur mit etwas Verzögerung, ist ein dem Nutzer bekanntes Phänomen. Das mag stören, aber es wird im Allgemeinen „für normal“ gehalten.

Ja, damit geb ich mich nicht zufrieden und damit sollen sich meine Nutzer auch nicht zufrieden geben müssen.

… und andererseits bleibt diese Verhalten vom Nutzer unbemerkt, er wird es der Seite also auch nicht negativ anlasten.

Wenn die 500-MB-„Flatrate“ schon lange vor Ende des Monats alle ist, mag das nicht der einzelnen Seite angelastet werden. Dort ist aber, wenn alle deiner Logik folgen, eine der Ursachen zu suchen. Unbemerkt bleibt das Verhalten, bzw. dessen Folgen, aber keineswegs.

Gut, es wird bemerkt, aber der rationale Nutzer wird die Schuld dafür nicht bei einer Webseite suchen, die ein, zwei Bilder unnötiger Weise nachgeladen hat, wenn der Löwenanteil des Volumens von Youtube, Spotify oder Netflix aufgebraucht wurde.

Zudem gibt es ja für Technik-Geeks die Möglichkeit das optimistische Vorladen per Browser-Einstellung zu unterbinden. Man hat also eine Wahlmöglichkeit, aber per Default versucht man es der technisch weniger versierten Gruppe so angenehm wie möglich zu machen.

Mich als Nutzer grämt die Drosselung nach Verbrauch meiner Pseudo-Flatrate. Ich kenne, gerade wenn ich Nicht-Technik-Geek bin, die Einstellungsmöglichkeit nicht. Erst recht weiß ich nicht, dass Seitenautoren die mir nicht bekannte Einstellung umgehen können und nicht erwünschten und bei mir Mehrkosten erzeugenden Traffic verursachen. Was also dem „Technik-Geek“ zumindest teilweise möglich ist, nämlich das Unterbinden dieses für Mobilverbindungen nicht erwünschten Verhaltens, willst du mir, als nicht dieser Gruppe angehörendem Besucher deiner Seite, aufbürden?

Ich möchte dir nochmal ins Gedächtnis rufen, dass wir hier über Bilder disktutieren, die mit hoher Wahrscheinlichkeit sowieso vom Nutzer angefordert werden. Zumindest ich denke hier nämlich an Bilder, die ich zum primären Seiteninhalt zähle, zum Beispiel Bilder aus der Galerie eines Fotografen oder Künstlers oder eine Klickstrecke, sowas in der Art eben. Der Fall, dass das Bild vorgeladen wird und dann doch nicht angeschaut wird, sollte der Ausnahmefall sein, nicht die Regel. Ansonsten sollte man vielleicht Neuabwägen, ob die Vorteile die Nachteile überwiegen.

50MB Tarife sind 2015 auch nicht mehr der Stand der Dinge. Außerdem werden die Nutzer, deren Datenvolumen tatsächlich überschritten wird, wohl als aller erstes genervt auf ihren Provider reagieren, der ihnen das Paket als Flatrate verkauft hat, und nicht sofort deine Webseite verdächtigen.

Der Benutzer mag nicht die Seite verdächtigen, aber wird er stattdessen den Provider nerven? Ich glaube nicht daran, dass er das tun wird.

Das glaube ich auch nicht, aber erfahrungsgemäß richtet sich der erste Groll trotzde in diese Richtung.

Die skeptischen User werden sich vielleicht noch eine Statistik über die Traffic-Verbraucher zu Rate nehmen und dann nüchtern feststellen, dass der Flaschenhals wirklich ganz woanders liegt und ihr Frust richtet sich dann auch nicht gegen die Webseite.

Wieso? Deine Seite, die Daten lädt, die ich nicht nutzen wollte, ist der Flaschenhals.

Verglichen mit der Videoplatform und dem Musikstreaming-Dienst, die suit ja schon angeführt hat, sind die drei unnötigen Bilder wohl kaum der Flaschenhals.

Jeder weiß, dass das Laden eine Webseite etwas dauert und sie bei Anforderung nicht unmittelbar da ist und erst verzögerungsfrei funktioniert, wenn sie vollständig geladen ist. Mein Bestreben wäre, diesen Zustand so schnell als möglich zu erreichen. Jedes unnötige Laden weiterer Daten ist meiner Meinung nach in dieser Hinsicht kontraproduktiv.

Nein, das denke ich nicht. Kontraproduktiv ist es, wenn sich die Leitung die meiste Zeit im Leerlauf befindet und dann zu gewissen Zeitpunkten eine geballte Last bewältigen muss. Man kann das Laden und die Reaktionszeiten der Webseite positiv beeinflussen, indem man versucht die Last gleichmäßiger zu verteilen, das optimistische Vorladen funktioniert nach genau diesem Prinzip.

[Auge]

Hallo

Ich beginne mal von hinten auf deinen Beitrag, denn dann kann ich hoffentlich ein großes Missverständis direkt ausräumen.

Wenn deine Seite bei bestehender WLAN-Verbindung langsam lädt oder verzögert reagiert – eine Stelle, an der ich über den Seitenaufgbau an sich nachdenken würde –, willst du optimistischerweise noch weitere Daten dazuschieben, die diesen Zustand der Langsamkeit und Verzögerungen weiter konservieren?

Nein, genau das will ich nicht. Ich will, dass das intiale Rendern der Seite so schnell wie möglich geschieht, deshalb will ich die Leitung nicht mit Dateien belasten, die erst später gebraucht werden. Diese Dateien, sollen aber später auf Abruf so schnell wie möglich bereit stehen und nicht wieder Ladezeiten benötigen, deshalb teile ich dem Browser mit, er möge die Ressourcen dann laden, wenn er Zeit dafür hat, weil er gerade sowieso im Leerlauf-Modus läuft und die Netzwerk-Verbindung ungenutzt ist.

Alles schön und der Theorie nach sinnvoll, aber auch wenn du diese Funktion sinnvoll einsetzt, heißt das nicht, dass das grundsätzlich so geschieht. Ich möchte dazu mal den abgegriffenen JS-Vergleich ziehen. Es gab schon immer sinnvolle Einsatzzwecke aber auch die Möglichkeit Schindluder damit zu treiben. Wegen Letzterem haben, auch heute noch, wo das Verhältnis ein anderes ist, nicht wenige JS (zumindest teilweise) abgeschaltet.

Es werden eben nicht nur die von dir unten erwähnten 20 Bilder der Fotogalerie einer Künstlerwebsite vorgeladen, von denen ich mir schlussendlich doch nur drei Stück im Detail ansehe, sondern jeglicher Mumpitz auf jeglichen Seiten.

Auch wenn ich mich wiederhole, bitte lies die FAQ von Mozilla zu link prefetching.

Tintenvorladen? *scnr*

Das WLAN-Beispiel wollte ich eigentlich als Beispiel für eine schnelle und stabile Leitung gebrauchen. Im Heimnetzwerk sind Volumenflatrates nun wirklich nicht mehr die Regel, und diese Nutzer sind dann nur an schnellen Rekationszeiten interessiert, Download-Volumen spielt dann keine Rolle.

Wer weiß, wie lange das noch so ist. Das unter dem Namen „Drosselkom“ bekanntgewordene Ansinnen der Telekom ist ja nicht nur auf diese beschränkt. Die Telekom hat irgendwann zurückgezogen, aber O2 bietet bei Neuverträgen für Festnetzanschlüsse standardmäßig einen Volumentarif an. Die drosseln halt nicht, wie es die Telekom vor hatte, bis auf Modem-Niveau, aber mit 2MBit fällt Videostreaming oberhalb Briefmarkengröße wohl dennoch aus.

Nun habe ich einen solchen Vertrag nicht. Mich stört das Vorladen an dieser Stelle auch nicht, es stört mich aber, wie aus meinem Text herauszulesen sein sollte, beim Internetzugang über Mobilfunk. Ich kann aus Nutzersicht auch nur von meinem und von von mir beobachteten Nutzerverhalten ausgehen.

1. Die Verbindung kann auch während des Vorladens abbrechen. Das ist also kein Argument dafür oder dagegen.

Ja, aber das Vorladen geschieht im Hintergrund, unbemekrt vom Benutzer, nur der Browser erkennt den Fehler und kann den Download sofort neustarten, sobald die Verbindung wieder besteht.

… zu Lasten meines Datenvolumens.

… und andererseits bleibt diese Verhalten vom Nutzer unbemerkt, er wird es der Seite also auch nicht negativ anlasten.

Wenn die 500-MB-„Flatrate“ schon lange vor Ende des Monats alle ist, mag das nicht der einzelnen Seite angelastet werden. Dort ist aber, wenn alle deiner Logik folgen, eine der Ursachen zu suchen. Unbemerkt bleibt das Verhalten, bzw. dessen Folgen, aber keineswegs.

Gut, es wird bemerkt, aber der rationale Nutzer wird die Schuld dafür nicht bei einer Webseite suchen, die ein, zwei Bilder unnötiger Weise nachgeladen hat, wenn der Löwenanteil des Volumens von Youtube, Spotify oder Netflix aufgebraucht wurde.

Nichts für ungut, aber diese Annahme ist realitätsfremd. Wer Volumentarife hat – und das sind in Deutschland im Mobilfunkbereich die meisten – wird sich Netflix über diesen Zugang klemmen, Youtube-Inhalte über WLAN laden und dies nach spätestens ein oder zwei Monaten auch bei Spotify so halten. Alles andere wäre (Achtung Zuspitzung!) finanzieller Selbstmord.

Ich möchte dir nochmal ins Gedächtnis rufen, dass wir hier über Bilder disktutieren, die mit hoher Wahrscheinlichkeit sowieso vom Nutzer angefordert werden. Zumindest ich denke hier nämlich an Bilder, die ich zum primären Seiteninhalt zähle, zum Beispiel Bilder aus der Galerie eines Fotografen oder Künstlers oder eine Klickstrecke, sowas in der Art eben.

Woran machst du die „hohe Wahrscheinlichkeit“ fest? In den meisten Fällen – mit einem Smartphone(!), mit einem Tablet sieht das anders aus – reichen mir bei guter Gestaltung der Seite die (hoffentlich) groß genug seienden Vorschaubilder. Die gehen ja typischerweise über die gesamte Breite des Viewports und sind, wenn sie nicht die viel zu detailreiche Ansicht einer Szene sind, gut erkennbar. Wenn ich dann noch die Vollansicht haben will, habe ich auch kein Problem mit einer (typischerweise) kurzen, zusätzlichen Ladezeit.

Der Fall, dass das Bild vorgeladen wird und dann doch nicht angeschaut wird, sollte der Ausnahmefall sein, nicht die Regel. Ansonsten sollte man vielleicht Neuabwägen, ob die Vorteile die Nachteile überwiegen.

ich halte das keineswegs für die Ausnahme. Am Smartphone will ich nicht ausgiebig surfen. Dazu ist mir der Viewport zu klein. ich will mich kurz über Neuigkeiten informieren. Bilder spielen da eine eher kleine Rolle und sind (für mich) eher dazu da, mir einen kurzen Eindruck von etwas zu verschaffen oder zu erweitern.

Die skeptischen User werden sich vielleicht noch eine Statistik über die Traffic-Verbraucher zu Rate nehmen und dann nüchtern feststellen, dass der Flaschenhals wirklich ganz woanders liegt und ihr Frust richtet sich dann auch nicht gegen die Webseite.

Wieso? Deine Seite, die Daten lädt, die ich nicht nutzen wollte, ist der Flaschenhals.

Verglichen mit der Videoplatform und dem Musikstreaming-Dienst, die suit ja schon angeführt hat, sind die drei unnötigen Bilder wohl kaum der Flaschenhals.

Im Vergleich nicht, aber da diese Dienste bei der deutschen Mobiltarifstruktur eher wenig genutzt werden … Sei's drum, ich hatte „dass der Flaschenhals wirklich ganz woanders liegt“ sowieso so interpretiert, dass sich das gegen die Provider und nicht gegen andere datenhungrigere Dienste richtet. Also aneinander vorbei.

Fazit: Natürlich soll der besuch auf einer Website dem Benutzer leicht und angenehm gemacht werden. Das findet in den Randbedingungen der Realität aber seine Grenzen, z.B. die der Volumentarife. Was mich an deiner Argumentation hinten herum am meisten störte, war der Schluss, der Geek wisse ja, wie man das Vorladen abschalten kann und der Rest guckt mit vordergründig guter User Experience in Sachen Datenvolumen in die Röhre.

Schade.

Tschö, Auge

[1unitedpower]

Woran machst du die „hohe Wahrscheinlichkeit“ fest?

Das muss man von Fall zu Fall abwägen, dafür kann ich kein allgemingültiges Rezept angeben.

In den meisten Fällen – mit einem Smartphone(!), mit einem Tablet sieht das anders aus – reichen mir bei guter Gestaltung der Seite die (hoffentlich) groß genug seienden Vorschaubilder. Die gehen ja typischerweise über die gesamte Breite des Viewports und sind, wenn sie nicht die viel zu detailreiche Ansicht einer Szene sind, gut erkennbar. Wenn ich dann noch die Vollansicht haben will, habe ich auch kein Problem mit einer (typischerweise) kurzen, zusätzlichen Ladezeit.

Hier will ich dir nur im letzten Satz widersprechen, bei dem Rest bin ich mit dir einer Meinung. Ich glaube allerdings, dass es nicht immer so einfach ist zwischen schwarz und weiß zu entscheiden, es gibt Fälle, wo optimistisches Vorladen die UX positiv beeinflusset, diese gilt es zu erkennen und dann sinnvoll auszunutzen.

Dass du an anderer Stelle kritisiert, das man dieses Feature auch missbrauchen kann, finde ich eine unfaire Argumentation, denn ich spreche mich hier deutlich für den verantwortungsbewussten Einstatz von Prebrowsing aus.

Fazit: Natürlich soll der besuch auf einer Website dem Benutzer leicht und angenehm gemacht werden. Das findet in den Randbedingungen der Realität aber seine Grenzen, z.B. die der Volumentarife. Was mich an deiner Argumentation hinten herum am meisten störte, war der Schluss, der Geek wisse ja, wie man das Vorladen abschalten kann und der Rest guckt mit vordergründig guter User Experience in Sachen Datenvolumen in die Röhre.

Schade.

Da es das ist, was dich am meisten stört: Bei Chrome Mobile findet man die Option beispielsweise unter "Einstellung->Bandbreite->Webseite vorabladen", das hätte nun auch ein Nicht-Geek noch heraufinden können. Und dann möchte ich nochmal darauf pochen, dass bei dieser Lösung dem User überhaupt eine Wahl geboten wird (1), wohingegen bei der konservativen Lösung, die ihr hier verteidigt, dem Nutzer einfach eine Mahlzeit serviert wird, ganz ohne Wahlmöglichkeit. Und dieses Essen kaut ihr auch denjenigen vor, für die das Download-Volumen nur eine untergeordnete bis hin zu gar keine Rolle spielt. Ihr messt hier mit zweierlei Maß.

1. laut suit ist das noch nicht allen Browsern der Fall.

[Auge]

Hallo

… Wenn ich dann noch die Vollansicht haben will, habe ich auch kein Problem mit einer (typischerweise) kurzen, zusätzlichen Ladezeit.

Hier will ich dir nur im letzten Satz widersprechen, bei dem Rest bin ich mit dir einer Meinung. Ich glaube allerdings, dass es nicht immer so einfach ist zwischen schwarz und weiß zu entscheiden, es gibt Fälle, wo optimistisches Vorladen die UX positiv beeinflusset, diese gilt es zu erkennen und dann sinnvoll auszunutzen.

Ich möchte meinerseits klarstellen, dass ich dem Argument, dass das Vorladen das Verhalten einer Webseite bzw. -anwendung verbessern kann, oft verbessern wird, nicht widersprechen will. Die Frage ist (für den Fall Mobiltarif im wahrsten Sinne des Wortes) der Preis.

Dass du an anderer Stelle kritisiert, das man dieses Feature auch missbrauchen kann, finde ich eine unfaire Argumentation, denn ich spreche mich hier deutlich für den verantwortungsbewussten Einstatz von Prebrowsing aus.

Ich als Nutzer kann es nur eingeschaltet lassen oder es auschalten. Wenn du (hypothetisch) der einzige sein solltest, der dieses Feature sinnvoll einsetzte, müsste ich dich dennoch ausbremsen, wenn und weil ich dem Missbrauch durch andere entgehen wollte.

Was mich an deiner Argumentation hinten herum am meisten störte, war der Schluss, der Geek wisse ja, wie man das Vorladen abschalten kann und der Rest guckt mit vordergründig guter User Experience in Sachen Datenvolumen in die Röhre.

Schade.

Da es das ist, was dich am meisten stört: Bei Chrome Mobile findet man die Option beispielsweise unter "Einstellung->Bandbreite->Webseite vorabladen", das hätte nun auch ein Nicht-Geek noch heraufinden können.

Nun doch? Klar, wer erst einmal in die Einstellungen reinschaut, sollte es finden. Aber wie du in deinem ersten Posting vermutetest, wird ein nicht unwesentlicher Teil des Publikums – unabhängig davon, ob es für sie relevant ist – die Einstellung nicht finden, einfach weil sie nicht in die Einstellungen reinschauen.

Und dann möchte ich nochmal darauf pochen, dass bei dieser Lösung dem User überhaupt eine Wahl geboten wird (1), wohingegen bei der konservativen Lösung, die ihr hier verteidigt, dem Nutzer einfach eine Mahlzeit serviert wird, ganz ohne Wahlmöglichkeit. Und dieses Essen kaut ihr auch denjenigen vor, für die das Download-Volumen nur eine untergeordnete bis hin zu gar keine Rolle spielt. Ihr messt hier mit zweierlei Maß.

1. laut suit ist das noch nicht allen Browsern der Fall.

Im (Desktop) Firefox gab es (meiner Erinnerung nach) mal einen Schalter im Einstellungsmenü. Der ist mittlerweile verschwunden. in die Tiefen von about:config traut sich andererseits nicht jeder. Die Wahlmöglichkeit ist im Einzelfall (oder auch in vielen Einzelfällen) umgekehrt genauso klein, als wenn ich kein Vorladen nutzte.

Tschö, Auge

[1unitedpower]

Ich möchte meinerseits klarstellen, dass ich dem Argument, dass das Vorladen das Verhalten einer Webseite bzw. -anwendung verbessern kann, oft verbessern wird, nicht widersprechen will. Die Frage ist (für den Fall Mobiltarif im wahrsten Sinne des Wortes) der Preis.

Zur Kenntnis genommen, bei der Wehemens des anfänglichen Widerstands, hatte ich diese Ergebnisoffenheit nicht sofort wahrgenehmen können.

Da es das ist, was dich am meisten stört: Bei Chrome Mobile findet man die Option beispielsweise unter "Einstellung->Bandbreite->Webseite vorabladen", das hätte nun auch ein Nicht-Geek noch heraufinden können.

Nun doch?

Als Angreifer meiner Arugmentation hätte es imho. auch eurer Sorgfaltsplicht unterlegen, solche Fakten zu recherchieren, bevor ihr sie offen kritisiert. De fakto muss ich jetzt nach eigener Recherche festellen, dass es bei mobilen Browsern sogar die geläufige Vorseintellung ist (Beispiel Chrome Mobile), Prefetching nur in WLAN-Netzwerken zu erlauben und für mobile Datennutzung zu unterbinden. Über andere mobile Browser konnte ich keine ähnlichen Informationen finden, gehe aber davon aus, dass sie ähnliche Strategien implementieren. Das ist ein Kompromiss, der euch sehr entgegen kommen dürfte und hoffentlich eure Meinung zum Prefetching auch positiv beeinflusst.

Klar, wer erst einmal in die Einstellungen reinschaut, sollte es finden. Aber wie du in deinem ersten Posting vermutetest, wird ein nicht unwesentlicher Teil des Publikums – unabhängig davon, ob es für sie relevant ist – die Einstellung nicht finden, einfach weil sie nicht in die Einstellungen reinschauen.

Ja, da lag ich falsch mit meiner Vermutung.

[Auge]

Hallo

Ich möchte meinerseits klarstellen, …

Zur Kenntnis genommen, bei der Wehemens des anfänglichen Widerstands, hatte ich diese Ergebnisoffenheit nicht sofort wahrgenehmen können.

Die Vehemenz des Widerspruchs bezog sich auf den Konflikt mit dem Datenvolumen. Das habe ich und auch suit immer wieder zu erkennen gegeben. Diesen Widerspruch habe ich nicht fallen gelassen.

Da es das ist, was dich am meisten stört: Bei Chrome Mobile findet man die Option beispielsweise unter "Einstellung->Bandbreite->Webseite vorabladen", das hätte nun auch ein Nicht-Geek noch heraufinden können.

Nun doch?

Als Angreifer meiner Arugmentation hätte es imho. auch eurer Sorgfaltsplicht unterlegen, solche Fakten zu recherchieren, bevor ihr sie offen kritisiert.

Zumindest für mich kann ich sagen, dass der Angriff auf dein Argument, der Geek wisse schon, wie man es abschalten kann und der Nicht-Geek eben nicht, habe stattdessen aber die gute UX (und eben auch den höheren Datenverbrauch), hin erfolgte. Dass es grundsätzlich einstellbar ist, weiß ich ja.

Ich halte es aber für herablassend, den Nicht-Geek wegen seiner Unkenntnis mit einem *pfft*^[1] in die Kostenfalle rennen zu lassen ^[2].

De fakto muss ich jetzt nach eigener Recherche festellen, dass es bei mobilen Browsern sogar die geläufige Vorseintellung ist (Beispiel Chrome Mobile), Prefetching nur in WLAN-Netzwerken zu erlauben und für mobile Datennutzung zu unterbinden. Über andere mobile Browser konnte ich keine ähnlichen Informationen finden, gehe aber davon aus, dass sie ähnliche Strategien implementieren.

Das kann ich für den bei mir unter CM 11.4 laufenden Android-Stock-Browser v4.4.4 nicht bestätigen. Dort kann ich das Vorladen vertrauenswürdiger Suchergebnisse (was auch immer das sein mag) ein- oder ausschalten. Genauso kann ich das Vorladen von auf einer Seite verlinkten Webseiten beeinflussen. In beiden Fällen wird zwischen „nie“, „nur mit WLAN“ und „immer“ unterschieden. Für Bilder kann ich jedoch nur festlegen, ob sie grundsätzlich geladen oder nicht geladen werden.

Bei wohlwollender Auslegung der Einstellungen mit wohlwollenden Vermutungen würde ich annehmen, dass das nachladen verlinkter Bilder unter „verlinkte Webseiten“ fällt. Mit Gewissheit kann ich das nicht sagen.

Das ist ein Kompromiss, der euch sehr entgegen kommen dürfte und hoffentlich eure Meinung zum Prefetching auch positiv beeinflusst.

Wenn es denn einstellbar ist, ja.

Klar, wer erst einmal in die Einstellungen reinschaut, sollte es finden. Aber wie du in deinem ersten Posting vermutetest, wird ein nicht unwesentlicher Teil des Publikums – unabhängig davon, ob es für sie relevant ist – die Einstellung nicht finden, einfach weil sie nicht in die Einstellungen reinschauen.

Ja, da lag ich falsch mit meiner Vermutung.

Tschö, Auge

---

1. Das *pfft* ist polemisierend und lässt sich sinngemäß mit einem „Wenn er's nicht kennt, ist's halt so.“ übersetzen. ↩︎

2. Genau so las sich der Absatz in deinem ersten Posting für mich. Und ja, das ist natürlich meine Interpretation. ↩︎

[1unitedpower]

Ich halte es aber für herablassend, den Nicht-Geek wegen seiner Unkenntnis mit einem *pfft*[^1] in die Kostenfalle rennen zu lassen ^[1].

Den Vorwurf muss ich zurückweisen. Aus der Diskussion sollte deutlich geworden sein, dass ich versuche sorgfältig im Interesse meiner Endnutzer abzuwägen und nicht über das Interesse hinweg. Das wird auch aus der Wortwahl in dem von dir kritisierten Satz deutlich, in dem ich nämlich schrieb, ich versuche es den Usern so angenehm wie möglich zu machen. Von einer Kostenfalle zu sprechen ist ebenfalls unzutreffend, ich habe die Bedingungen, die die Grundlage für einen optimistischen Prefetch bilden sollten, mehrmals erwähnt. Die Kostenfalle anzuführen ist auch deshalb unfair, weil der Begriff suggeriert, dass der durch Prefetching fälschlicherweise enstandene Traffic, unverhätlnismäßig groß gegenüber den Datenmengen ist, die bei koventionellen Webseites allgemein akzeptiert werden. Das ist nicht der Fall.

Prefetching schlicht zu ignorieren, macht aus einer Webseite auch kein Ressourcen-schonendes Rinnsal. Wir können den Einfluss gerne weiter diskutieren, aber dann lass uns bitte in realistischen Dimensionen denken und nicht über-polarisieren. Wir können zum Beispiel den Overhead in Relation zu den eingesparten Traffic setzen, den wir heutzutage mit Techniken erhalten können, deren primäres Ziel es ist, das Download-Volumen zu minimieren.

---

1. Genau so las sich der Absatz in deinem ersten Posting für mich. Und ja, das ist natürlich meine Interpretation. ↩︎

[Gunnar Bittersmann]

@@1unitedpower

Ich möchte dir nochmal ins Gedächtnis rufen, dass wir hier über Bilder disktutieren, die mit hoher Wahrscheinlichkeit sowieso vom Nutzer angefordert werden. Zumindest ich denke hier nämlich an Bilder, die ich zum primären Seiteninhalt zähle, zum Beispiel Bilder aus der Galerie eines Fotografen oder Künstlers oder eine Klickstrecke, sowas in der Art eben.

Und hier tut sich ein guter Kompromiss auf: Es werden nicht alle Bilder der Galerie vorgeladen, sondern nur das erste. Wenn der Nutzer dieses tatsächlich in groß anschaut, wird das zweite vorgeladen usw. Wählt der Nutzer in der Vorschau gleich das vierte, muss er eben warten.

LLAP

[1unitedpower]

Und hier tut sich ein guter Kompromiss auf: Es werden nicht alle Bilder der Galerie vorgeladen, sondern nur das erste. Wenn der Nutzer dieses tatsächlich in groß anschaut, wird das zweite vorgeladen usw. Wählt der Nutzer in der Vorschau gleich das vierte, muss er eben warten.

Ja, das wäre ein sinnvoller Einsatz.

[Gunnar Bittersmann]

@@1unitedpower

Auf der anderen Seite, reagieren Nutzer natürlich zurecht genervt darauf, wenn eine Internetseite langsam lädt oder verzögert reagiert, auch wenn sie sich mit ihrem Smartphone oder Tablet im heimischen WLAN-Netzwerk befinden.

Du willst an (W)LAN vs. Mobilfunkverbindung festmachen, ob Ressourcen vorgeladen werden oder nicht?

Vorsicht! Ich tippe gerade auf einem MacBook Air[^1], das im WLAN hängt. Mein WLAN-Router ist aber mein iPhone, was die Verbindung zum Internet über Mobilfunkverbindung herstellt. Da will ich vielleicht doch nicht vorladen – trotz WLAN.

LLAP

[1unitedpower]

@@1unitedpower

Auf der anderen Seite, reagieren Nutzer natürlich zurecht genervt darauf, wenn eine Internetseite langsam lädt oder verzögert reagiert, auch wenn sie sich mit ihrem Smartphone oder Tablet im heimischen WLAN-Netzwerk befinden.

Du willst an (W)LAN vs. Mobilfunkverbindung festmachen, ob Ressourcen vorgeladen werden oder nicht?

Vorsicht! Ich tippe gerade auf einem MacBook Air[^1], das im WLAN hängt. Mein WLAN-Router ist aber mein iPhone, was die Verbindung zum Internet über Mobilfunkverbindung herstellt. Da will ich vielleicht doch nicht vorladen – trotz WLAN.

Nein, will ich nicht. Ich wollte lediglich auch mal den Fall einer stabilen Internet-Leitung diskutieren. Das heimische WLAN-Netzwerk sollte hier als ein Beispiel für eine Leitung fungieren, die diese Eigenschaft typischerweise erfüllt. Natürlich trifft das nicht auf jede WLAN-Verbindung zu. Nachdem ich das jetzt schon zwei Mal klargestellt habe, sollte der exemplarische Charakter nun doch mal deutlich geworden sein.