アルゴリア検索を導入してみたら、速くて便利で気に入った話!

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

静的サイトでも動作する検索を模索してみたよ

Google検索とかじゃなくて?

ぴー
ぴー
じゃんくはっく
じゃんくはっく

自分のサイトにもっと特化して検索できるやつが欲しかったのよ

このブログってGitHub Pagesでしょ? どうやるのかしら?

ぴー
ぴー

ゴールデンウィーク真っ最中ですね! 皆さんは何してますか?

僕は、まったりとPCと戯れて、世界中の面白いネタを探しています。もうね、あるわあるわ。面白ネタがたくさんあって、世界は広いなと、再認識しました。

さて、今回のネタは「検索」です。このブログはgithub pages ってのを使っていて静的なサイトなんです。見た目はWordPressのブログサイトっぽいのですが、htmlとcssとjsだけの構成でPHPとかデータベースとか動作していないんです。なので、自分のサイトの検索機能はGoogleのを使っているんですが、もっと良いのはないかなーと探していました。こういう分野のエンジニアは、フロントエンド・エンジニアと、いうんですが、自分は苦手分野なのであまり知識がありませんでした。

見つけたところは、Electronのサイト!

Electronえれくとろんっていう、仕組みがあるのですがこの本家サイトの日本語ドキュメントにその良い例が載っています。

Electron ドキュメント

https://www.electronjs.org/ja/docs/latest/

このサイトを見ると、キーボード操作 CMD+K で検索ウィンドウが出てきます。

こんな感じで、検索文字をタイプするごとにそのキーワードを含んだページとヒットした文字部分が出てくるわけです。検索キーワードの提案(サジェスト)が出るのではなく、検索結果がリアルタイムで表示されるイメージです。このキーワードに対して、その候補のページが出てくる仕組み・検索システムが優秀で使いやすいんです。

で、この仕組みってどうやって作っているんだろうなーと思っていたところ、このウインドウの下にはalgoliaあるごりあ と表示されています。どうやら、algolia の検索システムを使っているようです。

ちなみに、Electronっていのは、簡単に紹介すると以下です。そのうち、ネタにしようかなと思っています

Electron(エレクトロン)とは、ウェブ技術でデスクトップアプリケーションを作成できるテクノロジーです。 HTMLとCSS、JavaScriptを使って開発し、WindowsとmacOSの両OSのアプリケーションを1つのコードから作ることができます。

https://ics.media/entry/7298/

algolia の検索システムとは何なのか?

さて、algoliaの検索とはいったい何なのでしょうか? 英語サイトですが、サービス名称は「Algolia Searchあるごりあ さーち」と言うようです。

Algolia Search

https://www.algolia.com/products/search-and-discovery/hosted-search-api/

FAQのところを見ると、概要が見えてきます。まず、Algoliaは高速で、SaaSさーす製品でモバイル向けにも特化してあり、日本語も使えるようです。

機能は大きくわけて、2つあるようです。1つは、Autocompleteと呼ばれる、検索キーワードを入れると、リアルタイムで検索結果が出る仕組み。もう一つは、検索キーワードの提案(サジェスト)のAutoCompleteで、これは「Query Suggestions」を設定すると可能のようです。

こういうのは、まず使ってみるのが手っ取り早いです。幸い、WordPressでalgolia検索を使うのは簡単です。まずは、このサイトですでに実装してあるので、それを紹介してみます。

このブログでの実装例

このブログでは、キーボード操作「/」スラッシュをタイプすると、以下のような検索ウィンドウが出てきます。

検索テキスト入力エリアにフォーカスするには、「.」ドットをタイプするかマウスでフォーカスします。適当な検索ワードをタイプすればその結果を含むページが下に表示されます。これは、検索キーワードのサジェストとは違いますが、検索結果がすぐに出てくるので検索結果に遷移しなくても良くて便利です。検索ワードをタイプしてから、検索結果が出てくるのが異常に速くないでしょうか?

WordPressに入れてみる

では、このブログと同じことをしてみたい人向けに具体的な手順の紹介です。2つプラグインを入れるのですが、まず、1つ目は以下です。

WP Search with Algolia

https://ja.wordpress.org/plugins/wp-search-with-algolia/

次に、algolia のサイトではアカウントを作成し、Applicationを作成し、APIキーを参照します。

で、その各種項目を先ほどのWordPressプラグインに設定します。

