2022.01.27

SSG パート2 : モダンな静的サイトジェネレーターとは？ #GitLab #GitLab Pages #SSG #静的サイトジェネレーター #静的ウェブサイト

GitLab

この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。

本ブログは「GitLab」社のブログで2016年6月10日に公開された「SSGs Part 2: What are modern static site generators」の日本語翻訳です。

SSG パート2 : モダンな静的サイトジェネレーターとは？

投稿者：Marcia Ramos

今回はパート2です。モダンな静的サイトジェネレーターの概要をご紹介します。

静的サイトジェネレーターとは何でしょうか？何に使用するのでしょうか？なぜ使用する必要があるのでしょうか？使用制限はあるのでしょうか？GitLab Pagesではどのように使用できるでしょうか？

これらの質問にピンと来た方は、このブログシリーズをぜひご覧ください。「静的サイトジェネレーター（SSG）」というテーマ共通で3つのブログをアップしています。

ひとつ前の記事「パート1: 動的Webサイトと静的Webサイト」では、両者の違いやメリット・デメリットを簡単に説明しました。

「パート3：GitLab Pagesを使用してあらゆるSSGサイトを構築」もぜひご覧ください。

注：このシリーズは、ウェブ開発に精通している方、静的サイトジェネレーターに興味があり、GitLab Pagesでのサイト構築をお望みの方を対象としています。

現代の静的サイトジェネレーターの利点

静的サイトジェネレーター (SSG) は、ウェブ開発を自動化して、動的に書くことで静的なサイトを出力するために作られたソフトウェアです。つまり、動的にコーディングし、静的に公開するのです。無駄な努力は必要ありません。

SSGが最も魅力的なのは、迅速にコーディングでき、ウェブホスティングにかかるコストを削減でき、サーバーサイドの動的ウェブページと比較してページの読み込み時間を驚くほど短縮できるということです。また、同時に多くのアクセスが発生した場合、静的サイトは動的サイトよりもサーバーの過負荷によるクラッシュが起こる可能性が低くなります。

注：より詳しく知りたい方は、本連載の入門記事である「SSG パート1: 静的ウェブサイト vs. 動的ウェブサイト」をお読みください。

SSGの構造

SSGは、静的サイトの開発をより速く、より反復的に行うための機能を組み合わせた構造を持ちます。以下のリストにある項目を一つずつ説明していきます。

環境
テンプレートエンジン
マークアップ言語
プリプロセッサー
ディレクトリ構造

環境

環境はプラットフォームとも呼ばれ、基本的にはSSGが書かれたプログラミング言語で構成されています。それによって、SSGの構成やカスタマイズ、性能が変わってきます。
例：Ruby、Python、Node JS

テンプレートエンジン

テンプレートエンジンは、サイトの動的な構造全てを左右させる、非常に重要なものです。快適に使用できるように、必ずテンプレート付きのSSGを選びましょう。
例： Liquid、Haml および Slim (Ruby)、Twig (PHP)、 [Swig] (JavaScript)

イメージを膨らませるために、Liquid Templating Engineを使用しているHTMLファイルの例を見ていきます。

<!DOCTYPE html>
<html lang="en">
    {% include head.html %}
<body>
    {% include header.html %}
    <main class="content">
        {{ content }}
    </main>
    {% include footer.html %}
</body>
</html>

お察しの通り、サイト全体で繰り返される3つのコンテンツ用ファイル（head、header、footer）があり、このテンプレートを使用するすべてのページに含まれています。唯一異なるのは、そのページの {{ content }} です。これは別のファイルに書かれたもので、このタグを使用してテンプレートにも動的に含めています。最終的に、すべてのファイルはウェブサーバーに格納される前に、通常のHTMLページにコンパイルされます。このプロセスをビルドと呼びます。GitLab Pagesを使用すると、あらゆるSSGをビルドできます。

フラットHTMLとの優位性
* タイポを最小限に抑制：すべてのファイルを大幅に削減し、読みやすさが向上します
* 繰り返しの回避：サイト全体で繰り返されるすべてのブロックが、あらゆるページに同等に含まれます
* アップデートの高速化：footer.htmlファイルの内容を変更すると、サイト全体に反映されます

マークアップ言語

マークアップ言語は、何らかの方法で構文的にテキストと区別できるように文章を記述するシステムです。軽量マークアップ言語は、簡潔な構文を持ち、あらゆるテキストエディタを使った編集が容易になるように設計されています。

コンテンツを書く際に使用されるもので、ほとんどのSSGがコンテンツを書く目的でマークダウンエンジンを使用しています。しかし、AsciiDoc、TextileおよびReStructuredTextなど、軽量マークアップ言語は他にも数多くあります。

