Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A 2x Faster Web

blog.chromium.org

Post reply on HN
Print view View original

31–40 of 69 posts

Re: A 2x Faster Web

#31

Post by neilc »

swombat wrote: post #7

Impressive, how Google are taking on challenges that pretty much no other company could possibly address... replacing email... enhancing HTTP, etc... They're the only company with the means to take on such massive, unprofitable projects, and at the same time enough street cred that everyone won't immediately assume they're trying to make the web proprietary. The fact that they tend to open up these things from the ge…

They're the only company with the means to take on such massive, unprofitable projects, and at the same time enough street cred that everyone won't immediately assume they're trying to make the web proprietary.

They are hardly the only company doing this. Microsoft Research do a ton of pretty visionary / far-reaching work, much of which has nothing to do with MS-proprietary platforms. For example, the VL2 architecture for data center networks: http://sns.cs.princeton.edu/2009/10/new-datacenter-networks/

Re: A 2x Faster Web

#32

Post by timdorr »

sp332 wrote: post #9
nixme wrote: 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…

The future of the internet is ubiquitous encryption. Better to break caching models ASAP so that fixing them can be done incrementally.

Provided we're using IPv6 exclusively. SSL removes the ability to do virtual hosting, which is why we didn't run out of IPs 5-10 years ago.

Re: A 2x Faster Web

#33

Post by olefoo »

adamt wrote: post #24
nixme wrote: 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 (i…

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

It won't break all caching, just intermediate caches. True this does raise bandwidth usage and initial page load latency (assuming static content is not already cached on the client), but to say it breaks all caching is off.

That said, static image serving is not going to benefit from this new protocol all that much. It seems, like much of Google's other work in this area, to be focused on improving the performance of web-based applications.

Re: A 2x Faster Web

#34

Post by mseebach »

timdorr wrote: post #27
mseebach wrote: post #21

Earlier quoted context omitted.

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

Googles crawlers are located all over the place, and especially for the latency score, they should hit the site from a few different locations, as well as different times of day.

The cache trick is the same for not-logged-in users as well as for Google. If you're showing the same page to more than one user (and you should be, for your not-logged-in users), you should cache it and show everyone that. If show Google a few hours old version (that you wouldn't want users to see) you'll be punished with the current rules.

If you're only showing content to logged-in users, Google can't see anything, anyway.

Re: A 2x Faster Web

#35

Post by blasdel »

timdorr wrote: post #32
sp332 wrote: post #9

Earlier quoted context omitted.

The future of the internet is ubiquitous encryption. Better to break caching models ASAP so that fixing them can be done incrementally.

Provided we're using IPv6 exclusively. SSL removes the ability to do virtual hosting, which is why we didn't run out of IPs 5-10 years ago.

Any client supporting SPDY would absolutely support the Server Name Indication extension from RFC4366

Re: A 2x Faster Web

#36

Post by Periodic »

olefoo wrote: post #33
adamt wrote: post #24

Earlier quoted context omitted.

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 (i…

> SSL encryption will break all caching, and add latency in terms extra round-trip times. It won't break all caching, just intermediate caches. True this does raise bandwidth usage and initial page load latency (assuming static content is not already cached on the client), but to say it breaks all caching is off. That said, static image serving is not going to benefit from this new protocol all that much. It seems, l…

> It is designed specifically for minimizing latency through features such as multiplexed streams, request prioritization and HTTP header compression.

They specifically say their goal is to minimize latency to make web based applications more responsive. They aren't interested in making you able to download movies faster, what they want to do is make the web more responsive so that they can develop more apps for the web that traditional would have required a desktop client.

Re: A 2x Faster Web

#37

Post by ciupicri »

olefoo wrote: post #33
adamt wrote: post #24

Earlier quoted context omitted.

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 (i…

> SSL encryption will break all caching, and add latency in terms extra round-trip times. It won't break all caching, just intermediate caches. True this does raise bandwidth usage and initial page load latency (assuming static content is not already cached on the client), but to say it breaks all caching is off. That said, static image serving is not going to benefit from this new protocol all that much. It seems, l…

> It won't break all caching, just intermediate caches.

As far as I know, Firefox and maybe other browsers don't store on disk content delivered via https by default, which means that final caches will also be affected. Sure, the default can be changed, but it's an extra security risk. If it wouldn't be, the default setting wouldn't be like this.

Re: A 2x Faster Web

#38

Post by andreyf »

bobbyi wrote: post #22
dkubb wrote: 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.

You better start using it, then. Be it an official part of pagerank, or some emergent property of their crawlers, I've seen very good evidence that page load speeds have strong influence on natural search rank.

Regardless, Google is doing this to push at the technical limitations on apps like GMail or Google Reader, not Joe Shmo's burger shop.

Re: A 2x Faster Web

#39

Post by dkubb »

andreyf wrote: post #38
bobbyi wrote: post #22

Earlier quoted context omitted.

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

You better start using it, then. Be it an official part of pagerank, or some emergent property of their crawlers, I've seen very good evidence that page load speeds have strong influence on natural search rank. Regardless, Google is doing this to push at the technical limitations on apps like GMail or Google Reader, not Joe Shmo's burger shop.

That was my thinking too. With PageRank Google is trying to find a way to measure the perceived quality of the user experience for each page. Except there's no way to do that directly, so they look at indirect methods, like counting the number of inbound links. This is just another indirect measurement to add to (what I'm sure is) hundreds of other factors they use to rank a site.

IMHO a site that cares about the user experience would have been optimized to load quickly.

Heck, even if Google told people speed was important, and didn't incorporate any speed measurements into PageRank, I think it would have a positive effect.

Re: A 2x Faster Web

#40

Post by [deleted] »

teej wrote: post #28
shimon wrote: 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.

[deleted]
Post reply on HN