そもそも「セキュリティ対策」と一口に言ってもその範囲は広いわけで、健康管理に例えるなら「予防」や「診断」、「治療」とったカテゴリがあるワケで、さらに「予防」的なものには、

• 「定期的にバックアップをとっておきましょう」的な「定期検診」系
• 「常に最新版にアップデートしておきましょう」的な「うがい励行」系
• 「パーミッションやパスワードを強化しましょう」的な「体力増強」系
• 「2要素認証やファイアウォールを導入しましょう」的な「マスク着用」系

とまぁ色々あるワケです（ヘタクソな例えでスミマセン）。

一方、WPScan の脆弱性データベース には、プラグインやテーマが毎月10個ほど、続々と登録され続けています。

そこで私が最近こだわっているのが「未知の脆弱性という病巣を抱えたプラグインやテーマへの攻撃」を防御する「免疫力強化」系（！？）です。

ということで、IP Geo Block の現状の防御力を調べ、今後の開発の方向性を見定めるために、プラグインの脆弱性データベース から最新の50個を順に拾い、「攻撃ベクタ」という観点で分析を実施してみました（ものすごく骨の折れる作業でした ）。

自分でも予想外の結果だったので、ここに公開します！

分析条件

DBの最新から順に無料で落とせるプラグインを拾い、公開されている「概念実証」（POC）を元にそのパターンを次の様な定義の「攻撃ペクタ」で分類しました。

攻撃ベクタ

＝ 脆弱性の種類 × 攻撃経路

「脆弱性の種類」は、XSS や SQLI、LFI、CSRF などを表します。また「攻撃経路」は「WordPress に備え付けの入口」という狭義の意味として、以下の分類としました。

AX

WordPress 標準の Ajax を経由した攻撃

FE

一般公開ページの URI を経由した攻撃

PD

プラグイン PHP ファイルへの直接攻撃

WA

wp-admin 配下のファイルを経由した攻撃

また特に今回の分析のミソは、「何種類の脆弱性をカバーできるか」ではなく、「脆弱性に関する実際の統計的分布に基づいた攻撃経路の分布が得られる事」にあると考えています。別な言い方をすれば、「脆弱性の種類」と「攻撃経路」のどちらに着目した方がより効果的な防御が出来るかを調べたかったのです。

分析結果

まずは50件に占める「攻撃経路」の割合を以下の図に示します。同時に IP Geo Block の前バージョンと最新バージョンのカバー範囲を重ねてみました。

IP Geo Block は、国コードだけでは防げない攻撃を遮断する「ゼロディ攻撃の防御（WP-ZEP）」を装備しているのがウリです（少なくとも私的には）。そこで WP-ZEP の防御力を推定するためのコード・リーディングや幾つかの再現テストも同時に実施しました。

次の表はその結果で、IP Geo Block 2.1.0 の防御成否を示しています。「GEO」は「国コード」による遮断の成否を、「ZEP」は WP-ZEP による遮断の成否をそれぞれ表していて、単純な防御率としては、前バージョンの 2.0.8 で26%、今回更新の 2.1.0 では60%となりました。

表を眺めるみると、何となく「攻撃経路」に着目した方が良いのでは？ という感じがしています（いい加減な、結果ありきの分析でゴメンナサイ）。

今後の対応

上の表を 「経路」で並べ替えて みて下さい。NG が残っているのは、ほとんどが「一般公開ページの URI を経由した攻撃（FE）」と「プラグイン PHP ファイルへの直接攻撃（PD）」であることが分かります。これらが厄介なのは、管理者権限を持たない一般訪問者向けの機能を含んでいるという点です。

実は IP Geo Block 2.1.0 は、今回の分析を元に「PD*」（wp-load.php を読み込んでいる、プラグイン PHP ファイルへの直接攻撃）に対処できるよう、対策をしています。その結果、WordPress のコンテキストとは全く関係なく単独で実行が出来てしまう「PD」が残ったというワケです。

私にとって驚きだったのは、一般公開ページ向けのサービスに WordPress とは独立な脆弱性が予想以上にあったという事実です。このリスクを下げるには、一般公開ページ向けにも何らかの対策を施すべきということが、定量的にも分かっちゃった次第です。

まとめ

正直、前バージョンの IP Geo Block については、思ったより防御率が悪くてガッカリ、というか「誇大広告」ぎみで、利用して下さっている方々にちょっと申し訳ない気持ちになりました。同時に「他のセキュリティ・プラグインはどうなんだろう？」という興味も湧いてきたので、そのうち「ゼロディ攻撃に対する防御力」という観点で比較検証してみたいと思います。

次のステップは「PD*」を遮断する事です。これにより遮断率を80%にする事ができます（が、副作用も増えます）。原理的なところはほぼ出来ているのですが、リライトの設定とか新たな脆弱性を作り込まないための検証とか、結構時間がかかると思います。

また IP Geo Block は「一般公開ページは誰でもアクセスできる様にしておきたい」という気持ちで作ってきました。今後はこの選択もユーザーに任せるべき？ と思っています。ただ「検索botは遮断しない」とかの「抜け穴」を作らなくちゃならないので、気が進まないのですが …

まぁ、今後もチマチマと改善は加えていくので、使ってくれれば励みになります 。

背景

拙作の「プラグイン作者必読！実例に学ぶ脆弱なWordPressプラグインの作り方、又はwp-adminを守る理由」では、脆弱性を持つプラグインの多くで「重要な処理」を行う際、「権限と nonce の検証」が欠落していることを明らかにしました。またその後も 同様の例 が後を絶ちません。

本来なら WordPress 自体が本質的にセキュアな仕組みで出来ていて、この手の脆弱性を作り込む余地がないのが理想でしょう。一方で、もしそんな作りになっていたら、現在私たちが手にしている自由は無かったのかもしれない、とも思います。

それならということで、補助的に「権限の検証」と「nonce の検証」を埋め込むことで、これらが欠落して起きる CSRF や SQLi といった攻撃や LFI などの脆弱性からサイトを守る機能を追加してみました。

理想的には、この機能はプラグインに依存せず「ゼロデイ攻撃の防御」が可能です。

が、現実にはそれほど素晴らしいものではなく、防御できるのは一部になります。まずはその辺りの事情から説明させて下さい。

プラグインで「何か重要なことをする」3つの方法

プラグインが 管理メニュー にその入口を追加すると、その URL は、登録した種類に応じて例えば次の様になっているハズです。

• wp-admin/admin.php?page=my-plugin
• wp-admin/tools.php?page=my-plugin
• wp-admin/option-general.php?page=my-plugin
• …

さて、それぞれのページで「ボタンを押した時に何か重要な処理をする」には、（コア系の処理を除けば）最もベーシックな方法として次の3つがあります。

「重要な処理」を実行する3つの方法を実装したサンプル

wp-admin/admin.php?action=do-my-action

Akismet でも使われている方法 で、ユニークなアクション名 do-my-action を軸に「重要な処理」を実行するコードを組み立てます。

まずは、フォームによるボタンの作成です。

[php]
<form method=”post” action=”<?php echo admin_url( ‘admin.php’ ); ?>”>
<?php wp_nonce_field( ‘do-my-action’, ‘_wpnonce’ ); ?>
<input type=”hidden” name=”action” value=”<?php echo ‘do-my-action’; ?>” />
<input type=”submit” value=”重要な処理” class=”button button-primary” />
</form>
[/php]

あるいは、a タグで飛ばすなら次の様にします。

[php]
<?php
$link = add_query_arg(
array(
‘action’ => ‘do-my-action’,
‘_wpnonce’ => wp_create_nonce( ‘do-my-action’ ),
),
admin_url( ‘admin.php’ )
);
?>
<a class=”button-secondary” href=”<?php echo esc_url( $link ); ?>”>重要な処理</a>
[/php]

またリクエストされたアクション do-my-action をフックするには、以下を定義しておかなければなりません。

[php]
add_action( ‘admin_action_’ . ‘do-my-action’, ‘my_action’ );
function my_action() {
// 権限と nonce の検証
if ( ! current_user_can( ‘manage_options’ ) ||
! check_admin_referer( ‘do-my-action’, ‘_wpnonce’ ) ) {
return; // ログイン画面に戻される
}

// ここで重要な処理
…

// 結果の表示：Ajax の場合
if ( defined( ‘DOING_AJAX’ ) && DOING_AJAX ) {
wp_send_json( $result );
}

// 結果の表示：ページを遷移する場合
else {
if ( isset( $_REQUEST[‘_wp_http_referer’] ) ) {
// wp_nonce_field() が埋め込んだリファラに遷移
$redirect_to = $_REQUEST[‘_wp_http_referer’];
}
else if ( isset( $_SERVER[‘HTTP_REFERER’] ) ) {
// ブラウザが出力したリファラに遷移
$redirect_to = $_SERVER[‘HTTP_REFERER’];
}
else {
// 予め設定したページに遷移
$redirect_to = admin_url( ‘admin.php?page=’ . ‘my-plugin’ );
}

wp_safe_redirect( $redirect_to );
exit;
}
}
[/php]

余計な経路は介さずに関数 my_action() を起動、「重要な処理」に集中し、「結果の表示」は他に任せるという 潔さ が、この方法のミソでしょう。

wp-admin/admin-ajax.php?action=do-my-action

詳細は 他の記事 に譲りますが、前述の my_action() に Ajax 用のフックを引っ掛けます。

[php]
add_action( ‘wp_ajax_’ . ‘do-my-action’, ‘my_action’ ); // ログインユーザー用
add_action( ‘wp_ajax_nopriv_’ . ‘do-my-action’, ‘my_action’ ); // 非ログインユーザー用
[/php]

おっと、ここでは「重要な処理」に「非ログインユーザー用（no privilege）」は必要ありませんネ。

wp-admin/admin-post.php?action=do-my-action

admin-post.php は、純粋な POST リクエストに対する入口です。Ajax と同様に「ログインユーザー」と「非ログインユーザー」を振り分ける事が出来ます。

[php]
add_action( ‘admin_post_’ . ‘do-my-action’, ‘my_action’ );
add_action( ‘admin_post_nopriv_’ . ‘do-my-action’, ‘my_action’ );
[/php]

ゼロデイ攻撃を防御する仕組みと限界

脆弱なプラグインに代わって「権限と nonce の検証」を行うには、遷移前のページに nonce を埋め込み、「重要な処理」の前に検証を実行しなければなりません。

このため前述の3つの基本形に対し、リンク、フォーム、jQuery による Ajax リクエストの各々に nonce を埋め込み、リクエストを受けたところで検証をする仕組み入れています。

一方、プラグインが「重要な処理」のリクエストを受け付ける方法は、前述の3つ以外にも無数に存在します。例えば admin.php?page=my-plugin&job=do-my-job で、表示の前に処理を振り分けても OK ですし、（酷いのになると、プラグインはイベント駆動で開発されるべきという お約束 を無視して）WordPress を経由しないケースも見受けられます。

同様に、PHP が他の PHP に直接リクエストする場合（サーバーサイド）や、ブラウザから flash や JavaScript のロケーション・オブジェクトを介してリクエストする場合（クライアントサイド）などがあり得ます。このような場合は nonce の埋め込みが出来ず、逆にこの仕組みが邪魔になってしまいます。

そこで、「この仕組みをバイパスする処理」について、および「この仕組みでも防げない脆弱性」について、以下に説明します。

コア系で使われるリクエスト

メディア・ライブラリでは、Plupload が flash や silverlight 経由でアップロードを行なうため、これらのアクション名を特定し、バイパスしています。

他のflash系を使うプラグインなど

jQuery 以外で Ajax を行うプラグイン向けに、バイパスすべきアクションを追加するフィルター・フックを用意しました。

[php]
add_filter( ‘ip-geo-block-admin-actions’, ‘my_admin_actions’ );
function my_admin_actions( $admin_actions ) {
$actions = array(
‘do-some-plugin-action’, // バイパスするアクション名
);
return $admin_actions + $actions;
}
[/php]

権限昇格（PE）は防げない

WordPress ではバックエンドでの処理に際し、ユーザーの種類と権限 を細かく制限する事が出来ますが、権限の十分条件はプラグインやテーマに依存し、PHP ソースでも解析しない限り外側からは特定する事が出来ません。

そこで本プラグインでは、「ログイン」を最低限の権限としています。

よって、異なる権限間で発生し得る nonce の漏洩や権限の回避といった、「権限昇格」の脆弱性に対する攻撃は防ぐ事が出来ません。

効果の検証

最近発表された脆弱性の事例から、防御が成功する場合と失敗する場合を1例ずつ紹介したいと思います。

防御が成功する場合

2015年1月、All In One WP Security & Firewall の CSRF 脆弱性が CVE に上がりました（JVN へは2015年3月）。

「悪意あるリンクを踏むと、特定の 404 イベント・ログが削除される」という、深刻度の低い脆弱性です 。

