It is entirely possible to get a cell signal on a train, even in tunnels. We as a society just choose not to build out the necessary infrastructure.

Ruby isn't that hard to install and use is it? <ducks>

As software developers make up a vanishingly small amount of all users on trains, it seems prudent to highlight their collective experience, not the portion of a one-off that you can control as an individual contributor.

I'm well aware that you or I as individuals have very little control over public transit infrastructure. It's a shame we cannot team up as a group to solve these issues rather than fixate on our experiences solely through a personal lens.

You could have truly wireless electricity power your phone and never have to recharge. You just need to invest in more infrastructure.

That you (and others) think network connectivity is anything higher than a rounding error in terms of rail infrastructure costs is likely part of the problem.

Lazy loading makes it impossible to do anything to manage a poor connection.

This was the exact problem lazy loading was supposed to solve

In all seriousness, as engineers we of course can't assume the happy path is common, and to ensure good UX more often than not we need to account for these cases.

I'm am discussing a solution rather than a series of ephemeral and incomplete fixes. Not that developers can solve public transit issues but that society at large is the only one that can truly solve these issues.

The users are not wrong in my assertion nor do I think disabling lazy loading is the solution. Disabling lazy loading is an ephemeral and incomplete fix that helps some scenarios while degrading the experience in other scenarios.

The solution is improved infrastructure. I don't see why this position is controversial.

It seems more likely that the expectation that users must have consistent connectivity to load (and keep loaded) the most fundamental aspects of a website (images and text) is a poor assumption and the hubris to leave this type of assumption unchecked the actual root problem.

Building a website with the assumption that the user will have a perfect internet connection is like writing an application without error handling. When something goes wrong you can't just blame reality for being imperfect.

For example, I open a webpage and then go offline. Later, I scroll down, but the content is missing.

Another time, I open a webpage and save it. But most of the content is not saved, because it has not been loaded.

The network activity is actually higher for a page with lazy-loading elements.

All-around, it does not make any sense to me, personally.

I guess the lack of user control here is the annoying part. Hopefully in the next round of standards updates this makes it in.

Especially since Google got so bad you can't refind webpages you know exist.

It seemed to me that older versions of the Opera browser did this, and the text-based "links" browser seems to do this today.

I've even had an issue on a project recently caused exactly by the rendered view being saved for the back button. I've also had to demonstrate a possible issue with full page loaders on a regular website twice for the same back button reason - because apparently people (or at least several of my colleagues) don't find browsers' native request loading indication enough anymore... Rotten by JS loaders and SPA's, I guess?

(Firefox) load everything > ctrl+a > right click > view source (have to wait a bit for that to work) > ctrl+a again > copy > paste into text document > save as > example.html

It is a truly insane workflow, as if you are trying to do something weird.

Better to just right click > take screenshot > whole page or use the cli https://firefox-source-docs.mozilla.org/devtools-user/taking...

This bites me often, too. It's always infuriating.

