Lazy image loading minder lazy?

[NoepZor]

Ik weet niet of dit onder categorie First World Problems valt: ik kijk in sommige (grote verzamel)topics zo af en toe of er iets interessants is gepost op basis van afbeeldingen die voorbij komen (dit is bijvoorbeeld het Legotopic of het DIY klustopic). Wat ik dan doe is snel van boven naar beneden scrollen en de plaatjes scannen. Wat nu de situatie met de lazy loader is, is dat ik allemaal witte vlakken voorbij zie komen tijdens het scrollen in plaats van afbeeldingen. Is dit op een of andere manier nog iets te versnellen zodat de afbeeldingen net wel geladen zijn tijdens wat sneller scrollen?

Ik vind overigens het doel van de image loader absoluut niet verkeerd. Voor het mobiele dataverbruik scheelt het nogal of je 150KB of 2MB in laadt, terwijl je 1 plaatje ziet.

[crisp]

Dat zou impliceren dat we tijdens (langzaam) scrollen dus toch moeten checken of er plaatje moeten worden getoond. Het probleem van code uitvoeren tijdens scrollen is dat dit direct effect heeft op de soepelheid van het scrollgedrag. Met andere woorden: het scrollen wordt er minder soepel van (stotterig/'jank'), wat imo nog minder wenselijk is...

[Raven]

Kun je het niet zo regelen dat die (inderdaad nogal trage ) lazy image loader alléén werkt als er vanaf een mobiel apparaat wordt gekeken en niet vanaf een (al dan niet geforceerde) desktop?

[crisp]

Een 'mobiel apparaat' is niet te herkennen. Hooguit kan je op basis van schermgrootte een educated guess maken, maar zelfs dan zegt het niets over netwerksnelheid of databeperkingen, en ook een desktop op een breedband internetverbinding heeft baat bij snellere laadtijden.

Ik zal iig een ticket maken om te kijken of er nog iets te doen is tijdens 'slow scrolling', maar ik kan niet beloven dat dat prio gaat krijgen...

[ Voor 8% gewijzigd door crisp op 10-10-2016 20:04 ]

[Ernemmer]

Misschien de optie in je profiel maken zodat je het uit kan zetten, dat zou een stuk fijner scrollen door de topics.

[ Voor 3% gewijzigd door Ernemmer op 10-10-2016 20:49 ]

[gws24]

Snellere laadtijden voor gewone topics is prima en vind ik lazy loading ook goed werken maar het is wel irritant in de grote plaatjes topics. Meestal wil ik snel door die topics scrollen om te kijken of er interessante afbeeldingen tussen zitten maar nu moet je om de paar posts wachten tot de plaatjes geladen zijn. Dat levert dus juist niet een snellere laadtijd op. Wat de beste oplossing hiervoor is, ook voor de belasting van de servers van tweakers, weet ik niet maar een optie zoals Fable voorstelt zou ik waarderen.

[NoepZor]

Dat is ook inderdaad wat ik constateer, in de topics met een gemiddeld aantal afbeeldingen werkt het prima. Maar bij verzameltopics met veel afbeeldingen onder elkaar gaat ie op een gegeven moment wat achterlopen op het scrollgedrag. Ik snap het punt met code uitvoeren tijdens scrollen, jerkiness is inderdaad nog irritanter dan even wachten op een plaatje. Maar ik zie dat anderen het ook opgevallen is. Het is geen grote tekortkoming, ik wil niets afkraken, het is een FWP maar het viel me in ieder geval op. Vandaar dat ik dit gemeld heb In ieder geval dank voor de moeite crisp!

[Ernemmer]

Eigenlijk heeft het altijd goed gewerkt, en nu in het tijdperk waarbij praktisch iedereen over breedband beschikt wordt het langzamer.
Gaan we met deze oplossing nu niet achteruit ipv vooruit?

[crisp]

Ernemmer schreef op dinsdag 11 oktober 2016 @ 10:24:
Eigenlijk heeft het altijd goed gewerkt, en nu in het tijdperk waarbij praktisch iedereen over breedband beschikt wordt het langzamer.
Gaan we met deze oplossing nu niet achteruit ipv vooruit?

Je 'vergeet' dat er ook een shift gaande is naar mobiel, waar breedband geen gegeven is en databundels vaker wel. Plus dat zware pagina's ook duidelijk een merkbare negatieve impact hebben op de performance op een apparaat met minder geheugen en minder snelle cpu.

ik las laatst ook een goed artikel in de Volkskrant over de milieu-impact van ons exponentieel stijgende datagebruik, waarvan het grootste deel imo puur onnodig is...

[Ernemmer]

crisp schreef op dinsdag 11 oktober 2016 @ 11:23:
[...]

ik las laatst ook een goed artikel in de Volkskrant over de milieu-impact van ons exponentieel stijgende datagebruik, waarvan het grootste deel imo puur onnodig is...

misschien dan ook maar stoppen met radioreclame, zodat er maar zo min mogelijk mensen energie gebruiken om Tweakers te bezoeken.

Zou je misschien een overzichtje kunnen posten van het soort bezoeken dat hier komt, mobiel of desktop, ben wel benieuwd.

[ Voor 12% gewijzigd door Ernemmer op 11-10-2016 11:32 ]

[crisp]

Ernemmer schreef op dinsdag 11 oktober 2016 @ 11:31:
[...]