残念ながら（？）公式の SVN リポジトリ からは既に該当のバージョンは削除されていますので、ミラーサイトの Github からクローンを落としての再現です。

「悪意あるリンク」は、図の通りです。

404 Event Logs

これを WordPress 以外のページに貼付けてクリックすると、All in one Security の管理画面に飛んで、ログが削除されます。

All In One WP SecurityのCSRF

一方、IP Geo Block の「ゼロデイ攻撃を防御」を有効にすれば、以下の様にブロックすることが出来ます。

ブロックされたリクエスト

防御が失敗する場合

2015年3月11日には、WordPress SEO by Yoast の 1.7.3.3 以下で任意の SQL が実行できる という、深刻度の高い脆弱性が公開されました。

この脆弱性の根本原因は nonce の検証漏れによる CSRF なので、本プラグインにとって最も「オイシイ」ケースですが、残念ながら防御対象であるリクエストの「3つの方法」に当てはまらず、防御できません。

何処まで基本形を拡張できるかは、今後の課題ですネ。

IP Geo Block の設定

「設定」画面の「検証の設定」で、「管理領域」および「管理領域のajax/post」に「ゼロデイ攻撃の防御」を選んで下さい。

IP Geo Blockの設定

オマケの機能

折角組み込んだ nonce が第三者に漏れては元も子もありません。これが起きるケースの1つに、「URL に埋め込まれた nonce がリファラを介して外部に漏れる」が想定できます。

そこでログイン中に外部リンクを踏んだ場合、ブラウザがリファラをリセットしてから飛ぶ仕掛け「リファラ・サイレンサー」を入れてあります。ネットスケープ時代からブラウザが独自に取り入れている機能なため、大抵のブラウザで働くと思いますョ 。

バグ出し協力のお願い

さてさて、今回追加した機能がウマく働くかどうかは、ひとえに「nonce が埋め込めるかどうか」にかかっています。が、ウマくいかない場合も多々あるかと思います。

そこで「試してもイイよ」というパイオニア精神が旺盛な方、トラブル発見の際は、ぜひ サポート・フォーラム とか、コメント欄とかに書き込みをお願いします m_(..)_m

昨今、自動車業界が「自動運転」で騒がしい事はご存知だと思います。ブームの発端は Google X のプロジェクト なワケですが、中でも「セキュリティ」が盛り上がりを見せています。

つい先日も BMW がセキュリティ上の欠陥を見つけた とか、DARPAのハッカーが、衛星通信サービスの脆弱性をついて GM のコンピュータ・ソフトウェアを書き換え、ホーンを勝手に鳴らすのはご愛嬌としても、ブレーキを利かなく出来る という問題が騒がれました。期せずして、自動車業界にはセキュリティの専門家がいないということを露呈しちゃったワケです。

背景

今を遡る事、??年前、マルチメディア・パソコンなるものがもてはやされた後、インターネットを使ったビジネスが流行ると言われていました。

しかし現実的には、なかなかウマいビジネス・モデルが出てきませんでした。当時、「ナゼ？」と考えていて思い当たったのが、インターネット上で安心してお金のやり取りをするには、盗まれないようにする仕組みが必要だと言う事です。

時は流れて現在、IoT というキーワードがもてはやされていますが、やはり自動運転時代のビジネスが花開くためには、「セキュリティだ！」という、漠然とした思いに駆られ、去年からセキュリティの勉強を始めていたワケです。

何を隠そう、その具体的成果が 前回のエントリー です。

自動車会社によるセキュリティ・エンジニアの争奪合戦が始まるゾ

今はまだ、セキュリティを要件とした自動車業界からの人材募集 は目立っていませんが、そのうちセキュリティ・エンジニアの大争奪合戦が始まるんじゃないかというのが、今の私の見解です。

大手自動車メーカーの給料って、40代で1000万ぐらいじゃないかと思っているのですが（根拠なし）、これから年収1000万から2000万ぐらい（これも根拠なし）を目指したいヒトは、自動車業界をターゲットにしたセキュリティの専門家を目指すのがイイんじゃないかと思う今日この頃です。

妄想系が過ぎますかネ？

冒頭のグラフ は最新の分析結果で、この事実を裏付けています。プラグイン開発の チュートリアル や 手引き には、脆弱性を作り込まないためのポイントが上手にまとめられているのに、なぜ無くならないのでしょうか？

「ヒトが作るものだから、バグがあって当然」と言ってしまえばそれまでですが、 Sucuri のブログ を読み漁っていると、こと脆弱性に関する限り、 WordPress に特有の「思い込み」や「見過ごし」といった、ヒトの心理的・認知的な盲点が原因の多くを占めているんじゃないかと思えてきます。

だから単に PHP のセキュリティ How To ではなく、私が公開している唯一のプラグイン の機能設計と脆弱性を作り込まない実装のために勉強したたこと − 実際に攻撃を試し脆弱性を追跡して見えてきたこと − を中心にまとめてみたいと思います。ただし具体的な攻撃方法は、元記事以上に詳しくは触れません、あしからず 。

SQL インジェクション

端的には、 OWASP の SQL インジェクション チートシート に示されている「防御の3原則＋2」が基本なんだと思います。

OWASP の SQL インジェクション チートシート

優先すべき防御策：

• オプション #1： プリペアド・ステートメント を使う（パラメータ化されたクエリ）
• オプション #2： ストアード・プロシージャ―を使う
• オプション #3： ユーザーからの入力は全てエスケープする

追加の防御策：

• 追加で強化すべき： 最小限の権限で実行する
• 追加で検討すべき： 入力はホワイトリスト方式で検証する

これらの防御原則に対し WordPress では、 $wpdb->prepare() や esc_sql()、あるいは 役割りと権限 を検証する current_user_can() などを準備することで、開発物をセキュアにするプログラミング環境を提供しています。

故に、これらの原則に従って対応する関数を正しく使っていれば、 SQLi は起きないハズなんですが…

次の例は「思い込み」に起因すると思われる SQLi の例です。

Custom Contact Forms に見る「思い込み」の盲点

次のコードは、① 設定を SQL ダンプしダウンロードする、② バックアップしておいた SQL をインポートする、という管理者向け機能のコードの一部です。

[php]
if (!is_admin()) {
…
$custom_contact_front = new CustomContactFormsFront();
} else {
…
$custom_contact_admin = new CustomContactFormsAdmin();
…
add_action(‘init’, ‘adminInit’);
}

/* 設定のエクスポート、インポート（管理者向け）*/
function adminInit() {
$this->downloadExportFile();
$this->downloadCSVExportFile();
$this->runImport();
}
[/php]

上記コードには、最低でも5つの問題点が考えられます。

1. 「管理者」かどうかの検証を is_admin() に頼っている
2. 予め想定された経路が前提で、別経路でアクセスされた場合を想定していない
3. 生の SQL 文を出力する仕様のため、DB のプレフィックスが暴露される
4. SQL のエクスポート、インポートに際し、権限を検証、限定していない
5. インポートでは、任意の SQL 文が実行できる

結果、誰でも DB の書き換えが可能という深刻な脆弱性が生じてしまいました。

ダウンロードされた生のSQL文

1. について言えば、ここでの is_admin() の使い方は必ずしも間違いじゃないと思います。ただし 2. においては、「正規にログインした管理者がダッシュボードからアクセスする」という「予め想定された経路」以外にも、 admin-ajax.php や admin-post.php を直接叩くという経路があり得ます。これらには admin の名が付いてはいますが、管理者以外でも機能する仕様となっており、おまけに is_admin() を true にします。

よって、ある条件で admin-ajax.php にアクセスすると SQL ダンプが始まってしまうという、「想定外の経路」が存在する構造になっていたのです。

Sucuri が作者に連絡するも応答がなかったため、WordPress のセキュリティ・チームが急遽、対策版をリリースしました。その内容は、単に init へのフックを削除し、 adminInit() の実行を阻止するというものでした。

仮に SQLi の防御原則に則った実装をするなら、以下の様にすべきだったでしょう。

• nonce（後述）を検証して特定ページからの要求である事を確認し、
• current_user_can('manage_options') で権限を検証し、
• データベースへの入出力はすべてパラメータ化、
• さらに入出力時には、値の検証と無害化をした上で、
• 適切に組み立てられエスケープされた安全な SQL 文を実行する。

この原則が見逃されてしまった要因には、 is_admin() への誤った「思い込み」が盲点となった事が挙げられるのではないでしょうか。フォーラムでのディスカッション が、そのことを如実に物語っているように思います。

全く同じ「思い込み」の元凶に admin_init フックがあり、 admin-ajax.php などにアクセスするとトリガーがかかるようになっています。テーマ Platform の 任意の PHP コードが注入できてしまう脆弱性 や、プラグイン MailPoet の 任意のファイルがアップロードできてしまう脆弱性 が同種の例として報告されちゃってます。

「admin の名が付いたファイルやフックには気を付けろ！」ってことですネ。

2015年2月18日 追記

admin_init の公式ドキュメント には、管理画面へのアクセスを管理者に限定するコードが載っていますが、一般ユーザーによる公開ページの Ajax も許容するコードになっているので、コピペする時は注意しましょう 。

XSS

XSS の詳しい話は 専門家 に譲りますが、ほとんどの場合、外からやって来るデータ（DB から読み出したものを含む）の検証漏れか、出力前のエスケープ漏れでしょう（「安全なウェブサイトの作り方」によると、前者は「保険的対策」、後者は「根本的対策」とされています）。

まずは、「これじゃあ漏れも仕方ない」的な例を紹介します。

Blubrry PowerPress に見る「見過ごし」の例

下の表を見れば分かりますが、 Blubrry PowerPress では、最初から XSS が未対策だったワケじゃありません。

対策前後のコードの一例を以下に示しますが… 何と言うか… 一言で表せば、追跡するのがとても厄介なコードです（すいません、想像してください ）。そして至る所にパッチが当てられ、その対策の慌てっぷりがヒシヒシと伝わってきます 。

[php]
/* before */
<input type="hidden" … value="<?php echo empty($_POST[‘tab’]) ? 0 : $_POST[‘tab’]; ?>" />
/* after */
<input type="hidden" … value="<?php echo empty($_POST[‘tab’]) ? 0 : intval($_POST[‘tab’]) ); ?>" />

/* before */
powerpress_page_message_add_error( …, $_POST[‘feed_slug’]) );
/* after */
powerpress_page_message_add_error( …, esc_html($_POST[‘feed_slug’]) ) );

/* before */
echo ‘<rawvoice:metamark type="’. $MetaMark[‘type’] .’"’;
/* after */
echo ‘<rawvoice:metamark type="’. esc_attr($MetaMark[‘type’]) .’"’;

/* before */
‘<em>’. htmlspecialchars($post_title) .'</em>’,
‘<em>’. $feed_slug .'</em>’ );
/* after */
‘<em>’. htmlspecialchars($post_title) .'</em>’,
‘<em>’. htmlspecialchars($feed_slug) .'</em>’ );
[/php]

こういったヤッツケ仕事的パッチワークの問題点は、「対策漏れ」がないかの検証が難しいこと、そして htmlspecialchars() と esc_html() の混在など、統一性のない対策方針が果たして正しいのか判断がつかない事ではないでしょうか？

私には、混在（要は、省略されたパラメータの扱い）が直ちに問題となる例題は示せませんし、実際、大丈夫なのかもしれません。しかし WordPress という系の中では、コアチームが熟成させてきた関数群を使うべきだと思っています（例えば esc_html() の内部では 厳密性の高い htmlspecialchars() の使い方 がされている）。

追記：徳丸さんの 『例えば、PHPを避ける』以降PHPはどれだけ安全になったか | 徳丸浩の日記 に の第３パラメータについて詳しく解説されていました。

入力の検証と出力のエスケープ、およびモデルとビューの分離

「見過ごし」を防ぐ上で大事なことは、「モデル」における「入力の検証」と、「ビュー」における「出力のエスケープ」と言った具合に、見通しのよい設計と実装をする事だと思います（注：ここでは MVC の話をしているつもりはありません）

ちょっと厳しい言い方ですが、先のコードはこれら2つが混沌としているため、「対策漏れ」が起きて当然と言われても仕方ありません。

Codex の Validating Sanitizing and Escaping User Data と Data Validation（日本語版）には、XSS や SQLi、 DT など、様々な攻撃を阻止するための入出力に関する検証と無害化の関数群がリストアップされています。

ただし一部、日本で語られている考え方やネーミングと、多少の違いと混乱があるので要注意です。例えば、不要なタグやコードを削除する「入力の検証（クリーニング）」の関数群が sanitize_*() というネーミングになっていたり、「出力のサニタイジング」にエスケープ処理を施す関数群 esc_*() と sanitize_text_field() が混在していたり、といった具合です。

いずれにしても、見通しの良い設計と共に、これらの関数群をコードの文脈に合わせて適切に使うことが肝要でしょう。

