Some nice comments here – http://wphacks.com/still-no-wordpress-271/ .
Updates from January, 2009 Toggle Comment Threads | Keyboard Shortcuts
-
Matt
-
Andrew Ozz
Optimizing script loading, implementation
The “first run” of the script loading optimization is in trunk. It uses both methods: splits the scripts queue in head and footer parts, then concatenates and compresses them before sending them to the browser. Most CSS is also concatenated and compressed.
There are two new constants that disable concatenating and compression:
CONCATENATE_SCRIPTSandCOMPRESS_SCRIPTS. Setting the first to false would disable both concatenating and compression, the second disables compression only. There is also a simple AJAX method to test if compressing from PHP works as expected on the server. It is run only once and the result is saved as an option. It will run again if that option is deleted.For plugin authors there are two new actions in the admin footer:
do_action('admin_print_footer_scripts');anddo_action("admin_footer-$hook_suffix");. The order of execution is:"admin_footer"can be used to print scripts before the default footer scripts"admin_print_footer_scripts"used to print the default scripts followed by any external scripts that were queued for the footer"admin_footer-$hook_suffix"can be used to print scripts that should appear on a specific admin page only
The preferable way for plugins to add scripts to admin pages would be either to enqueue them properly (which is a must if the script depends on a default script) or to use the
$hook_suffixhooks to add them only where needed.New hook(s) may also be needed in the functions dealing with splitting or concatenating the script queue. Suggestions are welcome either here as comments or on trac as enhancements tickets.
Update: added
do_action('admin_enqueue_scripts', $hook_suffix);allowing plugins to easily queue scripts on the exact pages. To find out the value for$hook_suffixon a specific page, echo it from your function and visit the page.Queueing a script for the footer follows the same syntax as in script loader:
$scripts->add( 'handle', 'full/url/to/file.js', array( 'dependency' ), 'version' ); $scripts->add_data( 'handle', 'group', 1 );
Group 1 means queue for the footer, group 0 (zero) is the default.
-
bttv
I hope this optimization work without errors in version 2.8.
-
Kim
Super duper writeup on how to use the built-in wp_scripts and wp_styles hooks… Also I learned about the JS footer thing
Thanks again!
-
Tsafi
Thanks Andrew you realy save me alot of time with this post.
Andrew Ozz
Optimizing script loading, part II
After more tests and research it seems the best two options for the WordPress admin are either minifying all scripts and loading most in the footer or concatenating and compressing them on per page basis.
Minifying and loading scripts in the footer gives slightly slower performance with both cold and primed cache and would depend on the ability to set appropriate caching headers on the server. On the plus side this method would be compatible with the current plugins and wouldn’t introduce higher server load.
On the down side the loading speed improvement with primed cache would depend on the availability of mod_headers and/or mod_expires (presuming most installations are on Apache). It seems many hosts have either one or both modules installed but that still leaves a lot of installations without proper caching headers. In these cases the browser would keep checking for updated content which would increase the loading time with primed cache considerably.
Concatenating and compressing all scripts would give better speed improvement and we will be able to set all needed headers. The last couple of days I’ve been testing a method that uses a separate php file similar to how the Gears manifest is produced. This is the same basic method used by many “website php compressors”, a stand-alone php function that gets as argument the names of the needed scripts then concatenates and compresses them. It doesn’t use server side caching (that proved to be problematic on some servers) since the cold cache page hits on the admin are relatively few.
The advantage is that WordPress is not run second time on every cold cache page load so it uses a lot less server CPU time and memory. The disadvantage is that it would work only for the default scripts whose paths are included in the script loader. This also seems to be compatible with all existing plugins as any additional scripts are loaded after the single script and all requirements are satisfied.
Another disadvantage is that a few hosts seem to compress all php output in a non-standard way that may result in double compression. This method would also need “Optimization options” screen with a few checkboxes that would allow the user to enable/disable the concatenating and compression as it won’t be needed when using Gears.
GaMerZ 8:09 am on January 15, 2009 Permalink |
Hmm, any idea how do I queue script for the footer?
Andrew Ozz 9:00 am on January 15, 2009 Permalink |
Just updated the post with an example.
GaMerZ 9:09 am on January 15, 2009 Permalink |
Thanks =D What about the footer for the normal pages?
perhaps modify wp_enqueue_script to accept 1 more argument which is group?
So that one can do this
wp_enqueue_script('wp-postratings', plugins_url('wp-postratings/postratings-js.js'), array('jquery'), '1.50', 1);GaMerZ 9:37 am on January 15, 2009 Permalink |
I managed to enqueue stylesheets to specific pages in WP-Admin with the following code:
### Function: Enqueue Ratings Stylesheet In WP-Admin add_action('admin_enqueue_scripts', 'ratings_stylesheets_admin'); function ratings_stylesheets_admin($hook_suffix) { $postratings_admin_pages = array('wp-postratings/postratings-manager.php', 'wp-postratings/postratings-options.php', 'wp-postratings/postratings-templates.php', 'wp-postratings/postratings-uninstall.php'); if(in_array($hook_suffix, $postratings_admin_pages)) { wp_enqueue_style('wp-postratings-admin', plugins_url('wp-postratings/postratings-admin-css.css'), false, '1.50', 'all'); } }As stylesheet will always be in the head, this will work beautifully.
Most people register JavaScripts via wp_enqueue_script() or a combination of wp_register_script() and wp_print_scripts(). Accessing $wp_scripts and setting the group via add_data() is a little bit weird at least from a plugin author point of view.
If we can get wp_enqueue_script() to have a “group” argument. The script loader will know whether when the JavaScript will be loaded at the header or footer and load it accordingly while still hooking onto “wp_print_styles” or even “init”.
In order to print JavaScript onto a normal page (outside WP-Admin), currently I have to hooked onto “wp_footer”, calling wp_register_script() and then calling wp_print_scripts().
Andrew Ozz 10:44 am on January 15, 2009 Permalink |
Agreed, will add the extra param to wp_enqueue_script() and wp_register_script().
The front-side problem is a harder one. Many themes don’t seem to have the “wp_footer” call. The “get_footer” action can be used instead but that makes printing scripts there less effective as it runs too early, before the footer HTML. Even seen a few themes that don’t have a consistent footer and don’t use “get_footer”.
Frank 11:13 am on January 15, 2009 Permalink |
Thanks, i wait so long for this function.
GaMerZ 1:33 pm on January 15, 2009 Permalink |
@Andrew: Yea, some themes does not even have wp_head() in their header.php as well. The only way around this is to bring awareness I think.
Frank 6:33 pm on January 15, 2009 Permalink |
Hello Andrew,
i hope you write over the new paramters for hook in the footer of frontend. This is very nice for better perfromance and control the js in footer. I like the wp_enqueue_* functions and i hope more themes-developer use thsi for intecrate the js-libraries. I see so much themes with a lot of plugins and many plugins load the sam js-library in the head and the site is slow and the user can not read the content. T think, wp_enqueue* is a very nice function for control js and css in the site. Very good for backend in plugins and also for hook in frontend.
*sorry for my bad english