Separate CSS files increase initial page load time by 40% to 70%

in looking over a default page, it does appear that admin.css, forum.css, help.css, and watchdog.css, are all being included unecessarily. forum.css, for exampl,e is only necessary *when navigating forum pages*. watchdog is only necessary *when examining watchdog entries*. We'd do well to include those conditionally rather than all the time. Some of the others -- block.css, user.css, system.css, node.css, and so on... well, I'm not sure. :)

The proper fix, I believe, would be to move the drupal_add_css() call that is now in every module's hook_menu() call to the page handlers for that module, and anywhere else in that module that it is needed. Let the module figure out when it will need its CSS, and add it when necessary.

I believe that was the intent originally, and it makes sense, so the task now is to tackle modules one at a time and move drupal_add_css() to where it makes sense.

I'm a fan of #3 and #4, selective construction of a single CSS file. You could do some of #3 by overriding theme_stylesheet_import, something that's been discussed before. I also tried overriding theme_get_styles, hoping to write the consolidation portion in #4, but it wouldn't take. I'm still a bit baffled by that.

Just for arguments sake I ran a test on a sample page.

Version 1: Drupal generated all of the CSS calls, a total of 4 separate CSS files.
Version 2: I modified page.tpl.php to only load 1 CSS file, a consolidated version of all the original CSS files.

I ran both pages through a simple assessment application and found only a minor difference.

HTTP Requests
V1: 19
v2: 16

Total Size (bytes)
V1: 45385
V2: 42471

Object Sizes (bytes)
HTML
V1: 6914
V2: 6693
CSS Images
V1: 4343
V2: 1647
CSS
V1: 17268
V2: 17271

Download Times (seconds)
56K
V1: 9.85
V2: 8.66
T1
V1: 1.04
V2: 0.43

Although it'd be nice to decrease the number of HTTP Requests, I'm not sure there's a great deal of benefit. Of course, I say this while handing out giant grains of salt. This is just one test on file with maybe a dozen modules activated.

Thoughts?

conditionally contructing a single css file per page view doesn't work too well because you lose the benefit of browser caching. personally, i don't mind the extra requests, and think other solutions add too much complexity relative to their benefit. of the ones presented, including fewer css files (like watchdog) based on context is the simplest. and it should be watchdog itself who decides this.

benchmarks on this are appreciated but they are highly dependant on the latency of the requestor. this really only affects high latency requestors.

I can do some benchmarks. On a busy server, it can take 1-2 seconds before your request is being served. If you need to do that for each .css file, you end up with really slow page loads ... (even with client-side caching, the client has to do a HTTP request for _each_ CSS file).

I threw together a quick patch to only include forum.css when needed: http://drupal.org/node/82133

If everyone takes 2 modules or so, we can have them all nicely conditionalized quickly. No API change, some performance improvement, and doesn't contradict more advanced refactoring inside drupal_add_css().

Putting drupal_add_css() inside hook_menu() is a hack anyway, IMO. :-) A hook_headresources() or something for always-needed CSS and JS makes more sense, but for things that are not always needed, just include them where necessary.

Grugnog2: "I am a bit confused by how your number of http requests only dropped by 3, when the css files were consolidated". There was a decrease of three because V1 had 4 separate calls to CSS files and V2 only had 1, the consolidated file.

The decrease in HTML is due, of course, to the fewer lines of code. I'm not sure about the CSS Images difference though, that's a bit confusing.

I'm curious to see more benchmarks and of course see just whether or not subjective filtering and consolidated files actually yield a substantial increase in speed.

And, just for fun, try running running your pages through http://www.websiteoptimization.com/services/analyze/. It's fun.

I knew this issue was going to creep up after my split drupal.css patch went in :-)

I'm in the camp that we should better conditionally load CSS files when needed. Many of them are loaded when they aren't needed at all. However, adding in various calls to drupal_add_css() can certainly clutter up the code a bit, but in reality, it's only a handful of extra lines instead of just one catchall in hook_menu().