最後に蛇足ですが、IPA セキュア・プログラミング講座 にある「スクリプトが動作する箇所」の図と WordPress の esc_*() 関数との対応を取ってみました。

図を描いてみて分かったのですが、 expression 攻撃を阻止する関数は無さそうなので、外から入力されたデータを style 属性に注入するのは避けた方が良さそうですネ。

スクリプトが動作する箇所と対応するWordPress関数

HD FLV Player に見る「見過ごし」の例

FLASH PLAYER PLUGIN の古いバージョンと PHP バージョン 5.3.4 以前との組み合わせには、任意のファイルがダウンロードできるという脆弱性が存在します。

Sucuri の報告 には、以下の様な download.php のコードが掲載されています。

[php]
$finename = $_GET[‘f’];
header(‘Content-disposition: attachment; filename=’ . basename($filename));
readfile($filename);
[/php]

実際にはこれほど単純ではなく、 $finename に対して、絶対パスの追加と拡張子の検証が行われています。しかし、ディレクトリ・トラバーサルの検証（validate_file() で可能です）や NULL バイト攻撃 の検証が見過ごされたため、一撃で破られるシングル・フェイルとなってしまいました。

また download.php が WordPress とは無関係に単独で実行出来るようになっていたという点も問題でしょう。wp-load.php を読み込んだり、 admin-ajax.php や admin-post.php 経由で nonce や権限を検証するなど、 WordPress の仕組みを使うべきだったのではないか、と思います。

先の htmlspecialchars() にも言える事ですが、僅かな処理時間の増加をケチったんだとすると、その結果、脆弱性を作り込んでしまっては、本末転倒と言えるのではないでしょうか？

2015年5月23日 追記

PHP 5.3.4 以前には、ファイル・システム系の関数が NULL バイトの攻撃に弱いという問題 がありましたが、5.3.4 で チェックが強化 されました。

手元の環境で調べてみた結果は以下の通りです。

当然このまま include( $file ) とかすると、パスワードがバッと表示されちゃいます。WordPress は PHP 5.2.4（推奨は 5.4 以上）から使える事になっているので、拡張子を調べるだけじゃダメで、 str_replace( "¥0", "", $file ) などによる NULL バイトの無効化が必須というワケです。

この辺りは PHP と Web アプリケーションのセキュリティについてのメモ がとても参考になるので、一読を激しく推奨します。

権限昇格（PE）

WordPress における nonce を一言で表せば、「今、このページにアクセスしているユーザーだけが知りえる秘密の情報」です。詳しくは拙作の WordPressプラグインのコーディングでありがちな10の間違いと設計時に考慮すべきこと や 初歩からわかるWordPressのnonceでAjaxをセキュアに実装する方法 を参照してください。

でもその nonce だって漏れるんです。漏れると、単なるユーザーが管理者の権限にまで昇格しちゃうんです。次は、そんな脆弱性の紹介です。

UpdraftPlus に見る「思い込み」の盲点

登録ユーザーのダッシュボード上で wp-admin/?action=hogehoge にアクセスすると hogehoge_handler() にフックされるようにしたとします。

[php]
add_action( ‘admin_action_hogehoge’, ‘hogehoge_handler’ );
[/php]

このハンドラは wp-content/plugin/hogehoge/admin.php で定義され、「何か」する目的で、ブラウザに次の様な出力をするものとします。

[php]
function hogehoge_handler() {
…
?>
…
<input type=”hidden” name=”_wpnonce” value=”<?php echo wp_create_nonce(‘hogehoge-secret-nonce’);?>”>
…
<?php
}
[/php]

この登録ユーザー向け秘密情報のタネである 'hogehoge-secret-nonce' が、管理者向けのタネと共通で使われていたりすると、ちょっと心配な事になります。いわゆる「秘密情報の漏洩」ですネ。

さらに別の管理者向けハンドラでは、 check_admin_referer('hogehoge-secret-nonce') による nonce の検証を行っただけで管理者権限の検証が漏れたりすると、いわゆる「権限昇格」が起きてしまうのです。

UpdraftPlus が正にこのパターンにハマってしまいました。また同様の脆弱性は、あの有名な WPtouch でも 報告されています。

これらも一種の「思い込み」と言えるでしょう。

CSRF

CSRF が起きる原因は単純です。

例えば管理画面で「変更を保存」のボタンを押すと、内部で保存処理をして新しい画面に遷移しますが、遷移前の画面に nonce が埋め込まれていなかったり、保存処理の前に nonce がチェックされていなかったりすると、即 CSRF となります。

この場合、保存処理の所で管理者の権限を検証するだけでは CSRF は防げません。管理者が自らのクッキーを持ったまま悪意のあるリンクを踏んで起きる脆弱性だからです。

「管理者かどうかチェックしているから大丈夫」という「思い込み」があったのでしょうか、 Sucuri のデータベース からは、有名どころの W3 Total Cache を始め、この脆弱性を持ったプラグインが数多く検索されます。

オプションの保存処理であれば、 nonce の生成・検証と管理者権限の検証の両方を確実に行ってくれる Settings API を積極的に使うのが吉でしょう。

2018年2月18日 追記

WordPress での CSRF 対策 – nonce ってナンスか？ がとても分かり易かったので、一読推奨です 。

ファイル・インクルージョン（FI）

FI は、ファイルシステム系の関数に検証が十分でない入力を与える事で起きる脆弱性です。2014年9月には、 file_get_contents() を介して 任意のファイルがダウンロードできてしまう という Slider Revolution の LFI が報告されました。

Slider Revolution に見る「思い込み」の盲点

管理者向けのある機能に対し、admin-ajax.php を経由した次の様な攻撃で、任意のファイルが漏洩します（本サイトにも未だに時々やってきます）。

[html]
http://victim.com/wp-admin/admin-ajax.php?action=revslider_show_image&img=../wp-config.php
[/html]

Slider Revolutionの脆弱性により漏洩したwp-config.php

Slider Revolution では、管理者用クラスの中で admin-ajax.php に対するアクション・ハンドラが登録されます。しかし同ハンドラでは、以下の様な検証が全く行われないまま file_get_content() を呼び出していました。

• お約束の nonce を検証していない
• 実行しようとしているユーザーの権限を検証、制限していない
• ディレクトリー・トラバーサルの検証やパスの限定など、入力の検証と無害化をしていない

問題の構造は冒頭の SQLi と同じですネ。 admin-ajax.php のネーミングに由来する「管理者向け」という「思い込み」が原因です *。想定が「管理者」だとしても、何らかの脆弱性で権限昇格だってあり得るんだから、他の検証を省略できるってことにはならないのです！

* 断定根拠： 有料販売もしているプラグインですョ、上記の様な基本的な検証が全く実装されていないなんて、あり得ないじゃないですか！

まとめ

今回分析した案件の多くが、admin の名前が付く関数やアクションフックに対する「思い込み」によるものと推察（一部は断定）しました。また数の多い XSS では、「見過ごし」が起き難い設計が重要との認識を新たにしました。

心構えとしては、常に攻撃側／非攻撃側という2つの側面から、コードの1行1行に「盲点がないか」を問いかけるってことでしょうか。

とどのつまり、性善説じゃダメで、次のような性悪説を元に開発に臨むというのが個人的な結論です。

• 入力は汚染されている
• DB は改ざんされている
• 秘密の情報は漏洩する
• 管理者権限は回避、奪取される
• 攻撃は想定外の経路から来る
• 実際に今、ページにアクセスしているワケではない

攻撃者はさらにプラットフォーム（OS やら PHP、時には WordPress コア）自体に内在する脆弱性とを組み合わせてきます。

これらを全て防ぐのって大変なことですが、こと WordPress という エコシステム に関して言えば、防御に必要な仕組みはコア開発の方々が揃えてくれているので、後は「使いこなし」ってことで、この記事を〆たいと思います。

「ランダムで長いパスワード」をアカウント毎に頻繁に変えるのは面倒なワケで、長い間変えずに使い続けと、漏洩時のリスクが極めて高くなるってことだと思います。

おっと、何も パスワードの定期変更は必要か の議論へ乱入しようというワケじゃありません。

IPアドレスのジオロケーション情報を元に海外からの投稿を弾くスパム対策プラグイン IP Geo Block に、wp-login.php や wp-admin/admin.php、xmlrpc.php へのアクセスを遮断するセキュリティ機能、さらにはログを記録する機能を追加したので、その告知が本記事の主題です 。

IP Geo Blockの制作コンセプト

WordPress がセキュリティ的に最も強固なのは、「テーマはデフォルト、プラグインは使用せず」という素の状態である

何か目新しいことを言っているつもりはありません。サーバー設定、パーミション設定、強いパスワードなど、基本的な条件を整えた後 は、プラグインまみれの WordPress より、クリーン・インストール直後の WordPress の方が、脆弱性を抱える可能性が低いってことです。

ハッカーやクラッカーに、「なぜハッキングやクラッキングをするのか」と問えば、「そこに脆弱性があるから」と答えるかは分かりませんが（それぞれ目的が違いますからネ）、テーマを弄り、有象無象のプラグインを使い出す結果、脆弱性を抱え込むことになります。

そこでセキュリティ・プラグインの出番となるワケですが、単機能で物足りなかったり、iThemes Security や BulletProof Security、Wordfence Security などの フルスペック なプラグインでは、多機能過ぎて設定が難しかったり重たかったりと、私的には「単機能以上、重量級未満」の ちょうどいいサイズ のプラグインがあってもイイんじゃないかと思ってました。

速度比較については後述しますが、例えば Wordfence Security では明らかにページの応答速度が悪化します（しかも128Mのメモリを要求する！）。

ということで、今回も自分が ちょうどいい と思う機能をだけを実装しました:D。

出来る限りシンプルかつ軽量に

ウチの様な共有サーバーでも問題なく使えるよう、従来の遮断機能 に加え、WordPress が標準で備えている幾つかの典型的な「入口」を遮断対象に追加しました。実際、コア部分は、コメントを含め60行弱の PHP を追加した程度です。

またシンプルな故、例えばIPアドレスの国別遮断機能がプレミアム版のみで提供される Wordfence Security と組み合わせるのも、有効だと思います。

ログ機能は手厚く

私が借りている LaCoocan では、月別の統計的アクセスレポートはあるものの、個別のアクセスログを見ることができません。そのため、いつ何処にどんな攻撃を受けたかを特定する手がかりが少なく、攻撃の事前対策や事後処理が困難です。

有名なプラグインに 狂骨 がありますが、ログする対象を xmlrpc.php や admin-ajax.php にも拡大した感じと思ってもらえれば良いと思います。

オプションは極力少なく、拡張性は高く

誰かが使うかもしれない機能をオプションに組み込んで無闇にコードを肥大化させるより、各所にアクション・フックを設けて拡張性を残すことを選びました。またユースケース別サンプルコードを sample.php に載せ、同梱しています。

機能の概要

ログ機能

より詳しい情報が得られるよう、$_POST データのキーを指定すると、その中身を展開して記録する機能を持たせました。

$_POSTデータのキーを展開して記録

ログは、カテゴリ毎に DB 上のリング・バッファ（最大100個で固定）に記録されます。また攻撃の事後に解析できるよう、選択的にバックアップ・ファイルを残すためのアクション・フックも設けました。

[php]
/**
* パスワードが破られたか否かを後で確認できるようバックアップする
*
* @param string $hook ‘comment’, ‘xmlrpc’, ‘login’, ‘admin’ のいずれか
* @return string $path 非公開領域への絶対パス、または null（バックアップなし）
*/
function my_backup_dir( $hook ) {
if ( ‘login’ === $hook )
return ‘/absolute/path/to/’;
else
return null;
}
add_filter( ‘ip-geo-block-backup-dir’, ‘my_backup_dir’ );
[/php]

バックアップは CSV フォーマットのテキストファイルとして月別に記録されます。public_html などの公開領域以外で書き込み可能な場所を指定して下さい。

遮断機能

本プラグインでは、WordPress で最も基本的かつ重要な以下の4カテゴリ、7つの投稿・攻撃パターンを遮断対象としています。

wp-comments-post.php

2014年11月21日、WordPress コアに存在した XSS、CSRF、SSRF 脆弱性を修正する 4.0.1 セキュリティ・アップデート版がリリース されました。

この中には、ダッシュボード上で管理者が承認待ちのコメントを確認すると、管理者権限を攻撃者が取得できてしまうという、格納型（蓄積型あるいは持続的）XSS の修正が含まれています（出典1、出典2）。

コメントの投稿とトラックバックはここで受けますが、余計なものは内部に取り込まないのが一番ということでしょう。

xmlrpc.php

実はコレがとってもヤバいんです。その名の通り XML による 遠隔命令を実行する手続き の入口なんですが、単にピンバック・スパムの温床になるだけじゃなく、ピンバックを悪用した DDoS 攻撃の踏み台 *1 に使われたり、wp-login.php と同様にクラッキングの対象になったり、また古くは ポートスキャン が出来たりなど、いっそ閉じておくのが当然のようなシロモノです。

