GeneratePress × KUSANAGIで、AIこき使って「全部燃やした。」　～PSIオール100までの道程

本サイト「きもおた・わーどぷれす。」のリニューアルをしました。
GeneratePressとKUSANAGIでサイト構築して、PageSpeed Insights（PSI）オール100を獲りました。

リニューアルにおいては、

不要なものをとにかく削ぎ落としました。
徹底して軽くした結果、最高のスコアがついてきました。

ChatGPTの描いてくれた密度の濃いメインビジュアルを設置し。
UIにこだわり、インタラクションを随所にしかけ。
速度とデザインを両立させた満足のいく仕上がりとなりました。

いわゆる「引き算の美学」。
私は何を考え、どういうスタンスでリニューアルにのぞんだのか。
本稿では語ってみたいと思います。

動作環境

サーバー：ConoHa VPS（KUSANAGI Nginx） メモリ2GBプラン
OS：AlmaLinux OS 9

セッティングの労力を要する代わりに、使いこなせばWordPressを高速で動かすことができます。

サイトリニューアルを図った理由

今春、WEBディレクターとしてサイト制作業界にデビューしました。
プロを名乗る身となった以上、「素人の備忘録」という当サイトのキャッチフレーズから卒業しなくてはならない。
長らく放置していたテックブログを自らの名刺にふさわしいサイトへ作り変えることにしました。

ただし、私がやるのではありません。
AIという名の執事をこき使います。

WEXALは既に燃えていた

KUSANAGIにはプレミアムバージョンとしてWEXALがあります。

例えるなら、高性能な Autoptimize + EWWW Image Optimizer のようなもの。
KUSANAGIに限らず、ConoHa WING やお名前.com レンタルサーバーでも利用できます。

導入して動かすだけで、WordPress周りの最適化を比較的手軽に進められるため、以前はかなり重宝していました。
当時の話はこちらです。

ただ、難点がありまして。

上記の記事を書いた頃は、メモリ2GBでも普通に動いていました。
ところが昨年春頃から、原因を断定できないもののサーバーが繰り返しダウンするようになります。
WEXALが一因かもと見て外してみたところ、以降は発生しなくなりました。
私の環境における見立てとしては大きく外れていなかったものと思っています。

その後は、キャッシュ以外の高速化施策をほぼ放置しています。

いえ、正確には何もしていなかったわけではありません。
手始めにjQueryをフッターへ移動させてみました。
その際、何かしらの不具合が発生し、どこかが動かなくなったんです。
具体的に何が影響を受けたかは思い出せないのですが、ともかくサイトの安定を優先させることにしました。

サイト高速化はUXの追求に他ならない

しかし今回、リニューアルをすることになり、重い腰を上げました。

お仕事では上流工程を担当していますが、当サイトのコンテンツは中流・下流工程の話がメインです。
高速化もその範疇ですから、一見すると私の守備範囲ではないようにも見えます。
デザインだけ整えれば、それなりに面目は立つようにも見えます。

しかし、

サイト高速化はSEOの文脈で語られることが多いです。
検索順位を上げるためにはサイトを速くしなくてはならない。
昔は至上命題でしたし、今でもある程度までは真実です。

ただ、現在はコンテンツファーストです。
サイトを取り巻く環境全般も向上し、以前ほど極端に高速化へこだわる必要は薄れました。
だからこそ私は、これまで放置を決め込んでいたわけです。

しかし、そもそもの話として。

来てくれた訪問者が快適に閲覧できるよう、サイト速度をできる限り高める。
この思想もまた、WEBディレクターの仕事のうちではないのか。
たとえコスパが悪くても、できることはとことんやる。
それが心を尽くすということではないのか。

特殊な考えなのは自認していますし、他人に押しつけるつもりもありません。
ですが、私がそう思うのだからしかたありません。

プロの名に賭けて、引くに引けない戦いが始まりました。

Cocoonを燃やした

高速化を図るにあたって、障害となったのがCocoonでした。

誤解のないように書くと、Cocoonをくさしたいわけではありません。
むしろ逆で、とても重宝してきました。
プラグインを入れるまでもなく、ありとあらゆる機能が入っています。
吹き出し、広告ユニット、ブログカード、SEO、高速化。
エディタにも最初からさまざまな装飾が入っています。
これひとつでかなりのことが完結してしまう強さがありました。

しかし、

ありとあらゆる機能が入っているということは、そのぶん読み込むものも増えるということです。
必然的に重くなります。

使わないCSSも大量に読み込みます。
言うまでもなくムダです。

さらにCocoonは、機能追加を重ねてきただけにコードも入り組んでいます。
WEXALでCocoonを使うならAIが調整してくれるからいいのですが。
自力でカスタマイズやチューニングするには、ちょっと私の手には余る印象でした。

何かもっとシンプルなテーマを探そう。
機能は後から自分でコードを組めばいい。
CSSも自分で書けばいい。
そのほうが軽量化を図れるし、読み込みの制御もしやすくなる。

……決断しました。

GeneratePressという名の薪を新たにくべた

Cocoonを燃やすと決めたはいいものの、何を使うか
国産テーマの有名どころは多機能な上にほとんど有料。
多機能テーマを選ぶならCocoonを燃やす意味ありませんし。
仕事ならともかく、プライベートなサイトでテーマにお金払いたくありません。

Gemini執事。