少し説明は端折りますが、「Search Page」では、とりあえず真ん中の「Use Algolia in the backend」を選んでおけば良いでしょう。Autocomplete では、検索させる対象、たとえば「投稿」を選択してインデックスを再作成しておきます。

WP標準の検索ウィンドウで確認

WP標準の検索ウィンドウで、検索キーワードを入れたら、検索結果が出てくるようになっていれば成功です。

アイキャッチ記事の画像があれば、こんな感じで表示されるかなと思います。

キーボード操作で検索ウィンドウを出す

続いて、キーボード操作で、検索窓がポップアップする部分です。検索結果に遷移しなくて良いので、どのページからも検索ウィンドウが表示されれば便利かなと思いました。

そのような動作をするプラグインを昔みたことがあったので検索してみました。「wp-keyboard-nav」というのがあったので、それには検索窓がついていないので、少し手直しして、以下のような野良プラグインを作ってみました。

Keyboard PopUP algolia search
WordPress の野良プラグインです。プラグイン名称は、Keyboard PopUP algolia search です。 キーボード操作でポップアップする検索ウィンドウです。algolia検索と組み合わせて使うために、改造しました。元ソースは、wp-keyboard-nav LINK というプラグインです。

https://github.com/take-i/wp-keypopup-algolia

こちらは何も設定は必要ありません。プラグインを入れれば、すべてのページでキーボード操作で検索ウィンドウが出てくるかと思います。

レスポンス時間はどのくらいなのか?

検索ウィンドウに1文字づつタイプするごとに、Algolia のAPIにリクエストが飛び、レスポンスされます。何回か試したのですが、ほとんどが100ms 以内に帰ってきています。

以下のように、20ms以内くらいで帰ってくるようです。劇速いです!

まとめ

今回、なんとなくわかったのは以下となります。

・Algolia の無料枠は、10,000検索リクエスト/月
・検索対象の数制限は、10,000 レコード
・無料枠利用にカード登録は必要なし
・個人用サイトなら無料枠で足りそうだが、しばらく運用してみる
・有料版は、1000リクエスト/月 で1.5ドル
・検索クエリーは1文字づつ、APIリクエストが飛んでいる
・その、ほとんどが20ms以内にレスポンスされている
・検索結果が検索窓に検索キーワードを入れた時点で表示される
・↑これがすごく便利で気に入りました
・日本語にも対応していている
・紹介はしきれなかったが、静的サイトでも少しの手入れで動作する
・速いというのは、正義だなと改めて実感
・キーボードで出てくる検索ウィンドウは思ったより、便利
・algolia にINDEXデータを入れる部分はwordpressで可能
・algoliaの管理画面でAnalyticsがあり、検索ワードや表示ページなど統計データが見れる

あとがき

英語サイトの情報なので、まだあまり日本語の情報がないのですが、この手のサイト内検索を商材にするサービスは他にもたくさんあります。商用のサイトなら、たくさんある商品や情報の中から、お客さんが希望するモノにたどり着きやすくするため、サイト内検索は結構重要だと思っています。

今回の話は、バックエンドにデータベースがあって、それを直接検索参照させる従来のやり方ではないケースです。このブログのように、静的なページがあってそれを対象に高速で検索させる場合は何が正解なのでしょうか。ある人は、全文検索エンジンを入れたらどう? とか。検索用のインデッックスを持ったDBを用意すればよいとか。

このブログの場合は、記事の作成時点ではWordPressで管理していて、書き出すときに静的なHTMLにしています。全ての記事のインデックス(目次情報)は、WordPressで動作している時点でAlgolia に投げられます。静的ページからの検索は、JavaScript経由でAlgoliaに参照され、文字が入るたびにリアルタイムに検索結果が表示される仕組みです。

データベースは無く、作るつもりもないので静的ページをどうやって手間なく、検索させるか? の1つの解だとは思います。

著者にメッセージ

間違いのご指摘など、コメントじゃなくて、個人的にやりとりしたい場合はこちらからどうぞ。お返事が遅くなるときもありますが、ご了承を。

WordPressをhtmlファイルに出してGitHub Pagesで運用するスタイルが最高

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

スマホサイトでWordPressも納得したしなー!

あ〜、例の記事をネタにするんですね!

ぴー
ぴー
じゃんくはっく
じゃんくはっく

やっぱり運用が楽なのがいいしね!

