Finally,dynamic loading is worse for slow connections. People on slow connections load pages in the background or switch to a different task while the page loads. They're used to this, it's normal procedure when browsing. Dynamic pages break this. We see the page load quickly, but then constantly have multi-second pauses while consuming the content because the page keeps halting to load more content.
Well, that's not being done correctly, either, then. What *should* be done, so that users can immediately switch to a tab ans see content, is to load the content that is visible in the current viewport first, then content less than one full screen out of view, so it's there when the user starts scrolling. For many pages, that means just loading all the content, but for longer pages there will still be content left unloaded. The script loading the content should monitor load times and determine if a given bit of content is will take more than 0.5*[number of screens away] seconds to load, and load it early if it is.
Done correctly, the user shouldn't be aware of the delayed loading in most cases, and minimally aware of it in the worst case. Given that one side has bandwidth costs and the other side likely has either caps or costs, it's beneficial to everyone, but, again, only if it is done right. Which we can both agree it, typically, is not.
But, when you decry the practice in its entirety, you set yourself up to be ignored by the developer community as a whole. They hear someone who simply prefers to not have the feature at all; mind you, it's a feature their employer is insisting on having, so they're not allowed to listen to you. Instead, do what I'm doing, point out what is wrong with the implementations and pose solutions; then, the developers can listen.
47% expect a web page to load in two seconds or less.
40% will abandon a web page if it takes more than three seconds to load.
52% of online shoppers claim that quick page loads are important for their loyalty to a site.
14% will start shopping at a different site if page loads are slow, 23% will stop shopping or even walk away from their computer.
64% of shoppers who are dissatisfied with their site visit will go somewhere else to shop next time.
Since when is giving people what they want a bad thing?
As for your claims re: performance, well, I agree it can be overdone. But you're wrong in cases where it is done right. Loading and rendering only the data that needs to change is *much* faster than loading and rendering the entire page and, done correctly just as bookmarkable.
I can't help the fact that the people who ultimately decide whether developers eat or not don't allow them the time required to implement things properly. My workaround was to quit working for someone else, and I've seen the quality of my own work improve immensely since then.
Especially static content, and especially when the content of the article is a series of sentences punctuated by big squares that, rather than loading images, contain t.co redirects to the images that some doofus tweeted.
And this is where your understanding of the problem fails.
Again, this is a middle-management and bean counter problem, not a developer problem. The developers don't sit there and ask "How can we add more Twitter to our pages?" On the contrary, the bean counters say "We can save on bandwidth by letting Twitter and Instagram host our images, while at the same time monetizing our users through forced interaction" and the managers relay that as "Give us the ability to easily link to Twitter and Instagram images or go find another job".
And, of course, the developers do it. Why? And why shouldn't you fault them for it? Because they know damn well that if they go work somewhere else, it's just more of the same, from the same kind of shitty bean counters and managers who don't understand that this shit kills their user base, in turn killing their income. If they don't do it for their current employer, they'll be asked to do it for their next, and the one after that, and after that, and so on, and so forth, until they are unemployable. Even McDonalds won't hire them after they're on their 6th job in a year. Then they starve.
I can totally see other developers, who haven't been conditioned to realize that system resources are finite and not everyone has the latest and greatest CPU and GPU with oodles of RAM and gigabit internet (I wish... 150mbps is the best I can get and it's not worth the expense), assuming, since their code only lags slightly on their maching (which they blame, of course, on the browser dev tools), that it will, at worst, only lag a little on the user's machine which, typically, is much *much* less powerful.
So, I really don't blame the developers implementing the shit code, even; it all comes back to the idiot telling them not to fix what's broken, because they don't see how or why it's broken in the first place.
I worked for myself for 7 years before taking that job and I watched the quality of my code steadily decline while I was there. I've only been working for myself again for a little less than 2 months and I'm already seeing the quality of my output shooting back up to where it was 4 years ago, and still climbing, as I've learned much over the past 4 years, on top of simply having better tools now than I did then.
Without that perspective, though, I see how easy it is to blame developers for everything, but the reality is much, much different in most cases and developers don't get to choose to write good code; they only get to choose between writing shit code for their current employer or for their next. Sometimes that's because the employer sucks and sometimes it's because they suck; I've talked about both here.
Don't get me started on sites that don't even start loading the images until they're scrolled into view and don't use placeholders, so the images, when they finally do load push down the content you were reading. If I understand correctly, that's what you're talking about and yes, as a web developer, it annoys me to no end when some code monkey pulls that shit and sullies my good name, and that of the other competent developers I know.
It's not even that hard to do, but most devs don't take the time to think about it, usually because they're not allowed to spend their time on such things. Again, blame shit-tire middle management and bean counters for that.
But that's cool, just go on blaming web developers and technology, keep shielding the bean counters and middle managers who refuse to consider the end users and force us to either create complete shite or move on to the next job, where we'll be forced to make the same decision again... and again... and again.