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

131–140 of 171 posts

Re: Page Weight Matters (2012)

#131

Post by voltagex_ »

malka wrote: post #62
motoboi wrote: post #19

Coming from a low bandwidth, high latency part of the world, I can't confirm this enough. Today, I have 2 mbit and can use Netflix or Youtube just fine, but mere 4 years ago, I had 600k and, boy, that was hard. Hard as in loading youtube URL and go for a coffee. UPDATE: In case Duolingo developers are listening, please test your site on high latency and very low bandwidth scenarios. I just love your site, but lessons…

> Hard as in loading youtube URL and go for a coffee. You can't even to that now. Youtube videos buffer about 1m30 of videos and stops after that :(

I understand that Google is doing this to save an immense amount of wasted bandwidth. These days if I need to wait for something to load, I use youtube-dl.

Re: Page Weight Matters (2012)

#132

Post by Brakenshire »

gwern wrote: post #50
foxbarrington wrote: post #38

If it takes two minutes to load a 100kb page, does it take twenty minutes to watch a 1MB video? Over three hours to watch a 10MB video?

Probably not. Downloading the video is going to depend more on throughput than on latency. The initial connection & page load, as it hits all the domains and resources, is going to be much slower because it relies more on latency and roundtrips.

The article says that the page would have taken 20 minutes to load under previous circumstances.

Re: Page Weight Matters (2012)

#133

Post by kragen »

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.

What would be super awesome would be a daily drumbeat about how to slim down and simplify applications, with working, open-sourced code.

Here, I'll beat a drum a little. Maybe it will inspire somebody.

I just wrote this tiny text-rendering engine, mostly yesterday at lunch. On one core of my laptop, it seems able to render 60 megabytes per second of text into pixels in a small proportional pixel font, with greedy-algorithm word wrap. That means it should be able to render all the comments on this Hacker News comment page in 500 microseconds. (I haven't yet written box-model layout for it yet, but I think that will take less time to run, just because there are so many fewer layout boxes than there are pixel slices of glyphs.) http://canonical.org/~kragen/sw/dev3/propfont.c

The executable, including the font, is a bit under 6 kilobytes, or 3 kilobytes gzipped.

Re: Page Weight Matters (2012)

#134

Post by kuschku »

nostrademons wrote: post #121
rattray wrote: post #115

Earlier quoted context omitted.

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

But, the advantage of /custom: It uses less personalized results, and it returns exactly 20KiB of data – which is why it still loads so fast.

There was a day when I just wrote a small script to open all sites mentioned in Google’s robots.txt (which did not return 404) in a separate tab. That’s how I found it.

As far as I know, some partners actually still embed /custom (I’ve only seen it at a newspaper a few months ago), so removing it might be problematic.

Re: Page Weight Matters (2012)

#135

Post by motoboi »

malka wrote: post #62
motoboi wrote: post #19

Coming from a low bandwidth, high latency part of the world, I can't confirm this enough. Today, I have 2 mbit and can use Netflix or Youtube just fine, but mere 4 years ago, I had 600k and, boy, that was hard. Hard as in loading youtube URL and go for a coffee. UPDATE: In case Duolingo developers are listening, please test your site on high latency and very low bandwidth scenarios. I just love your site, but lessons…

> Hard as in loading youtube URL and go for a coffee. You can't even to that now. Youtube videos buffer about 1m30 of videos and stops after that :(

At the time, I wrote an Chrome extension that would select the lowest resolution (240p at the time), but I can't remember if it was capable of autoplay.

Re: Page Weight Matters (2012)

#136

Post by hyperion2010 »

Heh, I've been using flask tempting to make some html forms for exploring large datasets. Turns out when you have 6000 terms that show up in 6 different UI elements putting those in as raw html results in a 13mb file that compresses down to 520kb. Pretty awful use case for forms. I'm pretty prejudiced against JavaScript, but having seen this I now deeply appreciate being able to send something other than raw html.

Re: Page Weight Matters (2012)

#137

Post by justinator »

kuschku wrote: post #134
nostrademons wrote: post #121

Earlier quoted context omitted.

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

But, the advantage of /custom: It uses less personalized results, and it returns exactly 20KiB of data – which is why it still loads so fast. There was a day when I just wrote a small script to open all sites mentioned in Google’s robots.txt (which did not return 404) in a separate tab. That’s how I found it. As far as I know, some partners actually still embed /custom (I’ve only seen it at a newspaper a few months a…

    > As far as I know, some partners actually still embed
    > /custom (I’ve only seen it at a newspaper a few months
    > ago), so removing it might be problematic.
An ISP local to here does. [0]

http://centurylink.net/search/index.php?context=search&tab=W...

I see it every so often if a domain doesn't get resolved - they'll hijack the request and show you their own page. I was pretty surprised that that still happens.

Re: Page Weight Matters (2012)

#138

Post by staplung »

nostrademons wrote: post #121
rattray wrote: post #115

Earlier quoted context omitted.

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

Ahh, heirloom. (That's the name of the system that renders Google for ancient user-agents). Takes me back. It actually got a small set of updates in 2010 when we wrote Heirloom+ and it appears that someone has collapsed the two systems into one since I left in 2011. I'm strangely gratified to see that no one has come up with a better layout solution than putting the results in a table.

Re: Page Weight Matters (2012)

#139

Post by [deleted] »

staplung wrote: post #138
nostrademons wrote: post #121

Earlier quoted context omitted.

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

Ahh, heirloom. (That's the name of the system that renders Google for ancient user-agents). Takes me back. It actually got a small set of updates in 2010 when we wrote Heirloom+ and it appears that someone has collapsed the two systems into one since I left in 2011. I'm strangely gratified to see that no one has come up with a better layout solution than putting the results in a table.

[deleted]

Re: Page Weight Matters (2012)

#140

Post by Dru89 »

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…

It's somewhat tangential, but I'm curious what you mean by "HTML-aware templating language".
Post reply on HN