Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The 49MB web page

thatshubham.com

Post reply on HN
Print view View original

251–260 of 389 posts

Re: The 49MB web page

#251

Post by int_19h »

drnick1 wrote: post #123

It's almost criminal that the article does not mention network-wide DNS blocklists as an obvious solution to this problem. I stop nearly 100% of ads in their tracks using the Hagezi ultimate list, and run uBlock on desktop for cosmetic filtering and YouTube. I should really run some to tests to figure out how much lighter the load on my link is thanks to the filter. I also manually added some additional domains (most…

It does indeed work pretty well today, but they have already developed ways to circumvent it. For example, serving ads from the same domain as the main page.

Re: The 49MB web page

#252

Post by int_19h »

jdross wrote: post #8
ronsor wrote: post #4

Earlier quoted context omitted.

Well, I'm going to block the ads anyway (or just leave), so if they're trying to find profitable ads, they may need to revise their strategy.

“I’m going to either steal your work in a way you don’t consent to, or not consume it” isn’t really great. The alternative is paywalls

Anything that kills adtech faster is a good thing at this point.

Re: The 49MB web page

#253

Post by doe88 »

hilbert42 wrote: post #11

These days the NYT is in a race to the bottom. I no longer even bother to bypass ads let alone read the news stories because of its page bloat and other annoyances. It's just not worth the effort. Surely news outlets like the NYT must realize that savvy web surfers like yours truly when encountering "difficult" news sites—those behind firewalls and or with megabytes of JavaScript bloat—will just go elsewhere or load…

I don't understand all these sites with moving parts even with muted soon, like if everything was a collection of GIFs. NYT followed this path and started to insert muted clips preheminently on their page one, very very annoying.

Re: The 49MB web page

#254

Post by chrismorgan »

jonwinstanley wrote: post #215
chrismorgan wrote: post #198

Earlier quoted context omitted.

Peanuts! My wife’s workplace has an internal photo gallery page. If your device can cope with it and you wait long enough, it’ll load about 14GB of images (so far). In practice, it will crawl along badly and eventually just crash your browser (or more), especially if you’re on a phone. The single-line change of adding loading=lazy to the elements wouldn’t fix everything, but it would make the page at least basically…

Haha excellent. Presumably all the images are the full res haven’t been scaled down for the web at all?

Could it be any other way?

Re: The 49MB web page

#255

Post by rhysfonixone »

hibikir wrote: post #179
PunchyHamster wrote: post #20

Our developers managed to run around 750MB per website open once. They have put in ticket with ops that the server is slow and could we look at it. So we looked. Every single video on a page with long video list pre-loaded a part of it. The single reason the site didn't ran like shit for them is coz office had direct fiber to out datacenter few blocks away. We really shouldn't allow web developers more than 128kbit o…

You don't even need video for this: I once worked for a company that put a carousel with everything in the product line, and every element was just pointing to the high resolution photography assets: The one that maybe would be useful for full page print media ads. 6000x4000 pngs. It worked fine in the office, they said. Add another nice background that size, a few more to have on the sides as you scroll down... I wa…

Many web application frameworks already have extensive built-in optimization features, though examples like the one that you shared indicate that there are fundamentals that many people contributing to the modern web simply don't grasp or understand that these frameworks won't just 'catch you out' on in many cases. It speaks to an overreliance on the tools and a critical lack of understanding of the technologies that they co-exist with.

Re: The 49MB web page

#256

Post by trashb »

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.

Re: The 49MB web page

#257

Post by aembleton »

jakub_g wrote: post #237

> 422 network requests and 49 megabytes of data Just FYI how this generally works: it's not developers who add it, but non-technical people. Developers only add a single ` ` in the page, which loads Google Tag Manager, or similar monstrosity, at the request of someone high up in the company. Initially it loads ~nothing, so it's fine. Over time, non-technical people slap as many advertising "partner" scripts they can…

The good thing about the heavy use of GTM, is that its easy to block. Just block that one endpoint and you remove most of the advertising and tracking. When some new advertising service is invented, its already blocked thanks to the blocking of GTM.

Re: The 49MB web page

#258

Post by DorkyPup »

quectophoton wrote: post #241
DorkyPup wrote: post #232

Author here. Woke up in today to see this on the front page, thank you to the person who submitted it! Initially, my biggest fear was the HN "Hug of Death" taking it down. Happily, Cloudflare's edge caching absorbed 19.24 GB of bandwidth in a few hours with a 98.5% cache hit ratio, so the origin server barely noticed. The discussions here about DNS-level blocking and Pi-hole are spot on. It's interesting that the bur…

Out of curiosity, do you have (and want to share) stats about requests per second? It's always nice to know these things for future reference. No worries if not :)

Sure thing! I don't have the exact instantaneous peak since Cloudflare groups historical data by the hour on the free tier, but the peak 60 minutes last night saw 70,100 requests. That averages out to about 20 requests per second sustained over the hour. Wish I could be more granular but hope that helps a little.

Re: The 49MB web page

#259

Post by aembleton »

TheMode wrote: post #74
keane wrote: post #48

Earlier quoted context omitted.

It’s hard to beat https://lite.cnn.com and https://text.npr.org (I imagine their own employees likely use these as well) or https://newsminimalist.com

https://lite.cnn.com seems to load 200KB of CSS

27KB of CSS for me, but only if I switch off uBO. Otherwise, there's no CSS. I think the CSS is just for the cookie popup styling.

Re: The 49MB web page

#260

Post by Gravityloss »

PunchyHamster wrote: post #20

Our developers managed to run around 750MB per website open once. They have put in ticket with ops that the server is slow and could we look at it. So we looked. Every single video on a page with long video list pre-loaded a part of it. The single reason the site didn't ran like shit for them is coz office had direct fiber to out datacenter few blocks away. We really shouldn't allow web developers more than 128kbit o…

Should also give designers periodically small displays with low maximum contrast, and have them actually try to achieve everyday tasks with the UX they have designed.
Post reply on HN