This isn't a problem with HTML 5, it's a problem with the Camper site itself.
The Chrome developer tools show 202 HTTP requests, including tons of tiny images, and many non-minified JavaScript files. And there's only about 500k of data, so it's not really a bandwidth problem unless you're on an EDGE connection or something horrible like that.
The big bottlenecks here are round-trip latency and the maximum number of parallel requests made by the browser—if a round trip ping takes 250ms, and you can make 6 requests at a time, then it will take you a minimum of 8.4 seconds to load the page, no matter how big your pipe.
For the sake of comparison, the main Hacker News page takes 6 HTTP requests to load. A Google search results page takes 22.
Camper could fix their site by tiling all their little PNGs into a couple of large PNGs, and merging all their JS into a single file. If they got their file count under 25, they'd load quite quickly.
Yes, the site itself is immediately at fault, but the author used it as an example of her point, which is that the web in its current state is pathetic.
There are plenty of little things that can make a website faster: image sprites, minified js, etc. Why don't the tools we use automatically handle this?
Why are we so focused on creativity and customization instead of standardization and ease of building? Look at the waves of designers who are crying foul over Twitter Bootstrap and trying to convince us not to use it because they realize that the demand for their services has just been cut in half!
Why are there no tools that provide the myriad of widgets we roll by hand each time? Lists, sliders, progress bars, drop-downs, calendars, etc. Well, there are. There's GWT, there clones of it for python, there's Wicket, and more. But few people seem to use them.
There's more that can be added here, but the point is the web needs much better tools, processes, standardization, and ease of programming.
We're giving people the tools to make the web a bad experience and in general that's been the end result, though we try to avoid those websites.
Why are we so focused on creativity and customization instead of standardization and ease of building? Look at the waves of designers who are crying foul over Twitter Bootstrap and trying to convince us not to use it because they realize that the demand for their services has just been cut in half!
Well, what 'we' are you talking about? As someone who's primarily a back-end developer with some 'front-end' skills (but not necessarily design skills), I'm not at all focused on customization or creativity. Bootstrap has been fantastic, because it allows me to make decent looking sites out of the box.
If/when a project gets to the point where a) it's out of proof of concept and b) the client/team wants better visuals, then we'll bring in a designer or two, and press them to design something around the existing CSS/structure that's there (within reason).
This will piss off the UX people to no end, and in some cases, they may be right to get upset. One size does not fit all, and Bootstrap in its current form doesn't handle every situation elegantly.
What I hope to see is an evolution of Bootstrap and some similar tools crop up to address these UX/UI needs from the perspective of a web 'person' - not a designer, not a developer, but a hybrid role. A role that both understands and implements all facets of the technology (not just advises/consults, but can actually be hands on), and a role with a primary focus on the hands-on. Not photoshop/dreamweaver on one hand, and not GWT/abstractionkits on the other.
That role doesn't quite exist yet, because the tools aren't quite there yet, but as tools like Bootstrap evolve, I think we'll see this. There should be no need to 'mockup' stuff first in Photoshop if the only (or primary) end result is web, but that's still how many projects work.
This is a very good point. Perhaps it is time to think about what a modern web truly should be.
The web has many things going for it. It's no mystery why it's so popular. It's the leading platform to share information and media with the world. It is also a platform for apps that have a unique and very powerful advantage: you can just link to an app and you can use it just a couple seconds later, everything is automatically saved and loadable from any web-connected device, and if you don't want to use it again you can simply forget about it. This is a much nicer experience compared to manually downloading and installing/extracting an app.
However, the web has many serious problems. The web originated in the early 90s as a way to browse text and images, and new things have been haphazardly stacked on top of that over time, resulting in what we have today. It is a lot trickier to make dynamic content for the web than it should be. Due to the limitations of JavaScript, its web API and the web overall, anything scripted for the web browser feels like it's a flimsy hack. People have made much software to try to make things more sane--jQuery, CoffeeScript, GWT, etc.--but they can't solve the deep architectural problems that the platform faces. The time we could be spending focusing on making cool things is lost trying to wrestle with web browsers to get them to do what we want them to do. That's a huge loss in productivity.
We would all benefit if we redesigned the web from the ground-up.
Exactly right. The number of HTTP requests is ridiculous on this site. Check out the waterfall view on WebPageTest[1]; even though the files are all small, it's another connection for every single one. As ekidd said, CSS spritesheets and combining js/css is the answer.
Out of curiosity, has anyone reached out to camper and told them? It would be interesting to see if a dialogue can be started with the company to see how they would react.
IE users should already be used to lack of rounded corners, full page reloads for address changes, and more things as IE's release policy causes it to fall further behind the web. Not letting them do something else won't change their already poor experience.
IE and Safari (Vast majority of desktop computers and a good chunk of macs and IOS devices) don't...
...In fact, I have just re-read your original comment and noticed the "various parties" bit which my brain skipped over before.
My previous belief was that you were saying they should just switch the site to SPDY right now and screw anyone who doesn't support it right this moment which is obviously unworkable.
But since that doesn7t appear to be the case, i have no idea why downvotes were done (unless they made the same mistake I did).
If you want 100% support; just wait for the IETF to finish HTTP/2.0. It may not be the exact SPDY protocol, but it will most likely support a reasonable form of multiplexing, and I am confident all major browsers will implement it. But its probably ~2yrs away.
The Chrome developer tools show 202 HTTP requests, including tons of tiny images, and many non-minified JavaScript files. And there's only about 500k of data, so it's not really a bandwidth problem unless you're on an EDGE connection or something horrible like that.
The big bottlenecks here are round-trip latency and the maximum number of parallel requests made by the browser—if a round trip ping takes 250ms, and you can make 6 requests at a time, then it will take you a minimum of 8.4 seconds to load the page, no matter how big your pipe.
For the sake of comparison, the main Hacker News page takes 6 HTTP requests to load. A Google search results page takes 22.
Camper could fix their site by tiling all their little PNGs into a couple of large PNGs, and merging all their JS into a single file. If they got their file count under 25, they'd load quite quickly.