スクリプトタグに「async」や「defer」属性を自動で付加する方法とWP6.3以降の対応例

WordPress 6.3では、別ファイルに書かれたスクリプトの登録を行う「wp_register_script」と、別ファイルに書かれたスクリプトの適用をする「wp_enqueue_script」に「async」「defer」属性を追加するパラメーターが指定できるようになりました。

Registering scripts with `async` and `defer` attributes in WordPress 6.3

詳しくは上の公式ブログを見ていただければと思います。

これによって、スクリプトの読み込みを行う時点で、読み込みを遅延させる「async」または「defer」属性を追加することができるようになり、WordPress6.3以降を使用していて、かつ、スクリプトの登録＆読み込みプログラムで属性の指定をしていると、HTML上では以下の赤字部分のように出力されるようになります。

<script src='スクリプトのURL' id='スクリプトのID' defer data-wp-strategy='defer'></script>

主旨とは外れてしまうので、さらっと書いておくことにしますが、この「async」や「defer」属性を追加することで、読み込みが途中で停止する、いわゆるレンダリングのブロックを回避することができ、表示速度の向上やCWV(Core Web Vitals)の改善を図ることができます。

ただ、これにより、テーマへ以下のような「script_loader_tag」を使ったカスタマイズコードを追加して「defer」や「async」属性を追加している場合や、今後このパラメーターを追加しているプラグインと追加していないプラグインが混在していくと思われ、注意が必要かと思われます。

このページを興味を持って読む方には心配は無用かと思いますが、環境によってうまく動作しなかったり、テーマやプラグインの既存の機能と競合して不具合が出る可能性がありますのでご注意ください

WordPressで出力されるスクリプトリンクに「async」や「defer」属性を自動で追加させるコード

WordPressの表示高速化を目指すプラグインの多くは、出力されるスクリプトを適切に読み込ませることで最適化を図る機能が備わっています。

やり方はさまざまですが、以下のコードをテーマのfunctions.phpへ追加するだけで、HTML上へ出力されるスクリプトタグに、「defer」属性が追加され、いわゆる「レンダリングをブロックするコンテンツ」と指摘されるのを防止し、かつ、表示速度も向上します。

/* JS非同期読み込み defer */
if(!is_admin()){
if ( !function_exists( 'pwcn_defer_parsing_of_js' ) ){
function pwcn_defer_parsing_of_js( $url ) {
	if ( FALSE === strpos( $url, '.js' ) ) return $url;
	if ( strpos( $url, 'wp-i18n-js' ) ) return $url;
	if ( strpos( $url, 'wp-hooks-js' ) ) return $url;
	
	return str_replace( " src", " defer src", $url );
}
}
add_filter( 'script_loader_tag', 'pwcn_defer_parsing_of_js', 10 , 2);
}

ちなみにこの機能はこのサイトで公開している「Hima Art Utility」プラグインにも搭載しており、上記のコードはプラグインのソースをコピーして、ユーザー定義関数名を変更したものです

WordPress6.3以降では対策が必要かも

たったこれだけのコードで特にCWVの顕著な改善ができるので、ぜひ有効化しているテーマのfunctions.phpへ追加して利用してほしいのですが、前述したように、WordPress6.3以降で使用する場合には、以下のような不具合というか不都合が発生する可能性があります。

• WordPress6.3以降で、プラグインやテーマ側のスクリプトの読み込みプログラムに属性指定がある場合には、2重に出力されてしまうようになる
• 双方の属性の指定によっては、2重に出力された属性で「async」と「defer」の両方が出力されてしまう

星の数ほどあるプラグインやテーマすべてが一斉にこの属性を付加するようになれば、上記のカスタムコードは必要もないですし、問題は起きないのですが、そうはいかないので、何かしらの措置が必要だと思います。

また、高速化を目論むプラグインで、この手法を使用してスクリプトの遅延処理をさせているものでは、同様の不都合や不具合が起きる可能性がありますので注意が必要です。

そこでいろいろなケースを考え、自身でテストをいろいろと行って出した結論が「一旦WordPress側で付加した属性を削除した上で、改めて属性を追加する」方法です。

具体的には、上記のコードの前に、追加された「defer」や「async」属性を一旦削除するというものを追加した、以下のようなコードになります。

//管理画面では適用しない
if(!is_admin()){
/***** サイト高速化 *****/
/* 一旦吐き出されるdefer属性を削除 */
if ( !function_exists( 'pwcn_delete_defer_parsing_of_js' ) ){
function pwcn_delete_defer_parsing_of_js( $url ) {
	if ( FALSE === strpos( $url, '.js' ) ) return $url;

	return str_replace( " defer data-wp-strategy='defer'", '', $url );
}
}
add_filter( 'script_loader_tag', 'pwcn_delete_defer_parsing_of_js', 10 );
}

/* 一旦吐き出されるasync属性を削除 */
if(!is_admin()){
if ( !function_exists( 'pwcn_delete_async_parsing_of_js' ) ){
function pwcn_delete_async_parsing_of_js( $url ) {
	if ( FALSE === strpos( $url, '.js' ) ) return $url;

	return str_replace( " async data-wp-strategy='async'", '', $url );
}
}
add_filter( 'script_loader_tag', 'pwcn_delete_async_parsing_of_js', 10 );
}

/* JS非同期読み込み defer */
if(!is_admin()){
if ( !function_exists( 'pwcn_defer_parsing_of_js' ) ){
function pwcn_defer_parsing_of_js( $url ) {
	if ( FALSE === strpos( $url, '.js' ) ) return $url;
	if ( strpos( $url, 'wp-i18n-js' ) ) return $url;
	if ( strpos( $url, 'wp-hooks-js' ) ) return $url;
	
	return str_replace( " src", " defer src", $url );
}
}
add_filter( 'script_loader_tag', 'pwcn_defer_parsing_of_js', 10 , 2);
}

まずは、上の2つのユーザー定義関数で、WordPressの「wp_register_script」や「wp_enqueue_script」関数を使ってHTML上で追加出力された「defer」または「async」属性を削除し、改めて最後のユーザー定義関数で「defer」属性を追加するというものです。

属性が追加されているかを判別する関数があればと思ったのですが、調べ方が悪いのか、2023年7月17日現在では、存在しないようなので、この方法で重複や別属性が付加されてしまうのを防ぐしかなさそうです。

一応【Hima Art Utility】では、このコードを使って、バージョン3.1で対応する予定です。

他に良い方法があるとは思いますが、一応メモとして公開しました。

今回のWordPress6.3のスクリプト処理について疑問を持たれている誰かの役に立てば幸いです。

ありがたい属性設定追加機能ではあるものの．．．

逆に今までどうして一旦出力したスクリプトタグに属性を追加するんだろう、出力時に追加された方がいいのに．．と常々思っていましたので、今回のアップデートについては、個人的にはとってもありがたい機能だと思います。

ただやはり前述したように、途中から追加されることで「属性が設定されているもの」と「属性が設定されていないもの」が混在し、「設定されていないものには属性を追加する」という措置が必要になるので、気づかないうちに誤認識されたりすることがあるのかも．．とも思います。

もしもテーマやプラグインを作成したりカスタマイズしたりしたことのない方や、プログラム自体に興味のない方（テーマ任せ、プラグイン任せの方）で、この変更によって何等かの動作不良などが起こると、また何の気なしに「バグ」なんて言い方されるのでしょうね．．．。