続・WordPressをwgetとNetlifyでお手軽に静的サイト化する話

前回のWordPress静的化から発展し、今回は今ご覧になっているこのサイトを静的化していきます。

…しかし公開からしばらくすると、ページ表示がなんだかモッサりしているなぁと感じるようになりました。そこで今回はNetlifyからGoogleさんのところのFirebase Hostingに鞍替えし、その作業をまとめて行こうと思います。

今回の作業で公開するサイトはwgetコマンドで静的化したサイトなので…きっと簡単に再現できるはずです。もしWordPressの静的化を行うのであれば前回と前々回の記事をご覧いただけると幸いです。

Netlifyが遅い問題

NetlifyはほぼGitリポジトリを選択するだけでお手軽に静的ファイルをホスティングしてくれる使いやすいサイトです。しかし、こちらの記事を参考にすると、Netlifyには日本国内の拠点がなくアクセスが海外旅行するようで、どうしてもレスポンスが遅くなるようです。その遅さは体感できるほどでした。

というわけで、今回はその遅さをどうにか解消したいと思い、Netlifyから同じく基本無料から利用することができるFirebase Hostingを試してみよう！…となったわけです。

ちなみに、実際の測定結果は本記事の最後に掲載していますので、Firebase Hostingとの比較と共に見ていただけるとです。

Firebaseプロジェクトを作成する

まずはプロジェクトを作成しておきます。Googleアカウントはほとんどの方が持っていると思いますので、早速 Firebase のコンソールページにアクセスします。プロジェクト作成自体はページの指示通りに入力していけば迷わずできるはずです。

Firebaseをインストールする

次にデプロイに使用するFirebase CLI をインストールします。インストールの方法は色々ありますが、node環境がないので今回はスタンドアロンバイナリを直接ダウンロードする方法で進めていきます。

手順としては以下のコマンドだけで導入(ダウンロード~パス通し)までできます。

$ mkdir /parh/to/firebase_dir && cd /parh/to/firebase_dir
$ wget -O firebase https://firebase.tools/bin/linux/latest
$ chmod +x ./firebase
$ echo 'export PATH=$PATH:/parh/to/firebase_dir' >> .bashrc

ちなみに他の導入方法は公式ガイドを参考にしてみてください。今回はLinux環境でしたがWindowsやMac環境用の説明も載っていますので指示通りに進めれば導入できるはずです。

Googleアカウントを紐付ける

次にGoogleアカウントとの紐付けを行います。基本的には下記のコマンドを実行して表示されたURLにアクセス、承認してあげるだけです。

$ firebase login --no-localhost

i  Firebase optionally collects CLI usage and error reporting information to help improve our products. Data is collected in accordance with Google's privacy policy (https://policies.google.com/privacy) and is not used to identify you.

? Allow Firebase to collect CLI usage and error reporting information? Yes
i  To change your data collection preference at any time, run `firebase logout` and log in again.

Visit this URL on any device to log in:
https://accounts.google.com/o/oauth2/auth?client_id=.....

? Paste authorization code here: [認証後表示されたcodeを入力]

✔  Success! Logged in as [ログインしたGmailアカウント]@gmail.com

しかし、今回は承認後のlocalhostが正常に動作しなかったので(おそらくファイヤーウォールのせい)、今回はlocalhostを使用せず、codeを入力する方式でアカウント紐付けを行いました。このためのオプションが--no-localhostになります。

Firebaseプロジェクトの初期化

次にプロジェクトの初期設定を行います。

$ cd /path/to/web/dir
$ firebase init hosting

     ######## #### ########  ######## ########     ###     ######  ########
     ##        ##  ##     ## ##       ##     ##  ##   ##  ##       ##
     ######    ##  ########  ######   ########  #########  ######  ######
     ##        ##  ##    ##  ##       ##     ## ##     ##       ## ##
     ##       #### ##     ## ######## ########  ##     ##  ######  ########

