This is mostly solvable. I recently deployed lazy loading for schematic images on https://ultimateelectronicsbook.com/ and configured IntersectionObserver (with polyfill) to have a rootMargin equal to 3*window.innerHeight (see https://developer.mozilla.org/en-US/docs/Web/API/Intersectio...). Under most reading and even fast-scrolling conditions, the image will be loaded well before it is scrolled into view.

But I will agree with the sentiment -- I find it incredibly annoying on pages that do lazy loading and don't implement this enlarged intersection check to make it appear seamless.

Nice website! Some unsolicited advice: Just looking at the switches page of your website, most images are around 100 kb despite being visually fairly simple. Naively saving one as an indexed PNG image resulted in no visual changes but reduced the size by a factor of roughly 2. I would recommend optimizing your images in addition to what you're already doing if loading time is important. SVG probably would do even better, but I don't know how you're making the images, so I don't know how much work that would be.

Anyone know any books that go the opposite order? Start with interesting working projects, add in the theory as needed to adjust the projects.

To learn photography I'd prefer starting with a camera. Not withe theory of light or the properties of atoms that allow glass to be transparent or how lenses are ground.

Similarly, if possible, to learn electronics i'd like to start at a higher level and work down rather than bottom up.

Interesting, as I'm exactly the opposite.

Are there names for these two types of teaching/learning approaches? Is one "better" than the other?

"Bottom-up" vs "top-down" is the general name for the two approaches, although they're not specific to learning (also e.g. to project planning).

Edit: Actually I'm not sure that's really right, even example-led approaches are usually bottom up. For example, an example-led approach to programming would start with "hello world" and work up from there, leaving a full-blown example project (if there is one) to the end.

Completely non-ironically, I prefer a middle-out approach. I like to dive in past the "beginner" stage immediately, and go from there. If I feel like I need to go back and learn the basics, I can do so on a need-to-know basis.

Your book looks really great, how does it compare with the classic AoE?

Wow, thank you! I think Art of Electronics reads well for people who already have some theory and are ready for a more practical guide. Currently, I'm aiming to build in just a bit more theory/math/background than that, so it can be usable for an undergrad college course, for example. I think AoE really lives up to the "Art" part of the title, and that's probably why it's so beloved.

> equal to 3*window.innerHeight

So basically is regular loading.

Not on long pages with little scrolling.

Looks like the perfect use case for infinite scrolling.

> Click here to see more pictures

Your book looks like a potentially great resource for teaching electronics to music tech students. I will follow your progress! Thank you for sharing.

Lazy loading as a standard would actually make it much easier to modify lazy loading behaviour through browser config and/or addons. Now you are at a mercy of website creator, with a standard and the ability to modify default behaviour through a config you could possibly just switch off lazy loading if thats better for you

this is what I'm hoping since lazy loading is constantly an issue for me (where I live my internet is frequently less than ideal.) Unfortunately my issues are more apparent with content lazy loading, and less with image lazy loading.

This is hands-down the best part of this for me. I can't stand Medium.com and blogs like it, because the images are almost always smeary placeholders unless I want to wait for, like, a whole 60 seconds. And my internet connection is 18mbps! I'd turn off lazy loading in a heartbeat!

Won't turning off lazy loading just make the whole page go slower to load? You are having to queue up connections at some level, just saying not to do it lazily is just asking to download a ton of crap you could skip out on. Or worse, putting it in contention with the rest of the stuff you are downloading. (Imagine opening several tabs on large stories with tons of images now set to eager load. First thing the browser will likely do, is ignore requests from other tabs. Then, you are just back to the game of the page not loading till you get to that tab.)

My use case is predownloading an article before getting on the subway. Sure it's better to lazy load the images in the common case, but the rare cases where the equations and explanatory diagrams are just blurry smears when you are out of 3g range are really annoying. Having the whole article + images download in the background while you are on another tab would be just fine in those cases. As it stands, I have to pre-swipe an entire Medium article and then go all the way back up to start reading it, if I want to make sure I can keep reading it when the subway is in certain parts of the track.

