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."
Now you can refresh your Facebook page twice as fast!
is the "extend" part. Let's hope they don't get any temptation to become incompatible.
---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol
:-)
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
When can we expect the SPDY protocol to be implemented in HTTP servers like Apache or Nginx? Does anything need to be done? The summary only talks about adding support to the client portions.
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
Sorry, can't do, your post is read-only for most slashdotters.
Well.. creating standards or changing standards is bad. You break things, stuff stop working, people get angry.
Theres always some ways to cut corners and optimize everything withouth touching the standard.
Then you see that the standard is really unappropiate for the problem, and that a simple change on the standard coud unlock freedom and speed.
So you create a new protocol. But you find that such protocol break a lot of routers and proxys (very old, buggy, crappy, undocumented using, proxies).
Then you see a person getting the same speed you have manage with your new standard, using the old standard in a new way.
So you drop your new standard, because have a lot of problems, and is not really giving nothing new to the table.
Then you learn to respect standards a lot more. Like I do.
So only once in a blue moon you see this history having a happy end. Lets hope this time we have it here.
-Woof woof woof!
Comment removed based on user account deletion
Whenever someone starts a project with that in mind: it means shit!
Why wasn't it open source from the start?
Look what happened to symbian...
(Well, maybe I should rtfa but I'm already killing precious time by reading slashdot so that wouldn't be nice..)
A lot of people knew that when they decided to hide the http:/// portion of the URL bar, the real reason was to be able to push SPDY without users noticing, the problem: they told the user do not need to see that, bla bla bla, Not that I have something against an efficient enhancement to HTTP, but please, no need to hide the real reason
This is open sauced.
And it's a damn good sauce too!
Finally a story for us geeks that want geek stories....I guess cmdtaco is slowly waking up....
Let's say, for example, that Microsoft had: 1) Taken an existing web standard and made proprietary changes to it (promising to make the changes open-source, "in the future"), and 2) Implemented those changes in IE and MSN/Bing/Live.Com making those sites faster when using IE. Wouldn't everyone here being screaming "Anti-trust" and demanding an SEC investigation?
My Amiga struggles with Google as it is. What will happen when 'SPDY' becomes mandatory?
I think I covered that in the "They suck at being EVIL" part. Perhaps you failed to read my entire post?
"A person is smart. People are dumb, panicky dangerous animals and you know it." - K
like what they did with Kerberos.
The way MS extended Kerberos was 100% within the specifications of Kerberos. It was designed to do EXACTLY what Microsoft did.
The problem is that most implementations of Kerberos in the unix world were based off the same broken implementation that didn't actually deal with the specification properly. Get your facts straight.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Where the hell do you come up with this?
Standards are always being tweaked/change, but it's up to the companies seeking to make those changes doing it in an ethical way that matters most. While a lot of companies do a lot of unethical shit, the standards (and requirements of standards) do tend to speak for themselves. If this was some "Chrome-only" feature they wouldn't document it and/or open source it. If this is truly anti competitive you would hear the world shouting about it by now.
n/t
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
I am thinking Google did not learn the lesson from the SCSI acronym. Initially, the creator of SCSI wanted it to be pronounced "Sexy" and we ended up saying "Skuzzy." Obviously, Google wants this to be pronounced as "Speedy" but I can easily see this becoming "Spoddy."
And I have looked around a bit... I still can see where SPDY is defined anywhere as to what the letters mean? I can imagine a lot of meanings... except for the Y. (Standard Protocol no aDopted Yet)?
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.
IMO this is what separates Chrome from other browsers - the fact that Google is turning stuff out like this, and keeping the active development cycle going, quickly. Firefox seems to be playing catch up at this point with other browsers - sure it's more customizable and has a few more features, but do we see Mozilla rolling out protocols that "cut page load times in half" (I have some doubts that it'll be half, but that's just me). Thank you Google, for taking another step in the right direction with your browser.
If theyre using SPDY on google.com, its STILL an HTTP GET. Dont believe me? Go there with Chrome's developer tools open to the network tab. Check the headers.
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.
As part of the "Let's make the web faster" initiative, we are experimenting with alternative protocols to help reduce the latency of web pages.
This smells very close to the "embrace extend and extinguish" technique of Microsoft. Unless Google follows it by keeping the technology open, work on getting it certified into the next version of the standards, this would become the first step in Google becoming the next Microsoft.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
I cannot be the only person to think this is not a good thing. So now we'll have sites that have to run both technologies with regular HTTP/TCP as fallback and we fragment the web browser ecosystem even more.
Thanks Google. As much as I want HTTP to be faster, I think this way is a bit degrading to the web... There was no standards process. It will probably now be rushed as a standard.
Basically its a fake way of making Google look faster, so you either adopt Google's tech to get ahead. It reeks of a Microsoft strategic move to me. Can't optimize the browser? Change the browser and make an incompatible change! Well done...
Slashdot needs Geekcode | Can anyone recommend any good SCIFI? My tastes: Foundation, Startide Rising, CITY, Ringworld,
I notice they're on version 10 since March 27...does that mean this is included in their latest build?
http://www.srware.net/en/software_srware_iron_download.php
-Styopa
I thought BEEP was a great concept that seemed to die on the vine. When I saw "multiplexing," I figured Google had resurrected the protocol but it looks like BEEP just doesn't go far enough.
As for that 6 socket connections per client connection...wow! Never knew those kinds of resources were being devoured for every network connection.
I swear to God...I swear to God! That is NOT how you treat your human!
Actually the article is wrong about this, the code is open source (Chrome or alteast Chromium which it is based on is an open source project after all) and their are drafts for the RFC.
New things are always on the horizon
SPDY just multiplexes HTTP-requests over TLS ('SSL' as used by HTTPS) or in theory TCP.
New things are always on the horizon
SPDY does not make ads cache more or less, any browser that does or would implement SPDY already does caching for HTTPS correctly (it adheres to what the creator of the webpage specied in the headers).
New things are always on the horizon
SPDY also allows the server to communicate with a client without a client request
Could this possibly be used to attack client computers?
Are YOU using the TOOL, or is the TOOL using YOU? Think about it!
I don't know why you are rambling on about this.
The people working on SPDY submitted or working on atleast 3 different drafts for different changes to the IETF for backwardcompatible changes (SSL/TLS False start, HTTP-header for upgrade-to-SPDY and SPDY) that I know of.
New things are always on the horizon
It is the summary and article that are wrong.
SPDY has a draft and they already sumitted to other drafts to the IETF.
New things are always on the horizon
Well, maybe he wasn't referring to caching by the browser, but to caching by some intermediate server (forward caching).
The Tao of math: The numbers you can count are not the real numbers.
Yeah, I was thinking about that later.
I actually think not that many people actually still use proxies.
New things are always on the horizon
This is an interesting wrapper around MIME, but it is not HTTP in any way. Honestly, it's more like an "embrace-and-extend" in the Microsoft sense. It is backward-incompatible in ways that are inconsistent with its stated philosophy of bandwidth savings (and in ways which break the most basic HTTP semantics), and it throws gratuitous binary into the wrapper while using FUD to justify its presence (notably the specter of "security problems"). This is sad, because it actually does contain some much-needed improvements to HTTP, such as TLS-only, compression-by-default, and header compression. But it's not an extension, because that implies backward-compatibility: it's a replacement, and one with certain other design decisions that are questionable at best.
Some questions in particular:
1) Why break the request-line and status-line? This is the major compatibility-killer, and it adds to the bandwidth consumed by the protocol in ways directly counter to the concept of saving bandwidth. To call requests and responses "virtually unchanged" from HTTP is disingenuous when the most basic syntactic requirements for both of these things is completely different: they are in fact completely different, not virtually unchanged: what you've unchanged is MIME.
2) Why binary for the wrappers? The specter of security issues via incorrect parsing is true as far as it goes, but by no means insurmountable, and the bandwidth savings are minimal at best. In exchange, the spec becomes considerably harder to debug (and thus to implement) and to extend further as needed by future requirements.
The client has to initiate the connection with the server, these features just allow the sever to send back more data than was requested. If there was a bug in how the client processed the data then it could be exploited as a security request. However that is already true today of the data the client is requesting. This extra data will be in the same format as if the client directly requested it (except with the X-Associated-Content header added), so the same code should be used to parse it.
Like I mentioned above, I don't think the push features of SPDY improve it enough to be worthwhile, but I don't think they are a security problem.
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.
Right. I've commented on this before. If a page loads slowly today, it's usually for one of three reasons.
The SPDY approach won't fix any of these problems. Client side last-mile bandwidth usually isn't the bottleneck. It might make a difference on mobile, where getting through the air link is a bottleneck. It might help for Google's own pages, where there are multiple components coming in from different Google servers. Google tends not to load content from others on their own pages, so they need more connections to their own servers. Most sites aren't like that.
A new source of delay is "social" features. "Like" buttons for Facebook, Digg, etc. all add to page load time. "Disqus" comment forms add to page load time.
Making all the junk stuff load concurrently creates another problem. As each irrelevant item arrives, the page has to be reformatted to fit. So the user is shown a page which "squirms" as all the unwanted junk is pulled in.
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.
The big difference, though, is that Google has implemented SPDY on google.com websites and on Chrome. So you only get the speedup with the combination of google.com and Chrome, two things which are under Google's control, and which now (more than before) work better together than if you replace one with a competing product.
I am unsure what the open source status of the client and server side code here is. But even assuming both are fully open source and fully functional right now, this concerns me. There has been no standards process for SPDY that I am aware of. Is Google seriously making Chrome "the browser that works best with google.com" by adding special extensions?
It should be noted that SPDY is not an acronym or initialism. It's merely a shortening of the word Speedy.
So, if you're wondering what SPDY stands for, the answer is nothing.
What's closed about WebM? And you're trying to accuse Google of openwashing without a single mention of Android?
"When information is power, privacy is freedom" - Jah-Wren Ryel
This methodology was tried long ago, it's called HTTP keepalive. The problem is that every blasted selfish client wants to keep your server connections occupied in hopes that you'll be browsing forth within a short period. In the One-Process-One-Connection model, this is extremely inefficient and taxing on the server. The idea of keeping connections open for HTTP kills the multiplexing ability of the server. This is great for IMAP, but sucks for HTTP. HTTP is lightweight, all they are doing is adding some extensions to the original keepalive model, multiple streams on the same connection, and push.
The multiple stream issue doesn't seem like a win because you would need a highly specialized HTTP engine (like Google has probably designed for their search tool) to take advantage of multiple streams per connection. The traditional model doesn't lend itself well to this. The Apache process/thread model would be closer and permit this kind of solution, but typically threads suffer from I/O starvation due to blocking on data. I could also see some caching issues and subquery issues with the multiple stream per connection model.
Of course the push method is really there so Google can use HTTP like other push protocols, but be able to code against HTTP instead of using the other protocols for what they were designed for. Why not put weight behind the protocols that are intended for these kinds of things instead of trying to co-opt an existing protocol to do your bidding? There is already an IMAP-push proposal, which I'm sure would see swift adoption if Google deployed that internally.
I remember some "push" (content) network from the late 90s that went nowhere, had an ex-Cisco or Netscape guy as a co-founder. Push has traditionally been a non-starter because it either is just a roll reversal, or it's an attempt to circumvent the notion that clients are clients and servers are servers.
My favorite example that doesn't get much play is ETRN in SMTP. Basically it's intended to solve the (old) dilemma of dialup mail servers.
It is incompatible with all other websites and all other browsers - it only works with the combination of Chrome+Google's own websites.
This is flat out wrong. Just this morning I used Chrome to connect to a test server that was running a node.js implementation of SPDY. I verified the connection using chrome://net-internals. It worked well.
There is nothing in chrome that prevents this from working on other domains/websites.
There is nothing stopping anyone from implementing their own server.
End of FUD.
You're absolutely correct about protocol openness being the important issue.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Wow! In my early 20s, I used to read PLATO Notesfiles, and later Netnews, and if I wanted to read news it came on chopped-up dead trees. (For a year or two that was also how I read netnews, once it had gotten big enough that printing it all 4-up on the new laser printer was easier than reading it article-by-article at 1200 baud.)
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
You mean those things that Ghostery and NoScript block?
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Browsers have cached DNS for years, in addition to the caching that ISPs do. It's been a problem for load-balancers and disaster recovery web servers, because they can't trivially move what machine you're getting web pages from just by changing the DNS response.
I noticed Chrome offering to pre-fetch DNS. It's a mostly good idea, though we're going to see things like web bugs that use unique DNS entries to get around browser privacy features that block them from loading images or running Javascript things.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
I've been surprised how much stuff Ghostery finds to block, in addition to the things NoScript and AdBlock Plus block.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
What happens if you can't afford to buy an SSL certificate for your mom and pop website? (Yes, I know, someone at Comodo will buy one for you. Har har.) Is SPDY only for large hosts or can the little guy benefit as well?
Because this causes more slowdowns than anything else.
You've gotta be kidding me! You need to fix your hosts file. 127.0.0.1 loads faster for me than anything else.
SWM seeks new sig for a brief fling