CMS & WordPress
Someone wants me to take over administration of a drupal7 site.
A quick "view source" of the front page reveals this ubercart site specifies 27 different CSS files (each of which is really an sql select at some level).
Is each such CSS file a separate GET, the way images are? Isn't this a large, and largely unnecessary performance drag?
I find myself wondering if I might use drupal just for the forums and ubercart, and show all the other largely-static pages in a leaner and meaner way.
There is a way to aggregate CSS and JS into a single file. However, depending on the modules being used they could break – probably unlikely. If you haven't worked with Drupal 7 you will learn that there are many sacrifices being made in terms of front-end code to provide the absolute amount of flexibility for designers without ever needing to touch the an back-end code. That is just something you have to live with unless your going to through a clean it all up yourself which generally isn't worth it and means eliminating certain theme options. Back to the original question though so long as JS or CSS is the same across the entirety of the site turning on aggregation in the performance settings *shouldn't break anything.
Not to discredit you oddz but there is no 100% way to aggregate all css files more importantly some of the core modules will not allow this as the are depended on some of the template files. But drupal does things there own way and have added many override functions to accomplish the editing of these such template files. Images are a much easier task as the core is not dependent on these files. If you can or could i would suggest moving from drupal to a system that is better structured for the editing. Drupal is user friendly not developer friendly....
There's nothing wrong with trying to do what you're suggesting.
Probably best way to go about this ... is to just use your own template files for everything from nodes to fields, blocks and pages. Use a hook to unset any variables that are responsible for creating your header, or just unset them in your page.tpl file. And then just include your own CSS and JS files from your custom templates files in your theme directory.
If something breaks, then trace back and figure out where the break occurred and and add whatever needs adding to fix it. It's not the perfect solution; you'll get your hands a little dirty, but in the end, it's possible that you could wind up with a "best of both worlds" where you're using your own templating "framework" (not literally, but figuratively) while using Drupal to feed your structure with the dynamic information it needs to render your pages.
It's not out of the question. Most people just don't have the patience to make it that far, before they just plug their nose and either accept it for what it is, or just drop it altogether for something that doesn't need to be finessed, coddled and begged to do what you want it to do and then just get out of the way. Drupal doesn't like "getting out of the way." So it's just a little tricky to accomplish.
Someone just needs to come out with a good tutorial to explain how to do all of this, because it's totally understandable why someone wouldn't want to have to sift through all of those hooks without just throwing their hands in the air and loudly exclaiming "WTF?" Maybe I'll come out with something like that if I ever get the time.
i wish i could have but the client gets what the clients asks witch was not the best choice but the project turned out and worked flawless
I've never run into a situation where I wasn't able to aggregate my CSS files except when I didn't declare them within my theme info file.
If you have a dozen or two CSS files and you go to admin/config/development/performance, you can aggregate CSS and JS files. Your theme and core CSS will be aggregated and the same thing will happen with your JS files. If there are any modules that do not like their CSS or JS aggregated, they will be aggregated as a separate file. The result is still what you're looking for which is less calls to the server to deliver the page.
Edit: Also keep in mind that you will see several more JS and CSS files when you are logged in if you are using the D7 Overlay Admin effect.
Not to discredit you oddz but there is no 100% way to aggregate all css files more importantly some of the core modules will not allow this as the are depended on some of the template files.
That makes no sense. How do you figure? It would depend largely on how the aggregation module was implemented and where it hooked into the page generation process. But I assure you it is 100% possible - even possible without Drupal but as an apache module possibly.
EDIT | Apparently I feel very "possible" today
What is meant by that is that some modules add asset files based on conditional outside the realm the the core application like the URL. Therefore, when adding any asset it is possible to have it be ignored when creating the aggregate file. In which case the asset(s) are their own separate requests. When you store foreign key references in serialized table columns I just gotta assume the worst…
That is funny you have a question like this as I have taken on a drupal site and slowness and other issues. I have converted it off all into vbulletin. It was better than drupal but if not for one thing I would have converted to xenforo but it likes social groups.
Drupal is not known for its scalability nor speed.
Actually it kind of is when put head to head with other full featured CMS's it tends to come out quite well which is why it is used for big websites like Warner, Disney, Sony, Whitehouse, etc... On the flip side, it also performs quite well when it's used for smaller websites when configured right.
Organizations like the White House or Disney, what have you ... don't have these huge needs for lighting-fast speeds. Nor are they likely dealing with the kinds of hardware and bandwidth limitations that a lot of mid-sized companies might be dealing with on a shared godaddy account or even your typical $20/month VPS.
With the right caching enabled, there is essentially no difference between what the various CMS's are ultimately cranking out. From the server's standpoint, it's just a static page in a tmp or cache directory. Whatever process was used to produce that page, however ugly or slow, may or may not be relevant.
If you're dealing with Twitter, or an online stock trading service for example, where up-to-the-second information changes need to be reflected immediately ... then it really starts to matter a lot more, and really, just about any CMS system is going to start looking pretty slow and clunky. But then again, it's not very likely one would use Drupal or Joomla for that kind of thing anyway.
If you define "speed" as speed to develop ... then you're getting a lot of bang for the buck with Drupal. You can crank out some pretty complex apps with a lot of advanced functionality using things like organic groups, cck, views and entity/node relationships ... in a good deal less time than it would take to make the same app in Ruby on Rails, for example -- and have a CMS attached to it out of the box. And that's not a knock on ROR. It's when the application is actually "completed" where things get interesting. You might be able to crank something out in no time with Drupal or even Ruby on Rails, but maintaining it is another challenge altogether.
On the other hand ... for a much simpler application with much more modest requirements, Drupal is probably overkill, and you'd probably be able to develop the same app in much less time using something like Wordpress.
...keep in mind that you will see several more JS and CSS files when you are logged in if you are using the D7 Overlay Admin effect.
Most of the Drupal-generated files are only relevant to logged-in users, once the designer has gone through the whole thing and made it all look presentable. Apart from the admin UI, I don't normally even want any CSS from modules or core. It would be kind of like using a massive CSS reset and then over-writing the whole thing further down in the same file, and I always wonder why people still do that.
In all of the Drupal builds that I've so far done or reworked, I've not even served anything but my own CSS files to logged-out users (a.k.a. Joe Public), so the HTTP requests and size in KB end up comparable to what I would have got with just about any similar site. That not only eases the performance worries somewhat, but the clean slate also makes theming a bit easier because there is little or no duplication or specificity issues. I include only one small stylesheet in the info file, which is just to tidy up the appearance when logged in.
Well, yes and no. I was suggesting that the OP log out to make sure they didn't have any extra code cluttering up a site that Joe Public wouldn't experience. That way they will have a better idea of what they need to deal with. Beyond that being that Drupal is modular in some instances you will have additional stylesheets or JS files accompanying included modules (think jQuery, nice-menus, CCK or Gmap for starters).
- Also, there's no getting around core stylesheets that define nodes, navigation etc... I often reset ul.menu, ul.menu li, li.leaf, etc.... in my boilerplate css for that specific purpose.
I tend to follow the same philosophy. For simple sites, I often include 1 stylesheet in the info file but for complex sites to simplify things I'll have several stylesheets to account for navigation, product catalogue, slideshow, etc.... Then I'll aggregate and compress them using the admin -> performance tools. It's all the same code I would have in a single stylesheet but seperated for ease of editing when someone other than myself has to go in and edit.
IMO, Drupal 7 is much better than D6 at aggregating and compressing files and will also cache pages for anonymous visitors. In D6 I've used BOOST for caching which does a pretty good job too.
next page →