Live data from Hacker News

The 49MB web page

thatshubham.com

291–300 of 389 posts

Re: The 49MB web page

#291
post #59

Earlier quoted context omitted.

> Please stop blaming the devs. You're laundering blame. Almost no detail of a web site or app is ever up to the devs alone. If a bridge engineer is asked to build a bridge that would collapse under its own weight, they will refuse. Why should it be different for software engineers?

It's a website and not a bridge. Based on the description given, it's not a critical website either. If it was, the requirements would have specified it must be built differently. You're not even arguing with me BTW. You're arguing against the entire premise of running a business. Priorities are not going to necessarily be what you value most.

While I assume that there are plenty of critical websites out there which are built with efficiency and resource consumption control in mind, the few I have worked on were not.

On those sites you’re right: the approach was different, but not necessarily better. Tracking library bloat and marketing-driven design were reduced. But insane “security” constraints (e.g. “you have to stay on outdated revisions of this library” or “containers are not allowed on the backend, only bare metal”, no joke—constraints that led to significant increased security risk) and extremely user-hostile design practices increased, as well as there being an exceedingly long hurry-up-and-wait turnaround time for shipping important fixes/improvements.

Working on a safety/state-critical site isn’t a panacea, in other words.

Re: The 49MB web page

#292

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!

Have the same story but I forgot to disable tc netem on a server, luckily it was just staging.

Re: The 49MB web page

#293
> The user must perform visual triage, identify the close icons (which are deliberately given low contrast) and execute side quests just to access the 5KB of text they came for.

They thing is, though... they _don't_ have to. It's been my standard practice for years to just tap ctrl-w the moment any web page pops up a model box. Some leeway is given to cookie dialogs _if_ they have a disagree/disable button _prominently_ visible, otherwise they're ctrl-w'd too.

"Newsletter..." ctrl-w.

"Please disable your..." ctrl-w.

"Subscribe to read..." ctr-w.

Ctrl-w is your friend.

Re: The 49MB web page

#294

> 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…

I tried to fight against the introduction of GTM in a project I worked on; we spent a lot of effort on coding, reviewing, testing, optimizing and minimizing client-side code before our end-users would see it, and the analytics people want a shortcut to inject any JS anywhere? I didn't win that one, but I did make sure that it would only load after the user agreed to tracking cookies and the like.

Yeah, it’s really hard to compete with a solution that takes engineers out of the loop. The biggest reason large orgs go so crazy with GTM is that it’s a shadow deployment pipeline that doesn’t require waiting for engineers to work a request, or QA, or a standard release process.

And sure, better prioritization and cooperation with eng can make the “real” release processes work better for non-eng stakeholders, but “better” is never going to reach the level of “full autonomy to paste code to deploy via tag manager”.

This is the same reason why many big apps have a ton of Wordpress-managed pages thougout the product (not just marketing pages); often, that’s because the ownership and release process for the WP components is “edit a web UI” rather than “use git and run tests and have a test plan and schedule a PR into a release”.

Re: The 49MB web page

#295

Earlier quoted context omitted.

> 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 pages without JavaScript. No. "savvy" web surfers are a rounding error in global audience terms. Vast majorities of web users, whether paying subscribers to a site like NYT or not, have no idea w…

"…but no one at the NYT is losing any sleep over people like us." Likely not, but they are over their lost revenues. The profitability of newspapers and magazines has been slashed to ribbons over the past couple of decades and internet revenues hardly nudge the graphs. Internet beneficiaries are all new players, Google et al.

Sure, but GP’s still right: savvy internet users are a rounding error in volume … and thus revenue as well. So whatever forces are enshittifying news websites, they’ll not reconsider because power users complain.

Re: The 49MB web page

#296
post #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.

The AP and Reuters are well-staffed and have functional websites. The sites aren’t great (they’ve been afflicted with bloat and advertising along with most outlets, just at a marginally lower rate), but they are at least usable.

Re: The 49MB web page

#297

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…

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.

It doesn't throttle Websockets, so be careful with that

Re: The 49MB web page

#298
post #242

> users are greeted by what I call Z-Index Warfare Nice term! > Or better yet, inject the newsletter signup as a styled, non-intrusive div between paragraphs 4 and 5. If the user has scrolled that far, they are engaged. They're engaged with the content ! There is no way to make some irrelevant signup "non-intrusive". It's similar to links to unrelated articles - do you want users to actually read the article or jump…

Z-index warfare is so stupid (the practice, not the name). It's not only with media publications, but ecommerce sites as well.

There have been countless businesses that have lost out on my money because I clicked on their ad (good job!), start reading the product info on their website as it loads (that's basically a sale), and then the page finished loading with a barrage of popups for cookie consent, newsletter signup for a discount code, special offers, special sale, spin the wheel for a prize, etc. That's when I close the tab and forget about it.

Re: The 49MB web page

#299

I started on this when project when I was at The New Yorker. I had just manage to convince people to give us space to do web performance optimization - and then we had to drop it quickly to work on AMP. Very frustrating. This site was created to give developers and pms some ammunition to work on improving load speed https://webperf.xyz/

The leader https://nautil.us on your board is incredibly fast!
Post reply on HN