misschien dan ook maar stoppen met radioreclame, zodat er maar zo min mogelijk mensen energie gebruiken om Tweakers te bezoeken.

Zou je misschien een overzichtje kunnen posten van het soort bezoeken dat hier komt, mobiel of desktop, ben wel benieuwd.

Preciese cijfers weet ik niet, maar ik meen dat dat al op ongeveer de helft zit tegenwoordig. Ik zal het zo eens navragen

[Ernemmer]

crisp schreef op dinsdag 11 oktober 2016 @ 11:36:
[...]

Preciese cijfers weet ik niet, maar ik meen dat dat al op ongeveer de helft zit tegenwoordig. Ik zal het zo eens navragen

Bedankt,

Zou je misschien nog even willen uitleggen waarom er door deze toepassing minder data verbruikt wordt als je mobiel door een topic gaat?
Uiteindelijk ga je toch langs elk plaatje en moet je die toch downloaden. Alleen nu zit er een kleine vertraging in waardoor je er eigenlijk langer over doet.

[crisp]

Ernemmer schreef op dinsdag 11 oktober 2016 @ 11:44:
[...]


Bedankt,

Zou je misschien nog even willen uitleggen waarom er door deze toepassing minder data verbruikt wordt als je mobiel door een topic gaat?
Uiteindelijk ga je toch langs elk plaatje en moet je die toch downloaden. Alleen nu zit er een kleine vertraging in waardoor je er eigenlijk langer over doet.

- soms open je een topic en lees je niet helemaal door tot het einde maar haak je al eerder af (dat komt vaker voor dan je denkt)
- zolang je voorbij plaatjes scrolled worden deze niet geladen; alleen als je 'stilstaat' worden de zichtbare plaatjes geladen
- sommige links wijzen al naar een plek ergens midden of onderaan een topic ('nieuwe berichten'-link, links naar specifieke berichten)

en verder betekent het niet meteen inladen van alle plaatjes op een pagina dat de pagina zelf sneller 'responsief' is

[NoepZor]

Ik denk dat het meer bedoeld is voor de situaties waarin je niet helemaal door de topics gaat. Stel dat er onderin een topic een 3-tal posts staan met een uitgebreid fotoverslag van 10MB. In de oude situatie laadde je die 10MB in, in de nieuwe situatie pas als je er naar kijkt. Prima oplossing, maar het kan van mij nog een tikje sneller Als voorbeeld bijvoorbeeld facebook, daar kun je oneindig blijven scrollen en de nieuw ingeladen posts / afbeeldingen staan op tijd klaar. Nu is dit allemaal bij FB gehost op cdn's. Ik weet niet in hoeverre de externe hosts van de hier geplaatste afbeeldingen nog van invloed is.

[crisp]

oneindig scroll ben ik iig geen voorstander van

Ernemmer schreef op dinsdag 11 oktober 2016 @ 11:31:
[...]
Zou je misschien een overzichtje kunnen posten van het soort bezoeken dat hier komt, mobiel of desktop, ben wel benieuwd.

Nagevraagd Gemiddeld zit het rond de 60% desktop / 40% mobiel waarbij mobiel voornamelijk smartphones is. Tablets zijn wat lastiger te kwantificeren, maar lijken over het algemeen ook minder gebruikt te worden.

Overigens is het heel wisselend per onderdeel van de site en ook afhankelijk van de dag en het tijdstip. 's Ochtends rond 7 uur op een werkdag kan het aandeel mobiel bezoek wel 80% zijn

[Ernemmer]

crisp schreef op dinsdag 11 oktober 2016 @ 12:23:
oneindig scroll ben ik iig geen voorstander van


[...]

Nagevraagd Gemiddeld zit het rond de 60% desktop / 40% mobiel waarbij mobiel voornamelijk smartphones is. Tablets zijn wat lastiger te kwantificeren, maar lijken over het algemeen ook minder gebruikt te worden.

Overigens is het heel wisselend per onderdeel van de site en ook afhankelijk van de dag en het tijdstip. 's Ochtends rond 7 uur op een werkdag kan het aandeel mobiel bezoek wel 80% zijn

Bedankt, toch leuk om even te weten.

[NoepZor]

crisp schreef op dinsdag 11 oktober 2016 @ 12:23:
oneindig scroll ben ik iig geen voorstander van

Voor een forum is dat inderdaad niet nodig, vind het wel handig om pagina's te hebben. Het ging me meer om het voorbeeld, dat de content er staat zodra je er heen gescrolld bent.

Enne, waarschijnlijk is het toiletbezoek rond 7.00 's ochtends ook vrij hoog, of heeft Tweakers dat niet gemeten?

[josvane]

Ernemmer schreef op maandag 10 oktober 2016 @ 20:08:
Misschien de optie in je profiel maken zodat je het uit kan zetten, dat zou een stuk fijner scrollen door de topics.

Dat is wat mij betreft een goede oplossing. De manier hoe het nu werkt is echt bloed irritant als je door de grote topics heen wilt scrollen op zoek naar afbeeldingen.

Wellicht kan het in of uit schakelen zelfs op basis van domeinnaam.

tweakers.mobi lazy loading aan.
tweakers.net lazy loadin uit.

[Verwijderd]

Kunnen ze geen knopje inbouwen waarmee je lazy loading kunt uitzetten?

[Hero of Time]