You're about to initialize a Firebase project in this directory:

  /path/to/web/dir/


=== Project Setup

First, let's associate this project directory with a Firebase project.
You can create multiple project aliases by running firebase use --add, 
but for now we'll just set up a default project.

? Please select an option: Use an existing project
? Select a default Firebase project for this directory: project_name (project_name)
i  Using project project_name (project_name)

=== Hosting Setup

Your public directory is the folder (relative to your project directory) that
will contain Hosting assets to be uploaded with firebase deploy. If you
have a build process for your assets, use your build's output directory.

? What do you want to use as your public directory? [document_root_dir_name]
? Configure as a single-page app (rewrite all urls to /index.html)? No
? Set up automatic builds and deploys with GitHub? No
? File [document_root_dir_name]/404.html already exists. Overwrite? No
i  Skipping write of [document_root_dir_name]/404.html
? File [document_root_dir_name]/index.html already exists. Overwrite? No
i  Skipping write of [document_root_dir_name]/index.html

i  Writing configuration info to firebase.json...
i  Writing project information to .firebaserc...
i  Writing gitignore file to .gitignore...

✔  Firebase initialization complete!

今回は最初の手順でプロジェクトを作成済みなので、既存のプロジェクトを選択しました。また、デプロイするファイル群はWordPressから作成済みなので404.htmlやindex.htmlの生成は不要、また今後のデプロイは自作のスクリプトから実施する予定なので、GitHubの項目もNoで回答していきます。

ここまでできれば準備は完了です。

デプロイする

では最後にデプロイしていきます。とはいえデプロイもコマンド1つです。

$ firebase deploy --only hosting

=== Deploying to 'web-konetaclick'...

i  deploying hosting
i  hosting[web-konetaclick]: beginning deploy...
i  hosting[web-konetaclick]: found 1583 files in [documentroot_dir]
✔  hosting[web-konetaclick]: file upload complete
i  hosting[web-konetaclick]: finalizing version...
✔  hosting[web-konetaclick]: version finalized
i  hosting[web-konetaclick]: releasing new version...
✔  hosting[web-konetaclick]: release complete

✔  Deploy complete!

Project Console: https://console.firebase.google.com/project/[project name]/overview
Hosting URL: https://[project name].web.app

処理が終わると、ホストされたURLが発行されますので、ここから正常にデプロイされているかを確認することができます。

作業前後

最後に作業前後それぞれでのレスポンス時間を比較して終わろうと思います。冒頭でも書きましたとおり、作業前の環境はNetlifyにデプロイされています。

計測にはGo製のベンチマークツール「hey」を使用しました。お手軽簡単にベンチマークを取ることができるのでおすすめしておきます。

作業前 (Netlify)

$ hey https://koneta.click

Summary:
  Total:	2.1298 secs
  Slowest:	1.3774 secs
  Fastest:	0.1981 secs
  Average:	0.4127 secs
  Requests/sec:	93.9070

Summary:
  Total:	2.1298 secs
  Slowest:	1.3774 secs
  Fastest:	0.1981 secs
  Average:	0.4127 secs
  Requests/sec:	93.9070

Response time histogram:
  0.198 [1]	|
  0.316 [143]	|■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
  0.434 [2]	|■
  0.552 [0]	|
  0.670 [4]	|■
  0.788 [0]	|
  0.906 [2]	|■
  1.024 [42]	|■■■■■■■■■■■■
  1.142 [5]	|■
  1.259 [0]	|
  1.377 [1]	|


Latency distribution:
  10% in 0.2010 secs
  25% in 0.2040 secs
  50% in 0.2094 secs
  75% in 0.9042 secs
  90% in 0.9809 secs
  95% in 1.0159 secs
  99% in 1.1090 secs