I just have a bad/unreliable connection, and wish websites would GET while the GETtin is good.

Strictly, I'd agree it is better to preload all content for the article. Sadly, that shouldn't include pictures there just for space. Would be a neat audit to do daily. How many images downloaded contributed to your stories or day?

But that's why it's so important that it be part of the HTML spec. Previously, it would have to be implemented in Javascript. Now, you could configure your User Agent to ignore the attribute and eager load.

That way you get the behaviour of always-load and the rest of us get fast loading pages. This is a Pareto move.

Do we really expect people will be configuring their User Agent to ignore this attribute? Seems, wishful thinking.

I want a browser that can predict when I'll have patchy Internet, loading and prefetching as much as possible right before.

I want pages that can load in less space. When most of my Kindle books download faster than most web pages, there is a serious problem.

The problem are mostly with images and javascript.

That is why I wish the next generation image format to push the quality and size ratio. I think JPEG XL currently has the best chances at succeeding Jpeg.

We should have faster Internet (5G and Fibre ) for everyone, and better Image compression for everyone. Hopefully in 5 to 10 years times this problem will be a thing of the past. Assuming we dont bloat every website into WebApps that tries to download 10MB before it even load.

No there's not. Web bloat is a problem, but it's not useful to compare media-rich audio-video capable applications with the lightly formatted, text-only, Kindle book format.

I'm comparing content to content. Yes, some is media rich, but if I want media heavy, I'm likely using Netflix/Youtube or similar anyway. If I'm using a web page, I actually actively don't want media heavy content.

And you can get graphic novels on Kindle nowadays. To pretend it is just text is to undersell the formats now. Could I claim they are bloating? Certainly. Still have a long way to go before they reach current web browser bloat. Which only seems to be marching on. With no signs of restraint on what to pursue.

It’s also not useful for a web page you’re visiting for a few tens of kilobytes of text and a few images to be a media-rich audio-video capable application full of trackers and ads-that-might-be-malware.

Well, in my book webpages are there to display mainly text and maybe an image. So the comparison seems useful to me.

Google says the average size of a Kindle book is 2.6Mb. Web pages are often bad but they're not that bad. If you regularly find Kindle books download faster than webpages I suggest you talk to your ISP.

Web pages are in fact that bad. Testing just now:

* https://www.cnn.com/ is 1.3MB of data.

* https://www.nytimes.com. is 5MB of data.

* https://www.reddit.com/ is 6MB of data.

* https://www.google.com/ is 400KB of data.

* https://www.facebook.com/ (not logged in) is 2MB of data

* https://twitter.com/home/ is 1-3MB of data depending on the ads it decides to show.

Those are all on-the-wire sizes, so after gzip compression and whatnot.

You've picked some very heavy websites, and only two (or three, depending on Twitter) of your six examples are over the 2.6Mb threshold, but fair enough. Popular sites tend to be full of images, and images are usually quite big.

However, this is good, because those are great examples of how browser lazy loading is going to help. When I loaded Reddit it pulled down 7Mb of data, but more than 5Mb was images. Looking at the content above the fold my browser downloaded about 4.5Mb that it doesn't need until I scroll. This change to the HTML spec will get all those sites first load below the average size of a Kindle book. Awesome.

All the examples are indeed over 2.6Mb as that's only 325kB. You probably mean 2.6MB instead but since you're using Mb consistently and the discussion is about transfer sizes I'm not sure.

If you felt mistreated I'm sorry. But it was a genuine question.

https://en.wikipedia.org/wiki/Non-apology_apology#Ifpology ;)

My Kindle books download in a few seconds. And then they are loaded completely and I can jump around in them rather well now. Properly linked books even let me jump from exercises to answers and back rapidly.

