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

91–100 of 171 posts

Re: Page Weight Matters (2012)

#91

Post by keithpeter »

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 ;)

As does http://www.google.co.uk/custom

Thanks very much for the tip off.

Re: Page Weight Matters (2012)

#92

Post by spion »

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…

Its a great solution! I'd use dictionaries for faster lookups though.

But not exactly pure JSON. Client-side, you need to attach methods (or getters) that fetch the user object to the comment. I suppose you could just attach get(reference) that takes this[reference + '_id'] and looks it up inside the `result[reference]`. m:n relations will be harder though.

Otherwise you can't e.g. simply pass each comment to e.g.a react "Comment" component that renders it. You would also have to pass the user list (dictionary) to it.

Re: Page Weight Matters (2012)

#93

Post by spion »

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 I agree that gzip will probably fix this single-handedly. The main cost here is very likely network transfer, so gzip will do great.

Re: Page Weight Matters (2012)

#94

Post by [deleted] »

kuschku wrote: post #88
danneu wrote: post #81

Earlier quoted context omitted.

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.

[deleted]

Re: Page Weight Matters (2012)

#95

Post by flippant »

lnanek2 wrote: post #39

Pretty funny story considering YouTube is back to unusable on slow connections. They used to buffer the full video, so you could load up a page, let it sit until the video buffers, then watch it eventually, maybe after reading your social news sites. Nowadays the buffering feature has been removed and you'll just come back, hit play, get a second or two of video, then it has nothing again for a long time. Feels bad f…

It's for the average user with a decent connection that skips parts of a video. This is tedious, but if you want to buffer a YouTube video try youtube-dl[0] or using VLC.

[0]https://rg3.github.io/youtube-dl/

Re: Page Weight Matters (2012)

#97

Post by MereInterest »

QuavMo wrote: post #51
RyJones wrote: post #29

Earlier quoted context omitted.

We AABN tested injecting delay into rendering the MSN home page and found a direct correlation between amount of delay and the abandon rate. People are not tolerant of delay. Here is the team I worked on: http://www.exp-platform.com/Pages/default.aspx

"people"? What people? This OP's experience seems to indicate that there is a lot of patience in "Southeast Asia, South America, Africa, and even remote regions of Siberia".

It sounded more like patience was relative to expected wait time. If you expect something to take 20 minutes, then a 2 minute wait isn't much at all. If you expect something to take 2 seconds, then a 10 second wait is quite irritating.

Re: Page Weight Matters (2012)

#98

Post by acdha »

spion wrote: post #42
elorant wrote: post #35

Earlier quoted context omitted.

The fact that there isn't a daily drumbeat about how bloated, how needlessly complex, how ridicuous most of the world's web appliactions of today really are - baffles me Well there is, or at least there used to be. The reason native apps in mobile became so popular is exactly because web sites are bloated. It might not matter in the PC but in a device running on batteries it matters a lot. The real problem of web dev…

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…

> * The DOM. Its slow and full of old cruft that takes up memory and increases execution time.

I'm not going to say that the DOM is wonderful but … have you actually measured this to be a significant problem? Almost every time I see claims that the DOM is slow a benchmark shows that the actual problem is a framework which was marketed as having so much magic performance pixie dust that the developer never actually profiled it.

Re: Page Weight Matters (2012)

#99

Post by RyJones »

MereInterest wrote: post #97
QuavMo wrote: post #51

Earlier quoted context omitted.

"people"? What people? This OP's experience seems to indicate that there is a lot of patience in "Southeast Asia, South America, Africa, and even remote regions of Siberia".

It sounded more like patience was relative to expected wait time. If you expect something to take 20 minutes, then a 2 minute wait isn't much at all. If you expect something to take 2 seconds, then a 10 second wait is quite irritating.

I'm certain you're right but we need to test that :)

the way I read OP was the abandon rate was ~100% previously in areas with high latency/low bandwidth, and his experiment had a non-zero abandon rate that was shrinking as word spread. Perhaps I need to read it more carefully.

Re: Page Weight Matters (2012)

#100

Post by csense »

The more things change, the more they stay the same.

I remember visiting microprose.com with my 14.4k modem in the mid-90s and being mad that they used so many images I had to wait for about 5-10 minutes or so. I couldn't effectively read it at home and usually ended up reading it at the library.

Post reply on HN