Details (average, fastest, slowest):
  DNS+dialup:	0.0794 secs, 0.1981 secs, 1.3774 secs
  DNS-lookup:	0.0138 secs, 0.0000 secs, 0.0944 secs
  req write:	0.0000 secs, 0.0000 secs, 0.0003 secs
  resp wait:	0.1262 secs, 0.0957 secs, 0.3134 secs
  resp read:	0.0098 secs, 0.0003 secs, 0.4600 secs

Status code distribution:
  [200]	200 responses

作業後 (Firebase Hosting)

$ hey https://koneta.click

Summary:
  Total:	0.9511 secs
  Slowest:	0.4694 secs
  Fastest:	0.0224 secs
  Average:	0.2059 secs
  Requests/sec:	210.2747

Summary:
  Total:	0.9511 secs
  Slowest:	0.4694 secs
  Fastest:	0.0224 secs
  Average:	0.2059 secs
  Requests/sec:	210.2747
  

Response time histogram:
  0.022 [1]	|
  0.067 [0]	|
  0.112 [0]	|
  0.157 [129]	|■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
  0.201 [17]	|■■■■■
  0.246 [1]	|
  0.291 [2]	|■
  0.335 [12]	|■■■■
  0.380 [8]	|■■
  0.425 [14]	|■■■■
  0.469 [16]	|■■■■■


Latency distribution:
  10% in 0.1220 secs
  25% in 0.1397 secs
  50% in 0.1482 secs
  75% in 0.2916 secs
  90% in 0.4160 secs
  95% in 0.4473 secs
  99% in 0.4690 secs

Details (average, fastest, slowest):
  DNS+dialup:	0.0437 secs, 0.0224 secs, 0.4694 secs
  DNS-lookup:	0.0007 secs, 0.0000 secs, 0.0034 secs
  req write:	0.0000 secs, 0.0000 secs, 0.0007 secs
  resp wait:	0.1325 secs, 0.0171 secs, 0.1564 secs
  resp read:	0.0046 secs, 0.0004 secs, 0.1526 secs

Status code distribution:
  [200]	200 responses

というわけで、思っていた以上の高速化を実現することができました。今回はレスポンス時間という観点でのみの比較ですが、Firebase Hostingを利用したほうが調子が良さそうなので本格的に使っていきたいと思います。

おまけ (ConoHa1GB + WordPressそのまま)

最後におまけとして静的化前のWordPressでも調査してみようと思います。こちらは現在ConoHaの1GBプラン上で動作しています。また、これはwget用に用意しているだけなのでだいぶスペックは制限しています。そのため調査時も並列は1つで調査しています。

$ hey https://[origin domain].com -c 1

Summary:
  Total:	22.6286 secs
  Slowest:	13.3695 secs
  Fastest:	0.1897 secs
  Average:	4.7227 secs
  Requests/sec:	8.8384

Summary:
  Total:	22.6286 secs
  Slowest:	13.3695 secs
  Fastest:	0.1897 secs
  Average:	4.7227 secs
  Requests/sec:	8.8384
  

Response time histogram:
  0.190 [1]	|■
  1.508 [20]	|■■■■■■■■■■■■■■■■
  2.826 [20]	|■■■■■■■■■■■■■■■■
  4.144 [49]	|■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
  5.462 [37]	|■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
  6.780 [37]	|■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
  8.098 [22]	|■■■■■■■■■■■■■■■■■■
  9.416 [5]	|■■■■
  10.734 [0]	|
  12.052 [6]	|■■■■■
  13.369 [3]	|■■


Latency distribution:
  10% in 1.1740 secs
  25% in 2.9277 secs
  50% in 4.7938 secs
  75% in 6.3292 secs
  90% in 7.7741 secs
  95% in 8.6856 secs
  99% in 12.5423 secs

Details (average, fastest, slowest):
  DNS+dialup:	0.0227 secs, 0.1897 secs, 13.3695 secs
  DNS-lookup:	0.0075 secs, 0.0000 secs, 0.0292 secs
  req write:	0.0001 secs, 0.0000 secs, 0.0005 secs
  resp wait:	3.4589 secs, 0.1632 secs, 13.3391 secs
  resp read:	0.3117 secs, 0.0180 secs, 2.8701 secs

