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.

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.

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.

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.

[1] http://www.webpagetest.org/result/120528_SJ_E14/

EDIT - Sent em a tweet. Lets see what happens

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.

Similar Technique...Like what?

Downvotes were probably due to those two things "Not really providing a useful answer" (sorry if that comment offends. Just my opinion).

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

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!

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.

[1] http://www.createopen.com/blog/2012/05/taking-responsive-des...

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.

As others have mentioned, the trick is using tools appropriately. But first you need to know for what use cases you are designing.

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.

Maybe a new content type would work... "text/html" would be the application and "text/static-html" would be "just the content"? Browsers would then just have a toggle option of some sort.

This whole thing seems like a Macromedia redux of sorts. Web devs suddenly have a bunch of new tools to play with and some of them go nuts and do stupid things we'll all laugh about in 5-10 years. Of course in 5-10 years there will be something else for short-sighted marketers to abuse...

Also, what's wrong with HTML/CSS that is in any way resolved by XML/XSLT? I'm genuinely curious why somebody would put their content into a format with no default, well-understood display semantics.

and the client could use the default xslt if they were happy with that, and a custom otherwise.

What happened to graceful degradation? Is it not agile enough to expect a server to be able to work at least minimally with any browser?

Online stores show so little of what they're actually selling - we wanted to try stripping out everything that isn't the products. (using shoes from Amazon as the example here)

That is presumptuous: Most users have zero choice in the matter.

I think you're confused and you aren't really keeping up with the conversation.

Now some might say that good web design was violated by make the site dependant on JS. However, as the title shows, this is 2012. My cellphone has the ability to render most JS effectively. The old adage about degrading JS is just that, old. It was in a day before ECMA Script was sanctioned or common on the browsers. It was before jQuery and the like unified the browsers.

tl;dr: JS is ubiquitous and is what the front end, and even the whole app is built on.

I just tried with Links 2.6 and it worked fine on StackOverflow.com.

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.

I don't expect good design from bloggers. If they say smart things, I'll read. I expect good design from people who theoretically want my money, because it's their job not to irritate me when I'm trying to pay them.

I've avoided buying products from companies who make terrible design decisions. Not even to punish them, just to avoid having to deal with the pre-product bullshit.

So never expect good skype experience or any real-time services like - Live search on 3G networks.

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)

It's pretty image-heavy, for sure, but that's to be expected when how else are you supposed to look at shoes?

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.

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.

Region blocking applies to shoes?

