Cloud Four Blog

Technical notes, War stories and anecdotes

CSS Media Query for Mobile is Fool’s Gold

Read the follow up article written August 21, 2013

Ethan Marcotte’s article Responsive Web Design has caught the imagination of web developers. Several subsequent articles have touted the CSS media query feature as a way to build mobile-optimized web sites.

Even I’m guilty of contributing to this meme with my article on CSS orientation.

Unfortunately, CSS media query is fool’s gold for mobile devices. It hides tough problems and gives developers a false promise of a simple solution for designing to multiple screens.

The Short Version

Ferreting out the problems with CSS media queries for mobile devices is easy if you look at what media queries purportedly promise:

All you need to do to transform your desktop web design into something optimized for devices with smaller screens, less powerful CPUs, and slower network connections is to add more code.

The idea of adding more code—adding more to download—in order to optimize for mobile should be the first clue that this isn’t a good solution.

Core Assumption: Speed Matters More on Mobile

I’m going to point out several technical flaws with media queries. Nearly all of them rely on my belief that speed matters more on mobile devices.

That isn’t to say that we’re more tolerant of slow desktop web pages. Instead, that mobile is more likely to be used in situations were the speed of access matters more (urgently looking for a business) and under conditions (network speed, device processing power) that are less optimal for speed.

When designing for mobile, performance is a key consideration.

Letting the Browser Scale Images is a Bad Idea

Ethan’s article on Responsive Web Design relies on a technique he calls Fluid Images.

The idea behind fluid images is that you deliver images at the maximum size they will be used at. You don’t declare the height and width in your html, but instead let the browser resize the images as needed while using CSS to guide their relative size.

This technique is a bad idea for mobile for a couple reasons.

Full Images = Unnecessarily Large Files to Download

The full image is downloaded despite the fact that it will only be seen at a fraction of the size on a mobile device. In the Responsive Web Design example page, the images are 330 x 345 pixels in true size, but when viewed on an iPhone, they are only ever seen at approximately 150 x 157 pixels.

The six images of characters from Sherlock Holmes that are included in the example page total 208K. Resizing those images and optimizing them reduces the total file size for all six images to 45K. That’s an 78% reduction in file size and download time.

Original Resized K Saved % Saved
Total 208.3K 45.8K 162.5K 78.0%
Holmes 34.7K 8.1K 26.6K 76.6%
Watson 39.0K 8.4K 30.6K 78.4%
Mycroft 30.5K 6.7K 23.8K 78.0%
Moriarty 43.4K 8.2K 35.2K 81.1%
Adler 26.0K 6.6K 19.4K 74.6%
Winter 34.7K 7.8K 26.9K 77.5%

Downloading 162K unnecessarily on a mobile device is nothing to sneeze at no matter how good the mobile phone is.

Browser Resizing Can Be CPU and Memory Intensive

Yes, desktop browsers and iPhones have no trouble resizing images, but what about older or cheaper phones with less formidable CPUs? With this technique, we’re asking them to download larger images, uncompress them to their full size in memory, and then resize them to fit the screen.

Even Apple’s Mobile Safari documentation says “You need to size images appropriately. Don’t rely on browser scaling.”

Using Media Queries to Deliver Different Images Doesn’t Work

I know what many of you are probably thinking. So the fluid images technique doesn’t work. Let’s just use media queries to deliver different images depending on screen size.

There are two ways this can be accomplished. The first is to have image tags that are hidden by CSS. The second is to use CSS background images and switch the background image. Let’s look at both techniques.

Hiding Image Tags Using CSS Media Queries

Rachel Andrew‘s article about CSS media queries showcased dConstruct’s web site as an example.

dConstruct Desktop View

The dConstruct site is beautiful. The site grows bigger as your browser gets bigger. The photographs come to life when you hover over them. It’s truly worth a look.

The large photographs of the speakers are placed on the page using image tags. The black and white images are a single sprite that is layered over the color photographs using CSS.

dConstruct Mobile ViewAnd if you view the site on a mobile device, the large photographs of the speakers are hidden from view. You get a simple list that fits well on the screen.

A CSS media query instruction is used to set display:none on the div containing the speaker images.

However, the iPhone still downloads the images even though they are not displayed.

There was a some speculation during the Big Web Show interview with Ethan Marcotte that perhaps the tools that were reporting what the browser was downloading were erroneously inflating the number of files that were truly download.

