What are Responsive Websites made of?

A few weeks ago I tested (again) nearly 500 responsive websites in different resolutions. My test was focused on size differences between resolutions, but looked at the overall page size as a single unit.

In this blog post, I’d like to dig into the same data, but this time drill down into the specific types of resources on the page – Image, JavaScript, CSS and HTML files. Such a drill down can give us better insight into which optimizations are being applied today, and help guide us regarding where to focus our performance evangelism.

RWD Page Size

The average size of an RWD site ranged from 1,187 KB on the largest screen to 1,093 KB on the smallest one. The next chart shows those page sizes split into the four primary content types mentioned above, plus an “other” category to capture the rest.


As you can see, the overall size doesn’t change much, which was the point I made in the previous post, so I won’t fret over it too much now. However, the chart captures some new interesting tidbits, which I’ll go over in the next few sections.

It’s worth noting that while I’m only digging into 2013 data here, most of the observations seem to hold true for the data I collected in 2012.

Images make up the vast majority of bytes

As expected, and matching the trend we see across all websites, images make up the bulk of the bytes. Images account for about 6x the average weight of JavaScript files, and 9x that of CSS.

Images are also consistently the biggest component on a page, regardless of screen size. This implies optimizations like Responsive Images, which deliver smaller images to smaller screens, are not being applied.

Only images are optimized to screen size

Across resolutions, the only resource type that truly changes in size across resolutions is image. CSS, HTML, JavaScript and the (tiny amount of) HTML all stay the same across resolutions.

I see this as an obvious sign of inefficiency. Consider the complexity of the “mobile” view (on most RWD sites) compared to that of their “desktop” view. In many cases, the number of interactions or widgets on the page is much smaller, and yet the same amount of HTML, JS & CSS is delivered (and processed) to all screen sizes.

Clearly images are not optimized well enough either, as mentioned in the previous section, and given their size images are probably still the first thing to optimize. However, compared to other resource types, images are miles ahead.

RWD sites are “lighter” than regular desktop websites

Even on the largest resolution, the average page weight in this test suite is ~1.2 MB. This is quite small compared to the overall ~1.4MB average page size, and almost on par with the average home page size of the top 100 websites.

Given the performance issues on the smaller screen, I wouldn’t claim RWD developers are more performance aware than average. However, RWD does force you to think about what’s really needed on your page, which can lead to less clutter on the page – and thus fewer bytes.

And of course there is the possibility the sites inventoried by http://mediaqueri.es/ are not representative enough to compare to the bigger list of websites HTTP Archive tracks. Until we have more known RWD sites we don’t have much we can do about this concern, except take some of the comparisons with a grain of salt.

RWD sites use less JS and more CSS than average

Somewhat surprisingly, only ~10.5% of page bytes (on average) came from JS files, compared to ~15% on websites in general. The gap sounds even bigger in absolute numbers – an average RWD site uses ~120KB of JS instead of the overall average of ~220KB. This may again be attributed to the more minimalist design, or perhaps the need to make these sites work across more old mobile browsers – thus relying less on JavaScript.

However, RWD sites compensate for that with CSS weight, which accounted for 7.5% of RWD site page bytes, compared to 2.5% or less on websites overall. Despite being smaller overall, the average RWD site packs 85KB compared to the 36KB an average website uses – roughly 2.5x more. This part is not surprising at all, as much of RWD relies on CSS, and browser compatibility often requires duplicating CSS content, but it seems to be an area to improve in.

Comparing Requests

Since performance is made up of more than just byte download, this second chart outlines the average number of requests per resolution, again split by content type.


This chart mostly reinforces the insights I mentioned above:

  • Total number of requests doesn’t change much across resolutions
  • Images make up the majority of requests, by a large margin (though not quite as large as the gap in bytes)
  • Average total number of requests – roughly 41 – is quite low compared to the overall average of 91.
  • Total number of JS requests is almost half the average number

Unlike what we’ve seen with bytes, even the number of CSS requests is lower than the overall average of 5, though higher than the top 100 average of 2.7. In other words, RWD sites seem to have bigger CSS files, not more of them.

Seeing that the average RWD site uses only 41 requests is encouraging, though it could also imply complex websites don’t feel like RWD is a valid option for them. Another explanation could be that current RWD implementers are – on average – better developers & designers. RWD is still a new trend, and talented teams are more likely to be early adopters, making today’s numbers better than what they’ll be in the future.

Image Optimization – Requests vs. Bytes

RWD image optimization focuses on two main areas:

  • Not downloading hidden images
  • Downloading smaller images on smaller screens

I was curious to see if websites implement one of these more than the other. To check if that’s the case, I plotted the number of image bytes and image requests side by side, across the different window sizes.


You’d notice the two lines are quite cleanly aligned. This indicates (though it’s hardly scientific proof) that both optimization aspects are equally popular – though calling either popular is a stretch, as most websites don’t apply either.

I would suspect most RWD sites either optimize images or not, but if they do – they optimize both aspects. Helping this theory is the fact most responsive images tools, like PictureFill, also implicitly avoid handling hidden images.


This data gives us some good further insight into the state of RWD websites today. We can now say that:

  1. The push for using responsive images is reaping some fruit. There’s still plenty of work to do before we’re in a good spot, but we’re making progress.
  2. Pretty much all other aspects of RWD websites, are not optimized to screen size. We should further evangelize serving just the right amount of HTML, JS and CSS to clients, and build supporting tools.
  3. It’s possible that RWD naturally helps reduce clutter and thus make web pages leaner. While not a factual statement, the data we currently have points

