Google Cuts Chrome Page Load Times In Half w/ SPDY

An anonymous reader writes "It appears as if Google has quietly implemented the SPDY HTTP replacements in Chrome (well, we knew that), and its websites. All its websites were recently updated with SPDY features that address some of the HTTP latency issues. The result? Google says the pageload times were cut about in half. SPDY will be open source, so there is some hope that other browser manufacturers will add SPDY as well."

Detailed info on SPDY

[NevarMore]

http://www.chromium.org/spdy/spdy-whitepaper [chromium.org]

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Use in HTTP Servers

[S77IM]

http://code.google.com/p/mod-spdy/ [google.com]

thank you, finally

[hesaigo999ca]

Finally a story for us geeks that want geek stories....I guess cmdtaco is slowly waking up....

Re:Have no page load problems

[gpuk]

Normally, DNS lookups *are* locally cached by default....... if you're on Windows, try running ipconfig /displaydns

The problem might be with your upstream resolver(s). If you use your ISPs resolvers, maybe they are are overloaded? Or if you are using a non-ISP upstream cache, maybe it's sparsely populated? Either of these would make initial lookups slow.

You could give Google's public resolvers a try and see if they improve your lookup times: 8.8.8.8 and 8.8.4.4

SPDY clarifications

[mbelshe]

Thanks for all the kind words on SPDY; I wish the magazine authors would ask before putting their own results in the titles!

Regarding standards, we're still experimenting (sorry that protocol changes take so long!). You can't build a new protocol without measuring, and we're doing just that - measuring very carefully.

Note that we aren't ignoring the standards bodies. We have presented this information to the IETF, and we got a lot of great feedback during the process. When the protocol is ready for a RFC, we'll submit one - but it's not ready yet.

Here are the IETF presentations on SPDY:
      http://www.ietf.org/proceedings/80/slides/tsvarea-0.pdf [ietf.org]
and
      https://www.tools.ietf.org/agenda/80/slides/httpbis-7.pdf [ietf.org]

I've also answered a few similar questions to this here: http://hackerne.ws/item?id=2420201 [hackerne.ws]

We love help- if you're passionate about protocols and want to lend implementation help, please hop onto [e-mail] Several independent implementations have already cropped up and the feedback continues to be really great.

Re:BAD

[mbelshe]

Actually, you should read the spec as to how it is implemented. The TLS/NPN mechanism for switching to SPDY has no "fallback".

And there is no intent to rush - heck - we've been working on it for over a year. You think that's rushed? If you're an engineer, I hope you'll appreciate that protocol changes are hard. You can't use pure lab data (although we started out with lab data, of course). Now we need real world data to really figure it out. We changed it in a way which *nobody noticed* for about 4 months. So, I don't think we hurt the web at all, but we are accomplishing the goals of learning how to build a better protocol.

Seriously, if you have a better way to figure out new protocols, we'd love to hear them at [e-mail], and if you want to lend a hand implementing, that is even better!

Re:SPDY - server push

[ThePhilips]

I'm not sure there's really a security issue here. From the spec [chromium.org], all its doing is letting the server send back multiple items in response to a request for one item. So if you request X, and the server knows you're going to need Y too, it can send both at once.

If server "knows" that I "need" 2MB of flash ads to see the 40K html page, it would send them to me. IOW browser is out of control what server sends, browser can only discard the content which has wasted my bandwidth and isn't going to be displayed.

It's not like the server can connect to you out of nowhere and start firing stuff at you. And since a server can already send malicious content back in response to a request, the security aspect isn't really worse then it already is.

With HTTP, there is no way server can send me something my browser didn't asked for. It can send something bad *instead* of what my browser asked - but only once and with user visible effect. With SPDY, server can send me loads of junk *silently*, still appearing to be serving legit content.

For static content, it is even worse: first time I visit the page it is cached and then a cached copy used. With SPDY, bandwidth is going to be always wasted for transferring the static content. Yes, I need it to display the page - but no, I have already local cached copy.