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

51–60 of 389 posts

Re: The 49MB web page

#51

Post by Joel_Mckay »

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.

Based on the damage rate for company laptop screens, one can usually be sure anything high-end will be out of your own pocket. =3

Re: The 49MB web page

#52

Post by curtisblaine »

CalRobert wrote: post #21
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…

Do you think youtube will continue to make it possible to use alternate clients, or eventually go the way of e.g. Netflix with DRM so you're forced to use their client and watch ads?

Big tech will slowly enforce "secure browsing" and "secure OS" in a way that will make it impossible to browse the web without a signed executable approved by them. DRM is just a temporary stopgap.

Re: The 49MB web page

#53

Post by ngruhn »

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…

> Don't get me started on airlines websites

You can't beat China Southern . They have the most dog shit website I've ever seen. The flight was fine but I gave up doing online check in after 3 attempts. Never mind the bloat:

- required text fields with wrong or missing labels. One field was labeled "ticket no.". It kept getting rejected. I randomly tried passport number instead. It worked.

- sometimes fields only have a placeholder that you can't fully read because the field has not enough width ("Please enter the correct...") and the placeholder disappears once you start typing.

- date picker is randomly in Chinese

- makes you go through multi step seat selection process only to tell you at the end that seat selection is not possible anymore.

- signed up with email; logged out and went back to the SAME login page; now sign up via phone number is required!?

Re: The 49MB web page

#54

Post by sublinear »

hobs wrote: post #46
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…

From the perspective of the devs, they have a responsibility for saying something literally wont fly anywhere, ever, saying the business is responsible for every bad decision is a complete abrogation of your responsibilities.

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 priority is not performance. It says nothing about their ability to write performant code. It says nothing about whether that performant code is even possible in a browser while meeting the approval of the dozens of people with their own agendas. It says everything about where you work.

Re: The 49MB web page

#55

Post by curtisblaine »

Bratmon wrote: post #2

Maybe I'm just getting old, but I've gotten tired of these "Journalists shouldn't try to make their living by finding profitable ads, they should just put in ads that look pretty but pay almost nothing and supplement their income by working at McDonalds" takes.

> Journalists shouldn't try to make their living by finding profitable ads

I mean, they can absolutely try. That doesn't mean they should succeed.

Re: The 49MB web page

#56

Post by lousken »

rule #1 is to always give your js devs only core 2 quad cpus + 16GB of RAM

they won't be able to complain about low memory but their experience will be terrible every time they try to shove something horrible into the codebase

Re: The 49MB web page

#57

Post by zahlman »

hilbert42 wrote: post #35
alpinisme wrote: post #22

Earlier quoted context omitted.

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.

If you have enough detail for a blog post I'd heartily encourage you to submit it.

Re: The 49MB web page

#58

Post by userbinator »

I also use and like the comparison in units of Windows 95 installs (~40MB), which is also rather ironic in that Win95 was widely considered bloated when it was released.

While this article focuses on ads, it's worth noting that sites have had ads for a long time, but it's their obnoxiousness and resource usage that's increased wildly over time. I wouldn't mind small sponsored links and (non-animated!) banners, but the moment I enable JS to read an article and it results in a flurry of shit flying all over the page and trying to get my attention, I leave promptly.

Re: The 49MB web page

#59

Post by xigoi »

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…

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

Re: The 49MB web page

#60

Post by the_snooze »

It's really hard to consider any kind of web dev as "engineering." Outcomes like this show that they don't have any particular care for constraints. It's throw-spaghetti-at-the-wall YOLO programming.
Post reply on HN