And second, if I scroll too far, the comment widget loads on each page, which causes the machine to spend Internet bandwidth on downloading, and CPU time on laying out, comments from other readers rather than downloading and laying out other articles.
So, wait... you like lazy loading, then?
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?
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.
Factorials were someone's attempt to make math LOOK exciting.