The Altar of Shiny

Web design trends often carry hefty performance costs

Web and mobile users continue to expect faster sites and apps–especially when it comes to mobile–and this year I’d like to see people who work on the web spend more time focusing on performance as a user experience priority instead of chasing trends.

I recently ran across this article in Forbes, which lists a number of web design goals/trends that Steve Cooper is eyeing for a site redesign of online magazine Hitched. My intention is not to pick on Hitched or Cooper per se, but the list is a molotov cocktail of potential performance woes:

  • Continuous scrolling
  • Responsive design
  • Parallax sites

You can use most of those techniques without creating performance nightmares, but it is unfortunately rare. I feel like I’m living in an alternate reality where I’m hearing that users want simpler, faster sites, and yet the trends in web design are marching in the opposite direction.

Any of these approaches in Cooper’s list could backfire in terms of performance, or with user expectations–which are ultimately more important than raw performance itself. Check out this fantastic presentation from Dan McKinley at Etsy on the surprising outcome when they implemented (and then tested) continuous scrolling on their site. (To be fair, Cooper does mention performance gains that come with smaller buttons in many flat designs. But he fails to think about the far more significant performance drains from all the other techniques he’s considering.)

Tammy Everts of Radware recently posted her Top 9 list of web performance predictions for 2014, and I want to quote directly from the second item in the list:

Essentially, what’s happening is that IT is inheriting pages with performance problems caused by lack of foresight during the UX design phase, and now IT is forced to go backwards to identify and fix the problems, rather than taking a planning-first, forward-looking approach. Not only is this unfair, it’s also inefficient. Performance shouldn’t be kept in an IT silo or treated as an afterthought. It needs to be considered as an integral part of user experience design from stage one.

To this end, tomorrow we’re kicking off a series of posts on web performance aimed at web designers, written by Lara Swanson, who manages the mobile engineering team at Etsy. We start with the premise that performance is a key part of the user experience, and walk through a series of ways that web designers (and developers) can factor performance into their design workflow.

Related

Sign up for the O'Reilly Programming Newsletter to get weekly insight from industry insiders.
topic: Web Perf/Ops
  • Ben Henick

    I’ll be interested in this upcoming series, but I suspect it won’t do much to get at the actual root of the problem.

    People, even specialists who know better, have a bad habit of conflating “web design” with pixel-pushing, such that whooshy-shiny things are judged good precisely because they’re whooshy and shiny.

    At the professional end of the spectrum, the pressure toward this outcome can be filed squarely under the heading of Cool New Crap – a subject area where the first person to do it well wins, and too many of the unabashed imitators who follow likely fail to do it as well. E.g.: high-resolution displays are a boon to phones and smaller tablets, but 2160-line digital TV is pretty much overkill until further notice.

    Imagine, then, what happens when the impulse toward Cool New Crap is experienced and advocated by NON-specialists, who not only conflate web design with pixel-pushing, but also conflate Cool New Crap with the establishment of a first-mover advantage. Most of these people then realize only with difficulty (if at all) that the context of the project for which they’re responsible leaves little scope for the Cool New Crap, leaving an awful lot of sites that are needlessly resource-intensive in ways that fail to propel (or even detract) them from their business objectives.

    (Related: let’s not forget what the scramble for the first-mover advantage ultimately accomplished nearly fifteen years ago.)

    On Facebook earlier today, I put my sentiment across as follows:

    “There is an elephant in the room:

    “Project stakeholders.

    “My near-universal experience is that I give advice, the client inevitably goes ‘yeah, but’, and hilarity ensues at the expense of the site’s usability and performance (and often its TCO as well).

    “Once you compound this problem with the ‘get it done’ mentality—which leads to spaghetti code and corresponding performance hits, as we all know—and the ravages inflicted by print-trained designers who are still inexplicably being commissioned to design sites, the current state of affairs should come as no surprise.

    “…So the pitch needs to be made to the habitués of management seminars and B-schools (and the authors of the books they read), not the implementers they hire. THOSE folks will generally try to do the right thing, given adequate time, resources, and clearance.”

    • Courtney

      Thanks for the thoughtful comments, Ben. I agree that stakeholders who don’t understand the importance of these things can be a real challenge. The solution to this, IMO, is for people working with stakeholders to have concrete data at hand–Lara’s post (which I’ve now linked to from mine since the first one is live) provide links to some very useful data that I think are quite persuasive when it comes to selling people on the importance of performance on the web.

  • http://borasky-research.net/about-data-journalism-developer-studio-pricing-survey/ M. Edward (Ed) Borasky

    I’ve seen more sites slogged down by incessant yammering to social media share buttons, commenting systems and advertising tracking beacons than I have slogged down by on-site features. Install ‘Do Not Track’ and watch some major sites suddenly get a lot faster.