SSGを知る②:最近の静的サイト・ジェネレータ事情 | from about GitLab.com

法律: IT メディア 解説記事 ウェブ制作 フノス(訳者)

  引き続き、静的サイト・ジェネレータ特集です。
 前回は、「静的サイトとは何か」というような内容で終わってしまいましたが、いよいよ本題です。

  静的サイト・ジェネレータって何でしょう。
 というか、なんのためにどうやって使うものなの。
 どんなことにむいているの。できないことって何。
 GitLab Pagesで使う時の約束事は?
                        などの疑問にお答えします。

  

  【前回の記事】 SSGを知る①:静的 vs 動的 ウェブサイト

  【次回の記事】 SSGを知る③:様々な静的サイト・ジェネレータを使うための予備知識

  
 注:今回は、ウェブ開発に関する知識をある程度持ち合わせている人を対象にした記事です。
 静的サイト・ジェネレータに興味があり、特にGitLab Pagesへのデプロイを真剣に考えている方は、ぜひご一読ください。


 

  

 
   最近の静的サイト・ジェネレータって、どのへんがいいの?

  静的サイト・ジェネレータとは、静的サイトの作成を自動的に行ってくれるソフトウェアのことです。コード記述をする時には、変更をすぐさま反映できる利点を活かして、動的な処理がなされることが多くあります。
 なので、SSGの特性を「コード記述は動的に、発表するものは静的に」と言い表す場合があります。
 セキュリティリスクがほとんどなく、それなりに良いウェブサイトを作成できることが最大のメリットです。

  SSGの良さは、コード記述が効率的なことと、お金がかからないこと(特にウェブ・ホスティング関係)、そしてページの読み込み時間を動的サイトよりも短縮できることです。

 また、アクセス数が突然増加しても、静的サイトがアクセス不能になることはほとんどありません。なぜなら、動的サイトよりも仕組みが単純で、サーバーにかかっている負担が少ないからです。

  注:この仕組みについてもっと詳しく知りたい方は、前回の記事をご覧ください。


 

  SSGの構造

  SSGには、静的サイト開発をより早く失敗せずに終わらせることが求められています。そのため、ソフトウェアの構造としてはやや独特ですけれど、構造自体が難しいわけではありません。
 主に次の部分に分かれています。

  開発環境

 開発環境、またの名をプラットフォームは、SSGを作り上げているプログラミング言語によってほとんど決定します。プログラミング言語が違えば、設定やカスタマイズの方法、それからパフォーマンスの癖などが違ってきます。
 SSGは Ruby、Python、Node JSなどで記述されているものが多く見られます。

 

  テンプレート・エンジン

  ウェブページを作りたい人なら、さすがにテンプレート・エンジンが何であるかはわかっておいた方がよいみたいです。
 テンプレート・エンジンは、動的言語で記述されています。サイトの構造を決定しておくもので、入れておくとページ作りが大変にはかどります。
 代表例: LiquidHamlSlim (Ruby)、Twig (PHP)、Swig (JavaScript)
 

  たとえば、Liquidテンプレート・エンジンを使ってページを記述すると、このようなHTMLファイルが作成されます。

======================
<!DOCTYPE html>
 <html lang="en">
     {% include head.html %}
 <body>
     {% include header.html %}
     <main class="content">
          {{ content }}
     </main>
     {% include footer.html %}
 </body>
 </html>
======================
 「head、header、footer」という3つの.htmlファイルが挿入されていることがわかりますね。
 Liquidの場合、この3つのファイルがテンプレートとして自動的に挿入されます。挿入しているファイル自体は静的ですが、ファイルを自動で入れる際に、動的な言語が必要なようです。
 {{ content }}の部分に、ページの内容が記述された別のファイルが入るので、その部分がページ毎に異なります。

 こうしてつくられたページはウェブサーバーに収容される前に、全てのファイルをコンパイルして、きちんとしたHTMLファイルに変換されます。
  この工程をビルドといいます。

 

  これらのシステムの利点


  マークアップ言語

  マークアップ言語とは、コンピューターの中で文書を書くために開発されたシステムのことです。
 決まった作法に従って文章を書くだけで、機械で表示できる形式に変換できます。まさに機械にも人間にも分かりやすいスグレモノ。
 単に文字を書くだけでなく、文字に色を付けたり、リンクを入れたりと、エフェクトを添加することもできるので、サイトを作る時には是非とも活用したいものです。

 とくに軽量マークアップ言語と呼ばれる部類は、覚える作法もそこまで多くなく、様々なテキストエディターで記述できるようになっています。
 あなたが書きたいコンテンツに合ったものを選びましょう。

  ウェブコンテンツも作りやすい特性上、ほとんどのSSGがマークアップ言語に対応しています。少しマイナーかもしれませんが、 AsciiDocTextileReStructuredTextなども軽量マークアップ言語の一種です。

  マークアップ言語にmarkdownを使っているSSGでも、たいていmarkdownエンジンを選ぶことができるようになっています。たとえば、Rubyで記述されたMarkdownエンジンを少し紹介すると、KramdownRDiscountRedcarpetRedClothあたりですね。

  markdownでページを書くと、初めの方に「フロントマター(front matter)」というページの情報を載せる項目があるのです。
 次に例示するのは、Jekyll例示サイト「example.md」ファイルとMiddleman例示サイトの「example.html.md」ファイルに書かれているフロントマターです。どちらも同じ内容のもの使っています。

