Summary
perlで書かれた小さな静的サイトジェネレーターDapperは実用に耐えるのか。ある程度の規模のサイト運営を視野に、サイト構築にかかる所要時間をチェックしてみた。
Dapperは競合他ソフトに比べて必ずしも不利というわけではない。しかし、評判の高いHugoに比べるとかなり遅いとの結果が得られた。快適なサイト運営を実現するにあたっては、データ管理に何らかの工夫が必要かもしれない。
Introduction
Dapperは、別記事『perlベースの静的CMS : Dapperを試してみませんか？』にて紹介したとおり、シンプルでわかりやすく使いやすそうな静的サイトジェネレーターである1。
2020年2月初頭現在、私はこのDapperが本格的に自サイトの運営に使えるか検討中なのだが、その過程で、『多量のページを扱う場合の静的サイトジェネレータのパフォーマンス』という記事を発見した。
確かに性能評価は必要だ。一見使いやすそうでも、対象サイトの規模がちょっと大きくなると手も足も出なくなってしまうというのでは困る。この記事に触発されて、dapperの簡易的な性能テストとして「1000記事からなるサイトの構築にどれぐらい時間を要するか」を試してみることにした。
私の事前の予想（期待）は、次のようなものであった。
いうてもテキスト処理を得意とするperlベースのシステムだからね。他の同類ソフトと比べて結構いい勝負をしてくれるのではないか。
Material and Method
今回は、記事ソースに見立てた1000個のmarkdownファイルを用意し、これを、Dapperにかけてサイト構築、すなわちHTMLファイルの生成をやらせる。他方、爆速な静的サイトジェネレーターとの評価が高いHugoにも同じデータを処理させる。両者の所要時間を比較し、Dapperの有用性について検討する。
データの準備
まずは処理の対象となるソースファイルとして、前述の参考記事の中でも使われていたhttps://gist.githubusercontent.com/DominikAngerer/b4a29b5ec9a69fc09546882586bc2d6b/raw/aeab6fdd6dbbcb7626e2ef2a8123e677cc19dcc1/lorem-markdown.md
をダウンロードした。
Dapper用として、このmdファイルにFront Matter（サイト名・およびレイアウトファイル名を指定した2行のパラメータ設定）を付加した上で1000コピー作って、Dapperのソースファイル用ディレクトリ中に配置した。
次に、Hugo用として、同じmdファイルを1000コピー作って「コンテンツ用ディレクトリ」に配置した。
サイト作成
それぞれのテスト用ディレクトリの中でtimeコマンドを通してサイト構築用コマンドを実行し、htmlファイル群を生成させ、所要時間をチェックした。
使用したソフトのバージョン
検証に使用した両ソフトのバージョンは以下の通りだ。
- Hugo Static Site Generator v0.63.0-DEV linux/amd64 BuildDate: unknown
- Dapper version 0.18
Result
それぞれのサイト構築コマンドの実行結果を示す。
hugoの場合
$ /usr/local/time -p hugo
中略
Total in 2587 ms
real 2.63
user 4.75
sys 0.38
dapperの場合
$ /usr/local/time -p dapper build
中略
Project built.
real 23.42
user 23.05
sys 0.35
Discussion
参考にさせてもらった記事では、同等規模のサイト構築にHugoで1.726秒かかったということなので、私のマシンはその70%の処理能力ということか。
当該参考記事での試験結果から単純計算を試みれば、おそらくDapper君はGatsByやVuePressには勝てる可能性が高そうだ。決して悪いパフォーマンスではない。しかしながら、私の実験ではHugoに比べるとDapperのサイト構築には10倍の時間がかかった…。予想以上の差での敗北。いやHugoの評判は伊達ではなかったというところか。
1000ファイルからなるサイトは決して現実的に大規模とはいえない。ブログを毎日地道に継続執筆していけば、3年弱でこれぐらいの規模には確実に到達するわけだ。サイトデータ更新に20秒強かかるとなると、寝る前に一回だけ実行とかであればよいが、試行錯誤・推敲を繰り返しながらその日のうちに何度も構築をかけるというスタイルで臨むにはいささかストレスが溜まる待ち時間と言わねばならないだろう。
もちろん、所属組織のちょっとした紹介サイト2を作りたいといった要請であれば、dapperの処理速度は全く問題にはならず、充分に速く処理を済ませてくれると言ってよいだろう。その上、余計なものが出来ない分かえってコンテンツの管理がしやすく、テキストはmarkdownを利用してちゃっちゃと揃えることができる。そうした点で、dapperは誠に間尺にあった選択となりえる。
しかし、大規模なサイトを相手にするならば、再構築にかける必要のないソースファイルはbuild前に別所に退避しておくなどの対応を考えるべきかもしれない。もちろん、build→アップロードを実行するシェルスクリプトを作っておき、それを呼び出したら結果を待たずに寝てしまうというのも一つの対処ではあるだろうが。