Google has already made the fastest browser with Chrome 4 – which has the fastest JavaScript execution speed – and now it intends to speed up the web even further by changing the very protocols with which we communicate with the web.
HTTP as Google points out is rather clumsy when it comes to concurrency. Currently multiple connection need to be made, and each additional connection incurs an overhead as another connection is negotiated. Google points out further problems with the HTTP protocol:
- The communication between client and server is initiated exclusively by the client. While browsing a news site, for example, the server has no way to inform the client that a new news item is available. In websites, Ajax solves this to an extent by polling the server for updates but its inefficiency is obvious.
- HTTP headers are becoming larger as new features are added, and currently these are passed to the client uncompressed. While the size of an individual header might be quite small, as a large number of headers are transmitted, the size piles up. By compressing the data in the headers, over time, large savings can be incurred.
- Additionally, headers are quite redundant. Many headers remain throughout the communication with one website, and need not be transmitted repeatedly.
- Data compression is optional. Google believes that any data transmitted between server and client should always be compressed.
Google has designed a new protocol called SPDY (pronounced SPeeDY) with which it intends to decrease the page load times to as much as 50%. Google claims that their current draft of SPDY has already accomplished this goal.
The new protocol is implemented in a layer above HTTP, and as such no changes to the current infrastructure will be required. Additionally, SPDY will require no changes by web site authors; the only changes will be to the web servers and clients.
To accomplish all this the protocol improves on HTTP adding support for the following:
- Multiplexed requests. An unlimited number of requesters can be issues at once to the same server, over a single connection using the SPDY protocol.
- Prioritized requests. By specifying which resources are more important, the client and server can both deliver the important content first and faster while the non-essentials can come later.
- Compressed headers. Any web page today will have a significant number of linked resources in the form of JavaScript files, CSS style-sheets, images etc. Even 50 or 60 such elements in a page is no big number these days! As each resource is requested, the bandwidth used by the headers piles up. By compressing the headers great savings can be accomplished.
In addition to these improvements, SPDY also adds some entirely new features for server initiated connections. These server-initiated streams can deliver content to the user based on when the server chooses to rather than requiring the client to keep checking back. The server-initiated features are:
- Server push. A new “X-Associated-Content” header informs the client that it is receiving content before it has been asked for. Google believes that this can considerably improve user experience on their first visit to a site.
- Server hint. Instead of straightaway pushing content to the client, a new “X-Subresources” header can inform the user about resources. The header can notify the user about specific resources that it should ask for. In this case the content is not pushed to the client automatically. The client can decide on its own whether to request the specified resource(s) or not. This, Google believes, will speed up non-initial communications.
Google has tested this protocol with a modified version of Chrome which can communicate using this protocol. Their extensive tests with the top 25 websites can be seen here.
The web had to develop someday, somehow, and with a free and open entity such as a web it is sure to be difficult to take charge, yet someone has. Who else better suited to the task than Google?