まず結論から行くとまだうまく行っていません。ハマりどころがあるんで、まずそれを記録しておくことにします。きっと、誰かの役にたつかもです。

ハマりどころ１

サブドメインで、一文字は登録できません。例えば、以下のようなサブドメインは、登録しようとするとエラーが出ます。

j.gpl.jp

２文字以上はOKです。１文字はサブドメインとしては問題なくちゃんとアクセスも出来るし通常のDNSにも登録できます。Rapid START CDN側の問題というか制約でしょう。

汎用JPドメインの第２レベルは、３文字以上しか登録できませんが、第３レベル（今回でいうjの部分）はドメイン運用者が自由に決めらます。文字種は限りがあります。英字(A～Z)、数字(0～9)、 ハイフン( – )が使用できます(先頭と末尾の文字をハイフンとするのは不可)

では、２文字でやって見ましょう。Good Gameの略でgg.gpl.jpということにしましょうか。Gが多すぎて見にくいですがね。まぁテストなんで良しとしましょう。DNS登録して、digなどで引いてみましょう。TTLは60秒と短くしてあります。

# dig gg.gpl.jp
::
;; ANSWER SECTION:
gg.gpl.jp. 60 IN A 116.58.181.140
::

では、RapidStartのCDNコンパネで登録してみましょう。

はい、できました！次は、オリジンサーバのAレコードをDNSに登録します。
origin.gg.gpl.jp
というAレコードです。こんな感じで引ければOKです。

# dig origin.gg.gpl.jp
::
;; ANSWER SECTION:
origin.gg.gpl.jp.	60	IN	A	116.58.181.140
::

次はドメイン所有確認のため、長いドメイン部のテキストレコードをDNSに設定しておきます。

以下のように確認しておきます。

$ dig -t TXT xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.jh.gpl.jp
::
;; ANSWER SECTION:
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.jh.gpl.jp. 60 IN TXT "redbox-cdn-verification=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
::

所有確認が出来れば、ステータスがOKになります。コンパネの設定から、WordPress のキャッシュポリシーにしておきます。

あとは、動作確認のためhostsファイルを書き換えて確認せよとありますのでやってみます。

$ cat /etc/hosts
#::
127.0.0.1	localhost
255.255.255.255	broadcasthost
::1             localhost

160.16.92.179 gg.gpl.jp

これでブラウザーから　http://gg.gpl.jp/　へアクセスしてみます。

さて、何がだめなんでしょうかね？　どなたかわかる方いらっしゃいましたらコメントください。一応、RapidStartのフェイスブックのチャットで聞いているんですが、まだ回答がありません。

ちなみに、このテストがOKであれば、該当Aレコードをcnameに書き換えます。が、このままでは同じ結果になるのでCNAME書き換えてもだめです。

この　free.rs.cdnw.net のIPは引いてみると以下です。

$ dig free.rs.cdnw.net
::（略）
;; ANSWER SECTION:
free.rs.cdnw.net.	29	IN	A	59.106.219.219

59.106.219.219 なんですが、160.16.92.179　からでも同じホストへアクセスできるのでしょうかね。ちょっと相手側構成はわかりませんが、そのように指示があるので経路が違うだけなんでしょう。

一応、試したことは以下ですが、同じ結果です。

・コンパネからキャッシュの全削除
　→　上のほうに失敗の文字がでているんですが消せてるんでしょうかね。

・同じことをもう一度、違うサブドメインで登録
　→　最初、jh.gpl.jp で登録し、今回 gg.gpl.jp でやってみたがだめ。

今回はサブドメインでの運用を想定していて、大まかな流れは以下のようになります。

①名前解決で同じサーバに向ける
DNS周り、またはhosts で以下ドメインを１つのサーバに向けるよう設定します。
または、ワイルドカード DNS の設定をします。今回はローカルで以下のようにHOSTSをいじりました。
例：gpl.jp → 127.0.0.1
www.gpl.jp → 127.0.0.1
hoge.gpl.jp → 127.0.0.1
hack.gpl.jp → 127.0.0.1

