Responsive Web Design Makes It Hard To Be Fast

Update: updated title and reference to mdot site below, following feedback

I like Responsive Design. Heck, I LOVE Responsive Design. I think it’s a brilliant methodology, which address true challenges in a very good way. But no matter how fond you are of RWD, I think you have to face the music – RWD makes it very hard to write a fast website.

I’m not saying you can’t write a high performance responsive website. I’m not saying you shouldn’t use RWD (Responsive Web Design) – I would actually recommend it to most organizations. However, RWD makes pages inherently more complicated, and all in all would make the mobile web slower.

What’s with all the doom and gloom?

What triggered this post was a great recent post by Tim Kadlec, titled “Blame the Implementation, not the Technique”. The post challenges all these absolute, black and white statements, and says good implementation can address most problems. One of his examples is that RWD websites can have high performance, if you just implement them correctly.

I agree with Tim’s general point. I’ve been talking about the common performance problems with RWD for a while now, and I’m certain most responsive websites out there have terrible performance simply due to poor implementation. I even work on a product that does that sort of acceleration automatically. You can probably make most responsive websites load dramatically faster – often 4 or 5 times faster – on a mobile screen.

However, there’s no escaping the fact RWD – by its very design – puts some real roadblocks in the way of a website trying to be fast.

So what’s the problem?

The problem is complexity.

In the world of the mobile web, the primary two options are a responsive site or a dedicated mobile website (a.k.a. mdot). To be clear, for the purposes of this post, a dedicated website site means a website design purely for a single (or small range) of screen sizes and contexts. For instance, an mdot site design for smartphones.

An average mdot site – a dedicated smartphone-oriented website – is a very simple site. For starters, it usually has a small HTML, that can be quickly delivered in a handful of packets.  In addition, it has very few scripts, CSS files and images, and each of those tends to be small. While mdot sites can have horrible performance due to various mistakes (see this deck for examples), they’re just naturally biased in favor of performance (compared to RWD).

Responsive websites, on the other hand, are complex. A responsive page – when loaded on a smartphone – would still require the browser to download and contend with a big HTML file. After the HTML, the site would need to take extra care to avoid running certain scripts, loading certain CSS and download certain images. Avoiding these resources is possible – and desirable – but it’s definitely not easy. In addition, even if perfectly implemented, avoiding those resources requires code and complexity, and has its own performance price.

You can’t escape this fact. A responsive website tuned to perform the best it can would not be as fast as a dedicated mdot site tuned equally well. Or more realistically, an average responsive website would always be slower than an average mdot site.

Update: It’s worth noting that responsive websites can also use a small HTML with scripts that dynamically generate more HTML on bigger screens. This is a good way to avoid DOM bloat, but it only replaces it with new performance problems created by these  blocking scripts, which delay rendering and get in the way of browser optimizations.

I don’t care. I’m going responsive whether you like it or not.

I know you are. And I would encourage you to do so. As much as it hurts me to say it, performance is not the only thing that matters for web pages. It’s also not the first time the web has gone against the performance track.

If you jump back to the early 90s, you’ll find many websites that are purely textual. These websites would perform AMAZINGLY on any browser. They’ll be faster than Google’s home page, and automatically adjust themselves to a screen on any size – as future friendly as it gets (especially when you consider they were created 20 years ago).

And yet, the user experience on those sites is horrible. The only value in making them fast is that users would very quickly realize they should go to another website. Optimizing your user’s experience must include performance, but I’m not naïve enough to think performance is all that matters, nor would I recommend that approach.

Then what should we do?

We should do what we are currently doing – keep pushing RWD, and make sure we push for performance awareness with it. Push developers and designers to consider performance to be a core requirement, and do the best to address it from day one.  Push browser vendors to make it easier to create fast responsive websites, like the effort to standardize responsive images. Push business to set performance goals and see bad performance as a show-stopping quality bug. On the implementation side, we should do what we can to overcome the main hurdles. Some good places to start here, here and here.

And at the same time, we should accept that RWD means a slower website. Just like Retina images give users richer but slower performance, RWD has its costs. We should accept that as a fact, and do what we can to mitigate the performance cost.