Remember that these conclusions, and for that fact all of these data, refer to the state of RWD today. It doesn’t mean responsive websites always behave this way, it just indicates what is actually happening in implementations today. I’ll keep tracking them, to help point out how we’re doing, and where we should focus our attention next.

Posted on April 29th, 2013
  • http://www.josiahsprague.com/ Josiah Sprague

    It would be interesting to be able to drill down into this data a little bit more. I bet more custom-built solutions (built without a lot of bulky plugins and frameworks) have even better numbers. Part of the problem is that a lot of developers just add plugins and prebuilt things to their website to get certain features without considering the performance impact.

    • Guypo

      I completely agree.

      That said, my attempt here was to focus specifically on RWD, so perhaps the right point to highlight is that plugins are not RWD performance aware. As a result, they do not optimize to avoid downloading their content if not actively displayed, or minimize their payload on a smaller screen.

      • http://www.josiahsprague.com/ Josiah Sprague

        I guess my thoughts are that RWD isn’t a plug-and-play thing. All of the pieces of the website puzzle have to be put together with an intentional design towards RWD. I bet if we could look at the data for intentionally designed RWD sites vs slapped together plug-and-play RWD sites, we’d see a huge difference.

        • http://about.me/morula/ Morula

          I couldn’t agree more, very well said!

  • http://www.facebook.com/scottiee Scott Lucas

    Regarding responsive images: With the latest smartphones sporting a Full HD display with a resolution that a desktop user could only dream of it is a losing battle to send small images to small devices.

    Of course it would make sense with the few left devices which have a 1024×768 frame, but then you have to question whether it is worth it.

    • Guypo

      Fair point, and it comes up often. The bottom line decision of whether a small screen should get a small image despite a high resolution is a matter of perspective.

      In my opinion, if a screen is small then the value of a high quality image is lower than on a big screen – even if the pixel resolution is the same. Even if you disagree, you can still consider using LQIP (http://www.guypo.com/feo/introducing-lqip-low-quality-image-placeholders/).

  • Morningtoast

    I’m wondering if these numbers were calculated on the initial visit or on subsequent pages on the same site. Obviously the initial visit to a site will be heavier than following pages due to caching…which in some ways is why the case of optimizing by limiting size/requests might not be a hardline solution. If the initial visit downloads 800k of stuff but every page visit after that results in less than 100k thanks to caching, is the 800k really that bad? Shoving all that size down the pipe each time is clearly a problem but there are some arguments to front-loading resources.

    • Guypo

      Yes, these numbers are based on a clear cache experience – first visit.

      However, mobile cache sizes are quite small (see http://www.guypo.com/uncategorized/mobile-browser-cache-sizes-round-2/), and so you should assume many users will hit your site with a cleared cache, even more than in the desktop world.

      You’re right that caching is a good practice, and that it can accelerate next page views, but that’s fully complimentary to the problem I’m describing. I didn’t test how well do RWD sites handle caching resources, but the overall stat is not that exciting, with only ~40% of resources being cached (http://httparchive.org/trends.php#maxage0).

  • http://ecmazing.com/ Šime Vidas

    “…right amount of HTML, JS and CSS…”. While the amount of CSS and JS may be different for different resolutions, the amount of HTML should stay the same, as one should provide the same data to the visitor regardless of screen resolution. Correct?

    • Guypo

      Nope. Try loading a responsive website in Chrome, and resize chrome to be as small as it can be (making the website quite small too).

      Then use Chrome Dev tools and see:
      1) How much of the DOM is hidden (display:none)
      2) How much of the DOM is below the fold (in general, but even more so in comparison to the desktop view)

      You’ll find that in many websites, there is a lot of never-seen or rarely-seen HTML content, which caries download time, CPU and memory costs.

      • http://ecmazing.com/ Šime Vidas

        That’s what sites are doing, but it’s not a good practice, is it? My original point was that the same content (i.e. the same amount of data) should (ideally) be provided to all visitors, regardless of screen resolution. There are exceptions of course (certain type of content isn’t appropriate for small screens, or big screens) but, generally speaking, the amount of data distributed to the visitor should not depend on the screen resolution. So, when creating RWD sites, the developer should have one set of data for all visitors, and then define different sets of JS, and CSS code for different resolutions.

        • Guypo

          It depends on your interpretation and what you’re comparing to.

          If you thinking pure RWD, then yes – return the same HTML to all screens, try to make it as small as you can, and decide stuff at the client.

          If you’re thinking RESS, then you may want to return an optimized HTML to different screens.

          And if you’re comparing to dedicated mdot sites, then the fact the HTML is the same size across the board implies RWD is less performant

        • http://www.claudioschwarz.com/ Claudio Schwarz

          Maybe the article from Laura Kalbag is interesting for you:


          In my opinion you should hide as less possible elements in RWD.

  • http://www.websitetemplates.org/ Stacy Summers

    amazing post! thanks!

  • myResponsiveThemes

    wow! amazing info, very interesting, thanks for sharing.


  • fiswebdesign

    This is really amazing and very useful post. Thanks for sharing this here with us.