The only method I know of is combining all of your styling into one stylesheet, and if you have a lot of pictures on your website, combine all of your pictures into one big picture and use css to display the pieces of the image that you need(CSS image sprites, look it up on W3schools) Compression also helps a lot, google this and click the first link: GZip HTML Compression tool
The idea is you can use CCS3 for things which you would normally use images for, like rounded corners and shadows.
CSS3 is not a cure-all for site speed woes. While certainly doing some things as CSS3 properties instead of images, or even javascripts can be faster to load, they can also incur speed penalties -- multiple backgrounds for example take a long time to render, making a page look horrible every time you scroll as the background erases and redraws. You want to speed up a site, it's the same as it's always been... Semantic markup with separation of presentation from content means smaller HTML, less DOM elements, and therein faster page loads and leveraging of caching models. Equally important one should set page size and file count limits... A limit to how many separate files and how big a normal page should be... while some things like forum indexes and gallery pages will blow way past that limit, having a goal for your 'normal' pages is a must-have. Which is why I have an ideal target of 72k and a upper limit of 144k -- that's for HTML+CSS+SCRIPTS+IMAGES combined! -- likewise I have 16 or less files per page as the ideal, 24 as the upper limit. ... which i why all my pages load blazingly fast just about everywhere. Usually to the tune of ten times faster than everybody else -- what with most of the people sleazing out websites these days seeing nothing wrong with blowing a megabyte over four or five dozen files, to go with their HTML 3.2 they either slap a 4 tranny or 5 lip service on, trying to hide that they've not updated their skills since 1998.
Well, not to threadjack, BUT... It's a fat bloated library, that BY ITSELF uncompressed is larger than what I consider the ideal size for an entire PAGE of a website (HTML+CSS+SCRIPTS+IMAGES!!!), and compressed is damned near 2/5ths... 90% of what it does has NOTHING to do with cross browser scripting of anything useful despite it's wild claims to that effect, and instead seems to be for stupid animated crap that IMHO doesn't even BELONG on a website. ESPECIALLY since the majority of people using it seem to give a flying purple fish about actually having graceful degradation, people on metered or low bandwidth connections (which as we have a bandwidth crunch AND more mobile users are becoming MORE common, not less!), etc, etc... It literally seems to piss all over most any project it's used on. WORSE, it's become the go-to tool for the ignorant and feeble minded -- where you'll have {nasty string of expletives omitted} responding to questions like "How do I make a link have a hover effect" with "use jquery". I've actually seen people answering questions as simple as "make text red on hover" with "use jquery". My advice, 99% of the time someone says to use some fat bloated idiotic needless cryptic library in an INTERPRETED LANGUAGE that is also bandwidth restricted? DON'T!!! I've never seen a well written javascript framework, or well written code based on one. It's why I've gotten in the habit of disabling scripting and enabling it 'as needed' on a per site basis (thanks Opera for building that functionality in without some stupid bloated 'extension') just so I don't have to see that crap. I don't care if it's jQuery, mootools, the scripting that comes with that idiotic rubbish called YUI -- it's all pointless trash that does more to make broken inaccessible websites than Frontpage used to! Much less the idiocy of 1.5 megabyte websites with 600k of javascript to typically deliver a half dozen 30-40k content images and 4k of plaintext. If you don't know what's wrong with that, well, I can't say it in polite company. Let's just say my words on the subject would involve something anatomically impossible with your maternal ancestor. But of course, with the majority of people making websites STILL just sleazing out HTML 3.2, and then slapping either a 4 tranny or 5 lip-service on it as if 4 strict, semantic markup and separation of presentation from content never existed, it's no surprise they start throwing endless pointless javascript on top to stroke the designer and developers... ego... instead of concentrating on what's important: ACCESSIBLE DELIVERY OF CONTENT! But of course, I'd not be surprised if that was lost on you after viewing the page in your siggy -- Now be warned, I'm going to be a bit harsh -- I'm just telling you EXACTLY what I see wrong... Which I suspect is why you even needed to ask the question. Inaccessible fixed metric fonts, fixed width layout, 12 URL attributes pointing at 404's, complete lack of attempt to compress your images (and using PNG for what should probably be jpeg), 8 stylesheets without a media attribute in sight, 13k of markup doing 6k's job, and of course most relevant to the topic at hand, 34 separate JavaScript files totaling in excess of of a quarter megabyte. Even compressed your scripting ALONE on that page is larger than the upper limit I allow for an entire page's HTML+CSS+SCRIPTS+IMAGES! ... and that's before we talk about the nonsensical gibberish use of numbered headings, tranny doctype (saying you are in transition from 1997 to 1998 coding practices), endless pointless DIV wrappers for no good reason, color contrasts below accessibility norms in several places, clearing DIV like it's still 2001, static style inlined in the markup, attributes like TARGET that have no business in any markup written after 1998 (and really have no business prior on anything other than framesets), incomplete document... To be honest I'm a little shocked it only has five validation errors, NOT that in tranny validation does anything meaningful. (kinda like that steaming pile known as HTML5, or as I call it, the new transitional). If you know what I mean... of course, it's a turdpress template -- with all the idiotic extra classes it insists on throwing at everything for no good reason. (proof whoever makes their stock templates and code generation outside the skin needs a good swift kick in the junk). But again, you're using 509k in 47 files to deliver what I doubt would 'need' to break 100k in 16 files or less... Which drags this right back onto the OP's topic. For every file past the first 8 you have the handshaking penalty, that could add up to 30 seconds or more if you don't happen to live in the magical fantasy-land of 30ms latency broadband (aka well over half the people in the US), and half a megabyte of transfer... FOR WHAT? Three actual content images, one legitimate theme image, a background that looks more like a CRT that needs a good degaussing, and 503 BYTES of plaintext. ... which means it's slow, riddled with accessibility issues, and harder to maintain. JS for nothing and your scripts for free -- that ain't working, and that's not how you do it.
I agree that most CMS's including Wordpress do not produce the most efficient web pages and I don't think many people would argue that when you are comparing it to a hand coded HTML page but things are done that way to make it more easier to use for a broader audience and range of skill level. I would assume the same for jQuery, although I have personally never needed to use the animations that jQuery offers I am happy for the things that I have needed which had made my life easier. Secondly what are you are saying about web pages having to be around 100 Kb doesn't really have anything to do with its success. I'm sure if you look around you will see that many of the most successful websites go over that and potential customers in the web development industry are often impressed by flashy effects, and styling you may consider overly excessive and unnecessary. At the end of the day, most people aren't examining the code of the website. So if it makes my life easier to use a library or CMS that results in a few extra Kb of data per page I'll go ahead and use it. Not to mention the fact that there is often no alternative if you want a slick interface that your client can use to modify there website in the future (other than coding your own).