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!
50% faster first posts!
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
This is Google's version of Embrace, Extend, ?, Profit. It's just that Google really sucks at being EVIL
"A person is smart. People are dumb, panicky dangerous animals and you know it." - K
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
[Insert reason on why Google is "evil" for doing this here]
http://www.chromium.org/spdy/spdy-whitepaper
Because this causes more slowdowns than anything else.
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..)
We aren't sure if this keyboard posted by Beverloo is actually a screenshot of the Chrome keyboard.
"Old Media" now simply comment on "New Media"
"New Media" now simply plagiarize from blogs
Who is making the next product, I'll throw together some fake screenshots and call them "leaked photos" - I suggest you all do the same in your own inventive ways.
And nothing of value was lost.
Are we completely pathetic?
Finally a story for us geeks that want geek stories....I guess cmdtaco is slowly waking up....
HTTP got us along ways, but it has some serious architectural issues that make it unsuited for the modern web. We've been looking at SPDY and while it isn't perfect, it does fix a lot of the bottlenecks that are intrinsic to HTTP. It isn't a perfect replacement, but the perfect is the enemy of the good. I'll be happy if SPDY manages to displace HTTP over the next decade or so.
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?
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.
Must be a specimen from the nearly extinct species of "diggeratus". I, for one, am excited for having spotted one of these out in the wild.
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)?
"SPDY supports unlimited connection streams, can prioritize and even block requests if Google determines the site is a threat to any government it happens to be seducing^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H a communication channel gets overloaded and supports header compression."
nonsig. unsig. desig.
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.
Pray I do not alter it further.
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.
Anyone else a little uncomfortable with this?
What if Microsoft created a new protocol to speed up communication between IE9 and Bing? Slashdot would (rightfully) outrage at the idea.
Why no outrage if Google does it? Because the code will eventually be open source? Give me a break.
This shows where Google is really heading: keep code open source to keep the geeks happy, but keep their standards closed. This is WebM all over again. This is a closed standard, that no one except Google was involved in creating, and Google is using their position in the market to force it on customers.
In an ideal world, standards should be both open source and openly developed. Google is better than Microsoft for open sourcing their code... but they are still closing the standards. Only Google can say how the standard will develop.
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.
From the whitepaper: "...Exclusively client-initiated requests. In HTTP, only the client can initiate a request. Even if the server knows the client needs a resource, it has no mechanism to inform the client and must instead wait to receive a request for the resource from the client."
I bet Google's servers will know the client needs ads. Ad-blocking will not be as easy.
We use HTTP servers to pass assets in the virtual world protocols and this sounds like something we did (but expanded in the TCP layers) to combine bidirectional ReSTful connections. SPDY doesn't combine the content, yet everything else we had in mine appears done. This work was described in IETF WGs, so given NOTE WELL I hope we inspired this kind of work for wider deployment!
The reverse connection to the client without an immediate request previously is key! SPDY obviously retains some credentials and that makes it a little more trivial behind firewalls.
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
...and it wants IE5 back. Y'know, that One Cool Browser With All Those Nifty Markup And Protocol Extensions.
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!
I mean if someone cared about page load times, they would be using Opera, the ONLY browser to fully support and have enabled HTTP 1.1 pipelining, which provides FAR better results across FAR more sites...
The only difference of course, is Opera ASA don't have the bottomless pits of money to tell the wider world about these things. I find it curious that it's Chrome this, chrome that, nobody is talking about the MASSIVE bandwidth savings that Opera 11.10 is getting using WebP server transcoding...
http://my.opera.com/chooseopera/blog/on-a-horse-opera-turbo-to-the-rescue
12MB of browsing slashed to 3MB....
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
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.
"Her favorite color"? IS CHROME: http://www.youtube.com/watch?v=EmAAaXI8riY
Trace Adkins does an excellent job of describing the surfing experience using Google Chrome, w/ this lyric excerpt:
"Zippin' by, on an electric glide, w/ DUAL TAIL PIPES, doin' 105 on a 2 lane... (headin' outta town...")
(Google's become the "New York Yankees" (or Dallas Cowboys of the 1970's-1980's) with TONS OF CA$H, to hire on the best they can find... & the results in this browser? Well worth it...)
APK
P.S.=> Yes - I like it, & even though I am more of an Opera 11.x fan, I have to admit that Google's Chrome (moreso the project it comes from, Chromium) is F A S T!
It just works well too, & compatible as heck with most all websites out there...
Plus, Chrome shows NO ZERO KNOWN SECURITY VULNERABILITIES UNPATCHED (especially on today's "Wild West" internet):
---
Vulnerability Report: Google Chrome 10.x
http://secunia.com/advisories/product/34532/?task=advisories
Unpatched 0% (0 of 3 Secunia advisories)
---
Imo @ least? That's a mixture of both SPEED, COMPATIBILITY, & SECURITY that's tough to beat...
Of course, Opera's plenty fast too & has been called "the world's fastest browser" for decades now, & IE9's no slouch lately either, & both of those (and FireFox) are ALL @ ZERO KNOWN UNPATCHED SECURITY VULNERABILIES (& for months now... about time!)... apk
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.
Instead of requesting each item individually, why doesn't the brower request an item list for the page, compare it to the cache, return the list of items required, then have the server send all items in a single sequential stream?
You would have a point if Google would have announced that Honeycomb won't be open source. As far as I know, they still intend it to be but have delayed that a bit. I don't have any reason to assume malice here, at least not yet.
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
"Ever since I've installed a host file (http://www.mvps.org/winhelp2002/hosts.htm) to redirect advertisers to my loopback, I haven't had any malware, spyware, or adware issues. I first started using the host file 5 years ago." - by TestedDoughnut (1324447) on Monday December 13, @12:18AM (#34532122)
FROM http://tech.slashdot.org/comments.pl?sid=1907528&cid=34532122
Now?
20++ ADVANTAGES OF HOSTS FILES OVER DNS SERVERS &/or ADBLOCK ALONE for added layered security:
1.) HOSTS files are useable for all these purposes because they are present on all Operating Systems that have a BSD based IP stack (even ANDROID) and do adblocking for ANY webbrowser, email program, etc. (any webbound program).
2.) Bad news: ADBLOCK CAN BE DETECTED FOR: See here on that note -> http://arstechnica.com/business/news/2010/03/why-ad-blocking-is-devastating-to-the-sites-you-love.ars
HOSTS files are NOT BLOCKABLE by websites, as was tried on users by ARSTECHNICA (and it worked, proving HOSTS files are a better solution for this because they cannot be blocked & detected for, in that manner), to that websites' users' dismay:
PERTINENT QUOTE/EXCERPT FROM ARSTECHNICA THEMSELVES:
----
An experiment gone wrong - By Ken Fisher | Last updated March 6, 2010 11:11 AM
http://arstechnica.com/business/news/2010/03/why-ad-blocking-is-devastating-to-the-sites-you-love.ars
"Starting late Friday afternoon we conducted a 12 hour experiment to see if it would be possible to simply make content disappear for visitors who were using a very popular ad blocking tool. Technologically, it was a success in that it worked. Ad blockers, and only ad blockers, couldn't see our content."
and
"Our experiment is over, and we're glad we did it because it led to us learning that we needed to communicate our point of view every once in a while. Sure, some people told us we deserved to die in a fire. But that's the Internet!"
Thus, as you can see? Well - THAT all "went over like a lead balloon" with their users in other words, because Arstechnica was forced to change it back to the old way where ADBLOCK still could work to do its job (REDDIT however, has not, for example). However/Again - this is proof that HOSTS files can still do the job, blocking potentially malscripted ads (or ads in general because they slow you down) vs. adblockers like ADBLOCK!
----
3.) Adblock doesn't protect email programs external to FF, Hosts files do. THIS IS GOOD VS. SPAM MAIL or MAILS THAT BEAR MALICIOUS SCRIPT, or, THAT POINT TO MALICIOUS SCRIPT VIA URLS etc.
4.) Adblock won't get you to your favorite sites if a DNS server goes down or is DNS-poisoned, hosts will (this leads to points 4-7 next below).
5.) Adblock doesn't allow you to hardcode in your favorite websites into it so you don't make DNS server calls and so you can avoid tracking by DNS request logs, hosts do (DNS servers are also being abused by the Chinese lately and by the Kaminsky flaw -> http://www.networkworld.com/news/2008/082908-kaminsky-flaw-prompts-dns-server.html for years now). Hosts protect against those problems via hardcodes of your fav sites (you should verify against the TLD that does nothing but cache IPAddress-to-domainname/hostname resolutions via NSLOOKUP, PINGS, &/or WHOIS though, regularly, so you have the correct IP & it's current)).
6.) HOSTS files protect you vs. DNS-poisoning &/or the Kaminsky flaw in DNS servers, and allow you to get to sites reliably vs
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
That you're a FUCKTARD, Josh?
Spoke TOO soon, I guess, because TODAY (the next day after my post to you all), GOOGLE CHROME 10.x turned up a "bug"... talk about "ironic", lol!
Anyhow/anyways: So, here 'tis (per my subject-line) again, for your reference:
---
Vulnerability Report: Google Chrome 10.x
http://secunia.com/advisories/product/34532/?task=advisories
Unpatched 25% (1 of 4 Secunia advisories)
---
There you go...
Nice part is though, that the LAST TIME this happened?
Chromium's team FIXED IT THE SAME DAY (not too long back no less)...
APK
P.S.=> "Onwards, & UPWARDS!"... apk
See subject-line (just posting this for "posterities' sake" is all).
APK