Y’know, folks complain (with some justification) that Bitcoin wastes a massive amount of energy globally. But almost noöne uses Bitcoin, or mines it; I wonder how much energy is wasted on transporting & executing useless JavaScript. It’d be interesting to know how it compares.
This definitely interests me as well. Another 'wasteful' mechanism is the nearly-ubiquitous use of JSON over a more optimized format like protocol buffers, etc... It reminds me of another HN discussion here: https://news.ycombinator.com/item?id=9761667
I understand that economically the savings in development time usually outweighs the bandwidth costs, but I would be interested in any analysis on how wasteful this is overall.
We tested this at $dayjob and JSON+gzip wins hands down because you already have an optimized native-code parser in the browser.
Large-ish arrays of similar JSON objects compress very well with gzip, and ultimately parse more quickly than JS-based protobuf or msgpack, at least in our testing.
I wondered the same thing. I wrote a basic crawler to measure JS footprint on various sites on the web. Most of the JS bloat I found was due to misconfigured webpack configs: leaving development mode on, inline source maps, etc. Tons of whitespace and comments. I tweeted at some of the offenders (https://twitter.com/bundlebloat for those interested), but only a few actually fixed the problem.
You may not need a crawler for this. The HTTP Archive has already done all the crawling for a million URLs from the most popular websites. If one of their existing reports doesn't cover what you need, you can write custom queries using BigQuery:
Bitcoin mining is screenless. Javascript energy is generally outweighed by screen energy anyway, I would imagine. All of which I believe isn't really the lowest hanging fruit.
Your spelling of “noöne” is commendable - I love the rare occasions when I see things like coöperation these days - but “no one” is definitely two words.
I think that ‘noöne’ is the logical next step from the (widely viewed as permissible) ‘no-one’; OTOH ‘noone’ would just be wrong.
Keeping it as two words would be like writing Rechtsschutzversicherungsgesellschaften as rechts shutz versicherungs gesellschaften, which would obviously be terrible
> The use of [diaeresis], however, is considered to be largely archaic.
My experience has it pretty much only moderately commonly used now in “naïve”, and by people that read and enjoy The New Yorker (though possibly only to be different and not for any good reason).
> And if anyone at Google is reading, you should try recommending these strategies for speeding up pages instead of pushing self-serving faux standards like AMP.
They do, sure, but they don't put any teeth into it. AMP pages get special treatment in search results. It's not about promoting fast pages, it's about promoting pages which buy into Google's self-serving AMP nonsense.
Otherwise I'll just dismiss this as the same cloud-oriented geriatric yelling that Hacker News has been upvoting for the last 15 years, to absolutely no purpose or result.
I came here to say basically this. Complaining that a content-centric site like the New York Times loads 2.8mb of data just to load an article is completely valid because it's entirely unnecessary, and makes the end user experience noticeably worse. But let's not generalize that by dismissing all single-page applications; sometimes a heavy frontend really is the best solution.
Author here. Obviously not all "websites" are suited to be done with HTML and CSS alone. The examples I gave, the New York Times, GitHub, and sr.ht, along with many others, are.
That doesn't make anyone less of a dick for letting ad networks ruin their websites. It just means that the old quote applies: "It is difficult to get a man to understand something, when his salary depends on his not understanding it."
I would argue that complex tools like this really have no place on the web. The benefits (available anywhere) are greatly outweighed by the cons (slow, no integration with your system, browser crap, ads, etc etc etc)
TBH as a user i do not see a reason for these two to be running inside a web browser. They'd be faster, more light on system resources, more capable and less locked to their developers' whims as standalone desktop applications (Electron monstrosities excluded).
Web: write once, run everywhere, the user is guaranteed to have the runtime installed.
This is damn hard to beat, even with other reasonably written multiplatform toolkits like Java FX or Qt.
Also, a web page is its own environment, not intended to blend in. With "native" apps, there's always a bunch of "...but not native enough" complaints. (My idea is that some apps should explicitly aim to look alien and their own, without making attempts to fit in, like e.g. Photoshop or Blender do.)
With Java FX, you have to have the user install a recent JRE. With Java 9, though, I suppose you can make one fat binary with only the relevant parts of JRE and you code strung together, and the rest removed. (This has security implications, though.)
Qt means C++ which is a pain for many reasons, or e.g. Python which is a pain to distribute, though this can be alleviated (pack everything into a single fat binary). You still have to have a build per platform.
I just suppose that Web tech expertise is easier to come by, and a Web product faster to produce, at least initially. This trumps great many reasons from the business perspective.
They've all at least got convenient extensions you can install to auto optimise images, like with EWWW Image Optimizer or Smush Image Optimiser for WordPress.
Running the topmost image through Compressor.io gives a ~82% file size reduction with no noticeable image quality loss, and converting the next one from a PNG to a JPEG reduces the size by ~77%. I think there is clearly room for improvement here.
FontAwesome 5 is better. I just integrated this with sr.ht and I can embed each individual svg file direclty into the page when it's rendered server-side. Negligible bandwidth.
a) Apps where the user is expected to stay a while
b) Sites where the user is there, maybe once ever (most likely also scared off by the ads)
For Apps, I would always prefer a pre-load of JS that was built with React and downloads about 2-4 MB. If there is an update I will be forced to download it again.
On the UPSHOT, almost everything I do in that app is now a 3-8KB request. This means transitioning pages, changing states of things, all happen in about 50ms including whatever visual changes are required on the screen.
Compare that to full-screen refresh apps and I am usually waiting 200-400ms. It just feels too damn slow.
Why am I even typing this? This is the freaking whole point of an SPA. Are we not all caught up on this yet?
Unless your user is sitting in the same datacenter as the app, there is almost no chance that you're getting a 50ms latency on any action that requires a round-trip.
Pinging google.com from my current connection (NYC) results in an average 26ms latency. Facebook is 25ms. That's just baseline connection latency for a user in a place with a solid connection, and you're unlikely to do better.
Realistically, most apps that aren't Google scale are lucky to get 300ms average latency. The way you improve responsiveness is by eliminating round-trips, not assuming that client-side frameworks will save you.
Frameworks don't make your code smart. Writing a webapp that aggressively preloads without causing problems is hard, and while frameworks give you some tools to make that easier, they don't do the hard work for you.
> Realistically, most apps that aren't Google scale are lucky to get 300ms average latency.
I am hosting a quite popular site built with perl and php over 20+ years
and with at least 2 round-trips to the DB per request. 150ms latency triggers a warning in monitoring, 200 is considered "critical". The site sits on the west coast, the monitor in Chicago. The site serves at least 10 concurrent clients at any time (read: 5am) up to a few thousand.
And I am painfully aware that the bottleneck is the code, not the network.
Honestly, it sounds like you're set up better than 95% of the webapps I've encountered (and I'm including some big, famous names in that list). Big, well-resourced dev teams make the mistake of assuming that "works on my box" is the definitive measurement of site speed.
But also, let's be real for a moment: define "latency". Is 150ms your (client-measured) connection time? Your render time? Your usable-page time? Again, most webapps are lucky to get HTML back to the user in under 300ms, and if your 150ms metric is "time to server-side render", then you very likely aren't.
150ms are client-side read. But without any js-triggered modifications to the DOM tree, this is pretty much the render time (rendering is 2ms on my not-too-beefy laptop).
Yes, that's quite good. It's pretty common to find server-side actions that take longer than 150ms to just return the page, and 2ms render times absolutely smoke most JS-framework pages.
I stand by my original comment (it's better to avoid loads than to assume you're fast), but good on you for getting those latencies down.
Your math sounds wrong, so I did it on paper and proved that it's wrong.
The average bandwidth for a mobile device in the USA is about 3.25 mb/s (26mbps). So to load your "2-4mb" Javascript library you're looking at 400ms to connect + 1000ms to download resources. That's 1400ms.
Now for the rest of the math I benchmarked my own website. My homepage is ~300kb and loaded in 461ms. The fastest you're going to get ANYTHING back from my server is about ~170ms.
Lets start with your App. 1,400ms and the app is loaded. Load another page and it takes 200ms to load another 5kb of content. Load one more page and it's another 200ms for 5kb of content. I've been waiting on your website for a total 1,800ms and viewed three "pages" of content.
Lets move on to my website. ~450ms and the site is loaded. Load another page and it takes another ~450ms to load another 300kb. Load another page and that's another ~450ms to load another 300kb. I've been waiting on my website for a total of 1,350ms and viewed three actual pages of content, but the user only had to download 900kb instead of 4mb.
User expectations are very different for when they are starting work vs when they are in the middle of something. If it's really a SPA you can also disguise the load times with optimistic updates and such
Also don't forget that frameworks like Phoenix, or alternatively aggressive optimization in other ways, can be significantly faster at that 'first load' than you describe.
But the person you're replying to specifically cited SPAs, single page applications, as the use case for "download a big JS library first and then minimize future loads." If the SPA presents more than five 5kb chunks of what you define as "actual pages of content" to the user in a single session -- which doesn't sound at all unreasonable -- then using your own numbers, the SPA is now slightly beating your web site (2600ms to 2700ms). By ten "pages," the SPA has substantially pulled ahead (3400ms to 4500ms), and has still only sent 50kb of data past the initial huge hit. If the JS library is closer to the 2mb side than the 4mb side, it may well have already sent less data.
At any rate, the NYT page that Drew DeVault is complaining about isn't an SPA, and its problems don't stem from loading a JS library whose point is to make future requests faster. Its excessive JavaScript use is driven almost entirely by including advertising/marketing-driven code, and I would argue that JS is being a bit scapegoated here: it's a symptom, not the problem. I bet we could deliver a lean, mean, highly-optimized version of that web site that duplicated the exact same ads, down to the same obtrusive banner behavior. Would we like the site more then? Would any of us really respond, "Wow, it's so much better now that I can be frustrated by this terrible design in a tenth the load time!"?
I agree that there is a point where SPA's make sense. Like Gmail. If a user logs in, they're probably going to stay a while and use quite a few features. But I'd be willing to bet that the vast majority of NYT visitors will load just one page and then navigate away. If someone is browsing their search results and EVERY website developer assumes that their visitor is in-it for the long haul, that one user is going to consume 12mb of data to load 3 pages off of 3 different domains.
I believe the point of the post wasn't to demonize Javascript, but to point out that there are a lot of low-hanging fruit in the world of web design and that it takes very little effort for developers to simply look at their design in terms of respecting users bandwidth and only using what you need to get your message across.
NYT sent this guy 2.8mb of data from 5 different domains to communicate 9037 bytes of requested content. That should resonate with anyone using multiple Javascript libraries, especially the ones who are offended.
As long as web designers and developers continue to target imaginary users or themselves, they'll also leave real users wanting more.
Great, you've shaved off 150-350ms of refresh load time. So why does your website take 10-15 seconds to load on my phone when I'm walking about the supermarket?
Get out of the lab. Start testing with real users in real contexts. You'll quickly learn that many of your assumptions about what users want disappear.
The issue of course is that about 80% of websites don't need to be 'apps' or SPAs or what not. If you're building a news site for instance, it's basically a blog at the end of the day, not something akin to Gmail or Discord or what not.
Same goes with a lot of sites that seem to be built as web apps despite not needing to be apps in any shape or form.
It reminds me of when I was in 8th grade and I discovered Visual Studio and made tons of "apps" that were glorified iframes with a menu and an about box for no reason other than I could. It's a clear case of a solution in search of a problem syndrome (not that there aren't proper use cases for complex web/desktop apps, obviously).
Map and chat apps are the ones I can think of right now that is better as a single-pager. I have been writing web apps for over 10 years. They aren't single-pagers, yet everything is a "3-8 KB request" and happens in "about 50 ms." There is never a time at any point where "2-4 MB" is needed. Now perhaps you are thinking these are ugly, and it means little to you if I claim that they aren't. All I can say is before I was a programmer I was a graphic designer, and I still like studying and thinking about user interface design. Oh, and my customers have complimented the look and feel of my apps, without solicitation, many times through the years.
On a related note, does anyone have a good recommendation for a lightweight analytics solution?
I've looked at Piwik/Matomo and it looks pretty good. I've also been looking at NGINX Amplify, but that is more web server metrics rather than "analytics" and it's SaaS of course.
You'd think that there would be tons of NGINX plugins for stuff like this, but I haven't found any good self-hosted ones. I really would like to avoid running heavy JS on pages that are <10KB.
So everyone should optimize their web pages? That's not really news. The fact it happens demonstrates the real problems: lack of understanding of the people uploading the content, real financial needs from ad suppliers (Beggars can't be choosers), legacy software that won't be rewritten any time soon and a load of other issues.
I don't think anyone disagrees with the theory, it's the reality we have to deal with.
> The heaviest page, the marketing page, today weighs 110 KB with a cold cache, and 4.6 KB warm. (more comparisons between cold and warm loads)
I set HTTP cache-control immutable on my blog's image/JS/CSS URLs this weekend. Cache-Control: immutable tells the browser that this URL will never change, so don't check to see if it has. It should cut down on the warm loads more. If it does change, the timestamp in the URL path will change, so browsers will check the new URL.
Unfortunately, the extent to which these sorts of guidelines will ever be followed is at most the extent to which programmers feel like putting in extra effort over and above that required to meet business requirements, and will usually require programmers to push back against business requirements in order to achieve any headway.
Those little social buttons that track every user and nobody ever clicks? You're going to have to spend as much time making the case to your boss why they're a bad idea as you would simply implementing them. Ditto ad spam, interstitials, sticky banners, and the like. And if the UX is bad but conversions increase, good luck.
These sorts of guidelines are great for small sites you control yourself. The chances of being able to follow them, even if you give a shit, on a corporate site where conversions put food on the table, is essentially nil.
│ Today I turned off my ad blocker, enabled JavaScript, opened my network monitor, and
│ clicked the first link on Hacker News - a New York Times article. It started by
│ downloading a megabyte of data as it rendered the page over the course of eight full
│ seconds. The page opens with an advertisement 281 pixels tall, placed before even the
│ title of the article. As I scrolled down, more and more requests were made,
| downloading a total of 2.8 MB of data with 748 HTTP
| requests.
That's why I do that in the background with a python script and inline the contents of the hn articles into an RSS feed [1] that I read on a terminal based client [2]. Source [3].
I just tried http://nytimes.com with both Lynx and Safari "in Lynx mode" (disabled JS, CSS, Images).
Reminded me how much I miss gopher.
Lynx's rendering was unusable, because their front page has all the nav, colophon, etc. cruft ahead of the content (in the DOM).
Safari's rendering was almost usable. It still shows fancy typeface for the headmast, etc. Huh. Then I tried to disable custom fonts. I was amused to learn they're rendered with SVG, with no alt-text.
How do they make the money to keep the site up than. Server cost is like 5% of the expenses. Journalist salaries, writer salary all that full time salary, where do you get that from. No other business model exists.
Your bill to isp does not pay the bill for my time and make me a profit. I need to make money, and if you have a problem with my business model, you can move on.
I don't like the NYTimes website, but I like their reporting. If a ton of JavaScript is the price, I'll grudgingly take it. If there's a better way to pay, I'll gladly take that. But this article doesn't provide one, making it nothing more than navel-gazing.
I'm entirely serious. If there's enough people like you, there's a good chance that it'll be noticed.
I tend to think that websites are under-optimizing for responsiveness, though I confess that I don't have evidence for that claim. However, I also think that the kind of puritanism on display in this article requires an amount of work that would be a waste (again, no evidence).
The average NYT subscriber probably doesn’t understand these intricacies around how websites are built and delivered to their phones, or how network effects and scaling affect the infrastructure needed to do so.
They also probably don’t care because they just signed onto the latest “unlimited” data plan with their service provider.
So there probably aren’t enough people who understand the problem to make NYT notice (or care) due to boycotting.
Regarding your last point: a waste for whom? AFAICT the only people benefitting from sticky/engaging services, highly instrumented frontends and downright dark patterns are the people extracting wealth, either directly from subscriptions (not so bad) or, in a much grander sense IMO, data brokers (bad, real bad).
People notice when things are slow and annoying. They close the window and don't look at it.
You might be right that not enough people will change their behavior to make a difference. And if so, tough luck. You and I aren't entitled to a news outlet that meets our latency requirements. We are entitled to complain on HN, but no one will really listen.
Of course you also benefit via reading the news, having reporting on official corruption, and all that jazz. Contrary to your snark about wealth extraction, media outlets are typically losing money and cutting back on reporting. The NYTimes is in a better position than most, but in general, the problem is too little money, not too much.
When on mobile, I don't actually passively browse. I only browse when I need something specific (e.g., directions, movie start time, etc.). To that end, I've used less than 100MB in the last month.
It would also be nice if we could have browsers restrict page size. That is, "hey, server, I'll only accept your page if it's less than X size." That'd be nice because then developers could get some actual feedback.
> And if anyone at Google is reading, you should try recommending these strategies for speeding up pages instead of pushing self-serving faux standards like AMP.
That's hardly fair, Google has been advocating the same web optimization techniques that were listed as part of their Google Lighthouse initiative. I know it's fun and trendy to hate FANG, but you could have got the same recommendations if you opened up Chrome dev console and went to the Audits tab.
This is a problem of economics more than design failure. The current legal/technical system that has developed between ISPs doesn't charge parties fractionally very well.
I still contend that silver-bullet-chasing is at the heart of a lot of web bloat. You have a "startup founder" (or fortune 500 middle-manager) who believes that he has a world-changing (or next-quarter revenue generating) idea, he just needs a couple of grubby programmers to type it into the computer for him. Now, he knows that these grubby computer geeks are far, far, beneath him, and that anything they know how to do must be trivially simple to do, he just didn't take the right classes in college to know which buttons to press to make the world-changing computer thing happen. So the programmers tell him it's going to take a few months. "A few months!" He explodes. "I need this by Thursday! I thought you worthless lot called yourself computer dwee- er, programmers!" So he casts them out of his sight and starts googling "how to program really fast". He comes across Angular. He doesn't know what "Angular" means, but google says it programs really fast, and google is smarters than those dorks who can't even make a website in two days. So he says, "here, use Angular, it makes things go really fast. This is the silver bullet we're searching for". Of course, Angular depends on a few MB of libraries - mostly because when somebody was creating a table controller or whatever the hell for Angular, he or somebody who had some sway over him told _him_ that these other dependencies would let him program real fast. And so on, down the line, until finally something bottoms out into some actual javascript that actually does something. But because making web pages load quickly and be pleasant to use and not choke the internet infrastructure is a "nice to have" but getting this world-changing thing "to market" is a matter of life and death, that nerdy sounding load-testing shit is pushed off until the very end until there's no time to do it and who cares because you can't stand the sight of those slovenly programmers any more anyway and if they knew what they were doing, they'd have gotten it right in the first place.
In addition to the technical concerns is the overall experience that is being designed that requires this type of implementation. This type of ad, popup, subscribe, video, etc... is ubiquitous across news/blogs.
The Internet made copyable content essentially worthless, and we don't have an answer for it yet. If you really want to solve this problem (ultra-bloated web sites because of ad frameworks and what-not), you have to solve that, and it's pretty hard. Honestly, it's probably the case that the only way to really fix it is to nationalize it and fund it with taxes. Not ideal (conflict of interest, obviously), but it's probably better than not existing.
I remember when this was what progressive web development (enhancement was the term) was. I still don't quite understand how it changed into meaning web workers and all the caching and background process stuff.
111 comments
[ 2.9 ms ] story [ 177 ms ] threadI understand that economically the savings in development time usually outweighs the bandwidth costs, but I would be interested in any analysis on how wasteful this is overall.
Large-ish arrays of similar JSON objects compress very well with gzip, and ultimately parse more quickly than JS-based protobuf or msgpack, at least in our testing.
https://httparchive.org/faq#how-do-i-use-bigquery-to-write-c...
[0] https://www.npmjs.com/package/crawler [1] https://rethinkdb.com
Keeping it as two words would be like writing Rechtsschutzversicherungsgesellschaften as rechts shutz versicherungs gesellschaften, which would obviously be terrible
> The use of [diaeresis], however, is considered to be largely archaic.
My experience has it pretty much only moderately commonly used now in “naïve”, and by people that read and enjoy The New Yorker (though possibly only to be different and not for any good reason).
https://news.slashdot.org/story/18/08/26/162242/bitcoin-mini...
They kind of do: https://developers.google.com/speed/docs/insights/rules
Cookies are for keeping logged in state. They are not needed to display html.
But I don't need Forbes so it's ok.
Otherwise I'll just dismiss this as the same cloud-oriented geriatric yelling that Hacker News has been upvoting for the last 15 years, to absolutely no purpose or result.
This is damn hard to beat, even with other reasonably written multiplatform toolkits like Java FX or Qt.
Also, a web page is its own environment, not intended to blend in. With "native" apps, there's always a bunch of "...but not native enough" complaints. (My idea is that some apps should explicitly aim to look alien and their own, without making attempts to fit in, like e.g. Photoshop or Blender do.)
With Java FX, you have to have the user install a recent JRE. With Java 9, though, I suppose you can make one fat binary with only the relevant parts of JRE and you code strung together, and the rest removed. (This has security implications, though.)
Qt means C++ which is a pain for many reasons, or e.g. Python which is a pain to distribute, though this can be alleviated (pack everything into a single fat binary). You still have to have a build per platform.
I just suppose that Web tech expertise is easier to come by, and a Web product faster to produce, at least initially. This trumps great many reasons from the business perspective.
Well played!
https://www.ubuntu.com/desktop
Total download size is 6.87MB and over 6s to render it, for a page with some nonsense overview text, and four pictures. Completely ludicrous.
suggests that the images aren't that bad, only one image is unoptimised, and you'd only shave off a meg from the final size.
Example: https://fontawesome.com/icons/accessible-icon?style=brands
12.75 seconds to load 8.22 MB of data about... a single icon.
a) Apps where the user is expected to stay a while
b) Sites where the user is there, maybe once ever (most likely also scared off by the ads)
For Apps, I would always prefer a pre-load of JS that was built with React and downloads about 2-4 MB. If there is an update I will be forced to download it again.
On the UPSHOT, almost everything I do in that app is now a 3-8KB request. This means transitioning pages, changing states of things, all happen in about 50ms including whatever visual changes are required on the screen.
Compare that to full-screen refresh apps and I am usually waiting 200-400ms. It just feels too damn slow.
Why am I even typing this? This is the freaking whole point of an SPA. Are we not all caught up on this yet?
I think there's a place for sites where the user is expected to stay a while, and where functionality doesn't warrant several megabytes of resources.
Thinking that there's anything but can lead to a wasteful landscape for the web.
Pinging google.com from my current connection (NYC) results in an average 26ms latency. Facebook is 25ms. That's just baseline connection latency for a user in a place with a solid connection, and you're unlikely to do better.
Realistically, most apps that aren't Google scale are lucky to get 300ms average latency. The way you improve responsiveness is by eliminating round-trips, not assuming that client-side frameworks will save you.
Which is why the comment is advocating for locally-cached resources.
"The way you improve responsiveness is by eliminating round-trips..."
Hence "preload" above.
I am hosting a quite popular site built with perl and php over 20+ years and with at least 2 round-trips to the DB per request. 150ms latency triggers a warning in monitoring, 200 is considered "critical". The site sits on the west coast, the monitor in Chicago. The site serves at least 10 concurrent clients at any time (read: 5am) up to a few thousand.
And I am painfully aware that the bottleneck is the code, not the network.
But also, let's be real for a moment: define "latency". Is 150ms your (client-measured) connection time? Your render time? Your usable-page time? Again, most webapps are lucky to get HTML back to the user in under 300ms, and if your 150ms metric is "time to server-side render", then you very likely aren't.
I stand by my original comment (it's better to avoid loads than to assume you're fast), but good on you for getting those latencies down.
The average bandwidth for a mobile device in the USA is about 3.25 mb/s (26mbps). So to load your "2-4mb" Javascript library you're looking at 400ms to connect + 1000ms to download resources. That's 1400ms.
Now for the rest of the math I benchmarked my own website. My homepage is ~300kb and loaded in 461ms. The fastest you're going to get ANYTHING back from my server is about ~170ms.
Lets start with your App. 1,400ms and the app is loaded. Load another page and it takes 200ms to load another 5kb of content. Load one more page and it's another 200ms for 5kb of content. I've been waiting on your website for a total 1,800ms and viewed three "pages" of content.
Lets move on to my website. ~450ms and the site is loaded. Load another page and it takes another ~450ms to load another 300kb. Load another page and that's another ~450ms to load another 300kb. I've been waiting on my website for a total of 1,350ms and viewed three actual pages of content, but the user only had to download 900kb instead of 4mb.
So I think you proved the OP's point.
At any rate, the NYT page that Drew DeVault is complaining about isn't an SPA, and its problems don't stem from loading a JS library whose point is to make future requests faster. Its excessive JavaScript use is driven almost entirely by including advertising/marketing-driven code, and I would argue that JS is being a bit scapegoated here: it's a symptom, not the problem. I bet we could deliver a lean, mean, highly-optimized version of that web site that duplicated the exact same ads, down to the same obtrusive banner behavior. Would we like the site more then? Would any of us really respond, "Wow, it's so much better now that I can be frustrated by this terrible design in a tenth the load time!"?
I believe the point of the post wasn't to demonize Javascript, but to point out that there are a lot of low-hanging fruit in the world of web design and that it takes very little effort for developers to simply look at their design in terms of respecting users bandwidth and only using what you need to get your message across.
NYT sent this guy 2.8mb of data from 5 different domains to communicate 9037 bytes of requested content. That should resonate with anyone using multiple Javascript libraries, especially the ones who are offended.
Great, you've shaved off 150-350ms of refresh load time. So why does your website take 10-15 seconds to load on my phone when I'm walking about the supermarket?
Get out of the lab. Start testing with real users in real contexts. You'll quickly learn that many of your assumptions about what users want disappear.
Same goes with a lot of sites that seem to be built as web apps despite not needing to be apps in any shape or form.
I've looked at Piwik/Matomo and it looks pretty good. I've also been looking at NGINX Amplify, but that is more web server metrics rather than "analytics" and it's SaaS of course.
You'd think that there would be tons of NGINX plugins for stuff like this, but I haven't found any good self-hosted ones. I really would like to avoid running heavy JS on pages that are <10KB.
It’s not self-hosted, but it’s fairly lightweight.
I don't think anyone disagrees with the theory, it's the reality we have to deal with.
http://bluefish.openoffice.nl/features.html
I set HTTP cache-control immutable on my blog's image/JS/CSS URLs this weekend. Cache-Control: immutable tells the browser that this URL will never change, so don't check to see if it has. It should cut down on the warm loads more. If it does change, the timestamp in the URL path will change, so browsers will check the new URL.
https://bitsup.blogspot.com/2016/05/cache-control-immutable....
I suggest caching the main HTML, too. It would get the total warm load down to less than 1 KB.
Those little social buttons that track every user and nobody ever clicks? You're going to have to spend as much time making the case to your boss why they're a bad idea as you would simply implementing them. Ditto ad spam, interstitials, sticky banners, and the like. And if the UX is bad but conversions increase, good luck.
These sorts of guidelines are great for small sites you control yourself. The chances of being able to follow them, even if you give a shit, on a corporate site where conversions put food on the table, is essentially nil.
│ clicked the first link on Hacker News - a New York Times article. It started by
│ downloading a megabyte of data as it rendered the page over the course of eight full
│ seconds. The page opens with an advertisement 281 pixels tall, placed before even the
│ title of the article. As I scrolled down, more and more requests were made,
| downloading a total of 2.8 MB of data with 748 HTTP
| requests.
That's why I do that in the background with a python script and inline the contents of the hn articles into an RSS feed [1] that I read on a terminal based client [2]. Source [3].
[1] https://damng.github.io/hackernews-rss-with-inlined-content/... [2] https://codezen.org/canto-ng/ [3] https://github.com/damng/hackernews-rss-with-inlined-content
Reminded me how much I miss gopher.
Lynx's rendering was unusable, because their front page has all the nav, colophon, etc. cruft ahead of the content (in the DOM).
Safari's rendering was almost usable. It still shows fancy typeface for the headmast, etc. Huh. Then I tried to disable custom fonts. I was amused to learn they're rendered with SVG, with no alt-text.
I don't like the NYTimes website, but I like their reporting. If a ton of JavaScript is the price, I'll grudgingly take it. If there's a better way to pay, I'll gladly take that. But this article doesn't provide one, making it nothing more than navel-gazing.
I'm entirely serious. If there's enough people like you, there's a good chance that it'll be noticed.
I tend to think that websites are under-optimizing for responsiveness, though I confess that I don't have evidence for that claim. However, I also think that the kind of puritanism on display in this article requires an amount of work that would be a waste (again, no evidence).
They also probably don’t care because they just signed onto the latest “unlimited” data plan with their service provider.
So there probably aren’t enough people who understand the problem to make NYT notice (or care) due to boycotting.
Regarding your last point: a waste for whom? AFAICT the only people benefitting from sticky/engaging services, highly instrumented frontends and downright dark patterns are the people extracting wealth, either directly from subscriptions (not so bad) or, in a much grander sense IMO, data brokers (bad, real bad).
You might be right that not enough people will change their behavior to make a difference. And if so, tough luck. You and I aren't entitled to a news outlet that meets our latency requirements. We are entitled to complain on HN, but no one will really listen.
Of course you also benefit via reading the news, having reporting on official corruption, and all that jazz. Contrary to your snark about wealth extraction, media outlets are typically losing money and cutting back on reporting. The NYTimes is in a better position than most, but in general, the problem is too little money, not too much.
It would also be nice if we could have browsers restrict page size. That is, "hey, server, I'll only accept your page if it's less than X size." That'd be nice because then developers could get some actual feedback.
That's hardly fair, Google has been advocating the same web optimization techniques that were listed as part of their Google Lighthouse initiative. I know it's fun and trendy to hate FANG, but you could have got the same recommendations if you opened up Chrome dev console and went to the Audits tab.
That website is an assault by design. And it looks like a lot of people don't really notice, or even mind, being assaulted by it.
First world problems...