They aren't going to see behind the TLS curtain, but they would see (assuming no DNS encryption) a domain name lookup followed by various traffic patterns; either: 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-trac…
Even with encrypted DNS, the unencrypted host name is usually part of the TLS handshake (or the server wouldn’t know what certificate to present to you).
But you also usually keep the connection alive for multiple requests.
Hardly any app is designed for subway riders. If they were, we'd have widespread preloading (like half an hour of tweets pre-loaded), seamless delayed posting (sending a new post when the internet comes back online), and visibility into what's downloading and uploading so users can make informed choices. As with all accessibility affordances, this will help people beyond the targeted group - like air travelers, folks…
I dunno, a number of apps I use on the subway are designed for such uses, including audiobook apps, podcast apps and many news apps (e.g. The Economist). But yes, other apps that could be designed that way may not work as well as they should. But even Netflix and YouTube can suggest downloads in advance now. Some apps will never be fully updated - for example, while the standard Mail app works great offline (it's getting it to connect sometimes that seems to take forever), the Gmail app always wants to upload a photo fully to the cloud before sending an email and this trips me up every time, because it never shows a progress indicator and it doesn't allow the email to be sent in the background before attachments upload. It's amazing how in 2023, we have all these engineering resources and lessons that can be learned from apps like WhatsApp, but we still build apps that assume always-on connectivity. It makes sense - even my local subway system is getting cellular service these days - but it's still doubly irritating if in an area with poor signal. (The signals poor, plus the app doesn't work or requires a re-launch, or... etc. etc.)
I live in Germany and so do most of my users, so I take the spotty internet rather seriously. There are lots of holes in the coverage even in the capital. Then there is the underground. 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…
it hurts SEO. In my case the user can live without those images, so it's a sacrifice I'm willing to make. 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.
I feel this. So much of what I do to appease Google Search Console ends up actually hurting the user experience. Blind ruled lacking of context.
They don't need to. They can infer based on the size and timing of the transfers. Nothing for a while then suddenly a huge download? Probably a picture. If the sizes are unique enough they might even figure out which. 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.
But how do they know what you're looking at and how are they using this information to do anything useful? I get you can probably differentiate between text and video, but I'm having trouble understanding exactly what information they would get from your bandwidth consumption.
Lazy loading breaks a lot of functionality. 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.
It feels like this is something the browser can solve by working towards these edge cases as bugs to fix. Especially saving the webpage with lazy loading. I've encountered similar issues when using iOS Share menu to convert a webpage to a PDF or Reader PDF, where sometimes you have to scroll the webpage first before it exports correctly. These are bugs that web browsers need to fix. Similarly, there should be some kind of warning or progress bar if you have downloads in progress but want to go to airplane mode. It could be optional, but like when you close your browser and downloads are still running, it could ask if you want to go offline after downloads finish, for example.
It's curious that some folks hate the side effects of insufficient infrastructure while missing that the lack of modern infrastructure is the root problem. 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.
So:
developers can't change the way society has chosen to prioritize infrastructure, Poor user experience is the result of this societal failure, thus there is nothing that can be done to improve user experience?
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.
It is the web developers choice to decide whether or not to deal with bad/poor internet connections. Most do not. Lazy loading makes it impossible to do anything to manage a poor connection.
> Lazy loading makes it impossible to do anything to manage a poor connection. This was the exact problem lazy loading was supposed to solve