*1： WordPress 3.9.2 でピンバックによる DDoS 攻撃関連の セキュリティ・アップデート が、また Akismet でも 関連するアップデート（日本語記事）がリリースされています。

一方で私も使ってますが、WordPress.org 公式のモバイルアプリ や Jetpack の一部機能には XML-RPC が必要で、公式サイトの FAQ では、XML-RPC が禁止されているサーバー用回避プラグイン が紹介されているぐらいです。

本プラグインでは XML-RPC の利便性を残すため、海外からのアクセスを弾くのは勿論、クラッキングと見なせるアクセスに対しては、wp-login.php と同様、国内外を問わず認証の試行回数を制限する機能を実装しました。

wp-login.php

パスワードのクラッキングは国内から受ける場合もあり得ます。そこで「国内外を問わず、認証失敗が一定回数（現状は5回で固定）を超えた場合、そのIPアドレスからの認証要求を一時的に禁止」します（禁止期間はIPアドレスのキャッシュ保持期間と連動で、デフォルトは60分です）。

同様の機能は Login LockDown が有名です。こちらはIPアドレスだけではなく、ユーザー・アカウント単位でも認証の試行回数が管理されていて、brute-force と reverse-brute-force の両攻撃を効果的に防げるよう工夫されています。

試行回数の管理方法は、IPアドレス単位／アカウント単位ともに一長一短ありますが、「串の数はそう多くはない」ので、IPアドレス単位で十分だと判断しました。

wp-admin/[admin.php | admin-ajax.php]

このカテゴリは、直接的攻撃に対するというより、サイトに何らかの脆弱性が存在した場合の間接的防御という位置づけです。例えば、XSS 脆弱性が原因のセッション・ハイジャックや、権限のチェックが十分でない脆弱なプラグインを経由したファイルの不正アップロードや盗用といった攻撃が想定できるでしょう。

最近の例では、Paid Memberships Pro の脆弱性 による任意ファイルの漏洩や、Slider Revolution の脆弱性 による wp-config.php のダウンロードとバックドアのアップロードがこれに当たります。

RevSliderの脆弱性を突いた攻撃

Paid Memberships Proの脆弱性を突いた攻撃

これらを防ぐには .htaccess によるIPアドレスの制限が最も効果的ですが、本プラグインならIPアドレスに依らず、次の拡張用コードで防ぐことが出来ます。

[php]
/**
* admin-ajax.php 経由の不正なアクセスを遮断する
*
* @global array $_GET, $_POST リクエストされた値
* @param array $validate
* @return array $validate[‘result’] 不正な場合に ‘blocked’（遮断）を設定
*/
function my_protectives( $validate ) {
if ( defined( ‘DOING_AJAX’ ) && DOING_AJAX ) {
// 保護するファイル名のリスト
$protectives = array(
‘wp-config.php’,
‘.htaccess’,
‘passwd’,
);

$req = array();
$req += array_values( $_GET ) + array_values( $_POST );
$req = strtolower( urldecode( implode( ‘ ‘, $req ) ) );

foreach ( $protectives as $item ) {
// リクエスト中にファイル名を発見したら遮断
if ( strpos( $req, $item ) !== FALSE ) {
$validate[‘result’] = ‘blocked’;
break;
}
}
}

return $validate; // 引き続き国コードを検証するため ‘passed’ は設定しない
}
add_filter( ‘ip-geo-block-admin’, ‘my_protectives’ );
[/php]

余談ですが、Codex の wp-config.php を安全にする にある .htaccess の設定は、HTTP でアクセス した時に 403 Permission Denied を返すか、中身が空の 200 OK を返すか（何も出力しない PHP が実行されるだけ）の違いにしかならず、先の様に内部に脆弱性がある場合の漏洩は防げませんので、念のため 。

[text]
# 内部からの漏洩は防げない
<files wp-config.php>
order allow,deny
deny from all
</files>
[/text]

また、Wordfence Security には Slider Revolution 専用 WAF が入っていて（先の拡張用コードの $protectives に revslider_show_image が指定されている感じ）、脆弱性を突いたアクセスをすると次の様な画面が表示されます。

Slider Revolution の脆弱性を突いた攻撃を遮断する Wordfence Security の WAF

一方、iThemes Security（4.6.2）は、設定をアレコレ弄ってみましたが遮断できず、また BulletProof Security（.51.4）は、.htaccess によってローカルから Admin 領域へのアクセスが禁止されるため、確認できませんでした 。

出来ない事

セキュリティ対策では、「何が出来るか」と共に「何が出来ないか」の想定が大事です。当然ですが、本プラグインは、フルスペック・プラグインが謳い文句にしている以下の様な機能は持っていません。

1. 認証の強化
   • パスワード強度のチェック、認証プロセスの強化（二段階認証など）
2. 不要なサービスの削除
   • admin変更、アカウント名隠蔽 *2、XML-RPC 無効化などの機能
3. 脆弱性や脅威のスキャン、特定攻撃パターンの検出、遮断
   • XSS 脆弱性 *3、CSRF 脆弱性、ファイルや DB の改ざん、ファイルの不正なアップロード（マルウェア、バックドア、ドットファイルなど）やダウンロード、SQL インジェクション等々を検出する機能、あるいは特定の攻撃パターンを遮断する WAF 機能
4. 攻撃を検知した時の警告
   • 管理者メール送信、管理画面への警告表示、アカウント・ロックなど
5. 攻撃に対する事前準備や事後処理
   • DB のバックアップやリストア、被害拡大を防ぐサイト閉鎖機能など

全て対応しようとすれば遅くなるのも仕方がない気がしますが、特にプラグインを数多く抱えていると（数じゃなく質の問題ですけどネ）、本プラグインのように「典型的な入口」を抑えるだけではダメで、3. 以降を重視せざるを得ないでしょう。

*2： 個人的には、隠すセキュリティ対策 はあまり重視していません。

*3： スキャンや WAF により、間接的に検出するんじゃないかと思いますが…。

応答時間の計測

どれだけ遅くなるかを見るために、ローカルに仕立てた WordPress で、ブルートフォース攻撃を想定したログイン・パスワードのクラックに対する処理能力を計測しました。

計測方法

WordPress brute-force attack detection plugins comparison を参考に、ApacheBench コマンド を使って計測しています。

[text]
# ab -t 60 -c 5 -p ‘postdata.txt’ -T ‘application/x-www-form-urlencoded’ -C ‘wordpress_test_cookie=WP+Cookie+check’ http://localhost/wordpress/wp-login.php
[/text]

postdata.txt には、ログイン・フォームから送信される内容を入れておきます。

[text]
log=admin&pwd=bruteforce&wp-submit=Log+In&redirect_to=http%3A%2F%2Flocalhost%2Fwordpress%2Fwp-admin%2F&testcookie=1
[/text]

計測結果

① セキュリティ・プラグインを有効にしていない場合、② IP Geo Block だけを有効にした場合、③（重量級プラグインの代表として）Wordfence Security だけを有効にした場合の3つについて計測しました。各プラグインの設定は、それぞれデフォルトのままです。

計測の環境と結果は以下の通りです。

• プラットフォーム：MacBook Pro Retina, 13-inch, Late 2013
• プロセッサ：2.8 GHz Intel Core i7
• メモリ：16 GB 1600 MHz DDR3
• OS：OS X 10.9.5
• サーバー：Apache/2.2.22
• PHP：5.4.30
• WordPress：4.1-ja

「プラグインなし」より「IP Geo Block」の方が若干向上していますが、これは WordPress の一連の処理のうち、比較的早い段階で弾いているからです。

一方 Wordfence Security では2倍ほどのコストがかかっています。キャッシュ・プラグインの併用など、何らかの高速化手段が必要でしょう（Wordfence Security は、それ自身がキャッシュ機能を持っています）。

今後は…

特に構想はありませんが、サンプルコードの一部を本体に取り込んでもいいかな？と思っています。

「単機能以上、重量級未満」にどれだけのニーズがあるか分かりませんが、ニッチはニッチらしく行きたいと思いますし、要望、バグ報告など大歓迎です 。

最初はそのプログラミングに関する独特のお約束事項にイラッとしましたが、キモであろう DI を「疎な関係のクラスを（実行時に）結びつけるのに必要な仕組み」と割り切り、DI – 猿でも分かる! Dependency Injection: 依存性の注入 で引用されている ITpro 記事 の クラス図 をコードから想像できるようになったところで、それなりに面白くなってきました。

何より「jQuery が要らなくなる！」のがとっても快感なんです （つらい時もあるけど…）。

さて今回は、jQuery まみれのページを AngularJS で書き換えた時に気付いた Ajax の動作 − 非同期通信の戻り値をいつどこで DOM に反映するか − に関する話題を書いてみます。

jQueryの場合

検索のクエリを渡すと Github のリポジトリを返す関数を例にとってみます。

[javascript]
function get_repos(queries) {
var url = ‘…’;
queries = encodeURIComponent(queries.replace(/\s+/g, ‘ ‘));

$.ajax({
url : url + queries,
type: ‘GET’
})

.done(function (data, textStatus, jqXHR) {
// 読み込み結果の処理
;
})

.fail(function (jqXHR, textStatus, errorThrown) {
// エラー処理
;
});
}
[/javascript]

私がよくやりがちなのが、「読み込み結果の処理」の所で DOM をゴニョゴニョとやる事です。当然「Github リポジトリ検索」をビューから切り離せなくなり、サービスとして独立させる事が出来ません。

ではどうするか？ async:false とは何か。或いは、非同期処理を諦めるのはまだ早い! に紹介されているようにオブザーバー・パターンを使うのも手ですが、ここでは簡単に次のようコールバックを使うことにします。

[javascript]
function get_repos(queries, callback) {
…// コールバック関数を指定 ↑

.done(function (data, textStatus, jqXHR) {
var res = …; // 読み込み結果の処理
callback(res);
})

.fail(function (jqXHR, textStatus, errorThrown) {
// エラー処理
;
});
}
[/javascript]

これに対する呼び出し側は例えば次の通りです（XSS 対策は文脈に合わせてネ）。

[javascript]
$(‘#submit’).on(‘click’, function () {
get_repos($(‘#queries’).val(), function (res) {
$(‘#repos’).html($.parseHTML(res));
});
});
[/javascript]

「読み込み結果の処理」は目的とするデータの抽出に専念し、DOM 操作を呼び出し側に集約するワケですネ。

（余談ですが、$(document.createDocumentFragment()) より $('<ul>') の方が 微妙に速そう です。 最後に一発 $.html() が良さげでした。）

AngularJSの場合

サービス部分は $http サービスを使えば、ほぼ jQuery と同様に出来ます（他にも get_users() とかを追加していく想定です）。

[javascript]
angular.module(‘myServices’, [])
.service(‘github’, [‘$http’, function ($http) {
this.get_repos = function (queries, callback) {
var url = ‘…’;
queries = encodeURIComponent(queries.replace(/\s+/g, ‘ ‘));

$http({
url: url + queries,
method: ‘GET’
})

.success(function (data, status, headers, config) {
var res = …; // 読み込み結果の処理
callback(res);
})

.error(function (data, status, headers, config) {
// エラー処理
;
});
};
}]);
[/javascript]

ちなみにコントローラー部分は次のようになります。

[javascript]
angular.module(“myApp”, [‘myServices’])
.controller(‘myCtrl’, [‘$scope’, ‘github’, function ($scope, github) {
$scope.submit = function () {
github.get_repos($scope.queries, function (res) {
$scope.repos = res.items;
});
};
}]);
[/javascript]

AngularJS、もう1つのパターン

Angular には、$http 関数の成功／失敗を処理する関数 success()、error() 以外に、もう1つ then() という関数があります（というか、こちらの方が古くてプリミティブ、たぶん）。両者の違いは次の通りです。

^* 印を成立させるには、次のように get_repos() から then() を介して $http の戻り値である Promise オブジェクト を返してやるのがミソです。

[javascript]
.service(‘github’, [‘$http’, function ($http) {
this.get_repos = function (queries) {
…
// ↓ この return がミソ
return $http({
url: url + queries,
method: ‘GET’
})

.then(
function (response) {
return response.data;
},
function (response) {
alert(response.data.message);
return {items: []};
}
);
};
}]);
[/javascript]

こうすると、サービス関数 get_repos() にコールバック関数を引き渡す必要がなくなり、呼び出し側は then() を介して目的のデータを受け取れるようになります。そればかりか、受け取るデータを変えながら次のチェーンにつなげられるというオマケ付きです。

どちらが好み？

jQuery の then() や AngularJS の success()、error() では jqXHR オブジェクトや展開されたレスポンス・オブジェクトがそのまま引数に渡されるだけで、同じ事は出来ません。