率直な感想なんかを聞いてみたいわ。

ぴー
ぴー

長らく、スマホ上でWordPress環境を作って、自家サーバで動かしていましたがSLAも納得の数値を出せたのでそろそろ違う環境にしようかなと、考えていました。

 今日のお話は、WordPressから静的なHTMLファイルを書き出してそれをGitHub Pages やNETLIFYで、独自ドメインを使って動かしてみた感想なんかを書きたいなと思います。具体的な手順なんかは記載していませんので、要望があれば別ネタにしたいなと思います。

WordPressでの編集から記事公開までの概略

全体の流れは、基本的に以下の3ステップです。

 (1) ローカル環境のWordPressで記事を書く

 (2) Simply Staticプラグインで、「静的ファイルを生成する」ボタンを押す

 (3) 上記でできたファイルを展開して、Github Pages のリポジトリへコミットする

Github Pages の設定をしておけば、こんな感じですね。(2) のファイル生成時間は、動作速度、記事数や画像数などにもよって変わりますが、自分の場合は1時間弱くらいでした。

WordPressのデータをどうやって、静的ファイルにするの?

これは非常によくできたプラグインがあります。それを使うだけ。いろいろ検討しましたが以下のが一押しです。

Simply Static
HTTPS://JA.WORDPRESS.ORG/PLUGINS/SIMPLY-STATIC/

これは、Pro 版と無償版があります。今使っているのは、無償版ですが、Pro版も検討しています。とりあえずは、無償版でも十分な機能を持っています。以下のように「相対 URL を使用する」でファイルを書き出す設定をしておきます。なぜ相対URLにしているかといえば、ミラーサイトにも公開しているからです。このブログの場合、以下のように複数のリポジトリへコミットしているからです。

 メインサイト:/

 エイリアス:https://junkhack.gpl.jp/

 ミラーサイト:https://jh.gpl.jp/

あとは、「静的ファイルを生成する」でOKです。このブログの場合、583個の記事を1時間弱で書き出せました。

書き出したあとはどうするの?

無事に静的ファイルが描き出せたら、圧縮ファイルを展開してGithub Pages のリポジトリにコミットするだけです。自分は、Sourcetree を使っています。

自動化するならスクリプトを作ってコミットもできると思います。そのうち、やってみたいなと思っています。ちなみに、Simply StaticのPro版はGitHub連携も出来るので一手間減ります。

環境づくりで、注意する点