Status code distribution:
  [200]	200 responses

Totalの項目は並列数が違うので無視するとして…その他の項目を見ると静的と比べるとだいぶ遅くなっているのが見えてきます。端末のスペックがそもそも違うので厳密ではありませんが、やはりスピード面では静的サイトに軍配が上がるようです。

参考

Firebase Hosting 公式ガイド … ほぼ ここをみるだけでこの記事は不要です。

この記事では、静的化元のWordPressの準備からNetlifyへのデプロイまでを書いていこうと思います。この記事に書いてあることを実行することで、このサイトと同じような状況にできると思います。今回は、WordPress静的化の作業をメインに書いていこうと思いますので、Webサーバの設定方法やDNSの設定など直接関係のない部分の説明は省きますのでご了承ください。

オリジンを作成

まずはNetlifyで使用する公開用のドメインとは別に、WordPressにより動的にページを生成して静的化の元にするオリジン用のドメインを準備します。本記事では、本サイトで作業することをイメージし、公開用のドメインを「koneta.click」、オリジン用のドメインを仮に「origin.koneta.click」として書いていこうと思います。今回はサブドメインを使いますが、別のドメインを用意していただいても問題ありません。

オリジン用のドメイン(とWebサーバ)の準備ができましたら、次はWordPressの設定です。とはいえ、特別な設定は不要なので、オリジン用に準備したドメイン(本記事ではorigin.koneta.clickの方)でいつも通りWordPressの初期設定を進めてください。初期設定が終わったら、その後もいつも通りでテーマの設定や必要なプラグインのインストールなど、サイトオープンに必要な作業を行い下準備は完了です。

動的必須部分の対応

今回はサイトを静的化してしまうため、動的で動作する部分は停止しなくてはいけません。これは使用しているテーマやプラグインによるところが多いと思いますが、本記事では多くのサイトで使われているであろう項目を挙げて停止していただきたいと思います。

コメント

まずはコメント機能です。コメントの無効化は簡単で、WordPressの設定画面から記事編集時のコメント有効の設定をデフォルトで無効にできるため、こちらを修正するだけで無効になります。合わせてウィジェットなどに新規コメントなどを表示している場合は、そちらも削除すれば完了です。

本サイトでは、コメント機能は残しておきたかったので、WordPressのコメント機能とは別のDisqusというサービスを使用することで、静的化後もコメント機能を利用できるようにしています。こちらの作業については後ほど紹介します。

検索

次は検索機能です。こちらも対応は簡単でウィジェットに表示されている検索ウィンドウを表示しないようにすれば完了です。しかし、もしテーマに検索機能が組み込まれている場合は、そちらも対応が必要になりますのでご注意ください。

検索機能はGoogleカスタム検索などを活用することで、静的化後も利用することができますが、私の経験上ではサイト内の検索機能はほとんど使われず、カテゴリやタグでの絞り込みは静的化後も使えるため、本記事では検索機能はなかったモノとして進めていきます。

更新情報サービス/ディスカッション設定 など

次は投稿した際に使われる通知系です。今回はオリジン側で投稿機能を残すため、投稿時の処理は動作はするのですが、ここで通知されるのはオリジンのURLで送られてしまうため、効果はなくなってしまっています。そんなわけで、こちらも動かないようにしていいと思います。

設定方法は管理画面設定の「投稿設定」から「更新情報サービス」の項目を削除して保存、また「ディスカッション設定」から「デフォルトの投稿設定」の各種設定をOFFにすれば完了です。

その他の動的部分

先ほど書きました通り、WordPressにおいて動的部分は使用しているテーマやプラグインによってもだいぶ異なります。本サイトで使用しているテーマやプラグインは最低限の機能しかないもののため、上記の項目程度でしたが、高機能なテーマなどを使用して、何もかも動的で生成するしているような場合は、最悪の場合諦めるのも手かもしれません。