出来る事に違いはないので、どちらを使うかは好みで良いと思いますし、チェーンする機会もあまりないでしょう。しかしどのパターンにおいても deferred や promise は常にチェーンできるようにしておいた方が良いと思います。まぁ、覚えておいても損しないってことでネ！

※ 今回の場合、factory を使っても書ける し、単純さが変わらないのならそうする より単純な方を選ぶべきなのかもしれませんが、練習用として dickeyxxx/angular-boilerplate を参考にしました。

2015年1月13日 追記

正確性を期すためとは思いますが、 promise オブジェクトの元である $q の 日本語訳 が微妙にわかりずらい（失礼ッ、もちろん翻訳の労には感謝の意と敬意を表します）ので、私なりの注釈をつけた意訳を載せておきます。また promise の概念については、2011年の拙作「jQueryのDeferredとPromiseで応答性の良いアプリを－基本編」を参考にしてください。

The Promise API

deferred のインスタンスが作成されると、新しい promise のインスタンスが作成され、（注：deferred オブジェクトのプロパティとして） deferred.promise で参照できるようになります。

promise オブジェクトの目的は、延期されていたタスク（deferred task）が実行を完了した時、関係者がその結果にアクセス出来るようにすることにあります。

メソッド

then(successCallback, errorCallback, notifyCallback) – promise が解決されたか（resolved）あるいは否決されたか（rejected）に関わらず、 then は結果が得られるとすぐに成功または失敗のコールバックを非同期に呼び出します。その際コールバックには、ただ1つの引数: 解決の結果または否決の理由 が渡されます（注：各コールバックに結果を引き渡せるということです）。

加えて promise が解決または否決されるまで、その進行を示すために notify コールバックが0回以上呼び出されます。

このメソッドは successCallback または errorCallback の戻り値を介して、解決または否決された（状態の）新しい promise を返します（注：結果を引き渡しながらチェーンできるということです）。また notifyCallback メソッドの戻り値を介しても通知されます（注：notifyCallback が呼び出された時もチェーンされるということです）。ただし notifyCallback メソッドからは promise を解決または否決（の状態に）することはできません。

最初のバージョンで IP アドレスから国が引ける API をネット越しに叩き、次いでサーバー負荷の低減を狙って キャッシュを実装した ワケですが、ここ最近、無料 RESTful API のサービス中止が相次いだため、急ぎ安定した MaxMind の 無料 GeoLite データベース を使えるようにする必要があった次第です。

プログラミングは嫌いな方ではないですが、スパムやら bot 対策は何も新しいものを生みません。一所懸命に作り込んでも空しさが拭えないので、せめてココで告知させて下さい 。

2014年10月13日 追記

今回のバージョンアップではオプションテーブルの更新が必要なのですが、自動更新では更新処理が働きません。対応策が見つかるまではお手数ですが、更新後に一旦
「停止」し、再度「有効化」していただくよう、お願いします m_(..)_m。

MaxMind GeoLite データベースに関する仕様

MaxMind の GeoLite データベースは、月に1度、月初に更新されます。これに合わせ、プラグインのインストール後は WordPress のクローンで定期的にダウンロードする仕様としました。また MaxMind のサーバーは、Last-Modified ヘッダをちゃんと返すので、最終更新の1ヶ月＋α後に If-Modified-Since リクエストヘッダを付けて落としに行きます。

「＋α」の部分はアクセスを集中させないための乱数で、1〜6日まで幅を持たせています。また 304 Not Modified が返ってきた場合は、24時間後に再リクエストを試みます。

あまり高頻度にリクエストすると 403 Forbidden が返ってきたりするので、この辺りは緩やかな仕様としています。

またデータベースは IPv4 用と IPv6 用があり、両方とも落とします。実は IPv6 用で IPv4 も引けるのですが、容量が IPv4 用より大きく検索時間がかかるので、使い分けるようにしています。

もう少し細かな話をすると、ダウンロードには wp_remote_get() を使っています。このため gzip 全データをメモリ中に読み込んでからファイルに書き出す事になりますが、容量的には 1.3MB 程度なのでメモリ不足になる事はないでしょう。

実は download_url() という関数を使えば、巨大なファイルも stream として落とせるのですが、先の If-Modified-Since が効かなくなるので使っていません。

この辺りは、HEAD メソッドでヘッダー情報だけ取得するようにすれば良いだけなので、いずれ省メモリ化を計りたいと思います。

技術情報

• GeoIP Products
• maxmind/geoip-api-php
• GeoLite Legacy Downloadable Databases

その他の更新項目

IP2LocationのIPv6用データベースのサポート

IP2Location の無料データベース IP2Location LITE が、10月1日のリリースから IPv6 をサポートするようになりました。

We are glad to announce that IP2Location is supporting IPv6 database in all products from this release.

10月のニュースレターより

これらのファイルを database.bin にリネームし、wp-content/ip2location/ に置けば利用可能です（登録 と 帰属リンク が必要）。ファイルサイズが大きくなるほど検索時間もかかるので、出来る限りコンパクトな形式を選択するのが吉です。

技術情報

• Free/Open Source
• Free Extensions/Plugins
• IP2Location Lite

RESTful APIの更新

API の幾つかが、サービス停止あるいはキーを要求するようになったので、削除しました。ストックはまだ幾つかあるのですが、MaxMind の自動ダウンロードにより、ほぼメンテナンス・フリーとなったため、今後は緩やかに削減の方向になると思います。

判定処理の効率化

前バージョンでは、コメントのチェックも想定し、preprocess_comment アクション・フィルタをフックしていましたが、pre_comment_on_post に変更しました。これにより wp-comments-post.php へのアクセス直後に判定でき、サーバー負荷が軽減されます。

今後は？

セキュリティ用プラグインとして本格的な Wordfence Security の プレミアム版 には、スパムや wp-login.php への Brute Force 攻撃 を防御するための Country Blocking という機能がありますが、有料です。

これが無料で提供できれば少しは価値があるかな？と思っています。ただセキュリティ用となると、海外からのアクセスを弾くだけでは成り立ちません。あまりコードを肥大化させる事なく実現できる道を探っていきたいと思います。

こいつらに貴重なサーバー資源を食われるのは1ミリたりとも許せないワケで、かつては日本以外の IP アドレスを .htaccess に手作業で書き込んでいましたが、あまりにも量が多く、馬鹿げているので止めました。

そんなワケで作ったのが、海外からの投稿を Akismet の起動前に弾く IP Geo Block というプラグインなんですが、スパムは激減するものの、IP アドレスの検索に少々時間がかかるのが気になる点でした。

で、この度、一度検索した IP アドレスをキャッシュに保持する機構を付けたところ、思いの外、効果があったので、バージョン 1.1.0 として告知したいと思います 。

バージョン 1.1.0 での変化点

主に次の3つです。

1. 一度検索した IP アドレスと国コードを一定期間キャッシュする機能を追加。
2. サービス提供元で生じた障害を分析し易くするため、エラー処理を改善。
3. ユーザーエージェント文字列をプラグイン独自のものに変更。

キャッシュ機構の追加

本プラグインは、IPアドレスの地理的位置情報が引ける無料RESTful API集 でピックアップした API を呼び出すか、IP2Location Tags など IP2Location が提供するプラグインのインストールで利用可能となるデータベースを用いて、IP アドレスの国コードを検索するのが仕様です。

前者は、API から返答が返ってくるまでの数百ミリ秒から数秒の間、コネクションが張られっぱなしになりますし、後者は、WordPress にインストールされたデータベース・ファイルの検索に50ミリ秒前後のCPU処理を必要としていました。

一方、今回のキャッシュ化により、2度目以降の検索は数ミリ秒で完了するようになりました。

スパムの投稿パターンにも依りますが、今のところデフォルトの設定で90%以上のヒット率をキープしています。

キャッシュの実装には Transient API を利用していて、デフォルトでは最大10個の IP アドレスを3600秒間保持するようにしています。

本プラグインの設定画面で上のようにならない場合、一旦本プラグインを「停止」し、再度「有効化」して下さい。自動的に設定値を更新します。

エラーメッセージ処理の改善

API 提供元の都合により、サービスに障害が起きたり停止したりすることがあります。例えば smart-ip.net はサイト自体が停止してしまったため、前バージョンの 1.0.3 で外しています。

このような状況を分析し易くするため、サービスが返すエラーメッセージや HTTP レベルで起きるエラーを検索タブで確認できるようにしました。

まぁ、ユーザーの皆さんにはあまり関係のない機能ですネ。

ユーザーエージェント文字列の変更

WordPress 標準の wp_remote_get() を使うと、ユーザーエージェント文字列は、例えば次のようになります。

[text]
WordPress/3.9.2; http://tokkono.cute.coocan.jp/blog/slow
[/text]

これを次のように変えました。

[text]
WordPress/3.9.2; ip-geo-block 1.1.0
[/text]

ただそれだけのことです。

IP2Locationのデータベースについて

海外からの投稿を弾くスパム対策用WordPressプラグインをリリースします にも書きましたが、本プラグインは IP2Location の無料プラグイン をインストールするか、それぞれを ip2location にリネームし wp-content にアップロードすることで、そのデータベースが利用可能になります（配置後、本プラグインを一旦「停止」、再度「有効化して下さい）。

必要なのは、データベース本体の database.bin と ip2location.class.php というクラス・ライブラリのファイルです。

またデータベースを オープンソースの無料データベース に差し替えれば、さらに幸せになれます。メールアドレスの登録と IP2Location.com への 帰属リンク張りが必要 ですが、IPv6 もカバーされているので、* 他の サービス API を呼び出す頻度がグッと減ります。

* IPv6 の無料データベースは、こちら でした。

私は About ページにリンクを貼った上で DB5.LITE を利用していますが、月に一度、データベース更新の案内が届くぐらいで、特に面倒なく使えています。

今後の構想

今回のキャッシュ化により、例えば WordPress の管理領域にアクセスしに来た IP アドレスを記録して弾く仕様を追加すれば、セキュリティ向上にもつながるかな？ などと夢想しています。

もっとも、優れた セキュリティ用プラグイン はたくさんありますし、より根本的な対策をすべきですけどネ。

まぁ、今後も細々とメンテはしていきますので、良かったら使ってやって下さい 。

ということで、レスポンシブ画像のことを調べていていましたが、その技術進化というか、紆余曲折も含めて色々とある様です。

最新技術を素早く取り入れることはもちろん大事ですが、特に過渡期においては、変化に強いサイトを作るためにも技術の先行きを見極めることが重要です。そこでタイトルのような視点で、これまでの経緯をつらつらと辿ってみました。

自分としてのテーマは、「じゃあ、今、どうするか？」だったのですが…。読んで下さる方の何かに役立つかどうかは甚だ心もとない記事です。

ちなみに今回記事で取り上げた話題については、レスポンシブ画像のデモ に、もう少し掘り下げて展示しています。そちらもぜひ覗いてみて下さい！

レスポンシブ画像をめぐる要求の変化

レスポンシブ画像とは従来、ビューポートや画面解像度（時には印刷時の解像度）などに適した画像を表示することを指し、

• ビューポートや回線速度に適した画像を提供し、モバイル環境での通信量低減を図る
• Retina などピクセル密度の高い表示デバイスには、解像度の高い画像を提供する

などが主な関心事項でした。

一方 W3C コミュニティ・グループ の1つである RICG が考える理想的なレスポンシブ画像とは「ユーザーのコンテキストに適した画像」です。彼らはその ユースケース として、上記に加え次のような要求があると考えています。

• 省電力モードでは低品質の画像を選択し、通信時の消費電力を抑える
• 端末のサイズに合わせ、ユーザーに対する訴求に最適な画像を提供する

特に後者は Art Direction（広告、宣伝、グラフィックデザインなどにおいて、主に視覚的表現手段を計画し、総括、監督すること）と呼ばれ、例えばモバイル用には単なる縮小画像ではなく、ユーザーに訴求したいエリアを切り出し拡大して見せる ことを要求します。

アートディレクションの例 / Photo from Barack Obama (CC BY-NC-SA 2.0)

RICG はこれらレスポンシブ画像をめぐる様々な要求を、以下のように、既存規格の拡張で実現できるよう検討を進めています。

• HTML の拡張
  • ビューポートとデバイス・ピクセル比に応じて適切な画像が選択できるよう、ユーザーエージェントにヒントを与えるマークアップ仕様
• HTTP の拡張
  • ユーザーエージェントの表示能力を HTTP リクエストに載せ、サーバーとのコンテンツ・ネゴシエーションにより適切な画像を提供する仕組み

ビューポートやデバイス・ピクセル比は、従来からスタイルやレイアウトで扱うべきと要素と考えられており、既に CSS3 メディア・クエリ で扱えます。

しかしアート・ディレクションの例でも分かる通り、もはやレスポンシブ画像に関する要求はコンテンツ自体の問題となり、ビューポートやデバイス・ピクセル比を HTML でも扱えるようにする必要が出てきた言えます。

