2026年9月12日

WordPressでJavaScriptを非同期読み込み（defer/async）に変換する手順

SEO・パフォーマンス

WordPressで読み込むJavaScriptを defer や async に切り替えると、スクリプトの取得中もHTMLの解析が止まらなくなり、最初の表示を早められます。WordPress 6.3 以降は wp_enqueue_script() に読み込み方式を指定する仕組みが標準で用意されているため、現在はタグを文字列置換するよりこちらを使うのが基本です。この記事では、defer と async の違いと使い分け、自分のスクリプトと既存プラグインのスクリプトそれぞれの変換方法、jQuery まわりでつまずく点、変換後の確認方法を説明します。

defer と async の違い

通常の <script src="..."> は、ブラウザがその位置でHTMLの解析を止め、ファイルを取得して実行し終えるまで先へ進みません。<head> 内に多数あると、その分だけ画面が表示されるまでの時間が延びます。

defer：取得はHTMLの解析と並行して進み、実行は解析が終わってから行われます。複数ある場合は、書かれた順番どおりに実行されます。
async：取得は並行して進み、取得が終わった時点ですぐ実行されます。実行の順番は保証されません。

使い分けの目安は次のとおりです。

ページの要素を操作するスクリプトや、他のスクリプトに依存する（または依存される）スクリプトは defer
アクセス解析や広告タグのように、他と依存関係がなく単独で動くスクリプトは async

迷ったら defer を選ぶと、実行順が保たれる分だけ不具合が起きにくくなります。

自分で読み込むスクリプトに defer を指定する

テーマやプラグインを自作している場合は、wp_enqueue_script() の5番目の引数に配列を渡し、strategy を指定します。子テーマの functions.php での例です。

add_action( 'wp_enqueue_scripts', function () {
	wp_enqueue_script(
		'mytheme-main',
		get_stylesheet_directory_uri() . '/js/main.js',
		array(),
		'1.0.0',
		array(
			'strategy'  => 'defer',
			'in_footer' => false,
		)
	);
} );

in_footer を false（<head> に出力）にしているのは、defer なら解析を止めずに済み、しかも早い段階で取得を始められるためです。フッターに置く書き方でも動作しますが、取得の開始が遅くなります。

この仕組みの利点は、WordPressが依存関係を見て安全かどうかを判断してくれる点です。たとえば defer を指定したスクリプトに、通常読み込みのスクリプトが依存している場合や、直後に実行されるインラインスクリプトが追加されている場合などは、実行順を崩さないように defer を付けずに出力することがあります。「指定したのに付かない」と感じたら、依存関係を確認してください。

既存のプラグインやテーマのスクリプトを変換する

自分で登録していないスクリプトも、ハンドル名が分かれば wp_script_add_data() で読み込み方式を後から指定できます。ハンドル名は、HTMLソースの <script ... id="xxxx-js"> の -js を除いた部分か、Query Monitor のスクリプト一覧で確認できます。

add_action( 'wp_enqueue_scripts', function () {
	// プラグイン側の登録が終わったあとに指定するため、優先度を遅らせる
	if ( wp_script_is( 'example-plugin-script', 'registered' ) ) {
		wp_script_add_data( 'example-plugin-script', 'strategy', 'defer' );
	}
}, 100 );

example-plugin-script は例なので、実際のハンドル名に置き換えてください。この方法も依存関係のチェックの対象になるため、安全でないと判断された場合は通常読み込みのまま出力されます。

WordPress 6.3 より前の環境での方法

古い環境では script_loader_tag フィルターでタグに属性を書き足す方法が使われてきました。この方法はWordPressの依存関係チェックを通らないので、対象は依存関係のないスクリプトに限定してください。

add_filter( 'script_loader_tag', function ( $tag, $handle, $src ) {
	$targets = array( 'example-plugin-script' );

	if ( in_array( $handle, $targets, true ) && false === strpos( $tag, ' defer' ) ) {
		$tag = str_replace( ' src=', ' defer src=', $tag );
	}

	return $tag;
}, 10, 3 );

WordPress本体の更新が可能なら、まず本体を更新し、前述の strategy を使う方法に移行するのがおすすめです。

jQuery を defer にするときの注意

もっとも不具合が起きやすいのが jQuery です。テーマやプラグインが本文中に jQuery(function($){ ... }) のようなインラインスクリプトを出力していると、jQuery 本体を defer にした時点で「jQuery is not defined」というエラーが出て、スライダーやメニューが動かなくなります。

jQuery に依存するスクリプトがすべて wp_enqueue_script() で登録されていて、インラインのコードがない場合に限り、jQuery ごと遅らせても動きます。どこかでインラインの jQuery コードが使われていないかを確認できないうちは、jQuery 本体は通常読み込みのままにし、jQuery に依存しない独立したスクリプトから順に変換していくと安全です。

キャッシュ系プラグインの機能を使う場合

WP Rocket、LiteSpeed Cache、Autoptimize、Perfmatters などには、サイト全体のJavaScriptに defer を付ける機能や、利用者が操作するまで実行を遅らせる機能があります（2026年10月現在。機能名や対象範囲は製品・バージョンにより異なります）。コードを書かずに一括で適用できる反面、上記の jQuery の問題などが起きやすいため、除外設定の欄に不具合の出たスクリプトを登録しながら調整します。

自分のコードで strategy を指定している場合でも、プラグインの一括機能と重ねると挙動が分かりにくくなります。どちらか一方で管理するようにしてください。

変換できたか、壊れていないかを確認する

作業の前にはサイトのバックアップを取り、変更後は次の順に確認します。

属性が付いたか：ページのHTMLソースを開き、対象の <script> タグに defer または async が付いているかを見ます。キャッシュプラグインやCDNを使っている場合は、キャッシュを削除してから確認します。
エラーが出ていないか：ブラウザの開発者ツールの「コンソール」で、赤いエラーが出ていないかを確認します。「is not defined」「is not a function」は実行順の問題であることが多いです。
機能が動くか：メニューの開閉、スライダー、フォーム送信、アクセス解析の計測など、JavaScriptに依存する機能を実際に操作します。
効果が出たか：PageSpeed Insights で、レンダリングを妨げるリソースに関する指摘が減ったかを確認します。

不具合が出たら、直前に変換したスクリプトを元に戻し、1つずつ切り分けると原因を特定しやすくなります。

まとめ

defer は順番を保って解析後に実行、async は取得次第実行。迷ったら defer を選ぶ
WordPress 6.3 以降は wp_enqueue_script() の strategy で指定でき、依存関係のチェックも働く
既存のスクリプトは wp_script_add_data() で後から指定でき、ハンドル名はHTMLソースや Query Monitor で調べる
jQuery 本体の変換はインラインスクリプトとの衝突に注意し、独立したスクリプトから順に進める
HTMLソース・コンソール・実際の操作・PageSpeed Insights の順で確認する