HUGOで3000記事とか6000記事に対応できるのか?ビルドは3分くらいで完了。サーバーへのアップロードには30分くらいかかった

HUGOヒューゴ は、記事がたくさんあるサイトにも対応できるのか?

その結論と、HUGO の実行結果の紹介です。

結論 ⇒ HUGO は数千記事でも使えた

結論ですが、HUGOは記事がたくさんあるサイトでも対応できました。

記事数に応じて、ビルドやアップロードの時間は増えましたが、それでも HUGO は実用的に使えました。

ところで、静的サイトジェネレーターでまず気になるのが、『サイトのビルドにかかる時間』だと思います。

HUGO では、3000記事でも6000記事でも、3分くらいで終わりました。

3000記事のサイトは『業績チャート』のことで、6000記事は『業績チャート 米国』です。

記事が増えたときに、プレビューやビルドで『3分』もかかるとなると、毎日更新するようなブログで使うのは、ちょっと厳しいかもしれません。

ですが、機械的に生成した記事をウェブサイトにするには十分だと思いました。

自分の場合は、サイトの更新ペースが1か月~3か月に1回だったので、十分実用的に使うことが出来ました。

スポンサーリンク

3000記事のビルドにかかった時間 ⇒ 約2分30秒

3000記事のマークダウン (.md) のビルドにかかった時間です。

自分の場合は、2分30秒くらいでした。

以下は、HUGO の実行結果です。

[chart.srbrnote.work]
Building sites …
                   |  EN
+------------------+------+
  Pages            | 3809
  Paginator pages  |   61
  Non-page files   |    0
  Static files     |    6
  Processed images |    0
  Aliases          |   35
  Sitemaps         |    1
  Cleaned          |    0

Total in 146535 ms
⇒ 約2分27秒

[Public フォルダのプロパティ]
サイズ: 1.97 GB
ファイル数: 3,912、フォルダー数: 3,940

6000記事のビルドにかかった時間 ⇒ 約3分

6000記事のマークダウン (.md) のビルドにかかった時間です。

自分の場合は、3分くらいでした。

以下は、HUGO の実行結果です。

[us-chart.srbrnote.work]
Building sites …
                   |  EN
+------------------+------+
  Pages            | 6469
  Paginator pages  |   64
  Non-page files   |    0
  Static files     |    6
  Processed images |    0
  Aliases          |    1
  Sitemaps         |    1
  Cleaned          |    0

Total in 174139 ms
⇒ 約2分54秒

[Public フォルダのプロパティ]
サイズ: 1.49 GB
ファイル数: 6,541、フォルダー数: 6,533

こちらは記事は多いですが、画像データが少なめだったので、3000記事のときよりもサイズが小さくなっています。

3000記事のアップロードにかかった時間 ⇒ 約30分

サイトの更新は、HUGOヒューゴ が作成した Publicパブリック フォルダの中身を、サーバーにアップロードして完了します。

3000記事のサイトをレンタルサーバーにアップロードしたときは、だいたい30分かかりました(FFFTP 使用)。

このときにアップしたファイルは、ほぼ HTML ファイルのみです。

画像はすべて HTML に埋め込みました。

ところで、なぜ30分もかかったのか?

これは、ファイルとフォルダの数が多かったのが原因でした。

もともとは、画像の PNG が60000枚あって、サイト全体の再アップロードに5時間くらいかかっていました。

3000記事分のファイルとフォルダにプラスして、60000枚の PNG でした。

でも、5時間はちょっとキツイですよね。

あと、サーバーのファイル数制限にも到達しそうになりました。

なので、画像を全部 HTML に埋め込んじゃいました。

HTMLのサイズが大きくなるといったデメリットは、この際、妥協しました。

その結果、アップロード時間は30分にまで短縮できました。

そういうわけで、実は30分でも、かなり速くなったほうなのでした。

先に載せた HUGO の実行結果は、2つとも、画像ファイルを全部埋め込んだときのものです。

Python で PNG を Base64 にエンコードして、その文字列を img タグの src 属性のところに埋め込みました。

Base64 にエンコードしたことで、全体のファイルサイズは +40% 近くに増えましたが、ファイルの数は大幅に削減できました。

アップロード時間に関しては、差分だけアップする形にしたら、もっと速いのかもしれません。

ですが、自分の場合は、毎回全部の記事を新しくする必要がありました。

ちょっと極端な例だったかもしれませんが、HUGO の採用を考えていらっしゃる方の参考になれば幸いです。

スポンサーリンク
HUGO
シェアする(押すとSNS投稿用の『編集ページ』に移動します)
フォローする(RSSフィードに移動します)
スポンサーリンク
シラベルノート
タイトルとURLをコピーしました