②WEBの設定で、*.gpl.jp を同じWEBROOTを見に行くよう設定

③WEBROOTにClassicPressを展開
→wp-config.php のDB設定
DBはもう作ってあるものとします。

④WEBアクセスしてClassicPressをインストール
→　普通にウィザードに沿ってインストールするだけです。

⑤wp-config.php へ設定を記載
define(‘WP_ALLOW_MULTISITE’, true);

⑥管理画面へログインし、サイトネットワークの設定　へ
→ サブドメイン型でインストール

⑦インストール完了すると以下のように指示が出てきます。
wp-config.php と .htaccessへ指示通りに記載

————- wp-config.php

define(‘MULTISITE’, true);
define(‘SUBDOMAIN_INSTALL’, true);
define(‘DOMAIN_CURRENT_SITE’, ‘gpl.jp’);
define(‘PATH_CURRENT_SITE’, ‘/’);
define(‘SITE_ID_CURRENT_SITE’, 1);
define(‘BLOG_ID_CURRENT_SITE’, 1);

————- .htaccess

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ – [L]

# add a trailing slash to /wp-admin
RewriteRule ^wp-admin$ wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ – [L]
RewriteRule ^(wp-(content|admin|includes).*) $1 [L]
RewriteRule ^(.*\.php)$ $1 [L]
RewriteRule . index.php [L]

⑧再度、ログオフ、ログインしてサイトネットワーク管理の管理画面にアクセス
→ 設定＞サイトネットワークの設定　から各種設定
→ 管理メニューを有効化（プラグイン）

以上で、OK。新規サイトを追加する場合は以下。

①サイトネットワーク管理　から追加
サイト＞新規追加

以上で、複数のClassicPressサイトが出来上がり。基本WordPressと同じですね。

マルチサイトの運用はいろいろ勘所がいると思いますので不定期に何か気がついたら書いていくことにします。管理系のプラグインは便利そうなのが出ているので何か見繕って使っていくと思います。

https://ja.wordpress.org/plugins/search/Multisite/

次回は、とりあえずローカルのMAMP環境で以下をやってみたいと思います。

・MAMP Pro 環境でLet’s Encryt のワイルドカードSSLを設定

うまくできるかな？

自宅サーバになったら、AdSense もやってみたいなと思って登録しようと思いました。

Google AdSense
https://www.google.com/adsense/

が、登録中、以下のようになります。

マニュアルによれば、サイトの追加からできるようですが、これをやるにはまずメインのドメインを追加して認証させないとだめみたいです。

サイトリストでサブドメインを追加または削除する
https://support.google.com/adsense/answer/9130110?hl=ja

メインのドメインっていうと、gpl.jp や www.gpl.jp というものですがこれはとりあえず運用していません。しかし、とりあえずサイトを起動させておかないと許可が降りないのかな？　ま、そういうのはやってみればわかりますね。やってみましょう！

次のステップでは、マルチサイト機能を使ってメインドメインを動作させてみようと思います。ClassicPress でもできるはずですので動作確認も兼ねてみましょう。あと、ローカルの MAMP Pro 環境で Let’s Encrytの SSL をワイルドカードで出来るかやってみようと思います。

・ClassicPress で マルチサイトを立ち上げる

・MAMP Pro 環境でLet’s Encryt のワイルドカードSSLを設定

とりあえず、このようなネタをあげる予定です。

はい、2.2秒かかっていたようです。レポートには、いろいろ書いてありますが画像の項目は以下のようにアドバイスされていました。

次世代フォーマットで画像を配信する
JPEG 2000、JPEG XR、WebP で画像をエンコードすると、読み込み時間が短くなり、モバ
イル通信のデータ量も少なくすることができます。フォールバック用に PNG 画像や JPEG 画
像も用意し、未対応ブラウザにはそちらを配信するようにしましょう。

ということで、WebP に変換することことにしました。変換には方向性として２つあり、１つはクラウドサービスでWebPに変換してもらうのを利用する方法。もう１つは、自サーバの機能を使ってWebP に変換する方法です。後者は、PHPがimagemagic をサポートしていてそのフォーマットにWebP がある場合に有効です。