Posted on October 9th, 2012
  • Jason Grigsby, ☁4

    I agree with your general point here. As you know, the talk I gave at Velocity made a similar point. However, I have a small niggle:

    “A responsive website tuned to perform the best it can would not be as fast as a dedicated mdot site tuned equally well.”

    A responsive website tuned to perform the best it can would start with a baseline experience that was tiny, test for screen width, and then selectively load additional content and javascript.

    Other than the check of screen width, which would be nearly instantaneous, the responsive site would be as fast as the mdot site because it would have essentially the same content, html and css. In this scenario, it would be the larger screen resolutions that would would have the bigger difference between the pure desktop site and responsive one.

    Of course, this is mostly theory at this point because I don’t know of a responsive design implementation that takes that aggressive of an approach yet. But that is the direction a lot of folks are headed.

    • Guypo

      See my response to @micahgodbolt:disqus

    • Brad Frost

      Exactly. The fact of the matter is that responsive sites need to initially send down some form of logic to deal with large screens, while dedicated sites don’t. Poor responsive implementations simply shoe-horn desktop designs into small screens, but good implementations (like the ones you mentioned) minimize the impact by initially including essentially a bare-minimum, doing some very lightweight detection, and building up the more complex experience from there.

      I firmly believe this is where things are going, and I think techniques like conditional loading will allow us to create highly performant experiences that still achieve content parity and don’t sacrifice complexity.

      • Guypo

        As mentioned above, I agree this is a better approach, but it just mitigates the problem – it doesn’t make it go away.

        Introducing that layer of logic that applies the conditional loading would have its price, and will slow down the website, both on desktop and on mobile.

      • Roman

        Loading most of the content as a result of script execution would negatively impact SEO.

    • ronan cremin

      Jason, while I agree with you in theory, do you know any site that has actually managed to make this progressive enhancement work in a substantive way that works with a wide range of device capabilities?

      • Jason Grigsby, ☁4

        I believe not a lot of sites have done this because it is a fairly new approach. It took a year after I wrote about images the first time to get progress on responsive images and another year before it was being taken seriously by the W3C. The conversations we have are often a couple years ahead of where common development is.

        So let’s check back in a couple of years. ;-)

        • Guypo

          Quite possible, and I hope you’re right.

          I would still claim it’s never going to be as fast as dedicated, static HTML, but as long as the gap is small enough we may make our peace with it.

  • fjpoblam

    Some (many?) mobile devices have capacities more limited than their desktop/laptop brethren. If anything, RWD should yield a site *more* efficient than a non-responsive site

  • micahgodbolt

    Completely agree with @twitter-5774462:disqus –

    1. “require the browser to download and contend with a big HTML file” Why can’t our html be similarly slim? Start mobile first, then add complexity when needed.

    2. “the site would need to take extra care to avoid running certain scripts” — or only load base js and a single yepnope

    3. “avoid…loading certain CSS and download certain images” — similar to 2, progressive enhancement.

    Still a great article and wonderful conclusion. Just seemed to make a few over-generalizations about RWD pitfalls that already have solutions.

    • Guypo

      What you and @twitter-5774462:disqus suggest will help performance of RWD sites, but not equate it with mdot.

      Dynamically generated content slows down websites considerably. Browsers today have very sophisticated look-ahead behaviour that looks for resources further down the HTML long before they’re needed, and either starts downloading them or at least prepares to do so (by doing DNS resolutions, opening TCP connections, etc).
      Therefore, dynamically generated content is processed significantly more slowly than static HTML.

      In addition, waiting until the page is laid out to make decisions like what image to download (explained in detail in a great post by Grigsby a short while ago) introduces another delay.

      Note that I still recommend what you’re suggesting – it’s still much better to generate content dynamically than to download content you don’t need. It’s just not as fast as a dedicated, static HTML.

      • Jason Grigsby, ☁4

        My point wasn’t to argue that there wasn’t a performance hit, but to argue that a site implementing current responsive best practices would likely see the bigger performance difference between the desktop site and its responsive counterpart, not between the mobile site and its responsive counterpart.

        Like I said, it is a niggle. Not a big difference from what you’re saying.

      • SilentLennie

        Why not configure the webserver to load one of several static files based on certain criteria ? Only the choice of what content to load should be neede. The file(s) can still be static.

  • ronan cremin

    Minor point: we need to move beyond labeling the dedicated mobile experience the “mdot” site—this occludes the broader debate. It’s entirely possible to serve up multiple different experiences at a single URL—there need not be a separate “site” as such.

    • Guypo

      Good point, very true.

      • jordanwilson

        Extremely important point. mdot should be dead, but what’s the term for a non-rwd mobile solution @ single url? Most terms are too broad.

        • SilentLennie

          A mobile (site)design ?

  • Andi

    Thanks for the reading, many interesting points and much to consider for ALL web dev’s. Any one considering RWD should read and engage this. Standards and quality help will be common in the near future, just see google tends keyword: responsive web design. I wish that was my back account…

  • rethinkmobile

    Thanks for sharing the interesting post !

  • Web design Melbourne

    The website dedications are so additional with handful biased performance. It is small HTML handfull files of the packets. The best valuable making websites are so approach recommend.

  • nshankar

    We are actually at a point roughly 10 years ago, when page (a reference for good design) used to count 60KB and had everything it has today (600kb may be?)

    Honestly, we have screwed a good html tech with hapless js, css, and made it meaningless and difficult to design. Thinking of what? the bandwidth is cheap and browsers can handle the crap. It is now hampering mobile where the attention span is less than 10sec. (or till the screen goes black)

    The foundations remain the same every time. If you can’t deliver a pitch in 10 sec anywhere (elevator?), you’re gone.

    We can take this moment to optimize the web sites in general that opens up fast regardless of desktop or mobile. We will cut complexities.

    One solution is to introduce a small page that delivers the elevator pitch with buttons to navigate to other, relevant, thick pages. As this page loads fast anywhere, it helps the visitor to move to the real site and opt in.

    • Kolyan Mambozo

      Absolutely right. Stratigury, as G.W.B. once said. Some of these RWD’s are single-column centered layouts with typo-gliphics and minimum graphical elements mainly “drawn” by css. Very dry and maybe elegant but to smaller group of enthusiasts. The main thing that drives expectations from both side is actually still our intent, as users. If I’ll need to get something from searched by phrase and given page, I do not give a … but I’ll wait as long as needed. I’ll read, watch some visuals and either stop right there or simply continue my search. People who impatiently jerks between sites poorly implemented his/her search. Secondly, those who looking for information and following provided links are ALREADY MOTIVATED to wait, again – as needed.

  • Jenish Patel

    good point raised by you. Its matter of implementation. If its implemented and coded well than its gives a great benefit to you. But if its coded with huge images, or lots of content on a single page or huge page size than it will create panic in smartphone users as it
    takes long time to load and perform.

  • Shiva

    Right,Good to see these useful info here..Thanks a lot for sharing them with us….

  • Adam

    Trim the fat for all – avoid sniffing and the mdot. If you absolutely must have disparate sites then give the user the choice – don’t redirect for them.

  • Sandra Edwards

    Great blog. ive learned a lot of things from it!

  • SilentLennie

    OK, I like a challenge. You say responsive design could be bad for performance. I was and probably still am in the other camp.

    I’ve been thinking about this problem for a few days now. And I agree the complexity is a real problem. ;-)

    tl;dr/conclusion is: It isn’t so much about responsive design but more about sending the same content differently for the high latency links and the small caches of mobile devices. Responsive design is fine and we’ll use it to fit different screen or window sizes.

    I was working on moving the HTML of my site onto a CDN (kind of like whole site acceleration). Large parts of the page are static (they are cache-able for a limited time), for the small part that is dynamic I can use an AJAX request for example. So I’m still gonna do that first before I’ll work on mobile.

    Our audience isn’t very mobile, the subject and use of the content our site is targeted at desktop users because it is meant for downloading large files (this makes our site the exception to many, many others). So we didn’t have a mobile site yet. We still want to have one to show people what is available on the site.

    Here is my plan (not that I have time to execute it in the very near future, I have some other things to do first):

    - reduce the HTML even more than we already have, use an AJAX-request where we need it. As mentioned above this makes it also possible to serve the HTML from the CDN.

    - create 2 new URLs with the same content as the desktop version:
    http://www.domain.tld/m/ and m.domain.tld with a Canonical URL which points to the desktop version at http://www.domain.tld (for search engine robots)

    - employ serverside mobile device detection on the server for domain.tld (which normally redirects to http://www.domain.tld) to redirect to http://www.domain.tld/m/ The domain.tld can’t be handled by the CDN anyway a CNAME at the DNS zone apex does not work.

    - I might even use nginx to figure out if the mobile user is on WiFi (fairly low latency requests) and not redirect to the mobile version (look up: TCP_INFO socket option).

    - put a SCRIPT-tag in the top of the HTML, before anything else it detects the mobile device and redirects to /m/. You want the /m/ instead of redirecting to m.domain.tld because it prevents the extra DNS-request and TCP-connection.

    - The SCRIPT-tag is blocking, hopefully it prevents the rest of the page from being parsed (needs testing ?!!) which means no extra DNS-requests for domain-sharding domains and TCP-connections are done for things we don’t need.

    - a user that types: m.domain.tld is rewarded by not having to suffer the blocking SCRIPT-tag with redirect; it gets the mobile content directly

    - as the caches on mobile are so small, we’d probably just cat the HTML, JS, CSS and data-URLs for the images in one or very few longer files (sorted by when the content is needed so it can start to render the page immediately and display what is needed which it is being downloaded by the client).

    - the images in the desktop version already have a width & height so the size of the image is known, but we might want to use smaller versions for the smaller screen on mobile ? If so we’d use STYLE-tags in the mobile version and detect with javascript the screen size and a different URL for one CSS file with different dataURLs (for large screens will also include different sizes of the images on the page).

    - the JS should be downloaded as strings of which parts should only be evaluated when it is needed

    - because the URLs differ for the different HTML-versions we can place the HTML on the CDN as well (or have it cached).

    - very big maybe, we’ll use localstorage like bing and google search to store parts of the CSS/JS/data URLs and set a cookie so a return visitor doesn’t need to download it again.

    What do you think ?

    • Guypo

      Sounds like slide 53 of my “Performance Implications of Responsive Design” deck ( :)

      I definitely agree that you can make responsive websites much faster than they currently are, and many of your suggestions above are useful (some of them are related to mobile and not RWD, like the cache size comments). I tried to be clear about that in the post above, but from responses clearly it wasn’t emphasized enough.

      I also agree that the fluid aspect of responsiveness is less of an issue. The problem is with downloading & processing content (HTML & resources) that is subsequently hidden and not used.

      What I’m *also* saying, though, is that:
      1) Being fast on a responsive website is significantly harder than being fast with an mdot site. As a result, many/most websites are not willing to go through the effort and end up with slower sites – as per your own point above about not having time to implement your suggestions…

      2) These optimizations have a performance cost as well. So the most highly optimized responsive website is not as fast as the most highly optimized mdot site.

      • SilentLennie

        So maybe the summary is:

        Doing mobile fast is more complex than responsive design. Doing both is just annoying. ;-)

  • firesky

    great reading, I have to say it’s surely not our responsibility to be cognicent of performance in relation to responsive web design yes performance can be made optimal and yes there is cost associated with responsive images though I am willing to create high impact optimised images for a more visually orientated user. It has to come down to the broadband providers ultimately to meet user requirements on mobile devices.

  • ambreen11

    A responsive web design ensures that users get the best and consistent
    experience of a website on any device of the user’s choice and
    preference – be that the iPhone, the iPad, the smartphones running the
    Android OS, or the Windows OS and several others. As a result website
    owners and content publishers can need not exercise the option to build
    versions of their website for every popular device platform which they
    expect their audience might be using.

  • rob

    this is A great page. i found a page called its a fast and easy way to create and post your own web page.

  • Jafar

    Really all you need to do is use different “head” and “footer” areas which load specific JS CSS or image files for the viewing device.

    Using a PHP script like MobileESP and checking server side what device is trying to access the site is better in my opinion.

  • Julia Agnes

    wow! thanks for sharing this post

  • Web Development Company

    Now a days web design is the main part of the website an this is best for looking wise see your website..

  • metawizard2

    I work with a platform that takes one “application definition” and then spits out optimized websites for the different mobile devices and desktop web. We get a great deal of pushback from proponents of RWD saying that it is archaic to create outputs specific for each platform / browser, but if the underlying tool I’m using is doing the heavy lifting, isn’t that the very problem that RWD is trying to solve? Is there more to RWD than just getting the right look and feel for each platform that I’m missing, or am I stuck in the middle of a computing holy war?

    • Guypo

      There’s no simple answer, but a core concept in RWD is that identifying the devices is an eventually losing strategy. New devices don’t get identified well, it’s hard to bucket devices perfectly and many fall “between” device definitions, some operating systems (iOS) keep you from identifying a device on the server, zoom level/font-size are not controllable, etc.

      I think you’re better off positioning what you’re doing as an RESS optimization *on top* of RWD. A web page/site can be responsive, but it can be trimmed to remove content from known clients that will never require it (e.g. remove desktop-only HTML when delivering content to a smartphone)

  • Julia


  • sravt clave

    Thanks for sharing your valuable information,very useful info that you provided,
    Responsive and Mobile Web Designing Services in USA CANADA SINGAPORE UK