WordPress をやめてしまった理由
WordPress はすばらしいコンテンツ編集・管理機能を持つと思うが、次のような理由で、だんだん嫌になってきた。
アップデートがめんどくさい
WordPress を使う場合、OS、PHPバージョン、WordPressバージョン、MySQL(データベース) バージョンを意識する必要がある。
OS、WEBサーバ、PHP、WordPress、MySQL とも頻繁にセキュリティアップデートがある。特に WordPress は更新が多い。
レンタルサーバを使えば、OS、PHP、MySQL バージョンは面倒をみてもらえるが、WordPressバージョンについては自動更新があるといっても、常に最新バージョンを保たなくてはならない。
PHP、MySQL のメジャーバージョンが変わる場合は、動作するかどうか検証が必要だろう。
WordPress バージョン、特にメジャーバージョンが変わる場合は、プラグインの検証等も必要だろう。
はっきりいって、しんどい。
高速化が大変
SEO 関連の記事を読んでいると、サイトの速度が Google の検索結果を左右するようになってきた印象がある。
そもそも、アクセスした時点で PHP が動くのだから、速いわけがないと思う。
高速化しようとすると、fpm を使ったり、php のバージョンを上げたり、WordPress のキャッシュプラグインや、画像最適化プラグインを導入したりする必要がある。
fpm などは、レンタルサーバで元々そのような構成を取っている場合もあるとは思うが、常に速いサーバを求めて、レンタルサーバを選ぶ必要がある。
かなり知識が必要で時間もかかる。
オフラインでの記事作成ができない
WordPress にログインして記事を作成する必要がある。
本当は、慣れたテキストエディタで編集したい。
データベースのセットアップがめんどう。特に、サーバやページの移動の時。
新規に WEB サイトを作るたびに WordPress やデータベースを設定する必要がある。
サーバを引っ越す時は、DB をセットアップして、export / import して、画像は別にコピーして、など、かなりめんどくさい。
特定のページを別のサーバに持っていく、といった時も同様の手順になり、かなりめんどうだ。
何かやろうとすると、すぐ、プラグインが必要になる。「プラグイン地獄」
WordPress で SEO、高速化、セキュリティ対策などをしようとすると、すぐにプラグインが必要になる。
プラグインで肥大化して、WEB サイトの速度も低下したりする。そしてその速度低下を防ぐために連鎖的に別のプラグインを入れたり・・・
そして、プラグインにも脆弱性があったりするので、常時、最新版に更新しておく必要がある。
自動的に更新はされるものの、正直、疲れる。
私はプラグイン地獄と呼んでいる。
サイトジェネレータ
WordPress のめんどうを見るのに疲れてきて、サイトジェネレータを使うことにした。 使っているサイトジェネレータは、hugoである。
WordPress を使っていたサイトも、Migrate to Hugoを参考に、全て、脱 WordPress を図った。
サイトジェネレータを使うメリット
セキュリティ対策がシンプルになった
セキュリティ対策としては、侵入されないために、ソフトウェアを最新バージョンに更新しておく必要があるだろう。
そもそも、事前生成した HTML/CSS/JS を WEB サーバに置いているだけなので、システムへの侵入の余地は PHP ベースのシステムに比べて遥かに小さい。
サイトジェネレータを使う場合、ソフトウェアバージョンの更新が必要なものは、OS と WEB サーバだけになる。 このぐらいであれば、自分でサーバを立てた場合でもめんどうを見られる。Ubuntu であれば apt update を実行すれば良いし、そもそも、自動更新だろう。
レンタルサーバ等を使う場合は、WEB サーバのバージョンだけ気にしていればよいし、WEB サーバのメジャーバージョンが上がったり、WEB サーバ自体が変わったとしても、通常は動作するだろう。
高速化の対策がシンプルになった
WEB サーバだけなので、そもそも高速になっているはずだ。高速化を考えるとしても、せいぜい、CDN に対応するぐらいになる。 今のところは、アクセス数も多くないので、シンプルにしておきたいと考え、CDN は使わず、一つの WEB サーバでホスティングしている。
画像サイズは事前に計画しておく必要があるかもしれない。いまのところ、大きなサイズの画像は置いていないので、何もしていない。
データベースが不要。ページの移動も簡単になった。
サイトジェネレータの場合、データベースは不要だ。WEB サーバを用意すればよい。
引っ越す場合は、生成した HTML/CSS/JS を別のサイトにコピーすればよい。ドメインを引っ越し先に変更してサイトを生成し直す必要はあるかもしれない。
また、ページを別のサイトに移動する場合は、テキストファイルを別のサイトに移動して、サイトを生成し直すだけでよい。
低スペックのサーバでも動作する
データベースが不要になり、WEB サーバだけでよくなった。そのため、低スペック(低価格)のサーバでも動作する。
レンタルサーバのほぼ 100 円の低スペックプランでも使える。
Google Cloud Platform の Free Tier を使えば、ほぼ、0 円で運用することができる。rsync(ssh) を使ってファイル転送することができる。だたし、WEB サーバを設置できる程度の知識は必要。
慣れたテキストエディタを使えて、記事作成が速くなる(テキストエディタが好きな人だけのメリットだが)
PC 上の慣れたテキストエディタで編集できるようになった。 コンテンツの入力が速くなるだろう。
hugo server
とし、PC 上で WEB サーバを起動し、プレビューしながら記事を作成する必要がある。 GUI しか使えなければつらいかもしれないが、昔はこの方法だったと思う。
サイトジェネレータを使うデメリット
WordPress のようなグラフィカルなエディタがない
テキストエディタでマークダウン形式で入力する必要があり、画像もアドレスをテキストで入力して、保存、ブラウザで確認、といった編集方法になる。WordPress のような、見たものが表示される、といった編集方法でないと理解できない、という人には不評だろうと思う。
複数人での更新がしづらそう
複数人で運用する場合、更新しづらいかもしれない。
WordPress であれば、ログインして投稿すればコンテンツが更新される。サイトジェネレータの場合は、サイトをビルドしてアップロードする必要がある。
場合によっては、github を使えないといけない
前項とも関係するが、ドキュメントのソースコードを編集するので、git/github などの利用が不可欠になってくる。
また、サイトジェネレータコマンドを実行する必要がある。
これらのツールを、あらゆる人が使いこなせるか、というと、できないと思う。
(そんなわけで、headless cms がもてはやされているようだ)
サイトジェネレータで WEB サイトを作る流れ
WEB サーバ、AWS(s3+cloudfont)、Netlify など
サイトジェネレータでサイトを作る流れとしては、以下のようになる。
- ローカルの PC 上でテキスト (markdown 形式) で記事を入力する。
- hugo serve コマンドでローカルに WEB サーバが立ち上がるので、表示内容を確認する。
- hugo コマンドを実行して html を生成する。
- public ディレクトリの下のファイルを ftp/sftp などを使って WEB サーバやレンタルサーバに転送する。
AWS(s3+cloudfront) に置く場合は、ファイル転送に hugo deploy コマンドも使用することができる。
Netlify に置く場合は、github(gitlabでもよさそう) にドキュメントソースを push しておいて、Netlify で github のレポジトリを指定すれば、Netlify でビルドされ、サイトが(CDNで)公開される。以後、github に push すれば、Netlify でビルドし、サイトが更新される。サイトジェネレータをセットアップする必要がないので、良いと思う。
GitHub Pages を hugo(gohugo) で作る場合
GitHub Pages を使う場合は次のようになる。
github pages は、やはり、サイトジェネレータを使うのであるが、標準では jekyll というサイトジェネレータになる。
github pages に hugo で作ったページを公開する場合は、以下のような手順になる。
- github のレポジトリ画面で、設定 > Pages に移動し、Source の項目でブランチとフォルダを指定。フォルダのほうは、/docs を選択する。
- ソースのトップフォルダーに空の .nojekyll という名前のファイルを作る。static pages参照
- config.toml に publishDir = “docs” を追加。publishDir参照
- github に push
その他サービス
Cloudflaire も使えるようだが、まだ、試せていない。
github に置き、Cloudflaire にコピー、という流れか?
Tweet