KUSNAGIのプレミアムエディションにあるWEXAL® Page Speed Technologyはすばらしい機能なんですが、自分の環境には合わず泣く泣く止めたという話です。
KUSANAGI推奨環境以下でやってる稀なパターンです。この点はご了承ください。
KUSANAGIのWEXALとは何か？
KUSANAGIは、ウェブサイトのサーバー側の環境を効率化して高速化した仮想マシンです。
最上位グレードはPremium Edition（以降PE）で、PEには唯一、WEXAL® Page Speed Technology（以降WEXAL）という機能が使えます。
この最上位グレードは法人が使うときは有料ライセンスが必要なんですが、個人利用は無償のライセンス（パーソナルライセンス）が用意されています。
WEXALとは何か？
WEXALは、KUSANAGIを開発した会社（Prime Strategy）が開発したもので、これもウェブサイトの高速化の技術です。
ざっくり言うと、KUSANAGIが作ったサイトページのレンスポンスを、ユーザーに返すのではなくWEXALが受け取り、ここでHTMLのレンダリングをしてキャッシュしておきます。ページはキャッシュで表示します。
KUSANAGIのWordPressとユーザーのブラウザの間にあるもの。
ここからは個人の見解ですが、OSのプロセスを見るとNode.jsが常駐起動し、サイトにアクセスするとchromeというプロセスが起動します。
このchromeはブラウザのレンダリング機能をサーバー側でできるようにするソフトウェア。
ブラウザの機能をサーバーに移植したもの。
中身はSSR（Server Side Rendering）？
SSRを知っている人はピンとくるでしょう。まさしくWEXALはKUSANAGIをSSRにするものです。
そのほか、画像をwebpに変換するなどいろいろなサイト高速化の施策が行われています。
WEXALはほかに、レンダリングや画像、KUSANAGIを構成するWebサーバーやDBをAIを使って最適化します。自分で設定を変更することもできますが、基本的にはAIに任せたほうが良い。
（AIが環境に合わせて設定ファイルを書き換える。）
やっぱりサーバースペックが必要か？
WEXALを止めたのはサーバースペックが耐えられないから。
レンダリングが始まるとCPUが当たり前のように90%超えを連発します。サイトアクセスが同時に10アクセスくらいがつづくと、CPU負荷が下がらない。
結局、1日に4, 5回はCPUがパンパンになりました。サーバーがいつ落ちるかドキドキもの。
WEXALを止めるとCPU負荷が落ち着き、つねに20%弱以下になりました。
KUSANAGIの推奨メモリは4Gなのに半分の2Gでやってるのがおかしいんでしょう。ダメ元でやってやっぱりダメだったという当たり前のオチ。
レンダリングがCPUを掴むと何が起きるか？
CPUの負荷が高いと、いろいろとイラッとすることが起きます。
サイトの表示が遅い。
WordPressの管理画面は絶望的。（更新・保存に時間がかかる。）
プレビューがなかなか開かない。
せっかくWEXALという良いものがあっても、イラッとしたら意味がないですからね？
WEXALを止めたら元に戻りました。
AMPは使えない！
サーバースペックがパンパンになるよりもこっちのほうが大事です。
AMPは未対応です。
| WEXALが起こすエラー | AMPの仕様 |
|---|---|
| カスタムJavaScriptを挿入する。 | JavaScriptの使用禁止。 （一部を除き。） カスタムに例外はない。 |
| カスタムCSSを挿入する。 | 一部のプロバイダを除き、外部CSSの禁止。 カスタムCSSはインラインだけOK。 |
| AMP専用のHTMLタグを使っていない。 | 使えないHTMLがあり、AMP専用タグ に変える必要がある。 |
AMPでエラーを出すと、AMPページがGoogleの検索結果から消されます。急にスマホのPVが激下がりしたのでモチベーションが下がりました。
これがWEXALの即停止の一番の理由です。
ただ設定の中身を見ると、初期設定がAMPに対応してないだけで、やりようによってはイケるような気もするので、やってみる価値はあります。
（検証には時間がかかりそう。）
AMPの優位性が若干低下
Googleはモバイル検索のトップニュースにAMPのページだけを表示するように優位性を与えていたのですが、2021年6月の中ごろ以降、非AMPページもトップニュースに掲載するようになりました。
AMPか非AMPかではなく、コンテンツの内容重視（Googleのポリシーに合っているか？）、コアウェブバイタルという指標で評価します。
これからのサイトでは『速く表示するならAMP』ではなく、『速く表示する手段のひとつのAMP』になり必須ではなくなるということ。
非AMPのWEXALでAMPと競合できるパフォーマンスを発揮できるのならAMPはいりません。
この先どうなるか分かりませんが、AMPはいらないから気にしないという判断もあると思う。
WordPressの統計情報がぐちゃぐちゃになる
もうひとつ止めた理由は、WordPressをベースに有名なサービスを提供しているAutomatticが作っているプラグイン、JetpackのPV数（ページビュー）が異常に爆上がりして使い物になりません。
ふだんはサイトのトップページが1日30PVくらいなのに10倍くらいに跳ね上がる。そのほかのページも割増感がある。
個人の見解ですが、WEXALのレンダリング作業のたびに内部で大量にサイトアクセスが発生しているもよう。
このへんは設定でどうにかできそうですが、レンダリングやキャッシュの削除の頻度を落とすと、これまたサイトのパフォーマンスに影響します。
WEXALを止めたらこの不満も無くなったのでとりあえず保留。結局、無償版と大して変わらなくなったんじゃないだろうか？
WEXALの止め方
肝心のWEXALの設定を変える方法を紹介するの忘れてました。WEXALはpstコマンドで操作します。
cd /home/kusanagi/kusanagi_htmlpstコマンドは、KUSANAGIの初期設定で作られるプロビジョニングのディレクトリ下でないと使えません。
pst offpst status
WEXAL Page Speed Technology = off
1476 inotifywait
1472 watch
0 queueWEXAL Page Speed Technologyがoffになってれば停止しています。あとキューが0になってることも確認して下さい。
監視プロセス（watch）はonになっていますが、WEXAL全体を止めているのでそのままでいいです。
