This post was mentioned on Twitter by zoompf: All browsers hurt Performance by downloading CSS w/ print media type even if you don’t print! Problem and fix here: http://bit.ly/6pXo5E…

The reason I’m recommending to avoid NOSCRIPT elements is because I see them as an inferior alternative to graceful degradation. We have two ways to provide certain content to script-less clients; one — where content is present from the start, and is then hidden/removed/transformed by a script; and another — where content is stuffed into NOSCRIPT, and the job of displaying it is essentially delegated to a browser.

The problem is that SCRIPT’s are known to be stripped by corporate firewalls and/or proxies, and if Javascript is enabled, NOSCRIPT-based degradation turns out to be unsuccessful. Why prefer solution that has known flaws if there’s another alternative that has none and costs just as much?

Now, in this particular situation, the problem is not that apparent of course, as you rightfully explained. The subset of people who would suffer from SCRIPT removal _and_ needed to print a page is probably insignificant in a typical scenario. However, we could still try to avoid faulty NOSCRIPT.

Why not include print stylesheet the usual way (then remove it with script)? Potential problem I see here is that script would need to be positioned before link/style element. I’m also not sure if downloading of stylesheet is delayed while script positioned before is executed. If it isn’t, then removing element is pointless, as request might have already been sent.

Many websites do not contain print specific style information. However 100% of visitors to a website with a separate CSS file for print rules will make an HTTP request for a resource (print.css) whose content is actually used less than 100% of the visitors. Thus we have identified a performance problem for websites with a separate printer specific style data: an unnecessasry HTTP request. It does not matter whether print.css contains 3 rules or 300 rules. Its an unnecessary request and we performance junkies love to reduce HTTP reqeusts!

I believe this post has value if for only bringing this performance problem to the attention of a wider audience.

I was only able to find one published solution to this problem: concat together the print style information and use @media. This seems like a good idea and it aligns with our existing mindset of “concat resources together to reduce HTTP requests.”

However this solution doesn’t seem like a good solution if your print.css is larger than “small” or if only a “small” subset of visitor print your webpage onto paper. In fact, it becomes a worse solution as the size of the print specific rules increases and/or as the number of users who are actually printing decreases.

So, I propose another solution that I think is kind of sexy: Using JavaScript to lazy load printer specific CSS! Which solution works for you will depend on your site design and traffic patterns the same way whether you should inline CSS and JavaScript or use external files depends on your site design and traffic patterns.

Is there a downside to the second solution? Sure. Its still 2 HTTP requests though 1 is deferred. There could be an accessibility issue (though the impact to accessibility of using JavaScript to lazy load print style information is debatable). The <NOSCRIPT> fallback should work just fine except:

-If you are on a site with printer specific style information in a separate file…
-and you have JavaScript enabled…
-and you are on a network with a device that is selectively removing some JavaScript…
-and it selectively removes the JavaScript that lazy loads the style sheet…
-and you decide to print that web page…

then you will not print it using the proper style rules

I don’t think there will be much of a loss of life or limb because of that

I completely agree with you (and said so in the article) that if you have a small print.css then the JS solution does not make sense. You have convinced me that downloading printer information if its in a separate file at page load makes sense. The “online but then go offline and print” is a valid use case. As I mentioned in the article, browsers should defer downloading external printer specific style sheets until after window.onload has completed.

It was amusing to read this line off of a printed version of this post, during lunch, few days ago

I think the “problem” with print stylesheets is generally not that severe, and some of the advise given here is somewhat harmful when employed on the public web.

First of all, it’s hard to imagine a print stylesheet of a large size. Not in a typical scenario. In my experience, print stylesheets usually consist of a rather small set of rules; rules that mainly cancel out some of the screen formatting. “A list apart” is a good example of an article-centered site, and its print stylesheet (http://www.alistapart.com/css/print.css) is only a handful of declarations — hiding few things, displaying anchors urls, normalizing positoning, etc. I can’t imagine a print stylesheet 30-40% size of a main one (as you mention). It’s more like 1-5%, or even less. Given proper compression and minification, the additional weight of print-related rules becomes even less significant.

Second, providing print stylesheet via Javascript is really terrible for accessibility. Why should people with Javascript disabled, not available or stripped off receive worse treatment? NOSCRIPT-based fallback is also a poor solution (see, for example, this comment on my blog — http://perfectionkills.com/optimizing-html/#comment-56958). In a typical scenario, where print declarations are of reasonable size, I really don’t think it’s worth employing Javascript-based solution.

And speaking of browsers downloading print stylesheets at load time, the default behavior is not that unreasonable. What if a user goes offline after opening a document and then tries to print it (perhaps, reading a blog post first, on screen, and then wanting to finish it while commuting back home from the office — this time in a printed form; something I do pretty often).

Good question. I just ran a test and putting a tag at the bottom of your HTML, even if it has a “print” media type, delays the “start render” until all the style sheets has been downloaded. This makes everything much was as nothing gets drawn until everything gets downloaded!

check out the webpagetest results: http://www.webpagetest.org/result/091207_f078bac18b54823e149c6e87aea8c96c/1/details/ ]]> http://zoompf.com/blog/2009/12/browser-performance-problem-with-css-print-media-type#comment-21 Kyle Simpson Mon, 07 Dec 2009 20:20:02 +0000 http://zoompf.com/blog/?p=226#comment-21 Could you also effectively do about the same thing by just putting your tag for your print style at the very bottom of the page, that way it gets a much lower loading priority compared to the screen? That is, at least until we get fully internet-aware printers that surf and print automatically... that'll be interesting. :) Could you also effectively do about the same thing by just putting your tag for your print style at the very bottom of the page, that way it gets a much lower loading priority compared to the screen? That is, at least until we get fully internet-aware printers that surf and print automatically… that’ll be interesting.