静的化する

ここまでできましたら、準備は完了です。いよいよ静的化を行います。静的化は前回の記事と同じようにwgetコマンドを使用し、コマンドのに使用している各種オプションについての説明なども書いてあるのでコマンドは前回記事を参照してください。

WordPressをwgetとNetlifyでお手軽に静的サイト化する話

WordPressで動ているサイトからプラグイン不要で静的ファイルを生成し、それをNetlifyに設置することで高速安心な静的サイトを構築していきたいと思います。

これで静的化は完了です。あとはNetlifyで公開するだけなのですが、その手順も前回書いたので今回は省略させていただきます。公開するときのドメインは、オリジンのドメインとは違う公開用の方のドメインで設定してください。

プラスアルファ作業

今回の静的化はwgetにより、画像など静的コンテンツやリンクはローカルだけで解決できるように自動で書き換えられていますが、meta情報などリンク以外のアドレスは変換されません。そうなるとmeta情報は公開しているドメインとは変わってしまいますし、オリジンのドメインがもろバレなので、セキュリティ面でも意味がなくなってしまいます。そこで、プラスアルファ作業として、これらを解消していこうと思います。また先ほど書いた通りコメント機能も使えるようにしてみようと思います。

オリジンを隠す

まずは静的化したファイルから管理画面を含むオリジンのドメインを公開用のドメインに変更しようと思います。変更の方法は何でも大丈夫ですが、私は以下のコマンドを使って一括で変更しようと思います。

# 隠蔽単語を置換
find $WORK_DIR$ORIGIN_DOMAIN -type f | xargs sed -i -e "s|$ORIGIN_DOMAIN|$SITE_DOMAIN|g"

コマンドは上記の通りです。これを静的化したファイルのルート部分で実行することでオリジンドメインと公開用ドメインを置換することができます (後ほど本記事で使用するコマンドをまとめますので、今は無視で大丈夫です)。

あとは、オリジンの方にアクセス制限を行います。こちらは念のための設定ですが、無駄にアクセスされないためにも設定しておいて損はないと思います。アクセス制限の方法はいくつかありますが、今回は簡単にBASIC認証でやってみました。おまけで後ほど出てくるコマンドもBASIC認証に対応させみました。

コメントフォームを追加

次はコメント機能を直していこうと思います。今回は「静的サイト コメント」で出てきたDisqusというコメントサービスを使ってみます。

Disqus – The #1 way to build your audience

Disqus offers the best add-on tools for websites to increase engagement. We help publishers power online discussions with comments and earn revenue with native advertising.

テーマによって導入手順が異なるため詳細な説明は省かせていただきますが、WordPressのプラグインで導入するのではなく、HTMLタグで導入します。「Install Disqus」を押すと「WordPress」の選択肢がありますが、こちらではなく、手動で登録するため、ページ下部にある「I don’t see my platform listed, install manually with Universal Code」からコメントフォームを表示するHTMLタグを取得できます。

このタグで使用しているテーマのコメント表示部分(おそらくcomments.phpの中)の<?php if (comments_open()) : ?>~~~<?php endif; ?>内を書き換えてあげるだけでコメントフォームを設置することができます。

<?php do_action('bp_before_commentpost'); ?>

<div id="commentpost">

<?php if (comments_open()) : ?>
    [取得したHTMLタグ]
<?php endif; ?>

</div>
<?php do_action('bp_after_commentpost'); ?>

完成イメージは上記の通りです。これでコメントフォームが表示されれば完了です。

自動でコミットするようにする

今のままでは、記事などを更新した後は手動で静的化を行い、NetlifyでのデプロイをするためGitに変更を登録する作業が必要になります。しかし、それは限りなくめんどくさいので…最後に、Netlifyへのデプロイを自動化してみようと思います。NetlifyではGitの指定リポジトリの指定ブランチコミットされた内容を自動的にデプロイしてくれるため、ここでは静的化とオリジンドメインの隠蔽、コミットまでを行う処理を自動で動くようにしてみます。

