Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Website Obesity Crisis (2015)

idlewords.com

Post reply on HN
Print view View original

81–88 of 88 posts

Re: The Website Obesity Crisis (2015)

#81

Post by flukus »

cableshaft wrote: post #61
flukus wrote: post #50

Earlier quoted context omitted.

Craigslist is great design. I'll take that over what "UX experts" come up with any day.

Craigslist seems overwhelming and like bad design when you first encounter it, but start using it for awhile and being able to go exactly where you need to go with one click and know exactly where on the page it will be located, without scrolling, and have your mouse ready to click it, is actually really nice.

Even better is you can bookmark what you want, no navigating through an animated SPA.

Re: The Website Obesity Crisis (2015)

#83

Post by exelius »

oliwarner wrote: post #55
exelius wrote: post #23

Earlier quoted context omitted.

It was never about the code. It was always about the products.

"Never" isn't accurate though. If you step away from vapid content sites for a minute, to a place where real money and products are exchanged, there are strong cases for load time affecting the likelihood of purchase or cart abandonment, or whether they'll resubscribe to your SaaS. It does largely depends on how much the user thinks they specifically need you but if it's between your flabby website, taking seconds to…

Everything you mention is something that is the concern of a product manager, not an engineering lead. It becomes the engineering lead's problem when the product manager tells them it is. A huge problem at a lot of companies is when engineering teams go "off script" and build solutions for problems that nobody has. Is it an accident that Google's "10% policy" has largely evaporated as pressures on efficiency and productivity have come in from Wall Street?

Also speed on the type of sites you mention is a solved problem. CMSes these days have an option to generate static content and push it to a CDN. Is it free? Nope. But it's a problem with a solution.

Re: The Website Obesity Crisis (2015)

#84

Post by jplayer01 »

charles-salvia wrote: post #43

Ads are definitely a huge problem, but it seems they are at least equally, perhaps even less of a contributor to bloat than the tons of off-the-shelf Javascript frameworks/libraries major websites throw in to perform analytics, or to implement stock features like user-comments, login, social-media stuff, etc. I mean, just looking at the network resources for a fresh download of www.cnn.com, I see: livefyre_base.js, 1…

Been running with uMatrix for a few weeks now and it's crazy how much gets loaded on every website that isn't necessary for the actual page's functioning. Websites finally feel snappy again - it's the best extension I've ever used.

Re: The Website Obesity Crisis (2015)

#85

Post by jplayer01 »

Terr_ wrote: post #5

My strategy has been to disable all javascript by default, and whitelist specific sites. So far I'm pleased with the result, especially how fast most of the random HN/Reddit links load.

I've started using uMatrix, it makes such a huge difference in performance and usability.

Re: The Website Obesity Crisis (2015)

#86

Post by oliwarner »

exelius wrote: post #83
oliwarner wrote: post #55

Earlier quoted context omitted.

"Never" isn't accurate though. If you step away from vapid content sites for a minute, to a place where real money and products are exchanged, there are strong cases for load time affecting the likelihood of purchase or cart abandonment, or whether they'll resubscribe to your SaaS. It does largely depends on how much the user thinks they specifically need you but if it's between your flabby website, taking seconds to…

Everything you mention is something that is the concern of a product manager, not an engineering lead. It becomes the engineering lead's problem when the product manager tells them it is. A huge problem at a lot of companies is when engineering teams go "off script" and build solutions for problems that nobody has. Is it an accident that Google's "10% policy" has largely evaporated as pressures on efficiency and prod…

I don't think I could disagree more with your post.

Every developer you have should be capable of weighing up performance ramifications of their decisions, and be able to discuss and justify them. Not saying that every line needs explaining but come on... Not their concern? I'm all for getting stuff done but doing a crappy job the first time more than doubles the TTL.

Moreover, telling your developers to ignore this stuff means it becomes a lost skill. When you do need them to double-back and profile and bisect everything back to 0AD, they'll be much less capable than a performance-conscientious developer.

I don't disagree that over-optimisation is a thing, but a hands-off approach is far more toxic. Big ticket optimisation rewrites should not be something a single developer takes on without their lead signing off. Letting developers do that is a management issue.

And "the type of sites I mention[ed]"? I think you misread my post because I was very explicitly talking about e-commerce and webapps. Not CMSes and not usually something you can run entirely static from a CDN.

And just because it's static and/or on a CDN doesn't mean it's not bloated to hell and back; that's really the point TFA is making.

Re: The Website Obesity Crisis (2015)

#87

Post by johansch »

pavement wrote: post #65
mwfj wrote: post #15

I first realized Javascript/Frontend/client developers were a danger to society about 10 years ago. We were trying to figure out why some particular, quite globally popular web site did not work when transcoded in our Opera Mini transcoder. The page itself looked perfectly static, no fancy effects or anything. Turns out the site had decided to re-implement the "click a link" feature entirely in javascript, down to th…

What you've described is basically a heat map data collection script, or part of one. The script will capture the (x,y) coordinates and cache a running log of where events occurred. It's proxying the events and then forwarding them, so it can get inbetween the event and the outcome, and record the event's details with greater precision. Since JavaScript events are asynchronous, one part of the heatmap recorder may ha…

Hi,

thanks for the description. I'm pretty sure that what we witnessed at that time wasn't something like this though. We spent quite some time picking apart the javascript.

Re: The Website Obesity Crisis (2015)

#88

Post by tinus_hn »

This is part of a larger phenomenon in IT where resources are plentiful so they are wasted. A small part of it is due to high resolution displays which cause an increase in the size of required bitmaps and some of it comes with 64 bit computing, but a lot of it is due to a general lack of care.

Perhaps the browser needs to implement a limit so a page just can't use an infinite amount of memory, CPU time and bandwidth. Or perhaps we should decide that 10 pieces of javascript is enough and any attempts to load more will just fail. The web designers will complain but they'll manage.

Post reply on HN