You May Be Losing Users If Responsive Web Design Is Your Only Mobile Strategy

Advertisement

You resize the browser and a smile creeps over your face. You’re happy: You think you are now mobile-friendly, that you have achieved your goals for the website. Let me be a bit forward before getting into the discussion: You are losing users and probably money if responsive web design is your entire goal and your only solution for mobile. The good news is that you can do it right.

In this article, we’ll cover the relationship between the mobile web and responsive design, starting with how to apply responsive design intelligently, why performance is so important in mobile, why responsive design should not be your website’s goal, and ending with the performance issues of the technique to help us understand the problem.

Designers and developers have been oversimplifying the problem of mobile since 2000, and some people now think that responsive web design is the answer to all of our problems.

We need to understand that, beyond any other goal, a mobile web experience must be lightning fast. Delivering a fast, usable and compatible experience to all mobile devices has always been a challenge, and it’s no different when you are implementing a responsive technique. Embracing performance from the beginning is easier.

Responsive web design is great, but it’s not a silver bullet. If it’s your only weapon for mobile, then a performance problem might be hindering your conversion rate. Around 11% of the websites are responsive1, and the number is growing every month, so now is the time to talk about this.

According to Guy Podjarny’s research2, 72% of responsive websites deliver the same number of bytes regardless of screen size, even on slow mobile network connections. Not all users will wait for your website to load.

With just a basic understanding of the problem, we can minimize this loss.

Mobile Websites Are From the Past

I’m not saying that you should not design responsively or that you should go with an m.* subdomain. In fact, with social sharing everywhere now, assigning one URL per document, regardless of device, is smart. But this doesn’t mean that a single URL should always deliver the same document or that every device should download the same resources.

Let me quote Ethan Marcotte3, who coined the term “responsive web design”:

“Most importantly, responsive web design isn’t intended to serve as a replacement for mobile web sites.” — Ethan Marcotte

Responsive, Mobile And Fast

We can gain the benefits of responsive design without affecting performance on mobile if we use certain other techniques as well. Responsive web design was never meant to “solve” performance, which is why we can’t blame the technique itself. However, believing that it will solve all of your problems, as many seem to do, would be wrong.

Designing responsively is important because we need to deal with a range of viewport sizes across desktop and mobile. But thinking only of screen size underestimates mobile devices. While the line between desktop and mobile is getting blurrier, different possibilities are still open to us based on the device type. And we can’t decide on functionality using media queries yet.

Some commentators have called this “responsible responsive web design,” while others consider it responsive web design with a modern vision. Without getting into semantics, we do need to understand and be aware of the problem.

While there is no silver bullet and no solutions that can be applied to every type of document, we can use a couple of tricks to improve our existing responsive solutions and maximize performance:

  • Deliver each document to all devices with the same URL and the same content, but not necessarily with the same structure.
  • When starting from scratch, follow a mobile-first approach.
  • Test on real devices what happens when resources are loaded and when display: none is applied. Don’t rely on resizing your desktop browser.
  • Use optimization tools to measure and improve performance.
  • Deliver responsive images via JavaScript while we wait for a better solution from browser vendors (such as srcset).
  • Load only the JavaScript that you need for the current device with conditional loading, and probably after the onload event.
  • Inline the initial view of a document for mobile devices, or deliver above-the-fold content first.
  • Apply a smart responsive solution with one or more of these techniques: conditional loading, responsiveness according to group, and a server-side layer (such as an adaptive approach).

Conditional Loading

Don’t always rely on media queries in CSS because browsers will load and parse all of the selectors and styles for all devices (more on this later). This means that a mobile phone would download and parse the CSS for larger screens. And because CSS blocks rendering, you would be wasting precious milliseconds over a cellular connection.

Replace CSS media queries with a JavaScript matchMedia query on devices whose context you know will not change. For example, we know that an iPhone cannot convert to the size of an iPad dynamically, so we would just load the CSS for it that we really need.

We can also use feature detection, such as with Modernizr4, to make smarter decisions about the UI and functionality based not only on screen dimension.

Responsiveness According to Group

While we can rely on a single HTML base and responsive design for all screens when dealing with simple documents, delivering the same HTML to desktops and smartphones is not always the best solution. Why? Again, because of performance on mobile.

Even if we store the same document server-side, we can deliver differences to the client based on the device group. For example, we could deliver a big floating menu to screens 6 inches and bigger and a small hamburger menu to screens smaller than 6 inches. Within each group, we could use responsive techniques to adapt to different scenarios, such as switching between portrait and landscape mode or varying between iPhones (320 pixels wide), 5-inch Android devices (360 pixels) and phablets (400 pixels and up).

Server-Side Layer

The last optional part of a smarter responsive solution is the server. Server-side feature detection and decisions are not new to the mobile web. Libraries such as WURFL5 and Device Atlas6 have been on the market for years.

Mixing responsive design with server-side components is not new. Known sometimes as responsive design and server-side components7 (RESS) and sometimes as adaptive design, it improves responsive design in speed and usability, while keeping a single code base for everyone server-side.

Unfortunately, these techniques haven’t gained much traction in the community over the last few years. Just look at any blog or magazine for developers and compare mentions of “RESS” and “adaptive” to “responsive.” There’s a reason for that: We are front-end professionals. Anything that involves the server looks like a problem to us, and we don’t want that.

In some cases, the front-end designer will be in control of a script on the server; in other cases, a remote development team will manage it, and the designer won’t want to deal with the team every time they want to make a small change to the UI. I know the feeling.

That’s why it might be time to think of a new architecture layer in large projects, whereby a front-end engineer can make decisions server-side without affecting the back-end architecture. Node.js is an excellent candidate for this platform, being a server-side layer between the current enterprise back-end infrastructure and the front end.

In this new layer, the front-end engineer would be in charge of decisions based on the current context that would make the experience fast, responsive and usable on all the devices, without touching the back-end architecture.

Responsive Design, Performance And Technical Data

You might have some doubts by this point in the article. Let’s review some technical details to allay your concerns.

Responsive design usually entails delivering the same HTML document to all devices and using media queries to load different CSS and image files. You might have a slightly different idea of what it means, but that is usually how it is implemented.

You might also think that mobile networks today are fast enough to deliver a great experience. After all, 4G is fast, and devices are getting faster.

Well, let’s see some data before drawing conclusions.

Cellular Connections

4G networks are not available everywhere, and even if the whole world was on a 4G network today, the situation might not be what you expect. Less than 3% of mobile phones8 out there are on a 4G connection. Taking only the US, the number of 4G users has reached approximately 22%, and even those lucky users are not on 4G 40% of the time9.

We usually think of mobile network speeds in terms of bandwidth. With 3G, we get up to 5 Mbps; with 4G, we get up to 50 Mbps. But that’s not usually the most important factor in a mobile web browsing experience. While more bandwidth is useful for transferring big files (such as a YouTube video), it doesn’t add much value when you’re downloading a lot of small files and the latency is high and fixed. Latency is the round-trip time that the first byte of every package takes to get to a device after a request.