マークダウンを採用しているSSGでは、通常どのマークダウンエンジンを使用するかを選択できます。サイト構成で設定されています。
例（RubyでMarkdownが実装されているもの）： Kramdown、RDiscount、Redcarpet、RedCloth

マークダウンで書かれたブログやページのほとんどが、そのページや記事に関する情報を含む front matter（前書き的）な章から始まり、そのすぐ下にコンテンツがあります。これは、Jekyllサイトで使用された example.mdファイルと、Middlemanサイトで使用された example.html.md ファイルです。

---
# front matter (between three-dashes block)
title: "Hello World" # post or page title
date: YYYY-MM-DD HH:MM:SS # date and time, e.g. "2016-04-30 11:00:00"
author: "Foo Bar" # a common variable to exemplify
---

# An h1 heading

Some text.

front matterの変数は、上の例では title 、 date 、 author ですが、サイト全体でテンプレートタグを使って呼び出すことができます。Liquidの場合、次の通りに書いてみると…

<h2>Title: {{ page.title }}</h2>
<p>Date: {{ page.date }}</p>     
<p>By {{ page.author }}</p>

次のように出力されます：

<h2>Title: Hello World</h2>
<p>Date: 2016-04-30 11:00:00</p>
<p>By Foo Bar</p>

今回の例では、コンテンツはシンプルに出力されます:

<h1>An h1 heading</h1>
<p>Some text.</p>

プリプロセッサー

プリプロセッサーもまた、開発スピードの向上のために作られたものです。コーディングを簡素化し、独自のファイルを標準のものにコンパイルします。
例：Sass、Stylus（CSS向け）　CoffeeScript（JavaScript向け）

再度イメージを膨らませるために、CSSで直接書かれたコードブロックと、Sassで書かれたコードブロックを確認してみましょう。

CSS:

h1 {
  color: #333;
  padding-top: 30px;
}
p {
  color: #333;
}

Sass:

$clr = #333
h1
  color: $clr
  padding-top: 30px
p
  color: $clr

大規模なスタイルにおいて、中括弧 { } とセミコロン ; を保存することは、誰が入力しているかで変更部分が多くなります。また、Sassの変数（例えば、上記の $clr ）を使って、いくつかの標準設定を定義し、スタイルシート全体に適用できます。最終的にはすべて通常のCSSにコンパイルされます。このブログでは深堀りしませんが、プリプロセッサーにはさらに面白い機能や利点があります。

ちなみに、上記Sassの例では、その上のCSSコードに正確にコンパイルされます。

ディレクトリ構造

ディレクトリ構造はSSGごとに異なります。SSGを使い始める前に、ファイルツリーについて学んでおくことが重要です。そうしないと、構造を適切に使用せず、理解不能なビルドエラーに直面するかもしれません。
例：Hexo構造、Middleman構造、Jekyll構造
新しいファイルを正しいディレクトリに追加することが重要です。

ビルドインのSSG機能

標準的なコンポーネントに加えて、より簡単に、より速く静的サイトの構築やプレビューを行える機能が数多く組み込まれています。例えば、次のようなものです。

ほとんどのSSGには、サイトのローカルでのプレビュー用サーバーが予めインストールされています
また、インストールパッケージにはLiveReload プラグインが含まれているものもあるので、保存するたびにブラウザでページ更新することは不要です
ほとんどが、サポートされているプリプロセッサー用のビルドインコンパイラを提供しています

ブログを意識したSSG

最新のSSGにおける最も魅力的な機能の一つは、データベースやサーバーサイドのみで処理されたファイルにブログやブログの中身を保存することなく、ブログのコンテンツを管理できることです。

ブログを意識したウェブサイトジェネレーターは、新しい順のコンテンツリストやアーカイブリスト、ブログスタイル機能など、ブログスタイルのコンテンツを作成します。SSGはどうやって実現するのでしょうか？

ファイルツリーとテンプレートエンジンを使用していきます。ファイルツリーが post の特定のディレクトリを定義し、テンプレートエンジンがブログを動的に呼び出します。

以下の図のように、投稿を for ループで表示することで、1つのページに表示できます。（Liquid使用）

 <ul>
    {% for post in site.posts %}
      <li>
        <span>{{ post.date }}</span>
        <h2>
          <a class="post-link" href="{{ post.url }}">{{ post.title }}</a>
        </h2>
      </li>
    {% endfor %}
  </ul>

このコード（ {% for post insite.posts %} ）は、サイト投稿内の各投稿（post）に対して、すべての投稿が番号なしリストのアイテムとして、それぞれのパスへのリンクが表示されることを意味しています。

