Respond.js Performance? about html5please

[paulirish]

haha i knew this would happen. :)

so there are two factors of the overhead. stylesheet parsing and superfluous XHRs. the XHR should mostly be mitigated if you have expires headers, but the parsing is a tricky beast and can break depending on certain syntactical constructs.

but since the issue is on perf.. i suppose the onus is on me to provide the perf evidence. will do.

[scottjehl]

Thanks for adding the issue, @davatron5000. As creator of the script, what I say can be taken with salt, but I'm also curious why a polyfill (there are several) wouldn't be good advice here. I'll try and explain.

Paul, I'm looking forward to seeing what you come up with for performance, but I'm not sure what we're comparing Respond's performance to: other media query polyfills? To not using a polyfill at all?

I think we can all agree that running Respond.js is going to be slower - quite a bit slower perhaps if you're talking in milliseconds - than NOT running Respond.js. I've done a great deal of work optimizing Respond to run as fast as possible in IE, favoring version 8, and for what the benefits it brings to users, I'd suggest that it's fast. It's not native-fast, but for IE8 users, probably fast as they'd expect.

The question for html5please is whether the use of a polyfill should be recommended for CSS3 media queries.

According to StatCounter, IE8 is still listed as either the first or second most popular browser on the planet for the past 3 months, right behind our beloved Chrome Latest, and unlike IE 6 and 7, it's users don't appear to be on any auto-upgrade path.

If you view Responsive Design (mobile-first or not) as a benefit to users, and not merely a developer convenience for cross-device development, then why shut off all that usability goodness off for such a large percentage of potential audience?

[paulirish]

(yes, i'm comparing it to not using a polyfill at all)

I'll have to get some data. In the meantime I'll strike this clause.

[scottjehl]

Thanks, Paul.

It's responsible to discuss whether a polyfill is worth its weight.

My criteria tends to be that polyfills are a cost that really have to be noticeable to the end user. Will people appreciate and notice the improved experience as a result of this feature addition, or is it just a shim to let me develop with newer standards behind the scenes?

I'll look forward to whatever you come back with to see if improvements can be made.

One thought:

If html5please's advice is going to remain that developers simply "make peace" with the lack of this feature in IE8 and less, I think it'd help to link to some resources on what that really means, particularly with a mobile-first layout. @adactio and @necolas have written about ways to avoid using a polyfill and still serve something usable to IE, but incorporating SASS or even cutting things up manually is different than doing nothing at all. If these resources are offered alongside a polyfill, developers can make an informed decision about what is best for their user base.

[Raynos]

Closing issue as the performance penalty has been removed from the site.