[1vuio0pswjnm7]

There could be a companion article: "Will Consuming Only Real HTML Content Make A Website Faster? Let's Experiment!"

Having myself run this "experiment" for many years now by (a) controlling DNS so that only the domain in the "address bar" URL is resolved^1 and (b) making HTTP requests using a TCP client and/or an unpopular nongraphical web browser that only processes HTML and does not perform auto-loading of resources. No images, JS, CSS, etc.

The answer to the question is yes. This "makes a website faster", or, more specifically, as someone else in the thread has stated, it does not make the website slow. It does not accomodate the practices of "web developers" that slow a website down.

But most importantly, IMO, it makes "website speed", not to mention appearance, more consistent across websites. Good luck achieving any semblance of that with a popular graphical web browser.

Most web pages submitted to HN can be read this way. I find it easier to consume information when it follows a consistent style of presentation and without the distractions enabled by "modern" web browsers.

1. This is the only URL the www user is informed about. In the short history of the www so far, auto-loading from other domains, whether through HTML, Javascript or otherwise, has unfortnuately been abused to the point where allowing it produces more risk-taking for the www "user" than convenience for the www "developer". Sadly, instead of deprecating the "web development" practices that have been abused and make websites slow, the new HTTP standards proposed by an advertising company and supported by CDNs cater to this practice of "composite" websites comprised of resources from various third parties. It stands to reason that advertisers and therefore "tech" companies and their providers, e.g., CDNs, stand to benefit more from "composite" websites than www users do. IMHO the easiest way to "make websites faster" is to stop enabling "web developers" to do the things that make them slow.

[azangru]

> stop enabling "web developers" to do the things that make them slow

It's been said countless times; but Slack, Discord, Youtube, Google Meets, Figma, Google Maps, Google Docs, Github, Excalidraw, Penpot, Diagrams.net etc. etc. are all web sites. They are a different class of websites than Hacker News or Project Gutenberg, being more apps than documents, but they are an important class, too; and they were all made possible because web developers were enabled, through various browser apis, to build them; and I am grateful for that. Wishing that web developers were not enabled to build complex things on the web is inconceivable to me. It's the culture and the education around web development that should change; not the enablement of web developers.

[gnz11]

> being more apps than documents

Is “web application” not a common term anymore? Haven’t we always made the distinction between web apps and web sites?

[lowwave]

> IMHO the easiest way to "make websites faster" is to stop enabling "web developers" to do the things that make them slow.

yeah as one those developers who jumped on the processing everything on the client/browser side, and supported all the browser having fancy JS features when ajax first popularised by gmail, I have come to regretted my decision. Especially with all the standards proposed by an advertising companies, the user/consumers don't really benefit from the usage of the web.

[makeitdouble]

I see it as a rare case of "hate the players not the game"

I've come to rely a lot on gitlab and github's web interfaces through the years for diff and quickly navigate a specific commit, or a project I don't want to checkout. All the improvements coming from more JS and Ajax have been a boon to me. Sure I could do everything locally, but it's just so much more convenient.

Same for gmail as you mention it: I wouldn't go back to the previous web mail interfaces short of getting paid a living salary just for that. Same for banking web sites, which came such a long way.

The technology and trend is a net plus, advertising company coming to ruin whatever they can ruin is par for the course. I mean, looking at newspaper, TVs, Google Search, YouTube, Instagram, AppStore search etc....making anything it touches worse is in the ad business' DNA.

[lowwave]

For sure, I agree that the ajax UI/UX offered by gmail is a game changer. And all those features that makes it convenient for users, can be accomplished without compromising security/privacy. What I don't like are companies proposing standard disguising as a some convenient feature, where in reality is just a racket to mine data from the users.

[throwaway742]

What browser do you use?

[1vuio0pswjnm7]

For reading HTML, I use various versions of links 1.x and links 2.x, patched to meet personal preferences. Of course links can make HTTP requests, as well as display HTML, but I use a variety of programs to make HTTP requests. When I use links to make HTTP requests, it is always through a loopback-bound proxy.

For commercial use of the www of course I am forced use a popular graphical web browser like everyone else. But I make minimal commercial use of the www. Most www use for me is academic or recrerational.

[throwaway742]

I had campus security called on me because I was using an acoustic coupler on a payphone to a free dial-up provider to browse the internet via links. Luckily the security guard understood what I was talking about and was chill, but he couldn't understand why I wasn't just using the campus WiFi.