And there is some irony that I am likely tracked heavily on what I've read. Certainly on what I note. So it isn't like I'm clamoring for no scripts. Just find it odd that the push for web applications has destroyed the use of web pages.

Websites make gazillion requests and run a bunch of javascript that is in their (not necessarily your) interest. Download size is not the only driver for slowness.

The majority of those requests aren't blocking though, and nor is the JS code when it's parsed and run, so it won't have much of an impact on the parent's perception of how long it takes to load a page. There will be exceptions on sites that have been poorly made but those are unusual these days. If you sit with devtool's Network tab open you'll see a ton of stuff going on, but most of the bad stuff is after the page has rendered and become interactive.

Web apps are a different story because they often load a couple of meg of JS before anything happens, but so long as things are being cached correctly that's only a problem occasionally.

Surely browsers could already do that without a lazy loading spec. I mean, I’m pretty sure browsers already queue requests so that if you load a page with 10,000 img tags it probably won’t do 10,000 simultaneous requests.

Not simultaneous, but it does queue them with some parallelism (6 request for chrome IIRC).

Page basically dies; any Ajax requests are at the back of the queue. Scroll halfway down that page, you'll be waiting 5 mins for the images in viewport to load since they are processed in order. You can roll your own lazy load, but it's a pain and often done poorly. A good browser implementation would be great for most pages (but 10k+ might still require custom work).

If they're annoyed they'll go on the Internet and find out how to do it. Defaults should be useful to the many, and the few can reconfigure their UA.

Think about all the use-cases you could build. Maybe you could later set "I'm on a metered connection" at the OS level, have your browser pick that up, and not overuse your metered connection, etc. etc. Maybe you could have that in a browser extension that you manually toggle. No, this is far too useful.

I'm still skeptical. Is there any precedent for similar features that are used today? Closest I can think of is turning off JavaScript. Which this seems made to combat, honestly. And, honestly, I doubt that has penetration worth talking about.

And again, just don't put so many giant graphics on a page. Problem mostly solved. With less tech and likely faster results.

Please read the spec. Your accusation of this being intended to defeat turning off JS is dealt with here[0]. It's only a +188 -66 patch and eminently readable. If you are discussing this without reading it, this is going to be an unproductive discussion.

0: https://github.com/whatwg/html/pull/3752/files#diff-36cd38f4...

The size is a non sequitor. This is something that otherwise requires javascript. Full stop. No?

Now, I don't actually think this is being done to sidestep people that turn off javascript. Mainly because I just don't think that is a market worth worrying about.

But I can't see why this is a feature that we need. Progressive loading, I could almost see. But by and large, high resolution images are just not compatible with high speed page loads. I'm not seeing how this feature actually changes that.

The link is to the part of the diff that enforces that it behaves identically to current unannotated tags when Javascript is disabled. Obviously if it's designed to be no different from the current state when JS is disabled then it can't combat disabling JS.

See, for me, disabling it would be not eagerly loading anything. This is literally putting the site into what is assumed the least optimized state of scripts are off. Ironic, as typically scripts off should be faster.

Why should built-in lazy loading combat turning off Javascript? It means less pages will be broken when you do that.

Nah. We only expect Firefox to listen to their use-base and disable it everywhere.

And with some extra noise, maybe the Chromium based browsers follow.

If Chrome disables lazy loading by default then web sites will continue to just use javascript lazy loading as they do today. Disabling lazy-loading in your browser is inherently something that can only be useful if it's not the default.

The point of lazy loading images is generally to spare the browser from making a bunch of upfront requests to below the fold content, thereby making it so the page and content in the viewport is ready faster.

If images aren't ready by the time you scroll down, this is more an issue with the particular implementation of lazy loading, but the concept is sound.

I always thought the point of lazy loading is to save the company serving the on bandwidth costs. AFAIK it's never been a good user experience scrolling down and then having to wait for images to load.

