don't use @import
Permalink
This is something I didn't know. Using @import and link together might break parallel downloads.
Why does concrete5 use @import? I never cared, but by reading this article I might get the impression that it is better to avoid @import:
http://www.stevesouders.com/blog/2009/04/09/dont-use-import/...
Why does concrete5 use @import? I never cared, but by reading this article I might get the impression that it is better to avoid @import:
http://www.stevesouders.com/blog/2009/04/09/dont-use-import/...
yeah, I've heard this too before. Seems like there's not really a good reason to use @import.
Good eye Remo. @import was/is historically used to hide styles from older/less-sophisticated browsers. Both Netscape 4 and the pre-opera/pre-webkit mobile browsers would choke on CSS layout techniques. Any styles put in @import rules would be ignored by these browsers, resulting in an unstyled yet readable page. This is becoming less important as mobile browsers start to catch up with their full-computer counterparts, but for some users it might still be a priority.
As far as Concrete specifically goes, the performance problems described in that article are avoided in most areas since @import is used exclusively, without a link tag. (see the @import @import section, although there are times where this isn't true with versions of IE). Also, "download everything in parallel" isn't always the best way to increase front-end performance. When you have too many resources downloading in parallel, CPU render-time becomes the bottleneck instead of bandwidth. Parallel downloads are limited by the number of http requests you can make at once, and only affect the initial loading of a page. You'll get more bang for your buck if you focus on configuring your server to aggressively cache CSS content so users don't re-download the styles every-time they come to your site.
When you're working on a product meant for all kinds of users in all kinds of situations there is no "one true way" to do things. What's right for one user might not be right for another. What's really awesome about Concrete5 (and other open source projects) is if you identify a bottleneck for your specific situation, you have the ability to fix it for your specific situation.
As far as Concrete specifically goes, the performance problems described in that article are avoided in most areas since @import is used exclusively, without a link tag. (see the @import @import section, although there are times where this isn't true with versions of IE). Also, "download everything in parallel" isn't always the best way to increase front-end performance. When you have too many resources downloading in parallel, CPU render-time becomes the bottleneck instead of bandwidth. Parallel downloads are limited by the number of http requests you can make at once, and only affect the initial loading of a page. You'll get more bang for your buck if you focus on configuring your server to aggressively cache CSS content so users don't re-download the styles every-time they come to your site.
When you're working on a product meant for all kinds of users in all kinds of situations there is no "one true way" to do things. What's right for one user might not be right for another. What's really awesome about Concrete5 (and other open source projects) is if you identify a bottleneck for your specific situation, you have the ability to fix it for your specific situation.
This video has a lot of good information on this subject if anyone's curious:
http://ajaxian.com/archives/ajax-experience-videos-performance-and-...
http://ajaxian.com/archives/ajax-experience-videos-performance-and-...
My opinion about it:
1. Netscape 4 - I don't care about that anymore, Speed is more important than ancient browser support.
2. Parallel downloads - I've never seen a site that causes a high cpu load unless it's some kind of game. Have you? I'm sitting in front of a PowerPC G4 with 512MB
There are also some scripts that don't render site elements, in that case, it is recommended to move these scripts to the end of the body! Don't know why, but I never like that but it would make sure scripts don't block the rendering process..
3. What's best - sure, this is always difficult to answer. But is there someone who still works with netscape 3? I don't think so.. We are still annoyed by IE6 and it's quirks, I doubt someone tests their sites with IE2,3,4,5 NN1,2,3,4..
I'm just trying to speed up concrete5 in general..
1. Netscape 4 - I don't care about that anymore, Speed is more important than ancient browser support.
2. Parallel downloads - I've never seen a site that causes a high cpu load unless it's some kind of game. Have you? I'm sitting in front of a PowerPC G4 with 512MB
There are also some scripts that don't render site elements, in that case, it is recommended to move these scripts to the end of the body! Don't know why, but I never like that but it would make sure scripts don't block the rendering process..
3. What's best - sure, this is always difficult to answer. But is there someone who still works with netscape 3? I don't think so.. We are still annoyed by IE6 and it's quirks, I doubt someone tests their sites with IE2,3,4,5 NN1,2,3,4..
I'm just trying to speed up concrete5 in general..
I was wondering about this. Particularly when I got the FOUC bug in Firefox on one of my custom themed sites. after I did the upgrade to 5.3. I think the non-parallel nature of the @import lagged the final appearance somewhere along the way since the custom sheet was being forced to load after the core sheets and js.
I solved the problem by popping the custom css right after the html declaration and before the rest of the external links. However, I don't really like this solution since any conflict with a css declaration after it may override my custom sheet if it's not scoped carefully.
I solved the problem by popping the custom css right after the html declaration and before the rest of the external links. However, I don't really like this solution since any conflict with a css declaration after it may override my custom sheet if it's not scoped carefully.
