Live data from Hacker News

The 49MB web page

thatshubham.com

151–160 of 389 posts

Re: The 49MB web page

#151

Earlier quoted context omitted.

I'm pretty damn sure those videos were put on the page because someone in marketing wanted them. I'm pretty sure then QA complained the videos loaded too slowly, so the preloading was added. Then, the upper management responsible for the mess shrugged their shoulders and let it ship. You're not insightful for noticing a website is dog slow or that there is a ton of data being served (almost none of which is actually…

this isn't purely laundering blame. it is frustrating for the infrastructure/operations side is that the dev teams routinely kick the can down to them instead of documenting the performance/reliability weak points. in this case, when someone complains about the performance of the site, both dev and qa should have documented artifacts that explain this potential. as an infrastructure and reliability person, i am happy…

Yes, but can you blame someone for trying when all the gas stations are 1000 miles away? That's the exact situation the devs are put in all the time.

Oh, and the rest of the business doesn't even know what a car or gasoline are!

Re: The 49MB web page

#152
post #91

Earlier quoted context omitted.

Why don't you tell your boss or team something like that and see how well that flies. The responsibility of the devs is to deliver what was asked. They can and probably do make notes of the results. So does QA. So do the other stakeholders. On their respective teams they get the same BS from everyone who isn't pleased with the outcome. Ultimately things are on a deadline and the devs must meet requirements where the…

> The responsibility of the devs is to deliver what was asked. Software development isn't factory work. And factory workers are expected to notice problems and escalate them. Anyway, they're paying me far too much to have me turn off my brain and just check the boxes they want checked in all situations. Sometimes, checking boxes because they need to be checked is the thing to do, but usually it's not.

> Software development isn't factory work

We're definitely way past the point where there is a singular definition of what "software development" is supposed to mean.

I also didn't describe anything like factory work.

Re: The 49MB web page

#153
Not only are loading times and total network usage ridiculous, sites will continue to violate your privacy via trackers and waste your CPU even when background idling. I've written about these issues a few times in the last few years, so just sharing for those interested:

A comparison of CPU usage for idling popular webpages: https://ericra.com/writing/site_cpu.html

Regarding tracker domains on the New Yorker site: https://ericra.com/writing/tracker_new_yorker.html

Re: The 49MB web page

#154

I just loaded the nytimes.com page as an experiment. The volume of tracking pixels and other ad non-sense is truly horrifying. But at least in terms of the headline metric of bandwidth, it's somewhat less horrifying. With my ad-blocker off, Firefox showed 44.47mb transferred. Of that 36.30mb was mp4 videos. These videos were journalistic in nature (they were not ads). So, yes in general, this is like the Hindenburg o…

Why are we supposed to think it's normal to see videos on every page? Even where it's directly relevant to the current page, what's the justification in thrusting those 36.30mb on the user before they explicitly click play?

I don’t think you are supposed to think anything.

It’s a news site with a lot of auto-playing video. If you like that kind of content, great. If not, there’s lots of other websites with different mixes of content. I subscribe to the economist which has few videos and they never auto play.

But that’s a question of taste. 5mb of JavaScript and hundreds of tracking assets is not.

Re: The 49MB web page

#155

Allowing scripting on websites (in the mid-90s) was a completely wrong decision. And an outrage. Programs are downloaded to my computer and executed without me being able to review them first—or rely on audits by people I trust. That’s completely unacceptable; it’s fundamentally flawed. Of course, you disable scripts on websites. But there are sites that are so broken that they no longer work properly, since the deve…

> Programs are downloaded to my computer and executed without me being able to review them first—or rely on audits by people I trust

Would've been cool if we could know if site X served the same JS as before. Like a system (maybe even decentralized) where people could upload hashes of the JS files for a site. Someone could even review them and post their opinions. But mainly you'll know you're getting the same JS as before - that the site hasn't been hacked or that you're not being targeted personally. If a file needs to update, the site could say in the changelog something like "updated the JS file used for collapsing comments to fix a bug". This could be pushed by the users to the system.

Especially important for banking sites and webmail.

Re: The 49MB web page

#156

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…

> We'll simply cut the headlines from the offending website and past it into a search engine and find another site with the same or similar info but with easier access.

Where do you trust to read the news? Any newsrooms well staffed enough to verify stories (and not just reprint hearsay) seem to have the same issues.

Re: The 49MB web page

#157

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…

> We really shouldn't allow web developers more than 128kbit Marketing dept. too. They're the primary culprits in all the tracking scripts.

often we're told to add Google XSS-as-a-serv.. I mean Tag Manager, then the non-tech people in Marketing go ham without a care in the world beyond their metrics. Can't blame them, it's what they're measured on.

Marketing and managers should be restricted as well, because managers set the priorities.

Re: The 49MB web page

#158

Earlier quoted context omitted.

Do you have a suggestion how else to handle the situation I described?

There’s a magic word that can be used in scenarios like this: “No.” Failing that, interpret the requirements. Nobody can watch a bunch of videos at once that don’t even show up until you scroll! That’s a nonsense requirement and the dev’s failure to push back or redirect in a more viable direction is a sign of their incompetence, not that of the non-technical manager that saw YouTube’s interface and assumes that that…

> You’d have to know about lazy loading and CDNs, but neither is black magic.

I suppose you've never experienced the corporate hell that can happen with a CDN. The dev could submit a dozen servicenow tickets only to see half of them rejected by those same incompetent non-technical managers, or they could just make the thing work now and move on.

The next project will be better after the dust settles and those rejections have been reviewed and escalated into proper discussions. Nobody tells the story of that project because it does the things everyone expects. Guess who led those discussions and fought to get the meetings on the calendar? The "incompetent" devs of course!

Re: The 49MB web page

#159

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…

I'm pretty damn sure those videos were put on the page because someone in marketing wanted them. I'm pretty sure then QA complained the videos loaded too slowly, so the preloading was added. Then, the upper management responsible for the mess shrugged their shoulders and let it ship. You're not insightful for noticing a website is dog slow or that there is a ton of data being served (almost none of which is actually…

Fuck that. I just left a job where the IT dept just said "yes and" to the executives for 30 years. It was the most fucked environment I've ever seen, and that's saying a lot coming from the MSP space. Professionals get hired to do these things so they can say "No, that's a terrible idea" when people with no knowledge of the domain make requests. Your attitude is super toxic.

Re: The 49MB web page

#160
post #48

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…

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

Love both of them. CNN has become a bit "left-leaning Fox News" for my taste, though.

If Al Jazeera or BBC had a similar text only site, that would be best. I really love the different perspectives.

I mostly use brutalist.report to find the articles, then deal with them on a case by case basis.

Post reply on HN