ジェットパックプラグインは死活監視サービスがあるのか!

今回引越しをやっていて、気が付いたことがいくつかあります。その1つに、ジェットパックプラグインには、WEBがちゃんと動いているかどうかをチェックしてくれるサービスが無料でありました。

じゃんくはっく
じゃんくはっく

Jetpackプラグインって機能いっぱいあるな!

使い切れるのかしら?

ぴー
ぴー

とにかく、たくさん機能があるんですよね。最近は、このジェットパックに有料機能をつける戦略のようで、バックアップとかSEOとかあるようです。今回は無料の機能で死活監視機能がどんなものか試してみました。

サーバが動いてないとき

こんな表示のメールが届きます。

サーバが再び動き出したとき

こんな表示のメールがきます。

ログには?

ちょうどこの時は、何か作業していてWEBを止めていたんだと思います。ログには以下のように出力されていました。

192.0.101.226 - - [15/Sep/2020:00:46:13 +0900] "HEAD / HTTP/1.1" 403 0 "-" "jetmon/1.0 (Jetpack Site Uptime Monitor by WordPress.com)"
192.0.101.226 - - [15/Sep/2020:00:54:50 +0900] "HEAD / HTTP/1.1" 403 0 "-" "jetmon/1.0 (Jetpack Site Uptime Monitor by WordPress.com)"
192.0.101.226 - - [15/Sep/2020:01:02:42 +0900] "HEAD / HTTP/1.1" 302 0 "-" "jetmon/1.0 (Jetpack Site Uptime Monitor by WordPress.com)"
192.0.101.226 - - [15/Sep/2020:01:02:44 +0900] "HEAD /wp-admin/setup-config.php HTTP/1.1" 200 0 "-" "jetmon/1.0 (Jetpack Site Uptime Monitor by WordPress.com)"
192.0.101.226 - - [15/Sep/2020:01:11:53 +0900] "HEAD / HTTP/1.1" 200 0 "-" "jetmon/1.0 (Jetpack Site Uptime Monitor by WordPress.com)"
192.0.101.226 - - [15/Sep/2020:01:18:32 +0900] "HEAD / HTTP/1.1" 200 0 "-" "jetmon/1.0 (Jetpack Site Uptime Monitor by WordPress.com)"
192.0.101.226 - - [15/Sep/2020:01:26:37 +0900] "HEAD / HTTP/1.1" 200 0 "-" "jetmon/1.0 (Jetpack Site Uptime Monitor by WordPress.com)"

何をしていたのかは忘れましたが、ログを見るとおそらく、ジェットパッックプラグインの再セットアップでもやっていたのでしょう。

無料でやってくれるなら、使ってみてもいいかなと。現在は、とりあえずこの機能を使うかどうか検討中なので一旦停止しています。

他の無料の外部から監視するサービスは?

お仕事では、Mackerel(マカレル)というサービスを使っていますが、これ無料では監視ができないんですよね。

Mackerel(マカレル) 料金

https://mackerel.io/ja/pricing/

すごく使いやすくて、警告をLineとかに飛ばしたりできるんで重宝(迷惑かも?w)しています。

無料のこれ系のサービスは今まで調査したことがないので、この機会に少し調べてみようと思います。これ系の検索ワードは、日本語では、外形監視 無料 とか。英語だとなんていうんでしょうかね? APM (Application Performance Monitoring) とかかな?

なんとなく、良さそうなものをピックアップしてみます。

New Relic

https://newrelic.co.jp/pricing

Site24x7

https://www.site24x7.jp/url-monitoring.html

StatusCake

https://www.statuscake.com/pricing

Freshworks Inc.

https://www.freshworks.com/website-monitoring/pricing/

あとがき

比較表を今作る元気はないので、とりあえずメモしておきます。Site24x7とかは、スピードテストとかでお世話になったことがあり知っていますが他は知りませんでした。結構、無料でもやれるんですね。今度、どれか採用してレポートしたいなと思います。