Graag, want ik begin er toch wat minpunten mee te zien. Vooral bij langlopende of oude topics waar plaatjes staan, die het eigenlijk niet meer doen. In die gevallen verspringt de pagina, want ipv 600 hoog is 't opeens nog maar 1 of 2 regels tekst dat de URL van het plaatje laat zien.
Of topics waar veel plaatjes gepost wordt en je er 'even snel' doorheen wil bladeren. Je bent in sommige gevallen langer aan het wachten op het plaatje dat moet verschijnen, dan dat je aan het kijken bent ernaar.

[crisp]

Dat verspringen hou je toch, met of zonder lazy-loading. Wellicht zouden we in de lazy-loader dat verspringen zelfs op kunnen lossen door het error-event op te vangen en daar iets mee te doen

[Hero of Time]

Niet helemaal. Als je naar een specifieke reactie gaat in een topic met niet werkende plaatjes, wordt de hele pagina geladen voordat je naar het bericht gaat. Er is dan al bekend of er 600 pixels verticaal of maar 2 regels voor een oud bericht nodig is. Met lazy loading wordt die ruimte gereserveerd die eigenlijk niet nodig is, omdat het plaatje niet werkt. Voorbeeld (is een afgesloten deel, dus niet iedereen kan die openen). Scroll omhoog en je ziet de pagina verspringen. Er zijn twee reacties die plaatjes bevatten die het niet meer doen, waardoor alleen nog maar de URL er staat als plain text. Zou er geen lazy loading toegepast worden, dan heb je dat probleem niet.

[crisp]

Hero of Time schreef op dinsdag 25 oktober 2016 @ 20:35:
Niet helemaal. Als je naar een specifieke reactie gaat in een topic met niet werkende plaatjes, wordt de hele pagina geladen voordat je naar het bericht gaat. Er is dan al bekend of er 600 pixels verticaal of maar 2 regels voor een oud bericht nodig is. Met lazy loading wordt die ruimte gereserveerd die eigenlijk niet nodig is, omdat het plaatje niet werkt. Voorbeeld (is een afgesloten deel, dus niet iedereen kan die openen). Scroll omhoog en je ziet de pagina verspringen. Er zijn twee reacties die plaatjes bevatten die het niet meer doen, waardoor alleen nog maar de URL er staat als plain text. Zou er geen lazy loading toegepast worden, dan heb je dat probleem niet.

De browser zal totdat hij daadwerkelijk gaat proberen het plaatje op te halen (wat even kan duren als er nog veel plaatjes voor staan) wel degelijk al de opgegeven breedte en hoogte reserveren. Zonder lazy-loading heb je dus ook verspringing, alleen op een ander tijdstip (maar vaak net zo hinderlijk). Met lazy-loading kunnen we die verspringing voorkomen, met inderdaad als side-effect dat er 'nutteloze' ruimte gereserveerd blijft. Maar als de verspringing het grootste probleem is, dan is dat toch een verbetering?

[Raven]

Verwijderd schreef op dinsdag 25 oktober 2016 @ 18:47:
Kunnen ze geen knopje inbouwen waarmee je lazy loading kunt uitzetten?

Graag.

Die lazy loading lijkt steeds trager te worden hier, ook met embedded YouTube-filmpjes....

[_David_]

Ik denk dat het product/development team niet nog een instelling wil toevoegen, er zijn er al genoeg.

Het is ook beter om de lazy loading te verbeteren ipv een optie bieden om het uit te zetten.

[crisp]

Ik voel weinig voor een optie waarmee iemand de lazy-loader uit kan zetten. In de eerste plaats omdat ik denk dat er maar weinig gebruik van gemaakt zal worden, in de tweede plaats omdat dat ook meteen een heel rigide oplossing is en in de laatste plaats omdat ik geloof dat we de behaviour wel degelijk nog kunnen verbeteren.

Wat _David_ hierboven dus ook zegt

[The Eagle]

Vertel dan ook meteen even waarom op een iPad 4 die voor GoT ingesteld is op gewone desktop weergave, dat lazyloading ook van toepassing is. Klinkt mij nl meer in de oren als een bug dan een feature. En het is rete-irritant.
Plus uiteraard dat tablets merendeels thuis en dus via wifi gebruikt worden. En dan noeit dat hele databundelverhaal niet

[Hero of Time]

crisp schreef op dinsdag 25 oktober 2016 @ 20:53:
[...]

De browser zal totdat hij daadwerkelijk gaat proberen het plaatje op te halen (wat even kan duren als er nog veel plaatjes voor staan) wel degelijk al de opgegeven breedte en hoogte reserveren. Zonder lazy-loading heb je dus ook verspringing, alleen op een ander tijdstip (maar vaak net zo hinderlijk). Met lazy-loading kunnen we die verspringing voorkomen, met inderdaad als side-effect dat er 'nutteloze' ruimte gereserveerd blijft. Maar als de verspringing het grootste probleem is, dan is dat toch een verbetering?

In dit geval vind ik van niet. De verspringing is dermate vervelend dat het niet altijd duidelijk is wat er nou eigenlijk gebeurt. Je scrollt omhoog maar in feite ga je omlaag. Hierdoor kan je je hardware ten twijfel trekken. Mijn vader heeft al een muis waarbij de scrollwiel wat vaag doet en met enige regelmaat omgekeerd scrollt. Voor mij zo frustrerend dat ik de muis niet eens wil gebruiken voor scrollen.

