「みんなの翻訳」は、世界中の文書をみんなで協力して翻訳するサイトです。

みんなの翻訳ロゴ
ブクタブ
翻訳サイト

カテゴリ一覧

このサイトについて 新規登録はこちら お試し翻訳

一覧

2017/07/28

メンテナンス終了のお知らせ

2017/7/25-2017/7/28に実施したメンテナンスは、2017/7/28/14:20に終了いたしました。 ご協力をいただき、ありが…

List

hanako

English⇒Japanese

Hnoss

English⇒Japanese

shikimi

English⇒Japanese

sysInfo

English⇒Japanese

ホーム > 翻訳記事

翻訳記事

SSGを知る①:静的 vs 動的 ウェブサイト | about GitLab.com / Marcia Ramos

  ウェブサイトは静的なものと、動的なもの2つに分かれますが、それらにはどのような違いがあって、どのような長所があるのでしょう。
 GitLab Pagesで扱えるのはどっちだろう?
 静的サイト・ジェネレータなんて聞きなれないな。なんだろう?

  そんな方のために、この記事を作りました。
 「静的サイト・ジェネレータ(SSGs)」について知っておくべきポイントをおさえた3連企画です。

 進行を大まかに説明します。

  パート1(この記事):動的 vs 静的ウェブサイト -それぞれの違い、長所短所について

  



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


 

  

 
  静的サイト、動的サイトとは?

  静的ウェブサイトとは、
 HTMLマークアップ言語  (主にサイトの文章)、
 CSS   (スタイルやレイアウトの設定)、
 JavaScript  (要素の動きの設定。フェードイン・アウト、ホバーなど)
 を組み合わせて作成したウェブサイトのことです。

 ページはこれらの言語で作られた単純なファイルとして、ウェブサーバー上にあるVPSなどに保管されています。

 私たちはウェブブラウザでURLなどを打ち込んでページに移動しますね。そのときに、私たちのブラウザ(クライアントと呼ばれます)は、ウェブサーバーにHTTPリクエストを送信します。
 実はここで「どのファイルの情報を欲しているか」という情報をサーバーに送っています。そのリクエストの返答(HTTPレスポンス)として返ってきたものを、ブラウザが解読して表示したものが、ウェブページです。
 