======================
---
 # front matter (3つの項目に分かれている)
title: "Hello World" # 記事タイトル
date: YYYY-MM-DD HH:MM:SS # 本来は更新日時が "2016-04-30 11:00:00"のように表示される
author: "Foo Bar" # 作者
---

 # An h1 heading

 Some text.
======================

 フロントマターは変数です。テンプレート・エンジンに代入させる設定をすると、フロントマターの内容がそのままサイトのデザインに組み込まれるようになります。

 Liquidテンプレート・エンジンの場合だと、次のように設定します。

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

 今回のフロントマターの場合、HTMLに直された時には次のようになります。
 

======================
<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>
======================



 プロセッサー

  プロセッサーはコンテンツを作る時に使う言語の定型文セットのようなものです。コードを打つ手間が省け開発が簡単になるほか、コンパイルする時もバグの心配が少なくて済みます。
 たとえば、CSSなら SassStylusが、JavaScriptなら CoffeeScript などが有名です。

  どれだけ短くなるか、同じ設定を通常のCSSとSassで書いて比べてみましょう。

  通常のCSS

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

  Sassで書いた場合
======================
$clr = #333
 h1
  color: $clr
  padding-top: 30px
 p
  color: $clr
======================
 まず最初に、「$clr」で色を指定してから、「color」の項目で代入させています。Saasには「$clr」のような変数があり、複数個所で同じ設定が簡単にできるんです。
 { }(中括弧)や ; (セミコロン)での区切りもありませんね。これがもっと長文化すると、入力する文字数も少なめになることがわかりますよ。

 そして、このように、短くて単純な設定をし終えたら、後は自動的に普通のCSSに変換してコンパイルされます。
 本当はもっと面白い機能がたくさんあるのですが、それはちょっと長くなるので、ここでは割愛します。
 

  もう一度いいますけど、この2つのCSS設定、どっちも内容同じですからね。

 

  ディレクトリの構造

  静的サイトを構成するディレクトリの配置は、SSGによってそれぞれ異なります。
 SSGを使い始める前に、そのSSGがどのような「ファイルツリー」を構成しているかについてきちんと確かめておいてください。大切です。
 「サイトが何でかビルドしない」という人の大半が、ファイルを適切に配置できていません。
 その原因は、ファイルツリーをほとんど理解できていなかったり、そこの説明を読み飛ばしているところにあります。

 Hexo structureMiddleman structureJekyll structureなど、各SSGの説明をよく読んで、新しく作ったファイルを正しいディレクトリに入れてください。


 

  SSGを選ぶときに参考にしたいポイント

  ディレクトリの構造の好き嫌いなどの、基本的な機能についてだけでなく、
 ビルドイン機能もSSGを選ぶ重要なポイントです。
 これがあるのとないのとでは、サイトを作る手間の桁が違う場合もあります。
 最低限、次の3項目があるかどうかをチェックしてください。

   Blog-Aware SSGs(ブログ対応SSG)
 最近の静的サイト・ジェネレータは、ブログの制作に対応していることが特色です。
 ブログを作るのに、記事を入れておくためのデータベースや、サーバで処理しなくてはならないファイルをわざわざ作らなくても、コンテンツの拡充を楽に行えます。
 

  コンテンツを日時順に並べたり、アーカイブリストを作ったり、「ブログといえば」というコンテンツを作ることができるんですよ。

  基本的には、ファイルツリーとテンプレート・エンジンを使ってサイトを作っていきます。記事はファイルツリーの中の「posts」ディレクトリに入れられることがほとんどです。それにテンプレート・エンジンのデザインが自動で適用されていきます。
 この特定のディレクトリ内にある記事に、テンプレートが自動対応する機能が「posts dynamically」などと説明されていることがあるので、覚えておきましょう。
 

  Liquidテンプレートを使ったブログを作るとして、全てのページに何らかの処理を一括でかけるfor loopという設定があります。

