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

161–170 of 389 posts

Re: The 49MB web page

#161

Post by sublinear »

tempaccount5050 wrote: post #159
sublinear wrote: post #33

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…

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.

I suppose the realities of teamwork can be seen as "toxic" by some individuals.

Re: The 49MB web page

#162

Post by jiggawatts »

FridgeSeal wrote: post #132
coin wrote: post #111

Earlier quoted context omitted.

Stepping back, it's pretty ridiculous that I need to download executable code, often bloated, solely to view read-only content. Just render the thing on the backend and send it to the client.

But the web-dev-hype people told me that JS-heavy SPA’s (and associated designs) were faster and better for the user! I didn’t bother validating this, but I’m sure they wouldn’t lie or misinterpret!!

For me personally the most infuriating example of this is the Azure Updates[1] page, which in my job I need to check nearly daily to see what's reaching EoL, what's new, etc...

A couple of years ago they redeveloped it as a SPA app.

The original server-rendered version of it worked just fine, but it "had" to be made into an interactive client-side monstrosity that loads many times slower for "reasons".

It doesn't even load successfully about a quarter of the time. It shows items in reverse order (entries from 2013 first), which is some sort of async loading bug. They will never fix this. It's been there for two years already, it'll be there for a decade more, mark my words.

Then, it takes about a minute to load sometimes on a poor connection.

The links are JavaScript and don't allow "open in new tab".

Etc...

All of this to enable client-side filtering, which is a non-feature nobody ever wanted. A simple server-side filter capability would do the same thing, faster.

And anyway, the filtering is broken! If click the "New or updated" filter, it drops down an empty selection with no options. Clicking anything else doesn't change what is shown!

While developing this over-engineered monstrosity, they took the original site offline for "maintenance!"

Hilariously, despite Azure having multiple CDN products, the Azure Updates page doesn't correctly use their own CDN and marks almost everything as "no-cache; no-store" causing 2.5 MB (after compression) to be re-transferred every time, despite using unique signed URLs with SHA256 hashes in them!

This is the state of web-dev in the 2020s: A multi-trillion-dollar software company can't hire developers that know anything else other than SPA web app development!

This commonly used page has spectacularly poor web engineering, and this is from a company that sells a web app platform, a CDN, and the ASP.NET web app development framework!

If they can't get it right, who can!?

[1] https://azure.microsoft.com/en-au/updates/

Re: The 49MB web page

#163

Post by ajxs »

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…

Something about these JS-heavy sites I haven't seen discussed: They don't archive well.

Websites that load a big JS bundle, then use that to fetch the actual page content don't get archived properly by The Wayback Machine. That might not be a problem for corporate content, but lots of interesting content has already been lost to time because of this.

Re: The 49MB web page

#164

Post by psim1 »

Joel_Mckay wrote: post #34
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…

If you want to see context aware pre-fetching done right go to mcmaster.com ... There are good reasons to have a small cheap development staging server, as the rate-limited connection implicitly trains people what not to include. =3

And this! https://www.mcmaster.com/help/api/ Linked from the footer of every page!

I'm so happy to have seen their web site that I want to do business with them, even though I have no business to be done.

Re: The 49MB web page

#165

Post by maxloh »

snickerer wrote: post #107

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.

JavaScript and WebAssembly programs are always executed in a sandboxed VM, without read access to the host OS files (unless, of course, you grant it).

Enabling scripting was a necessary step for interactive websites. Without it, a full page load would be required every time you upvote a Hacker News comment. In my opinion, the real problem is that browsers allow too many connections to third-party domains, which are mostly ads and trackers. Those should require user-approved permissions instead of being the default.

Re: The 49MB web page

#166

Post by bsjshshsb »

Bratmon wrote: post #100
pocksuppet wrote: post #97

Earlier quoted context omitted.

48MB

Which MB should they cut out? Bear in mind that any cut that reduces their CPM or rate of conversation to paid will have to also include an equivalent reduction in their staff.

Maybe the old "speed the page up and fewer people will bounce" adage applies?

Re: The 49MB web page

#167

Post by Joel_Mckay »

psim1 wrote: post #164
Joel_Mckay wrote: post #34

Earlier quoted context omitted.

If you want to see context aware pre-fetching done right go to mcmaster.com ... There are good reasons to have a small cheap development staging server, as the rate-limited connection implicitly trains people what not to include. =3

And this! https://www.mcmaster.com/help/api/ Linked from the footer of every page! I'm so happy to have seen their web site that I want to do business with them, even though I have no business to be done.

Some CAD/CAM applications directly integrate a component toolbox. =3

Re: The 49MB web page

#168

Post by 6510 »

KronisLV wrote: post #86
vunderba wrote: post #80

Earlier quoted context omitted.

PSA for those who aren’t aware: Chromium/Firefox-based browsers have a Network tab in the developer tools where you can dial down your bandwidth to simulate a slower 3G or 4G connection. Combined with CPU throttling, it's a decent sanity check to see how well your site will perform on more modest setups.

I once spent around an hour optimizing a feature because it felt slow - turns out that the slower simulated connection had just stayed enabled after a restart (can’t remember if it was just the browser or the OS, but I previously needed it and then later just forgot to turn it off). Good times, useful feature though!

I wonder if that works beneficial on old computers that freeze up when you try load the GB js ad-auction circus news circus website. I want to browse loaded pages while the new tabs load. If the client just hangs for 2 min it gets boring fast.

Re: The 49MB web page

#169

Post by ksec »

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

So they could do exactly what they are doing on the web and may be even more but with Native code so it feels much faster.

I got to the point and wonder why cant all the tracking companies and ad network just all share and use the same library.

But on Web page bloat. Let's not forget Apps are insanely large as well. 300 - 700MB for Banking, Traveling or other Shopping App. Even if you cut 100MB on L10n they are still large just because of again tracking and other things.

Re: The 49MB web page

#170

Post by socalgal2 »

Yes, it's 100% horrible. For me the solution is simple. If I click a link and the page is covered in ads and popup videos I CLOSE THE PAGE!!!!

Vote with your behavoir. Stop going to these sites!

Post reply on HN