このブログは、スマートフォンの中に引越ししました!

えっ? と思われた方もいるかもしれませんが、このジャンクハックブログは引越ししました。それもスマートフォンの中にいます!

なんで、引越しをしたの?

はい、結論から言いますと今まで使っていたWordPress.comのパーソナルプランの料金が上がったからです。月額400円から500円で年間一括6000円となります。まぁ、100円くらい良いんですがなんとなく、年間で6000円かーと思いましてね。

今から2年ほど前、 WordPress.com 上のパーソナルプランっていうところを使い始めていました。

Linuxエンジニアがサーバを作らず結局、WordPress.com の有料プランに入ることにしたよ

https://junkhack.gpl.jp/2018/10/17/20181017/

レンタルサーバはたくさんあるんですが、WordPressのオートマチック(Automattic Inc.)がやっているサービスです。ビジネスプランまで契約しようかと当初は思っていましたが、このブログがそんな人気が出るわけでもなくチマチマとパーソナルプラン(当初月額400円)でやっていました。

更新期限が10月中旬ということもあって、2、3ヵ月前から自宅サーバを検討していました。ご興味があるかたは、以下から検索してね。(検索システムも速くしてあります)

Termuxとか、自宅サーバ関連

https://hack.gpl.jp/?s=Termux+自宅サーバ

月に500円、年間6000円支払うなら電気代に払って自宅サーバでブログを楽しみたいな! と思ったのであります。

スマホの中に引越しとは?

 はい、このブログはスマホの中から今見ているみなさんに提供しているんです。信じられませんよね!w

これは、Termux というAndroidアプリがありまして、それがつまりは Linuxなんですよね。正確にいえば、Android自体がLinux Kernelを採用したOSなんで、その上でLinux環境を構築するアプリなんです。

で、その環境にWEBサーバやら、データベースサーバやらを作り、WordPressを動作させているんです。回線は、普通のNTTの光回線に InterLinkのIP固定サービスでやっております。いわゆる自宅サーバというやつですね。

あとがき

これで、Pluginもテーマファイルもやりたい放題です。

ぴー
ぴー

やっぱりWordPressはカスタマイズしたいよね!

とりあず、今日は引越ししたよ! というネタをあげたかったので以上にします。またねー。

スマホ上に作った自宅サーバのWordPressで、テスト評価がほぼオールAになった!

はい、ただ今引っ越し準備中でして、このブログをスマートフォン上に作ったWordPressサーバに引っ越しします。9月末か10月頭予定で各種チューニングをやっていましたが、ついにスピードテスト系の評価サイトでほぼオールAを取ることに成功しました。

いくつかある評価サイトの中では、ここが一番好きです。ここの計測サイトは東京リージョンもあり、また各種グラフが見やすくビデオプレビューまで付いて来ます。

WEBPAGETEST

https://www.webpagetest.org/

主な評価観点は、左から以下のようになっています。

  1. セキュリティ
  2. 初期アクセスまでの時間
  3. Keep-alive通信がONか?
  4. 圧縮転送されているか?
  5. イメージの圧縮はどうか?
  6. 静的コンテンツがキャッシュされているか?
  7. CDNを使っているか?

7番のCDNは一部、WordPressのをつかっていますが、全部は使っていないので、x になっています。これはどうするかまだ迷っています。一度、国内のCDNをテストで使ってみようと思ったのですがうまく動作せずでした。まだ原因がわかっていません。

 難易度的には、簡単なものから3・4・5・6・2・1・7で難しかったです。今回は、自分なりの考えをメモりつつ、1つづつ紹介していきたいなと思います。必ず正解っていう部分はないところでもあるので、あくまで自分はこんな対策と対応をしたよっていう感じです。いろいろツッコミどころはあるとは思いますが、何かあればコメントでお気軽にどうぞ。

難易度G・Keep-alive通信がONか?

