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."
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.
Yes. thedailywtf.com has such stories. I specifically remember one, where the delete button of database entries was a GET link from the list page. So Google's little spider went there, and crawled the entire list. Requested every single delete link address on the page. I think it was not even linked from anywhere. The crawler got there by reading out the referrer addresses from when the developers came to Google from a link on that site.
And if I remember correctly, it of course was a non backuped production database. The only one in fact. Must have been fun.:)
>>>Sounds like those "dialup accelerators" from back in the '90s...
Hey I still use one of those you insensitive clod! It's called Netscape Web Accelerator, and it does more than just prefetch requests - it also compresses all text and images to about 10% original size. How else would I watch 90210 streaming videos over my phoneline?
Why I can almost see what looks like a bikini. Man Kelly is hot...;-)
Most of the features of fasterfox are found in about:config. There is no sense in installing an addon that will slow the browser down when the browser already has pipelining and prefetching (albeit disabled)
Ye are joking, but ye are correct. Take this slashdot page. I used to be able to participate in discussion forum with nothing more than a 1200 baud (1kbit/s) modem. If I tried that today, even with all images turned off, it would take 45 minutes to load this page, mainly due to the enormous CSS files
It would be nice if websites made at least *some* attempt to make their files smaller, and therefore load faster.
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.
by Anonymous Coward
on Thursday November 12, @03:08PM (#30078010)
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!
And all other "add this piece of Javascript to your Web page and make it more awesomer!"
Yes, yes, they're useful. And you can't fathom a future without them. But in the meantime I'm watching my status bar say, "completed 4 of 5 items", then change to "completed 11 of 27 items", to "completed 18 of 57 items", to "completed... oh screw this, you're downloading the whole Internet, just sit back, relax and watch the blinkenlights".
Remember when a 768kbps DSL line was whizzo fast? Because all it had to download was some simple HTML, maybe some gifs?
And all other "add this piece of Javascript to your Web page and make it more awesomer!"
Yes, yes, they're useful. And you can't fathom a future without them. But in the meantime I'm watching my status bar say, "completed 4 of 5 items", then change to "completed 11 of 27 items", to "completed 18 of 57 items", to "completed... oh screw this, you're downloading the whole Internet, just sit back, relax and watch the blinkenlights".
Remember when a 768kbps DSL line was whizzo fast? Because all it had to download was some simple HTML, maybe some gifs?
I want my old Internet back. And a pony.
That's why smart web developers put those scripts at the end of the body.
That's why smart web developers put those scripts at the end of the body.
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 a
That's why smart web developers put those scripts at the end of the body.
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.
Adsense is embedded where the ads are going to be, Google Maps scripts are embedded where the map is going to be, etc.
This doesn't have to be the case, unless you're still coding per 1997 standards. Even with CSS 1, you can put those DIVs last in the code and still place them wherever you want them to be.
It's what I do with the Google ads (text only ads, FWIW) on one of my personal sites - so the content loads first, and then the ads show up.
LOL. I'd suggest disabling javascript and calling it a day.
Alternatively, use a text-based browser. If the webpage has any content worth reading, then a simple lynx -dump in 99% of cases will give you what you want, with the added bonus of re-formatting those mile-wide lines into something readable.
On the other hand, I suspect most people don't want the "old internet". What was once communicated on usenet or email in a few simple lines, for example, now increasingl
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.
CSS can make things shorter and faster if they just remember to link to it as a static file.
You can't cache something that changes, and anything, like CSS and Javascript, that's caught in the on-the-fly generation of dynamic and uncacheable text in spite of actually being static, is just going to clog up the tubes.
In fact, thanks to slashdot's no-edits-allowed policy, each comment itself is a static unchangeable snippet of text. Why not cache those?
Sending only the stuff that changes is usually a good optimization no matter what you're doing.
CSS and javascript themselves aren't bad. Failing to offlink and thus cacheable-ize them however, is.
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.
Right now the plan is to use port 443. We may as well make the web a safer place while we make it faster. The plans for indicating how a client/server speaks SPDY is still somewhat up in the air.... what we have planned right now, is: UPGRADE (ye olde HTTP UPGRADE). and, putting some string into the SSL handshake that allows both sides to advertise which protocols they speak. If both speak SPDY, then it can be used. This is nice because you don't have the additional latency of an additional roundtrip (and that latency can be large!)
AOL actually does something similar to this with their TopSpeed technology, and it does work very, very well. It has introduced features like multiplexed persistent connections to the intermediary layer, sending down just object deltas since last visit (for if-modified-since requests), and applying gzip compression to uncompressed objects on the wire. It's one of the best technologies they've introduced. And, in full disclosure, I was proud to be a part of the team that made it all possible. It's too bad all of this is specific to the AOL software, so I'm glad a name like Google is trying to open up these kind of features to the general internet.
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.
e 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.
The problem is that worrying about semantic vs presentation is something that almost no one gives a s**t about, because it is an artificial division that makes sense for computer science reasons, not human reasons. I don't sit down to make a web page and completely divorce the content vs the layout; the layout gives context and can be just as important as the content itself in terms of a human brain grasping an attempt at communication.
I know I shouldn't use tables for presentation but I just don't care. They are so simple and easy to visualize in my head, and using them has never caused a noticeable slowdown in my app, caused maintenance headaches, cost me any money, etc. The only downside is listening to architecture astronauts whine about how incorrect it is while they all sit around and circle-jerk about how their pages pass this-or-that validation test.
In oh so many ways writing a web app is like stepping back into computer GUI v1.0; so much must be manually re-implemented in a different way for every app. Heck, you can't even reliably get the dimensions of an element or the currently computed styles on an element. Lest you think this is mostly IE-vs-everyone else, no browser can define a content region that automatically scrolls its contents within a defined percentage of the parent element's content region; you've gotta emit javascript to dynamically calculate the size. This is double-stupid because browsers already perform this sort of layout logic for things like a textarea that has content that exceeds its bounds. And guess what? This is one of the #1 reasons people want to use overflow:auto. Don't waste screen real-estate showing scrollbars if they aren't necessary, but don't force me to hard-code height and width because then I can't scale to the user's screen resolution.
This kind of crap is so frustrating and wastes MILLIONS upon MILLIONS of man-hours year after year, yet we can't even get the major browser vendors to agree to HTMLv5 and what little bits (though very useful) it brings to the table. So please spare me the semantic vs presentation argument. If just a few people gave a s**t and stopped stroking their own egos on these bulls**t committees and actually tried to solve the problems that developers and designers deal with every day then they wouldn't have to worry about forcing everyone to adopt their standard (IPv6), the desire to adopt it would come naturally.
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.
HTTP-NG ( http://www.w3.org/Protocols/HTTP-NG/ [w3.org] ) was researched, designed, and even, yes, implemented to solve the same problems that Google's "new" SPDY is attacking -- in 1999, ten years ago.
The good news is that SPDY seems to build on the SMUX ( http://www.w3.org/TR/WD-mux [w3.org] ) and MUX protocols that were designed as part of the HTTP-NG effort, so at least we're not reinventing the wheel. Now we have to decide what color to paint it.
Next up: immediate support in FireFox, WebKit, and Apache -- and deafening silence from IE and IIS.
No. Akamai gives boxes to ISPs that cache Akamai's customer's content closer to the ISP's customers. Akamai then uses logic they've put together into DNS to redirect requests to the appliance closest to the request.
No. Akamai offers many services and features beyond 'giving' boxes to ISPs. For instance, they have their own global CDN unrelated to any ISP which you can pay to have your content served across. They'll host it or reverse proxy/cache it. They also can multicast live streaming media, on demand streaming media, etc. You get the picture. In once sentence, Akamai is a high availability, high capacity provider of bandwidth. And they accomplish that in a variety of ways other than just putting boxes in ISPs.
>>>Gopher predates HTTP by a fair number of years.
Not correct. Gopher and HTTP were both released in summer 1991, so virtually the same birthdate. However gopher was available on the IBM PC that same year while HTTP was still confined to Unix systems, so that's why people misremember gopher as being first. (HTTP came to IBM PC, Macs, and Amigas in 1993.)
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.
Most cache programs just straight up ignore this. Because of the '?' in there. It ends up being a query to static data.
Then never mind the load balancing bits they put in there with 'v9.lscache4.c.'. So even IF you get your cache to keep the data you may end up with a totally different server and the same piece of data just served from another server. There have been a few hacks to 'rewrite' the headers and the names to make it stick. But those are just hacks and while they work they seem fragile.
The real issue is at the HTTP layer and how servers are pointed at from inside the 'code'. So instead of some sort of indirection that would make it simple for the client to say 'these 20 servers have the same bit of data' they must assume that the data is different from every server.
Compression and javascript speedups are all well and good but there is a different more fundamental problem of extra reload of data that has already been retrieved. As local network usage is almost always faster than going back out to the internet. In a single user environment this is not too big of a deal. But in a 10+ user environment it is a MUCH bigger deal.
Even the page that talks about optimization has issues http://code.google.com/speed/articles/ [google.com] 12 cr/lf right at the top of the page that are not rendered anywhere. They should look at themselves first.
I strongly suspect that whether or not HTTP is "broken" is largely a matter of perspective. For classic website serving, HTTP works pretty well. Not perfectly; but easily well enough that it isn't worth replacing.
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 connecti
Oh that's wonderful (Score:5, Funny)
Now we can see Uncle Goatse twice as fast.
Re:Oh that's wonderful (Score:5, Funny)
I want my old Internet back.
ME TOO!
Parent
Re:Oh that's wonderful (Score:4, Interesting)
Parent
Re:Oh that's wonderful (Score:5, Funny)
Just over 2 hours.
Parent
Re:Is he your biological uncle? (Score:4, Funny)
oldermanwholikestofondleyou.cx
To follow the goatse.cx standard, I believe it should be http://oldermanwholikestofondleyour.co.ck
It's only $250 to register a .co.ck address!
Parent
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.
Parent
Re:Oh that's wonderful (Score:5, Insightful)
Parent
Before you click! (Score:4, Funny)
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:
Parent
Re:Before you click! (Score:4, Informative)
Yes. thedailywtf.com has such stories. I specifically remember one, where the delete button of database entries was a GET link from the list page. So Google's little spider went there, and crawled the entire list. Requested every single delete link address on the page. I think it was not even linked from anywhere. The crawler got there by reading out the referrer addresses from when the developers came to Google from a link on that site.
And if I remember correctly, it of course was a non backuped production database. The only one in fact. Must have been fun. :)
Parent
Re:Before you click! (Score:5, Funny)
>>>Sounds like those "dialup accelerators" from back in the '90s ...
Hey I still use one of those you insensitive clod! It's called Netscape Web Accelerator, and it does more than just prefetch requests - it also compresses all text and images to about 10% original size. How else would I watch 90210 streaming videos over my phoneline?
Why I can almost see what looks like a bikini. Man Kelly is hot... ;-)
Parent
addin not needed (Score:4, Informative)
Parent
and faster still.. (Score:4, Insightful)
remove flash, java applets ad's
20X faster!
Re:and faster still.. (Score:4, Funny)
You could also remove images, CSS, Javascript, and text, imagine the time savings!
Parent
Re:and faster still.. (Score:5, Funny)
Remove the content too. It's all meaningless stuff like this post.
Parent
Re:and faster still.. (Score:5, Insightful)
Ye are joking, but ye are correct. Take this slashdot page. I used to be able to participate in discussion forum with nothing more than a 1200 baud (1kbit/s) modem. If I tried that today, even with all images turned off, it would take 45 minutes to load this page, mainly due to the enormous CSS files
It would be nice if websites made at least *some* attempt to make their files smaller, and therefore load faster.
Parent
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.
Parent
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!
How about telling Analytics to take a hike? (Score:5, Insightful)
And all other "add this piece of Javascript to your Web page and make it more awesomer!"
Yes, yes, they're useful. And you can't fathom a future without them. But in the meantime I'm watching my status bar say, "completed 4 of 5 items", then change to "completed 11 of 27 items", to "completed 18 of 57 items", to "completed... oh screw this, you're downloading the whole Internet, just sit back, relax and watch the blinkenlights".
Remember when a 768kbps DSL line was whizzo fast? Because all it had to download was some simple HTML, maybe some gifs?
I want my old Internet back. And a pony.
Re:How about telling Analytics to take a hike? (Score:5, Funny)
And all other "add this piece of Javascript to your Web page and make it more awesomer!"
Yes, yes, they're useful. And you can't fathom a future without them. But in the meantime I'm watching my status bar say, "completed 4 of 5 items", then change to "completed 11 of 27 items", to "completed 18 of 57 items", to "completed... oh screw this, you're downloading the whole Internet, just sit back, relax and watch the blinkenlights".
Remember when a 768kbps DSL line was whizzo fast? Because all it had to download was some simple HTML, maybe some gifs?
I want my old Internet back. And a pony.
That's why smart web developers put those scripts at the end of the body.
Parent
Re: (Score:3, Insightful)
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 a
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.
Parent
Re: (Score:3, Informative)
Adsense is embedded where the ads are going to be, Google Maps scripts are embedded where the map is going to be, etc.
This doesn't have to be the case, unless you're still coding per 1997 standards. Even with CSS 1, you can put those DIVs last in the code and still place them wherever you want them to be.
It's what I do with the Google ads (text only ads, FWIW) on one of my personal sites - so the content loads first, and then the ads show up.
Re: (Score:3, Insightful)
I want my old Internet back. And a pony.
LOL. I'd suggest disabling javascript and calling it a day.
Alternatively, use a text-based browser. If the webpage has any content worth reading, then a simple lynx -dump in 99% of cases will give you what you want, with the added bonus of re-formatting those mile-wide lines into something readable.
On the other hand, I suspect most people don't want the "old internet". What was once communicated on usenet or email in a few simple lines, for example, now increasingl
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.
Re:Solving the wrong problem (Score:5, Insightful)
IAWTP. With NoScript on and off, the web is a totally different place.
Parent
Re: (Score:3, Funny)
So if Google sped up the non-ad web, they would have more room for their ads?
SNEAKY!!
Re:Solving the wrong problem (Score:5, Funny)
I think you mean SNKY
Parent
Re:Solving the wrong problem (Score:4, Insightful)
CSS can make things shorter and faster if they just remember to link to it as a static file.
You can't cache something that changes, and anything, like CSS and Javascript, that's caught in the on-the-fly generation of dynamic and uncacheable text in spite of actually being static, is just going to clog up the tubes.
In fact, thanks to slashdot's no-edits-allowed policy, each comment itself is a static unchangeable snippet of text. Why not cache those?
Sending only the stuff that changes is usually a good optimization no matter what you're doing.
CSS and javascript themselves aren't bad. Failing to offlink and thus cacheable-ize them however, is.
Parent
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.
Cool.... but it's not http (Score:5, Insightful)
So which ports are you planning to use for it?
Re:Cool.... but it's not http (Score:5, Informative)
Right now the plan is to use port 443. We may as well make the web a safer place while we make it faster. .. what we have planned right now, is:
The plans for indicating how a client/server speaks SPDY is still somewhat up in the air..
UPGRADE (ye olde HTTP UPGRADE).
and, putting some string into the SSL handshake that allows both sides to advertise which protocols they speak. If both speak SPDY, then it can be used.
This is nice because you don't have the additional latency of an additional roundtrip (and that latency can be large!)
Parent
Not a terribly new concept. (Score:5, Informative)
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:While we're at it ... (Score:4, Insightful)
e 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.
The problem is that worrying about semantic vs presentation is something that almost no one gives a s**t about, because it is an artificial division that makes sense for computer science reasons, not human reasons. I don't sit down to make a web page and completely divorce the content vs the layout; the layout gives context and can be just as important as the content itself in terms of a human brain grasping an attempt at communication.
I know I shouldn't use tables for presentation but I just don't care. They are so simple and easy to visualize in my head, and using them has never caused a noticeable slowdown in my app, caused maintenance headaches, cost me any money, etc. The only downside is listening to architecture astronauts whine about how incorrect it is while they all sit around and circle-jerk about how their pages pass this-or-that validation test.
In oh so many ways writing a web app is like stepping back into computer GUI v1.0; so much must be manually re-implemented in a different way for every app. Heck, you can't even reliably get the dimensions of an element or the currently computed styles on an element. Lest you think this is mostly IE-vs-everyone else, no browser can define a content region that automatically scrolls its contents within a defined percentage of the parent element's content region; you've gotta emit javascript to dynamically calculate the size. This is double-stupid because browsers already perform this sort of layout logic for things like a textarea that has content that exceeds its bounds. And guess what? This is one of the #1 reasons people want to use overflow:auto. Don't waste screen real-estate showing scrollbars if they aren't necessary, but don't force me to hard-code height and width because then I can't scale to the user's screen resolution.
This kind of crap is so frustrating and wastes MILLIONS upon MILLIONS of man-hours year after year, yet we can't even get the major browser vendors to agree to HTMLv5 and what little bits (though very useful) it brings to the table. So please spare me the semantic vs presentation argument. If just a few people gave a s**t and stopped stroking their own egos on these bulls**t committees and actually tried to solve the problems that developers and designers deal with every day then they wouldn't have to worry about forcing everyone to adopt their standard (IPv6), the desire to adopt it would come naturally.
Parent
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.
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.
HTTP-NG Revisited (ten years later!) (Score:5, Informative)
The good news is that SPDY seems to build on the SMUX ( http://www.w3.org/TR/WD-mux [w3.org] ) and MUX protocols that were designed as part of the HTTP-NG effort, so at least we're not reinventing the wheel. Now we have to decide what color to paint it.
Next up: immediate support in FireFox, WebKit, and Apache -- and deafening silence from IE and IIS.
fst wb prtcl (Score:4, Funny)
If they really wanted a faster web, they would have minimized the protocol name. Taking out vowels isn't enough.
The protocol should be renamed to just 's'.
That's 3 less bytes per request.
I can haz goolge internship?
Re:Akamai? (Score:5, Informative)
Parent
Re: (Score:3, Informative)
Re: (Score:3, Funny)
You youngsters and your fancy text based web browsers. In my day, we used gopher, and we LIKED it!
Re:Just turn off image loading (Score:5, Funny)
here's an onion to hang on your belt, granpa.
now, on a more serious note, isn't gopher a faster protocol than HTTP ? could we just use it to transport html, pictures, etc ?
Parent
Re:Just turn off image loading (Score:5, Informative)
Gopher is not installed by default, kiddie...
Gopher is installed by default on most builds of Firefox. Try this in your address bar: gopher://gopher.floodgap.com/1/world [floodgap.com]
Parent
Re:Just turn off image loading (Score:4, Informative)
>>>Gopher predates HTTP by a fair number of years.
Not correct. Gopher and HTTP were both released in summer 1991, so virtually the same birthdate. However gopher was available on the IBM PC that same year while HTTP was still confined to Unix systems, so that's why people misremember gopher as being first. (HTTP came to IBM PC, Macs, and Amigas in 1993.)
Parent
Re:Just turn off image loading (Score:5, Informative)
Someone already invented this.
It's called Opera browser
Parent
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.
Re:Slashdot could use the help (Score:4, Insightful)
They need start with practicing what they preach...
http://code.google.com/speed/articles/caching.html [google.com]
http://code.google.com/speed/articles/prefetching.html [google.com]
http://code.google.com/speed/articles/optimizing-html.html [google.com]
They turn on caching for everything but then spit out junk like
http://v9.lscache4.c.youtube.com/generate_204?ip=0.0.0.0&sparams=id%2Cexpire%2Cip%2Cipbits%2Citag%2Calgorithm%2Cburst%2Cfactor&fexp=903900%2C903206&algorithm=throttle-factor&itag=34&ipbits=0&burst=40&sver=3&expire=1258081200&key=yt1&signature=8214C5787766320D138B1764BF009CF62A596FF9.D86886CFF40DB7F847246D653E9D3AA5B1D18610&factor=1.25&id=ccbfe79256f2b5b6 [youtube.com]
Most cache programs just straight up ignore this. Because of the '?' in there. It ends up being a query to static data.
Then never mind the load balancing bits they put in there with 'v9.lscache4.c.'. So even IF you get your cache to keep the data you may end up with a totally different server and the same piece of data just served from another server. There have been a few hacks to 'rewrite' the headers and the names to make it stick. But those are just hacks and while they work they seem fragile.
The real issue is at the HTTP layer and how servers are pointed at from inside the 'code'. So instead of some sort of indirection that would make it simple for the client to say 'these 20 servers have the same bit of data' they must assume that the data is different from every server.
Compression and javascript speedups are all well and good but there is a different more fundamental problem of extra reload of data that has already been retrieved. As local network usage is almost always faster than going back out to the internet. In a single user environment this is not too big of a deal. But in a 10+ user environment it is a MUCH bigger deal.
Even the page that talks about optimization has issues
http://code.google.com/speed/articles/ [google.com]
12 cr/lf right at the top of the page that are not rendered anywhere. They should look at themselves first.
Parent
Re: (Score:3, Insightful)
How is this different from Web servers that serve up gzipped pages?
Well, for one, gzipping output doesn't have any effect on latency.
Re: (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 connecti