Speed up WordPress and Get Full Manual Control of CSS, Images, Javascripts With Enqueue Scripts and Rackspace Cloud Files. Here is How We Can Do it. Well, most of us uses W3 Total Cache. Unfortunately, W3 Total Cache does not have the function to unhook the minified Javascripts, CSS files. Additionally, some Javascripts, CSS needs to be manually minified or should not be minified. W3 Total Cache works good for smaller websites but for bigger blogs like our website with 5K+ Posts, it is mandatory to manually control the delivery via Rackspace Cloud Files CDN. It is impossible to check each and every posts. W3 Total Cache is nothing but a modernized version of an old Cache Plugin. WordPress had the Cache function by default before, for various issues, that has been discontinued. Essence is that, definitely we will use W3 Total Cache, but we must Optimize and Speed up WordPress and Get Full Manual Control of CSS, Images, Javascripts With Enqueue Scripts and Rackspace Cloud Files CDN based on our high end back end.
Speed up WordPress and Get Full Manual Control of CSS, Images, Javascripts : For Whom it is Written?
This guide to Speed up WordPress and Get Full Manual Control of CSS, Images, Javascripts With Enqueue Scripts and Rackspace Cloud Files is written for Akamai or Rackspace Cloud Files or any OpenStack Swift user with Rackspace Cloud Sites or Rckspace Performance Server.
It is mandatory to understand, our target is to optimize the server backend first, use the advanced features of WordPress.
Speed up WordPress and Get Full Manual Control of CSS, Images, Javascripts : What Things to Know and Do
Google PageSpeed Insight throws an ugly message – Eliminate Render-blocking Javascript and CSS WordPress. The linked article is a guide, an excellent guide to unhook the specific Javascripts and make it loading from Rackspace Cloud Files CDN/Akamai CDN and in footer. How in footer ? Here is the reference :
1 | http://codex.wordpress.org/Function_Reference/wp_enqueue_script |
---
So the function says :
1 | wp_enqueue_script( $handle, $src, $deps, $ver, $in_footer); |
Look the in_footer part. An example :
1 2 3 4 5 6 7 8 9 | add_action( 'wp_enqueue_scripts', 'script_managment', 99); function my_script_managment() { wp_deregister_script( 'jquery' ); wp_deregister_script( 'jquery-ui' ); wp_register_script( 'jquery', 'http://aaaaaaaaa.r37.cf2.rackcdn.com/jquery.min.js' ); wp_register_script( 'jquery-ui', 'http://aaaaaaaaa.r37.cf2.rackcdn.com/jquery-ui.min.js' ); wp_enqueue_script( 'jquery', 'http://aaaaaaaaa.r37.cf2.rackcdn.com/jquery.min.js', array( 'jquery' ), '4.0', true ); wp_enqueue_script( 'jquery-ui', 'http://aaaaaaaaa.r37.cf2.rackcdn.com/jquery-ui.min.js', array( 'jquery' ), '1.8.16', true ); } |
If not mentioned, it is set to false. You need to force to yes. Sometimes, this way fails. It is not that the method is wrong, it can happen, something is forcing to call a Javascript for proper function. In these cases, first de-register the named file :
1 2 3 4 | function my_script_managment() { wp_deregister_script( 'jquery' ); wp_deregister_script( 'jquery-ui' ); } |
Keep in mind, this is might not be the way to eliminate javascripts included in wp-includes due to conflict in name :
1 | https://core.trac.wordpress.org/browser/tags/3.8.1/src/wp-includes/script-loader.php#L0 |
CSS, should not be loaded in footer. It will look bad to load the website without CSS first. Rest remains the optimizing CSS and Icon-Fonts. We wrote about the Icon-Font before.
In CSS file, if the reference is :
1 2 3 4 | .error404 .post { background-image: url(images/icon-404.png); background-size: 256px 256px; } |
It simply means, by default, the CSS will call the image from the CDN container’s sub-folder named image. Either create a folder in that container by using CyberDuck and upload the images or change the CSS :
1 2 3 4 | .error404 .post { background-image: url("http://anothercontainer.rackcdn.com/icon-404.png"); background-size: 256px 256px; } |
In the later method, page loading will technically more efficient as the container is different.
