1. WP minify
This plugin integrates the Minify engine into WordPress. Once enabled, the plugin will be able to merge and compress your JS and CSS files to increase the loading speed of the page.
Its main features are:
- easy to use;
- Debugging tools are provided;
- Ability to handle external JS and CSS files;
- Ability to exclude specified JS and CSS files;
- Ability to specify the location of the processed JS and CSS files (header or footer, or even elsewhere);
- You can add expiration time to the processed JS and CSS files.
When the WordPress 3.1 beta came out, I found that WP minify incompatible with it, will cause the Web site can not load properly.
Perhaps the future WP Minify upgrade will solve the incompatibility problem, but I can't wait. Later, we found Autoptimize, a plug-in with similar functionality, and the plug-in was simpler to operate.
Autoptimize consolidates, streamlines, and compresses all JS and style sheet (CSS) files, adding cache expiration flags. Then put the stylesheet file on the page header (again to improve the page load efficiency), and put the JS file to the end of the page. It also streamlines the HTML code and gives your page a thin body. But I don't think it's very obvious to thin HTML pages, as long as your server turns on Gzip compression, there's no need to do that.
I personally feel that autoptimize is more than WP minify better use of WordPress optimization plug-ins.
This plugin is very simple to write. I looked at the source code, the completion of the task of the code only 6 WordPress functions (see below), that is, 6 lines. So this plugin has been updated since it was created. I started because I saw it. The last change date is still on September 22, 2009, so ignore it.
Remove_action (' Wp_head ', ' wp_print_scripts ');
Remove_action (' Wp_head ', ' wp_print_head_scripts ', 9);
Remove_action (' Wp_head ', ' wp_enqueue_scripts ', 1);
Add_action (' Wp_footer ', ' wp_print_scripts ', 5);
Add_action (' Wp_footer ', ' wp_enqueue_scripts ', 5);
Add_action (' Wp_footer ', ' wp_print_head_scripts ', 5);
If necessary, you can add the following code to the Wp_head () function of a particular WordPress template to reverse the process, that is, to invalidate it and restore it to its original loading location:
Remove_action (' Wp_footer ', ' wp_print_scripts ', 5);
Remove_action (' Wp_footer ', ' wp_enqueue_scripts ', 5);
Remove_action (' Wp_footer ', ' wp_print_head_scripts ', 5);
Add_action (' Wp_head ', ' wp_print_scripts ');
Add_action (' Wp_head ', ' wp_print_head_scripts ', 9);
Add_action (' Wp_head ', ' wp_enqueue_scripts ', 1);
Of course just say some specific page template, if it is all pages, then simply disable the plugin well:D
Two. How to use
I believe for most wper, read the previous introduction to know how to choose the optimization of their needs and reasonable use of plug-ins. It is based on the following three considerations:
Do you use a lot of HTML annotations, spaces, blank lines, and so on in your page template? If not, then you do not need to use HTML streamlining for a little bit of bandwidth savings (when Gzip compression is typically below 1%);
Do you have multiple CSS style sheet files loaded in your page? If not, you do not need to use plug-ins to streamline and consolidate CSS style sheets, manual streamlining and integration of CSS style sheets is simpler and more efficient than using Plug-ins;
Three. Special case handling
Such a situation is also very common. For example, I created a separate link page where I used the JQuery method to get the favicon of a linked site. Obviously, I just need to use this part of the code on this single page, so it's best to put this code directly in the page template. The problem: This part of the content is obviously before wp_footer, so this code appears before the Jquery.js file, causing the code snippet to actually work because the code snippet that calls the JQuery method must be loaded later than the Jquery.js file.
So how do you deal with this particular situation? It's actually very simple. Taking the above scenario as an example, since we need to call the Jquery.js file first, we'll just output the required jquery.js file directly before the code snippet, instead of using the Wp_enqueue_script () function, rather than the wp_print_scripts () function.
If we use it in the middle of the page,
<?php wp_print_scripts (' jquery ');?>
The Jquery.js file is directly exported (usually its compressed version jquery.min.js), so even if other plug-ins or something is used,
<?php wp_enqueue_script (' jquery ');?>
Tell WordPress need to load jquery.js,wordpress in Wp_footer () when the processing will also check the front is not already there, if there is no reload again.