いずれにしても当初言われていた「ワンソースでマルチデバイスに対応」というレスポンシブデザインの謳い文句は、もはや画像に関しては「死語」に近く、要求が複雑化していくと共に、今後はマルチソースの方向になると思われます。

Retina 用の画像は低画質で良い！ – Retina 革命

2012年の初頭は、レスポンシブWebデザインが Future-Ready なコンテンツ で Future Friendly なサイトを作る技術としてもてはやされていた頃です。

ところが Retina の出現をキッカケに「画像のボケ」が問題になり、そのクオリティを保つため、通信量の増加には目をつぶり、デバイス・ピクセル比に応じて縦横2倍の画像を提供するよう、コンテンツを修正せざるを得なくなりました。

以降、相当数の「レスポンシブな画像を実現する手段」が提案されてきましたが、どの手法を使えば良いのか、未だ決定打がない状態が続いていると思います。

一方で、Daan Jobsis さん の2012年7月27日の記事 Retina 革命 が大きな反響を呼びました。彼は、Retina 用の高解像度画像なら、画質をかなり落としても十分綺麗に見えるということを明らかにしたのです。

例えば、320×240 の画像なら Retina 用には 640×480 の画像を作るわけですが、その際 jpeg の画質を 80 とか 90 にする必要はなく、20 か 30 で十分で、かつ非 Retina 用画像に比べてファイルサイズが 75% 程度で済むというのです。

Neste Oil Rally 2010 – Jari-Matti Latvala in shakedown by kallerna (CC-BY-SA-3.0 or GFDL)

同時にその画像は、非 Retina デバイスで見ても遜色ないことや、元ファイルの解像度が足りない場合でも Photoshop で拡大した画像の方が良い結果が得られることも明らかにしています。

つまり、Retina 用と非 Retina 用に画像ファイルを分ける必要がなく、常に2倍の（低画質な）高解像度画像を提供すればイイというワケです。

どのデバイスでも、ファイルサイズが小さく、より高品質だなんて、あり得ない！

彼はデザイナーとしての視点から、ハードウェアの技術革新が従来の常識を覆したことに、純粋に驚いたのでしょう。これが「Retina 革命」とタイトル付けされた理由です。

もちろん、このような画像のレンダリングは電力を余計に消費するため、通信時間の短縮とを天秤にかける必要があるかも知れません。それでも、読み込みとレンダリングを最悪2回実行してしまう Retina.js を使うよりは、はるかにマシでしょう。

むしろ Daan さんの発見は単なるテクニックではなく、デバイスピクセル比の問題を HTML 外で解決する道を示唆しているとも考えられます。

現に 複数のレイヤーに解像度毎の画像を差分として載せ、圧縮率を高めるレスポンシブ画像コンテナ や 全画像の同時並列な読み込みとレンダリングを可能にするプログレッシブ・ダウンロード の研究などが進んでいます。

また Google の開発者は 将来 webp で 3D 画像を扱いたい と語っていますし、そのうち 3D 表示デバイスなどがもっと一般化するかもしれません。これらの研究成果は、新しいメディア・タイプの出現を予感させます。

特に過渡期においては Daan さんの様なテクニックやハックの類いが必ず出現するものですが、RWD に関する要求の複雑化を念頭に置けば、標準規格の整備と共に、ブラウザの進化が不可欠な状況にあると思います。

ブラウザの漸進的な進化

レスポンシブな画像を実現する 様々な手法 の中には、異なるサイズの画像を二重に読み込み、サイト速度の低下や電池の消耗を引き起こすものがあります。

例えば JavaScript を使う手法では、<img> 要素の src 属性を差し替える前（つまり HTML 解析時）に ブラウザの先読み機能 が働いてしまいます。

また回線速度に応じた画像を選ぶ場合も、 foresight.js 等のスクリプト読み込み後ではなく、Navigation Timing Network Information API を元に、 HTML 解析時に選ぶのが理想的です。

このような レスポンシブ画像が抱える様々な課題を解決する には、その手段が ブラウザのネイティブな機能として取り込まれることが必須 です。

このため2011年台から <picture> 要素が提案 されてきたワケですが、ここにきてようやく <img> 要素の srcset 属性 が Chrome 34 に実装 されました。その元になった RICG の仕様案は以下の通りです。

srcset="url [descriptor] [, url ...]"

url

画像への URL

descriptor

device pixel ratio

小数点を含むデバイス・ピクセル比（DPR）に "x" を付加

image dimension

正の整数である画像の幅に "w" を付加

例えば次のマークアップでは、DPR に適した画像が選択されます。

[html]
<img src=”small.jpg” srcset=”small.jpg 1x, medium.jpg 2x” alt=”…”>
[/html]

さて、ここで私が注目したいのは DPR を直接指定する第1の書式ではありません。ビューポートが絡むと、例えばスマホ用 small.jpg の 2x が、デスクトップ用 medium.jpg の 1x と同になったりする可能性もあり、この書式では表現できないからです。

かつては 第1と第2の書式が混在した仕様案 もありましたが、最近の仕様案 では、両者は区別されています。

実は RICG の案には「sizes」という属性があります。これはデバイス・ピクセル比に振り回されることなく、レイアウト指向でマークアップできるようにするためのもので、ブラウザが最適な画像を選択できるようヒントを与える役割りを果たします。

簡単化のために <img> 要素の例でちょっと説明しますネ。

[html]
<img src=”small.jpg” alt=”…”
sizes=”(min-width: 40em) 45vw, 90vw”
srcset=”small.jpg 480w, medium.jpg 960w, large.jpg 1920w”>
[/html]

sizes 属性には 45vw とか 90vw などの ビューポートに対する表示幅の百分率 を指定します（% も指定可）。

一方 srcset 属性には 1x とか 2x の代わりに 480w とか 960w などが指定されています。これらは一見すると ビューポート幅 を指しているようですが、実は各画像ファイルの横幅（CSS ピクセル値）を表します。

これらによりブラウザは、次式で算出される値を元に srcset 属性の中から最適な幅を持つ画像ファイルを選択します。

[text]
最適な画像ファイルの幅 = ビューポートに対する表示幅の百分率 / 100 × ビューポート幅 × デバイス・ピクセル比
[/text]

この書式であれば、純粋にレイアウト上の計算から導かれる選択肢をマークアップすれば OK で、ブラウザは、自らのビューポート幅やデバイス・ピクセル比に適した画像を選択することが出来るのです。

残念ながら Chrome 34 でこの書式は実装されていません。ですが RICG の 実装状況リスト にあるように、 <picture> 要素とのセットでリリースされるのではないかと思っています。

少しずつかも知れませんが、 RICG の活動が実を結ぶとイイですネ。

コンテンツとスタイルの境界

そもそも <picture> 要素の仕様案 は <video> 要素と相関性のある案 を元に策定されました。例えば以下のマークアップでは、ブラウザが適切なフォーマットを選ぶことができます。

[html]
<video poster=”firstframe.jpg”>
<source src=”sample.mp4″ type=”video/mp4; codecs=’…'”>
<source src=”sample.ogv” type=”video/ogg; codecs=’…'”>
</video>
[/html]

ここまではコンテンツ側の問題であり、特に違和感はありません。これに対し、<picture> では、例えばこんな感じです。

[html]
<picture>
<source media=”(min-width: 480px)” srcset=”small.jpg medium.jpg 2x”>
<source media=”(min-width: 960px)” srcset=”medium.jpg, large.jpg 2x”>
<img src=”small.jpg” alt=”…”>
</picture>
[/html]

この仕様であれば、新しいメディア・タイプの出現やアート・ディレクションの要求を受け入れることが出来るでしょう。

一方、サイトのブレークポイントと上記 media 属性とが一致していないと、意図したリソースが選ばれないという問題が出てきます。こうなるともはや、「ドキュメント（HTML）とスタイル（CSS）の分離」という Web の原則や常識は、どこに行っちゃたの？ と疑いたくなります。

この仕様案に関しては、下位互換性のためとは言え、それ自体でコンテンツを表示しない画像系のタグが増えることに、ブラウザ・ベンダーが反対していたという話があったようです（すみません、出典は失念しました）。

最初の章でも書きましたが、実のところ、ドキュメントとスタイルの境界が極めて曖昧になる、というか、両者の結び付きが強まることが、今後の大きな課題だと思います。

先に「<picture> 要素はいずれ実装される」などと無責任な予測を書きましたが、この課題がどう決着されるのかは見ものです。これまでのように、そこそこの期間を要する可能性もあると思いますが、皆さんはどうお考えでしょうか？

さて過渡期の今、どう対処するか？

ハッキリ言って、分かりません（オィ、コラァ！）。少なくとも今回、記事に貼る画像を、デスクトップでの表示幅の2倍かつ画質 0 で作成してみました。まぁ、jpeg ならそれなりに減量効果はあります。

次回は、レスポンシブ画像を実現する様々な手法を取り上げながら、世界の人たちがどう対処しているのかを見ると共に、レスポンシブ画像に要求される近々の要件を整理しながら、さらに掘り下げてみたいと思います。

ご期待ください（するかぁ！？）。

もちろんこういった問題の解決を図るプラグインも多数リリースされていますが、ページ単位の処理なので、サイト全体の構成を通して最適にはなりません。

そこで第1部「サイト高速化の「戦略」と「戦術」- GradeAのその先へ」、第2部「サイトに適したリソース配置とasync/defer完全マスター – レンダリング優先のグッド・プラクティス」では、数あるベスト・プラクティスの全体を俯瞰し、個々の Tips やテクニックからは見え難い、最適化の考え方や道筋を提案しました。

その総仕上げとして今回は、WordPress サイトを例題に、必ず結果の出る HTTP リクエストの削減方法を提案したいと思います。

実践的手法の概要

HTTP リクエストの削減を目的とした css、js の結合系プラグインでは、「サイトが正しく機能しない」といったことが頻繁に起き、その修正にはトライ＆エラーが必要です。

プラグインの幾つかは、トラブルに対処するための調整機能を提供してくれていますが、サポート・フォーラムを見ていると、そういった機能を使いこなす前に（あるいは存在すら知らずに）導入を断念するケースも少なくありません。

元はと言えばプラグインの導入で増えた乱雑な css や js を、ページ内の文脈に合わせて自動で結合すること自体、ムリな話です。「どのファイルをどう結合すべきか」は人手で仕分け、ある程度シンプルになったところでプラグインの力を借りる – 数あるプラグインを試して私が得た結論は、結局はこれが王道かつ近道だと言うことです。

そこで今回は、どのプラグインにも手を加えることなく css や js を見通しよく人手で結合し、残りをプラグインで自動結合する、という方針で臨むことにします。人手 とは言え、結合を簡単化する補助的なツールを作成しましたので、ご安心を。

以下、その概要です。

人手による結合

「サイト高速化の「戦略」と「戦術」- GradeAのその先へ」でも述べたように、まずは以下の観点で css や js をグループに仕分けます。

• <head> に配置するリソース：「Above the hold」のコンテンツに関連するリソース
• </body> に配置するリソース：サイト全体を通して共通なリソース

このうち、結合の対象とするのは WordPress の標準的な方法で挿入されたファイルとします。

「標準的な方法」とは、wp_enqueue_*() で挿入されたことを意味します（アクション・フックの wp_head や wp_footer をトリガーに、外部ファイルの読み込みコードを直接 echo で吐き出すのは、今や時代遅れなのですョ ）。

作戦としては以下の通りです。

• wp_enqueue_*() でキューイングされているリソースを抽出する
• 一旦個々のリソースを wp_dequeue_*() で解除する
• 解除したリソースを、適当なツールで結合する
• 結合したリソースを wp_enqueue_*() でキューに登録する

最も面倒な作業が「キューイングされているリソースの抽出」ですが、各プラグインのソースコードを調べることなく、この作業を簡単化するツールは後半で説明します。

また、リソースの結合には PHP プログラム「minify」を使います。応答性という点ではベストではありませんが、次のようなメリットがあります。

1. 使い方が簡単
2. インストールが簡単
3. グループが構成できる
4. gzip 圧縮やキャッシュ有効期限の設定ができる
5. 圧縮ファイルを予めキャッシュできるため、負荷が低い
6. 304 Not Modified の応答ができる
7. APC や Memcache の導入も可能
8. 幾つかの WordPress プラグインと親和性が良い

特にグループを構成できる点が、今回の趣旨にはぴったりです。また安定運用の暁には、構成したグループを静的ファイルに置き換え、CDN に叩き込めば完璧です！

プラグインによる結合

前章の結合で残ったリソースは次のいずれかでしょう。

• ページに個別のリソース
• ベスト・プラクティスに従い、</body> 直前に置けば良いスクリプト

これらをプラグインで再結合します。

過去 の 記事 では Head Cleaner や WP Minify（現在は更新停止、セキュリティ問題アリ）をオススメしましたが、改めて19のプラグインをざっと評価した結果、以下の理由により、今回は Autoptimize をイチオシとします。