Cellular networks have more latency than other connections. While the latency on a DSL connection in a US home is between 20 and 45 milliseconds, on 3G it can be between 150 and 450 milliseconds, and on 4G between 100 and 180. In other words, latency is 5 to 10 times higher on a cellular connection than on a home network.

Other issues include the latency when there is a change in radio state, the dead time when a phone turns on the radio to get more data after having been asleep, the lower available memory on average devices and, of course, battery and CPU usage.

Responsive Design on Cellular Networks

Consider a real case. Keynote, a company that offers performance solutions, has published data on the website performance of top Super Bowl 2014 advertisers10. The data speaks for itself: On a wired or Wi-Fi connection, the loading times range from 1 to 10 seconds, while on a cellular connection, the loading times range from 5 to 60 seconds. Think about that: one full minute to load a website being advertised in the Super Bowl!

Website performance of the top Super Bowl 2014 advertisers.11
Website performance of the top Super Bowl 2014 advertisers. View large version12)

The same report shows that 43% of those websites offer a mobile-specific version, with an average size of 862 KB; 50% deliver a responsive solution, with an average size of 3211 KB (nearly four times larger); and 7% offer only the desktop version to mobile devices. So, by default, responsive websites are larger than mobile-specific websites.

Of course, responsive design can look different, but, unfortunately, the average responsive website out there looks like these ones of Super Bowl advertisers.

Cloud-Based Browsers

If you still doubt that performance is a problem on the mobile web, consider that browser vendors are creating cloud-based browsers to help users — including  Opera Mini, the Asia-based UC Browser (which commands 11% of the global market share, according to StatCounter13), Amazon Fire’s Silk and now Google Chrome (through a settings option).

These vendors compress every website and resource in the cloud, and then the browser downloads an optimized version to the mobile device. They do it because they know that performance matters a lot to the user’s happiness.

Underestimating the Mobile Web

The web community has always underestimated the importance of mobile browsers. I’m used to hearing people say that the mobile web today is just Safari for iOS and Chrome for Android and that, for responsive design, we need only care about viewports that are 320 pixels wide. It’s far more complex than that.

Today, more than 10 browsers have a market share over 1%. Even if you want to consider only the default browsers on iOS and Android, it’s not so simple. Roughly speaking14, 50% of mobile users browse the web on iOS, 38% on Android, 3% on Windows Phone, 5% with Opera Mini (on various operating systems) and 4% on other platforms.

On Android, 64% of users today browse with Android’s stock browser, which is not the same as Google Chrome and which exists in different versions. Moreover, some of Samsung’s latest Galaxy devices have a version of the Android browser with a customized engine.

In terms of viewport size, we are dealing today with pixel widths of 320, 360, 400 and 540 with Android smartphones alone. My suggestion, then, is never to underestimate the mobile web, and to learn its unique characteristics.

Above-the-Fold Content in 1 Second

On a mobile device, we can consider a website to be fast when content above the fold (i.e. the content that is visible without scrolling) is rendered in 1 second or less. I know, 1 second seems awfully fast — especially considering that at least half of that time is taken up by the cellular connection — but it has been proven to be possible. A 1-second response keeps users engaged with the content, thereby increasing the conversion rate and reducing abandonments.

To achieve a 1-second response time, above-the-fold content needs to be received in one round trip over the transmission control protocol (TCP) — remember that the average 3G connection has almost half a second of latency. Because of a TCP feature known as a “slow start,” that first response should be no more than about 14 KB in order to avoid a second package. This means that at least the HTML and CSS for the above-the-fold content should fit in a single 14 KB HTTP response. If we achieve that, then we’ll have achieved the perception of a 1-second loading time.

This rule is not written in stone and will vary based on your content. However, because content that appears above the fold will usually not be the same on a mobile screen as on a desktop screen, achieving this goal of 1 second with a responsive design is very difficult. It’s possible, but combining techniques makes it much easier.

One HTML for All

A typical responsive design delivers a single HTML document to all devices: televisions, desktops, tablets, smartphones and feature phones. It sounds great, but we live in a world that has cellular and other problems. Your responsive HTML might render correctly on mobile devices, but it’s not as fast as it should be, and that is affecting your conversion rate.

If a single display: none appears in any of your CSS, then your website is not as fast as it could be. On a website that has been designed from scratch to be semantic, then the responsive overload would be almost nil; on a website whose HTML includes 40 external scripts, jQuery plugins and fancy libraries, mostly for the benefit of big screens, then the responsive overload would be at the high end. When the same HTML is used, then the same external resources would be declared for all devices.

This isn’t to say that responsive design alone can’t be done, just that the website won’t be optimized by default. If you are sensitive to performance, then your responsive solution might look different than the usual.

Let’s review Starbucks’ website. Its home page is responsive and looks great in the three viewports we tested (see the screenshots below). But upon checking the internals, we see that all versions load the same 33 external JavaScript files and 6 CSS files. Does a mobile device with 3G latency deserve 39 external files just to get the view shown below?

The Starbuck's website in different states.15
The Starbuck’s website in different states. (View large version16)

You might be thinking, “Hey, blame the implementation, not the technique17.” You’re right. This article is not against responsive web design. It’s against aiming for responsiveness in a way that leads to a weak implementation, and it’s against prioritizing responsiveness over performance, as we see with Starbucks. It looks great when you resize the browser, but that’s not all that is important. Performance also matters a lot to mobile users.

If your responsive website has performance problems, then the fault may lie with how you’ve framed the goal. If you have the budget for responsive design, then you must also have the budget for performance.

Loading Resources

Media queries are implemented in different ways, usually as one of the following:

  • a single CSS file with multiple @media declarations,
  • multiple CSS files linked to from the main page via media attributes.

In the first case, every device would load the CSS intended for all devices because there would be just one CSS group. Hundreds of selectors that will never be used are transferred and parsed by the browser anyway.

You might think that multiple external files are better because the browser would load the resources based on breakpoints. This is what we’re taught in tutorials in blogs, magazines, books and training courses.

<link rel="stylesheet" href="desktop.css"
  media="(min-width: 801px)"> 
<link rel="stylesheet" href="tablet.css" 
  media="(min-width: 401px) and (max-width: 800px)">
<link rel="stylesheet" href="mobile.css" 
  media="(max-width: 400px)">

Well, you’d be wrong. All browsers will load all external CSS, regardless of context. The screenshot below shows an iPhone downloading all of the CSS files excerpted above, even ones not intended for it.

Browser will load all external CSS files, regardless of the context.18
Browser will load all external CSS files, regardless of the context. (View large version19)

Why do browsers download all CSS files? Suppose you have one CSS file for portrait orientation and another for landscape. We wouldn’t want browsers to load CSS on the fly when the orientation changes, in case a couple of milliseconds go by without any CSS being used. We’d want the browser to preload both files. That’s what happens when you define media queries based on screen dimensions.

Can the dimensions of mobile browsers be changed? Mostly not yet, but vendors are preparing their mobile browsers to be resized like desktop browsers, which is why the browsers usually load all CSS declarations regardless of whether their width matches the media query.