(Looks like the website's database connection has maxed out)

[1] http://mozilla.github.com/pdf.js/

I'm not sure what your comment has added to the debate.

You're entitled to your opinion. But if your job is to make websites you shouldn't need a random post on a random blog to think about page weight...?

You buy $100 shoes because of style and brand. And this price tag does not always mean quality. There are plenty of expensive brands that fall apart under everyday usage.

It's a little like advertising perhaps. Advertising has become more of an art form than a tool. Awards given for achievement in creating ads are based on the perceived artistic value of an ad, not on its market effectiveness.

Web development is viewed as an art form by web developers. The web is not a tool to them. It's a canvas.

But the reality is that for many users in many cases, the web is a tool. They just want to accomplish some task, and they are not going to pay attention to artistic value.

Maybe a good example is Amazon. Many web developers criticise the site's design. But Amazon is doing just fine. Because users do not visit Amazon for an "experience". They visit it to buy things.

Maybe there should be two versions of every website: 1. an artisitic one aimed at "user experience" where the developer could display their design skills and 2. another aimed at getting some task(s) done, quickly and efficiently. The latter might follow some universal standard. No thinking involved in its "design", just following a spec.

The user could choose. The problem for the author of this blog post was she had no choice.

No way. It's marketing people who are responsible. Obvious example: http://www.dustincurtis.com/dear_dustin_curtis.html

At the level that Camper (or Amazon) is operating on, the marketing department holds all the cards when it comes to the web site. The web devs mostly decide how to implement, but they're operating at the behest of marketing.

If not, how can they even know what is possible to create using HTML, CSS, etc.?

If the answer is "they look at what the competition is doing," then how did the marketers at the competitor know what is possible?

It has to start somewhere. Who was behind the web back in 1993? Marketing departments? Are marketers the ones who know what can be done with HTML, etc., and what cannot?

If a marketing department asks a web developer to implement something that the developer knows will be an annoyance to end users, and then he decides to tell them it is not possible, does the marketing department not accept this answer? "Look, we know how to make websites, we know this can be done and we'd do it ourselves if we had the time, but we're busy doing marketing. Either you do your job and build this site as we ask, or we'll find someone else."

So, at some stage, some web developer somewhere makes a decision.

I remember reading the confession of a talented developer who wrote, using mini scheme, stealth malware to serve pop-ups. His skills were so good that he could disable all competing malware; the competition was helpless. The NY Attorney General later shut down his employer on consumer protection grounds. The developer was not typically an author of malware, and knew what he was doing was wrong, but his excuse for working with this outfit was that he needed a job.

Without that developer making a choice, the malware company would never have known it was possible to do what they were able to do with the help of this particular talented developer. The use of mini scheme, self modifying code and disabling all competing malware were not in his "job description". He showed them what was possible. And surely they loved him for it. But how about the users infected with the malware, who had to see his employer's pop-ups every day with no way to "turn it off"? What would they think of his work?

Just something to think about.

Anything is possible. It doesn't mean a particular idea is good (see: the topic website), but anything is certainly possible.

> It has to start somewhere. Who was behind the web back in 1993? Marketing departments?

For big companies? Yes.

> Are marketers the ones who know what can be done with HTML, etc., and what cannot?

Implementation is beside the point. Even if the Camper "experience" in the original link loaded quickly and was implemented perfectly, it would be bad.

> If a marketing department asks a web developer to implement something that the developer knows will be an annoyance to end users, and then he decides to tell them it is not possible, does the marketing department not accept this answer?

This is the difference between a good marketing department and a bad one. The good ones will take the feedback and the bad ones won't. It's also the difference between a good organization and a bad one -- if the org makes it a habit not to talk to engineers until the idea has gone through revision after revision, UX, etc, then there's too much inertia to overcome (say, 3 months of designing, UX development, intended to be launched in tandem with a meatspace campaign, as an example).

For giant companies, the web site is a piece of their action, and often times not the largest piece. The web team (the ones who implement) are pinned to the timelines of other rollouts (in-store campaigns, billboards, magazine ads, tv ads, and so forth). So while a certain idea might not be best, there may not be time to change it -- or (consider this) the web experience might not be the most important to a company that does 80% of their volume in meatspace.

Thinking that the web site & web team should be the gatekeepers of customer experience in a multichannel business that isn't focused online is a myopic view. In spirit I'm right there with you dude, but in practice (can you tell I've worked at giant companies?) it doesn't work that way.

I think web developers have a lot of power over how the web operates. Much more than marketing departments.

In the spirit of making money, I'm right there with you. Web developers have to eat.

But to think the matter of the web's usability, or unusability (what the blog post described), is out of their hands, and solely in the hands of marketing departments, I don't buy it. Marketing has the budget, they do not have the skills, or even the knowledge.

I see numerous examples year after year that show that both large and small companies do not have the first clue how stuff works or what the implications are on end users. Developers present them with a proposition and the company writes a check. When some egregious practice comes to the attention of the press, the companies often have no idea what they were even paying for -- they do not understand what was being done.

One need only look at SEO and the types of websites it produces. It's quite a stretch to try to hold marketing departments responsible for this state of affairs.

Google on an iPhone 3G is utter pain

Any Tiger PowerPC Mac is utterly painful because browser JS engines have got so much better that we throw way too much for older browsers to cope with at them.

Are you on a speedy networked desktop? You get the bells and whistles version. Are you own a tablet with less bandwidth? We note this, and load the appropriate version. Are you on a mobile phone on the move? We load the mobile edition which is about efficiency and speed. The user doesn't need to make decisions, but the site architect should be seamlessly making them behind the scenes.

Also, I'd love it so all versions to have the same content, optimized for all homes. If I visit another mobile/tablet site that reduces content for "my convenience" I will start punching web developers. :)