#!/usr/bin/sh

##### 設定 ##### ##### ##### ##### ##### ##### ##### #####

# サイト情報
SITE_DOMAIN="koneta.click(要修正)"          # 公開用URL
ORIGIN_DOMAIN="origin.koneta.click(要修正)" # オリジンURL

# 作業ディレクトリ
WORK_DIR="/var/path/to/wordpress/(要修正)"

# BASIC認証
BASIC_USERNAME="basic_username(要修正)"
BASIC_PASSWORD="basic_password(要修正)"

##### ##### ##### ##### ##### ##### ##### ##### ##### #####

SITE_URL="https://$ORIGIN_DOMAIN"

cd $WORK_DIR
rm -dfR $WORK_DIR$ORIGIN_DOMAIN

# サイトを静的HTML変換
wget --mirror \
     --no-parent \
     --page-requisites \
     --convert-links \
     --adjust-extension \
     --restrict-file-names=windows \
     --no-verbose \
     --http-user=$BASIC_USERNAME \
     --http-passwd=$BASIC_PASSWORD \
     $SITE_URL

# 隠蔽単語を置換
find $WORK_DIR$ORIGIN_DOMAIN -type f | xargs sed -i -e "s|$ORIGIN_DOMAIN|$SITE_DOMAIN|g"

# 現座時刻を作成
now_date=`date +'%Y/%m/%d %H:%M:%S'`

# 変更内容をコミット
git pull
git add -A
git commit -m "[modify] ブログ更新更新 $now_date"
git push origin master

実際のコマンドは上記のようになるのです。この「(要修正)」部分をご自身の環境に合わせて修正後、cronなどで定期実行されるようにすることであとは放置しているだけで更新の変更箇所がNetlifyに反映されます。これにて作業は押しましです。あとはサイトの更新をするだけです！

終わりに

ここまで長い記事を書いたのは初めてです。技術系記事はほとんど自分用の備忘録で書いていますが、果たしてこの記事が役立つことはあるのか…でも静的化は楽しかったので良しとします。最近は静的サイトジェネレータでのサイト作りが増えていて、WordPressは重い遅い脆弱と散々に言われていますが、個人的には使い慣れていることもありまだまだ使っていきたいと思います！

追記 2021-01-03

静的化したファイルのホスティング先をGoogleさんのところのFirebase Hostingに変更しました。その時の作業ログも記事にしましたので、気になった方は覗いてみてください。

静的化したWordPressのホスティング先をNetlifyからFirebase Hostingに変更しました

静的化したWordPressをホスティングするもページ表示がなんだかモッサりしているなぁと感じたNetlifyからFirebase Hostingに鞍替えし、その作業をまとめます。

じゃあどうするか…と考えてみると、WordPressは動的な仕組みとはいえ、ページに出す記事自体は固定のものなので、いっそのこと静的ファイルにしてしまえばいいのではと考えました。静的ファイルになることで、煩わらしい更新作業や管理画面への不正アクセスを恐る必要がなくなります。さらに副産物として、作成した静的ファイルをホスティングサービスに設置することで、高速に表示してもらえるようになります。

というわけで今回はWordPressで動ているサイトからプラグイン不要で静的ファイルを生成し、それを「Netlify」というホスティングサービスに設置することで高速安心な静的サイトを構築していきたいと思います。(wgetコマンドが実行できる環境構築とNetlifyの細かい設定については触れません…。)

静的化の注意点

さて、導入部分ではさも静的化がメリットまみれのように書いてしまったので、ここでWordPressを静的サイト化するデメリットについて触れておこうと思います。

動的部分が動かなくなる