• インラインの css や js も結合ファイルに含めるため、不具合が起きにくい
• 結合から外す除外指定の自由度が高く、柔軟な構成が可能
• </body> 直前の配置を基本に、一部を <head> に置くことも可能
• 細かな調整を可能とするアクション・フックが豊富
• 予め不具合の出るプラグインへの対応が埋め込まれている
• defer 属性がサポートされている
• サポート・フォーラムが活発で、何より作者の気合いが感じられる

css、js結合の実践的手法

例題として、ローカルに仕立てたサーバー http://localhost/ のドキュメント・ルート直下に WordPress 3.9 + TwentyFourteen を、そして以下のプラグインをインストールしました。

• Meteor Slides
  • インラインと外部スクリプトを組み合わせて使うため、自動結合で問題が起き易いパターンです。本例では「Above the fold」のコンテンツ、かつ各ページ共通のリソースという想定です。スクリプトの読み込み後にレンダリングするので表示が遅れがちですが、カスタマイズ機能を活用し、初期のレンダリングに必要な HTML をサーバー側で構築する例をお見せします。
• jQuery Smooth Scroll
  • これも各ページ共通で使う想定です。
• SyntaxHighlighter Evolved
  • クライアント側でレンダリングするタイプの代表で、リフロー や FOUC が避けらません。高速化の観点からは、サーバー側で HTML を構築する GeSHi を使った プラグイン の方が良いでしょう。コードに応じて読み込むリソースが変わるので、ページ毎に個別のリソースという想定です。
• WP Social Bookmarking Light
  • wp_head、wp_footer を介して css や js の読み込みを直接 echo するプラグインの代表です。Hatena に対応してるので、背に腹は代えられないという人なら。

この例題に対するリソース配置のゴールを以下のように設定しました。

• スライドショーを素早く表示させるため、そのリソースは <head> に配置する
• ただし後続のページ解析を妨げないよう、スクリプトは async 付きで読み込む
• また体感速度が速くなるよう、HTML は可能な限りサーバー側で構築する
• Syntax Highlighter 用のリソースは、結合した上で </body> 直前に配置する
• ソーシャルメディア用のスクリプトは </body> 直前に配置する

以下、この例題を元に具体的に説明していきます。手順は多目ですが、ガンバって付いて来て下さい。きっと報われます 。

1. キューイングされているリソースのハンドル名を調べる
2. minify のインストールと基本設定
3. groupsConfig.php に結合対象のリソースをグループとして登録する
4. functions.php でグループ化した各リソースをキューから削除する
5. functions.php でグループをキューに登録する
6. 残ったリソースをプラグインで結合する
7. 初期のレンダリングを高速化する
8. 参考情報

キューイングされているリソースのハンドル名を調べる

まずは次のコードを、テーマ（あるいは子テーマ）の functions.php に追加します。

[php]
/**
* Make the list of enqueued resources
**/
function my_get_dependency( $dependency ) {
$dep = “”;
if ( is_a( $dependency, “_WP_Dependency” ) ) {
$dep .= “$dependency->handle”;
$dep .= ” [” . implode( ” “, $dependency->deps ) . “]”;
$dep .= ” ‘$dependency->src'”;
$dep .= ” ‘$dependency->ver'”;
$dep .= ” ‘$dependency->args'”;
$dep .= ” (” . implode( ” “, $dependency->extra ) . “)”;
}
return “$dep\n”;
}

function my_style_queues() {
global $wp_styles;
echo “<!– WP_Dependencies for styles\n”;
foreach ( $wp_styles->queue as $val ) {
echo my_get_dependency( $wp_styles->registered[ $val ] );
}
echo “–>\n”;
}
add_action( ‘wp_print_styles’, ‘my_style_queues’, 9999 );

function my_script_queues() {
global $wp_scripts;
echo “<!– WP_Dependencies for scripts\n”;
foreach ( $wp_scripts->queue as $val ) {
echo my_get_dependency( $wp_scripts->registered[ $val ] );
}
echo “–>\n”;
}
add_action( ‘wp_print_scripts’, ‘my_script_queues’, 9999 );
[/php]

続いてページを表示し、HTML ソースから以下のようなコメントを抜き出します。

[text]
<!– WP_Dependencies for styles
ハンドル名 [依存するハンドル名…] ‘パス’ ‘バージョン’ ‘属性’ (付加情報…)
…
–>

<!– WP_Dependencies for scripts
ハンドル名 [依存するハンドル名…] ‘パス’ ‘バージョン’ ‘属性’ (付加情報…)
…
–>
[/text]

ハンドル名

wp_enqueue_style()、wp_enqueue_script() でキューに挿入されるリソースのハンドル名です。

依存するハンドル名

先立って読み込んでおくべきリソースのハンドル名が上位から順に並びます。

パス

wp_register_style()、wp_register_script() で登録されたリソースへのパスです。

バージョン

登録時に指定されたバージョン文字列です。

属性

css の場合はメディアタイプが表示されます。同一タイプであれば結合が可能です。

付加情報

css であれば IE 用の条件付コメントがここに表示されます。js の場合、1 (true) が立っていればフッターで読み込まれることを示し、それ以外は「読み込みに先立って実行されるべきインライン・コード」が現れます。

ここでのポイントは、色々なタイプのページを表示し、サイトに共通なリソース群や、優先して <head> に配置すべきリソース群など、グループ分けを行うことです。

今回は、Meteor Slides が各ページ共通、かつ優先すべきリソースという想定ですので、以下を <head> に置くリソースとして抽出しました。個別ページ用の comment-reply.min.js や IE 用の css などは含んでいません。

[text]
<!– WP_Dependencies for styles
genericons [] ‘http://localhost/wp-content/themes/twentyfourteen/genericons/genericons.css’ ‘3.0.2’ ‘all’ ()
twentyfourteen-style [genericons] ‘http://localhost/wp-content/themes/twentyfourteen/style.css’ ” ‘all’ ()
twentyfourteen-ie [twentyfourteen-style genericons] ‘http://localhost/wp-content/themes/twentyfourteen/css/ie.css’ ‘20131205’ ‘all’ (lt IE 9)
meteor-slides [] ‘http://localhost/wp-content/plugins/meteor-slides/css/meteor-slides.css’ ‘1.0’ ‘all’ ()
blogsynthesis-scroll-to-top-style [] ‘http://localhost/wp-content/plugins/jquery-smooth-scroll/css/jss-style.min.css’ ” ‘all’ ()
–>

<!– WP_Dependencies for scripts
jquery [jquery-core jquery-migrate] ” ‘1.10.2’ ” ()
jquery-cycle [jquery] ‘http://localhost/wp-content/plugins/meteor-slides/js/jquery.cycle.all.js’ ” ” ()
jquery-metadata [jquery] ‘http://localhost/wp-content/plugins/meteor-slides/js/jquery.metadata.v2.js’ ” ” ()
jquery-touchwipe [jquery] ‘http://localhost/wp-content/plugins/meteor-slides/js/jquery.touchwipe.1.1.1.js’ ” ” ()
twentyfourteen-script [jquery] ‘http://localhost/wp-content/themes/twentyfourteen/js/functions.js’ ‘20131209’ ” (1)
meteorslides-script [jquery jquery-cycle] ‘http://localhost/wp-content/plugins/meteor-slides/js/slideshow.js’ ” ” (var meteorslidessettings = {“meteorslideshowspeed”:”2000″,”meteorslideshowduration”:”5000″,”meteorslideshowheight”:”200″,”meteorslideshowwidth”:”940″,”meteorslideshowtransition”:”fade”};)
blogsynthesis-scroll-to-top-script [jquery] ‘http://localhost/wp-content/plugins/jquery-smooth-scroll/js/jss-script.min.js’ ” ” ()
–>
[/text]

ハンドル名 jquery には パス が現れず、jquery-core と jquery-migrate への依存が指定されています。それぞれのパスは次の通りです。

• wp-includes/js/jquery/jquery.js
• wp-includes/js/jquery/jquery-migrate.min.js

パスが空のハンドル名が出てきたら、面倒でも Handles and Their Script Paths Registered by WordPress を調べて下さい。

またこれらの情報は優先度が高い順に並ぶとは限りません。結合対象とする css と js のハンドル名をピックアップし、順番に注意した上で並べ換えておきましょう。

minify のインストールと基本設定

ダウンロード・リンク から最新版を落とし、解凍後、「min」ディレクトリだけをサーバーにアップロードします。「min」はドキュメント・ルートに置くことが推奨されていますが、今回は wp-content の直下に配置してみました。

基本設定で重要なのは2か所です。min/config.php を開き、以下を参考に設定して下さい。

キャッシュ保存場所の設定

次は、「min」の直下に「cache」というディレクトリを作成する場合の例です。

[php]
/**
* For best performance, specify your temp directory here. Otherwise Minify
* will have to load extra code to guess. Some examples below:
*/
//$min_cachePath = ‘c:\\WINDOWS\\Temp’;
//$min_cachePath = ‘/tmp’;
//$min_cachePath = preg_replace(‘/^\\d+;/’, ”, session_save_path());
$min_cachePath = dirname(__FILE__) . ‘/cache’;
[/php]

作成したディレクトリには、お使いのサーバーに合わせてパーミッションを設定します。大抵の場合は 755 で OK でしょう。

キャッシュ有効期間

ブラウザやプロキシー・サーバーに保持させるキャッシュ期間を「秒」で指定します。出来る限り長く（1か月）設定し、「Grade A」の条件を保ちましょう。

[php]
/**
* Cache-Control: max-age value sent to browser (in seconds). After this period,
* the browser will send another conditional GET. Use a longer period for lower
* traffic but you may want to shorten this before making changes if it’s crucial
* those changes are seen immediately.
*
* Note: Despite this setting, if you include a number at the end of the
* querystring, maxAge will be set to one year. E.g. /min/f=hello.css&123456
*/
$min_serveOptions[‘maxAge’] = 2592000; /* one month */
[/php]

その他

$min_builderPassword は、min/builder を利用しない（$min_enableBuilder = false）限り、気にする必要はありません。min/builder は、index.php に引き渡すクエリ文字列を構築する補助ツールです。詳しくは Minify 2.1 on mrclay.org を参照してください。

groupsConfig.php に結合対象のリソースをグループとして登録する

ピックアップしておいた結合対象の css と js を、サイト共通のリソース・グループとして min/groupsConfig.php に登録します。条件付きコメントで読み込まれる IE 用 css は含まないよう注意してください。

今回は、<head> に置く site-css と site-js をグループとして登録しました。もちろんグループは幾つでも定義する事ができます。

[php]
/**
* You may wish to use the Minify URI Builder app to suggest
* changes. http://yourdomain/min/builder/
*
* See http://code.google.com/p/minify/wiki/CustomSource for other ideas
**/

return array(
// ‘css’ => array(‘//css/file1.css’, ‘//css/file2.css’),
‘site-css’ => array(
‘//wp-content/themes/twentyfourteen/genericons/genericons.css’,
‘//wp-content/themes/twentyfourteen/style.css’,
‘//wp-content/plugins/meteor-slides/css/meteor-slides.css’,
‘//wp-content/plugins/jquery-smooth-scroll/css/jss-style.min.css’,
),

// ‘js’ => array(‘//js/file1.js’, ‘//js/file2.js’),
‘site-js’ => array(
‘//wp-includes/js/jquery/jquery.js’,
‘//wp-includes/js/jquery/jquery-migrate.min.js’,
‘//wp-content/plugins/meteor-slides/js/jquery.cycle.all.js’,
‘//wp-content/plugins/meteor-slides/js/jquery.metadata.v2.js’,
‘//wp-content/plugins/meteor-slides/js/jquery.touchwipe.1.1.1.js’,
‘//wp-content/plugins/meteor-slides/js/slideshow.js’,
‘//wp-content/plugins/jquery-smooth-scroll/js/jss-script.min.js’,
‘//wp-content/themes/twentyfourteen/js/functions.js’,
),
);
[/php]

（コメント以外の）先頭の // は minify 独自の表記法で、ドキュメント・ルートを表します。

上の例ではローカルの jquery.js を結合対象にしていますが、CDN を使いたい場合には外してください。またリモート・ファイルを加えることも可能です。詳しくは Non-File Sources を参考にして下さい。

設定後、http://localhost/wp-content/min/?g=site-css、http://localhost/wp-content/min/?g=site-js にそれぞれアクセスできるか確認しておきましょう。

ちなみに Apache サーバー なら、「min/.htaccess」の設定により ? が省略可能です。プロキシーによっては ? 付きのリクエストがキャッシュされないことがあるそうなので、できれば省略しましょう。

functions.php でグループ化した各リソースをキューから削除する

次に、結合対象の各リソースをキューから削除するコードを追加します。同時にこれらと依存関係のある IE 用 css も解除しておきます（後で復活させるので、ご心配なく）。