Dat het verspringen zonder lazy loading gebeurt en je daarmee alsnog bij de verkeerde reactie kan komen is iets minder hinderlijk, omdat bij een refresh dat probleem niet meer optreedt (de pagina is immers al helemaal binnen) en je wel naar de juiste reactie gaat. Op de desktop kan je zelfs een knop toevoegen om te springen naar de anchor waar het adres naar wijst.

crisp schreef op dinsdag 25 oktober 2016 @ 21:00:
Ik voel weinig voor een optie waarmee iemand de lazy-loader uit kan zetten. In de eerste plaats omdat ik denk dat er maar weinig gebruik van gemaakt zal worden, in de tweede plaats omdat dat ook meteen een heel rigide oplossing is en in de laatste plaats omdat ik geloof dat we de behaviour wel degelijk nog kunnen verbeteren.

Ik zou die optie iig gaan gebruiken. Als het pre-loaden veel slimmer wordt gedaan en niet zo beperkt als nu, waarbij het net lijkt of je 10 pixels in de buurt moet zijn om 'm te laten laden, ipv een veel groter bereik, zoals 500 pixels of meer, dan scheelt dat al een hoop.

Overigens, is het echt nodig om de lazy load ruimte wit te maken ipv transparant? Ik heb zelf Tweakers en GoT donker gemaakt, wat ik erg prettig vind voor m'n ogen. Om dan opeens fel witte vlakken te zien is net alsof je van een donkere ruimte direct in een lamp of de zon kijkt.

[crisp]

Hero of Time schreef op dinsdag 25 oktober 2016 @ 21:17:
[...]

In dit geval vind ik van niet. De verspringing is dermate vervelend dat het niet altijd duidelijk is wat er nou eigenlijk gebeurt. Je scrollt omhoog maar in feite ga je omlaag. Hierdoor kan je je hardware ten twijfel trekken. Mijn vader heeft al een muis waarbij de scrollwiel wat vaag doet en met enige regelmaat omgekeerd scrollt. Voor mij zo frustrerend dat ik de muis niet eens wil gebruiken voor scrollen.

Dat het verspringen zonder lazy loading gebeurt en je daarmee alsnog bij de verkeerde reactie kan komen is iets minder hinderlijk, omdat bij een refresh dat probleem niet meer optreedt (de pagina is immers al helemaal binnen) en je wel naar de juiste reactie gaat. Op de desktop kan je zelfs een knop toevoegen om te springen naar de anchor waar het adres naar wijst.

Mijn punt is juist dat je het met de lazy-loader helemaal kan voorkomen, dus winst

[...]

Ik zou die optie iig gaan gebruiken. Als het pre-loaden veel slimmer wordt gedaan en niet zo beperkt als nu, waarbij het net lijkt of je 10 pixels in de buurt moet zijn om 'm te laten laden, ipv een veel groter bereik, zoals 500 pixels of meer, dan scheelt dat al een hoop.

We kijken al een scrollhoogte omhoog en omlaag. Het enige punt is dat we dat alleen doen op het moment dat er helemaal geen scrollactiviteit (meer) is, en dat zullen we waarschijnlijk moeten verbeteren zonder dat het scrollen zelf daarmee schokkerig gaat worden. Het is dus vooral zoeken naar de juiste balans denk ik.

Overigens, is het echt nodig om de lazy load ruimte wit te maken ipv transparant? Ik heb zelf Tweakers en GoT donker gemaakt, wat ik erg prettig vind voor m'n ogen. Om dan opeens fel witte vlakken te zien is net alsof je van een donkere ruimte direct in een lamp of de zon kijkt.

Het is een off-white en die kleur is gekozen om een licht contrast te maken met de grijze achtergrond. Met custom css kan je dat zelf anders instellen

[The Eagle]

crisp schreef op maandag 10 oktober 2016 @ 20:02:
Een 'mobiel apparaat' is niet te herkennen. Hooguit kan je op basis van schermgrootte een educated guess maken, maar zelfs dan zegt het niets over netwerksnelheid of databeperkingen, en ook een desktop op een breedband internetverbinding heeft baat bij snellere laadtijden.

Volgens mij is er een aantal iteraties terug toch echt een instelling gekomen welke weergave iemand wil, desktop, grote of kleine tablet, smartphone. Hang hem dan daar aan op

Ik zal iig een ticket maken om te kijken of er nog iets te doen is tijdens 'slow scrolling', maar ik kan niet beloven dat dat prio gaat krijgen...

Als je nou die lazy loader uitzet voor de desktop en tablet profielen ben je er denk ik gewoon.
En standje automatisch laat je hem gewoon lekker aan staan

[Hero of Time]

crisp schreef op dinsdag 25 oktober 2016 @ 21:23:
[...]

Mijn punt is juist dat je het met de lazy-loader helemaal kan voorkomen, dus winst

Wat in de praktijk dus niet zo is. Dus verlies en irritatie.

[...]

We kijken al een scrollhoogte omhoog en omlaag. Het enige punt is dat we dat alleen doen op het moment dat er helemaal geen scrollactiviteit (meer) is, en dat zullen we waarschijnlijk moeten verbeteren zonder dat het scrollen zelf daarmee schokkerig gaat worden. Het is dus vooral zoeken naar de juiste balans denk ik.

De vraag is dus idd hoe je plaatjes met lazy loading aan alsnog kan laden tijdens het scrollen, zonder (merkbare) impact.

[...]

Het is een off-white en die kleur is gekozen om een licht contrast te maken met de grijze achtergrond. Met custom css kan je dat zelf anders instellen