ふむふむ。
KUSANAGIがF1マシンのエンジンならGeneratePressはシャーシにあたるっぽい。
しかもニッチ向けで、しかも海外テーマで、日本ではあまり広まっていない。
マイナーアイテム特有の「ちょっと外した特別感」が私の厨二心をくすぐってくる。

海外テーマながら、日本語も使える。
高校時代に英語の偏差値25を記録した私としては大変ありがたい。

そして私の一番の関心事。

GenerateBlocks ProはLightningのVK All in One Expansion Unit（ExUnit、統合プラグイン）みたいなものらしい。
だったらそんなのいらない。
機能は自分で組み上げるのが前提のテーマ乗り換えですから。

よし、決めた！

ちなみに、軽量な国産テーマとしてArkheも候補にありました。
ただ今回は日本向けの扱いやすさより、よりシンプルな土台と高速化の詰めやすさを優先してGeneratePressを選びました。

関連記事などを燃やして、新しい種を蒔き直した

KUSANAGI+GeneratePressという高速化の土壌はできました。
続いては、サイト設計の見直しです。

例えば関連記事や人気記事。
ブログにはあって当たり前の項目であり、基本機能です。

しかし、私は疑問に思いました。

関連記事はどういう分類方法をとったとしても、並べて記事がその人に刺さるとは限らない。
人気記事はなおのこと。他の人に人気であっても今読んでいる人に刺さるとは限らない。

あくまで私の考えにすぎませんが、

特に当サイトはテックブログ。
訪問者の特質としてネットリテラシーが強い傾向があります。
だったら、

その代わり、検索したくなったらすぐに探せるように画面右下へ検索ボタンを配置。
サイドバーにも検索バーを配置。
とどめに、MV直下に巨大検索バーを設置しました。

さらにタグでグルーピング。
狙ったトピックの記事を探しやすいような導線を確保しました。

燃やした灰から自作統合プラグインという花を咲かせた

しかし何も足さないわけにはいきません。
Cocoonを外したことでなくなった機能の中から必要なものを復旧します。

Cocoonの設定画面から必要な機能をメモします。
先程も挙げた吹き出しとか広告カードとかSEO機能とか。
そして、片っ端から、

 

新しくコードを書かせまくります。
実際に動かして検証して。
完成したものは自作の「GP統合プラグイン」で読み込ませます。

また、前項と同じく、既存のもので活用できるものは活用しました。
例えばブログカードはWordPressの埋め込み（oEmbed）を流用してCSSで整えました。

そんなこんなでCocoonで使っていた機能のうち、必要なものは全て実装できました。
もし自分でコーディングしてたら果たしてどれだけの時間を要したことか。

PHPだけじゃなくCSSやJSも同じ。
最低限のものだけを組み込むことで、一気に読み込みを減らせました。

これらは全て非同期読み込み、あるいはスクロールで発火させて読み込みを遅らせるなどの施策で対処します。
その結果、ただ軽くなっただけでなくレンダリングブロックもほぼ解消できました。

プラグインを燃やした

さらにプラグインの見直しにかかります。

• Site Kit by Google
  便利に使ってましたけど重いのでアンインストール。当日のデータは軽量アクセス解析のGoAccessで見るようにしました。
• Wordfence Security
  ずっと実用できずにいたKUSANAGIのWAFを攻略し、外すことができました。
• Cookie Notice & Compliance for GDPR / CCPA
  国内向けはバナーを自作。EU諸国などはGeoIPでアクセスを遮断しました。

Gemini君によると、アクセス遮断も高速化に間接的な効果があるとか。

とのことだそうです。

画像を燃やした

最後に画像。
当サイトではMVに超高密度のイラスト画像を置いています。
WebPですらサイズを下げきれず、サイト速度の足をかなり引っ張っていました。

一旦はAVIFへの切り替えも試しました。
しかしKUSANAGI側のImageMagick（imagick）のバージョンが古いせいで、運用面の問題が出ます。
手動でバージョンを上げても、KUSANAGIアップデート時に巻き戻される可能性が高い。
サイト速度のために運用面で問題を抱えるのは本末転倒なのでAVIFは止めました。

だったら、

これで一気に改善しました。

燃やして種を蒔いて灰を撒いて花を咲かせて、得られた果実

以上の施策の結果がこちら。

パフォーマンス以外のスコアは減点された時点で都度対応しました。
自分でコーディングしてるのですから楽なものです。

さすがにいつも出るわけじゃありませんが、トップページは90～100点で安定しています。
ここはもうGoogle様の御機嫌次第なので。

そして、オチ

厨二全開で御満悦だった私。
プライム・ストラテジー社も私の記事を読めば「こんな素晴らしいテーマが！」とびっくりするに違いない。

……しかし、何かを検索していたとき、たまたま引っ掛かりました。

誰も使ってないどころか、いつの間にか本家本元がGPに変わってました。
まさかとっくに先を越されていたとは。

納得することにしましたとさ。

まとめ

特別なことをしたわけではありません。
要らない機能は燃やす。
スムーズに動くよう整える。
その結果として、オール100になりました。

とは言え、

あくまで趣味のサイトだからできたんだけどね

仕事であればここまでできません。
こんなオールコーディング仕様でサイト作っちゃうと、後任の人がメンテできなくて困っちゃいますから
引き算という考え方を参考にしていただければ嬉しいですが、実務において勧めるものでないことはゆめゆめ御承知おきください。

本稿は総論的なものにとどめましたが、

• GPで不要CSSをどう減らしたか
• 自作統合プラグインで何を置き換えたか
• AVIF化や非同期読み込みをどう組んだか

などなど、