While stretchable viewports don’t exist on mobile devices (yet), some viewports resize in certain situations:

  • when the orientation changes in certain browsers,
  • when the viewport declaration changes dynamically,
  • when offset content is added after onload,
  • when external mirroring is supported,
  • when more than one app is open at the same time on some Samsung Android devices (in multi-window mode).

Browsers that are optimized for these changes in context will preload all resources that they might need.

While browsers might be smarter about this in the near future, we’re left with a problem now: We are delivering more resources than are needed and, thus, penalizing mobile users for no reason.

The Real Problem: Responsive Design As A Goal

As Lyza Danger Gardner says in “What We Mean When We Say ‘Responsive’3120,” designers define “responsive” differently, which can lead to communication problems.

Let’s get to the root. The term first appeared in a 2010 post by Ethan Marcotte21, followed by a book with the same name. Ethan defines it as providing an optimal viewing experience across a wide range of devices using three techniques: fluid grids, flexible images and media queries.

Nothing is wrong with that definition. The problem is when we set it as the goal of a website without understanding the broader goals that we need to achieve.

When you set responsive design as a goal, it becomes easy to lose perspective. What is the real problem you are trying to solve? Is being responsive really a problem? Probably not. But do you understand “being responsive” to mean “being mobile-compatible”? If so, then you might be making some mistakes.

The ultimate goal for a website should be “happy users,” which will lead to more conversions, whatever a conversion might be, whether it’s getting a visitor to spread the word, providing information or making a sale. Users won’t be happy without a high-performing website.

The direct impact of performance on conversions, particular in mobile, has been proven many times. If this is the first time you are hearing about this, just check any of Steve Souders22’ expert books about optimizing web performance.

When you know your goals, you can decide which tools and techniques are best to achieve them. This is when you analyze where and how to use a responsive approach. You use responsive design — you don’t achieve it.

Responsive vs. Users

The New York Times redesigned its website23 a couple of months ago with the goal of keeping “you in mind.” Meanwhile, thousands of other big companies present their new responsive websites with pride.

The New York Times follows responsive design in different ways, but some people complained that it still uses a separate mobile version, instead of adapting the layout based on the same HTML. An article even came out titled “The Latest New York Times Web App Misses the Point of Responsive Design24.”

The New York Times follows responsive design in different ways.25
The New York Times follows responsive design in different ways. (View large version26)

Who said that responsive web design means supporting all possible screen sizes with the same HTML? Sure, this is a common understanding, but that rule isn’t written anywhere. It’s just our need to simplify the problem that has led to it.

In recent months, companies have said things along the lines of, “We’ve applied a new responsive design, and now our mobile conversions have increased by 100%.” But did conversions increase because the website was made to be responsive, or are users realizing that the website is now responsive and so are happier and convert more?

People convert more because their experience on mobile devices is now better and faster than whatever solution was in place before (whether it was a crude mobile version or a crammed-in desktop layout). So, yes, responsiveness is better than nothing and better than an old mobile implementation. But a separate mobile website with the same design or even a smarter solution done with other techniques would achieve the same conversion rate or better.

Conclusion

“Your visitors don’t give a sh*t if your site is responsive,” — Brad Frost

Brad Frost27 is completely right. Users want something fast and easy to use. They don’t usually resize the browser, and they don’t even understand what “responsive” means.

It’s a bitter truth, and it doesn’t quite apply to all websites. But it’s better than thinking, “We can relax. Our website is responsive. We’ve taken care of mobile.” Sometimes, even when not relevant to the situation, saying that responsive design is “bad for performance28” can be good because it helps to spread the word on why performance is so important.

The New York Times is right: The goal is the user. It’s not a tool or a technique or even the designer’s happiness.

Further Resources

(al, ml)

Footnotes

  1. 1 http://www.guypo.com/mobile/rwd-ratio-in-top-100000-websites-refined/
  2. 2 http://www.guypo.com/uncategorized/real-world-rwd-performance-take-2/
  3. 3 http://www.abookapart.com/products/responsive-web-design
  4. 4 http://modernizr.com/
  5. 5 http://www.scientiamobile.com/
  6. 6 https://deviceatlas.com/
  7. 7 http://www.lukew.com/ff/entry.asp?1392
  8. 8 http://www.4gamericas.org/index.cfm?fuseaction=page&pageid=2253
  9. 9 http://opensignal.com/reports/state-of-lte-q1-2014/
  10. 10 http://blogs.keynote.com/the_watch/2014/02/you-can-run-but-you-cant-hide-from-performance.html
  11. 11 http://www.smashingmagazine.com/wp-content/uploads/2014/06/03-keynote-opt.jpg
  12. 12 http://www.smashingmagazine.com/wp-content/uploads/2014/06/03-keynote-opt.jpg
  13. 13 http://gs.statcounter.com/#mobile_browser-ww-monthly-201303-201403
  14. 14 http://firt.mobi/velocity
  15. 15 http://www.smashingmagazine.com/wp-content/uploads/2014/06/01-starbucks-opt.jpg
  16. 16 http://www.smashingmagazine.com/wp-content/uploads/2014/06/01-starbucks-opt.jpg
  17. 17 http://timkadlec.com/2012/10/blame-the-implementation-not-the-technique/
  18. 18 http://www.smashingmagazine.com/wp-content/uploads/2014/06/02-inspector-opt.jpg
  19. 19 http://www.smashingmagazine.com/wp-content/uploads/2014/06/02-inspector-opt.jpg
  20. 20 http://alistapart.com/column/what-we-mean-when-we-say-responsive
  21. 21 http://alistapart.com/article/responsive-web-design/
  22. 22 http://stevesouders.com
  23. 23 http://www.nytimes.com/redesign/
  24. 24 http://readwrite.com/2013/12/05/new-york-times-responsive-web-app-todays-paper
  25. 25 http://www.smashingmagazine.com/wp-content/uploads/2014/06/04-nytimes-opt.jpg
  26. 26 http://www.smashingmagazine.com/wp-content/uploads/2014/06/04-nytimes-opt.jpg
  27. 27 http://bradfrostweb.com/blog/web/responsive-web-design-missing-the-point/
  28. 28 http://timkadlec.com/2014/07/rwd-is-bad-for-performance-is-good-for-performance/
  29. 29 http://bradfrostweb.com/blog/web/responsive-web-design-missing-the-point/
  30. 30 http://www.lukew.com/ff/entry.asp?1392
  31. 31 http://alistapart.com/column/what-we-mean-when-we-say-responsive
  32. 32 http://blogs.keynote.com/the_watch/2014/02/you-can-run-but-you-cant-hide-from-performance.html
  33. 33 http://www.guypo.com/uncategorized/real-world-rwd-performance-take-2/
  34. 34 http://timkadlec.com/2012/10/blame-the-implementation-not-the-technique/
  35. 35 http://timkadlec.com/2014/07/rwd-is-bad-for-performance-is-good-for-performance/

↑ Back to topShare on Twitter

