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.
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.
I have a good Internet connection into my home here in the United States (I telecommute from a home office) but I also have 4 kids. The older two have graduated to streaming video to their laptops, but the younger two still prefer choosing titles from Netflix.
When they're all streaming video, I find have the exact same problem on a desktop with plenty of resources. I think Stephanie's message should be applied several ways. We should degrade gently for underpowered devices like phones, but we should also be cognizant of the network capacity of the user.
Coming from the embedded systems world, I know what it is to count every clock cycle and every byte of RAM. I need to remember those techniques when I'm designing and implementing web applications. Thanks Stephanie!
Yes, Google Maps interface comes to mind every time I get reminded about this issue: "Still loading? Use the basic HTML version or click here for help"
Although I wonder if this really is the best solution.
Problems:
User has to explicitly select a change.
Once you change it might go faster, but it's no guarantee and makes you wait a longer total time to get to the first complete view.
Benefits:
It does not depend on directly measuring bandwidth (wasteful and still would take longer)
Relays information about the problem to the user and not just a bad experience.
Although, short of dynamic loading of less intensive interfaces until it ends up rendering a "basic HTML" view, I fail to see one. I haven't seen this implemented though.
I wrote a bit about this [1]. The basic idea is that CSS media queries, which currently just let us know about screen sizes, should also give us otherwise information like network latency and CPU
I agree with her. I don't go to most sites to have some 'experience', rather I am there to find certain pieces of information or to use a service. Any technology that hinders me in the pursuit of that purpose, flash intro videos being the typical example, is frustrating and annoying.
If the technology is super cool I might play with it for a while, but in the end I am skipping through trying to find what I came for originally.
This particular example annoyed me - I found it glitchy and there was no compelling reason for me to want to look at it. I had no reason to visit the site in the first place, so perhaps my opinion is not that important.
On the other hand, the designers may have done lots of testing, and determined that this design is the one which results in the most sales (or whatever). In any case, technology should never be a substitute for good user experience, not even flashy html5.
This is the most important point: what is the site trying to accomplish? Or better, what are users trying to accomplish with the site? Presumably, the site is trying to sell shoes, and creating an "experience" around those sales might be crucial for Camper. On the other hand, such an experience may be (as in this case) an impediment.
As others have mentioned, the trick is using tools appropriately. But first you need to know for what use cases you are designing.
I know this will never happen, but how great would it be if we saw a revival of Gopher for this very reason? HTML is clearly going to be for applications in the future, so Gopher could fill in the hole of "just show me the content". Again, won't happen. But I can dream. If only there were a 0-click way to convert a html site to a gophermap/text files.
If you want that, you can just fire up links/elinks/lynx; it, surprisingly, works fairly well even today.
But even the writer of the article didn't want to just see the text - she wants to see the shoes and decide which one to buy. You don't want to see a table with shoes numbers, descriptions and prices when you are shopping; visuals are important, too.
That's why noone is actually using text-only browsers.
I think the real issue here is a lack of graceful degradation on the Camper website. Built the right way, their fancy paper.js presentation thing would source whatever content it needs from within the page itself. The only excuse is laziness coupled with an unhealthy infatuation with new shiny technologies. I guess there are some bored people behind this who think anything, even a shoe catalogue, can be revolutionised. And that's fine, but they forgot about the core fundamentals of the web -- the kind I can rely on when loading up lynx and firing off a GET request to see some ... content.
using a text browser at all feels quite pointless these days, as much as I like them. Even programming website (case in point stack overflow) just don't work at all without javascript and images.
I also find it odd that the masthead for the blog is a 737KB PNG...I don't know why you wouldn't use a JPG - at a high quality level it's virtually indistinguishable and 1/4 of the size.
It's a little pedantic, but if you're going to talk about how sites should be lightweight and then use a sizeable PNG image you're sort of opening yourself up for criticism.
HTML5 and "fast" aren't mutually exclusive. Plenty of examples where HTML5 mobile sites are plenty fast over 3G like Quora and Asana (just two that I use often).
I don't know what you mean by "fast over 3G" but over here 3G is faster than any available ADSL plan you can get. I sometimes tether to my phone to download some contents when I'm in a hurry. I'm guessing the article is talking about sub-256kbps wifi.
It's 2012, and I'm using a lousy hotel wi-fi shared by 503 guests that takes me back to 1997 connection speeds.
No wonder PDF is the solution. Sure, sites should be optimized to the fullest extent possible and probably even detect connection speeds and offer a low bandwidth version (are there libraries for this already?) when appropriate; but that's a huge amount of work (and money) for what basically are outliers (I wouldn't expect many people to browse the Campers site from a lousy wi-fi in Bangkok)
I am on unshared 12Mbps ADSL, not the fastest around but surely faster than 1997 connection speeds and my experience was similar. Around 20 seconds for the initial loading and 5-10 for each collection. I am glad I wasn't actually looking to buy shoes and just checking the times the content took to load so I wouldn't say this design example is a problem just for the outliers.
To be fair, the blogger is pointing to the Camper website "Lookbook" which in this industry is more of a "vanity" type display. It's meant to be a little creative and in this case it's extremely creative and extremely heavy.
If the author of the blog just wants to look at some shoes, then the Camper website catalog is probably where she wants to be:
I'm confident that if you looked at the Camper website daily visits a majority of browsing/shopping (90%+) will be taking place through the Catalog and not through the Lookbook.
If you take a minute to view the homepage HTML you'll notice that there is only 2 links through to the Lookbook and that is only accessible after hitting the arrow down / MENU menu item and then clicking through the SHOES menu and submenu items (which itself is a pretty unintuitive element).
The author brings up some good points about the Lookbook, but we shouldn't pretend that the website is using it as its main interface to the products.
I don't know if the camper website is differentiated by region, or if I'm looking at a totally different website (http://www.camper.com ?) but I'm not seeing what she's seeing at all. I see a pretty standard e-commerce website with no "loadings" at all.
It's pretty image-heavy, for sure, but that's to be expected when how else are you supposed to look at shoes?
> I saw some nice shoes today at the mall and want to know if they’re available back home (because i’ve learned from experience that region-blocking also applies to shoes).
There's really no reason for that camper app to load so slowly. Rendering the initial screen then loading additional assets in the background with a prioritized queue could probably cut the load time by 90%.
Well, no. Of course not. It's not at all about the technical feasibility, or even the ease, of delivering content up front. The web first began with the ability to deliver content up front and it's remained a viable option all long.
The continuing problem is that people (CEOs, designers, developers, et al) get sidetracked and forget what their site is supposed to be doing. They forget what their customers or prospective customers actually want to do: get information; use a service; buy stuff.
The Camper site is, like many other sites on the web, a bit over-produced. I would much rather have a clear layout and fast loading product pages than a fancy animated-just-for-kicks "experience" that starts to annoy after the first 30 seconds.
For some reason I thought this would be about PDF parsing on the client -- actually it's just somebody complaining that some eCommerce site takes so long to load that it's faster to download and read their PDF brochure offline.
Actually, when I read the headline I thought it was going to be about websites who make you download PDFs to read what could easily be presented in HTML as well (restaurants always seem to have PDF menus, for example).
[+] [-] ekidd|14 years ago|reply
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.
[+] [-] heliodor|14 years ago|reply
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.
[+] [-] SquareWheel|14 years ago|reply
[1] http://www.webpagetest.org/result/120528_SJ_E14/
[+] [-] rurounijones|14 years ago|reply
EDIT - Sent em a tweet. Lets see what happens
[+] [-] huggyface|14 years ago|reply
Or the various parties could implement SPDY or a similar technique, resolving most of the issues without adding maintenance issues.
EDIT: Really? Downvotes? Some people are a little too invested in their hackish, half-measure optimizations.
[+] [-] smoyer|14 years ago|reply
When they're all streaming video, I find have the exact same problem on a desktop with plenty of resources. I think Stephanie's message should be applied several ways. We should degrade gently for underpowered devices like phones, but we should also be cognizant of the network capacity of the user.
Coming from the embedded systems world, I know what it is to count every clock cycle and every byte of RAM. I need to remember those techniques when I'm designing and implementing web applications. Thanks Stephanie!
[+] [-] koide|14 years ago|reply
Although I wonder if this really is the best solution.
Problems:
User has to explicitly select a change.
Once you change it might go faster, but it's no guarantee and makes you wait a longer total time to get to the first complete view.
Benefits:
It does not depend on directly measuring bandwidth (wasteful and still would take longer)
Relays information about the problem to the user and not just a bad experience.
Although, short of dynamic loading of less intensive interfaces until it ends up rendering a "basic HTML" view, I fail to see one. I haven't seen this implemented though.
[+] [-] dave1010uk|14 years ago|reply
[1] http://www.createopen.com/blog/2012/05/taking-responsive-des...
[+] [-] Cogito|14 years ago|reply
This particular example annoyed me - I found it glitchy and there was no compelling reason for me to want to look at it. I had no reason to visit the site in the first place, so perhaps my opinion is not that important.
On the other hand, the designers may have done lots of testing, and determined that this design is the one which results in the most sales (or whatever). In any case, technology should never be a substitute for good user experience, not even flashy html5.
[+] [-] isnotchicago|14 years ago|reply
As others have mentioned, the trick is using tools appropriately. But first you need to know for what use cases you are designing.
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] MatthewPhillips|14 years ago|reply
[+] [-] runn1ng|14 years ago|reply
If you want that, you can just fire up links/elinks/lynx; it, surprisingly, works fairly well even today.
But even the writer of the article didn't want to just see the text - she wants to see the shoes and decide which one to buy. You don't want to see a table with shoes numbers, descriptions and prices when you are shopping; visuals are important, too.
That's why noone is actually using text-only browsers.
[+] [-] adr_|14 years ago|reply
[+] [-] avirambm|14 years ago|reply
[+] [-] padolsey|14 years ago|reply
[+] [-] AndrewDucker|14 years ago|reply
[+] [-] _feda_|14 years ago|reply
[+] [-] gyaresu|14 years ago|reply
[+] [-] objclxt|14 years ago|reply
It's a little pedantic, but if you're going to talk about how sites should be lightweight and then use a sizeable PNG image you're sort of opening yourself up for criticism.
[+] [-] dlokshin|14 years ago|reply
[+] [-] leviathan|14 years ago|reply
[+] [-] koide|14 years ago|reply
No wonder PDF is the solution. Sure, sites should be optimized to the fullest extent possible and probably even detect connection speeds and offer a low bandwidth version (are there libraries for this already?) when appropriate; but that's a huge amount of work (and money) for what basically are outliers (I wouldn't expect many people to browse the Campers site from a lousy wi-fi in Bangkok)
[+] [-] joliveira|14 years ago|reply
[+] [-] ereckers|14 years ago|reply
If the author of the blog just wants to look at some shoes, then the Camper website catalog is probably where she wants to be:
http://www.camper.com/en/eshop/productos.xhtml?type=W
I'm confident that if you looked at the Camper website daily visits a majority of browsing/shopping (90%+) will be taking place through the Catalog and not through the Lookbook.
If you take a minute to view the homepage HTML you'll notice that there is only 2 links through to the Lookbook and that is only accessible after hitting the arrow down / MENU menu item and then clicking through the SHOES menu and submenu items (which itself is a pretty unintuitive element).
The author brings up some good points about the Lookbook, but we shouldn't pretend that the website is using it as its main interface to the products.
[+] [-] codeka|14 years ago|reply
It's pretty image-heavy, for sure, but that's to be expected when how else are you supposed to look at shoes?
[+] [-] phylofx|14 years ago|reply
[+] [-] simonbrown|14 years ago|reply
Region blocking applies to shoes?
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] danenania|14 years ago|reply
[+] [-] dwc|14 years ago|reply
Well, no. Of course not. It's not at all about the technical feasibility, or even the ease, of delivering content up front. The web first began with the ability to deliver content up front and it's remained a viable option all long.
The continuing problem is that people (CEOs, designers, developers, et al) get sidetracked and forget what their site is supposed to be doing. They forget what their customers or prospective customers actually want to do: get information; use a service; buy stuff.
[+] [-] munimkazia|14 years ago|reply
(Looks like the website's database connection has maxed out)
[+] [-] chucknelson|14 years ago|reply
[+] [-] TomGullen|14 years ago|reply
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] bambax|14 years ago|reply
Who cares?
[+] [-] codeka|14 years ago|reply
[+] [-] lunarscape|14 years ago|reply
[1] http://mozilla.github.com/pdf.js/
[+] [-] andybak|14 years ago|reply
I'm not sure what your comment has added to the debate.
[+] [-] robmcm|14 years ago|reply
[+] [-] dlitz|14 years ago|reply