Drawar

I was a bit hesitant about this approach, but after seeing how large the site was growing it definitely made things easier going into that sections CSS file and tweaking instead of dealing with something large. Also gave us the ability to style the site at the same time without crossing paths.

Breaking up stylesheets is something I need to start exploring. Every second counts right guys?

Yeah, I've done this before for sites that had several "sections" with different design styles. It takes about the same effort to edit the CSS for me, but the cost to the user is much less when they make that first visit to the site. Good stuff, mayne.

Are you planning on suturing sheets back together for delivery and zipping it?

Well we have one CSS file for "structure" and generic things present on most pages (like the community member list in the sidebar for example) so that's loaded across the site. Then, depending on what section the page is in, it loads 1 or more additional CSS files that build on top of the base styles. The most complicated pages on the site still have less than 1000 lines of CSS behind them, which is more than 2x smaller than the previous site. Smaller pages could have as few as 500 lines of CSS, it all depends on the page.

One thing you want to watch out for though is abstracting the CSS to different files, but still using every line of that CSS on every page. Loading 5-10 different stylesheets per pageload puts a strain on your pageload time because the roundtrip to access the file adds seconds to the total load time the user experiences.

Mike - Ya know I saw that method and thought it was very cool.... maybe!

Yeah, loading a bunch of smaller sheets just ups your requests; and don't get me started on sending half empty packets. Kinda picky stuff, but you'll send more full packets with one big request then a bunch of smaller requests...

I started mid last year using the multi-page approach and now on any new site use it, if it's large enough. It's so much easier from a management point of view. A lot of work I do uses my CMS system now and the templating on that is also worked around using different CSS and pulling them in for modules that are active. I prefer it as an approach now if the site is a larger one.

In terms of performance, the entire idea of having as few files as possible is key especially if they're cached in the end.

1 file of 100k is better than 10 files of 10k each if the person is going to need each one, for two reasons:

1. TCP/IP, like ever protocol has a time/bandwidth overhead. HTTP provides an additional one.
2. Extra concurrent connections makes for a slower server, especially if you have extra PHP logic in there trying to decide which sheets to attach.

I do understand the maintenance viewpoint -- large CSS files are a bitch to manage. Why not try keeping them separate but named in a certain order eg:
1notes.css
2blog.css
3etc.css

... and writing a 2 minute C exec or batch file that just echos them together into a production file. You could then strip out all the whitespace (that wasn't between : and ;) and call it a day.