To verify that images are downloaded despite CSS media queries, I tested two different ways. First, I made a copy of a page using the responsive design onto a local server, loaded it on an iPhone, and then watched the web server logs to observe what was downloaded. Second, I set my iPhone to use my Mac as a proxy server so every request to dConstruct’s site was logged.

In both cases, it showed the image files are downloaded despite the fact that the media query has set them to display:none. This means that the iPhone downloads an extra 172K for photos that the user will never see.

Hiding CSS Background Images

Surely CSS background images will work better than image tags, right? Wrong.

I tested a few different combinations of CSS background images and media queries. What I found was:

  • Using CSS media query to set display:none on an element containing a background image does not prevent Mobile Safari from downloading it.2
  • Using CSS media query to override a background image with one created specifically for mobile results in both the desktop and the mobile image getting downloaded.4

Two methods that appear to work are:

  • Setting the parent of an element with a background image to display:none.3
  • Using media query min-width declaration to only specify a minimum browser width for the desktop image and a max-width for the mobile image does result in only the mobile image being downloaded in Mobile Safari.5

These two options mean that using CSS media queries isn’t completely impossible, but using the parent element to hide images and changing existing desktop CSS to add min-width declarations are significant changes to existing CSS. It isn’t going to be as simple as adding a CSS media query for mobile and calling your job done.

FWIW, it is this behavior of downloading images even if they are currently not displayed that allows us to have images show up in pull down menus and on other hover events without a delay while the image is downloaded. This is generally a good thing.

CSS Media Queries Do Not Optimize HTML or Javascript

My first introduction to media queries was when we were asked to assist another web developer who had built a page that contained a Google Map on the desktop version, but the div containing the map was hidden on the mobile web version using a media query.

Unfortunately, even though the map no longer showed up, the 180K javascript library was still downloaded by the browser.

CSS media queries will not remove unnecessary html nor remove javascript that will slow down mobile browsers.

CSS Media Queries aren’t Supported Well

If you can overcome all of the challenges I’ve outlined above, you’ll find that CSS media queries are not supported by many mobile browsers. PPK’s compatibility table shows that even amongst modern smartphones, the support is spotty and inconsistent.

The picture is much worse when you decide to support older browsers.

If you choose to use media queries to provide a mobile version of your web site, you’re not only picking a poor solution, but you’re excluding a large number of mobile users.

People with modern smartphones may be the demographic you care about, but you should be make a conscious decision about what device classes you support.

Ignoring the Mobile Context

The promise of CSS media queries is that you can take your existing desktop web site html and add this additional presentation layer for mobile. Doing so ignores the fact that a mobile user may have very different needs than a desktop user.

There is a great quote from Brian Fling in his book on mobile design:

Create a product, don’t re-imagine one for small screens. Great mobile products are created, never ported.

Does your desktop web home page use geolocation lookups? Probably not. Should your mobile site home page? Quite possibly.

If you send the same HTML and Javascript to the mobile user that you do for the desktop user, even if you format it to fit their screen, you’re likely missing opportunities to provide a great mobile experience based on the capabilities of the device and the context of the mobile user.

Separate Mobile Web Sites are a Good Thing

I know separate mobile web sites are a pain to develop. We have a lot of infrastructure to build to make the mobile web go, and I’m going to be writing more about that soon. But there are good reasons why we need separate mobile web sites.

During Ethan’s interview on the Big Web Show, some time was spent discussing how sharing links from the New York Times doesn’t work the way you would hope. If you send a link from the mobile site and someone opens it on their desktop browser, it is still formatted for mobile.

The conclusion drawn from this during the podcast is that CSS media queries might be a better solution because there would only be one URL, and it would work for both desktop and mobile.

Here’s some hard numbers to consider from a YSlow examination of the New York Times desktop and mobile home pages:

YSlow results for the New York Times Mobile and Desktop Home Pages

As you can see, the mobile web site has a fifth of the HTTP requests of the desktop version and is 583K smaller. That’s over 90% smaller and significantly faster on a mobile device.

(As an aside, HTTP requests are much more expensive on mobile devices than on desktop due to the latency of wireless network connections.)

I agree that the NY Times links should work, but the solution isn’t to take the bloated desktop home page and add more CSS code to make it mobile (un)friendly.

Some Good Uses of CSS Media Queries

There are some good uses of CSS media queries. If you’re building a discrete web application where you have more control and can make sure that the desktop web isn’t bloated, it can make sense.