======================
<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 in site.posts %}の部分)、

 番号の付かないリストとして日付順に表示し
 (<span>{{ post.date }}</span>)、

 それぞれの記事タイトルに、あてはまるページのリンクURLをつなげる
 (<a class="post-link" href="{{ post.url }}">{{ post.title }}</a>)

 ようにしてあります。
 

  もちろん、ここにあるのはあくまで一例ですから、HTMLを変更すれば他の一括処理も可能です。
 たとえば、同じカテゴリの文章だけを表示したりして、検索しやすくするという設定もできます。写真や本などのコレクションごとに分類してもおもしろいですね。

 デザインはSSGがテンプレート・エンジンを自動適用するので、これといった心配がありません。


 

  静的サイトに載せられるコンテンツ

  静的サイトは、HTML、CSS、JavaScriptでできたコンテンツなら、いくらでも載せられます。
 もっといえば、クライアントサイド・プロセシングができる言語でできていれば、何でもありです。
 

  対応言語とファイル形式

  対応している双方向サービス

 

  対応ユーティリティ

  静的サイトではできないこと


 これらの動作は全てサーバーサイドでの処理が必要です。
 特に、静的サイトのみを受け付けるウェブサーバーではこれらが使えないメカニズムについては、このシリーズの最初の記事でお伝えしました。

 

  SSGではできないことを外部ツールで補う

  ユーザー認証

  ユーザー記録ができないことから、ユーザー認証もできないことがわかります。
 ですが、Firebaseなどの外部サービスのユーザー認証を使えば、静的サイトでもユーザー認証ができるようになります。詳しくはこちらのページをご覧ください。
 

  コンテンツ・マネジメント

  SSGディレクトリに、ウェブブラウザから編集を加えることが不可能なわけではありません。
  Teletext.ioが出しているサービスからなら、それが可能です。ただし、あくまでできることは手直しのみで、新しくページを作成することができません。
 お使いのウェブブラウザでサービスを開始する方法は、ユーザー説明書に書いてあります。
 

  コンタクトフォーラム

  コンタクトフォーラムも外部サービスとの連携で掲載できるようになります。
 たとえば、 FormspreeFormKeepWufooFoxyFormGoogle Formsなどが使えます。
 どうしてもメールスクリプトを使いたい場合には、SendGridを使うという方法もあるようです。
 

  JavaScriptが使えない場合

  静的サイトにJavaScriptを載せることは自由ですが、ブラウザがJavaScriptに対応しておらず、まったく動作しない場合があります。
 その場合は、JavaScriptが動作していない旨を相手に伝える必要があります。
 そのときに、<noscript>タグをウェブページに追加します。JavaScriptが使えなかったときにだけ表示されるはずです。
 

======================
<noscript>Please enable JavaScript on your browser for a better experience with this website!</noscript>
======================
         あるいは
======================
<noscript>当ウェブコンテンツを十分にお楽しみいただくため、お使いのブラウザでJavaScriptの使用を許可するように設定してください。</noscript>
======================

 

  おわりに

 今回の記事はここでおわりですが、静的サイト・ジェネレータの使い方が、読む前より少しだけリアルに想像できるようになってくれたら幸いです。
 動的サイトの機能性は、確かに目を見張るものがあります。
 しかし、今回紹介した通り、静的サイトでもできることは思ったよりもたくさんあったでしょう。この時点で欲しい機能が全部見つかった!という方は、ぜひともSSGの使用をお考え下さい。
 

  次回は第3回、このシリーズは最終回ですけれども、GitLab Pagesで様々なSSGを使った実例をご紹介する予定です。
 SSGごとにどのようなCI設定をすればよいのかについても、ある程度ご説明しますので、ぜひご期待ください。
 

  様々なSSGで作成したサイト見本をこちらのページ(GitLab Pages公式)に掲載しています。新しいSSGを使ったサンプルも受け付けております。

 

 

  関連記事

 

 

 2017-09-23 11:58:35 / Hnoss
原文サイトを表示
[ 原文 ] https://about.gitlab.com/2016/06/10/ssg-overview-gitlab-pages-part-2/
Creative Commons License この作品は、クリエイティブ・コモンズ・ライセンスの下でライセンスされています。
クリエイティブ・コモンズ・ライセンス