I was thinking a hook_add_css() would be useful for modules where they could pass in an array of when their CSS should be loaded "menu, block, node, page, admin" and then the hook can distribute those CSS calls. This would be the cleanest approach but certainly require some thinking.

So I started to wonder whether or not selective inclusion and/or a combined CSS file would ultimately help the most. I have two topics I'd like to raise on the matter.

Point 1: Backfire?
If we selectively choose which CSS files to include AND create one master CSS file ("combined.css") to call in the page header, would there be issues with caching on the browser side? I know this may not be a huge deal but we've seen some browsers choke on CSS file updates. In essence, "combined.css" may change based on the page, thus requiring a comparative check with the server. There's more to discuss on this topic, I'm sure.

Point 2: No external CSS files
I decided to continue my test from earlier before and add V3. Here are the results.

Version 1: Drupal generated all of the CSS calls, a total of 4 separate CSS files.
Version 2: I modified page.tpl.php to only load 1 CSS file, a consolidated version of all the original CSS files.
Version 3: No external CSS files. CSS was included inline within <style></style> tags.

HTTP Requests
V1: 19
v2: 16
v3: 4

Total Size (bytes)
V1: 45385
V2: 42471
V3: 39543

Object Sizes (bytes)
HTML
V1: 6914
V2: 6693
V3: 22683
CSS Images
V1: 4343
V2: 1647
V3: 0
CSS
V1: 17268
V2: 17271
V3: 0

Download Times (seconds)
56K
V1: 9.85
V2: 8.66
V3: 7.88
T1
V1: 1.04
V2: 0.43
V3: 0.21

Conclusion: We're pretty much just moving bytes around but one thing that's quite significant is the drop in HTTP requests.

Here's the breakdown.
V1: (1) HTML, (2) JS, (4) CSS, (1) IMG & (11) CSS-IMG
V2: (1) HTML, (2) JS, (1) CSS, (1) IMG & (11) CSS-IMG
V3: (1) HTML, (2) JS, & (1) IMG

Interesting discovery, something I didn't personally know - inline CSS with background:url(); styles will not increase the number of HTTP requests. Respective webservers, in this case Apache, must fulfill these requests upon the original HTML request.

It's an evening of personal discovery.

Inlining the CSS in the header may reduce the HTTP request count, but as soon as you request a second page it becomes a net loss. That's the entire point of client-side caching. :-)