Also, Ros Hodgekiss from Campaign Monitor wrote an exceptional article on how you can use media queries in html email to provide a mobile optimized layout. This is perhaps the ideal use case because when you send html email, you have no choice but to send a single html document regardless of what device the recipient will be using.

Responsive Web Design Still Rocks

Wait? Responsive web design still rocks? Hard to believe after everything I’ve written, eh?

I’m not talking about CSS media queries, but instead of the idea of building around a grid, planning your design for different screen sizes, and thinking about the modular building blocks and how they can be moved based on screen size.

That is the real gem in Ethan’s article. I hope we see two things come from his responsive web design piece:

  • More desktop web sites that take advantage of fluid grids and CSS media queries to optimize for the multiple sizes of desktop screens. Media queries still make sense for desktop designs.
  • More designers and developers thinking about design as modular even if it isn’t implemented with media queries.

I find his comparisons to responsive architecture to be fascinating and the designs we’ve seen using these techniques to be compelling. But the core mechanism used to accomplish them, CSS media queries, isn’t up to the task when it comes to mobile development.

No Silver Bullets

Developing for the mobile web is difficult. There are no simple solutions that make it easy to provide a great mobile-optimized experience. CSS media queries are a tool, but they are not a silver bullet.

This shouldn’t be a surprise to us. We now take our content management systems for granted, but it wasn’t always this easy for the desktop web. We forget how difficult it was to simply get Apache running properly.

During the last big wave of technology, we had a lot of infrastructure to build before we could reliably deliver quality experiences for desktop browsers. We’ve got a similar road ahead when it comes to mobile.

But no matter how difficult, mobile is worth it. The power of having information in people’s hands—no matter where they are in the world—makes mobile worth the extra time and effort.

