Last modified: 2014-01-28 05:26:23 UTC
Since basic jquery is supported in recent MW versions I don't see why lazy image loading is not supported. Images below the monitor view are only loaded when viewed. This reduces http page loading time by less http requests and faster page building, esp. on gallereis but also on most article page views when people don't scroll. http://www.appelsiini.net/projects/lazyload - example page: http://www.appelsiini.net/projects/lazyload/enabled.html Users with disabled javascript can be served with a noscript tag.
If you think it's useless for thumbnails than explain why IMDb uses all over the place.
Don't some noscript like extensions have issues with the <noscript> tag? And of course when scripts are blocked with something like AdBlock or more likely RequestPolicy there will be a similar user. For the majority of users with JS enabled this also sounds like it'll cause the loading of images to be delayed resulting in it taking longer to show even the first images on the page. Lazy loading of course also causes images to flash in. Both distracting for most users and annoying for users who scroll down, want to see an image, and then have to sit and wait for their connection to download it. And to be quite frank. Lazy loading images to make pages not download as much when not necessary. That sounds like the kind of feature a browser is supposed to implement, not a website. I wonder what happens to Google's image spider when something like this is done.
"Both distracting for most users and annoying for users who scroll down, want to see an image, and then have to sit and wait for their connection to download it" That makes no sense, sorry. 1) 99,999% of the time users do not open a page in order to scroll down to see an image. And if, it will be there FASTER than without lazy iamges: 2) Without lazy images the image has to load as well. And images don't "flash in" more than without lazyness (wtf? "oh noes! the loading image scared me to death!!"). You can set a fade-in time if really wanted. But to be fair, the argument that it should be a browser feature not a website feature makes sense. But the advantage here is that browsers cannot know what a page is used for. Humans do. I wonder what the commons guys think about it.
"sounds like it'll cause the loading of images to be delayed resulting in it taking longer to show even the first images on the page." Hmh, no. If "fade-in" is not used, there is no delay. The page is ready without the images being loaded(!), then images are loaded. Thus, the whole page is loaded faster than without.
*sigh* please keep in mind how a browser works. - The browser starts downloading the HTML and does partial rendering as it downloads - As it finds scripts and images it starts to download them in parallel -- As images finish downloading the browser incorporates them into the rendered page -- Scripts are executed in order, blocking the rendering of things after them and naturally waiting for src="" based scripts to be downloaded. - domready is fired after the browser has finished downloading and parsing the HTML in the initial request. - Also in the case of ResourceLoader we initiate the downloading of a script inside a script, so the http requests for scripts also don't even start until the entire initial request has been downloaded and all the other <script> tags in the page have also been downloaded and executed. So here's what changes: - In a normal request the browser will start downloading images as soon as it sees the <img> tag and render them into the page while it's still downloading the page (with the first images in the page likely ending up ready to view along with the content while the browser is still working). - In a lazy request the <img> will have a placeholder, the browser will download all the scripts on the page and execute them, after the entire page has been downloaded and parsed and the other scripts have been executed it'll then execute the RL script and begin downloading our RL modules including the lazyload code, the lazyload code will then run and THEN after all that the browser will begin downloading the images at the start of the page. This means that on a long page lazy loading images at the JS level will delay the loading of the first images on the page and instead of being able to see the image while things like the sidebar haven't even shown up yet the image will not show up until EVERYTHING else has been downloaded. Try using Sloppy (http://www.dallaway.com/sloppy/) to simulate an EDGE connection and see what happens when you view the lazyload disabled and enabled demos using it to simulate a slow connection. Which actually brings up another point. Actually testing with sloppy myself shows me that not only does it slow down the loading but it also destroys the browser's native ability to progressively render a partially downloaded image ruining the user's experience even more.
On a normally loaded page the browser (in parallel) downloads all of the images on the page. While on a lazy loaded page images are not downloaded until they are in view. So on a normal page everything will be loaded and rendered relatively shortly. When lazy-loaded, the page has finished loading, and the user beings to scroll down the page reading the content images will begin to come in view as their reading the content. In a normal page these would already be loaded. In a lazy-loaded page the browser will start initiating new http requests as the user is reading. As the user is reading content placeholders will be replaced with a full image. This change is visible in the corner of the user's eye and has a similar effect distracting the user from the content they are trying to read as an animated .gif has. So yes, they "flash" in.
Thanks for the explanations. You're right, the first visible images load later. The delay is even there when the images had already been loaded to chache before. I didn't think of RL (MW 1.16 here). "In a lazy-loaded page the browser will start initiating new http requests as the user is reading. As the user is reading content placeholders will be replaced with a full image." That's what it's all about, right. The main advantage is to save unneeded http requests for cases when the user doesn't scroll (like long IMDb pages or Google image search). You mentioned slow internet connections: lazy loading is better than loading possibly unneeded stuff in advance, no? Cannot use Sloppy at work here, will test later. I agree they would "flash" in on article pages. But on galleries it would not distract concentration (nobody gets distracted when scrolling on Google image search). Take a random top-viewed article http://en.wikipedia.org/wiki/Barack_Obama : when you just need quick info from the top (e.g. when he's born) lazy loading would save loading 28 other images from below (not counting template icons and stuff). But the main argument that makes me think is why browsers didn't implent it yet by default.
(In reply to comment #7) > That's what it's all about, right. The main advantage is to save unneeded http > requests for cases when the user doesn't scroll (like long IMDb pages or Google > image search). > You mentioned slow internet connections: lazy loading is better than loading > possibly unneeded stuff in advance, no? > Cannot use Sloppy at work here, will test later. On a slow connection a normal page will download and in parallel download images as it can. If you wait for the page to load (as any dial-up user likely will be anyways) and come back you can scroll down and all the images will be ready for you as you read them. But if lazy-loading is in place only the top images will be downloaded. So after waiting awhile for the page itself to load instead of scrolling down and everything being ready you'll scroll down and have to wait even longer for your slow connection to download every image you come by bit-by-bit.
So you agree with me and normal page loading on slow connections is only better when you 1) come back and 2) sroll down so it can load from cache what was downloaded but not needed on first visit? Sounds not so convincing actually ;) I don't want to start an epic argumentation tho. Lazy loading has disadvantages but can save http requests on long pages and galleries.
*facepalm* What kind of bad reading does it take to come up with an assertion like that from what I said? I said that for a user reading the full article with a slow connection lazy-loading forces them to wait even longer to see the later images on the page instead of letting the browser just download them all slowly in parallel in the background while they are reading the first part of the page.
I believe lazy-loading of images would also break printing etc. My real preference long-term is on finer-grained reading sizes -- eg start by showing sections with active navigation/search between them, and have a separate "full printable article" view for those occasions when you actually need everything. But that's some ways away and needs better handling for references and all sorts of things, I expect. Specifically lazy-loading images on scroll I'm going to go ahead and nix; marking this as a wontfix.
Reopening this -- large articles, metered connections, and retina displays can combine to make images rather expensive. We should reconsider something like this, and just keep it off on the printable view. Nobody believes in printing the regular view anyway... :P :)
(In reply to comment #12) > We should reconsider something like this, and just keep it off on the > printable > view. Nobody believes in printing the regular view anyway... :P :) :/ I do.
(In reply to comment #12) > Reopening this -- large articles, metered connections, and retina displays > can combine to make images rather expensive. > > We should reconsider something like this, and just keep it off on the > printable view. Nobody believes in printing the regular view anyway... :P :) A year later... Is this still a good idea? The use cases mentioned by Brion are mobile-centric, and I wonder whether any improvements in core would automagically run in MobileFrontend or this feature in mobile should be in fact be implemented in MobilFrontend alone.
