這篇文章主要介紹了幾個優化WordPress中JavaScript加載體驗的插件,一般來說在WordPress中加載JavaScript最好使用wp_enqueue_script()函數以減少問題提高效率,需要的朋友可以參考下。

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 文件添加過期時間等。

當 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 樣式表文件作任何處理。

根據 JavaScript to Footer 的源代碼，它使用下面的 6 行代碼來完成工作：

1. remove_action('wp_head', 'wp_print_scripts'); 
2. remove_action('wp_head', 'wp_print_head_scripts', 9); 
3. remove_action('wp_head', 'wp_enqueue_scripts', 1); 
4. add_action('wp_footer', 'wp_print_scripts', 5); 
5. add_action('wp_footer', 'wp_enqueue_scripts', 5); 
6. add_action('wp_footer', 'wp_print_head_scripts', 5); 

如果有需要，可以在某個特定 WordPress 模板的 wp_head() 函數前加入下面的代碼，將上述過程逆轉過來，也就是使之失效，恢復成了本來的加載位置：

1. remove_action('wp_footer', 'wp_print_scripts', 5); 
2. remove_action('wp_footer', 'wp_enqueue_scripts', 5); 
3. remove_action('wp_footer', 'wp_print_head_scripts', 5); 
4. add_action('wp_head', 'wp_print_scripts'); 
5. add_action('wp_head', 'wp_print_head_scripts', 9); 
6. add_action('wp_head', 'wp_enqueue_scripts', 1); 

當然只是說某些特定的頁面模板，如果是所有頁面，那干脆禁用該插件好了 :D

二. 使用方法

相信對于大多數 WPer 來說，看了前面的介紹就知道如何選擇自己需要的優化插件并合理使用了。無非是基于以下三個方面來考慮：

你的頁面模板中是否使用了大量的 HTML 注釋、空格、空行等標記？如果沒有，那么你就不需要為了一點點（開啟 Gzip 壓縮時通常 1% 以下）的帶寬節省而使用 HTML 精簡功能；

你的頁面中是否加載了多個 CSS 樣式表文件？如果沒有，你也不需要通過插件來精簡和整合 CSS 樣式表，手工精簡和整合 CSS 樣式表比使用插件更加簡單有效；

基于 WordPress 默認會在頁頭中加載 JavaScript，一般的 WordPress 網站都需要對 JS 的加載位置進行優化。但是如果你大部分的頁面也都需要在頁面頭部加載 JS 以保證不會出現 JS 失效的情況，那你就不能進行這樣的優化了。

在我看來，WP Minify 就不需要了，原因在前面已經說過了。那么剩下的 Autoptimize 和 JavaScript to Footer 可以選用其一或者兩者配合使用（如果是配合使用，當然是使用前者的 HTML 和 CSS 精簡/整合功能，而使用后者的 JS 位置控制功能，因為后者就這一個功能）。我只需要控制 JS 的加載位置，所以就選擇了 JavaScript to Footer。因為我的頁面中也就四五個 JS 文件，又是放到頁尾加載，我覺得沒必要進行整合。

三. 特殊情況處理

雖然將 JavaScript 文件都放到頁面末尾加載對于頁面加載速度很有幫助，但是請注意，所謂頁面末尾指的是在 WordPress 的 wp_footer() 函數中調用，這個函數通常剛好位于頁面的 </body> 標簽前面（當然是末尾了）。

有時候我們可能會在 wp_footer 函數出現之前就需要用到某些 JavaScript，比如 jquery.js 文件。

這樣的情況也是很常見的。比如我單獨創建了一個鏈接頁面，在這個頁面中我使用了 jQuery 方法來獲取鏈接網站的 favicon。很顯然，我只需要在這唯一一個頁面使用這部分代碼，所以將這段代碼直接放在這個頁面模板中是最好的做法。問題來了：這部分內容顯然是在 wp_footer 之前出現的，那么這段代碼就在 jquery.js 文件之前出現了，導致該代碼段實際上無法工作，因為調用 jQuery 方法的代碼段必須比 jquery.js 文件后加載。

那么如何處理這種特殊情況呢？其實也很簡單。以上面的情景為例，既然我們需要先調用 jquery.js 文件，那我們就在該代碼段之前直接輸出需要的 jquery.js 文件，不使用 wp_enqueue_script() 函數，而改用 wp_print_scripts() 函數。

wp_enqueue_script() 與 wp_print_scripts() 的區別是：wp_enqueue_script() 是告訴 WordPress “我在這個頁面上需要用到某個 JavaScript 文件，你可要記得加載啊”。WordPress 默認在 wp_head() 中處理，而我們改為在 wp_footer() 中處理。wp_print_scripts() 則直接在你使用此方法的位置輸出需要的 JavaScript 文件，而不是加入到 WordPress 的處理任務中。

如果我們在頁面的中間使用：

<?php wp_print_scripts('jquery'); ?>

<?php wp_enqueue_script('jquery'); ?>

告訴 WordPress 需要加載 jquery.js，WordPress 在 wp_footer() 中處理的時候也會先檢查前面是不是已經有了，如果有了就不會再重新加載一次。

四. 結論

在 WordPress 中加載 JavaScript 最好使用 wp_enqueue_script() 函數以減少問題提高效率。如果不是有這些特殊情況要處理，使用 Autoptimize 顯然比較好，它全面完成任務而且使用簡單。

但是如果使用的主題本身已經很簡潔了，那么 JavaScript to Footer 更簡單高效，也就更好。