24 Comments on “CSS Media Query for Mobile is Fool’s Gold”

  1. Susan says:

    Thanks for the write up Jason. The place I’ve seen the media queries used the most are on people’s personal sites and I think depending on their own stats for who is viewing them, it’s not a bad decision. That being said, for a highly viewed site, such as the NYT – I agree with you.

    What do you think of Luke W’s ideas that when he talks about designing/developing for mobile he is talking only about smart phones and not the older feature phones. At An Event Apart Seattle, he talked about this extensively and basically I got the impression that he was not advocating trying to make something work for everyone, but solely for the iPhone, Andriod, etc market.

  2. B says:

    Great article. Much agreed. There are no simple solutions and you should always use the right tool for the job. Think performance.

  3. Jason Grigsby says:

    @Susan Thanks for the encouragement to finally write this up.

    First, regarding a personal site, people can do whatever they please of course.

    I do want to bring up one point regarding personal sites though. During the Big Web Show podcast, an audience member asked about the fact that the new responsive web design version Jon Hicks’s web site was 4.5MB. I love what Jon did with the design, but if the mobile site is 4.5MB, then you haven’t built a mobile site.

    Regarding the phones you target, it depends on the business, your customers, and what you are trying to accomplish. To say that one size fits all would be crazy. Each site has to be judged separately.

    But even if you only target smartphones, this isn’t a good technique. It is inconsistent even for smartphones. And there is a reason why I can’t find any of the top web properties using this technique.

    Finally, I’m planning some follow up articles regarding the changes that need to be made to web infrastructure to support mobile. In order to talk about why those changes are necessary, I first had to show that simple solutions like CSS media queries have big problems. More to come. :-)

  4. Lars Gunther says:

    Re the useless downloading of unneeded files on the iPhone. have you tested this with other browsers, like Opera mobile, Fennec or on an Android device? It would be fun to know if this is a general problem or an iPhone specific bug.

    Also, I do not see an open bug for this in Webkit’s Bugzilla. Perhaps it should be reported?

    A bigger issue for the future is how to make effective conditional downloads of scripts and other resources that by design are unaffected by mediaqueries. Checking viewport width or the display value of a div with a very small script and dynamically inserting a script tag should work, but it’s not a neat solution.

  5. Eddie says:

    Good article… you put in writing what I had been thinking about the topic, and then tested it too! Nice work.

  6. Jason Grigsby says:

    @Lars I didn’t test on other devices. Figured that if the iPhone had problems that it would be enough to convince people this technique wasn’t ready for prime time.

    FWIW, I did test on the desktop browsers. Safari and Chrome both act exactly like the iPhone. Firefox downloads images, but otherwise doesn’t download the other images. The disadvantage is that you get a flicker effect as you widen the browser screen.

    I haven’t reported it to Webkit because I’m not convinced it is a bug. Preloading images that *may* be used by the browser is probably a good performance technique and avoids flickering when images load.

    You’re correct about the bigger issue. It is unneeded or unnecessarily large HTML, JS, CSS and images that are problematic. When you look at the whole picture, it becomes clear that even if media queries worked, you’d still need to look back at your content management system to handle image resizing, minimized html, etc.

  7. Pim Derks says:

    While I do agree with your article and it definitely has an extremely valid point, what about this situation: a client has a limited budget, but wants his site to look good on iPhone.

    While I definitely do agree that a mobile website should be optimized for mobile phone, fact is that a lot of clients (at least, the clients I work for) don’t have the money for a seperate website. Two options:

    1) Do nothing: mobile users see the same website, but it’ll have columns etc and won’t be easy to navigate through.
    2) Use media-queries: visitors will be able to use the site and read it’s content more easily. If your HTML is clean and lean this’ll probably take very little of your time.

    In both scenarios you will have the same usage of bandwidth and the same files which will be downloaded. Maybe I’m missing something, but I would take the 2nd option? (disclaimer: I have very little experience with developing for mobile devices)

    Ofcourse a separate mobile site is way better and should definitely be considered if there is a budget for it for all the reasons you mentioned in your article. Just my 2 cents :)

  8. Jason Grigsby says:

    @Pim Your points are completely valid. I agree.

  9. Trygve Lie says:

    You point out a problem with CSS queries I’ve been thinking a long time.

    But; there are a difference in browsers here. As you point out; iPhone will download a bunch of images the user will not see when queries are used to hide them. I recently found out that Opera Mini and Mobile does not. Opera keeps track of what will be visible for the user and only download the data needed to present the page for the user. All other browsers does not. Opera does not download the extra data which iPhone download.

    This is a strategy I think all other browsers should adopt.

    I discovered this while looking at fallback solutions for SVG trough using the embed element and a fallback image inside the embed tag. It turns out that Opera does not load the image inside the embed element since it can display the SVG attached to the embed tag:
    http://www.trygve-lie.com/blog/entry/svg_embed_and_performance

    You have the same pattern for all browsers when it comes to CSS queries.

  10. I am very curious how you provide one (small) image voor all mobile devices, since there are big differences in mobile screen resolutions (e.g. the new iPhone’s screen resolution is twice as large as the previous versions). Have you seen some (old) iPhone apps on the iPhone 4? They look horrible, because they didn’t make their apps flexible.
    For me the only way to target all screen sizes is to deliver the image at the maximum size it will be used at. Images don’t block the download of HTML, CSS and Javascript anyway. The website can always be used before the images are loaded and/or when they’re hidden.

    It should also be noted that you can use media queries the other way around. If you use one stylesheet, you can put all default styles (color, typography, vertical margins etc.) first (without media queries). Then you can use media queries to define the wider screen styles (you only need a conditional comment with an extra CSS file to include the wide screen styles for IE<9).

    For your comments about mobile context I would advice to check one of the "Mobile first" presentations of Luke Wroblewski. If a mobile site is made after the desktop version, it appears that often the mobile version is actually better because it's more to the point etc. The fact that mobile users don't have much time or are task focused does not mean that desktop users have time to waste. Think mobile first and your desktop version will also be better. And if you use Geolocation for your mobile users, why exclude that function for desktop users (who can also be netbook, notebook or iPad users)? How can you make that separation of just mobile and desktop? There's so much more in between.

    I also think the comparison of the mobile and desktop version of NYT is not fair. The amount of HTTP requests on the desktop versions should be just as low as on the mobile version, because files of the same type should be joined together, so there's only one HTML, one CSS and one JS file. CSS images can be replaced with Data URI's.

    In my opinion (fast) mobile versions can perfectly be made with media queries. All it takes is some clever thinking (and use of minification, gzipping, caching, data URI's etc.).

    Without media queries your website can never be future proof for different devices.

  11. Jason Grigsby says:

    @Trygve Interesting stuff on Opera and SVG.

    I’m not sure I agree that Opera is handling it correctly because pre-loading images prevents the flicker effect. That said, I haven’t spent much time thinking about what browsers should do.

    Because CSS media queries don’t address javascript, html, etc., even if the images were supported, it would only be partial solution.

    SVG has been on my list to dig into so I’ve put your post into Instapaper for reading this weekend. :-)

  12. Jason Grigsby says:

    @jaspervdkamp Thanks for commenting. A few notes:

    * I never suggested providing one small image for all mobile devices. I don’t know where you got that idea. If anything, differences in resolution also point to the need to address different device classes with different code and images.

    * There are alternatives to delivering images at the maximum size. Delivering at the maximum size despite everything we know about how speed impacts usability–particularly on mobile–seems shortsighted and will impact a site’s ability to meet its goals.

    * “Without media queries your website can never be future proof for different devices.” I disagree. Look at http://mobiforge.com/designing/story/effective-design-multiple-screen-sizes or NPR’s COPE http://blog.programmableweb.com/2009/10/13/cope-create-once-publish-everywhere. That’s how to be truly future proof a site.

  13. What about doing a media query via the tag? That way, you load up an entirely different stylesheet for mobile devices?

    Here’s someone who talks about doing just that:

    http://forums.macrumors.com/showthread.php?t=924162

    and there’s an example here:

    https://developer.mozilla.org/en/css/media_queries

  14. Jason,

    I appreciate you challenging the conventional wisdom and pointing out some shortcomings of media queries. I think calling them “fool’s gold” is a bit over the top, however.

    I wouldn’t have expected them to prevent images that are linked from a stylesheet from loading, for example. The use cases you debunk seem to me to be based on a misunderstanding of what media queries can do.

    Properly used, I think they are far from fool’s gold. Used in the right way, they can be an extremely effective tool in our mobile app building kit. The biggest knock I see right now is the lack of support for them in (some versions of?) Android.

    Regards,
    -Andrew

  15. Jason Grigsby says:

    @andrew It’s great that you wouldn’t have expected them to prevent them from downloading, but the people who have been pushing media queries did.

    Perhaps fools gold is over the top, but listen to the Big Web Show podcast and see if you feel the same way. My jaw dropped listening to Dan Benjamin, who I like a lot, talking about how even if the page was 4.5MB, that it was worth it because of how cool it is.

    When I reread my post, the sentence that stands out to me as being clearly what I meant is:

    “It hides tough problems and gives developers a false promise of a simple solution for designing to multiple screens.”

    I might rewrite that slightly to say:

    “CSS Media Query for mobile–particularly as it has been thus far promoted–hides tough problems and gives developers a false promise of a simple solution for designing for multiple screens.”

    I stand behind that statement a 100%. The big problems aren’t CSS or reformatting for the screen. The big problems for mobile web are:

    * Content management systems designed before mobile that don’t separate out text from images and video which are necessary if you’re going to provide those assets in multiple sizes.

    * WYSIWYG editors for content authors that allow the creation of content that won’t republish anywhere.

    * HTML templates, javascript and css that assume desktop bandwidth, cpu, and caching behavior.

    These are BIG problems. My conversations with clients over the last year has made me realize how big these problems are. Our existing web infrastructure is ill-suited for the mobile web.

    If people promote CSS Media Queries as a tool to use when overhauling their site structure in the way @ppk suggests (http://www.quirksmode.org/blog/archives/2010/08/combining_media.html#more) where the result is HTML, CSS, and JS that starts for mobile devices and then is enhanced further to be desktop aware, then I would have no issue with it. But until I wrote this post, not a single article described it that way.

    Two final thoughts:

    1. I don’t understand why web developers are so obsessed with delivering the same HTML to different devices. There’s a reason why mobile developers have been using WURFL for years.

    2. I think there is a good reason why no one has implemented media queries on any major web properties. I believe that media queries are the idealized version of what should be done, but that when you have a real site with business objectives, you end up doing what Google, Yahoo, CNN, Twitter, Facebook, DIGG, etc. have done which is detect what the device is and deliver the same content with different HTML.

    Perhaps this is like the adoption of web standards and we’re just waiting for a large site to validate this approach. Or perhaps no one is using this technique despite how important mobile is to their businesses because they evaluated it and found that it to be insufficient.

    FWIW, I would love to be proven wrong. :-)

  16. @Jason,

    Thanks for the thoughtful response. I agree with your standout sentence as well. I was just surprised that media queries were being proffered this way! I came to them through developing iPhone web apps, where the whole experience is tailored to that mobile device and where media queries are just a technique I can use to, for example, detect device orientation or deliver slightly larger fonts for an iPad. Using a technology because it’s “cool” is almost always a recipe for a sub-standard experience.

    Thanks again for writing this and prompting a much needed discussion of the topic!

  17. James Pearce says:

    Spot on – great post. Just another tool in a big mobile toolbox.

    +1 for context… the most important point. If there’s a media query that will turn an airline’s desktop site (flight booking, credit card promotions, photos of reclining seats, chairman’s statements etc) into its corresponding mobile site (flight time checker, on-line check-in, QR-code boarding pass etc), then I would love to see it.

    On a practical note, for flexi-image rescaling without having to touch markup (or indeed CSS), you might check out http://tinysrc.net

  18. Great article, thanks!

    Two solutions spring to mind. The first is a hint on image references (both in CSS and HTML) that they should only be loaded if actually required for rendering, not speculatively. We do know when images should be ready for use immediately (eg on a user action) versus ones that if not needed will never be, and we should be able to tell the browser that clearly. Media queries should not (and do not as you point out) give us that as some of them might change.

    The other solution seems to be to baseline at a mobile site and progressively enhance to the desktop experience through Javascript, effectively moving the media queries into Javascript code. As you say, starting at desktop and trying to cut stuff out doesnt work, but going the other way could, and is much more in the spirit of progressive enhancement. This still leaves some issues with high screen density mobile devices potentially, but a better general baseline.

  19. [...] the end user. Jason Grigsby (@grigs) sums up the issue from a technical perspective in his article CSS Media Query for Mobile is Fool’s Gold: Ferreting out the problems with CSS media queries for mobile devices is easy if you look at what [...]

  20. Kevin Peno says:

    Another strong point against @media queries is that they don’t define the device. You mentioned that briefly in your article, but mostly related to user agent sniffing to redirect to a mobile html file/server. So one must ask, “Why do we have to rely on user agent sniffing????”

    I also see MOST people out there thinking that, just because they set max-width to 900px, it will make their site “mobile”. This is absolutely not the case. In fact, from my experience, MOST internet users DO NOT keep a browser open full screen. Thus, MOST internet users using a browser supporting media queries are likely to be served a “mobile” look. What about those people that shrink the window size to the cutoff point (say using the windows 7 drag to side feature to compare one page to another). The will be looking at one thing and have the site TOTALLY change on them during the transition.

    Are you looking to provide a slim look to everyone?

    CSS has a system for handling what kind of device it is, in @media queries no less. Its the handheld, screen, print, etc media types. However, in an effort to over glorify their new mobile devices as the future, mobile web browsers have decided to inconsistently support the handheld type. Most of the newest totally ignore the handheld media styles altogether and, worse perhaps, some import both handheld AND screen as valid types.

    In the age of “standards compliant browsers” why aren’t we crying foul on this?

    User Agent sniffing is a black art that, especially in the case of CSS, should have died a long long time ago. Are we going to continue to be doomed to string parsing hacks that have plagued us from the dawn of the internet for displaying content? Why doesn’t the CSS3 media spec standardize any of this?

  21. [...] started to get interesting with a counter-article by Jason Grigsby titled "CSS Media Query for Mobile is Fool's Gold". Jason claims: Unfortunately, CSS media query is fool’s gold for mobile devices. It hides tough [...]

  22. Very good article.
    I think we are still in the learning stage when it comes to mobile web.
    There is still a lot of people thinking that mobile is just a matter of adding more CSS, more images, etc
    Your “Short Version” statement, on solving the problem with more code, puts it beautifully.

    Lately I have been earing some opinions that “these new smartphones display full desktop websites just like a regular PC. Some of them even have Flash”.
    Obviously, the people thinking this way need to buy a smartphone and subscribe to a data plan right away.

  23. John Boxall says:

    Interesting article.

    A few notes – there is a longstanding Webkit bug (reported by none other than Thomas Fuchs of Prototype fame) regarding the lack of a way to abort the loading of an image asset: https://bugs.webkit.org/show_bug.cgi?id=6656

    Secondly – cowpaths are being paved for the ability to prevent the load of external resources via JavaScript. Look at the AdBlock extension for Safari to see this in action today. A special JavaScript event “beforeload” is called on every external resource. Using “preventDefault” the loading of the external resource can be prevented.

    Expect to see this in other webkit browsers soon!

  24. Erwin Heiser says:

    The reverse could also be asked: why does a desktop website need 27(!) javascript files, 5 stylesheets and 50 images?
    Whatever happened to keeping it lean and mean?