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

31–40 of 389 posts

Re: The 49MB web page

#31

Post by ceejayoz »

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…

Same for fancy computers. Dev on a fast one if you like, but test things out on a Chromebook.

Re: The 49MB web page

#32

Post by niccl »

galphanet wrote: post #19

This is just the top of the iceberg. Don't get me started on airlines websites (looking at you Air Canada), where the product owner, designers, developers are not able to get a simple workflow straight without loading Mb of useless javascript and interrupt the user journey multiple times. Give me back the command line terminal like Amadeus, that would be perfect. How can we go back to a Web where websites are designe…

Sadly, I think the only answer is some other form of payment than ad clicks. I've no idea what that could be, though.

Re: The 49MB web page

#33

Post by sublinear »

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…

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 the code). 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.

From the perspective of the devs, they expect that the infrastructure can handle what the business wanted. If you have a problem you really should punch up, not down.

Re: The 49MB web page

#34

Post by Joel_Mckay »

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

Re: The 49MB web page

#35

Post by hilbert42 »

alpinisme wrote: post #22
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…

What does playing fair mean in this context? It would be one thing if you were a paid subscriber complaining that even paying sucks so you left, but it sounds like you’re not.

I'd like to answer that in detail but it's impractical to do so here as it'd take pages. As a starter though begin with them not violating users' privacy.

Another quick point: my observation is that the worse the ad problem the lower quality the content is. Cory Doctorow's "enshitification" encapsulates the problems in a nutshell.

Re: The 49MB web page

#37

Post by mananaysiempre »

ceejayoz wrote: post #31
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…

Same for fancy computers. Dev on a fast one if you like, but test things out on a Chromebook.

“Craptop duty”[1]. (Third time in three years I’m posting an essentially identical comment, hah.)

[1] https://css-tricks.com/test-your-product-on-a-crappy-laptop/

Re: The 49MB web page

#38

Post by zahlman »

This site more or less practices what it preaches. `newsbanner.webp` is 87.1KB (downloaded and saved; the Network tab in Firefox may report a few times that and I don't know why); the total image size is less than a meg and then there's just 65.6KB of HTML and 15.5 of CSS.

And it works without JavaScript... but there does appear to be some tracking stuff. A deferred call out to Cloudflare, a hit counter I think? and some inline stuff at the bottom that defers some local CDN thing the old-fashioned way. Noscript catches all of this and I didn't feel like allowing it in order to weigh it.

Re: The 49MB web page

#39

Post by arccy »

sublinear wrote: post #33
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…

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…

Sounds just like a "helpless" dev that shifts blame to anyone but themselves.

Re: The 49MB web page

#40

Post by curtisblaine »

alpinisme wrote: post #22
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…

What does playing fair mean in this context? It would be one thing if you were a paid subscriber complaining that even paying sucks so you left, but it sounds like you’re not.

You're right, it means nothing. But it cuts two ways. These sites are sending me bytes and I choose which bytes I visualize (via an ad blocker). Any expectation the website has about how I consume the content has no meaning and it's entirely their problem.
Post reply on HN