まずは、当然ながらWordPressの動的部分が動かなくなります。記事部分のような静的でも問題ないところを抜くと、よく使われていそうな動的部分はサイト内検索や記事へのコメント機能などの機能が動かなくなります。また、テーマやプラグインによっては意味がなくなったり、正しく動作しなくなるものもあると思います。

テーマやプラグインなど独自のものについては、サイトごとに対応方法も異なるため何とも言えませんが、コメント機能とサイト内検索については外部のサービスを活用することで静的化と同じように動作させることができるそうです。 検索でしたら「Google カスタム検索」コメント機能では「Disqus」というサービスが使えそうです。

ページが増えると静的化に時間がかかる

もう一つのデメリットは今回の方法では記事数が増えると静的化の処理にとても時間がかかるという点です。今回の方法はファイルを作成する際に実際にページにアクセスして返ってきた内容を保存しています。 そのため生成するすべてのページにアクセスする必要があります。これはカテゴリやタグごとの一覧ページもひとつずつ保存する必要があるため、記事が増えることで、一覧ページも増えるため静的化がどんどん遅くなってしまうわけです。

もう運営・更新するつもりがないサイトではこれらのデメリットはあまり関係ありませんが、自分が静的化したいサイトでデメリットを許すことができるかは確認する必要があると思います。

静的化するよ

さて、デメリットについても書きましたので、いよいよ静的化です。静的化するにあたり動かなくなる部分はこのタイミングで消しておきます。私のサイトの場合ではコメント,ピンバック,検索でした。また不要な固定ページもありましたので合わせて削除しました。

準備が完了したのでwgetしていきましょう。wgetをする際はローカルでもリンクが切れないようにするオプションと、ページ内で使用している画像なども一緒にダウンロードするオプション(+α)を設定して実行します。

$wget --mirror \
      --no-parent \
      --page-requisites \
      --convert-links \
      --adjust-extension \
      --restrict-file-names=windows \
      --no-verbose \
      [サイトのURL]

このコマンドを実行することで指定したURLからリンクを辿っていきたどり着いたページがHTMLファイルとして保存されます。あとはこのファイルを煮るなり焼くなりで公開することができます。ちなみに設定しているオプションの効果は以下の通りです。

ファイルを設置するよ

最後にやっとの思いで作成したファイル達を静的ホスティングサービスで公開していきたいと思います。今回はタイトルにもある通りNetlifyというサービスを使います。Netlifyは静的なサイトを簡単高速に提供できるWebサービスで、公式サイト曰く、わずか3ステップでWebサイトを公開できるようです。

Netlifyにファイルを設置するにはGitリポジトリを使います。Netlifyでは、GitHub, GitLab, Bitbucketのいずれかで作成したリポジトリを接続することで簡単にデプロイすることができます。操作の詳細は省きますが、(Gitの操作ができれば)簡単にできると思います。デプロイ後はドメインやSSLの設定を行うことで普通のWebサイトとして公開することができます。

最後に

さて、ここまでWordPressサイトの静的化について書いてきました。もともとはもう更新する気のないサイトを放置しておくのが怖かったというところからこの作業を始めたのですが、作業を進めていくにつれだんだん楽しくなり、今書いているこのサイトも静的化したくなってしまいました(実際に静的化しちゃいました)。

今回は更新がないサイトということで、簡単に必要最低限やってきましたが、更新があるサイトとなると追加で気にしなくてはいけないことが増えていきます。そんなわけで続編として、更新があるWordPressサイトの静的化の手順もまとめていきたいと思います。

追記 2020/06/01

続編の記事を公開しました！

続・WordPressをwgetとNetlifyでお手軽に静的サイト化する話

前回のWordPress静的化から発展し、今回は今ご覧になっているこのサイトを静的化していきます。

今回の登場人物

WordPress … サイトやらブログやら簡単に作れるCMS
Netlify … 静的ホスティングサービス
GitHub, GitLab, Bitbucket … Gitホスティングサービス。 私はGitLab派！