-1 to any CSS/JS inclusion that breaks client-side caching. It's there for a reason as we should leverage it. I would be OK with a hook-based solution, but only if we had a good way to implement it. Just on the path won't work, as some (eg, location's css file) will be needed on some nodes but not others.

For 5.0, at least, I think the few extra bytes of PHP for multiple calls to drupal_add_css() where necessary are a good price for reducing the amount of CSS traffic needed.

Crell: I wasn't suggesting that inline CSS was the right solution, just providing more perspective and data.

bug 82922 was marked as a duplicate of this. commenting here to subscribe.

Ted articluated a nice fix for this issue. He proposes to append all the css files into one file and store it in the files dir with a name being a hash all the paths of all participating css files. the mega file would include comment delimiter so one could see which file contributed what css.

this way, we keep some browser caching, but cut all the requests down to one. killes suggested storing two versions (on demand): one gzipped and one not.

I expect Ted to make a patch when time permits.

And...

• If the files directory wasn't writeable, the css would be delivered as normal
• You'd give admin a way to nuke the mega-CSS file when changes were made.
• You'd allow modules to over-ride the mega-file as needed.

Is there any downside to this method?

Is there any downside to this method?

Still sends unneeded CSS code. On a site of 1000 users, maybe 3 need the watchdog CSS, ever. You can browse through a site and never have need of the event module CSS because you didn't happen to view an event page.

Development becomes harder, unless we're always re-stating the source CSS files for changes. You'd need to nuke the compiled file every time, or else be able to disable the cached version.

Would every theme then get its own compiled CSS? Remember, one of the main reasons for splitting up the CSS files was to make it easy (read: possible) for themers to arbitrarily cherry-pick which module CSS files they want to override or exclude. How would this affect that? What is the impact on sites using sections.module or making use of the new arbitrary template-per-path functionality? (I don't think there's any with the latter, but I'm just throwing it out there for completeness.)

Would we then do the same with a hook_js()? How would that get cached? Some of those files could get really large, and be needed on only one or two pages.

That's a good summary to get the juices flowing.

Still sends unneeded CSS code. On a site of 1000 users, maybe 3 need the watchdog CSS, ever. You can browse through a site and never have need of the event module CSS because you didn't happen to view an event page.

That would be a good example of where the css is defined as always being a separate file and only sent when required. I see what you mean though, there is a grey area in the middle.

Development becomes harder, unless we're always re-stating the source CSS files for changes. You'd need to nuke the compiled file every time, or else be able to disable the cached version.

Heaps of people get stuck not clearing the cache table during development, but that doesn't make cache bad. There would soon be a solution if needed. Eg. user 1 always gets separate files, or there is a development mode.

Would every theme then get its own compiled CSS? Remember, one of the main reasons for splitting up the CSS files was to make it easy (read: possible) for themers to arbitrarily cherry-pick which module CSS files they want to override or exclude. How would this affect that? What is the impact on sites using sections.module or making use of the new arbitrary template-per-path functionality? (I don't think there's any with the latter, but I'm just throwing it out there for completeness.)

Would we then do the same with a hook_js()? How would that get cached? Some of those files could get really large, and be needed on only one or two pages.

Yes, heaps of good points that I don't have good answers for :-)

See also this issue abotu gzipping the CSS:

http://drupal.org/node/11128

Should be possible to create a normal and a gzipped version of the combined CSS files and server the gziped if the browser supports that.

Yes I'm going to start work on a patch in the next couple days to address these issues.

I am against dynamic CSS files because of IE.

IE is *really* aggressive about caching a CSS file. Try developing exclusively with IE. Go and edit your CSS file. Try and get that file to update without forcing it.

Wait a few days without clearing your cache. You'll continue to get old results.

Dynamic CSS will simply *not* work reliably with IE. As far as I can tell, ever.

The solution I believe is best is to add CSS and JS files only when necessary. I've never been a proponent of adding CSS files always, especially when a good chunk of the CSS files will only be included in particular cases.

It's very clear that things like forum.css and admin.css only need to show up on particular pages. In fact, *in general* it's very easy to tie CSS to a particular section, include it conditionally, and be done with it.

drupal_add_css should check to ensure no CSS is checked twice (I believe it already does though I'm not sure on that) and then drupal_add_css can safely be called whenever it needs to be. This is not any more complex than any other declaration -- and that's exactly what it is. It's a declaration that output this code is generating needs this CSS or this JS file.

Is it possible to steamroll the IE caching issue by using uniquely named css files? OK, not a pretty solution, depending on your love of timestamps, but:

bluemarine-060928-1049.css

Once you finish development, you somehow trigger the creation of a new combined css file(s).

sime: That's part of the original proposal by Ted. He'll use md5 hashes of the file contents so the css will only change if its contents changes.

good discussion guys.

Here's my 0.02 cents on the topic...I'm not sure if it is applicable, but, here it is anyway.

I recently started using a style.php file instead of a style.css recently to handle style sheets. The main reason was it's much easier to build a theme when the css is in seperate files and you can start using php within your CSS, which is a handy thing.

Here's an example of a style.php I'm using (style.php is referenced in the page.tpl.php file in the head)

header("Content-type: text/css");
$primary = '#A9A9A9';
$primary_highlight = 'red';
$secondary = '#FFCC99';
$secondary_highlight = '#eaeaea';
$subtle = '#eaeaea';
$bg_colour = '#000';
$main_text_colour = '#A9A9A9';
$page_border_colour ='#202020';
$pre_background_colour ='purple';
$marker_text_colour ='red';
$agg_background_colour ='green';
$forum_background ='silver';
$forum_container_background ='#eaeaea';
$forum_container_link ='#990000';
$form_field_bgcolor = '#202020';
$form_field_error = 'red';
$form_field_text = '#fff';
//** link colours **//
$link_normal = '#eaeaea';
$link_title = '#eaeaea';
$link_hover_highlight = '#FFFFFF';
$title_link_normal = '#999999';
$title_link_hover_highlight = 'red';
$breadcrumb_links = '#666666';

//** block colours **//
$blocks_background = '#202020';
$block_titles = '#fff';
$default_border = '#606060';

include("page_framework.css");
include("blocks.css");
include("forum.css");
include("discography.css");
include("audio.css");
include("admin.css");
include("drupal.css");

How I reference the colours within the css is illustrated below using the body tag.

body {padding: 0;margin: 0; background-color: <?=$bg_colour?>;font: 76% Arial, Helvetica, sans-serif;}

That is extremely handy when the project is at the development stage and the client asks for a different colour scheme.

In the context of very large sites with a very large audience, I can see the logic in using the same principle in a more advanced way:

For example.

• parse the css - remove double spaces and all comments - so you can comment to your hearts content
• using arg(n)s, or other, to include or not include certain files, such as forum.css when viewing the forum for example

that might increase the efficiency of how styles are handled at both ends..i.e. individually they are easier to edit and the php delivers it all as one request without comments and without extra spaces, so it's very small.

on the cache front, I don't experience the same problem others have mentioned about IE cacheing the CSS when I'm using the style.php structure. I'm not an expert on cacheing, but all I have to do when previewing a change in IE is click refresh once.

I'm not sure if this adds to the discussion or not, or complicates how modules "include" their styles, but, I thought I would mention it.

Dub

yes, folks should only add their css when they need to. but thats not going to get us very far. we are trying to significantly reduce http requests andf thus speed up browser rendering.

the IE issue that earl describes is not relevant IMO. each file that gets generated has a unique filename. ie will not get confused about filenames. if you update a module and receive a new css file, then the css file cache needs clearing, just like any other cache. further, if a module is using php to produce dynamic css (i don't know any current module that does this), then it should opt out of the css cache with a simple param to drupal_add_css(). sime mentioned this a couple posts ago.

we'll all have a chance to test these theories one Ted's patch arrives. I think aggresive browser cache is a non issue. perhaps it will bother developers like the current menu cache does. our usual workarounds for that menu cache apply to the css cache.

and yes, we do seem to be going in circles a bit, but sometimes thats whats needed.

Yeah, I've caused a few circles. I think I'm on track now! :-)

IE having a broken cache mechanism will affect both a regularly-recompiled CSS file and regularly-edited module-specific CSS file the same way, so that's not a deciding factor. It's a PITA either way. :-)

Performance-wise, I guess we'd need to see benchmarks to know which was better for overall performance; sending unnecessary CSS or making multiple CSS requests.

I suppose the mechanisms needn't be mutually exclusive. We could have a hook_css() that is used on visiting admin/modules (or whatever the path is now) to build the "custom-built drupal.css" :-), and a drupal_add_css() to allow for selectively adding large or genuinely rarely-used CSS. It would be up to each module's author to decide which applied in which situation.

Of course, that then still complicates the logic for allowing themes to cherry-pick what they override, since there's two different times they'd need to do so. I guess we'll have to see what magic Ted comes up with. :-)

Open question: Aren't we in a feature-freeze? Just how much CAN we do right now in this regard? Is hook_css() even legal to add at the moment?

Actually, I don't like the idea of md5ing the contents for the file name because it becomes incredibly obscure. There's no way from looking at it to know what in the world it is. It looks like a junk file. I'd be much happier with print.css, screen.css, etc. as it's much more semantically meaningful. We shouldn't make the system more obscure and opaque just to get around IE being dumb. Besides, you'd still need to reset the Drupal CSS cache anyway on every change anyway. (I'm assuming that restating every file on every page load is needlessly inefficient.)

Nothing to add. Anything to minimize linked styles would be great. Just want to keep tabs on this.

Any progress here on Ted's solution? If we're not going to compile the CSS file, then we should start moving the drupal_add_css() declarations. One or the other, but we need to get it done soon.

Patch this week. Was waiting for Garland to land because of some technical overlap. It just went in so patch soon.

Assigning this to 5.0-beta1 and setting as critical. A 40% performance hit would be a bad thing to leave in there.

m3verick, how's the patch coming? If you're busy putting out other fires, is it something that you can post for someone else to work on?

Yes this is indeed critical, I have way more evidence to back this up from a large site I deployed last week.

Starting patch tomorrow morning, I've thought through it so much shouldn't take too long -- a day or so :-)

I'm not an expert on the subject at hand, so excuse my ignorance (Just thought i'd mention this)
What about removing whitespace as well? ...If the CSS are be generated into the files folder.
http://flumpcakes.co.uk/css/optimiser/

..and there... now i'm subscribed too :P

I agree with the last comment, plus a bit extra on top.

What would be great is if there's an admin page where the admin can choose various CSS options such as colours and other options. On pressing submit, PHP generates an optimized CSS file which is stored as a static file and sent to the client. As the CSS file is generated by the system and not human hands, there's no reason why it can't be compressed/optimized in the same way that JQuery is. In other words, no white space at all.

Without the admin page to choose CSS options (which I would presume would be more a Drupal 6 thing at this late stage), it would still be a good idea for Drupal to create an optimized/compressed CSS file which it stores on disk and serves statically rather than dynamically, all as one file, not all the separate files.

Just to clarify, my optimum is as per Drupal Dubliner's #25 above, but rather than serving a dynamic style.php (and the performance/caching penalty due to this) the $colours etc variables are textfield on an admin page, and on submitting that admin page, the optimized CSS file (including white space compression) is created. Again, more a Drupal 6 suggestion, but something that may be worth thinking about at this point at least.

jake: color.module already does this to some extent.

We should not diffuse the focus of this ticket too much. The aim of this ticket should simply be to correct a dramatic drop in performance due to multiple css files.

Sure the optimization thing could be in the patch, but if it delays the fix then that would be bad...

Agreed. The intended fix is to generate a single CSS file to eliminate needless HTTP traffic. The HTTP overhead is the same whether it's a 4kb CSS file or a 40 kb CSS file; one "is this newer than my cache?" request.

The initial request for the file can be sped up by enabling compression in apache if needs be, but that's irrelevant to this issue.

m3averck? :-)

Yep, I agree that focus shouldn't shift.
good idea to have this in mind for future discussions/features though.

Maybe the easyest solution is to include only the forum/admin/watchdog/... css when needed.

On the xxx_menu() function can we call the drupal_add_css() function only if we are on a specific area/page of the site?

Gzipping should be an interesting idea, if the web server allow it, but not the final solution. Idem for md5ing or collapsing all the needed css in one single css.

Here are my 2 cents.. if it's not too late..

I have a connection with a remote caching proxy. It caches css files for days with no way of clearing that cache..

I think the idea of dynamically generating a single file is the best solution. BUT we must find a way to make each different version of that file have a different name..

Someone suggested using an md5 hash to generate unique names. i think it is a good solution. But we must make sure that the hash changes if the css changes..

The downside of that is that there will be redundant caching.. if two css files have different names, they will be cached 2 times.. if they only have a 10% diff, 90% of the file will be cached 2 times.. if you have 10 modules each one having a custom css, one site will have 10 cached files with the same code..
perhaps we could dynamicaly generate a signle css file with a unique name but instead of selectivly including code based on the code needed, it should include all the code needed by all modules.. like now..

This way a user will have one file to download and cache.

My patch has landed, it solves these issues and more.

Time to discuss code: http://drupal.org/node/98819