HTTP Intermediary Layer From Google Could Dramatically Speed Up the Web 406
grmoc writes "As part of the 'Let's make the web faster' initiative, we (a few engineers — including me! — at Google, and hopefully people all across the community soon!) are experimenting with alternative protocols to help reduce the latency of Web pages. One of these experiments is SPDY (pronounced 'SPeeDY'), an application-layer protocol (essentially a shim between HTTP and the bits on the wire) for transporting content over the web, designed specifically for minimal latency. In addition to a rough specification for the protocol, we have hacked SPDY into the Google Chrome browser (because it's what we're familiar with) and a simple server testbed. Using these hacked up bits, we compared the performance of many of the top 25 and top 300 websites over both HTTP and SPDY, and have observed those pages load, on average, about twice as fast using SPDY. Thats not bad! We hope to engage the open source community to contribute ideas, feedback, code (we've open sourced the protocol, etc!), and test results."
Suspicious.... (Score:3, Interesting)
From the link
We downloaded 25 of the "top 100" websites over simulated home network connections, with 1% packet loss. We ran the downloads 10 times for each site, and calculated the average page load time for each site, and across all sites. The results show a speedup over HTTP of 27% - 60% in page load time over plain TCP (without SSL), and 39% - 55% over SSL.
1. Look at top 100 websites.
2. Choose the 25 which give you good numbers and ignore the rest.
3. PROFIT!
Solving the wrong problem (Score:5, Interesting)
The problem isn't pushing the bits across the wire. Major sites that load slowly today (like Slashdot) typically do so because they have advertising code that blocks page display until the ad loads. The ad servers are the bottleneck. Look at the lower left of the Mozilla window and watch the "Waiting for ..." messages.
Even if you're blocking ad images, there's still the delay while successive "document.write" operations take place.
Then there are the sites that load massive amounts of canned CSS and Javascript. (Remember how CSS was supposed to make web pages shorter and faster to load? NOT.)
Then there are the sites that load a skeletal page which then makes multiple requests for XML for the actual content.
Loading the base page just isn't the problem.
Application Layer... (Score:3, Interesting)
Doesn't that mean that both the client and the server have to be running this new application to see the benefits of this? Essentially either one or the other is still going to be using HTTP if you don't set it up on both, and its only as fast as the slowest piece.
While a great initiative, it could be a while before it actually takes off. To get the rest of the world running on a new protocol will take some time, and there will no doubt be some kinks to work out.
But if anyone could do it, it'd be Google.
Re:Solving the wrong problem (Score:1, Interesting)
I definitely agree on this one (who wouldn't). I'd say they clearly improve the look and feel of websites, but the simple addition of making them separate files requires a separation GET, which is far slower than consolidating. Also, a lot of sites do not compress these files (both in-transit, and simply removing whitespace from their web server versions--it's fine to keep it for your personal modification, but a compression tool should always be used on those scripts/files before putting them out for the rest of the internet to download. It has a dramatic affect on speed.
slashdot (Score:3, Interesting)
If only the Google engineers can do something about Slashdot's atrociously slow Javascript.
I've noticed a discernible difference in /. loadtime, in favor of Google Chrome vs FF 3.x on Mac OSX at home. And that's just the Chrome dev channel release. I was pleasantly surprised.
While we're at it ... (Score:5, Interesting)
While we're at it, let's also make processing web pages faster.
We have a semantic language (HTML) and a language that describes how to present that (CSS), right? This is good, let's keep it that way.
But things aren't as good as they could be. On the semantic side, we have many elements in the language that don't really convey any semantic information, and a lot of semantics there isn't an element for. On the presentation side, well, suffice it to say that there are a _lot_ of things that cannot be done, and others that can be done, but only with ugly kludges. Meanwhile, processing and rendering HTML and CSS takes a lot of resources.
Here is my proposal:
- For the semantics, let's introduce an extensible language. Imagine it as a sort of programming language, where the standard library has elements for common things like paragraphs, hyperlinks, headings, etc. and there are additional libraries which add more specialized elements, e.g. there could be a library for web fora (or blogs, if you prefer), a library for screenshot galleries, etc.
- For the presentation, let's introduce something that actually supports the features of the presentation medium. For example, for presentation on desktop operating systems, you would have support for things like buttons and checkboxes, fonts, drawing primitives, and events like keypresses and mouse clicks. Again, this should be a modular system, where you can, for example, have a library to implement the look of your website, which you can then re-use in all your pages.
- Introduce a standard for the distribution of the various modules, to facilitate re-use (no having to download a huge library on every page load).
- It could be beneficial to define both a textual, human readable form and a binary form that can be efficiently parsed by computers. Combined with a mapping between the two, you can have the best of both worlds: efficient processing by machine, and readable by humans.
- There needn't actually be separate languages for semantics, presentation and scripting; it can all be done in a single language, thus simplifying things
I'd be working on this if my job didn't take so much time and energy, but, as it is, I'm just throwing these ideas out here.
Re:Before you click! (Score:2, Interesting)
content will be loaded before you click!
Sounds like those "dialup accelerators" from back in the '90s ... the ones that would silently spider every link on the page you're currently viewing in order to build a predictive cache.
Re:Before you click! (Score:5, Interesting)
Which of course led to quite amusing results when some failure of a web developer made an app that performed actions from GET requests. I've heard anecdotes of entire databases being deleted by a web accelerator in these cases.
From RFC2616:
Re:Oh that's wonderful (Score:4, Interesting)
A novel idea (Score:4, Interesting)
How about we don't use HTTP/HTML for things they were not designed or ever intended to do? You know, that "right tool for the right job" thing.
Re:How about telling Analytics to take a hike? (Score:4, Interesting)
It's also why smart users filter them outright with something like AdBlock - anything that I see in the browser history that looks like a tracking/stats domain or URL gets blocked on sight. Come to think of it, I could probably clean it up publish it as an AdBlock filter list if anyone's interested; there's only a few dozen entries on there at the moment, but I'm sure that would grow pretty quickly if it was used by a more general and less paranoid userbase.
What's paranoid about insisting that a company bring a proposal, make me an offer, and sign a contract if they want to derive monetary value from my personal data? Instead, they feel my data is free for the taking and this entitlement mentality is the main reason why I make an effort to block all forms of tracking. I never gave consent to anyone to track anything I do, so why should I honor an agreement in which I did not participate? The "goodness" or "evil-ness" of their intentions doesn't even have to be a consideration. Sorry but referring to that as "paranoid" is either an attempt to demagogue it, or evidence that someone else's attempt to demagogue it was successful on you.
Are some people quite paranoia? Sure. Does that mean you should throw out all common sense, pretend like there are only paranoid reasons to disallow tracking, and ignore all reasonable concerns? No. Sure, someone who paints with a broad brush might notice that your actions (blocking trackers) superficially resemble some actions taken by paranoid people. Allowing that to affect your decison-making only empowers those who are superficial and quick to assume because you are kowtowing to them. This is what insecure people do. If the paranoid successfully tarnish the appearance of an otherwise reasonable action because we care too much about what others may think, it can only increase the damage caused by paranoia.
Re:Yeah, right... but WHY?!? (Score:3, Interesting)
If, though, your business model largely depends on creating webapp UIs that are good enough to compete with native local UIs, HTTP's latency and other issues are going to strike you as a fairly serious problem(particularly if the future is very likely going to involve a lot more clients connecting wirelessly via cell networks, where latency is already utter shit). Since that is pretty much exactly Google's situation, their motive seems pretty clear.
As for the "odd and immature" bit, if they had tried to roll this out as some sort of Web2.0 version of the old walled garden protocol setups(like the old "Microsoft network", before MSN became a normal ISP), then that would have been very odd and very immature. As it is, though, they've rolled out a potentially interesting project that fixes some problems that bug them under a liberal OSS licence. That seems like a fairly reasonable and inoffensive activity.
How about downsides... (Score:3, Interesting)
It's not all rosy as the short documentation page explains. While they are trying to maximize throughput and minimize latency, they are hurting other areas. 2 obvious downsides I see are:
1. Server would now have to keep holding the connection open to the client throughout the client's session, and also keep the associated resources in memory. While this may not be a problem for Google and their seemingly limitless processing powers, a Joe Webmaster will see their web server load average increase significantly. HTTP servers usually give you control over this with the HTTP keep-alive time and max connections/children settings. If the server is now required to keep the connections open it would spell more hardware for many/most websites;
2. Requiring compression seems silly to me. This would increase the processing power required on the web server (see above), and also on the client - think underpowered portable devices. It needs to stay optional - if the client and server both play and prefer compression, then they should do it; if not, then let them be; also keeping in mind that all images, video and other multimedia are already compressed - so adding compression to these items would increase the server/client load _and_ increase payload.
Re:Slashdot could use the help (Score:3, Interesting)
Re:How about telling Analytics to take a hike? (Score:3, Interesting)
Because the costs of doing so would outweigh the benefits, leading to no one agreeing to the use of their data, no ad revenue, and ultimately no professional web sites (except those that charge a fee to view). This situtation is termed a "market failure", in this case because of high transaction costs. Therefore, society standardizes the agreement to "they can use the info they get on you when you visit their page", and other people specialize in aggregating that info about you. This is similar to how Target can sell you something for a quarter and turn a profit, while even the most measily negotiated contract costs in the hundreds of dollars.
I personally block their tracking cookies, and have no moral objection to it, but you cannot reasonably assume all human interaction to be governed by explicit contracts.
Re:and faster still.. (Score:5, Interesting)
Cache headers are set to one week so unless you're clearing your cache every page load it's amounts to nothing.
If anything the scripts are bigger, but again, cached. Besides AJAX comments were a huge improvement for those of us on dialup- no more loading the whole page every time you did anything.
CSS and JS, when used correctly make things faster for users, even (and sometimes especially) for those of us on slow connections.
Re:Oh that's wonderful (Score:5, Interesting)
Slasdhot should track where moderators spend their mod points. Those who spend it all on the first five posts should be disqualified from moderating.
Re:Problems... (Score:3, Interesting)
Oh, also.. the measured in-lab 2X speedup was without any server push. Who knows, maybe the HELLO message will eventually include a flag that says that the server shouldn't push anything to the client. We're already talking about how to rate-limit anything speculative like this (so that client-requested content is almost never held up with content that is speculatively pushed).
Re:How about telling Analytics to take a hike? (Score:3, Interesting)
Instead, they feel my data is free for the taking and this entitlement mentality is the main reason why I make an effort to block all forms of tracking.
What about your sense of entitlement to get their content under your conditions?
Re:and faster still.. (Score:3, Interesting)
I think Flash should be made illegal. Yesterday I visited a website 100% made in Flash. I had to wait for it to load and then none of the links worked. Many Flash sites' links don't work in Firefox, I have no idea why. I suspect incompetent developers.
I sent a furious email to the company saying I was going to choose one of their competitors just because of the lousy website. I got a reply from their CEO basically saying "go ahead, we don't give a fuck".
Flash is like cake icing. A little bit tastes and looks great but many people find it cool to put a ton of sugar in the icing until it's nauseating.
Re:How about downsides... (Score:2, Interesting)
As a server implementor I can tell you that I'd rather have 1 heavily used connection than 20 (that is a LOW estimate for the number of connections many sites make(!!!!!!!)). Server efficiency was one of my goals for the protocol, in fact!
Average of 20 seems a lot considering most browsers cache all static content (images/HTML/Javascript/CSS/XSLT/etc.). Also, keep-alive can bring that number down to even less.
That is also a very general statement to make. Again, maybe that's true in Google's case (I don't know), but HTTP keep-alive handles this already for most cases by giving you control of how long you want keep the resources hanging around for a connection, or free them up for another client, and it's all depending on your environment.
For example, I am visiting a shopping site, blog entry, SPDY documentation page, etc., on average visitors spend X seconds/minutes on a single page on that site. With HTTP keep alive you are in charge of how soon you want to free up the server resource, and make it available for the next visitor; with a single permanent connection, you are still holding on to the resource as long as the client is still there.
Now, with say 100 visitors per 1 [time interval] starting at point N, you'll need to keep those 100 connections open until at least N+X. Now add 100 more visitors arriving at N+1, then N+2, etc. until you reach X. That's how many connections you'll need to keep open on average.
What I am saying is that number of connections is not going to be optimal in most cases. Because you'll almost always want to free up the resources way prior to the average of X. In fact, let's take some numbers:
100 clients / 1 second
X = 1 min
20 connections / client (took from your post)
Avg connection = 0.5 sec (doesn't matter as it rolls into the value of X anyway)
keep-alive = 0.5 sec (took from SPDY doc link)
With HTTP:
20 conns x 100 clients / sec = 2000 connections / sec (0.5 + 0.5)
Avg num of connections = 2000 (no keep-alive on client)
Avg num of connections = about 700 (w/keep-alive pipelining set to 4, default when enabled in Firefox)
Using SPDY:
Avg num of connections = 100 clients x 60 secs = 6000 connections
This would only make sense for low enough values of X where client needs to be getting constant dynamic updates from the server - an extremely media-heavy website maybe? It would almost have to be badly designed. I'm not sure, but it's certainly interesting. I am just wondering what testing conditions were used to achieve the results mentioned on the linked SPDY page.
When we're talking about requiring compression, we're talking about compression over the headers only.
In any case, as someone who operates servers... I can't tell you how many times I've been angry at having to turn of compression for *EVERYONE* because some browser advertises supporting compression, but doesn't (which interacts badly with caches, etc. etc).
OK my bad on that one then.
Re:Oh that's wonderful (Score:3, Interesting)
Or make it so you can only mod one comment per story.