Aangezien de placeholder weg is voor ik 'm kan selecteren, kan je het div id of class dan geven? Of valt het onder de div.img class?

[crisp]

Hero of Time schreef op dinsdag 25 oktober 2016 @ 21:48:
[...]

Wat in de praktijk dus niet zo is. Dus verlies en irritatie.

Volgens bij begrijp je me niet helemaal... Zonder lazy-loader heb je verspringing bij plaatjes die uiteindelijk niet geladen kunnen worden. Met de lazy-loader zouden we dat kunnen detecteren en het verspringen kunnen voorkomen.

[...]

De vraag is dus idd hoe je plaatjes met lazy loading aan alsnog kan laden tijdens het scrollen, zonder (merkbare) impact.

Juist, daar moeten we onderzoek naar doen. Ik heb al een poc waar ik al wat resultaten mee heb geboekt

[...]

Aangezien de placeholder weg is voor ik 'm kan selecteren, kan je het div id of class dan geven? Of valt het onder de div.img class?

Uit mijn hoofd is de class .lazyimg of .lazyload. Je zou die in forum.css wel moeten kunnen vinden

[Hero of Time]

crisp schreef op dinsdag 25 oktober 2016 @ 22:30:
[...]

Volgens bij begrijp je me niet helemaal... Zonder lazy-loader heb je verspringing bij plaatjes die uiteindelijk niet geladen kunnen worden. Met de lazy-loader zouden we dat kunnen detecteren en het verspringen kunnen voorkomen.

Eerder andersom. Ik heb in het verleden hier geen last van gehad, dat de pagina tijdens het scrollen versprong omdat een plaatje het niet deed. Nu wel.

Dat de pagina tijdens/net na het laden verspringt door een niet werkend plaatje heb ik het niet direct over.

[...]

Juist, daar moeten we onderzoek naar doen. Ik heb al een poc waar ik al wat resultaten mee heb geboekt

Klinkt goed. Maar is dit ook op een grotere schaal getest?

[...]

Uit mijn hoofd is de class .lazyimg of .lazyload. Je zou die in forum.css wel moeten kunnen vinden

OK, ga ik die eens door spitten. Moet mijn hele CSS toch nog eens bijwerken, wellicht zie ik er nog wat in dat ik ben vergeten of beter kan specificeren. Had eigenlijk veel eerder de boel van lokaal naar m'n account moeten verplaatsen, want op mobiel is het nog steeds licht.

[crisp]

Hero of Time schreef op dinsdag 25 oktober 2016 @ 22:45:
[...]

Eerder andersom. Ik heb in het verleden hier geen last van gehad, dat de pagina tijdens het scrollen versprong omdat een plaatje het niet deed. Nu wel.

Dat de pagina tijdens/net na het laden verspringt door een niet werkend plaatje heb ik het niet direct over.

Dat laatste doel ik dus wel op, dat kunnen we dus ook oplossen (en het verspringen tijdens het scrollen dus ook). Dat is dus geen reden om het kind maar meteen met het badwater weg te gooien (aka een optie om de lazy-loader te disablen)

[...]

Klinkt goed. Maar is dit ook op een grotere schaal getest?

As said was dat een poc (proof of concept), dus nee. Er is wel een ticket voor welke hopelijk in een van de komende iteraties meekomt

[Hero of Time]

Momenteel is lazy loading niet ideaal, omdat het te langzaam werkt bij snel scrollen en als een plaatje niet werkt, verspringt de pagina. Hoe zie je dit laatste dan opgelost worden? Want je zegt dat het verspringen tijdens het laden hiermee wordt opgelost, maar niet het verspringen na het laden.

[crisp]

Hero of Time schreef op dinsdag 25 oktober 2016 @ 23:23:
Momenteel is lazy loading niet ideaal, omdat het te langzaam werkt bij snel scrollen en als een plaatje niet werkt, verspringt de pagina. Hoe zie je dit laatste dan opgelost worden? Want je zegt dat het verspringen tijdens het laden hiermee wordt opgelost, maar niet het verspringen na het laden.

Simpel: als het error-event wordt getriggered ipv het load-event dan zetten we gewoon de placeholder weer terug en zorgen we voor een error-indicatie (bijvoorbeeld lichtrode achtergrond).

[InFamous]

Hero of Time schreef op dinsdag 25 oktober 2016 @ 22:45:
[...]

Eerder andersom. Ik heb in het verleden hier geen last van gehad, dat de pagina tijdens het scrollen versprong omdat een plaatje het niet deed. Nu wel.

Dat de pagina tijdens/net na het laden verspringt door een niet werkend plaatje heb ik het niet direct over.


[...]

Klinkt goed. Maar is dit ook op een grotere schaal getest?


[...]

OK, ga ik die eens door spitten. Moet mijn hele CSS toch nog eens bijwerken, wellicht zie ik er nog wat in dat ik ben vergeten of beter kan specificeren. Had eigenlijk veel eerder de boel van lokaal naar m'n account moeten verplaatsen, want op mobiel is het nog steeds licht.

