Live data from Hacker News

The 49MB web page

thatshubham.com

281–290 of 389 posts

Re: The 49MB web page

#281
post #47

My family's first broadband internet connection, circa 2005, came with a monthly data quota of 400 MB. The fundamental problem of journalism is that the economics no longer works out. Historically, the price of a copy of a newspaper barely covered the cost of printing; the rest of the cost was covered by advertising. And there was an awful lot of advertising: everything was advertised in newspapers. Facebook Marketpl…

> The fundamental problem of journalism is that the economics no longer works out.

Yes it does, from nytimes actual earning release for Q 2025:

1. The Company added approximately 450,000 net digital-only subscribers compared with the end of the third quarter of 2025, bringing the total number of subscribers to 12.78 million.

2. Total digital-only average revenue per user (“ARPU”) increased 0.7 percent year-over-year to $9.72

2025 subscription revenue was 1.950 billion dollars. Advertising was 565 million that includes 155 million dollars worth of print advertising.

Sure operating profit is only 550 million very close to the advertising revenue, but the bulk of their income is subscriptions, they could make it work if they had to. My suspicion is that if they dropped all the google ads they could have better subscription retention and conversion rates as well.

Re: The 49MB web page

#282
post #81

Let's play a fun prediction: I ask HN readers what will be the page size of NYTimes.com in 10 years? Or 20 years? Want to bet 100 MB? 1 GB? Is it unthinkable? 20 years ago, a 49 MB home page was unthinkable .

In 10 years - 100MB In 20 years - 20MB

I think there'll continue to be growth in page sizes, but then maybe we'll consider efficiency, or the NYTimes shuts down and the 20MB page will be the liquidators selling the domain. Maybe we don't even use domains by then as everything is on an app.

Re: The 49MB web page

#283
post #235

Earlier quoted context omitted.

I as a developer cannot refuse to not build as-is what was signed off by product manager in figma. Recently had to put so many huge blurs that there was screen tearing like effect whenver you srcolled a table. AND No i was not allowed to use prebake-blurs because they wouldnt resize "responsively"

If you don’t have an engineering manager or tech lead able to back you on saying no to a PM, there is something seriously broken with that organization.

True, but this describes at least half of software engineering organizations in my experience.

Re: The 49MB web page

#284

Bit unfair, turned off my adblocker and ran NY Times website with cache disabled via Dev Tools, came to 3MB. Still pretty damn high but not 49MB. (Will say I'm in the UK so might be different across the pond).

I'm also in the UK, and it came to 31MB. Then I turned off uBO, Firefox tracking protection, and rejected the cookie notice, and it went over 40MB.

Re: The 49MB web page

#285
post #280

> I don't know where this fascination with getting everyone to download your app comes from. Apps don't have adblockers.

Most in-app Ads can be blocked with simply changing your dns. And most people don't even use adblocker when browsing normal site. I kind of had to tech my surrounding people to use adblocker.

Isn't that a much higher bar for most people? I don't even know how to change the dns on my phone, and I am not a typical user, I am a dev.

But running a browser that blocks ads like duckduckgos is super simple.

But yeah I am sure there are additional tracking and possibly retention benefits.

Re: The 49MB web page

#286

"The Sticky Video Player Publishers love embedding auto-playing videos these days, which isn't really popular. You'll find mulitple forum, Reddit, HN, or Twitter threads about it. To make it somehow worse...when you scroll down, you think it would leave you as it leaves the viewport. No. It detaches, shrinks and pins itself to the bottom right of your screen and continues playing. It keeps the distraction going and a…

Blocking the domain of the video player works. For example, primis.tech you can add this to your uBO filter:

  ||primis.tech$domain=~primis.tech
Primis is one of them, but there are a few of these companies. I can't remember them all.

Re: The 49MB web page

#287
You want to know why so many people either jump straight to comments or use alternate sources (archive, llms)? Because if you load the actual site, it freaking blows to use the damn thing.

So much hostile user design.

Edit: NPR gets a little shout out for being able to close their annoying pop-ups by clicking anywhere that's not the notification. So it's still crappy that it hijacks the screen, but not awful I guess?

Re: The 49MB web page

#288
post #172

Earlier quoted context omitted.

Datapoint: During the pandemic, I had to use an old 2004 Powerbook G4 12" (256 MB RAM, OS X Leopard). Everything sort of worked and was even reasonably snappy. But open one website, and the machine went down. Unusable. Even if, indeed, I just wanted to read or look up a few kB of text. So painful.

One tool I've found useful in low-power/low-bandwidth situations is the Lynx web browser [1]. Used to be installed by default in most Linux distributions but I think that's probably not the case anymore. Wikipedia says its also available on OSX and Windows. https://en.wikipedia.org/wiki/Lynx_(web_browser)

Chawan is nice

https://chawan.net/

Re: The 49MB web page

#289
I was thinking about creating charts of shame for this across some sites. Is there some browser extension that categorizes the data sources and requests like in a pie chart or table? Tracking, ad media, first party site content...? Would be nice with a piled bar chart with piles colorized by data category.

Maybe you'd need one chart for request counts (to make tracking stand out more) and another for amount of transferred data.

Re: The 49MB web page

#290
post #256

One of the things I don't get is the economics of these trackers. Someone is serving this amount of data to every visitor. Even if you want to track the user as much as possible, wouldn't it make sense to figure out how to do that with the least amount of data transfer possible as that would dramatically reduce your operating cost? Perhaps size optimization is the next frontier for these trackers.

Traffic for the static payload is super cheap. And the insane amount of requests is handled easily by modern event-based architectures. The operation costs are most likely only a tiny amount of the overall economics of the tracker's buisness model. The generated tracking data is certainly worth an order of magnitude more then it takes to generate it.
Post reply on HN