That's exactly what it's for. Modern browsers already optimize request order to grab above-the-fold stuff first. Below-the-fold images are loaded eagerly, but only after that.

Of course, they aren't perfect at this, because in general figuring out what's above or near the fold is equivalent to the halting problem (thanks, Javascript!). They do it well enough for the typical case, though.

Lazy loading is all about the hosting costs.

Given prolific use of CDNs and the abundance of cheap bandwidth, saving the transfer of some images isn't as much as a concern as it may have been once upon a non-cloud point in time.

However, if 40-50% of your visitors bounce because your page takes 5s to load[0][1] due to your longform photo essay hammering the user's 4G connection with a bunch of images they won't even see 5 minutes into scrolling down, this is a real concern. Lazy loading shines in these moments.

0. https://royal.pingdom.com/page-load-time-really-affect-bounc...

1. https://developers.google.com/web/fundamentals/performance/r...

In any decent implementation, the lazy loaded images should be loaded before you scroll to them, unless you're jumping halfway down a page. They don't just load what's visible, but also the next section that it's expected you'll scroll to.

A decent implementation would require precognition or at least telepathy. You cannot know when the user scrolls where. Web pages are random access.

Also depends on the skill of the maintainer. Some unskilled maintainers joyfully upload high res unoptimized images (esp if the cms also doesn’t have constrains in place)

Forgive my ingorance, but wouldn't that mean that the browser has to load images in the correct order? So instead of delaying the load until the image is in view, just prioritize loading based on how far up/down the page an image is? If yes, couldn't the browser implement it without any additions to html?

It's not that easy. It's not always that you scroll gradually to the bottom of the page. If you click the scrollbar to the bottom, then the middle images shouldn't load. The same if you use hash navigation to the bottom.

If you refresh the page at the bottom, it will stay at the bottom, so no need to load top images.

Ok, but either way, isn't that logic that browsers could apply without changes to html?

the problem usually looks more like this: I load a page and start reading. When I'm done reading the text/content in the viewport, I scroll down. On a lazily loaded page, now it needs to download the content in the new viewport position. On a non-lazily loaded page, the time I took to parse the initial content allowed the browser to complete loading the page. So effectively the lazily loaded page is taking the 10 seconds it takes to load the page, and rather than doing it while I'm occupied on other things, it holds on to most of that ten seconds, and spends that time when it interferes with what I'm doing, paying it out--2 second wait here, 2 second wait there.

Obviously this is an implementation detail and well done LL could keep loading everything until its done, but frequently it doesn't try until I scroll down. NonLL pages also aren't perfect, and if a page tries to load everything at once, each thing added slows everything else down. But for some reason I never experience that on non-LL pages (or maybe they're good LL pages and I don't notice.) It could be that browsers do some smart things (the obvious would be something like queueing requests for page content, only allowing 5 or so open requests, and loading images in the order they are referenced in the HTML so stuff at the bottom of the page is loaded last.)

>The point of lazy loading images is generally to spare the browser from making a bunch of upfront requests to below the fold content, thereby making it so the page and content in the viewport is ready faster.

In practice, it has the opposite effect when the browser needs to figure out where on the page the image will end up at before attempting to load it.

This is a classic case of “But Sometimes”[1]. I guess sometimes lazy loading of images can be frustrating, but most of the times it’s not.

1: https://www.youtube.com/watch?v=GiYO1TObNz8

I hate lazy loading images all the time. Not just sometimes.

Lazy loading is always frustrating. It never loads fast enough.

Especially when you temporarily lose internet connection -- for example when on some parts of the subway -- which is typically when you want your whole article downloaded beforehand -- especially for example when said images are not just decoration but part of the content for example the equations that explain what you are trying to read about.

This is another good case for progressive images as at least you'll get something on the screen.

I suppose it takes ages because it's many(!) sets(!) of huge(!) images. Not sure if eager loading will help with load time, and it sounds like a huge waste if you didn't see all that enormous loaded stuff.