Prioritizing Performance in Responsive Design

Last year, Guy Podjarny ran tests on hundreds of responsive sites on and found that a full 86% of responsive sites send about the same hefty payload to small screens as they do to large screens. In other words, mobile users are downloading desktop-sized sites. Not good.

He ran the tests again this year and found that a few more responsive sites’ small views weigh less than their large screen counterparts. This may seem like progress, but Guy also mentioned that page weight overall is on the rise, so in my eyes any victory is quickly negated by overall page size increase.

What to Do About It

This trend needs to stop. How do we fight against bloated web pages? Here’s some things to consider:

  • Treat Performance As Design—It’s essential for everyone, not just developers, to make performance a priority. Performance is invisible and as a result slips between the cracks in projects. It also gets super technical super fast, which causes non-developers to lose interest. Change the nature of the conversation by talking about performance as an essential design feature. Boss or creative director not convinced? Point to Facebook’s app debacle as evidence that performance makes and breaks a product.
  • Set a Performance Budget—One great way to make sure performance doesn’t slip between the cracks is to set a performance budget. Set a maximum page weight, which forces everyone involved in the design process to make some tough, realistic decisions about what deserves to end up on the page.
  • Embrace Conditional LoadingConditional loading is one of responsive design’s most important techniques. From social widgets to images to maps to lightboxes, conditional loading can be used to ensure that small screen users don’t download a whole bunch of stuff they can’t use. Here’s a bunch of resources about conditional loading that explain why it’s so important and awesome.
  • Test oftenMobitest is a great tool that fires up a site up on a real mobile device and spits back page weight, load time and other performance-related stats. It’s a great gut check tool, but there’s no substitute for firing it up on your device while walking around town on a real cellular connection. Test on real devices early and often and you’ll see the true performance of your design.
  • Look for low hanging fruit—There are tons of little things we can do to improve the performance of our websites. I’m a big fan of using Yslow and Google Page Speed because they explain everything in relatively human terms and give you explicit instructions on how to make performance better.

Let’s prioritize performance in our responsive designs. I hope Guy runs his tests next year and is pleasantly surprised with the results.


  1. Thanks for doing this and saying this stuff. It gets me seriously frustrated at what devs are doing to their web apps today. They are killing themselves with laziness.

  2. Performance is often an afterthought by most devs. Going through the “pains” to ensure responsive websites are optimized for performance is one of the reasons some people choose not to adopt RWD

  3. Thank you for the post. I am definitely going to share this with my fellow devs. I wish more people treated this as a high priority during the build and not just a afterthought.

  4. I don’t think mobile sites being the same size as desktop sites is really the problem. It’s that sites are too damn big overall.

    In a brief rant on this a few,on the back I wrote:

    “There’s two things I don’t like about these kind of blanket statements. First, they lump same-sized sites with bigger-on-mobile sites, which positions them as a bad thing. And indeed, they can be for larger sites. But that brings me to my second point.

    The relative size of desktop versus mobile is not as important as the absolute size of the site itself… In a perfect world, the mobile version would be smaller. But decreasing the overall size of the site and the number of HTTP requests benefits everyone, even the desktop users, and results in better mobile performance, regardless of the relative-to-desktop size.”

    Full post:

  5. It’s important to note that payload size is only one aspect of site performance.

    For responsive sites looking for quick performance wins I would recommend:

    1. Unblocking rendering by moving synchronous JavaScript to the end of the document.
    2. Using correct caching headers
    3. Using a CDN to distribute static content

    Before looking at shaving bytes by optimizing payload size.

  6. andreas

    you can not say so easily that mobile should be smaller. sure it is important not to so much nonsense around, no matter what screen size. to make the smallest more performance – why? what if i use my cellphone with wifi and my laptop at trips with a small bandwith. then it turns your optimization. performance in general is important and not focused on a screen size.

  7. Thank you for this. As a designer, it used to be hard to factor this into my creative process, but if you force yourself, it will become second nature. Just like any other technique you use on every design. My business partner is a developer, and is pretty obsessed with page speed on every platform. We are forced to find a happy medium between elegant design and optimal performance on every project. I think that is the key. Obviously if you wanted your page to run at hyperspeed you could leave design out of the equation completely. Then you’d have the ugliest site ever. On the flip side, it’s probably not necessary to load an entire new style of font just to have a testimonial be italic on the homepage. Find a good balance, and the site will be fast and pretty!…Oh, and maybe some of that developer voodoo that I know nothing about might help too 🙂

  8. Great post, Brad. Performance is a design feature, as design is meant to be used. This is also why I consider usability to be a design feature. Our sites are ultimately meant to work for people. Making them wait longer for a bloated page doesn’t work too well for them. Performance optimization should be part of the process, not an afterthought.

    At the same time, our sites should be engaging, which great design does help. It took a while to think of design as more than just how it looks, but the returns have been great in shifting from that frame of thought. I firmly believe that beautiful performance isn’t removed from beautiful design, but should be baked right in.

  9. Brad – lots of good points well made.

    One driver for page bloat is agile development where a baseline performance test is hardly ever done so no-one sees the performance hit of subsequent sprints.

    Also the effect of variable mobile bandwidth is rarely factored in. This alone can have a huge impact on user experience.

  10. Treat performance as design, that’s my “aha!”, thanks for the article

  11. Greg

    This is all true but the frontend is only one part of the job. To consider the amount of loaded code and content most ot postings alike forget the backend (CMS) process that needs treatment. That means wee need best practice solutions for the most used CMS’s today.

Comments are closed for this post. If you've got something to add, feel free to reach out on Twitter.