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

101–110 of 171 posts

Re: Page Weight Matters (2012)

#101

Post by booohooo »

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…

> All HTML tags that could be left unterminated were,

Thanks for making the internet worse so you could make your precious little webpage fast to load.

Re: Page Weight Matters (2012)

#102

Post by kuschku »

spion wrote: post #92
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…

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 r…

Well, you could process the JSON on client side.

    response.comments.forEach(comment =>  comment.author = response.user[comment.author]);
Preferably, even, you could do it during rendering so it can be garbage collected afterwards.

Re: Page Weight Matters (2012)

#103

Post by shurcooL »

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…

> CSS classnames were manually named with 1-3 character abbreviations, with a dictionary elsewhere, to save on bytesize.

Not to take away from your effort, but that sounds like something a minifier should be able to do, right?

Edit: Yep, you said it below:

> A lot of these convolutions should've been done by compiler, and indeed, a lot were moved to one when we got an HTML-aware templating language.

Re: Page Weight Matters (2012)

#104

Post by spenczar5 »

booohooo wrote: post #101
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…

> All HTML tags that could be left unterminated were, Thanks for making the internet worse so you could make your precious little webpage fast to load.

The reason we make web pages is so they can be accessed, not so they fit some dubious image of technical purity. What they did seems fine to me.

Re: Page Weight Matters (2012)

#105

Post by nostrademons »

shurcooL wrote: post #103
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…

> CSS classnames were manually named with 1-3 character abbreviations, with a dictionary elsewhere, to save on bytesize. Not to take away from your effort, but that sounds like something a minifier should be able to do, right? Edit: Yep, you said it below: > A lot of these convolutions should've been done by compiler, and indeed, a lot were moved to one when we got an HTML-aware templating language.

Yeah. The issue was that there were two other constraints that had to be satisfied at the same time: CPU time to render the page couldn't go up appreciably (or we'd run out of machines), and there was a lot of legacy HTML and JS to update. Google actually had a CSS compiler at the time (since open-sourced as Closure Stylesheets), but it required that you run every JS reference of a classname through goog.getCssName (which was prohibitive because we couldn't use Closure in the JS for bytesize reasons), and that you post-process the HTML (which was prohibitive both for CPU reasons and because Closure Compiler is written in Java while the HTML for Google Search, at the time, was generated in C++).

Re: Page Weight Matters (2012)

#106

Post by phamilton »

spion wrote: post #49
phamilton wrote: post #44

Earlier quoted context omitted.

> * 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.

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…

There's actually a lot of momentum on this from with the IAB (standards body for online advertising). The goal is to separate content from analytics. The result would enable publishers to prioritize loading the content before loading analytics.

Re: Page Weight Matters (2012)

#107

Post by spion »

kuschku wrote: post #102
spion wrote: post #92

Earlier quoted context omitted.

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 r…

Well, you could process the JSON on client side. response.comments.forEach(comment => comment.author = response.user[comment.author]); Preferably, even, you could do it during rendering so it can be garbage collected afterwards.

Well, that counts as further deserialisation in my book. At least if you set up a convention to automate it for all kinds of objects. Otherwise you'd have to do it manually for every type of request

Re: Page Weight Matters (2012)

#108

Post by vans »

geocar wrote: post #87
tedunangst wrote: post #84

Earlier quoted context omitted.

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 wi…

I'm sorry, but watching an ad isn't just a payment like you do with money. It's a rape of your mind. It needs your personal data, to rape your brain deeper. So i block ads, not to see content, but because ads don't deserve to exist.

Re: Page Weight Matters (2012)

#109

Post by chestervonwinch »

coldpie wrote: post #43
dpweb wrote: post #7

If you have an engineering mind and care about such things - you care about complexity. Even if you don't - user experience matters to everyone. Have you ever seen something completely insane and everyone around doesn't seem to recognize how awful it really is. That is the web of today. 60-80 requests? 1MB+ single pages? Your functionality, I don't care if its Facebook - does not need that much. It is not necessary.…

I took this screenshot yesterday. This was a page showing a news article (text). http://i.imgur.com/hmFaW3M.png

This is the problem exactly - it doesn't have anything to do with the language ... too many damn bells and whistles and too many damn analytics / ad libraries. If you're delivering content, you should focus on delivering the content. My computer shouldn't nearly freeze trying to read a recipe, or the weather, or a simple news article, etc ...

Re: Page Weight Matters (2012)

#110

Post by dredmorbius »

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.

I'm increasingly of the mind that:

1. Advertising is the problem.

It's creating technical problems. It's creating UI/UX problems. It's creating gobs of crap content. It's creating massive privacy intrusions and security risks. And for what? Buzzfeed?

2. Ultimately, the problem is the business model for compensating informational goods. Absent some alternative mechanism (broadband tax, federal income tax applied to creative works), I don't see this changing much.

https://www.reddit.com/r/dredmorbius/search?q=broadband+tax&...

3. Micropayments aren't the solution.

http://szabo.best.vwh.net/micropayments.html

Post reply on HN