[php]
/**
* Dequeue resources
**/
function my_dequeue_styles() {
wp_dequeue_style( ‘genericons’ );
wp_dequeue_style( ‘twentyfourteen-style’ );
wp_dequeue_style( ‘twentyfourteen-ie’ );
wp_dequeue_style( ‘meteor-slides’ );
wp_dequeue_style( ‘blogsynthesis-scroll-to-top-style’ );
}
add_action( ‘wp_print_styles’, ‘my_dequeue_styles’ );

function my_dequeue_scripts() {
wp_dequeue_script( ‘jquery’ );
wp_dequeue_script( ‘jquery-cycle’ );
wp_dequeue_script( ‘jquery-metadata’ );
wp_dequeue_script( ‘jquery-touchwipe’ );
wp_dequeue_script( ‘meteorslides-script’ );
wp_dequeue_script( ‘twentyfourteen-script’ );
wp_dequeue_script( ‘blogsynthesis-scroll-to-top-script’ );
}
add_action( ‘wp_print_scripts’, ‘my_dequeue_scripts’ );
[/php]

functions.php でグループをキューに登録する

css の挿入

続いて、グループ site-css を挿入します。

ポイントは IE 用 css の再挿入です。wp_enqueue_scripts() と wp_print_styles() とでは、後者の方が後に実行されるため、ハンドル名を変えて再登録します。

[php]
/**
* Eequeue resources
**/
function my_enqueue_styles() {
wp_enqueue_style( ‘site-css’, site_url() . ‘/wp-content/min/?g=site-css’, array(), ‘1.0’ );
wp_enqueue_style( ‘my-enqueue-ie’, get_template_directory_uri() . ‘/css/ie.css’, array( ‘site-css’ ) );
wp_style_add_data( ‘my-enqueue-ie’, ‘conditional’, ‘lt IE 9’ );
}
add_action( ‘wp_enqueue_scripts’, ‘my_enqueue_styles’ );
[/php]

js の挿入

さらに、グループ site-js を挿入します。

ここでの最初のポイントは js の配置です。今回 site-js は <head> に配置するので、wp_enqueue_script() の5番目の引数 $in_footer には false を設定します。

第2のポイントは「読み込みに先立って実行されるべきインライン・コード」の設定です。本例ではスライドショーの設定がこれに当たり、wp_localize_script() を使って埋め込みます。

[php]
function my_enqueue_scripts() {
wp_enqueue_script( ‘site-js’, site_url() . ‘/wp-content/min/?g=site-js’, array(), ‘1.0’, false );
wp_localize_script( ‘site-js’, ‘meteorslidessettings’, array(
“meteorslideshowspeed” => “2000”,
“meteorslideshowduration” => “5000”,
“meteorslideshowheight” => “200”,
“meteorslideshowwidth” => “940”,
“meteorslideshowtransition” => “fade”,
) );
}
add_action( ‘wp_enqueue_scripts’, ‘my_enqueue_scripts’ );
[/php]

またより低レベルな関数 add_data() を使う方法もあります（css には add_data() のラッパー関数 wp_style_add_data() が有るのに js に無いのは何故でしょう？）。

[php]
function my_enqueue_scripts() {
wp_enqueue_script( ‘site-js’, site_url() . ‘/wp-content/min/?g=site-js’, array(), ‘1.0’, false );
$js = <<add_data( ‘site-js’, ‘data’, $js );
}
add_action( ‘wp_enqueue_scripts’, ‘my_enqueue_scripts’ );
[/php]

CDN の jQuery を使う場合は、site-js の登録を次のコードに置き換えます。

[php]
function my_enqueue_scripts() {
wp_deregister_script( ‘jquery’ );
wp_enqueue_script( ‘jquery’, ‘//ajax.googleapis.com/ajax/libs/jquery/1.11.0/jquery.min.js’, array(), ‘1.11.0’, false );
wp_enqueue_script( ‘site-js’, site_url() . ‘/wp-content/min/?g=site-js’, array( ‘jquery’ ), ‘1.0’, false );
…
}
[/php]

最後のポイントは、site-js への async 属性の付与です。ちょっと危ういハックですが、公式サポートがまだ実現していない 以上、やむを得ないですネ。

[php]
function my_add_async( $url ) {
if ( strpos( $url, ‘/min/?g=site-js’ ) !== FALSE ) {
return “$url’ async id=’site-js”;
}
return $url;
}
add_filter( ‘clean_url’, ‘my_add_async’, 11, 1 );
[/php]

他にも非同期化できるスクリプトがあれば可能な限り async や defer を付けましょう。詳しくは「サイトに適したリソース配置とasync/defer完全マスター – レンダリング優先のグッド・プラクティス」を参考にしてください。

残ったリソースをプラグインで結合する

ここまでで結合していない or できない css、js は次のいずれかでしょう。

• 標準的な手法で登録されてはいるが、ページごとに異なるリソース
• wp_head や wp_footer などのアクション・フックをトリガーに直接埋め込まれたリソース

これらを Autoptimize で結合し、</body> 直前に配置します。

今回の例題では、「読み込みに先立って実行されるべきインライン・コード」への対応がキモです。そのままではインライン部分がファイルに結合され、</body> 直前へと持っていかれてしまいます。

これを防止するため Autoptimize の除外リストに、インライン・スクリプトに含まれる文字列 meteorslides を（ついでに googleapis や site-js も）設定します。

あるいは次のようにアクション・フィルタでも設定できます。詳しくは Autoptimize に同梱されている autoptimize_helper.php_example を参照して下さい。

[php]
/*
* Autoptimize filter: Exclude js files
* @see: /wp-content/plugins/autoptimize/autoptimize_helper.php_example
*/
function my_jsexclude( $exclude ) {
return “googleapis,site-js,meteorslides,” . $exclude;
}
add_filter( ‘autoptimize_filter_js_exclude’, ‘my_jsexclude’, 10, 1 );
[/php]

Autoptimize は、デフォルトで </body> 直前のスクリプトに defer 属性を付けてくれますが、他との依存関係がなければ、さらに async 属性も付けちゃいましょう！

[php]
/*
* Autoptimize filter: Add async attribute
* @see: /wp-content/plugins/autoptimize/autoptimize_helper.php_example
*/
function my_override_defer( $defer ) {
return $defer . “async “;
}
add_filter( ‘autoptimize_filter_js_defer’, ‘my_override_defer’, 10, 1 );
[/php]

初期のレンダリングを高速化する

Meteo Slides は、スライドショーのテンプレートや css、js を（子）テーマのディレクトリに放り込んでおくことで、元ファイルを修正せずにカスタマイズが可能です。

そこで、wp-content/plugins/meteor-slides/includes/meteor-slideshow.php を（子）テーマのディレクトリにコピーし、127行目付近の次のコードを改修します。

[php]
echo ‘<img style=”visibility: hidden;” class=”meteor-shim” src=”‘ . $meteor_shim[0] . ‘” alt=”” />’;
[/php]

上記コードでは、スクリプトが実行されるまで1枚目の画像が表示されません。「Above the fold のコンテンツは、可能な限りサーバーサイドで構築する」ために、「style="visibility: hidden;"」を削除しちゃいましょう！

以上で終了です。フ〜、お疲れ様でした 。

参考情報

• 2012年06月13日 WordPress：functions.phpでJSやCSSを一元管理する方法とバージョン表記を消す方法
• 2010年08月14日 Passing parameters from PHP to Javascripts in plugins
• 2011年08月03日 wp enqueue inline script due to dependancies
• 2012年05月10日 Should 3rd Parties Use $wp_scripts/$wp_styles->add_data?
• 2012年01月12日 How to add defer="defer" tag in plugin javascripts?
• 2012年06月14日 One, Two, or Three | CSS-Tricks

おまけ – Autoptimize を使いこなす

Autoptimize は、ページ中のすべてのインライン・コードや自サイトにホストされた外部リソースを1つのファイルに結合することを基本に、そこから問題のあったリソースを外していくというアプローチを元に設計されています。

そこで、トラブルを解消し、効果を最大限に引き出す Autoptimize の隠れた機能とオプションの使い方を紹介しておきます。

【 結合の対象外とするブロックの指定 】

<!--nooptimize--> ～ <!--/noptimize--> で囲んだコード・ブロックを、結合の対象外とします。

[html]
<!–noptimize–>
<script>alert( ‘this will not get autoptimized’ );</script>
<!–/noptimize–>
[/html]

【 Force JavaScript in </body>? 】

Autoptimize はデフォルトで、スクリプトの読み込みを </body> 直前に移動させます。JavaScript は HTML の最後で読み込むのがパフォーマンス上はベストですが、問題が生じる場合が多々あります。

このオプションを有効にすると、Autoptimize は <head> セクションにあるスクリプトをそのまま <head> にとどめます。特に jQuery ベースのテーマに有効なオプションです。

【 Look for scripts only in <head>? 】

jQuery ベースのテンプレートなど、大抵は上記と組み合わると効果を発揮するオプションで、<head> 内のスクリプトだけを結合対象とします。例えばサイトに共通なリソースが <head> セクションに集約されていれば、キャッシュ *  のサイズを適切に維持することができます。

* Autoptimize がサーバーに生成するキャッシュとブラウザ・キャッシュの両方を指します。詳しくは 作者のブログ記事 をご覧ください。

【 Exclude scripts from Autoptimize 】

結合対象外とするスクリプトを、そのブロックに含まれる文字列をカンマ区切りで指定します。例えば whatever.js, another.js などです。またカンマ前後の空白はトリムされます。

デフォルトの設定が必要なければ、空にしておきましょう。また先頭から順に処理されるので、追加は先頭に行うのが吉です。

【 Add try-catch wrapping 】

外部スクリプトの読み込みとインライン・スクリプトの実行順序が崩れると、エラーが発生する場合があります。このオプションを有効にすると、エラー発生時にも繰り返し実行を試みる try-catch ループでインライン・スクリプトを囲みます（同時にログをコンソールに出力）。JavaScript のエラーが発生する場合に試すべきオプションです。

【 Generate data:URIs for images 】

小さな背景画像を Data URI 化します。画像ファイルへの HTTP リクエストを削減する効果があります。

【 Look for styles only in <head>? 】

<head> セクション外にある CSS を結合の対象外とします。スタイル崩れが発生した時に、試してみるべきオプションです。

【 Defer CSS loading 】

CSS を遅延読み込みします。特にモバイル向けコンテンツは、「Above the fold」のレンダリングを優先させるため、必要最低限のスタイルをインラインで展開し、残りを後から読み込むのが良いとされます。

このオプションを有効にする場合、<head> セクションにインライン展開したスタイルを <!--noptimize--> ～ <!--/noptimize--> で囲む必要があります。

【 Inline all CSS? 】

ページ・ビューや訪問者の少ないサイトなら、CSS のインライン化が有効な場合もありますが、それ以外では、パフォーマンスを低下させるでしょう。このオプションは、CSS の遅延読み込みを無効にします。

【 Exclude CSS from Autoptimize 】

結合の対象外とする CSS を、そのブロックに含まれる文字列をカンマ区切りで指定します。スタイル崩れが発生した時に、試してみるべきオプションです。

注意事項 !!

本記事では全てを一気に設定する感じで説明しましたが、本来は少しずつグループ化するリソースを増やしながら動作確認をし、進めるべきです。

また提案したプロセスの最大の難点は、functions.php と groupsConfig.php の2つを同時に更新しなければならないことです。本番環境でこれら2つの更新に時間差が生じるとマズイことになるのは容易に想像がつきますよネ。

万全を期するなら、groupsConfig.php に登録するグループ名を site-js-0.1, site-js-0.2, … というように1ステップずつ刻んで追加していき、運用が安定したら整理するというやり方があるかと思います。

また少なくとも functions.php は、すぐに元に戻せるようバックアップしておきましょう。可能なら、テスト環境を準備するのが吉です 。

まとめ

サイト全体を通して共通するリソースとページに個別のリソースを分けて束ねることで、初回訪問時はもとより、ページ遷移時の表示速度をも向上させることができます。これは、直帰率を下げることにもつながると思います。

その際、すべてをプラグイン任せにせず、逆に手作業を主体とすることで、起こりがちなトラブルを回避し、また個々のプラグインに手を入れることなく css や js を結合する方法について述べました。

そもそも「どのリソースをどう束ねるか」にはヒトの高度な分析力が必要で、完全自動というワケにはいかないでしょう。ただし面倒なところにはツールを使って簡単化できることを提案したつもりです。

またプラグイン導入の際は、単に機能面だけじゃなく、高速化の観点で選定することも大事な Tips の1つだと思います。

「CloudFlare 導入、一発 OK！」も悪くはありませんが（そういうサービスですからネ）、自サイトのリソース削減に四苦八苦している人、サイト全体を通した最適化で更なる高みを目指したい人は、ぜひお試しあれ。必ず結果は出ると思いますョ。