PageSpeed Insghts対策

参考になるかはわかりませんが、僕の場合、

function replace_script_tag ( $tag ) {
    return str_replace( "type='text/javascript'", 'async defer', $tag );
}

add_filter( 'script_loader_tag', 'replace_script_tag' );

こういうのを子テーマfunctions.phpに入れてます。

wp_enqueue_script()ってのでscriptタグを読み込んでいるわけですが、プラグインとかのjavascript(jQuery)とかはasync|deferが入ってないのもあるのでtype=text/javascriptの部分をasync deferと入れてます。

WordPress 4.1からscript_loader_tagってのが使えまして、<script>タグの変更ができるフィルターフックになります。

プラグインとかのwp_enqueue_script()で処理されてるものは上記でイケますが、後から読み込むもの、例えばGoogle adsense(これはレスポンシブ広告や、設定でasyncが入れられる)、レンタルサーバーのバナーjs等は別の対処が必要です。
またasyncは非同期に、いわゆる処理ができるようになったら読み込む、deferは後から読み込むと言うことなので、プラグインによってはasyncだと動作しない場合があったりして別途処理を分ける必要があります。
そのあたりはまた何かしらぐぐってみてください。

うちの環境で、
akismet,
color-box,
crayon syntax-highligher,
Simplicityの自前javascript(親・子テーマ),
jQuery_lazyload

あたりは問題なく動作しているようです(たまにエラーも出ますけど（笑）。

色々と言われてるjetpackのdevicepx(retina/HiDpi関係のjs)は、作者自らの回答通り、

function dequeue_devicepx() {
wp_dequeue_script( 'devicepx' );
}
add_action( 'wp_enqueue_scripts', 'dequeue_devicepx', 20 );

これを子テーマfunctions.phpに入れて対応しています。
参考: そのトピック(プラグインフォーラム)

css自体は遅延読み込みができるわけですが、そうするとアクセスする一瞬、素のhtmlが書き出されたりしてチラつきの原因にもなるので、僕は基本minfy(縮小化、いわゆる圧縮)で対応しています。

現在の自分が更新しているサイトはXdomainと言う無料レンタルサーバーで、htaccess自体は利用できますが、例えばSimlicityに付属しているhtaccessのテンプレートのような内容、いわゆるキャッシュ期間を設定したり、gzipしたりというものは対応していません(それ自身が対応していないのではなくコマンドが利用できない)。
そのため、例えばAutoptimizeのような便利なプラグインも、キャッシュフォルダ部分にhtaccessを利用するのでエラーが出て利用できないわけです(500 internal server error等)。

Xdomain自体は、リバースプロキシのような独自のキャッシュができる方法でサーバー構成で動作しているらしく、高速に動作するので必要ないといえばそうなのですが、PageSpeed Insghtsには怒られます（笑）
怒られてスコアも高くはありませんが、修正が必要部分が、修正を考慮までにはなったので後はcssをどうにかしたいなぁと考えている所です。
現在レンダリングブロックのパートでは、後から読み込んでいるXdomainのバナーのjsが1つだけ、残り18個のcssリソースがブロッキングしてますぜとなっています。
プラグインのcssは縮小化ぐらいしかできなかったりするわけですが、Simplicityのテーマで利用しているcssは1つにまとめられるだろうし、圧縮も可能なのでスコア自体はもう少し伸びそうですが、それが実際利用する時にどれぐらい有用なのかは何とも言えません。

参考までに: Blazechariot(Xdomain)

http/2が本格的に広まれば、レンダリングブロックがかなり軽減される(※)のではないかと思うので、どうなることやらですね。
※キャッシュプッシュ: 今まではhtmlを解釈した後にcssのダウンロードだったけれども、サーバーはクライアントの要求無くリソースを送信できるようになります。またクライアントがリソースを持っている場合は断ることもできる。
まぁhttp/2になっても半分の読み込み時間になるということはないんでしょうけどね。

＆quot; は "
＆#039; は '

です。

#25579

で投稿した「スクリプトに defer asyncを入れる」のはちょっと利用を控えていただきたいと思ったり。
今しがたまで、色々と調べていたんですが、PCではおそらく問題ないと思うんだけれど、スマホで色々と問題が出てきそうで、更に調査中です。
なんとか良い方法を見つけたいけど、どうも面倒なのが多くて、どうするか考えてます。

ひとまずの所、#25579で投稿したスクリプトの、

return str_replace( “type=’text/javascript'”, ‘async defer’, $tag );

これのasyncを、
return str_replace( “type=’text/javascript'”, ‘defer’, $tag );

こうしたり、

return str_replace( ” src”, ‘defer’, $tag );

こうすると、うちの環境ではエラーはでないようです。asyncは非同期に、実行できるようになったらするので、レンダリングされたhtmlに対してjQueryで何かするものに関してはdeferで良いかなぁなんて感じです。
asyncにしてもdeferにしてもhtmlの読み込みを邪魔しないので、レンダリングブロックにはならないと思います。

例えば　crayonとかのsyntax-highlighterとかは、preとかcodeとかで囲まれた部分を加工するわけですが、それが読み込まれる前に該当するスクリプトを読むと「タグがねぇよ」ってエラーを出したりします。
Google adsenseとかでレスポンシブ広告にしていると、例えばサイドバートップの部分に「幅やら高さはどうした？」と言うような事がありえます。幅や高さはcssの部分ですが、まず最初にhtmlが作られて処理をすると言う事が多いと思うので、どうしてもasyncでしかダメと言う場合を除いて上記の方法でscriptに関するレンダリングブロックは防げると思います。

deferは遅延読み込みで後から実行されるため、その分、(jQuery適用した後の)表示まで遅延される(表示が遅れる)と思いますが、まぁGoogleはそうしろというのでしょうがない所です。
Googleのレスポンシブ広告にはasyncが入ってますけども、後から読み込む外部スクリプト(※)に関しては上記スクリプトは適用されないので問題ないと思います。

※ text widgetで書く部分

うぉぉ、間違えた

return str_replace( ” src”, ‘defer’, $tag );　☓
return str_replace( ” src”, ‘defer src’, $tag );　◯

＞わいひらさん
＞hidekichiさん
ご返信ありがとうございます。