WordPress 本身以及主题和插件通常需要加载一些 JavaScript 来实现某些特殊功能。为了最大限度地保证兼容性，不至于出现 JavaScript 失效的情况，所以一般在页头加载 JavaScript 文件。但是根据 Yahoo 开发者论坛的建议，加载 JavaScript 应该尽量在页尾以提高页面的显示（响应、渲染）速度。本文根据作者的使用经验介绍几个相关插件，并说明如何在某些特殊页面仍然在页头加载 JavaScript。

下面先简单介绍几个相关的优化 JavaScript 的 WordPress 插件及特点，然后演示如何处理一些特殊情况。

一、优化JavaScript的WordPress插件

我曾经用过 WP Minify、Autoptimize、JavaScript to Footer这三个插件，下面一一介绍其特点。

1、WP Minify

这个插件将 Minify 引擎整合到 WordPress 中。一经启用，该插件就能够合并和压缩你的 JS 和 CSS 文件来提高页面的加载速度。

WP Minify 能够抓取生成的 WordPress 页面中的 JS/CSS 文件，将文件列表传递给 Minify 引擎。Minify 引擎处理后返回一个加强、精简并经过压缩的 JavaScript 或样式表文件（CSS），由 WP Minify 将其替换到 WordPress 页头中。

其主要特点是：

• 易于使用；
• 对 JavaScript、CSS 和 HTML 均有效；
• 提供了调试工具；
• 能够处理外部 JS 和 CSS 文件；
• 能够排除指定 JS 和 CSS 文件；
• 能够指定处理后的 JS 和 CSS 文件的位置（页头或页尾，甚至别的地方）；
• 可对处理后的 JS 和 CSS 文件添加过期时间等。

以前使用免费空间的时候，因为速度慢，我曾经利用这个插件在 K2 主题下的一个漏洞来减少访问网站时需要下载的内容量（详见给基于WordPress + K2 Theme的网站加速）。

当 WordPress 3.1 测试版出来后，我发现 WP Minify 与之不兼容，会导致网站无法正确加载。

2、Autoptimize

也许将来 WP Minify 升级后会解决不兼容问题，但是我等不及了。后来找到了 Autoptimize 这个具有类似功能的插件，而且这个插件操作更简单。

Autoptimize 整合、精简并压缩所有的 JS 和 样式表（CSS）文件，增加缓存过期标志。然后将样式表文件放到页头（同样是为了提高页面加载效率），并将 JS 文件放到页尾。它还能够精简 HTML 代码，给你的页面瘦身。不过我觉得给 HTML 页面瘦身作用不是很明显，只要你的服务器开启了 Gzip 压缩特性就没必要这么做了。

默认情况下，Autoptimize 会按照上面介绍的方式优化所有 HTML/CSS/JavaScript 。

我个人觉得，Autoptimize 是比 WP Minify 更好用的 WordPress 优化插件。

3、JavaScript to Footer

这个插件写的非常简洁。我查看了源代码，完成任务的代码只有 6 个 WordPress 函数（见下文），也就是 6 行。所以这个插件从创建之后就怎么更新过。我一开始就因为见它最后更改日期还停留在2009年9月22日，所以把它给忽略了。

但是它仅仅优化 JavaScript 的加载位置，也就是将所有在 WordPress 中正确声明了的 Javascript 文件都给移到页面末尾来加载。它没有对 HTML 代码和 CSS 样式表文件作任何处理。

二、使用方法

相信对于大多数 WPer 来说，看了前面的介绍就知道如何选择自己需要的优化插件并合理使用了。无非是基于以下三个方面来考虑：

1. 你的页面模板中是否使用了大量的 HTML 注释、空格、空行等标记？如果没有，那么你就不需要为了一点点（开启 Gzip 压缩时通常 1% 以下）的带宽节省而使用 HTML 精简功能；
2. 你的页面中是否加载了多个 CSS 样式表文件？如果没有，你也不需要通过插件来精简和整合 CSS 样式表，手工精简和整合 CSS 样式表比使用插件更加简单有效；
3. 基于 WordPress 默认会在页头中加载 JavaScript，一般的 WordPress 网站都需要对 JS 的加载位置进行优化。但是如果你大部分的页面也都需要在页面头部加载 JS 以保证不会出现 JS 失效的情况，那你就不能进行这样的优化了。

在我看来，WP Minify 就不需要了，原因在前面已经说过了。那么剩下的 Autoptimize 和 JavaScript to Footer 可以选用其一或者两者配合使用（如果是配合使用，当然是使用前者的 HTML 和 CSS 精简/整合功能，而使用后者的 JS 位置控制功能，因为后者就这一个功能）。

三、特殊情况处理

我只需要控制 JS 的加载位置，所以就选择了 JavaScript to Footer。因为我的页面中也就四五个 JS 文件，又是放到页尾加载，我觉得没必要进行整合。但是对我来说还是有些特殊情况需要处理。

在我的Buzz和站外资源 2 个特殊页面里，我在自建的页面模板中加载了一些特殊的 JavaScript 代码（详见将Buzz输出整合进网页和为WordPress创建个性化链接页面）。因为不会使用 wp_enqueue_script() 函数（其实对于只有个别页面需要这样做的时候，也没必要去讨那个麻烦），我就直接在模板中调用了需要的 Javascript。而在将所有 WordPress 中的 JS 文件移到页尾之后，我的这些 JS 就不能正常工作了。所以我需要针对这 2 个特殊页面做些处理。

根据 JavaScript to Footer 的源代码，

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);

我在那 2 个特殊页面模板的 wp_head() 函数前加入下面的代码，将上述过程逆转过来，也就是使之失效，恢复成了本来的加载位置：

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);

从而解决了问题。如果需要，你可以查看水景一页上的相关页面，看看 JS 文件的加载位置是不是有所不同。

四、结论

在 WordPress 中加载 JavaScript 最好使用 wp_enqueue_script() 函数以减少问题提高效率。如果不是有这些特殊情况要处理，使用 Autoptimize 显然比较好，它全面完成任务而且使用简单。

但是如果使用的主题本身已经很简洁了，那么 JavaScript to Footer 更简单高效，也就更好。

另外，我知道的要求必须在页头加载 JavaScript 文件的插件有：

• NextGEN Gallery

如果你还有别的信息，欢迎在下面留言告知。

本文发表于水景一页。永久链接：http://cnzhx.net/blog/wordpress-javascript-optimization/。转载请保留此信息及相应链接。