Browsers and developers should try to do their best with limited resources. So it most cases that means making predictions about user behavior. Sometimes that means preloading content (e.g. if you're on a landing page, preloading content from the next likely page will make the it feel much more performant) and sometimes lazy loading to not waste resources if a user isn't going to see content in the first place.

But of course there will be "bad branch predictions" sometimes. I think "having a page load before I get into the tunnel but not scroll down enough to have content load before I lose Internet connection" certainly seems like a case that it's fair not to optimize for.

Before the loading attribute on img, developers did have lots of custom solutions for lazy loading. A major point of lazy loading is to save resources on the server that would be wasted when serving an image that is never seen.

I would rather a user see the whole page, consume all the content, it’s not a big cost.

Some very large sites maintain alternate versions of images in chance the browser supports something more efficient than JPEG; that can save about 30% – at the expense of a lot of complexity and extra server side storage. Yet they still do it: It’s still worth it for them.

But nothing beats not loading the image at all!

As a web user, I personally also don’t particularly like it.

Or do you mean web developers should manually swap assets based on visibility, rather than make a binary load/don’t load decision?

I think this might be more of a well-intentioned effort to help end-users save on bandwidth, but it could lead to a bad experience as OP pointed out in their blog post.

The company I worked for did, but they didn't pay for a CDN, just loaded everything from one server

It’s just progressive enhancement: The browsers that support a format get the lighter version, the ones that don’t, get a heavier fallback.

I'm sure there are some other services which are more image heavy and will save some money this way, but it's not the only reason.

However loading the images early wastes bandwidth, and it hurts SEO. In my case the user can live without those images, so it's a sacrifice I'm willing to make. I hope that descriptive alt tags will help.

On the other hand, the whole text is there from the start and every other way is wrong.

This is one of the big problems with the modern web, It puts you in this doom loop: sacrifice the user to please Google to get users.

In this case it means preserving bandwidth unless it's needed. I lazyload images for the same reason I serve 4 different image sizes.

You can have a slow, bloated website but great metrics, because you’re doing the “right” things.

However lazy loading images that are not on screen is generally a good thing. Images are typically the heaviest part of a website and loading them only when needed is good.

The article in question acknowledges that, but is criticizing the implementation and failure mode.

I haven't seen any statistical evidence, but from my personal experience a typical website with some images, some JS is often heavier on the image side. Fonts can be large too. PNG are heavy. Videos are the heaviest but rare.

However per byte impact on performance (which is a very vague quality) is very different. Often JS degrades performance more than images.

No. An article should always be loaded in full. I clicked a link to a document, that means i wish to view it. Not half, not the first page, the whole thing. If you have tons of content in a single document, you should probably paginate anyway. Images are usually few, and if not totally unoptimized (which you should do before lazy loading), not a huge drain. By all means, lazy load all the unimportant banners, ads and UI elements. Better still, don't add them at all. Only for infinite scroll would lazy loading make sense, and even then batched by 10-20 ahead (or more), so I don't spend time waiting half a second for each and every image.

The heaviest part is nearly always ads and analytics. Cut those down first.

MDN says img lazy doesn't work unless javascript is enabled, so easy peasy to use javascript to make the images unlazy after onload.

You can't do that any more, unless you actively find a way to download the said video.

Bursts (page loads) with near silence in between, maybe just some non-human-triggered traffic from scripts that poll.

Bursts (page loads) with quite a bit more of a human-triggered cadence in between, if lazy loading during scrolling occurs.

But mouse-tracking analytics probably result in a similar leak, if not better.

https://blog.cloudflare.com/handshake-encryption-endgame-an-...

https://www.reddit.com/r/CloudFlare/comments/wp6yve/what_are...

https://en.wikipedia.org/wiki/Traffic_analysis

To stop this, we'd have to saturate the link 100% of the time even when no useful communications are taking place.

What they do with this information is anyone's guess. Just viewing something could put you into some kind of government watchlist. They could use parallel construction against you.

I would think you could effectively disable lazy loading by using a bookmarklet for individual pages, or a userscript in Tampermonkey for whole sites or patterns of sites.

It's not as simple of a solution as a browser option, but I figure solving your problem beats complaining about it.

It works ok most of the time, but I really wish there was a standard for that that browsers could just implement, rather than these (often centralized) apps having to reverse engineer it.

The one I use even belongs to a browser vendor, yet they’re trying to constantly upsell me a premium subscription.

(Specifically, everyone agrees progressively loading your content is to be avoided if possible, whereas “add loading=lazy to your images” is common performance advice.)

Sort of. If you quickly add a letter and then remove it while the page is loading it'll refresh the results though (sort of like a React force re-render)

In terms of pain points, the biggest is Safari. It gets rid of website state pretty quickly. I have tons of disk storage on my phone, why not serialize to disk? It could even be a "frozen" mode that still lets you scroll saved articles. It wouldn't be so useful for web apps, of course.'

On Korean subways I stream video at max res throughout the ride.

As a developer I'm much more interested in optimising for that than accommodating a minor improvement to the experience when experiencing connectivity issues.

This has saved my ass plenty of times when my ADHD brain needed content in places where I didn't have internet.

I haven’t tested it, but I would expect that Firefox for Android would still support going to about:config and changing… hmm, looks like dom.image-lazy-loading.enabled is no more, so I suppose you can just set dom.image-lazy-loading.root-margin.bottom to an enormous number (probably don’t need to worry about top/left/right, but you can do them for good measure if you want).

https://support.apple.com/guide/safari/keep-a-reading-list-s... relevant quote below...

Save a page in your Reading List to read when you’re not connected to the Internet: Control-click the page summary in the sidebar, then choose Save Offline. You can also swipe left over the page summary, then click Save Offline. To automatically save all pages in your Reading List, choose Safari > Preferences, click Advanced, then select “Save articles for offline reading automatically.”

On a very basic level, maybe Mozilla Firefox reader view can ignore the loading equals lazy hint and load all images. One step deeper, maybe we can keep these articles in some kind of local cache?

Come to think of it, what happened with Pocket, that Mozilla acquired? We were supposed to open source the pocket server like five years ago. Did it happen? Does anyone even care about pocket (the read offline app) anymore?

Edit: https://github.com/Pocket/extension-save-to-pocket/issues/75

Travellers may someday (and some do now) look back on losing signal with fondness. A time to reflect, meditate, plan, create, stop consuming for a little while, a welcome break.

You're welcome to meditate if you want while crammed into a stranger's armpit. The rest of us would just like to read the news or catch up with our friends.

This is only a partial solution as no more than a tiny minority would think to actually disable lazy loading. But at least there would be an option for the author and others who operate in contexts where the lazy loading is harmful.

  about:config

  dom.image-lazy-loading.enabled

See https://connect.mozilla.org/t5/ideas/firefox-for-android-abo...

Also: it's a pity that the lowsrc attribute was deprecated. I know there are alternative using JS, but it was useful.

In the now olden days of the internet, people on low-bandwidth connections used proxies that stripped away images.

The irony is that a full category list in json format that could be instantly filtered at the client side would be smaller in size than a couple of jpegs they serve with each product card. And that would make their servers rpm literally an order of magnitude less.

Also they’re probably not trying to save bandwidth but database servers.

At least that's the beef I have, and was reminded of when reading the parent comment.

You'd think it shouldn't be possible. I have fewer than three thousand styles and fewer than thirty thousand style plus color options but strange legacy ERP decisions mean you have weird "data points" like memory capacity of zero for a power bank. Well, duh. It is a power bank. Why do we need to store data for it to say it's memory capacity is zero?

However, I hope that you weren't really storing the integer 0 for the memory capacity of a power bank. It should be null. Most databases handle such sparse matrices very well, it really is not an issue.

It drives me nuts how much completely useless JS is written. 90% or more of web apps could easily be serverside rendered with maybe a few small scripts added.

Instead we have this shit, people writing hundreds or even thousands of lines of JS to make this dumb ass auto-refreshing search/filter page whose only purpose is to make a bunch of pointless requests and computation while I'm in the process of building my query.

Just have the filters be a form and the search button submits it. The backend executes the query, builds the page and returns it. Easy peasy, no pointless requests, no sending megabytes of pointless data in response to every request. No complex JS(which by the way is an absolute shit-tier language for anything beyond 100 LOC) logic.

I may be biased due to my personal experience, personally I find that the vast majority of JS I'm forced to deal with shouldn't exist. It's either a result of bad application design, bad API design, JS that just does things html and CSS do better, or dumb ass requirements like "we need this filter page to update the results every time the user does anything". No you don't, you just need a way to build a query and a way to submit it. And paginate it.

"But page loads take too long that's why we use SPAs" they take too long because you're sending megabytes of pointless JS that shouldn't exist. Remove the JS and they're fast. Plus SPAs are frequently slow as shit anyway, because most web developers just kind of suck and write shitty code. Like sending a huge Json document with every request rather than handling it in the backend.

As a consumer, this all feels like being between two fires. One side creates the stupidest UX possible, where one change can fix that, while the other side claims it’s all bs anyway and we must go medieval. Can’t we just listen to a user for once?

> sending the full dataset (*which could be fine if it's small*)

In the specific case of search/filter pages, I prefer the server-side rendered experience as a user. If I want to just check the box for RAM and search instantly, I can do that. But if I want to build a more complex query I don't need it to keep updating over and over.

I don't necessarily hate the auto-updating pages if they are implemented well. I just don't think they're any better, so why waste dev hours on it? It costs money to maintain that code, and the more of these pointless little JS applications you bake into your website the more expensive it is to build and maintain.

If there is something beyond Hanlons Razor, I’d like to understand by which metric it works and how. E.g. how fetching 30 rows 10 times through different params compares to fetching 200-300 rows once, assuming various sorts of caching, etc. If everyone does it, it’s either a common methodic or a common ui-fad incompetence. But then even a shallow search should yield at least some results. It doesn’t.

Most storefronts are designed more or less as an obstacle course to make any sort of scraping or automated retrieval more obvious, this includes having beyond useless filters, having no working search function, having nebulous item names, paginating with 4 items at a time, etc.

Very bad UX

Actually, in general I would like to see RSS (or even a more draconic, constrained form of RSS) be a relevant web standard for traditional information dense webpages.

Then you start counting to yourself: one one thousand, two one thousand, 3, 4, 5, 6...

After about six seconds, sometime a little less, the display updates to show the current ACTUAL time. The one it shows before that could be 5,20,40 minutes or up to an hour and a half, AGO.

I have never hated a phone so much. My hatred is palpable and intense. Of course the so-called-OS is the "latest" version which is only because Verizon abandoned it as soon as they rolled it out. And there are no options available that change this broken behavior.