phpinfo.phpにアクセス　→ サーバー設定のレポートを見る。
「imagick」項目の “ImageMagick supported formats” という行に「webp」があればサポートしています。

現在はまだテストサーバで mamp でやっていますので、これはサポートしていないことがわかりました。自分でサーバを作るときは対応させる予定ですが、今のところは外部クラウドのWEBサービスを使って高速化がどのくらい進むか確認してみようと思います。

パッと思いつくのは、https://tinypng.com/ のサービスです。

これをWordPress（ClassicPressでも利用可）で利用するPlugin があるので使うことにします。

Compress JPEG & PNG images
https://ja.wordpress.org/plugins/tiny-compress-images/

Plugin を有効にして、API をゲット（月に500まで利用可）です。メディア設定の自動リサイズを無効にして、medium_large_size_h のパラメータも以下から0 にしておきます。

https://yourdomain/wp-admin/options.php

設定は以下のようにしておきました。

どのくらい高速化が進んだか確認してみましょう！

結果、1.7秒です。0.5秒改善しましたね！

あとついでなので、Autoptimize プラグンで JS と CSS の最適化をしておきました。これは有名なんで説明は省略。

Autoptimize
https://ja.wordpress.org/plugins/autoptimize/

結果、高速化その３では最終的に、1.2 秒にまで改善できました。

あと、0.3秒ほど頑張れば１秒以下になって「速い」の部類に入るかと！　あとはサーバ側でがんばりましょうか。

・・・高速化その４　に続く

enひかりの IPv6 トンネルもかなり有効だと思いますが、なかなか良いスコアが出たので記録しておきます。ちにみに、純粋なClassicPress にした速度向上というのはわずかです。テーマの部分が大きいかなという印象です。

Google の PageSpeed Insights の結果です。ずっと99% であと1% が上がらなかったのですが、画像の遅延読み込み（※1）を行なったら100% になりました。現在のWordPress.com 上にあるデータと変わりないのに、テーマとかWordPress 本体を ClassicPress にして enひかりの v6ひかり＋固定IPの環境にしただけです。 １秒未満なので、とりあえずは十分な結果がPCは出ていますね。ちなみに、開発環境は以下の通り。

WEB：NGINX1.13.2（MAMP Pro）
PHP：php7.4.1（MAMP Pro）
DB：MySQL 5.7.26（MAMP Pro）

Server CPU：AMD Ryzen 5 3600
RAM：32GB
DISK：SSD

CMS：ClassicPress 1.1.2
テーマ：Sustyバージョン: 1.0.0
WP Plugin：
　Akismet Anti-Spam 4.1.4
　AMP 1.4.4
　Broken Link Checker 1.11.11
　Catch Infinite Scroll 1.7
　Lazy Load 0.6.1
　Switch to ClassicPress 1.2.0
　WordPress インポートツール 0.7
　WP Super Cache 1.7.1

　※1・・・画像の遅延読み込みとは、ブラウザが最初に「スクロールせずに見える」ページの画像のみを表示し、スクロールしたときに画像を読み込むということです。これらを簡単に実現するため、Lazy Loadを使っていますがやり方はいろいろあるようです。

モバイル環境については、まだ向上の余地がありそうです。JS の調整がまだ残っています。

ClassicPress は、wordpress5.3.2 から switch-to-classicpress プラグインを入れて行いましたがなんのトラブルもなくできました。ClassicPress にして明確になったのが、jetpackプラグインはない方が絶対的に速いです。また、ストレージ容量が ClassicPress は20MB くらい減りファイル数も300くらい減りました。

今の所、可もなく不可もなくといったところでしょうか？　しかし、良いなと思うのは ClassicPressバージョン1.xは、長期サポート（LTS）バージョンということで安定して動作してくれそうな気がします。プラグインも同じようにインストールすることができて、動作するものは「Compatible with your version of ClassicPress」と表示されますので目安になりますね。

というわけで、方針としては ClassicPress を使っていくことにしました。そして、jetpackプラグインはもう使わないことにします。テーマは、Sustyをカスタマイズして使うことにします。