Is a mobile+web developer, consultant, trainer and author of the books Programming the Mobile Web (2nd. edition) and Up and Running: jQuery Mobile. He is a frequent speaker, including Fluent, JSConf, TopConf, Velocity Conference talking about performance and mobile HTML5. He has delivered more than 200 trainings in more than 20 countries. He mantains the HTML5 Mobile Compatibility list and usually publish information on new capabilities on mobile browsers in his blog.

Advertising
  1. 1

    I think all web designers/developers needs to read this article, there’s a big misconception about responsive websites. First off, a lot of sites don’t actually need a responsive website. Evaluating the need for one should be task #1. You should not have a responsive website because everybody else is doing it.

    Secondly, I consider webpage load times THE most important thing, especially above the fold content. Google’s PageSpeed insights tool is a nice direction to start in, but doesn’t actually tell you how long your website took to load, only a little advice on how to make it better. Don’t dwell on your score out of 100, I wouldn’t call it relevant. Instead use Pingdom Tools to see how long, for real, your website is taking to load and how many HTTP requests your website is sending.

    I have an image-based design inspiration website, http://airwalk-design.com, which was a real torture to optimize, although it eventually achieved a 100/100 score on Pingdom Tools and the above the fold content rendered in under a second. Most scripts run onload while the user is admiring the design inspiration. It IS responsive, but there’s no hiding/showing of content. It’s more fluid than anything, using a lot of max-width so there’s no “mobile stylesheets” – I think this is the way to go. Don’t try to show off with a different mobile website. These are of course my opinions ;)

    -Daniel

    7
    • 2

      Well, your site definitely looks nice but honestly most pages are a bit more complex than that page.

      9
    • 3

      Paul Mark Quinn

      July 22, 2014 4:12 pm

      All points good and viable although you reference above the fold?
      How do you maintain above the fold on the constantly growing range of devices?
      Above the fold is a term I think that is a bit out of date

      12
      • 4

        Maximiliano Firtman

        July 23, 2014 1:46 am

        Hi Paul, the Above the fold idea on mobile performance is, in fact, new. For example, now Google Page Speed Insights gives you hints and help for separating your ATF content. While I agree that the ATF might defer between mostly phones, phablets and tablets, it’s the same within those groups. It doesn’t need to be a ATF-pixel-perfect situation. Thanks!

        2
      • 5

        While it is true (at least I think so as well) that “above the fold” is kinda dead, there are a few tools around that let you identify crucial contents and extract related CSS into an inline style tag in the head section of a website in order to improve performance or more important the reading experience of a user.

        e.g..: https://github.com/filamentgroup/grunt-criticalcss/ (no grunt, no problem: https://github.com/filamentgroup/criticalCSS ) is a nice solution. The last thing I heard was that it is in alpha state currently. Yet, handle with care whatever tool you are choosing. =)

        0
        • 6

          Maximiliano Firtman

          July 23, 2014 12:33 pm

          Hi Marco, I disagree that ATF is outdated. The idea might not be new but if you want to achieve the fastest performance on mobile, it’s necessary. Is the only way you can achieve today the 1s threshold on mobile when you have a large website and/or you have lot of resources. In fact, Page Speed and Google’s performance tools have added ATF suggestions just a couple of months ago: https://developers.google.com/speed/docs/insights/PrioritizeVisibleContent

          Also many talks in the last year have been covering in depth this idea: https://docs.google.com/presentation/d/1IRHyU7_crIiCjl0Gvue0WY3eY_eYvFQvSfwQouW9368/present#slide=id.p19

          I’m not saying that every website should consider this; it’s just one of many techniques you need to know to support your mobile users in a better way. Thanks!

          1
          • 7

            Not only content, but functionality. Clickable links or form submits, when should this be available? If you site is fast, then onload can be only a few ms away, but if not, what then?

            I will take Facebook for example. Let’s say that you know Facebook very well, you’ve opened it in the browser and you go straight to the notifications, what would happen if that kind of functionality wasn’t available until until the timeline had been loaded?

            Just something to think about.

            2
          • 8

            Maximiliano Firtman

            July 23, 2014 8:14 pm

            Facebook is a great example; they work exactly with the ATF content idea or even more aggressive than that. They are definitely not downloading the whole page, not even the sidebars until the onload. Therefore, it seems fast. Perception sometimes is more important than the real performance.

            2
      • 9

        Lets rename the fold ‘rofld’ (responsive fold) to acknowledge that this is different on different devices.
        Mobile designers would be considering where the fold might fall on various devices when working out the scaling and breakpoints for their responsive designs.

        0
    • 12

      Your site is fast because there is nothing to show in your site. It will be much faster if you just think about the js animation that you got on the bottom of your page. That animation is increasing your browser rendering and painting time. You are even not using css3 transform to push the hardware acceleration.

      Think about the news site, even think about this smashing site. Do you have any idea how to get 100/100 for these sites? Those measurements are bullshit man, you shouldn’t be proud of it unless you have tons of content to show. google.com perform 100/100. Simply because there is nothing to show, nothing to load.

      1
    • 13

      @Daniel – I would recommend serving up appropriate images for mobile. Right now you’re serving a 1575×1050 image (over 150kb) to iphone and ipad (mobile / tablet) users that can’t do anything with that.

      Your spotlight.png image is also only 315px wide, but is 160kb (more than the 1574×1050 image above!) – and it has no transparency. All of your png’s are uncompressed with no transparency (meaning why use a png?). So make them a .jpg, or run through an optimizer. I ran it through tinypng and got a 75% reduction to only 40kb. That’s a big difference. Run every image through and you’ll get close to 400kb back.

      The buysellads.com scripts you have on there also caused very high latency on my first page load (about 8.93 seconds). Maybe try lazy loading that if possible, if you aren’t already.

      Lastly, you’re using javascript to animate the letters on your footer. It’s CRAZY EXPENSIVE. Like, totally worth putting that in capitals, expensive. Don’t do that on mobile.

      My point is, Page Scores don’t always tell you what you need to know. You may have been able to game a 100 score, but in all honesty you missed some really important mobile optimizations. Sure, above the fold content can make your site appear to load faster, but if you haven’t optimized your site’s images and have some javascript animations playing on loop, then I think you missed some pretty big opportunities to make your site actually load faster for your users. Plus, these optimizations take far less time to implement and are far more maintainable than trying to optimize an ever-changing “fold”.

      2
  2. 14

    Mark Lodermeier

    July 22, 2014 3:04 pm

    Great article, I am just starting out in web design/development and until now I was using “responsive design” as my one and only solution to all screen types. SO, can anybody tell me, I’ve written this magazines staff over 2 weeks ago…DOES their ‘Smashing Book #4′ outline code examples of how to best utilize responsive, mobile, and many other new techniques? Is it worth buying is what I need to know? OR, does anybody have an even better resource where one can ‘solve the mysteries’ on implementing responsive and specific mobile techniques that use 1 HTML file? Cheers!

    0
    • 15

      Vitaly Friedman

      July 22, 2014 4:14 pm

      Dear Mark,

      I am afraid it’s offtopic here. Yes, the book covers some of the useful techniques and strategies to tackle responsive design, but I would also recommend you to look closer at the Mobile Book and Mobile Web Handbook in the “Books” section in the magazine: http://www.smashingmagazine.com/books/. I am confident that you will not be disappointed. However, I would also recommend reading Implemeting Responsive Design by Tim Kadlec and Responsive Workflow by Stephen Hay. And in fact, we might have a book on responsive design coming out soon, too, so please stay tuned!

      0
  3. 17
  4. 21

    You say to “Replace CSS media queries with a JavaScript matchMedia query” but testing by Andy Davies (no [recent] relation) seems to contradict that advice:

    http://andydavies.me/blog/2012/12/29/think-twice-before-using-matchmedia-to-conditionally-load-stylesheets/

    I’m all for techniques to square the contradictory circle of responsiveness vs. speed; I’m not sure we are there yet.

    3
    • 22

      Maximiliano Firtman

      July 22, 2014 11:26 pm

      This is not against RWD techniques, but the implications on mobile. While with matchMedia there are for sure a difference in terms of “priority” on some cases it will be faster at the end on mobile devices using cellular connections. Testing cases on a home connection is just theory, that’s not the real world. There are no general rules, this is better than that; you need to test, measure and decide on your own particular problem.

      -2
  5. 23

    Great article, Max. As usual. And thank you for mentioning WURFL. As an aside, we recently launched tools to make WURFL available to front-end programming in a way that is familiar to them, Javascript (more at http://www.smashingmagazine.com/2014/07/01/server-side-device-detection-with-javascript/ ).

    RWD is great and it is here to stay, but it is a no brainer that a mobile specific website will always load faster than a RWD site on a mobile device. There was an article recently that tried to make a point that this is not the case, but the author reached the goal by doing crazy assumptions against mobile-optimized sites and positive assumptions in favor of RWD. The reality is that mobile specific is blazingly fast compared to RWD (which can still be fast enough, particularly when carefully optimized)

    Of course, if one takes a pragmatic approach that considers all aspects of a software project, the economic advantages of a single set opf HTML/CSS/JS often outweights other considerations, so developer and project managers have plenty of reasons to still prefer RWD over mobile optimized all things considered. Then again, others may go for different approaches.

    1
  6. 24

    If you’re going to quote me, Maximiliano, I’d suggest revisiting the context of the quote.

    12
    • 25

      Maximiliano Firtman

      July 23, 2014 1:41 am

      Hi Ethan, I read the full part where you have that quote in your book and I don’t think I’m misinterpreting your words. If you feel it’s not what you meant, we can remove the quote and the link or add your comment there.

      To be honest, I feel that the paragraph where that line is it and the next paragraph are in line with this article. But it can be just my feeling anyway.

      Thanks.

      -6
      • 26

        I found the rest of the quote, “Most importantly, responsive web design isn’t intended to serve as a replacement for mobile web sites. Responsive design is, I believe, one part design philosophy, one part front-end development strategy. And as a development strategy, it’s meant to be evaluated to see if it meets the needs of the project you’re working on.”

        2
        • 27

          Regardless, that books fairly outdated now anyway, so it’s content doesn’t hold true anymore in a mobile first and ress dominated world.

          -2
          • 28

            Maximiliano Firtman

            July 23, 2014 8:18 pm

            While I agree than maybe the Responsive Web Design original definition might be outdated with new browsers, ideas and solutions; I think the original quote and the rest of the paragraph is perfectly valid today. And that’s exactly why I was saying here in this article.

            Because we are mobile first now, mobile performance should be Top #1 priority. If you can provide the fastest possible experience with RWD, go for it! If not, we need to hack it or use alternative techniques (call them however you want). My warnings here is that most people don’t realize they may have performance issues because they are just using standard “classic?” RWD techniques without paying attention to other important things, such as performance on mobile.

            -1
    • 29

      the quote reflects the message, the spirit and the context of what is written in the book.
      Not sure whz everzone has upvoted this comment and downvoted Maximiliano’s response.

      Ethan, I think you owe Maximiliano an explanation.

      2
  7. 30

    Wonderful article, much needed. I can’t count how many clients I’ve had clients who had 160+ separate resources loaded and called their website “responsive”. Sure, things nicely move around the page when you resize the browser, but this is NOT mobile-friendly test.

    Anyways, I was kind of expecting you would add painting/rendering performance here. Downloading too much content is a very obvious problem, but what seems to be ignored more often than not is how fast the page responds to user input. Too many scripts, plugins and libraries have been used to replace the default scrolling with something else. Too many heavy animations that look like slide shows and are not even relevant on mobile. Too many sites that crash browsers on older devices.

    Since this article encapsulates the issues around what some forget “responsive” should mean I believe render performance should have been mentioned here too.

    Now for the fingerprinting :D
    Plugins, libraries and CMS. These tools make development seem way too easy and facilitate births of disgustingly heavy spaghetti-coded abominations. After all, if I didn’t know anything about programming, usability and performance, hell yeah I’d click that one button to make my whole site “responsive”.

    3
    • 31

      Maximiliano Firtman

      July 23, 2014 12:26 pm

      Dmitri, I agree with you, performance should include responsiveness after initial load. BTW, responsiveness as how fast it react to user’s interaction not about RWD ;). I didn’t mention it here because I think it was a little bit out of scope of this article’s goal, but as a general idea I usually talk about this. Check the slides of my recent workshop on performance for mobile web; I’ve two sections: initial loading and experience & responsiveness http://www.firt.mobi/velocity

      1
      • 32

        And the cost of downloading data is a huge issue. I resent paying for even byte more than is absolutely necessary, – Pet bugbear is video !

        1
        • 33

          Oops pressed submit before I was finished.

          I would argue having 2 versions for mobile is necessary – one lightweight and the other the “full” responsive experience – and allow users to choose ! (eg if I were a Starbucks regular I could say always give me the lightweight version – then I wouldn’t see many images)

          Looking at the Starbucks example – just tell me there are great deals if I text “smile” or whatever – tell me about the loyalty card. Do I care about girls making a heart on a beach? Absolutely not! Do I resent paying to download the image when mobile – absolutely!

          Tablets excepted, the use case for many phone users is “I am in a hurry I want to find out “x” now!” I do not want to wade through image after image after image looking for it. In that usecase, in the Starbucks example – are the girls “noise” yes absolutely – without them I could have had the loyalty card info front and centre. (Newspaper sites are bad at this – hey I already know what our Prime Minister looks like – why do I need to see photo of him on my mobile phone when I read a story about him ? Whats worse, on many I also get a video of a reporter telling me what I am reading grrrrrrrrr )

          2
          • 34

            I agree but I can also see your idea of multiple versions getting in the way of SEO or complicating it at least.

            …I was tempted to leave my web url…sorry bad habbit from the past…

            0
      • 35

        Awesome, thanks for the link Maximiliano!

        0
  8. 36

    Maybe on correction: media queries are not (always) blocking the render path.

    See also:
    https://developers.google.com/web/fundamentals/performance/critical-rendering-path/render-blocking-css

    0
    • 37

      Maximiliano Firtman

      July 23, 2014 2:59 pm

      Hi Thomas, thanks for your message; I don’t see your point. The website you are pointing is saying the same thing as this article in terms of CSS and rendering.

      1
  9. 38

    A good thought-provoking article that reminds us again that responsive web design is a useful tool, and there are others – and that every tool has its pros and cons.

    I’m not sure that I’d call Opera Mini “infamous”, though. For many of the 244 million people who used it last month. it’s literally their only access to the web. I’m biased, though – I work for Opera.

    0
    • 39

      Maximiliano Firtman

      July 23, 2014 3:03 pm

      Hi Bruce; you are totally right. I’m sorry about that description of Opera Mini. It’s not an excuse but that was not the word I’ve used on my original article, it was changed by the editor. I didn’t realize the change until you mentioned it. I always embrace Opera Mini and advocate to web professional to test on it because millions of users are using it today. We’ll change that ‘infamous’ asap!

      0
  10. 40

    I’m webdesigner since 8 years and my problem is everyday is a new browser or Os day : ie7, ie8, ie9, ie10, ie11…, firefox, chrome, safari, opera, ios, android, windows !! Please :)
    I like my job, but my client want the lower price as possible for their web site and I don’t want to spend 300hours per site for 300€
    I’m webdesigner / front end developer, not browser vendors debugger / optimizer.
    Give us standard common solutions, for a better web ;)

    4
  11. 41

    “Who said that responsive web design means supporting all possible screen sizes with the same HTML? Sure, this is a common understanding, but that rule isn’t written anywhere. It’s just our need to simplify the problem that has led to it.”

    It’s not written anywhere no, but it should be. The problem is that many web developers are under the impression that a ‘desktop’ means you can abuse bandwidth. It doesn’t. If all sites which are intended to serve a function – i.e. they are not art (not getting into the debate on whether art serves a function), focussed purely on performing that task, there would not be a problem.

    All your reference material is around the design of layout, until this point where you are then stating that the functions you provide people on a big screen device should be different to that on a small. You could not be more wrong. These so called small screen devices have far more capability as an input device as the common mouse and keyboard of a ‘desktop’ based machine.

    If you think about that, creating a service which functions at its best on a ‘small screen’ device will always be better on a ‘large screen’ device. I’m air quoting all this because it is a dead notion to consider things based on size.

    Not a great article and I don’t think you actually have a point here either.

    @romain – your problem is you’re designing/building for browsers. Don’t.

    -2
    • 42

      Maximiliano Firtman

      July 23, 2014 5:41 pm

      “you are then stating that the functions you provide people on a big screen device should be different to that on a small” Where did I say or state that?? On the contrary, I’ve said that creating a mobile-specific version is not a good idea and I always advocate for full function websites on mobile devices. Sometimes the same HTML/CSS does the trick, sometimes it hurts badly the mobile performance.

      In wonderland, the idea of RWD as the solution for every screen is excellent; I want it. But unfortunately, as I’ve stated during the article, the mobile world -for example because of cellular networks- is different. Because of that we need to get out of our idea of how the world is and (unfortunately) do some tricks to provide the best possible experience to the users.

      Underestimating mobile is a big mistake. Not understanding that most users in the world are browsing with unreliable 3G networks with up to a half a second latency it’s a big mistake. If you understand your problems, you measure and you decide if your current solution (responsive or not) is good enough or not.

      It’s ok if you don’t like the article or my point; I’m not here for +1s ;)

      Thanks for the feedback! It’s always welcome.

      2
      • 43

        I think your entire issue is how you attacked the issue of mobile network/speed accessibility. It’s one thing to say be aware that not everyone has a fast mobile network connection, it’s another thing to actively state that RWD creates all these load time issues. That’s simply not the case. What creates all these load time issues is poorly optimized sites. REGARDLESS of their RWD status.

        1
        • 44

          I don’t know who said that, but it wasn’t me and nowhere in this article I’m saying that. Thanks for the feedback.

          0
          • 45

            You didn’t explicitly say that in the article, but it’s implied by various points in the article and by the title. Your article would have been accepted a lot easier if the title and content was focused more on optimization in general and less about how RWD creates problems on mobile. The arguments you make against RWD, are also what enables it to be device agnostic and the most future proof method. But you completely ignore that and focus on the couple of milliseconds in load time delay it causes.

            If someone is building a RWD that has a footprint 2-3 times that of a stand alone mobile or desktop site, then they are doing it wrong.

            -1
  12. 46

    This article preaches bad practices, gives bad advice, and generally side-steps the real issues of optimization.

    You can find utter disapproval (including my own rant) for this article flourishing on reddit: http://www.reddit.com/r/Frontend/comments/2bg1c4/you_may_be_losing_users_if_responsive_web_design/

    -3
    • 47

      I agree, I think the issue discussed in this article is optimization in general and is really not explicit to RWD. RWD is not inherently a performance issue if done well. A good RWD doesn’t add much code at all to make it adapt to different screen sizes.

      0
  13. 48

    Wow! I really like the way you presented the details in the post. Thanks

    0
  14. 49

    This article i thing miss some important data, as we build or media site to responsive people stop downloading our apps althought have been updated and prefers to use our responsive website as we can see our comscore & analytics data 50% Desktop, 47% Mobile & 3% Tablet.

    0
    • 50

      Juan, that is good data. If you can share it publicly it will be very useful for the community. However, I think there is an mistake on your conclusions. You say people stop using your app in favor of your responsive website. And I ask: “do your users realize that now the website is responsive?”. If your visitors are now in your website and not before, maybe is because your previous mobile experience wasn’t good. And now the experience that you are offering with a responsive site is much better. However, you can also provide the same good experience with a separate site and people won’t see the difference. I’m not saying you should do that, I’m saying that the cause of your data might not be the responsiveness of your new site but the better UX. If you didn’t think on performance also you can still improve the mobile experience over your current responsive solution, and this article talks about that basically.

      0
  15. 51

    Wow, thanks for writing. This article is a great wakeup call for designers (like me) who have been designing “responsive” websites even “mobile-first” without thinking about how to load things quickly on mobile, not just in a usable, readable layout/design.

    Definitely going to have to do some more thinking about this for my next website project.

    2
    • 52

      Thanks Caleb, that was one of my main goals while writing this article. Giving you a wakeup call (great analogy BTW). I know there are some professional that already know all of this but in my experience working with the community is not a common knowledge in the design/web community as other people think.

      0
  16. 53

    Very interesting read! Interestingly enough, I’ve had clients that did NOT want a responsive website. Their strategy was to develop a mobile app for iPhone and Android based smartphones.

    0
    • 54

      Hope they considered their user and business goals before they jumped on that equally thoughtless bandwagon! There shouldn’t be just a reflexively pick-one decision either way. Many factors should be considered in deciding which way to go.

      0
  17. 55

    ‘“Your visitors don’t give a sh*t if your site is responsive,” — Brad Frost’

    This is kind of a BS to believe in that because responsive design is recommended for many things – two main things being SEO and User Experience. And then saying that a visitor doesn’t care if a site is responsive… If I am on my phone and I open a website that has a desktop layouts that blurs me away from my focus, I ignore the website or come and later read it on my laptop (if its really worth my time). And everyone I know or hear about, have the same approach.

    0
    • 56

      Hi Gasim, but what you are saying is covered on the article. First, I’m not saying: “don’t be responsive”. Secondly, you are defining responsive as same URL for different devices (the SEO comment), but you can share the same URL with different versions too. Just two different approaches; SEO and UX are of course really important, but I don’t see a direct relationship with responsive for those goals.

      0
  18. 57

    Well, I just can’t wait to see how my colleagues from the web administration will react when they read this.

    We work for local government and they constantly avoid conversations about the design of the official website. I don’t know why people always fail to realize that event the public administration needs to be responsive as much as possible?

    0
    • 58

      Dana, all websites -including public administration- need to be fast and accessible with a good UX from everywhere. Being responsive or not is not a need, it’s a result. Sometimes semantics don’t matter too much, but the important thing is the end result. If you end with a fast, accessible and with a good UX on mobile and other devices, that’s great.

      1
  19. 59

    I’ve always been under the impression that the content of non-applicable inline media queries were NOT parsed by the browser. Surely that would be against the interests of browser performance. Do you have any evidence to show that a min width 1000px would be parsed by a phone browser??

    0
    • 60

      Paul, check the article again; you have the evidente there :) Look at the screenshot of the classic/old/simple RWD html code. The screenshot is from a real iPhone; you can see that it’s loaded the three CSS files. That code is not really the way to do RWD today; it’s just the simplest example to probe that most devices will download every CSS.

      0
      • 61

        You misunderstood what I was referring to. *Inline* media queries are blocks within a single file. That was your first example where you say all media queries are parsed.

        0
        • 62

          In terms of parsing is the same thing; the parser needs to parse the whole style declaration. I’m not saying it’s executing it, but in terms of download and parsing it’s doing that. And CSS blocks rendering (the browser will not start rendering if all the known styles were downloaded and parsed). On some situations the overhead is “good enough” and the performance cost is near null but in other cases the overhead is harming performance, forcing the CSS part to split into separate TCP packets, and with 3G latency going on it’s a high cost you are paying because you are delaying the initial rendering.

          0
          • 63

            What I’m interested in is evidence. How do you know that a mobile browser parses a min height 1000px block and doesn’t just ignore it after seeing that it’s not applicable?

            My CSS is all mobile first, minified, single file, with min-height blocks. Whether or not the browser parses the content of irrelevant blocks makes a big difference on slow mobile devices.

            2
  20. 64

    Hey, cool post! Informative one, i would say!
    i had only been using responsive designs until now but will be following your tips from now. thanks

    0
  21. 65

    Dragan Filipovic

    July 25, 2014 6:40 pm

    Uh, it’s becoming very hot.

    0
  22. 66

    Great overview of the issues we face when building sites for mobile. I however desagree with the mobile-first approach that is often advertised. My experience designing for mobile has led me to still stick with a web approach first while look at how the design and semantics will degrade on mobile and then make decide on plementations. As content and its relevance still dictate user experience.

    0
  23. 67

    Users for the most part do not care at all if your site is responsive. But hiring managers often do and other people you work with often do. This article is symptomatic of what often goes on in the realm of web development:

    1. Talk about how great and necessary a certain technique is
    2. Finally everyone starts using it
    3. Then talk about how it’s really not that great

    0
    • 68

      David Bartenstein

      July 26, 2014 11:18 pm

      Hahaha! True that Christian! But you’re oversimplifying the chain of reactions a little, agreed? Allthough your remark is definitely touching the core of the cord-jumping movements seen in webdesign world (and very recognizable), still progress is made everytime someone reconsiders the current most popular techniques. It just means the herd is always a little bit behind. But we catch up!

      0
      • 69

        Yeah, I’m oversimplifying. Just pointing out that I’ve seen this pattern quite a bit. And I’m not really even all that emotional about it. Like you, I still think this article is one good way to help keep people aware of all the different issues out there.

        0
  24. 70

    Haven’t you heard AppCache?
    CSS with JS is same slowness animal. Your browser can only run one javascript tread at a time.

    Don’t compare responsive web vs mobile App experience.

    To achieve the such speed the author suggested, the practice way is to use server side device detection and return different view. It is possible to still maintain same URL. Plus AppCache then it is possible…

    0
  25. 72

    Maximiliano Firtman, I agree with your points but I can’t think regarding the server side solutions as a front-end developer, that’s out of my scope either. It’s far better to have responsive site instead of not having the responsive site, otherwise I have to pinch and zoom my screen all the time, even while reading this blog.

    We need a solutions (I knew this problem already). I wish the solution will be much easier as I am thinking and it should be client side. For eg, if I am writing code in php then:


    =1024) {
    a long content
    } else {
    // For touch devices as well below 1024 of width
    short content
    } ?>

    so, this is how we don’t need to use display:none anymore and user shouldn’t load the unnecessary content.

    1
    • 73

      David Bartenstein

      July 26, 2014 11:20 pm

      Sorry Jimba, but I don’t really understand what you are saying here… Can you elaborate on that a bit more?
      Best regards,
      David

      0
    • 74

      Yes! Yes! Yes!

      0
    • 75

      I mean yes, yes, yes, Jimba’s approach – when responsive is more appropriate for balancing user goals with business resources.

      While responsive is obviously not always the best solution, when it is, you can certainly use logic like this to present content in a much more ideally optimized manner.

      This is a great and thorough article. Thank you Maximiliano.

      0
  26. 76

    Daam, some codes are removed in my example. It should be:


    = 1024 ) {
    Show Long Text
    } else {
    // For touch devices with below 1024 of width
    Show short text
    } ?>

    0
  27. 77

    David Bartenstein

    July 26, 2014 11:39 pm

    Nice job Maximiliano!

    I have to say I found your article to have a bit of a slow start with too much repetitions, but later on it got really good! And I wanna thank you for the many usefull references you included. I agree with everything in it.

    Nevertheless, I wish you would have included the SEO point of view regarding the choice to go with a single url for all devices, or a separate one for different devices. To my knowledge the main reason for having only one url for all devices is that separate urls will recieve traffic separately, thus ranking separately, which is something most website owners should try to avoid at all cost.
    Since your website needs to be found first before viewers can be either impressed or depressed by it’s performance, I believe ranking should get some priority over performance, or at least be set equal to it. So in most cases having a separate mobile website should not be considered an option if one cares about conversions. What’s your take on that?

    Best regards,

    David

    0
    • 78

      Thanks David for your feedback; Unfortunately I can’t cover every point of view from a single article -books are a better option; my book on the topic has 750 pages :P- Anyway, regarding your comments on SEO, I don’t think it’s a main reason. With the proper configuration, meta tags and redirections, you can still share SEO rankings between separate versions and URL. However, I agree that sharing the single URL is a good idea and is more future-friendly. I think social sharing is a bigger problem on a separate version if you don’t have proper redirection and using a single URL (responsive or not) is easier.

      0
  28. 79

    Great Article Maximiliano.

    0
  29. 80

    Mark Max Henckel

    July 28, 2014 3:17 pm

    Brillant. Event the number of comments here!

    0
  30. 81

    Any suggestions on how to tackle these issues in a WordPress environment?

    0
  31. 82

    There is a lot to agree with in this post. I agree that focusing on a particular technique can cause you loose sight of the more important overall goal—serving customers.

    We’re now operating in a multi-device world. It’s a given that publishing in this landscape is really difficult—so why not take all the help we can get in the form of different approaches and techniques?

    The pragmatist’s tool box doesn’t contain silver bullets.

    DotMobi is the creator of DeviceAtlas yet we’re more than happy to embrace RWD where it makes sense (we use RWD alongside server-side techniques in our goMobi mobile-first site builder service).

    One other point—RESS needn’t be difficult when pre-made open-source solutions can do all the heavy lifting for you: http://www.smashingmagazine.com/2013/10/08/responsive-website-design-with-ress/

    0
  32. 83

    “Don’t always rely on media queries in CSS because browsers will load and parse all of the selectors and styles for all devices (more on this later). This means that a mobile phone would download and parse the CSS for larger screens. And because CSS blocks rendering, you would be wasting precious milliseconds over a cellular connection.”

    I don’t think pulling up the CSS only used for that screen size is a good idea. While currently mobile browsers (on a phone) are pretty static in size, that’s not going to be the case for very long. Tablet OSes like Windows 8 allow you to snap multiple browser windows or re-size them. Having the CSS for all view-port sizes loaded allows for the layout to re-factor to the view-port whatever size the user makes it. Including all the CSS, enables the user to display multiple websites on one screen by just making the browser window 400px wide for each site or they can make them full screen. Giving the user that flexibility is far more important than shaving a few lines of CSS code and dropping the load time by a couple milliseconds.

    Also, when I code my RWD websites, they share 80-90% of the CSS, and 98% of the HTML across view-port sizes. Only a little bit of CSS is used to alter the layout depending on screen sizes. While you may consider that code a waste of load time for mobile users, I think in the long wrong it’s a much safer solution to provide the user with flexibility.

    All of this depends on the given project, but I think this article really only applies to HEAVY web applications that are obviously loading a lot of material. In all honesty, even the desktop versions of these applications should probably reduce their load time.

    Mobile optimization is just as valuable to desktop users as it is mobile users. So why segregate so heavily?

    2
  33. 84

    La Casita Del Cuco

    July 29, 2014 7:21 am

    When I heard for the very first time about responsive web I was building a website with lots of blocks of full screen images. I guessed that on a little screen a hughe file would not be needed, so made from every image a version adapted to the screen width, so on a mobile a 320px or 480px wide image would be loaded.

    Now I am experimenting a lot with Javascript, SVG and CSS3 animation and guessed that for a mobile version of my website I am heavily updating at the moment I would leave certain elements out, or replace for example the portfolio part with a slide. Experimenting and working on that as we are speaking

    Very nice article Maximiliano, will give it a more closer look this afternoon and do hope that it answers all my questions I have now at the moment.

    0
  34. 85

    Thanks for the great article! I think you got to the root of the problem.

    I am an active mobile web user so I know how frustrating it gets when it takes too long to load a web page. What’s more, there are still quite a few places in the UK that have a very poor 3G reception. But being redirected to a mobile version of some website without letting me choose is the ultimate evil, especially when you can not access the proper version from a mobile device at all.

    What’s more I have to deal with this issue in my professional life as I am a freelance website developer. A lot of customers want to have a mobile version just for the sake of it. I have been using media queries and JavaScript extensively, but I found through trial and error that it’s a poor technique. It’s like trying to use a spoon for every kind of meal. Sure it works, but it’s not always convenient.

    So, I have adopted a combined approach that works for me. I use server-side detection solution from https://51degrees.com/Products/Device-Detection to identify if the device is mobile and get some additional parameters. Then I can supply the CSS files, graphics and scripts appropriate for the device. This method addresses two of the problems you have outlined: firstly it is incredibly easy to use, I have written a PHP script once and re-use it ever since. Secondly, you have mentioned graphics and images, I am using the integrated image resized which does the job in most cases.

    0
  35. 86

    Whew. That was a long article. And yes, some very good points on how to actual craft a “responsive website” and how to look past the way it looks. Behind the scenes action matter just the same.

    Actually, there are many tools to assist with this. For instance for WordPress I even created a plugin for this http://wordpress.org/plugins/ss-device-detector/ .
    It’s based on a library that can be used for other platforms as well but the principle is the same.

    Moving away from `display: none` and more into NOT loading a resource at all.

    Cheers

    0
  36. 87

    I would absolutely love to deliver unique content based on device type, but the reality is that this is just not practical for enterprise. Most CDN providers won’t allow you to vary on UA in the first place, and you wouldn’t want to if they did. UA strings are entirely useless because there are just sooooooo many of them. Varying on UA is completely broken and utterly useless.

    I agree that responsive is not the answer for a lot of sites, but if your concerned with performance so much that you don’t want to load unnecessary resources, you’re also concerned with caching.

    0
    • 88

      Hi Greg, in terms of big corporate sites I don’t agree that caching is a problem; of course, delivering based on UA is an issue; but there are other smarter solutions compatible with every CDN and proxy servers out there. Check for example WURFL InFuze. I don’t say that making things fast is easy, but it’s what you need to to do if you don’t want to lose users on some cases. Thanks!

      1
  37. 89

    lawrence howlett

    August 8, 2014 8:16 am

    @Maximiliano, “If you have the budget for responsive design, then you must also have the budget for performance.”

    The problem is that a lot of clients simply don’t and a lot don’t understand the upside either. Trying to educate them, to spend probably in the region of 20% or more on the project to improve performance is huge chunk to get an ROI on, even with case studies to show it would work. Take my article on http://www.smashingmagazine.com/2014/03/19/how-to-plan-your-next-mobile-e-commerce-website/ for example, there are case studies of great ecommerce improvement, but selling this to clients is another challenge in itself.

    Do you think digital agencies should be baring the cost of this as another value added service? Where does the line stop when your sitting with a start up on a smaller budget? Is this only for those with deeper pockets, I fear so.

    0
  38. 90

    Nice blog details thanks for the sharing.

    0
  39. 91

    Hi Maximiliano,

    I enjoyed your article post on responsive design as well, thank you for sharing.

    0
  40. 92

    Nice information and web designing is the essential part in all business identity websites.

    0
  41. 93

    Nice Article Maximiliano , the article change all my ideas in design , It great

    0
  42. 94

    Frederik Krautwald

    September 25, 2014 4:56 pm

    Finally, someone addresses these points on a popular medium that Web designers read. Perhaps Web designers will also start getting back to actually *designing* Web sites, instead of just copying every other RWD, making the whole lot look the same.

    0
  43. 95

    Responsive Website Designing

    September 29, 2014 5:15 pm

    If you site is fast, then onload can be only a few ms away, but if not, what then?

    0

Leave a Comment

Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or else it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!

↑ Back to top