Drupal employs a great mechanism for speeding up page loads once active development has been completed. Under the Performance settings, there are several options for caching pages, CSS and more. As an example, from a high level, CSS files are consolidated from the often several dozen files down to one, with all whitespace, redundant or superseded selectors and comments removed. This is a great way to speed up your site once you are in Production. If you’re actively developing your site, you don’t want to use this because your changes won’t show reliably without constantly clearing your cache.
There are some caveats though. What? Caveats in Drupal? Uh, yeah. I love Drupal but it has more caveats than the US congress has vacations.
The symptoms are always the same – custom changes (to CSS, for example) don’t show up. In my case, Adaptive Themes manifests this type of behavior. AT has a way of “pre-caching” info within its area of Drupal and this will often lead to CSS customizations not showing up once performance caching has been enabled.
In AT’s case, there is a work around. If changes don’t appear:
- Clear the cache
- Immediately save the AT Theme/Subtheme you are using under Appearance
- Clear the cache again
That should do it. You can read the conversation between some of the AT geniuses here:
It’s pretty recent and they will have a solution at some point soon, I hope. Considering how awesome AT is, with all of the Responsive features and easy subtheming, this is a pretty small accommodation to make.
If you turn on JS Aggregation under Performance and your Views Slideshows stop sliding, look at this issue. A total Oops! moment. I saved the json2.js file as its placeholding HTML file instead of copying the code from the raw file. I’m not the only one eith so I don’t feel much stupider than I usually doo. ;-(
https://drupal.org/node/1290676 – read about the issue
https://raw.github.com/douglascrockford/JSON-js/master/json2.js – the actual code
Today I turned on the CSS aggregation feature in Performance and promptly broke all of my custom CSS. well, almost all of it. It was apparently pretty quickly that the custom css that i have in my custom css file was missing. the css file is properly registered in the .info file so at first I wasn’t sure what the problem was. then i found this.
If CSS aggregation/compression is enabled, all cascading style sheets added with $options[‘preprocess’] set to TRUE will be merged into one aggregate file and compressed by removing all extraneous white space.
so the workaround is to add all the custom css to a file that has had this variable set to TRUE. any of the subthemed css files that you may have moved will do. CSS doesn’t really care what file the styles come from; it just cares what they affect. the real fix will be to get the variable to be set to true for my custom file.
BTW, the performance difference is really noticeable: you have to be able to turn this on.
If you are curious about whether Blocks is better than Panels in terms of performance then check out this post:
This is great. It tests both components and gives the data in a nice, clinical summary. The long and short of it is that Blocks is SLOWER than Panels, especially if you are using Views. But check out the post for yourself.
Thanks to Greg Harvey for doing ALL the heavy lifting on this one!