もちろん、必要に応じてHTMLの構造を変更することも可能です。また、ブログを意識した構造を利用して、さまざまな種類の動的挿入を行うことができます。例えば、写真集や本などのように、同じカテゴリーの中で同じものを複数表示させるために使用できます。そのため、新しいアイテムを追加するたびに、SSGはテンプレートエンジンを使ってコレクションをまとめていきます。

対応コンテンツ

静的サーバーは、ブラウザで解釈されるあらゆる言語やスクリプトを完全にサポートします。これは、クライアントサイド処理として知られています。静的なサイトは基本的に、構造（HTML）、レイアウトやスタイル（CSS）、動作（JavaScript）の3つの要素で構成されていることを覚えておきましょう。

対応言語とファイル拡張子

一般的なファイル拡張子： .html / .css / .js / .xml / .pdf / .txt
一般的なメディアファイル：画像、音声、動画、SVG

対応しているインタラクティブサービス（例）

コメントシステム（例：Disqus、Facebook Comments、その他多数)
ライブチャット（例：JivoChat、Tawk.to）
PayPal決済規格
Facebookソーシャルプラグイン
Twitterキット
Google Apps (例: Analytics、Adwords、AdSense 等)
サイト内検索エンジン（例：Google Search、Swiftype、Tipue)
メーリングリストやブログの購読（例：MailChimp)

対応ユーティリティ（例）

HTML/CSS/JSのフレームワークとライブラリ例：Bootstrap、Foundation、Normalize、Modernizr、Skeleton、jQuery、HTML5 Boilerplate、Animate.css
Schema.orgマークアップすることで、検索エンジンが当サイトのコンテンツをよりよく理解できるようになります。これは、数あるSEOのテクニックの1つです。
Sitemapsもまた SEOにとって重要です。例）Jekyll Sitemap plugin、Middleman Sitemap、Hexo Sitemap plugin

SSGの制約

ここまで、SSGでできることをご紹介してきましたが、次にできないことを見てみましょう。

ユーザー登録
管理者権限の保持
mail()関数によるメール送信
サーバーサイド言語やスクリプトの使用

このような動作は、このシリーズの最初のブログで説明した通り、サーバー側の処理に依存するため、静的なウェブサーバーでは対応できません。

制約の克服

認証
ユーザー登録や、アドミン権限を持つことはできませんが、Firebaseのようなツールを使えば、静的サイトへユーザ認証を追加することでセキュリティを強化できます。Firebaseのさらなる情報に関してはこちらをご覧ください。

コンテンツ管理
Teletext.ioを使えば、Webブラウザから直接SSGのコンテンツを編集可能です。新しいページを作成することはできませんが、ページ内容の編集は簡単にできます。Teletext.io チュートリアルから、ご自身のウェブサイトに実装する方法が学べます。

お問い合わせフォーム
当社の静的ウェブサイトでコンタクトフォームが利用できます。サーバーサイドのスクリプトを静的サーバーで処理することはできませんが、利用できるサードパーティのサービスがあります。

例えば、Formspree、FormKeep、Wufoo、FoxyForm、Google Formsなどの関連サービスがお試しいただけます。メールのスクリプトを制御したい場合は、SendGridのparseメソッドを試してみてください。

JavaScriptの無効化
JavaScriptベースのものはすべて、静的サイトに追加が可能ですが、ユーザーのブラウザでJavaScriptが無効になっているとスクリプトは動作しません。しかし、この問題を最小限に抑えるためにできることはあります。Webページに <noscript> タグを追加することで、JavaScriptが無効な場合にのみ表示されるメッセージを入れることができます。

<noscript>Please enable JavaScript on your browser for a better experience with this website!</noscript>

まとめ

静的サイトジェネレーターのロジックや賢く使う方法、できることとできないことが理解いただけたと思います。動的なウェブサイトが優れていることは確かです。しかし、すべての機能を必要としないのであれば、SSGが素晴らしい選択肢となるでしょう。

本連載の最終章となるパート3のブログでは、GitLab Pagesですでに稼働しているSSGの数多くのサンプルをお届けします。さまざまなGitLab CIの構成を見て理解し、ご自身で構成ができるようになると確信しています。

すでにSSGのサンプルプロジェクトが山ほど用意されていて、GitLab Pages公式グループで見ることができます。新しいSSGをコントリビューションしてくださることも大歓迎です。

GitLab.comのアカウントは既にお持ちでしょうか？ぜひアカウントを作成してください！繰り返しになりますが、GitLab Pagesを使用して任意のSSGを構築し、無料でホストできます。