WordPress の環境作りでは、以下の点に気を付ける必要があります。

  • 書き出されるのは静的なHTMLとjsとcss と画像ファイルなのでコメントやメールフォームや検索など動的に動かすことができない
  • なので、コメントは全部閉じる
  • メールフォームなど、自分の場合はコンタクトフォーム 7を使わないようにした
  • 検索はGoogleのカスタム検索をWordPressのウィジェットに貼り付ける(https://programmablesearchengine.google.com/cse/
  • WordPressのスラグは全部英文字にしておく(日本語は使わない)
  • ローカル環境のPHP設定でメモリ関連の設定を上げておく

といったところでしょうか。静的化してもコメントやメールフォームを動かす別の方法もありますが、現時点ではまだ導入していません。そもそも、コメントやメールフォームは無くても良いかなと。あればコミュニケーションができますが、仕事の依頼系はメールでも十分かなと感じています。わざわざ、メールフォームにしておく必要性もないのが実際のところです。コメントについては、このブログの場合、ほとんど書き込みがないので無くても問題はありません。どうしても、コンタクト撮りたい場合は、メールしてもらえれば良いかなと現時点では思っています。

現時点で使っているプラグインは?

静的ファイルを書き出すSimply Staticを使っても、ちゃんと動作しているWordPressのプラグインは以下です。表示系ではない関係ないプラグインもありますが、表示系に関連するのは動いていることを確認しています。

+-------------------------------------------+----------+-----------+-------------+
| name                                      | status   | update    | version     |
+-------------------------------------------+----------+-----------+-------------+
| acf-quickedit-fields                      | active   | available | 3.1.6       |
| advanced-custom-fields                    | active   | none      | 5.11.4      |
| akismet                                   | active   | none      | 4.2.1       |
| autoptimize                               | active   | none      | 2.9.5       |
| backwpup                                  | active   | none      | 3.10.0      |
| bulk-media-register                       | active   | none      | 1.25        |
| admin-featured-image                      | active   | none      | 1.2         |
| export-all-urls                           | active   | none      | 4.1         |
| google-sitemap-generator                  | active   | none      | 4.1.1       |
| jquery-manager                            | active   | none      | 1.10.6      |
| list-urls                                 | active   | none      | 0.2         |
| luckywp-table-of-contents                 | active   | none      | 2.1.4       |
| multiple-domain-mapping-on-single-site    | active   | none      | 1.0.5       |
| permalink-manager                         | active   | available | 2.2.14      |
| search-regex                              | active   | none      | 2.4.1       |
| shortcoder                                | active   | none      | 5.6         |
| simply-static                             | active   | available | 2.1.5.2     |
| google-site-kit                           | active   | none      | 1.48.1      |
| ultimate-addons-for-gutenberg             | active   | none      | 1.25.2      |
| word-balloon                              | active   | none      | 4.18.4      |
| wordpress-importer                        | active   | none      | 0.7         |
| wp-external-links                         | active   | none      | 2.50        |
| wpfront-scroll-top                        | active   | none      | 2.0.7.08086 |
| wp-multibyte-patch                        | active   | none      | 2.9         |
| duplicate-post                            | active   | none      | 4.3         |
+-------------------------------------------+----------+-----------+-------------+

意外だったのは、目次を作っている「luckywp-table-of-contents」や吹き出し表示の「word-balloon」もちゃんと動作しています。

まとめ

今回、なんとなくわかったのは以下となります。

・運用コストが下がるので、今後はコンテンツネタに力を入れていきたい

・やっぱり静的ファイルは読み込みが速い!

・WordPressとは今後もローカル環境で付き合っていきます

あとがき

かなり前から、WordPress運用環境を変えたいなと検討していました。やっぱりシンプルが一番です。まだ切り替えたばかりなので、少し記事を書いてからまた感想などを書きたいなと思います。

著者にメッセージ

間違いのご指摘など、コメントじゃなくて、個人的にやりとりしたい場合はこちらからどうぞ。お返事が遅くなるときもありますが、ご了承を。

KeyCDNという安いCDNを半年使った感想、価格や月維持費などレポート!

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

CDNってのを半年、使ってみましたよ

クラウドからコンテンツを配信するってヤツですね。

ぴー
ぴー
じゃんくはっく
じゃんくはっく

どんな効果があって、月維持費はどのくらいかレポートしてみます。

私は、月500円くらいまでなら出せるかなー

ぴー
ぴー

KeyCDNは数年前、1位か2位くらいの安さでしたが、今はもっと安いのがあるようです。CDNのコスト計算サイトでは以下のようでした。blazingcdnというのが破格の安さのようです。

今回は前から気になっていたKeyCDNをこのスマホサーバのWordPressサイトに適用してみましたので、実際どのくらいの値段で運用できるんだ? みたいな感想をレポートしてみたいと思います。

そもそもCDNって何?

CDNは平たく言えば、画像やコンテンツを本家とは違うサーバから配信するというものです。キャッシュサーバとか、エッジサーバとか表現したりしますが、要は静的なファイルを本家サーバからではなく、CDNのクラウドから配信することによりネットワーク負荷や、レスポンス改善(時に改悪)したりするのが目的です。

コンテンツデリバリネットワーク(英語: content delivery network、CDN)

wiki

いくらするの?

ほとんどの人が気になるのは、初期や維持費などの価格がいくらなのか? っていうことと、速度はどのくらい改善されるのか? ってことだと思います。こればっかりは使ってみないとなんとも言えない部分があります。早速、値段からレポートしてみたいと思います。

 まず、KeyCDNは最初にクレジットを入れてそれを消費する仕組みです。最小の入金単位は 49ドル となります。日本円で当時のキャッシュカード換金レートで、5,553円でした。

 入金したのが、2021年の06月/01なので現時点で半年使っていることになります。クレジットの消費は以下のようになっています。

残りクレジットは18くらいです。49から約36%残っていますので半年で67% 消費したことになります。半年で、約3720円ですので、1ヶ月あたり620円という感じですね。

 グラフの途中に、ガクンとクレジットが消費しているところがありますが、これはキャッシュを完全に消去して作り直している部分です。

どのくらいのアクセス数なの?

統計期間が約4ヶ月くらいなので、KeyCDN上のデータでは以下のようです。

1日あたり、cssや画像やhtmlなど合計して1.8万くらいのヒットがあります。PV的な数値は1つ前の記事に載せてありますので、参考にしてください。

1ヶ月のデータ転送量は?

このサイトの1ヶ月のデータ転送量(総トラフィック)は、KeyCDNの統計データで見ると以下のようです。

PV的には2000〜2500くらいでこの転送量です。3000〜5000くらいのPVでも15GBを1ヶ月に超えることはありませんでした。

CDNの効果はどのくらい?

ページ計測サイトで、CDN適用前と適用後のデータを測っておきましたので載せておきます。

まずは、CDN適用前。

次は、CDN適用後。

だいぶ改善されていますね。適用前は、最初のレンダリングが始まるのに、約4.2秒かかっていますが、適用後は、0.8秒です。CDNの効果は絶大です。

まとめ

今回、なんとなくわかったのは以下となります。

・このサイトのようにPVが月に2000〜5000くらいでは、月600円〜700円くらいのCDNコスト

・設定は非常に楽

・CDNの効果は絶大で、最初の描画が4.2秒から0.8秒となった

blazingcdnというCDNはKeyCDNより激安で、どんな効果があるのか試してみたい気もする

あとがき

WordPressのように、コンテンツ側で結構リソースを使うタイプや、スマホサーバのように非力な環境ではCDNの効力は絶大です。しかし、利用コストが月に600円〜700円くらいかかり趣味で使うのなら良いのですが、静的HTMLにして運用したほうが、良いなという結論に至りました。要はWordPressは、リソースを使うし無駄が多いんです。近々、そういう運用に方針を変えますので、紹介したいなと思っています。

著者にメッセージ

間違いのご指摘など、コメントじゃなくて、個人的にやりとりしたい場合はこちらからどうぞ。お返事が遅くなるときもありますが、ご了承を。

2021/04〜12 site24x7 でのSLA状況・統計データ

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

この半年以上、スマホサーバは安定稼働してるよ!

一時期、落ちるって言ってたけど原因わかったの?

ぴー
ぴー
じゃんくはっく
じゃんくはっく

あー、あれはルータのマルチセッションの設定が原因だった

だから、Bad Gatewayだったのね。

ぴー
ぴー

この半年、仕事が急がしてく記事を更新する気力もなくグタグタと過ごしてきました。やっとまとまった休みも取れた(正月休み)ので記事を更新しておきます。

 site24x7 で監視していますが、最近は安定してきました。SLA統計データを出しておきます。

何を目指しているの?

稼働率・SLA99.95%をスマホ自宅サーバで目指せ!まずは1ヶ月間

LINK

site24x7のスターターパックを2020の10月から始めています。監視サービスでSLAを99.95%目指しています。99.95%とは1ヶ月にダウンタイムが21.6分以内であればOKということですが、最近はほぼ100%を維持しています。一時期、NGINXがBadGatewayになる現象が発生していましたが、これはやっと原因がわかりルータのマルチセッションの設定がよくなかったようです。詳細は省きますが、ドメインによってプロバイダAとBを分けていました。今は、マルチセッションはやめて1つのプロバイダから出ています。

2021・最終四半期のSLA

10月から12月の結果です。障害時間の合計は37 分 17 秒で、SLAは99.972%となり目標の99.95% 以上になっています。ちょこちょこダウンしているのは、大量のダウンロードなどで帯域を潰してレスポンスが一時的になくなる時間などで特にサーバがダウンしているわけではないです。外部から監視しているとそういう瞬断が3ヶ月で37分くらいあったということです。

PHPは、前回の記事でも紹介していますが、PHP7系のちょっと新しいのをビルドして入れています。

どのくらいのアクセス数なの?

ページを表示している回数(PV)は、こんな感じで月におおよそ2500〜5000という感じです。最近は全然記事を更新していなかったので、2000くらいまで下がっています。

検索数で見ると以下のような感じのサイトです。

最近は、MQA関連の音楽ネタと、pixel3のroot化記事関連がほとんどです。

まとめ

今回、なんとなくわかったのは以下となります。

・このくらいのアクセス数のサイトをスマホで安定稼働させることは十分可能

・消費電力などを考慮しても、レンタルサーバより安価で運用を趣味にしている人には良いかも

・しかし、WordPressの運用はクソめんどくさい。正直、もうGithub Pageとか、NETLIFYに静的ページを吐き出す運用にしようかと思ってる。

あとがき

放置ぎみになっている個人のブログっていうのは月にこのくらいのアクセス数で、当初のスマホで安定稼働させるっていう目的も達成したので、そろそろ違う運用も視野に入れています。WordPressとは関わっていきますが、静的ページを吐き出す運用のほうが楽でいいなーと思います。このSLA報告もこれが最後になるかもです。

著者にメッセージ

間違いのご指摘など、コメントじゃなくて、個人的にやりとりしたい場合はこちらからどうぞ。お返事が遅くなるときもありますが、ご了承を。

TermuxのパッケージPHP7.4.21最新ビルド

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

最近、仕事が忙しがったー!

もう今年も半分終わっちゃいましたね。

ぴー
ぴー
じゃんくはっく
じゃんくはっく

今回は、TermuxのPHPを最新の7.4.21 にしたよ

最新ビルド作ったんですか?

ぴー
ぴー

Termux のPHPバージョンは、今は8系になっていて7.4系の最終リリースは7.4.12 でした。ちょっと古かったので、2021年7月01日にリリースされたphp7.4.21をビルドしておきました。7系はあと1年くらいは使うつもりです。ところで、xdebug付きはどうやってビルドするんでしょうね。次の課題です。

PHP7.4.21のダウンロード先

Github: termux-php7

LINK

完全にはテストしていませんが、このサイトにも入れながらテストしています。今のところ大丈夫かな?心配な人は自分でビルドして、テストしてみてくださいね。ビルド方法はググってくだされ。

アップデート方法

前の記事で、php8.xからphp7.4.12にダウングレードする方法は書いていますので、今回はアップデートです。

TermuxでPHP7を使いたい! PHP8からPHP7にして使う。

URL

さくっと、バージョンあげてみましょう。

ステップ1

ZIP圧縮したのも以下にあるのでダウンロードして解凍しておきます。

cd 適当なDIR
wget https://github.com/take-i/termux-php7/raw/master/php_7.4.21-aarch64-deb.zip
unzip php_7.4.21-aarch64-deb.zip

解凍すると以下な感じです。

$ tree php_7.4.21-aarch64-deb
php_7.4.21-aarch64-deb
├── apache2_2.4.46-4_aarch64.deb
├── libicu_67.1_aarch64.deb
├── php-apache_7.4.21_aarch64.deb
├── php-fpm_7.4.21_aarch64.deb
├── php-pgsql_7.4.21_aarch64.deb
└── php_7.4.21_aarch64.deb

今回は、nginxですので、本体とphp-fpmを入れておきます。libicu_67は前回(php7.4.12)と同じなのでそのままです。apacheとphp-apacheはまったくテストしていませんので、自己責任で入れるならお願いします。動作しない場合は、ご連絡を。対応するかは別ですが。

ステップ2

アップデートする前に、パッケージが更新されないようしていた場合は以下のようにパッケージ名が出ますのでそれを解除しておきます。

$ apt-mark showhold
php
php-fpm

解除は、unhold です。

$ apt-mark unhold php php-fpm
Canceled hold on php.
Canceled hold on php-fpm.

解除されたか、再度 1つ上のコマンドを実施しておきます。

ステップ3

アップデートといっても、コマンドは同じです。

cd php_7.4.21-aarch64-deb
※以下は今回入れないので削除。
rm apache2_2.4.46-4_aarch64.deb php-apache_7.4.21_aarch64.deb* php-pgsql_7.4.21_aarch64.deb*

dpkg -i ./php*

ステップ4

確認。ちゃんと、7.4.21が入っていますね。

$ php -v
PHP 7.4.21 (cli) (built: Jul 10 2021 16:36:28) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies

勝手にアップデートされないようマークしておきます。

apt-mark hold libicu php php-fpm

マークされたか、確認

$ apt-mark showhold
libicu
php
php-fpm

ステップ4

nginxとphp-fpm を再起動しておきます。このスマホはroot化してあって、nginxはroot権限でmasterプロセスが動作しているので、sudoしてKILLしておきます。

$ killall php-fpm
$ sudo killall nginx
再起動
$ php-fpm
$ sudo nginx

phpinfo()などで確認しておきます。

まとめ

今回、なんとなくわかったのは以下となります。

・termuxのphp最新をビルドしてみた
・テストは人柱として、このホストやっています
・何かあれば報告(してね)
・xdebug付きのもビルドしてみたいがどうやるんだろうか?

あとがき

まだこのブログは、スマホのumidigi F2で動作させています。そろそろ電池を交換したので、pixel3を復活させないとですが、腰が思いです。あと、最近keyCDNも1ヶ月くらい運用していますので、そろそろそのネタも描きたいなと。ついでにアドセンスなんかも運用していますが、これは駄賃くらいにしかならないので、やめた方がいいんじゃないかという感じ。広告でるのは好きじゃ無いし、回避方法は見る側がいくらでもできますしね。

著者にメッセージ

間違いのご指摘など、コメントじゃなくて、個人的にやりとりしたい場合はこちらからどうぞ。お返事が遅くなるときもありますが、ご了承を。

静的HTMLをWordPressから作るには?

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

静的ページでミラーサイト作りたいな!

WordPressからHTML作るやつですね!

ぴー
ぴー
じゃんくはっく
じゃんくはっく

GitPagesとかNetlifyとかでブログ運用できるからね

コメントとかメール送信とかは?

ぴー
ぴー

ここんところ、WordPressから静的なHTMLを吐き出して運用するにはどうしたらいいかっていう事を研究していました。このブログは、現在スマホのPixel3やUmidigiF2で作られていますが、静的なHTMLページにできたら、かなり処理負荷が減り、またセキュアな運用ができるので実現してみたいなと思っています。

WordPressは設計が古い、王道のWEB-DBアプリ

WordPressは最初のバージョン1.xがリリースされてもうすぐ20年になろうとしています。付き合いは古く1.xと2.xの変わり目あたりからWordPressをいろんな用途で使っていました。基本的な設計は今も変わっておらず、WEB-DBアプリケーションの位置づけです。

WorePressは、アクセスされる側(フロントと俗にいいます)にPHPがあり、記事の実態や設定などは裏方(俗にバックエンドといいます)でMySQLデータベースが処理する王道なWEB-DBアプリです。図では以下のようになります。

PHP処理時間や、データベース処理時間をなくせば劇的に速くなります。今テストで2つのサーバに静的なHTMLを出していますので、記事の後半で視覚的に評価してみます。

静的なHTMLを吐き出すとどんなメリット・デメリットが?

WordPressがこの構成をしているのは、動的に処理ができるからです。記事の検索や各種プラグイン処理、コメント処理、メール送信機能などです。たとえば、この記事には「目次」がありますが、これは「LuckyWP Table of Contents」というプラグインが自動的に挿入してくれています。こういう固定表示系のプラグインは静的なHTMLを吐き出しても問題ありません。しかし、コンタクトフォーム 7などメール送信系やコメント部分、あるいは検索系は静的なHTMLでは実現できません。

普通にブログを書いて、コメントはあきらめ、PingBack(もう今はその恩恵もあまりない機能)やメール送信、その他動的に生成される機能を無視すれば、WordPressが出す静的HTMLで十分なんじゃないかなと思ったりします。

どうやって静的なHTMLを取得するか?

前置きが長くなりましたが、どうやって実現するかです。クライアント側でwgetコマンドなどを使い取得する方法や、WordPress本体側(プラグインを使って)から取得する方法の2つに大別されます。今のところ、プラグインを使ってHTMLを吐き出す方法が良さそうかなと思っています。実際に試して評価したのは以下2つです。

Simply Static

https://ja.wordpress.org/plugins/simply-static/

もう一つはこちら。

Export WP Page to Static HTML/CSS

https://wordpress.org/plugins/export-wp-page-to-static-html/

両方とも、Pro版があります。今のところ、後者の「Export WP Page to Static HTML/CSS Pro」は現時点の最新がver1.0.4ですがバグがあり正常に取得できません。またスラッグ にマルチバイト文字列があるとファイル生成時にURLエンコードされたファイル名で保存されてしまいます。(リンクされず404になる)この問題はSimply Staticでもありますが、英数字スラッグ であればSimply Staticでは問題ありません。もう少し様子を見て、良さそうならSimply StaticのPro版を検討しようかなと思っています。こちらはGit連携があるようで、完全に静的HTMLを他のWEB領域にデプロイすることができそうです。

Simply StaticのGitHub統合

https://patrickposner.dev/docs/simply-static/github/

静的ファイルをGitHub Pagesに出してみた

このブログを微調整した開発サイトから、Simply Staticを使い静的なHTMLを出力しGitHub Pagesにコミットしてみました。ドメインは独自ドメインにマッピングしてあります。SSLも自動ですので便利。

Github Pagesミラーサイト

https://jh2.gpl.jp/

こちらの応答時間はsite24x7の監視で以下のようです。

東京観測地点からの平均値は128ms です。速いですね。

静的ファイルをNetlifyに出してみた

GithubPagesのリポジトリにコミットすると、Netlifyにもデプロイされるようにしています。こちらも、ドメインは独自ドメインにマッピングしてあります。SSLも自動ですので便利ですね。

Netlify (ねっとりふぁい)ミラーサイト

https://jh.gpl.jp/

世界にはいろんな静的サイトホスティングがありますが、このNetlifyは無償でも使える有名なところです。こちらの応答時間はsite24x7の監視で以下のようです。

Netlifyの方は、東京から平均835ms です。Github Pagesのほうが速いですね。

比較のため、スマホサーバからの応答時間も

スマホサーバ、WordPress+NGINX+php7.4.x+mariadbでの応答も比較のため出しておきます。これは、KeyCDNを使ったりキャッシュを調整したりいろいろチューニングしています。

Pixel3 スマホサーバ
 WordPress+NGINX+php7.4.x+mariadb KeyCDN

/

site24x7の監視で以下のようです。

東京観測地点からは、平均385msです。ちなみに、KeyCDNを経由する前は以下のようです。

平均1.27秒なんでかなり遅いですね。KeyCDNの効果は劇的です。でも1ヶ月に1000円弱かかるんですよね。

また、これ以外にもLargest Contentful Paint(LCP)という指標があり、簡単に言えばユーザーがそのページにアクセスしたとき、一番大きな画像またはテキストブロックが描画される時間です。具体的にウチのブログの場合は、以下がそれです。

これも、KeyCDNを使うと1.3秒くらいまで縮まりますが、使わないと4秒くらいかかってしまいます。しかし静的HTMLサイトなら、時間帯にもよりますが1秒から1秒弱くらいになります。

WordPress構成のサイトだと、いろいろチューニングしないとこのくらいの速度にはなりません。結構面倒で、CDNを契約するとそれなりにコストがかかります。月間1万ページビューくらいのブログでも1000円くらいはCDNに持っていかれます。何も意識しなくても、静的HTMLページだとそれより速いですからね。しかも、GitHub Pagesや、Netlifyを使えば無料の範囲で実現できます。

まとめ

今回、なんとなくわかったのは以下となります。

・静的HTMLファイルだけで運用してみる価値は十分にあるが、迷う
・とりあえずミラーサイト的な位置づけで実験運用
・静的HTMLにした場合、検索、メール、コメント、Feedをどうするか?
・逆にそれ以外はほぼ、WordPressの動的機能を使う必要性は感じない
・全記事、スラッグ を英語にするにはどうしたら?自動変換してくれるプラグインとか?

あとがき

ほんとWordPressって手間がかかりますね。こういうのが面倒なんで、アーキテクチャーがオワコンとか言われているんです。

しかし、WordPress がnode.jsで動作して、設計も一新される時がいつかくるかもしれません。新しいものが必ずしも良いとは限りませんが、確実にアーキテクトは変化していきますので、何が最適なのかはいろいろ実験して手法を知っておくことが大切だなと思っています。チューニング次第では、apacheもnginxに近づけますし(面倒ですが)、WordPressも静的サイトに近づけることは可能です。まぁでも、実際は楽でセキュアなのが良いですよね。今時、sendmailなんて使いませんし、WEBサーバはnginxが主流です。

仕事では、あまり実験できないので趣味の範囲でいろいろ実験しておいて使えそうだなと思った手法は実際に仕事にフィードバックしていきたいですね。月〜金で仕事でmac使って、土日もほとんど同じような事をやっていますので、この業界が好きなんでしょうね。というか、オタクなだけですが。。。

ネットとPCと通販があれば、場所はどこでも生きていけそうです。ログハウスとか、手作りしながら、ブログ、Youtubeで配信する生活に憧れます。

著者にメッセージ

間違いのご指摘など、コメントじゃなくて、個人的にやりとりしたい場合はこちらからどうぞ。お返事が遅くなるときもありますが、ご了承を。