Slashdot Mirror
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."
:-)
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
My pages load plenty fast. What I notice is that when the page goes to google analytics that load process stops while waiting for the server. There was a time when pages would load partial content, and then go for the ads. Now, many pull the ads and analytics first. This would be good if the ad servers were fast, but the seem to be getting slower. Since google serves so many ads, it seems within it's power to make the web faster by making the ads faster. Perhaps, like MS, they want the web slow for all other browser, so Chrome seems so much faster.
"She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
http://www.chromium.org/spdy/spdy-whitepaper
No, because the Microsoft way to embrace, extend, extinguish was to keep the "how to extend" part to itself and secret, like what they did with Kerberos.
This is open sauced. You are free to implement it in your own stuff.
You would have known that if you read the article.
--
BMO
Comment removed based on user account deletion
http://code.google.com/p/mod-spdy/
Student: Is it true that the foundation of the universe is paradox?
Master: Well, yes and no.
Finally a story for us geeks that want geek stories....I guess cmdtaco is slowly waking up....
SPDY is (according to Google) going to be released as open source, so I'm hopeful that it's development will be more akin to Mozilla's tack with its "Do Not Track" header - add support to your own browser, then throw it out there and see if the market is interested. IE9 already supports the "Do Not Track" header and there is also signs of some interest from websites too, so that's looking good.
What would be even better though, especially given that SPDY is really an extension to HTTP akin to using GZ compressed data, is if Google were also to write up and submit an RFC or whatever mechanism it is that W3 uses to get HTTP extensions added to the standard, such as it is. SPDY seems very much like a win for both content providers and content consumers to me, so once the details are out there I'd like to think that we'd see fairly rapid adoption by the browsers over the next several months, followed by backend support from Apache, IIS et al with their next major releases.
UNIX? They're not even circumcised! Savages!
I'll take a stab at it :
Everything is sent through an encrypted channel making it difficult to filter out ads before they hit the client (like with privoxy for example.)
No cashing ("Since we're proposing to do almost everything over an encrypted channel, we're making caching either difficult or impossible." -Protocol Draft) means you'll be served "fresh" ads every time.
So it looks like this would be good news for Google's core business.
If all else fails, immortality can always be assured by spectacular error.
My favorite part of the SPDY is server push: now advertisers can clog my internet channel and hog the browser with ads long before the AdBlock kicks in. Or a hacked site would host malware and load it onto potential victims harddrives in parallel to normal surfing. Imagination is the only limit - of how it can go wrong.
For the security reasons, I think SPDY is a bad thing.
And I'm personally not bothered with 1-2s loading times.
P.S. The Chrome guys instead would have invested more times in the bookmarks, to make them useful. They could start by integrating Chrome with the Google Bookmarks.
All hope abandon ye who enter here.
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
and
https://www.tools.ietf.org/agenda/80/slides/httpbis-7.pdf
I've also answered a few similar questions to this here: http://hackerne.ws/item?id=2420201
We love help- if you're passionate about protocols and want to lend implementation help, please hop onto spdy-dev@google.com Several independent implementations have already cropped up and the feedback continues to be really great.
With Honeycomb, doesn't Google have a history of saying things will be released as open source, and then not releasing the source?
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 spdy-dev@google.com, and if you want to lend a hand implementing, that is even better!