ThemeShaper Forums » Thematic


Best Practise speed up your website for those slow load times!

(8 posts)
  • Started 7 years ago by proto
  • Latest reply from ScottNix
  • This topic is resolved
  1. proto

    Hey all,

    I'm working on speeding up my website. Thought this topic might be useful for those that come after and search for speeding up their website. As far as I can understand, this essentially involves putting all your css in one file and your javascript into another one master file, thus reducing the load times Versus loading X5 different js / css files. Hegla's brilliant post here show's how to combine the javascript files ( ).

    My questions / assumptions:

    1: I have plugins that load js files, can I bundle them in my master js file that combines the native thematic js files to reduce load times or will this break the plugins working correctly? How does this play when a plugin or even Thematic js files gets updated? Assume this means you'd have to manually update the master file each time a new css / js files is updated, eg say superfish.js is updated?

    2: Once I've bundled all the css together assume this negates the need for the @import rule. Assume I would have all Thematic files first, (reset.css, typography.css, 2-c-r-fixed.css, images.css. default.css, plugins.css, etc, etc). I created a pastbin here for anyone wondering what it might look like (yes it's a long file and that's only Thematic's native css files not my child theme or plugin css included in this master file!) Also be wary copy and pasters, the last chunk of code I think should logically include the layout you've decided for your website. In this instance I've opted for two column fixed left, replace this last chunk with your layout choice accordingly:

    Then finally you'd have add your custom CSS file at the end of the file to take precedence over all other styles I think? What about plugin css files? Can I include these in master CSS file to reduce load time? What happens when a plugin updates? Assume you'd have to manually update the CSS file?

    3: I use W3 Total cache and a Content Delivery Network (CDN). Any other tips on reducing load times, I've heard of something called GZIP is that worth using? Any other useful tips that would be useful to anyone else wanting to speed up their website? I saw some great tips on GZIP here (caution modifying the HTACESS File can break your site)

    4: I read via Google page speed checker that removing import calls help. So, for example, instead of using

    @import url("second.css")

    you'd use

    <link rel="stylesheet" href="second.css">

    This enables the browser to process the stylesheets in parallel whereas if import is used the files have to be downloaded individually processed before it can move on to process the next one, increasing load time. Should we therefore hard code the reference to our CSS / JS files thus allowing them to be processed simultaneously? Eg, instead of:

    <img src="<?php bloginfo('stylesheet_directory') ?>/images/cart.jpg" alt="cart"/>

    We should hard code it to:

    ` <img src="" alt="cart"/>

    Is this true? Google Page Speed says "This allows the browser to download stylesheets in parallel, which results in faster page load times". Does this mean hard coding the reference to the files is as good as putting them in one file as they are able to load in parallel rather than one by one?

    5: Assuming you compress all the CCS / JS in to file and minify them, how do you get rid of all those pesky calls to multiple CSS / JS files, is their a function or something that you use?

    Thanks so much for your help, hopefully this well help a lot of people down the line too! :)

    Posted 7 years ago #
  2. A lot of these topics are lengthy tutorials and there are multiple ways to achieve a lot of them.

    Most people either don't know or care about most of the items listed, people know the end user won't notice the details and these details eat up a lot of time (the developers money).

    1) When it comes to loading scripts for plugins, you can be smart about how they load assets. If your contact form is only located on one page, load that script only on that one page.

    Scripts like superfish are a little different in that I can't see what would need to be update, it works. So the link you posted about combining the scripts is great, I would say go one step further and load them in the footer also.

    Here is an example of the script manager template with some different scenarios.

    // script manager template for deregestering and registering files.
    function childtheme_script_manager() {
    	// wp_enqueue_script template ( $handle, $src, $deps, $ver, $in_footer );
    	// deregister standard jquery
    	// loads modernizr script, local path, no dependency, no version, loads in header
    	wp_enqueue_script('modernizr-js', get_bloginfo('stylesheet_directory') . '/js/modernizr.js', false, '2.0.6');
    	// loads dropdowns script, local path, yes dependency is jquery, no version, loads in footer
    	wp_enqueue_script('dropdowns-js', get_bloginfo('stylesheet_directory') . '/js/superfish-dropdowns.js', array('jquery'), false, true);
    	// loads custom jQuery script, local path, yes dependency is jquery, no version, loads in footer
    	wp_enqueue_script('custom-js', get_bloginfo('stylesheet_directory') . '/js/custom.js', array('jquery'), false, true);
    	// page specific loading, no need to load everything on every page
    	// if it is (! - not) contact page, do not load contact-form-7 scripts
    	if ( !is_page('contact') ) {
    add_action('wp_enqueue_scripts', 'childtheme_script_manager');

    Now not all plugins are intelligently built, some refuse to let you deregister a script and reload it (like if you wanted to move it into the footer), there just isn't much you can do sometimes. As far as packaging things... try not to I guess, unless it is something that provides "theme" functionality, a drop down, jquery tabs. No matter how clean you try to make things, a client/user can go in and load 20 plugins and destroy all the hard work you do anyways and you will again have 20 scripts/css files loading again. ;P

    2) As far as bundling CSS, again multiple routes to go. I personally need to step up my game and use a script that combines @imports into a single.css file (couldn't find the link) but this gets fairly advanced.

    Currently I combine all the CSS into one file and modify that CSS, I don't load custom styles in the bottom, I just chop the CSS up from there and modify as I see fit. I have recently stopped using the default reset and instead use normalize.css. I have my SublimeText2 editor set up so it imports the script for me using NetTuts Fetch (so it is modern) when I build the site. I am currently working on a stripped down and cleaned (really I just add/remove/changed to my liking) CSS file I can use on every build and if something changes or I need to add something I just modify that master that is used on every new build. I definitely don't keep my changes separate since I am not releasing child themes which the above may or may not apply to, I can't really see a reason to keep them separate though I haven't really thought a lot into it.

    As far as plugin CSS, yes you can combine it... For example I use Jetpack's sharedaddy for social icons a lot on sites because it is so easy. The problem is it loads the whole CSS including image assets for social icons you may not even be using. So I deregistered the styles like so.

    // deregister styles, combined into style.css
    function deregister_styles() {
    	wp_deregister_style( 'contact-form-7' );
    	wp_deregister_style( 'sharedaddy' );
    	wp_deregister_style( 'jquery.lightbox.min.css' );
    add_action( 'wp_print_styles', 'deregister_styles', 100 );

    Again, not all plugins will allow you to do this, or, you could only load them based on page, techically if I didn't combine contact-form-7 styles in my style.css I could still go the route of only loading those styles on the page it is needed like I did with the .js file for Contact Form 7. Yes you would have to automatically modify the files if something was added, sometimes you can only do so much optimizing before it is out of your control, especially if you don't have access to the files after. So if it is your personal site you can go crazy, but if its a client you just may have to let it be for that reason alone the file needs to be updated.

    3) Yes use Gzip or the normal compression if possible. You can find plenty of info on that. I use YSlow plugin for Firebug, haven't used the page speed tool in a while, but I don't know which is better. Either should be able to tell you what can be done to squeeze the most out of page speed/optimizations.

    4) It is general best practice not to use imports (unless you are using a script that combines them for production). I don't really understand your example, the less CSS files the better, so one is optimal. Now you list an image asset with PHP but that PHP is taken care of by the server and if you are using caching it would be no different than the static image. But again, i don't understand the question 100%.

    5) Not sure what you mean again. :P

    So just to be clear, there are tons of different scenarios as to what is the best route to go. You can only optimize so much before it is out of your hands. When I view source on WordPress sites, a lot of them have terrible practices when it come to the latest best practices. Most sites the only optimization you will see is W3 Total Cache. The reason I believe is it is a lot of work to optimize a site and most don't have budgets to do so, and the developers aren't going to go the extra mile every time just because they want you to have a site that is .5 seconds faster only to be completely negated by the 10 plugins when it is out of your hands.

    Posted 7 years ago #
  3. proto

    Thanks so much ScottNix,

    Your response is really appreciated. There's some interesting new avenues I hadn't considered before. I think you're also right in that after the big wins, sometimes you're looking at complex coding (possibly hours) to make 0.3 of a second off the load time. The client can also add 20+ plugins and then as you say all your hard work is quickly swamped!

    I'm increasingly learning I like to get the proverbial code between my teeth and do it but that sometimes it's about sizing up what the victory is and whether that same time is best spent on the higher value things!! (I need to get better at stepping away from the code and trying not to be a perfectionist!!)

    Sorry I wasn't so clear on question 4 & 5. What I was driving at was how do you get rid of the old legacy calls to the old, multiple CSS / JS files. I think the answer is trawling through code and finding wherever the scripts are loaded and removing them there. Assume that might mean hacking the plugins and where they add CSS / JS script to your theme file's header (although not sure hacking plugins is that way to go given how quickly they update = regular hassle again!!)

    Thanks again for your help ScottNix!

    Posted 7 years ago #
  4. Just minify the JS and load the stuff in the footer. not much else you can do because noob users gonna mess up the theme anyway :)

    Posted 7 years ago #
  5. proto

    Well said Jagst3r15!

    I can quickly see the clients adding a load of plugins ruining all that hard work lol!

    Posted 7 years ago #
  6. middlesister

    I started writing up a longer answer but ScottNix summed a lot of things up very nicely.

    Some thoughts and short answers:

    1) No your plugins will not break if you move all plugins' js to one master file but yes you would have to manually update that master file every time upon ugrades. That is, if the plugins js has been updated of course.

    2) Yes putting all css in one file means you no longer need to use @import.

    3) If you already have a CDN and everything is minified and cached, then yes compression is a logical next step. Like ScottNix said, there are several ways to do it. Look maybe at

    4) I think you are mixing things up here a bit. Yes, using <link> can make a page load faster than @import. Take a look at and see why. The article is a bit old but AFAIK the point is still valid.

    Using the <link> tag is not at all the same as hardcoding the links to your files. Since php is processed on the server-side, your two examples of <img> tag look exactly the same when they are sent to the browser. CSS on the other hand is processed client-side, i.e. the browser, and that is where the difference between <link> and @import matters.

    The best way to add <link> tags in wordpress is via wp_register_style() and wp_enqueue_style() - similar to the script equivalent. It will then be available to minifying plugins. You can even use it to add styles within conditional comments for IE.

    Bear in mind though that both <link> and @import results in an extra server request. Logically speaking it *should* be faster to break up a truly gigantic css file in parts to take advantage of the simultaneous download, but only if the file is sooo big that it would be slower to load that single one than getting an extra request. Don't know when that would happen. Probably better to minify and concatenate them all into one, even if it becomes big. Which leads to the next point.

    5) It is quite possible to combine all css and all js into one file/request. There is a plugin that will do just that and also compress them for you: That was the first I found but there must be more out there. I thought W3 Total Cache did it already? Maybe there is a setting for it you need to enable?


    In general, the approach ScottNix shows you with deregistering scripts on pages where they are not needed is a good thing to do. The only thing I would do differently is to keep jquery in the header since some plugins might not work without it ( ).

    And, like the others said, you can combine plugins css and js only if you know which plugins will be used on the site. Clients can always add whatever plugins they want long after you are gone, but for a personal site I would definitely do it.

    Posted 7 years ago #
  7. tbh unless your client has crap internet its not the theme developers fault. I'm working on a child theme and I'm going to do basic minifying, but the rest is up to the user. bad coding to try and guess which plugins ur user might or might not need/use too

    Posted 7 years ago #
  8. Just to be clear on the childtheme_script_manager snippet above, remove the wp_deregister jQuery, I forgot to remove that before I pasted it (middlesister caught it), I did however remove the line that registered the jQuery CDN, but after reading enough information, I no longer do it since it is a bad idea in general to mess with the jQuery script calls due to unknown factors with updates.

    I need to also go and fix my snippets page now. ;x

    On a side note, I would say there are different scenarios for a personal site, a client site and a child theme you plan on releasing for others to use. Not everything mentioned will apply from one to the other.

    Posted 7 years ago #

RSS feed for this topic

Topic Closed

This topic has been closed to new replies.