Page Weight Matters (2012) • Hacker News Board

Re: Page Weight Matters (2012)

#121

Post by nostrademons » Thu, Oct 15, 2015, 10:17 PM UTC

rattray wrote: post #115

kuschku wrote: post #65

Earlier quoted context omitted.

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

Wow. What is this and why does it exist?

It is the old rendering path for Google Custom Search Engines:

https://developers.google.com/custom-search/docs/overview?hl...

Way back when Google first got VC, before they invented AdWords and got profitable, they explored a lot of custom business partner opportunities. So there were a number of specialized Google search endpoints like /linux, /bsd, /unclesam (search over Federal government websites). These were maintained until about 2013 - they go through a different rendering path than the one that serves mainstream Google Search. /linux, /bsd, /unclesam, and a few others were decomissioned in 2013, soon before I left Google, but it looks like /custom got a reprieve for whatever reason. It's actually been deprecated by the Custom Search Engine functionality linked above, but nobody's gotten around to removing it.

Incidentally, you can also get a similar page (slightly different, its last update was around 2007 and it shows no ads) by setting your user agent to "Mozilla 3.0".

Re: Page Weight Matters (2012)

#122

Post by micampe » Thu, Oct 15, 2015, 10:22 PM UTC

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.

I wish HN prevented new accounts from commenting for one day unless verified by a mod.

Re: Page Weight Matters (2012)

#123

Post by pikzen » Thu, Oct 15, 2015, 10:35 PM UTC

jkaptur wrote: post #12

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

Honestly, I think "a daily drumbeat about how bloated, how needlessly complex, how ridiculous most of the world's web applications really are" pretty much describes every HN conversation on any article with even a remote connection to web technologies.

Thankfully web developers are sharing the goodness and distributing 100MB+ executables using NodeJS & CEF so desktop applications can be insanely large too :^)

Re: Page Weight Matters (2012)

#124

Post by paulirish » Thu, Oct 15, 2015, 10:42 PM UTC

More than page weight, this article demonstrates that averages are dangerous, especially for performance metrics. All key metrics should be plotted in 50/90/95/99 percentiles, and for latency-sensitive ones, geographic breakouts can often reveal a serious delta from the mean.

Re: Page Weight Matters (2012)

#125

Post by Kluny » Thu, Oct 15, 2015, 10:42 PM UTC

draw_down wrote: post #13

jkaptur wrote: post #12

Earlier quoted context omitted.

Honestly, I think "a daily drumbeat about how bloated, how needlessly complex, how ridiculous most of the world's web applications really are" pretty much describes every HN conversation on any article with even a remote connection to web technologies.

Jeez, you aren't kidding. It's as though, if we bitch enough about the technical deficiencies, the economic and social circumstances that cause them will, I dunno, vanish into thin air I guess. This topic is pretty much just red meat here

Well, bitching isn't that great. But as a web developer myself, it has affected the way I work. Like, there was an article just the other day about how to achieve "lightning fast page loads". I shared it around the office and as a result, 4 people have added new steps to their workflow to help reduce page load latency on our client sites.

The author knew the article would get good reception here, because of how much people complain about page latency, and I knew that page latency is a thing that's important to more people than just me, for the same reason. (My clients mostly don't seem to care, for some reason, but I bet their customers do).

So yeah, having these public conversations can make a difference. We just have to stay positive and constructive.

Re: Page Weight Matters (2012)

#126

Post by cr4zy » Thu, Oct 15, 2015, 10:44 PM UTC

I highly recommend turning on page throttling in the Chrome Dev Tools sometime. You'll be amazed at even how slow even 4G seems.

Re: Page Weight Matters (2012)

#127

Post by kellysutton » Thu, Oct 15, 2015, 10:50 PM UTC

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.

Two Client Hints are in the works to provide exactly this. Check out Save-Data and Downlink: http://igrigorik.github.io/http-client-hints/

Re: Page Weight Matters (2012)

#128

Post by dredmorbius » Thu, Oct 15, 2015, 10:52 PM UTC

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

Re: Page Weight Matters (2012)

#129

Post by kellysutton » Thu, Oct 15, 2015, 10:52 PM UTC

andrewstuart2 wrote: post #58

Page weight may matter, but I think amortized page weight matters most. It's like the marshmallow experiment for the web. If you can make one request at 10x the size, but it's only made 1/100th as often (presumably spans multiple pages) then as long as people come back enough to justify that initial extra cost, you've effectively decreased to 1/10th again. That's why I think AJAX, web manifest [1], indexedDB, localSt…

The Ember FastBoot project has the goal to provide exactly this: lightweight HTML/CSS on the initial load and then hydrate the page/application with JS.

http://emberjs.com/blog/2014/12/22/inside-fastboot-the-road-...

https://github.com/tildeio/ember-cli-fastboot

Re: Page Weight Matters (2012)

#130

Post by PavlovsCat » Thu, Oct 15, 2015, 10:55 PM UTC

jjzieve wrote: post #85

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

Sure, most games these days are probably more CPU/GPU bound, but then again people usually don't have more than one game running at a time, while caching the assets of thousands more.

Also, isn't adding bloat "more work"? And just like in real life, I think losing bloat is often harder than gaining it. Why not worry about carousels or endless scrolling or video background when even just one person misses that stuff? Where are all the highly successful websites that started to reduce bloat after they got off the ground? It's not a rhetorical question or sarcasm, I am interested, but I honestly can't think of even one example, it doesn't really mesh with my own (admittedly rather pedestrian) experience. A site starts with a blank design doc, and empty file and a white screen, and adding something and later removing it isn't easier than simply not adding it in the first place.