Lazy-loading does not have to rely on JavaScript

[Malvoz]

Rewording the sentence on lazily loading tiles, as it explicitly calls out a need for JS which isn't quite true as browsers are starting to implement native lazy-loading.

I included a link to https://web.dev/native-lazy-loading, as it is the best up-to-date resource on lazy-loading in my opinion.

[nchan0154]

Good one. Hype for native lazy loading!

[AmeliaBR]

Good point that we shouldn't describe the basic capability in a way that specifies the implementation.

However, I'm worried that the cross-link might confuse matters, since that page is also about a particular implementation (the loading attribute on HTML images) which also doesn't match how it currently works in JS mapping tools. (They dynamically create new img elements with the correct sources as required; even with browser lazy-loading, you usually wouldn't want to create image elements for every tile in advance.)

[Malvoz]

Ah that makes sense, I have removed the link.

[AmeliaBR]

Thanks!

[prushforth]

Was reading that resource on lazy loading, and its clear to me that a whole map viewer should be lazy loaded, if we're talking about the standard rendering model for HTML documents (is this actually a thing - below/above the fold being terminology that applies to that model). Maps, being part of a web page, could have part of their viewport below/ above the fold, so a similar consideration applies in that way. But there's also the logic currently exclusively built into JavaScript libraries, which loads tiles within the viewport, plus perhaps a buffer. So eager loading in that sense could load a lot of tiles to improve user experience, but lazy loading could improve bandwidth economy. It seems like something that should be built-in to the browser, perhaps in response to preferences established in user agent settings?