Live data from Hacker News

A 2x Faster Web

blog.chromium.org

21–30 of 69 posts

Re: A 2x Faster Web

#21
post #17
post #12

I love that Google is focusing on how to speed up the web, but they are missing the most obvious thing they could do that would have a dramatic impact on the speed of the web: Update their PageRank algorithm to take into account website speed, and then publish this as a fact. The idea would be that they would have GoogleBot measure the latency, and overall page load time and rank sites higher that respond faster, and…

Except your network connection to a site is going to be drastically different than Google's. Case in point: My datacenter directly peers with Comcast, so I get It would be like comparing the drive to a particular location using completely different starting points. Plus, people would start doing all sorts of tricks to boost their ranking. Serving static, cached files for Google and giving everyone else a slow, dynami…

It's a challenge, but one that can be overcome.

Google just needs to figure out a reasonable baseline latency to subtract - for that, there's ping, ping the previous host on the route, latency to other hosts with close IPs, GeoIP+a database of baseline latency to sites in the same area etc.

And the tricks will be dealt with the same way as now: If you're caught doing them, you're blacklisted. But this will be less of an issue in this case: If you've taken the trouble to set up caches that you can direct Google to -- why not direct your actual users to that too?

Re: A 2x Faster Web

#22
post #12

I love that Google is focusing on how to speed up the web, but they are missing the most obvious thing they could do that would have a dramatic impact on the speed of the web: Update their PageRank algorithm to take into account website speed, and then publish this as a fact. The idea would be that they would have GoogleBot measure the latency, and overall page load time and rank sites higher that respond faster, and…

If google stopped ranking the most relevant content at the top, I would start using bing instead.

Re: A 2x Faster Web

#23
post #8

Am I missing their explanation of how a SPDY-capable client and server discover and make use of SPDY instead of HTTP? For this to take hold in the wild, it has to be possible for me to run a combined HTTP+SPDY server, and for a client connecting to it to automatically make use of SPDY if it is capable. This must happen without user intervention (i.e. we don't expect people to type spdy:// instead of http:// ). It see…

HTTP supports protocol upgrades although this has never been used in the wild.

Re: A 2x Faster Web

#24
post #3

The whitepaper has more information: http://dev.chromium.org/spdy/spdy-whitepaper Interesting parts: - "...make SSL the underlying transport protocol, for better security and compatibility with existing network infrastructure." Won't this break many caching models? - "...provides an advanced feature, server-initiated streams. Server-initiated streams can be used to deliver content to the client without the client nee…

These all sound like a step in the wrong direction to me:

The reason HTTP has been so successful has been it's simplicity. HTTP with it's human readable format is not the most efficient, but this makes this it simple. Things like header compression to me are missing the point.

SSL encryption will break all caching, and add latency in terms extra round-trip times.

gzip encoding has minimal value on media data types (images, movies) that represent the majority of the data.

This just sounds like a whole load of complexity for a relatively small one-off hit.

Re: A 2x Faster Web

#25
post #12

I love that Google is focusing on how to speed up the web, but they are missing the most obvious thing they could do that would have a dramatic impact on the speed of the web: Update their PageRank algorithm to take into account website speed, and then publish this as a fact. The idea would be that they would have GoogleBot measure the latency, and overall page load time and rank sites higher that respond faster, and…

This is a horrible idea. Yes, it would result in increased focus by some people on speed, but probably the same people who focus on "SEO". So now content relevancy has yet another adversary in the battle for SERPs. There's a LOT of really incredible, original content out there written by amazing people who do it in their spare time and don't give two shits about their SEO or the speed of their server, and now that content is going to slip further down the rankings because it takes 2 seconds to load instead of 100 ms? No thanks.

Re: A 2x Faster Web

#26
post #14
post #10

Earlier quoted context omitted.

Agreed. I think the important thing to note is that Google is the only large company whose business model depends almost completely on the success of the Internet. This is why we see them at bat for Net Neutrality as well as efficiencies within communication protocols. Microsoft, Apple, Oracle, HP, IBM . . . those companies make their livings in other ways. The only company comparable to Google would be Yahoo in this…

While I agree with you generally. MS, Apple, Oracle, HP, IBM or any personal computer or server related business would either not be as successful or their product as widely used if there was no internet. IE. Imagine a personal computer market with no way for computers to communicate with each other, would users be still buying computers as much as they do now or would it be just a small niche market? Even though the…

These other companies get more value by the internet existing and being useful. They don't get much value when people use the internet more. Google does. In a sense, google competes with other ways people spend their time, like television.

Re: A 2x Faster Web

#27
post #17

Earlier quoted context omitted.

Except your network connection to a site is going to be drastically different than Google's. Case in point: My datacenter directly peers with Comcast, so I get It would be like comparing the drive to a particular location using completely different starting points. Plus, people would start doing all sorts of tricks to boost their ranking. Serving static, cached files for Google and giving everyone else a slow, dynami…

It's a challenge, but one that can be overcome. Google just needs to figure out a reasonable baseline latency to subtract - for that, there's ping, ping the previous host on the route, latency to other hosts with close IPs, GeoIP+a database of baseline latency to sites in the same area etc. And the tricks will be dealt with the same way as now: If you're caught doing them, you're blacklisted. But this will be less of…

But you're assuming location is all that matters. Certain network providers, no matter how close they are to you, just have shitty, overloaded networks.

The cache trick is that Google doesn't need to see dynamic content as much as the user does. Example: Any site that's based on user selection to determine customization. I might need to see recommended content that's based on a very complex algorithm that takes a while to generate the page. Whereas Google just needs to see a page. Cache for Google, generate from scratch for everyone else.

Re: A 2x Faster Web

#28
post #8

Am I missing their explanation of how a SPDY-capable client and server discover and make use of SPDY instead of HTTP? For this to take hold in the wild, it has to be possible for me to run a combined HTTP+SPDY server, and for a client connecting to it to automatically make use of SPDY if it is capable. This must happen without user intervention (i.e. we don't expect people to type spdy:// instead of http:// ). It see…

This is merely the spec doc for the DVD. The combo VHS-DVD players will come next.

Re: A 2x Faster Web

#29

Regarding the use of SSL by default, they better require the use of the SSL mode which sends the hostname before the crypto negotiation. Otherwise that's a lot of IP addresses required for virtual hosting!

We will.

Re: A 2x Faster Web

#30
post #8

Am I missing their explanation of how a SPDY-capable client and server discover and make use of SPDY instead of HTTP? For this to take hold in the wild, it has to be possible for me to run a combined HTTP+SPDY server, and for a client connecting to it to automatically make use of SPDY if it is capable. This must happen without user intervention (i.e. we don't expect people to type spdy:// instead of http:// ). It see…

You can read the code for the precise details, but we'll be using both an HTTP upgrade and a TLS extension.

But all this is still experimental.

Post reply on HN