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

Page Weight Matters (2012)

blog.chriszacharias.com

Post reply on HN
Print view View original

81–90 of 171 posts

Re: Page Weight Matters (2012)

#81

Post by danneu »

kuschku wrote: post #68
spion wrote: post #42

Earlier quoted context omitted.

JavaScript isn't the problem, but it seems to always take the blame. And its not even slow. Here are a couple of real culprits: * Advertising / analytics / social sharing companies. They deliver a boatload of code that does very little for the end-user. * REST and HTTP 1 in combination. A page needs many different types of data. REST makes us send multiple requests for different kinds of data, often resulting with th…

> Want to download all the comments with the user info for every user? You have a choice between repeating the user info per comment, requesting the comments first then the users by id (two requests) or using a serialisation mechanism that supports object references (isn't pure JSON) Or you send it like { "users": [ { "id": "de305d54-75b4-431b-adb2-eb6b9e546014", "name": "Max Mustermann", "image": "https://news.ycomb…

Alternatively, I would think that gzip does a good job of factoring out repeatedly embedded user objects.

Re: Page Weight Matters (2012)

#82

Post by BostonEnginerd »

jfoutz wrote: post #40
jonahx wrote: post #6

This is a fascinating example of Simpson's Paradox: https://en.wikipedia.org/wiki/Simpson%27s_paradox It also reminds me of the phenomenon, in customer service, whereby an increase in complaints can sometimes indicate success -- it means the product has gone from bad enough to be unnoticeable to good enough to be engaged with.

In WW1, helmets were introduced to protect soldiers. Surprisingly the frequency of head wounds went way up. It took a little while to realize soldiers were "just" being wounded, rather than outright killed if they had no helmet.

There's a similar story about putting armor on planes during WWII - http://www.johndcook.com/blog/2008/01/21/selection-bias-and-...

Re: Page Weight Matters (2012)

#83

Post by dimal »

phamilton wrote: post #44
spion wrote: post #42

Earlier quoted context omitted.

JavaScript isn't the problem, but it seems to always take the blame. And its not even slow. Here are a couple of real culprits: * Advertising / analytics / social sharing companies. They deliver a boatload of code that does very little for the end-user. * REST and HTTP 1 in combination. A page needs many different types of data. REST makes us send multiple requests for different kinds of data, often resulting with th…

> * Advertising / analytics companies. They deliver a boatload of code that does very little for the end-user. That's not quite fair. They subsidize the content for the end-user. Perhaps that's a crappy status quo, but in many cases without the advertising and analytics the content wouldn't exist in the first place.

If it degrades the user experience so much that the page is unusable, it's not serving the intended purpose. Users will block the ads or not bother waiting for the page to load. Some ads/buttons/analytics code is worth it, but most content sites don't seem to think about the tradeoffs at all.

Re: Page Weight Matters (2012)

#84

Post by tedunangst »

geocar wrote: post #78
spion wrote: post #49

Earlier quoted context omitted.

Perhaps. But maybe, if you add googleads, amazon adsystem, moatads, rubicon project, taboola, scorecardresearch, krdx etc [1], then you start wondering why are users using adblockers, so you add pagefair, and at that point you want to find out what works better so you add optimizely... maybe, just maybe, at that point, you're actually losing money because your page is so damn slow, rather than getting more because of…

I remember when I was young, Television was sponsored by Advertisers: One of my favourite shows, was made possible because of Advertisers. To bemoan Advertisers in my mind is to say that part of my childhood should never have existed, so I think greater, more focused criticism is required. Do you ever wonder why the landscape became the way it did?

If a TV show were five minutes of content, and 55 minutes of advertising, I would stop watching it. And yet, that's the approximate breakdown for many websites between content and advertising. And they wonder why readers complain.

Re: Page Weight Matters (2012)

#85

Post by jjzieve »

For some reason this whole problem reminds me of early game developers dealing with small amounts of RAM. Which clearly isn't a problem today. So would it be fair to say we should focus on increasing bandwidth to most of the world. I'm not saying page weight doesn't matter, but if you're just trying to get something off the ground maybe you shouldn't worry about it so much. I mean, why worry about users with poor bandwidth, if you don't even have users? If you already have a growing user base, then by all means refactor, reduce the footprint. But if you don't, code the damn bloated thing first.

Re: Page Weight Matters (2012)

#86

Post by smackfu »

kuschku wrote: post #65
nostrademons wrote: post #56

When I joined Google in 2009, we were on the tail-end of a latency optimization kick that Larry had started in 2007. At the time, we had a budget of 20K gzipped for the entire search results page. I remember working on the visual redesign of 2010, where we had increased the page weight from 16K to 19K and there was much handwringing at the higher levels about how we were going to blow our entire latency budget on one…

Remember, http://google.com/custom still loads instantly ;)

Funny that they didn't even update the Google logo on that page.

Re: Page Weight Matters (2012)

#87

Post by geocar »

tedunangst wrote: post #84
geocar wrote: post #78

Earlier quoted context omitted.

I remember when I was young, Television was sponsored by Advertisers: One of my favourite shows, was made possible because of Advertisers. To bemoan Advertisers in my mind is to say that part of my childhood should never have existed, so I think greater, more focused criticism is required. Do you ever wonder why the landscape became the way it did?

If a TV show were five minutes of content, and 55 minutes of advertising, I would stop watching it. And yet, that's the approximate breakdown for many websites between content and advertising. And they wonder why readers complain.

They know why readers complain. They wish you understood their perspective better.

A significant problem is that content costs a certain amount of money to be produced, and web content is unable to command those prices.

Ad fraud is a big part of it, and some of the companies in the best position to solve it (like Google) are benefitting so handsomely from ad fraud that I can't imagine them stopping it.

Ad blockers will hurt legitimate content producers, but because people defrauding advertisers don't use ad blockers, they'll continue to make money.

Re: Page Weight Matters (2012)

#88

Post by kuschku »

danneu wrote: post #81
kuschku wrote: post #68

Earlier quoted context omitted.

> Want to download all the comments with the user info for every user? You have a choice between repeating the user info per comment, requesting the comments first then the users by id (two requests) or using a serialisation mechanism that supports object references (isn't pure JSON) Or you send it like { "users": [ { "id": "de305d54-75b4-431b-adb2-eb6b9e546014", "name": "Max Mustermann", "image": "https://news.ycomb…

Alternatively, I would think that gzip does a good job of factoring out repeatedly embedded user objects.

yes, obviously – gzip even does that explicitly, replacing repeated text with references.

But it still takes more power for your server to go through gzip every time. And it will take more RAM on the client to store those objects.

Re: Page Weight Matters (2012)

#89

Post by nubs »

kuschku wrote: post #68
spion wrote: post #42

Earlier quoted context omitted.

JavaScript isn't the problem, but it seems to always take the blame. And its not even slow. Here are a couple of real culprits: * Advertising / analytics / social sharing companies. They deliver a boatload of code that does very little for the end-user. * REST and HTTP 1 in combination. A page needs many different types of data. REST makes us send multiple requests for different kinds of data, often resulting with th…

> Want to download all the comments with the user info for every user? You have a choice between repeating the user info per comment, requesting the comments first then the users by id (two requests) or using a serialisation mechanism that supports object references (isn't pure JSON) Or you send it like { "users": [ { "id": "de305d54-75b4-431b-adb2-eb6b9e546014", "name": "Max Mustermann", "image": "https://news.ycomb…

Something similar has been standardized as well with the JSON API specification (although it adds its own weight to the message as well, it does address this problem): http://jsonapi.org/format/#document-compound-documents

Re: Page Weight Matters (2012)

#90

Post by pswilson14 »

scrollaway wrote: post #25
gketuma wrote: post #5

As a web dev I always have this in mind but the challenge is convincing your client who wants a video background. Maybe we need a media query that detects internet speed.

Even then, it's fairly easy to load the video asynchronously and as part of the last assets, make its intro blend in to a single-color background, voila, problem "solved". I find video backgrounds ridiculous most of the time (though they can be done really well), but that's not the real problem here - the real problem is including 200-800kb javascript code that does nothing but track your user, and often enough doesn…

"Massive" JS frameworks aren't the issue, not by themselves. AngularJS, for instance, is only 39.5kb. Bloat sneaks into web applications in other ways, but merely bringing in a framework isn't enough to add a noticeable load on a web page.
Post reply on HN