(訳者より: HTTPリクエストを「選局」、ブラウザが解読して表示することを「視聴」と捉えるなら、実はブラウザにはあくまで「ラジオ」のような機能しかないことがわかります。
 ウェブページが「放送局」、そしてウェブサーバーは、「発信基地」や「電波塔」に相当します。ブラウザは電波塔から出された指示に従って、ページを表示しています。)

 

  動的ウェブサイトの場合、これらの動作がやや複雑です。
 静的ウェブサイトにあるような、文章、スタイル、要素の動作などの項目の他に、様々な情報を付け加えなくてはなりません。

 たとえば、オンラインショッピングを例にとって説明しましょう。
 これは皆さんすぐにお判りでしょうけど、モノの価格や在庫状況などは変化していくものですよね。これらの情報をウェブページに反映させる必要があります。

 このように日々刻々と変動していくデータを更新し、収容しているのが「データベース」という機構です。これとウェブページとをつなげて情報のやり取りを行っていきますが、それらの処理は、ウェブサーバーとはまた別のサーバーが行わなくてはなりません。

 動的サイトの場合、クライアントであるブラウザにウェブページを表示させる前に、
 まずサーバーが最新の情報を取得したり、ウェブページを更新したりしなくてはなりません。

 ちなみに、サーバーが処理をすることは「サーバーサイド・プロセシング」と呼ばれます。

 

  さて、2つのサイトの仕組みが大まかに理解できたところで、次は2つのサイトがどのような目的で作られたかについて解説します。
 

 

  どうしてできた?静的/動的サイト

  今から約25年前、1990年に Tim Berners-Leeという人物が発表した、ほんのちょっとのタグとリンクとで構成されたページが、世界で最初のウェブページです。
 そして、こちらは静的ウェブサイト

 それから3年後の1993年に、コモン・ゲートウェイ・インタフェース(CGI)が開発されて、ウェブサーバー側が予めスクリプトを処理して、ブラウザに表示させることが可能になりました。
 これ当時としては、大変画期的なシステムだったんです。

 そしてそれ以降、どちらかというと「動的ウェブサイト」のほうが、ウェブサイトの覇権をにぎっていくことになります。
 

  動的ウェブサイトの普及をより一層推し進めるきっかけになったのが、ウェブコンテンツ・マネジメント(WCMS)の到来です。
 これによりウェブサイトの作成はもとより、データベースの維持管理も簡単になりました。

 サーバーサイドの処理にバリエーションが増えることで、ユーザーはより高いレベルのウェブサービスを受けられるようになりました。
 これのおかげで「ウェブアプリ」というものが開発・発達していくことになります。
 もちろん、GitLabもその中の1つですよ。

 コンテンツ・マネジメントシステムも段々とその種類を増やし、 WordPressJoomla!DrupalMagentoGhostなど、実に数多くのサービスが世に出回ることとなりました。
 

  しかし、動的ウェブサイトが広まった理由は、データベースに接続してリッチなコンテンツを展開できることだけではありません。


 実は、テンプレートシステム目当てに利用する人々が多かったことも、大きな理由です。テンプレートがあるぶん、開発は効率的に、アップデートはより簡単に、そして極力ミスを減らしてウェブサイトを制作できるようになりました。

  しかし、思わぬところで落とし穴が発生します。サーバーサイド処理の人気に火が付いたことがきっかけで、脆弱性を攻撃されることが増えたのです。

 これもまた月並みな話ですが、脆弱性が見つかって、それに対処するとなると、それはもうとてつもない時間と手間がかかります。

 もはやこのままでは、ユーザーも運営者もサーバーも守り切れないという状況で、とあるセキュリティ担当者がこんなことを考え付いたそうです。
 

  テンプレートシステムさえ使えれば、作れるものは静的ウェブサイトでもよかったんじゃないか。このような理由で開発されたのが、静的サイトジェネレータ(SGGs)です。
 ウェブサイトを記述するソフトウェアは動的だとしても、実際に発表するサイトは全て静的であることが特徴です。

  静的サイトジェネレータは、2000年代の前半にはすでに登場しています。 Blosxomは2003年、 WebGenは2004年の発表です。
 そして2008年、 Tom Preston-Werner によって、今や静的サイトジェネレータの代表格といわれる Jekyllが発表されました。

 静的サイトジェネレータの人気は、ここ2,3年ほどで急激な上昇傾向を見せています。(Google Trendsのグラフ


 

  サーバー処理

  まずは、こちらの画像をご覧ください。

 静的サイトと動的サイトとが、サーバーとどのようにやり取りをして表示されているかが表されています。

  どれだけ動的な言語でプログラムされていたとしても、 ApacheNGINXIISなどのウェブサーバーソフトウェアは、静的ファイルしか保管・読み込みできません。
 なので、これらのサーバーの利用者は、HTML、CSS、JavaScriptしか使えないと考えておいた方がよいでしょう。

 ちなみにGitLabPagesは、NGINXサーバーで運営されています。なので、静的ファイルしか保管できません。


 動的なサイトにはウェブサーバーの他にコンテンツを処理するサーバーが必要です。
 そのサーバーには、アプリケーションソフトウェアが搭載されています。これがないとサーバーで動的なスクリプトを扱うことができません。代表的なものは、 PHPCold FusionASP.NETなどです。

 

  いかなるブラウザ(クライアント)も、HTTP(HyperText Transfer Protocol)と、URL (Uniform Resource Locator)とを介して、ウェブサーバーにしかアクセスできないようになっています。
 

 図A[静的サイトの場合]:
クライアントがURLを宛先として、HTTPリクエストをウェブサーバーに送信しました。
ウェブサーバーはこのリクエストに応じて、URLに符合したHTMLファイルを探し出します。
該当したファイルを、すぐさまクライアントにHTTPレスポンスとして返信します。
ブラウザが返信されてきたコンテンツを翻訳して、ディスプレイに表示します。
このとき、ブラウザが行っている翻訳処理のことをクライアントサイド・プロセシングと言います。
 

 図B[動的サイトの場合]:
クライアントがウェブサーバーにHTTPリクエストを送信します。
すると、ウェブサーバーは至急スクリプト処理をするよう、アプリケーションサーバーに指示を出します。
さらにアプリケーションサーバーが処理に必要なデータを参照するために、データベースに情報の送信を要求します。
データベースから送られてきた情報をもとに、アプリケーションサーバーが処理を開始しました。
アプリケーションサーバーが処理した情報を、今度はウェブサーバーに送付します。
ウェブサーバーが与えられた処理結果をもとに、HTMLファイルを作成します。
ようやくクライアントにHTTPレスポンスを返信することができました。
これがサーバーサイド・プロセシングです。
 

  両者の最も分かりやすい違いは、動的サイトの方が静的サイトに比べてやり取りをするサーバーの数が多く、ウェブサーバー1つでは処理が不可能であることでしょう。
 HTTPリクエストに何らかのレスポンスを行うことについては共通しています。

 

  当然、動的サイトの方がHTTPレスポンスにやや時間がかかる傾向にあります。
 

  もちろん、動的サイトの方がサーバーにより大きな負担をかけています。

 仮に、1ページのHTTPリクエストを受け取るたびに、情報を更新した方がよい内容でもないはずなのに、動的サイトに掲載したとしたら、どうでしょう。
 それだけ無駄な処理が発生しています。

  単なる日記ブログや覚書のようなサイトに、動的サイトを使う意味はそんなにありません。
 「ページを追加する」という変更があったとしても、そのページ書いてある内容が常に変動するわけではないからです。

 つまり、個人が作成するほとんどのサイトが、静的サイトにした方がよいのではないかという状態です。

 なにより、構造が複雑になれば、セキュリティの隙が生まれます。
 動的サイトが処理を行うには、ユーザーのデータを収集しなくてはならない場合もよくありますが、そのデータを盗み見される事案が後を絶ちません。
 

 あなたのサイトでは、ユーザーのことを詮索する必要が本当にあるのですか。
 あなたは、ほとんどだれも知らぬ間に自分の大事な情報を抜き取るサイトに毎日訪れたいと考えますか。

 

  結論

  動的サイトは、やっていることの規模や、スクリプトの内容から考えて、「ウェブアプリを配給するために作られたものだ」と大まかに割り切ってしまいましょう。

 実際、動的サイトを作ってみると、先ほど紹介した図Bよりも遥かに複雑な世界があなた待ち受けています。

 それに比べて、静的サイトは単純なもので、図Aとほとんど同じ構造です。
 メンテナンスにお金をかける必要も、ほとんどありません。
 この単純さが、GitLabで静的サイトを無料で公開しても全く支障がない最大の理由です。
 

  ウェブ開発者のほとんどが、静的サイトの制作に「時間がかかってアップデートが面倒だ」というイメージを抱えて、動的サイトを選びがちです。
 しかし、先ほども申しましたように、その問題は静的サイト・ジェネレータがほとんど解決しています。
 

  次回の記事では、最近の静的サイト・ジェネレータ事情をご紹介します。
 静的サイト・ジェネレータがどのように動作するのか、どのように使えば便利なのかについてお教えします。

  それでは!

 

 

 
PDF
更新日:2017-09-23 11:23:00 Hnoss 0  del.icio.usに追加   はてなブックマークに追加   twitterに投稿   facebookでshare
[ 原文 ] https://about.gitlab.com/2016/06/03/ssg-overview-gitlab-pages-part-1-dynamic-x-static/ Creative Commons License この作品は、クリエイティブ・コモンズ・ライセンスの下でライセンスされています。
クリエイティブ・コモンズ・ライセンス
翻訳者ページをみる

この記事の翻訳者

Hnoss さんの翻訳記事

【GitLab 公式 を訳してみた】GitLab RunnerをFreeBSDにインストールする

GitLab Runner > GitLab Runnerをインストールする >FreeBSDにインストールする 注: FreeBSDでは、現在 ”開発最先端”とされているリリース を利用することも可能です。  GitLab …2017-12-13 17:21:41

GitLab CI にプッシュしたものを GitHubに出力する | from: Leow Kah Man - Tech Blog

 今僕は、GitLabでウェブサイトを公開するためにGitLab CIランナーを使っています。でも、今度はそれをGitHub pagesでも公開できるようにしてみたい。  もしも、ネットのコンテンツを…2017-12-11 23:59:39

僕がHugo静的サイト・ジェネレータをGitLabで使うときにしたCI設定 | from Leow Kah Man - Tech Blog

 週末にかけて、GitHubに構えていた私のブログをGitLabに移転しました。GitLabだとCIビルドが自動的にできるところが便利です。  僕はGitLabのレポジトリにNodeJS Dockerイメージを構…2017-12-11 23:58:18

【GitLab 公式 を訳してみた】GitLab Runnerをインストールする

GitLab Runner > GitLab Runnerをインストールする  GitLab Runnerは、GNU/Linux、 macOS、 FreeBSD、 Windowsでインストールと使用することが可能です。  インストールには3つ…2017-12-06 17:57:33