img.lazyimg{background:#fafafa} in main.css

Kan je die niet gewoon een opacity: 0 meegeven? Dan is de ruimte wel gereserveerd maar is er gewoon geen irritant wit vlak zichtbaar.

[ Voor 12% gewijzigd door InFamous op 26-10-2016 08:31 . Reden: Verkeerde quote :X ]

[crisp]

InFamous schreef op woensdag 26 oktober 2016 @ 08:14:
[...]


img.lazyimg{background:#fafafa} in main.css

Kan je die niet gewoon een opacity: 0 meegeven? Dan is de ruimte wel gereserveerd maar is er gewoon geen irritant wit vlak zichtbaar.

Dan kan je ook background:none/transparent gebruiken Maar helemaal transparant betekent dat je gewoon lege ruimte ziet en dan eerder denkt dat er iets 'mis' is dan wanneer je iets van een 'placeholder' ziet.

[XWB]

Ik herken wat de topicstarter zegt. Ik "scroll" vaak door topics met de page down knop, even snel plaatjes scannen zit er nu niet meer in.

[Wom]

Wat de topicstarter ervaart is ook mijn gevoel. Dacht dat ik de enige was, dus verder niet echt over 'gezeurd' maar ik ben er ook nog steeds niet aan gewend. Merk dat ik er langer over doe om de content te scannen, wat voor mij niet geheel comfortabel is. Dacht dat het kwestie van wennen was/is, maar ik zou liever de functie uit kunnen schakelen.

Nu val ik in een zeer kleine minderheid, dus begrijp dat hier geen gehoor aan gegeven zal worden. Maar wilde het wel even delen. Het browsen door topics is voor mij minder prettig geworden.

[Hero of Time]

Prachtig voorbeeld waar dit verre van ideaal is: https://gathering.tweaker...es/1721371/////1477816784
Bij wie, met toegang, blijf je op de betreffende post ipv het extra lange plaatje van de reactie ervoor te zien? Ik iig niet op m'n mobiel.

[ Voor 22% gewijzigd door Hero of Time op 30-10-2016 11:27 ]

[crisp]

Hero of Time schreef op zondag 30 oktober 2016 @ 11:26:
Prachtig voorbeeld waar dit verre van ideaal is: https://gathering.tweaker...es/1721371/////1477816784
Bij wie, met toegang, blijf je op de betreffende post ipv het extra lange plaatje van de reactie ervoor te zien? Ik iig niet op m'n mobiel.

Ik snap je niet helemaal. Ik kom uit op die post, scroll omhoog en zie daar gewoon het plaatje in de voorgaande post Er verspringt ook niets o.i.d. Chrome op een Android tablet in grade A en B

[ Voor 6% gewijzigd door crisp op 30-10-2016 12:49 ]

[Hero of Time]

crisp schreef op zondag 30 oktober 2016 @ 12:44:
[...]

Ik snap je niet helemaal. Ik kom uit op die post, scroll omhoog en zie daar gewoon het plaatje in de voorgaande post Er verspringt ook niets o.i.d. Chrome op een Android tablet in grade A en B

Ik kom bij de post, maar een seconde later ben ik daar niet meer, ik zie dan het plaatje in de post erboven. Ik denk dat lazy lading hier de schuldige voor is.
Grade D overigens met m'n mobiel rechtop. Kantel ik 'm voor grade B, dan gebeurt het niet.

Misschien dat het een bug is door dit gedrag bij alleen grade D.

[ Voor 10% gewijzigd door Hero of Time op 30-10-2016 13:00 ]

[_David_]

crisp schreef op zondag 30 oktober 2016 @ 12:44:
[...]

Ik snap je niet helemaal. Ik kom uit op die post, scroll omhoog en zie daar gewoon het plaatje in de voorgaande post Er verspringt ook niets o.i.d. Chrome op een Android tablet in grade A en B

Verspringt bij mij wel op Grade D / XS:
[YouTube: https://www.youtube.com/watch?v=M-Prz0Lft50]
Chrome for Android 54.0.2840.68
Nexus 5

Hero of Time schreef op zondag 30 oktober 2016 @ 12:58:
[...]

Ik kom bij de post, maar een seconde later ben ik daar niet meer, ik zie dan het plaatje in de post erboven. Ik denk dat lazy lading hier de schuldige voor is.
Grade D overigens met m'n mobiel rechtop. Kantel ik 'm voor grade B, dan gebeurt het niet.

Misschien dat het een bug is door dit gedrag bij alleen grade D.

Als ik hem bij mij kantel (en dus op grade C / SM zit), dan springt hij ook, nog verder naar boven zelfs.

[ Voor 52% gewijzigd door _David_ op 30-10-2016 13:04 ]

[crisp]

Hmm, ik zal eens kijken of dat inderdaad door de lazy-loading komt en waarom dan alleen de lagere grades daar last van hebben. Dat is echter hooguit een bug en zie ik niet als een reden om het systeem maar weer op te heffen... (hoewel ik wel steeds meer genegen ben om de handdoek maar in de ring te gooien; blijkbaar vinden mensen het tegenwoordig niet bezwaarlijk om nutteloze mb's te downloaden zelfs als ze daar toch voor betalen en op moeten wachten... - het zal wel een generatiekloof(je) zijn)

[ Voor 38% gewijzigd door crisp op 30-10-2016 13:57 ]

[_David_]

crisp schreef op zondag 30 oktober 2016 @ 13:52:
Hmm, ik zal eens kijken of dat inderdaad door de lazy-loading komt en waarom alleen de lagere grades daar last van hebben. Dat is echter hooguit een bug en zie ik niet als een reden om het systeem maar weer op te heffen... (hoewel ik wel steeds meer genegen ben om de handdoek maar in de ring te gooien; blijkbaar vinden mensen het tegenwoordig niet bezwaarlijk om nutteloze mb's te downloaden zelfs als ze daar toch voor betalen...)

Dat zeg ik ook niet

Ik vind het systeem zeker een goeie toevoeging (en al helemaal wanneer het ook ingevoerd is bij user reviews, dat is het helemaal crime m.b.t de mb's), dat er nu een bug in zit doet daar geen afbreuk aan.

[Hero of Time]

crisp schreef op zondag 30 oktober 2016 @ 13:52:
Hmm, ik zal eens kijken of dat inderdaad door de lazy-loading komt en waarom dan alleen de lagere grades daar last van hebben. Dat is echter hooguit een bug en zie ik niet als een reden om het systeem maar weer op te heffen...

Wat ik merkte toen ik het topic weer opende vanwege een nieuwe post was dat er op dat moment niets mis meer was. Echter, scrollde ik omhoog dan gebeurde het weer. En daarbij zag ik dat de ruimte die gereserveerd was veel te weinig was. De breedte was al niet genoeg en dan heb je met verhoudingen te maken die de boel alleen maar erger maken. Er werd iets van 1/2 tot 2/3 aan breedte gepakt ipv de volle breedte. Fwiw, de stippellijn is blauw om het plaatje, niet rood om aan te geven dat deze te groot is dan bedoelt.

(hoewel ik wel steeds meer genegen ben om de handdoek maar in de ring te gooien; blijkbaar vinden mensen het tegenwoordig niet bezwaarlijk om nutteloze mb's te downloaden zelfs als ze daar toch voor betalen en op moeten wachten... - het zal wel een generatiekloof(je) zijn)

Ik heb geen mobiel internet en zit alleen nu eens met m'n m'n mobiel op GoT, maar deze functie zit mij eigenlijk meer in de weg dan dat het echt werkt. Dat wil ik niet op een generatiekloof gooien.

Voordat je de handdoek in de ring gooit lijkt het mij wel interessant om te zien wat jouw PoC op grote schaal doet.

[crisp]

Hero of Time schreef op zondag 30 oktober 2016 @ 14:19:
[...]

Wat ik merkte toen ik het topic weer opende vanwege een nieuwe post was dat er op dat moment niets mis meer was. Echter, scrollde ik omhoog dan gebeurde het weer. En daarbij zag ik dat de ruimte die gereserveerd was veel te weinig was. De breedte was al niet genoeg en dan heb je met verhoudingen te maken die de boel alleen maar erger maken. Er werd iets van 1/2 tot 2/3 aan breedte gepakt ipv de volle breedte. Fwiw, de stippellijn is blauw om het plaatje, niet rood om aan te geven dat deze te groot is dan bedoelt.

Het is meer een css bugje; img.resized2 zou geen width:auto mogen krijgen in responsive. Die kan ik dus snel fixen

[...]

Ik heb geen mobiel internet en zit alleen nu eens met m'n m'n mobiel op GoT, maar deze functie zit mij eigenlijk meer in de weg dan dat het echt werkt. Dat wil ik niet op een generatiekloof gooien.

Voordat je de handdoek in de ring gooit lijkt het mij wel interessant om te zien wat jouw PoC op grote schaal doet.

Ja, ik zal eerdaags eens kijken of ik al effect kan zien in de loadtime statistieken. Daar is het uiteindelijk ook mee begonnen, met het feit dat we zagen dat die tijden de afgelopen jaren behoorlijk zijn opgelopen (tijd tot onload van een pagina) en we al tot de conclusie waren gekomen dat dat voornamelijk veroorzaakt werd door meer en grotere afbeeldingen.

[Juup]

De huidige lazy loading frustreert mij mateloos.
Het voelt alsof ik op een hele trage verbinding zit omdat het na het scrollen lang duurt voordat de content er staat.
Zeer ergerlijk.

[Juup]

Is er enige progressie op dit front?
Gaat er nog iets veranderen of blijft deze feature as is?

[Ernemmer]

Het zou inderdaad erg fijn zijn als het als optie in het profiel aan te passen is.
Het is alsof je met een 4Mbit lijntje zit te surfen.

[ Voor 3% gewijzigd door Ernemmer op 20-11-2016 20:29 ]

[Femme]

Juup schreef op zondag 20 november 2016 @ 19:29:
Is er enige progressie op dit front?
Gaat er nog iets veranderen of blijft deze feature as is?

We hebben afgelopen week een aanpassing gedaan die ervoor zorgt dat de lazy image loader bij scrollen met gematigde snelheid verder vooruit laadt. Dat zorgt ervoor dat afbeeldingen in veel gevallen al zijn ingeladen als je door topics scant.

We zijn benieuwd hoe deze wijziging bevalt.

[Juup]

Ah als ik langzaam genoeg scroll dan gaat het idd redelijk goed.
Ik zie nog wel wat roze vlakken af en toe, bv:
Raven in "Buitenlandse TV Series 2016-2017"

Het is zeker minder erg dan voorheen.

[crisp]

Juup schreef op zondag 20 november 2016 @ 21:59:
Ah als ik langzaam genoeg scroll dan gaat het idd redelijk goed.
Ik zie nog wel wat roze vlakken af en toe, bv:
Raven in "Buitenlandse TV Series 2016-2017"

Het is zeker minder erg dan voorheen.

Een roze vlak betekent dat het plaatje ueberhaupt niet geladen kon worden. Het plaatje in die post doet het bij mij echter prima.

[Wom]

In mijn geval heb ik zeker verbetering gemerkt. Heb mij er niet meer aan gestoord in ieder geval, wat een teken is dat het voor mij in orde is. Bedankt

[Juup]

crisp schreef op zondag 20 november 2016 @ 22:26:
Een roze vlak betekent dat het plaatje ueberhaupt niet geladen kon worden. Het plaatje in die post doet het bij mij echter prima.

Het plaatje gaat goed in Safari maar werkt niet op Firefox 49.0.2, Firefox 50.0 en Firefox Developer 51.0a2 (tenzij de cache er correct mee gevuld is).
Allemaal op macOS 10.11.6
Enige plugin is LastPass en trackingprotection staat aan.

[crisp]

Juup schreef op maandag 21 november 2016 @ 17:21:
[...]

Het plaatje gaat goed in Safari maar werkt niet op Firefox 49.0.2, Firefox 50.0 en Firefox Developer 51.0a2 (tenzij de cache er correct mee gevuld is).
Allemaal op macOS 10.11.6
Enige plugin is LastPass en trackingprotection staat aan.

En met tracking protection uit? Overigens zou je dan zonder de lazyloader ook een 'broken image' hebben als het daar aan ligt.

[Juup]

crisp schreef op maandag 21 november 2016 @ 17:26:
En met tracking protection uit? Overigens zou je dan zonder de lazyloader ook een 'broken image' hebben als het daar aan ligt.

Argh.... als hij eenmaal in de cache aanwezig is kan ik het probleem niet meer reproduceren, ook niet na alle cache weg te gooien

[crisp]

Juup schreef op maandag 21 november 2016 @ 17:30:
[...]

Argh.... als hij eenmaal in de cache aanwezig is kan ik het probleem niet meer reproduceren, ook niet na alle cache weg te gooien

Zal je altijd zien Maar het is iig niet iets wat direct door de imageloader veroorzaakt kan worden... (wel indirect als bijvoorbeeld na het inladen van de pagina je verbinding wegvalt en je dan door het topic gaat scrollen).

[ Voor 15% gewijzigd door crisp op 21-11-2016 17:48 ]

[Juup]

crisp schreef op maandag 21 november 2016 @ 17:45:
Zal je altijd zien Maar het is iig niet iets wat direct door de imageloader veroorzaakt kan worden... (wel indirect als bijvoorbeeld na het inladen van de pagina je verbinding wegvalt en je dan door het topic gaat scrollen).

Nee het is iets dat alleen maar door de imageloader veroorzaakt kan worden omdat het "los" laden van deze resource wel werkt in dezelfde browser.

[crisp]

Juup schreef op maandag 21 november 2016 @ 18:27:
[...]

Nee het is iets dat alleen maar door de imageloader veroorzaakt kan worden omdat het "los" laden van deze resource wel werkt in dezelfde browser.

I beg to differ. Er is niets anders aan wat de imageloader doet ten opzichte van je browser (hij laat het ook aan de browser over, alleen op een ander tijdstip). Note dat een browser ook een tijdelijke (netwerk)fout bij het inladen gecached kan hebben.

[Juup]

Niets anders... behalve een hele zwik js code die bugs zou kunnen bevatten.
Moet ik nu echt jouw werk gaan doen en uitzoeken waarom dat plaatje niet laadt?

Sorry voor mijn botte reactie maar ik wordt een beetje prikkelbaar van een "feature" die misschien goed is voor mobiele gebruikers maar voor iedereen aanstaat en het voor iedereen doet voelen alsof het weer 1995 is met lekkere knallende 14k4 modems.

[crisp]

Juup schreef op maandag 21 november 2016 @ 22:06:
Niets anders... behalve een hele zwik js code die bugs zou kunnen bevatten.
Moet ik nu echt jouw werk gaan doen en uitzoeken waarom dat plaatje niet laadt?

Zolang dit probleem alleen bij jou lijkt te spelen... ja...

[Puch-Maxi]

Ik zie ook wel eens roze vlakken, vroeg me al af wat het was. Vooral bij het laden van plaatjes in het GGPT lijkt het alsof ik op een trage verbinding zit. Soms scrol je terug en zie je ineens plaatjes die je eerst nog niet gezien had .

[Juup]

crisp schreef op maandag 21 november 2016 @ 22:22:
Zolang dit probleem alleen bij jou lijkt te spelen... ja...

Het probleem zit 'm in de (Force-) Reload van een pagina met een gecachte error image.
Bij een gewone <img/> wordt de cache geinvalideerd en wordt er een nieuw request gedaan.
Bij de LazyImageLoader gebeurt dat niet.

[XWB]

Dat is vrij bekend issue, de gemiddelde lightbox heeft daar ook last van.

[Matthijs]

*schop*!

Graag zou ik m'n stem willen laten horen om het lazy loading optioneel te maken. Ik kijk vaak in topics met veel afbeeldingen op GoT, en deze nieuwe 'feature' zorgt bij mij enkel voor irritatie tijdens het scrollen. De argumenten voor datagebruik zijn duidelijk, maar voor mensen met snelle verbindingen niet relevant.

Standaard inschakelen en optioneel maken via voorkeuren zou een goede oplossing zijn lijkt me.

[ Voor 19% gewijzigd door Matthijs op 03-01-2017 15:28 ]