これは apache を使おうが、nginx を使おうが最初からデフォルトONになっているので意識せずともAになると思います。今回は、最終的に nginx を使うことにしましたので、nginx.conf に以下を設定しています。タイムアウト時間は短いほうが良いと思います。でも、ここは突き詰めると難しい部分です。興味がある方は、以下などを一読されると良いかなと思います。

ぜんぶTIME_WAITのせいだ!

https://qiita.com/kuni-nakaji/items/c07004c7d9e5bb683bc2
http {
::(省略)
    keepalive_requests 100;
    keepalive_timeout  3;
::(省略)

termux 上の android OSでは、一般的なLinuxと違ってKernelパラメータも調整されているはずですので、ここが何が適切なのかを明確にするには root権限のあるスマホで termux を動かし負荷テストをしながら、各種TCPの状態遷移を見ていくのが正しい姿勢です。という意味では一番難しい部類ですが、今回はそこまで突っ込まないことにします。

難易度F・圧縮転送されているか?

圧縮レベルは1でも十分という意見はありそうです。

http {
::(省略)
    gzip  on;
    gzip_vary       on;
    gzip_proxied    any;
    gzip_comp_level 6;
    gzip_types      text/plain text/css text/xml text/javascript
                    application/json application/javascript application/x-javascript
                    application/xml application/rss+xml application/atom+xml
                    image/svg+xml;
::(省略)

難易度E・イメージの圧縮はどうか?

これは今回は、ジェットパックのプラグインでwordpress のCDN側から画像が出ています。そこで適切に圧縮してくれているので簡単です。ただ、やりだすと奥が深いので、中間くらいの位置付けにしてあります。

難易度D・静的コンテンツがキャッシュされているか?

これは、レスポンスヘッダにNo max-age または expiresをつければ解決します。具体的には、nginxの設定で以下を設定すればOKです。

location ~* \.(jpg|jpeg|gif|png|css|js|swf|ico|pdf|svg|eot|ttf|woff)$ {
    expires 60d;
    add_header Cache-Control "public, no-transform";
    access_log off;
}

難易度C・初期アクセスまでの時間

これは、WordPress側でキャッシュを作るのが一番最速です。各種プラグインがありますが、いろいろ試した結果、今の所はAutoptimizeに落ち着いています。

デフォルト設定でも十分効果はあります。迷ってる設定としては、Google フォントの削除 をするかしないかです。表示の綺麗さを取るか、お客様に快適にアクセスしてもらうのを取るか ですね。あとは、ネットワーク的な速度の部分があります。今は InterLink の回線上にいますが、少し工夫してある部分といえば、常時利用する経路とは分離してあるくらいでしょうか? WiFiの5G接続でもこのくらいは出ますよという参考値になればと思います。WiFiルーターの側にスマホ(サーバ)は置いてあります。距離を離すと応答速度が遅れます。

難易度B・セキュリティ

これが結構難しかったです。まず、WordPress の最新を使ってもjquery 1.12.4でした。これは脆弱性があるので、あげて置きたいところですが WordPressはIE8のことも考えて意図的に落としているようです(たぶん)。なので、以下プラグインで上書きしています。

しかし、これ以外もやることがあって以下のチェックサイトに行ったほうがわかりやすいかもしれません。各種セキュリー関連のhttpヘッダーを付与する必要があります。

https://securityheaders.com/

最初はここ、真っ赤でF判定だったです。

対策としては、NGINXの設定でヘッダに以下をつければA判定となりクリアになりますが、まだiFrameの設定が未完結です。X-Frame-Optionsは、古く Content-Security-Policy の指定で行うのが良さそうです。frame-ancestors を指定し組み込める参照元を制限する方法が良いということはわかっているのですが、まだ設定値が決まりません。A判定は取っていますが、内容がない状態です。

add_header Strict-Transport-Security "max-age=15552000"; 
add_header X-XSS-Protection "1; mode=block";
add_header X-Frame-Options SAMEORIGIN;
add_header X-Frame-Options "ALLOW-FROM https://www.youtube.com";
add_header X-Content-Type-Options nosniff;
add_header Content-Security-Policy "default-src * 'self' data: 'unsafe-inline' 'unsafe-eval' ;";
add_header Referrer-Policy strict-origin always;
add_header Permissions-Policy "fullscreen=() geolocation=()";

難易度A・CDNを使っているか?

ここは、DNSの向け先を変えたり、CDNのキャッシュをコントロールしたりする必要があり、運用とも関わる部分です。一度設定したのですが、うまく動作せずここは今の所一番の課題となっています。そもそも、月間5000ページビューにも行かないこのサイトでCDNを導入する必要があるかどうか? という点もありますが、一度やって見ないとわかりません。あと仕事ではなく、趣味なので無料のものしか使う気はありません。さて、どこがいいんでしょうかね?

あとがき

このサーバは、スマホで動いていてWiFiの無線で繋がっていますが、こんなちっさな筐体でもWordPressが動く、しかもA評価までもらえるなんて! 感動です。Termuxは最高のアプリですね。神アプリ認定です。

 しかも、常時SSL対応ですよ。もちろん、無料のSSL証明書です。なんだか時代は刻々と進化していますね。

スマホサーバの構成をNGINX+php-fpm+mariadbの構成にしてWordPressを動かして速度を計測しておいた

NGINXとphp-fpm構成にしてみました。いつもの計測サイトです。

夜間のネットワークが一番空いている時なんで、速い感じでしょうか?

GCP東京リージョンからの、apache ab は以下。182/sec 〜!速っ 78秒かかっていたテストが5.5秒。あ、これWordPressのキャッシュ効かせる前でしたね。apache構成でも同じ条件でサイド計測しておかないと。

$ ab -n 1000 -c 100 http://jh.gpl.jp/
::
Server Software:        nginx
Server Hostname:        jh.gpl.jp
Server Port:            80

Document Path:          /
Document Length:        15997 bytes

Concurrency Level:      100
Time taken for tests:   5.479 seconds
Complete requests:      1000
Failed requests:        0
Total transferred:      16202000 bytes
HTML transferred:       15997000 bytes
Requests per second:    182.52 [#/sec] (mean)
Time per request:       547.887 [ms] (mean)
Time per request:       5.479 [ms] (mean, across all concurrent requests)
Transfer rate:          2887.87 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       16   20   6.5     19     149
Processing:    57  487  82.1    480     747
Waiting:       39  467  82.0    460     724
Total:         88  507  82.5    501     783

Percentage of the requests served within a certain time (ms)
  50%    501
  66%    531
  75%    544
  80%    551
  90%    578
  95%    642
  98%    702
  99%    738
 100%    783 (longest request)

まだ、SSLとか設定はこれからでパラメータなども未調整です。設定値は以下のサイトを大いに参考にさせていただきました。

NginxでWordPressを使う時の設定をまとめてみた

あとは、SSL設定をtermuxでどうやるかですね。自動化したいので、どんな感じの仕組みが動くんでしょうか。

あ、それからRapid START CDNのフェイスブックチャットに応答があったんで、もう一度試してみるかもしれません。

 追記

やっぱりWEBフォント読まないほうが速いんで、Autoptimizeで試験的にカットしてみました。

読み込むものが少なくなれば、表示するのも速いですね。WEBフォントがなくなることで、多少文字の表示は意図したものと違うことになりますが、快適に読んでもらえるほうが良いと思うので、とりあえずはWEBフォントは外す方向で。

あと、モバイル向けのスコアがかなり変わりました。

まぁ、そのうち気が変わるかもしれませんが。

Termuxのapache2+php7+mariadb10 環境でwordpressの表示スコア

とりあえず、1つの指標としてメモしておくことにします。まず、改善結果から。データ量は、今見ているこのブログの過去記事、約400件のデータでテンプレートは、Hew です。TOPの表示記事数は3です。スマホ側は、UmidigiF2にapache2+php7+mariadb10の環境となります。ClassicPressではなく、WordPress最新5.5.1です。

WebPageTest_Test_Details_-_Tokyo___jh_gpl_jp__-_09_06_20_18_04_20

改善前は以下です。

WebPageTest_Test_Details_-_Tokyo___jh_gpl_jp__-_09_05_20_15_15_05

2.2秒くらいから、1.3秒くらいまで改善しました。これは、キャッシュ化の効果です。キャッシュさせるのは、何がいいのか迷いましたが一番シンプルそうな、「Simple Cache」というのを使いました。

プラグイン_‹_JunkHack_—_WordPress

Jetpack の全ての機能を試していませんが、とりあえずは動いている感じです。設定も以下のように単純です。手動でのキャッシュ削除は設定画面の2箇所から可能です。

シンプルキャッシュ‹JunkHack_—_WordPress

nginx_1.19.2 と、php-fpm_7.4.9 の組み合わせでも確認してみたいですね。

Termuxパッケージ安定板
https://grimler.se/termux-packages-24/arm/

nginxの1.19.2 はオフィシャル側は 2020/08/11 に公開していて、termux 側は、8/18 なんでちゃんとメンテナンスされているようです。

とりあえず、apacheのhttpd.confのパッチは以下です。apache 2.4.46 のデフォルト設定ファイルとの差分です。

--- httpd.conf.org	2020-08-09 07:55:34.000000000 +0900
+++ httpd.conf	2020-09-06 01:56:57.560924026 +0900
@@ -63,8 +63,8 @@
 # Example:
 # LoadModule foo_module modules/mod_foo.so
 #
-#LoadModule mpm_prefork_module libexec/apache2/mod_mpm_prefork.so
-LoadModule mpm_worker_module libexec/apache2/mod_mpm_worker.so
+LoadModule mpm_prefork_module libexec/apache2/mod_mpm_prefork.so
+#LoadModule mpm_worker_module libexec/apache2/mod_mpm_worker.so
 LoadModule authn_file_module libexec/apache2/mod_authn_file.so
 #LoadModule authn_dbm_module libexec/apache2/mod_authn_dbm.so
 #LoadModule authn_anon_module libexec/apache2/mod_authn_anon.so
@@ -88,7 +88,7 @@
 #LoadModule cache_module libexec/apache2/mod_cache.so
 #LoadModule cache_disk_module libexec/apache2/mod_cache_disk.so
 #LoadModule cache_socache_module libexec/apache2/mod_cache_socache.so
-#LoadModule socache_shmcb_module libexec/apache2/mod_socache_shmcb.so
+LoadModule socache_shmcb_module libexec/apache2/mod_socache_shmcb.so
 #LoadModule socache_dbm_module libexec/apache2/mod_socache_dbm.so
 #LoadModule socache_memcache_module libexec/apache2/mod_socache_memcache.so
 #LoadModule socache_redis_module libexec/apache2/mod_socache_redis.so
@@ -109,7 +109,7 @@
 #LoadModule substitute_module libexec/apache2/mod_substitute.so
 #LoadModule sed_module libexec/apache2/mod_sed.so
 #LoadModule charset_lite_module libexec/apache2/mod_charset_lite.so
-#LoadModule deflate_module libexec/apache2/mod_deflate.so
+LoadModule deflate_module libexec/apache2/mod_deflate.so
 LoadModule mime_module libexec/apache2/mod_mime.so
 LoadModule log_config_module libexec/apache2/mod_log_config.so
 #LoadModule log_debug_module libexec/apache2/mod_log_debug.so
@@ -144,7 +144,7 @@
 #LoadModule session_dbd_module libexec/apache2/mod_session_dbd.so
 LoadModule slotmem_shm_module libexec/apache2/mod_slotmem_shm.so
 #LoadModule slotmem_plain_module libexec/apache2/mod_slotmem_plain.so
-#LoadModule ssl_module libexec/apache2/mod_ssl.so
+LoadModule ssl_module libexec/apache2/mod_ssl.so
 #LoadModule dialup_module libexec/apache2/mod_dialup.so
 #LoadModule http2_module libexec/apache2/mod_http2.so
 #LoadModule lbmethod_byrequests_module libexec/apache2/mod_lbmethod_byrequests.so
@@ -168,7 +168,7 @@
 </IfModule>
 #LoadModule dav_fs_module libexec/apache2/mod_dav_fs.so
 #LoadModule dav_lock_module libexec/apache2/mod_dav_lock.so
-#LoadModule vhost_alias_module libexec/apache2/mod_vhost_alias.so
+LoadModule vhost_alias_module libexec/apache2/mod_vhost_alias.so
 LoadModule negotiation_module libexec/apache2/mod_negotiation.so
 LoadModule dir_module libexec/apache2/mod_dir.so
 #LoadModule imagemap_module libexec/apache2/mod_imagemap.so
@@ -176,7 +176,7 @@
 #LoadModule speling_module libexec/apache2/mod_speling.so
 LoadModule userdir_module libexec/apache2/mod_userdir.so
 LoadModule alias_module libexec/apache2/mod_alias.so
-#LoadModule rewrite_module libexec/apache2/mod_rewrite.so
+LoadModule rewrite_module libexec/apache2/mod_rewrite.so
 
 <IfModule unixd_module>
 #
@@ -242,8 +242,10 @@
 # documents. By default, all requests are taken from this directory, but
 # symbolic links and aliases may be used to point to other locations.
 #
-DocumentRoot "/data/data/com.termux/files/usr/share/apache2/default-site/htdocs"
-<Directory "/data/data/com.termux/files/usr/share/apache2/default-site/htdocs">
+#DocumentRoot "/data/data/com.termux/files/usr/share/apache2/default-site/htdocs"
+DocumentRoot "/data/data/com.termux/files/home/htdocs"
+#<Directory "/data/data/com.termux/files/usr/share/apache2/default-site/htdocs">
+<Directory "/data/data/com.termux/files/home/htdocs">
     #
     # Possible values for the Options directive are "None", "All",
     # or any combination of:
@@ -256,14 +258,14 @@
     # http://httpd.apache.org/docs/2.4/mod/core.html#options
     # for more information.
     #
-    Options Indexes FollowSymLinks
+    Options FollowSymLinks
 
     #
     # AllowOverride controls what directives may be placed in .htaccess files.
     # It can be "All", "None", or any combination of the keywords:
     #   AllowOverride FileInfo AuthConfig Limit
     #
-    AllowOverride None
+    AllowOverride All
 
     #
     # Controls who can get stuff from this server.
@@ -276,7 +278,7 @@
 # is requested.
 #
 <IfModule dir_module>
-    DirectoryIndex index.html
+    DirectoryIndex index.php index.html
 </IfModule>
 
 #
@@ -529,3 +531,22 @@
 SSLRandomSeed connect builtin
 </IfModule>
 
+LoadModule php7_module libexec/apache2/libphp7.so
+<FilesMatch \.php$>
+   SetHandler application/x-httpd-php
+</FilesMatch>
+<IfModule dir_module>
+    DirectoryIndex index.php
+</IfModule>
+
+<IfModule mod_deflate.c>
+    DeflateCompressionLevel 1
+    <IfModule mod_filter.c>
+        FilterDeclare COMPRESS
+        FilterProvider COMPRESS DEFLATE "%{CONTENT_TYPE} =~ m#^text/#i"
+        FilterProvider COMPRESS DEFLATE "%{CONTENT_TYPE} =~ m#^application/(atom\+xml|javascript|json|rss\+xml|xml|xhtml\+xml)#i"
+        FilterProvider COMPRESS DEFLATE "%{CONTENT_TYPE} =~ m#^image/(svg\+xml|vnd\.microsoft\.icon)#i"
+        FilterChain COMPRESS
+        FilterProtocol COMPRESS DEFLATE change=yes;byteranges=no
+    </IfModule>
+</IfModule>

パッチの適用は上記をコピペしてp.txt などに保存、httpd.conf に以下のように patchしてください。

$ patch -u httpd.conf < p.txt

成功すれば、patching file httpd.conf のような表示となります。

mariadb のチューニングとかはやってないです。PHPは、php.ini  に以下のように記載してあります。

$ cat /data/data/com.termux/files/usr/lib/php.ini
[PHP]

upload_max_filesize = 64M
post_max_size = 64M
memory_limit = 64M

結構、スマホでも動くなー、いけそうだなーっていう感じです。

 

 

Rapid START CDNは諦めてJetpackプラグインのWordPressが提供しているCDNを使ってどうなるか検討してみる

結局、Rapid START CDNは登録したけどもうまく反映できず、諦めました。手順通りにやっても、CNAMEを切り替え後に Error 503 Backend Error になるんですよね。結局、フェイスブックの問い合わせにもお返事がなかったので原因を追求することが難しくなりました。

 ということで、CDNはとりあえず諦めようかなと思いますが、Jetpack をまだ入れて試していませんでした。Jetpackには、ワードプレスが提供しているCDNが使えるようになります。説明は以下にあります。

Site Accelerator

JetpackのSite Acceleratorは、Jetpackが画像を最適化し、サーバーのグローバルネットワークから画像と静的ファイル(CSSやJavaScriptなど)を提供できるようにすることで、ページの読み込みを高速化します。

あと、Jetpackを入れるメリットとしては、WordPressのローカルアプリで、Macから投稿するときのブログ投稿ツールが使えるようになります。最近はこれを使っていたので、今後もこれを使おうとする場合は、Jetpackを入れないとだめなようです。

まぁ、違う投稿ツールを使えばいいんですが、慣れているんでこっちで出来れば良いかなと。CDNも使えるしね。

以前検討した時は、Jetpackを入れると遅くなるっていうことがわかり外しましたが、あれはネット回線もサーバマシンも高速であったため、CDN使わなくても速かったからです。今度は、スマホサーバで動かしているし、回線もIPv4を使っているので、以前より速くありません。ちなみに、今はInterLink の PPoEのIP1固定を検討中で使っています。これは逆引きドメインを設定できるので良いなーと。またそれは別に紹介するとします。

 ではJetpackを入れてみましょう。しかし、ClassicPressでは動作しないので、WordPress最新を入れる必要があります。面倒ですが入れ直して、Jetpackプラグイン設定。一応、同条件で計測しておきました。

・Jetpackを入れる前のWordPress

・Jetpackを導入直後のWordPress

囲ってある部分が、Jetpackで変化があった部分ですが、レンダリング開始秒までは、Jetpack使用後もさほど代わりがありません。まだこの時は、最初のindex相当の部分は、CDN上ではないようです。JetpackでCDNになるのは、WordPress 共通で使うjquery.jsだったりの部分です。
※追記 ファーストアクセスの部分(上記でいえば、index相当の部分)は仕組み上CDNからのアクセスにはならないと思います。

設定はこのようにしています。もうちょっと様子見してみますか。あー、なんで画像が計測結果に出てないかわかりました!

上記2つの計測結果には、画像がまだエリア内に表示されていないので表示されなかったみたいです。

違うページを計測してみたら、以下のように画像URLが変わっていました。

https://i0.wp.com/jh.gpl.jp/wp-content/uploads/2020/08/e8b2bce3828ae4bb98e38191e3819fe794bbe5838f_2020_08_24_1_04.png?resize=496%2C1080

あーなるほどね。とりあえず、Jetpack入れて様子見してみます。

WPのcdnから配信された画像データと、オリジナルのファイルサイズを比較してみると以下のように半分くらいになっています。

$ ll
::
-rw-r--r--@  1 junkhack  staff  776994  9  5 21:20 org.png
-rw-r--r--@  1 junkhack  staff  281594  9  5 21:19 wpcdn.png

綺麗な画像で見せたい場合は、CDNから配信しないのがいいですね。ここで見せる画像なんかは、特にこだわりはないので問題ありませんが。