Optimierung: Hilfe beim dynamisches Laden der Hintergrundbilder
Lydia Inayat
- css
- javascript
0 Rolf b1 marctrix0 1unitedpower0 1unitedpower
Hallo,
vorab ich bin ein Neuling und habe mir alles via Tutorials und Bücher beigebracht. Derzeit setze ich gerade eine Seite um:
Wie man sieht, handelt es sich um ein langen Bilder-Tepich, wo bei RollOver große Bilder eingeblendet werden. Dadurch entsteht ganz schönes Datenvolumen, was ich gerne für den Anwender minimieren möchte. Ich habe deswegen ein LazyloadScript eingebunden ("unveil", wenn jmd das was sagt), was zuerst nur die Bilder im sichtbaren Bereich läd und beim runterscrollen, dann auch die übrigen. Das funktioniert bei den kleinen Bildern im Vordergrund ganz gut. Nur leider die ausgeblendeten Bilder im Hintergrund leider nicht (was ja eine viel größere Datenmenge ausmacht). Denn da liegen (wenn auch ausgeblendet) alle im sichtbaren Bereich (Position 0, da position: relativ und display:hidden). Ich habe es mit Opacity versucht, aber da kommt irgendwie nur Chaos raus.
Kann mir jmd. da einen Tipp oder Lösungsanatz geben, wie ich das mit dem smarten Laden auch da hinbekomme?
Ich weiß nicht ob die Scripte hilfreich sind, oder ob man mit dem Developertools von Firefox mehr Infos raus zieht. Sagt einfach, was ihr wissen müsst.
Ein Ausschnitt aus dem Script.
function fadePC () {
IDs ();
var smallPosTop = $smallID.position().top;
var smallPosleft;
var id = parseInt($id);
// letztes Bild wird position rüber gerückt
if((id+1) % imgCountRo==0){
smallPosleft = $smallID.position().left - imgSize - spaceSize;
}else{
smallPosleft = $smallID.position().left;
}
// positionieren des großen Bildes (fade)
$bigID.addClass('show').css({
"top":smallPosTop,
"left":smallPosleft
}).fadeIn('fast');
};
Schluck (macht der Browser :) )
Ich würde grundsätzlich mal im HTML nur den small-Bereich rendern. Dann kannst Du Dich mit .hover auf ein "Maus schwebt drüber" registrieren und in diesem Event Handler das große Bild dynamisch laden. Zum Beispiel so, dass Du in dieser einen Zelle ein position:absolute Element hinzufügst, das das <img> Tag für das große Bild enthält. Ich meine, dass der Browser das Bild dann nachladen müsste. .hover() bietet zwei Eventhandler - einer wenn der Hover beginnt und einer wenn der Hover endet, und im Ende-Handler kannst Du das große Bild wieder entfernen.
Wird über einem kleinen Bild mehrfach gehovert, sollte der Browsercache dafür sorgen, dass das große Bild nur einmal geladen wird.
Natürlich hast Du dann einen Moment Verzögerung zwischen "Maus betritt Bild" und "Großes Bild ist da". Das kannst Du durch ein animiertes GIF kaschieren (rotierende Punkte oder sowas), und durch ein Aufzoomen des großen Fensters per jQuery Animation - oder was auch immer du gern machen willst.
Ob es eine extraschlaue Lösung gibt, durch Kombination von CSS :hover, :after und attr() weiß ich nicht, dazu müsste ich eine Weile frikkeln.
Nebenbei: Warum hast Du das <figure> Element drin? Es ist ja keine Abbildung im Fließtext. Braucht unveil das? Ansonsten würde ich vermuten, dass es unnötig ist.
Gruß
Rolf
@@Rolf b
Dann kannst Du Dich mit .hover auf ein "Maus schwebt drüber" registrieren
Was ist das: Maus?
und in diesem Event Handler das große Bild dynamisch laden.
Und wenn man hovert passiert … nichts.
Natürlich hast Du dann einen Moment Verzögerung zwischen "Maus betritt Bild" und "Großes Bild ist da".
Lies: Einen laaangen Moment.
Das kannst Du durch ein animiertes GIF kaschieren (rotierende Punkte oder sowas)
Da isses wieder, das Sowas.
LLAP 🖖
Eine Maus? Das ist dieses Ding, was ein gewisser rothemdiger Schotte seinerzeit vor den Mund hielt und „Computer, Eingabe“ sagte, bevor er mit ein paar Tastendrücken ein Spezialmolekül designte :)
Statt mich einfach plattzuklopfen, erzähl doch mal, wie Du im konkreten Fall den laaaangen Moment vermeiden würdest. Bei deinem „Sowas“ Link hast Du davon gesprochen, Content anzubieten. Den gibtʼs hier nur nicht.
Rolf
@@Rolf b
Statt mich einfach plattzuklopfen, erzähl doch mal, wie Du im konkreten Fall den laaaangen Moment vermeiden würdest.
Die Bilder vorher laden. Natürlich nicht so früh, dass sie das initiale Rendern der Seite beeinträchtigen. Also zwischen initialem Rendern der Seite und Nutzerinteraktion.
Wenn das große Bild denn wichtig ist. Ansonsten: drauf verzichten. Zumindest auf den Hover-Effekt. Man kann das große Bild ja auch verlinken.
LLAP 🖖
Das große Bild verlinken? Nee, dass muss schon fluffig zu bedienen sein. Mit so Lightboxen, PopUps und Links ist nervig bei so einem Teppich.
@@Rolf b
Statt mich einfach plattzuklopfen, erzähl doch mal, wie Du im konkreten Fall den laaaangen Moment vermeiden würdest.
Die Bilder vorher laden. Natürlich nicht so früh, dass sie das initiale Rendern der Seite beeinträchtigen. Also zwischen initialem Rendern der Seite und Nutzerinteraktion.
Wenn das große Bild denn wichtig ist. Ansonsten: drauf verzichten. Zumindest auf den Hover-Effekt. Man kann das große Bild ja auch verlinken.
LLAP 🖖
“I love to go to JS conferences to speak about how to avoid using JavaScript. Please learn CSS & HTML to reduce your JS code bloat.” —Estelle Weyl
Hallo Gunnar,
Die Bilder vorher laden. Natürlich nicht so früh, dass sie das initiale Rendern der Seite beeinträchtigen. Also zwischen initialem Rendern der Seite und Nutzerinteraktion.
auf Verdacht laden verursacht - finde ich - nur möglicherweise überflüssigen Traffic.
Wenn das große Bild denn wichtig ist. Ansonsten: drauf verzichten. Zumindest auf den Hover-Effekt. Man kann das große Bild ja auch verlinken.
warum nicht den :hover/mouseover durch ein :focus/click erweitern? Ich würde bei diesem Bilderteppich das Nachladen und Vergrößern nur bei Klick(Touch) auslösen. Sonst werden beim Schieben der Maus zum gewünschten Bild schon alle auf dem Weg liegenden Bilder ebenfalls angefordert. Damit die Bilder auch ohne JS gezeigt werden, können bzw. sollten sie ja immer noch verlinkt werden.
Gruß
Jürgen
@@JürgenB
warum nicht den :hover/mouseover durch ein :focus/click erweitern?
Wie jetzt, es gibt :hover ohne :focus? ;-)
Und nein, :focus ist nicht click. Es gibt :focus ohne click – bei Tastaturbedienung.
LLAP 🖖
Hallo Gunnar,
Und nein, :focus ist nicht click. Es gibt :focus ohne click – bei Tastaturbedienung.
stimmt. Im JS sollte man bei (on)mouseover auch (on)focus berücksichtigen. Aber in diesem Fall würde ich die Bilder erst bei Tastendruck Enter laden.
Gruß
Jürgen
Hallo,
Danke für die schnelle Antwort. J a ich hab die Hover Bilder drin, weil ich gleich eine Lösung anbieten wollte, wenn der User kein JavaScript aktiviert hat. Der würde dann ja nichts sehen, ausser den Teppich an sich.
Dachte das <figure> Element ist ganz schlau gewählt, für die Bilder. das <p> Tag ist dann quasi der Bildtitel. Nicht gut? Muss ja auch gleich ein bisschen an SEO denken.
Schluck (macht der Browser :) )
Ich würde grundsätzlich mal im HTML nur den small-Bereich rendern. Dann kannst Du Dich mit .hover auf ein "Maus schwebt drüber" registrieren und in diesem Event Handler das große Bild dynamisch laden. Zum Beispiel so, dass Du in dieser einen Zelle ein position:absolute Element hinzufügst, das das <img> Tag für das große Bild enthält. Ich meine, dass der Browser das Bild dann nachladen müsste. .hover() bietet zwei Eventhandler - einer wenn der Hover beginnt und einer wenn der Hover endet, und im Ende-Handler kannst Du das große Bild wieder entfernen.
Wird über einem kleinen Bild mehrfach gehovert, sollte der Browsercache dafür sorgen, dass das große Bild nur einmal geladen wird.
Natürlich hast Du dann einen Moment Verzögerung zwischen "Maus betritt Bild" und "Großes Bild ist da". Das kannst Du durch ein animiertes GIF kaschieren (rotierende Punkte oder sowas), und durch ein Aufzoomen des großen Fensters per jQuery Animation - oder was auch immer du gern machen willst.
Ob es eine extraschlaue Lösung gibt, durch Kombination von CSS :hover, :after und attr() weiß ich nicht, dazu müsste ich eine Weile frikkeln.
Nebenbei: Warum hast Du das <figure> Element drin? Es ist ja keine Abbildung im Fließtext. Braucht unveil das? Ansonsten würde ich vermuten, dass es unnötig ist.
Gruß
Rolf
Hej Lydia,
ich verstehe den Sinn der Bilder überhaupt nicht. Die besitzen keinerlei Information (?) - oder ich bin zu doof dafür.
Und sind das nicht die immer gleichen Bilder? Wieso wird dann so viel geladen?
Auf meinem aktuellen iPhone verhält sich der Bilderteppich auch sehr seltsam (sieht auch gar nicht aus, wie ein Teppich)...
Die Texte auf den folgenden Seiten kann ich nicht lesen. Der grelle Hintergrund in Kombination mit den hauchdünnen hellblauen Buchstaben ist für mich nicht lesbar.
Marc
Hallo Marc,
die Seite ist auch noch mitten im Prozess. Die Bilder sind ein Portfolio von Projekten. Die Texte sind noch nicht fertig. Man sieht quasi je Farbe ein Projekt. Die Jahreszahlen markiern, wann das gemacht wurde. Bei RollOver sieht man das Bild größer und Farbig und bekommt dazu Textinformationen (die noch nicht gepflegt sind).
Ja auf dem iPhone bzw. Mobile ist es kein Teppich mehr. Das wurde so gewollt (leider). Auf dem Desktop funktioniert das mit der Interaktion am besten. Denn die Idee war, dass man über den Teppich fährt (mit der Mouse) und so einen überblick über die Projekte bekommt. Es geht dabei nicht um Details. Am liebsten hätte ich das auf TouchDevices auch so (touchswipe) nur das habe ich nicht hinbekommen. Wenn dazu eine Idee da ist. Gern her damit.
Das mit dem Laden der Bilder, bei MouseOver habe ich auch überlegt. Nur habe ich Angst, das es dann nicht flüssig läuft, wenn man über den Teppich swiped. Wenn Du verstehst was ich meine.
Greller Hintergrund mit hellblauen Buchstaben ? Kannst Du mir nen Screenshot schicken, wo das so ist? Es gibt eigentlich nur weiße Typo auf Farbe oder Farbige Typo auf Weiß.
Ich habe ne Idee, wie ich das lazyload auch für die Hintergrundbilder gültig machen kann. Ich werde die versuchen die sichtbaren (kleinen) Templatebilder als Referenz nehmen. Wenn diese im Sichtbaren Bereich sind, wird die img src der Hintergrundbilder entsprechend eingesetzt. Im Prinzip wie das Lazy nur mit einer anderen Referenz.
Wenn es Euch interessiert (und wenn es funktioniert), poste ich Euch das Ergebnis.
Danke für Eure Antwort und Gedanken :-D
Hej Lydia,
ich verstehe den Sinn der Bilder überhaupt nicht. Die besitzen keinerlei Information (?) - oder ich bin zu doof dafür.
Und sind das nicht die immer gleichen Bilder? Wieso wird dann so viel geladen?
Auf meinem aktuellen iPhone verhält sich der Bilderteppich auch sehr seltsam (sieht auch gar nicht aus, wie ein Teppich)...
Die Texte auf den folgenden Seiten kann ich nicht lesen. Der grelle Hintergrund in Kombination mit den hauchdünnen hellblauen Buchstaben ist für mich nicht lesbar.
Marc
Hej Lydia,
die Seite ist auch noch mitten im Prozess.
Hübsch ist das ja...
Die Bilder sind ein Portfolio von Projekten. Die Texte sind noch nicht fertig. Man sieht quasi je Farbe ein Projekt. Die Jahreszahlen markiern, wann das gemacht wurde. Bei RollOver sieht man das Bild größer und Farbig und bekommt dazu Textinformationen (die noch nicht gepflegt sind).
Ah - ok. Vielleicht wird es verständlich, wenn die Texte da sind. ;-)
Ja auf dem iPhone bzw. Mobile ist es kein Teppich mehr. Das wurde so gewollt (leider).
Wäre dann vielleicht auch zu klein...
Auf dem Desktop funktioniert das mit der Interaktion am besten.
Der Desktop ist am Aussterben dran... ;-)
Denn die Idee war, dass man über den Teppich fährt (mit der Mouse) und so einen überblick über die Projekte bekommt. Es geht dabei nicht um Details. Am liebsten hätte ich das auf TouchDevices auch so (touchswipe) nur das habe ich nicht hinbekommen. Wenn dazu eine Idee da ist. Gern her damit.
Vielleicht gibt es da etwas bei jQuery mobile - weiß ich Aber nicht...
Das mit dem Laden der Bilder, bei MouseOver habe ich auch überlegt. Nur habe ich Angst, das es dann nicht flüssig läuft, wenn man über den Teppich swiped. Wenn Du verstehst was ich meine.
Nicht so ganz - dass man erst klicken sollte um das Bild zu zeigen?
Ich weiß nicht, ob du so auf dem richtigen Pfad bist. Es gibt so schöne CSS-Animationen, wo man Bilder "drehen" kann und dann auf der Rückseite Text sieht. Zum Beispiel. Wenn man da mit der Maus drüber fährt, sieht das auch toll aus!
Und läuft sehr geschmeidig. An Deiner Lösung stört mich noch, dass sich ein großes Bild wechselt, wenn man mit der Maus auf dem Bild selber ist - und wenn es anders wäre, würde es mich stören, dass man die verdeckten Bilder nicht mehr erreichen kann - ich würde die bunten Bilder nicht größer machen als die ausgegrauten, ausgeröteten, ausgegrünten...
Greller Hintergrund mit hellblauen Buchstaben ? Kannst Du mir nen Screenshot schicken, wo das so ist? Es gibt eigentlich nur weiße Typo auf Farbe oder Farbige Typo auf Weiß.
Diese Seite hier kann ich trotz der großen Schrift schlicht nicht lesen: http://www.preview-design.com/FTPintern/TD_Web/TD_Web_07_lazy/about.html
Habe es ehrlich versucht!
Wenn es Euch interessiert (und wenn es funktioniert), poste ich Euch das Ergebnis.
Ja gerne. Dann wird es sicher klarer.
Danke für Eure Antwort und Gedanken :-D
Von mir waren es ja vor allem Fragen :-D
Marc
Hallo Marc
Der Desktop ist am Aussterben dran... ;-)
Ich weiß nicht, ob du so auf dem richtigen Pfad bist. Es gibt so schöne CSS-Animationen, wo man Bilder "drehen" kann und dann auf der Rückseite Text sieht. Zum Beispiel. Wenn man da mit der Maus drüber fährt, sieht das auch toll aus!
Wie machst du das in der mobilen Welt in der die Mäuse ausgestorben sind?
Mit besten Grüssen
Richard
Hej Richard,
Der Desktop ist am Aussterben dran... ;-)
Ich weiß nicht, ob du so auf dem richtigen Pfad bist. Es gibt so schöne CSS-Animationen, wo man Bilder "drehen" kann und dann auf der Rückseite Text sieht. Zum Beispiel. Wenn man da mit der Maus drüber fährt, sieht das auch toll aus!
Wie machst du das in der mobilen Welt in der die Mäuse ausgestorben sind?
Müsste mit ’active’ gehen. Oder die Animation mit JavaScript triggern. Bei gut gemachten Lösungen ist dann auch gleich ein Fallback mit dabei (bzw. von vornherein das Prinzip progressive enhancement berücksichtigt).
Es gibt dafür auf jeden Fall Beispiele, anlasslos werde ich die jetzt nicht raussuchen, sondern in Ruhe fertig frühstücken. ;-)
Wenn Bedarf besteht, werde ich nachher mal nach suchen, wo ich so was gesehen habe und ob das was taugt für mobile.
Gebt gegebenenfalls eine kurze Rückmeldung...
Marc
Hi Lydia,
deine Seite leidet unter einer bekannten Schwäche von HTTP/1.*. Für jedes deiner Bilder wird ein Browser eine separate Anfrage an den Server schicken und auf die Antwort warten. Für jede dieser Frage-Antwort-Runden wird eine neue TCP-Verbindung benutzt. Browser öffnen als Schutzechanismus aber maximal 6 TCP-Verbindungen gleichzeitig. Das heißt, er kann auch immer nur maximal 6 Bilder gleichzeitig laden. Wenn man deine Seite mit Netzwerk-Tools analysiert, kann man erkennen, dass die Bilder vornehmlich sequentiell und nicht parallel geladen werden.
Es gibt Techniken mehrere HTTP-Verbindungen über ein und die selbe TCP-Verbindung herzustellen. Damit erzielst du eine bessere Parallelisierung des Download-Prozesses und erreichst letztlich deutlich besseren Daten-Durchsatz. SPDY und HTTP/2.* unterstützen Multiplexing. Ein Protokoll-Upgrade wäre vermutlich Balsam für deine Seite.
Ich habe deswegen ein LazyloadScript eingebunden ("unveil", wenn jmd das was sagt), was zuerst nur die Bilder im sichtbaren Bereich läd und beim runterscrollen, dann auch die übrigen.
Das ist für dein Problem kontra-produktiv. Erst die Bilder aus dem sichtbaren Bereich zu laden ist auf jeden Fall sinnvoll, das solltest du weiterhin so machen. Die übrigen Bilder sollten dann aber direkt im Anschluss geladen werden und nicht erst beim Scrollen. Denn dann werden die Bilder natürlich erst verzögert heruntergeladen und angezeigt. Außerdem muss man immer auch den Fall berücksichtigen, dass die Netzwerk-Verbindung vom Nutzer unterbrochen wurde, dann können Bilder nicht nachgeladen werden, obwohl die Leitung zuvor vielleicht nur noch zur Verfügung gestanden hätte. Für die gefühlte Performance und die Robustheit von Webseiten sind progressive Ladestrategien deshalb die bessere Wahl. Offensichtlich geht man damit aber auch einen Trade-Off zu Lasten des Transfer-Volumens ein.
Hallo,
… Erst die Bilder aus dem sichtbaren Bereich zu laden ist auf jeden Fall sinnvoll, das solltest du weiterhin so machen.
das stimme ich zu.
Die übrigen Bilder sollten dann aber direkt im Anschluss geladen werden und nicht erst beim Scrollen.
Diese Ansicht teile ich garnicht. So lange volumembegrenzte Datentarife noch die Regel sind, sollte man das Datenvolumen der Besucher nicht leichtfertig verschwenden.
Gruß
Jürgen
@@JürgenB
Die übrigen Bilder sollten dann aber direkt im Anschluss geladen werden und nicht erst beim Scrollen.
Diese Ansicht teile ich garnicht. So lange volumembegrenzte Datentarife noch die Regel sind, sollte man das Datenvolumen der Besucher nicht leichtfertig verschwenden.
Darauf wies 1up ja auch hin: „Offensichtlich geht man damit aber auch einen Trade-Off zu Lasten des Transfer-Volumens ein.“
Vielleicht könnte man auch nach dem initialen Rendern der Seite die Bilder below the fold in niedriger Auflösung vorladen, damit die Nutzerin nicht „ins Leere“ scrollt. Wenn gescrollt wird, werden die Bilder in höhrer Auflösung nachgeladen und dann ersetzt.
Die Bildinformation für die niedrige Auflösung muss dabei doppelt übertragen werden. Was fehlt: ein Bildformat, bei dem das Laden jederzeit unterbrochen und später fortgesetzt werden kann.
Andere Möglichkeit: nicht alle Bilder vorladen, sondern nur die jeweils knapp unter the fold. Beim Scrollen dann die jeweils nächsten.
Beide Ansätze können auch kombiniert werden.
LLAP 🖖
Hallo Gunnar,
Die übrigen Bilder sollten dann aber direkt im Anschluss geladen werden und nicht erst beim Scrollen.
Diese Ansicht teile ich garnicht. So lange volumembegrenzte Datentarife noch die Regel sind, sollte man das Datenvolumen der Besucher nicht leichtfertig verschwenden.
Darauf wies 1up ja auch hin: „Offensichtlich geht man damit aber auch einen Trade-Off zu Lasten des Transfer-Volumens ein.“
ja, aber erst ganz am Ende, nachdem erst mal der Rat mit dem "Laden auch Verdacht" kam. Das wollte ich nicht unkommentiert stehen lassen. Wenn eine Seite wegen der dem Nachladen von Inhalten geschuldeten Verzögerung nicht flüssig zu bedienen ist, sollte man lieber über eine Verringerung der Datenmengen nachdenken, bzw. über ein intelligentes Nachladen, wie du es ja auch angeregt hast.
Gruß
Jürgen