HTTP Intermediary Layer From Google Could Dramatically Speed Up the Web

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."

Comments

Solving the wrong problem

[Animats]

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.

While we're at it ...

[RAMMS EIN]

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!

[wolrahnaes]

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:

Implementors should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves or others.

        In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered “safe”. This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.

        Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.

Re:Oh that's wonderful

[Anonymous Coward]

http://www.goatse.cx/

Re:and faster still..

[ProfessionalCookie]

Are you kidding? The new slashdot is way easier to participate on from dialup. The CSS file may look huge but it's a 29KB one time download.

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

[krelian]

Slasdhot should track where moderators spend their mod points. Those who spend it all on the first five posts should be disqualified from moderating.