【2018年版】このブログに使われている技術
この記事は2018年時点の構成です。
2022年現在は以下の構成になっています。
- 静的サイトジェネレーター:HUGO
- ホスティング:Cloudflare Pages
- 画像配信:Cloudinary
- 管理:GitHub
2020年現在は以下の構成になっています。
- 静的サイトジェネレーター:HUGO
- ホスティング:Firebase Hosting
- 画像配信:Cloudinary
- 管理:GitLab / GitLab CI
このブログの技術面の紹介をします。
このブログの記事の内容はイマイチかもしれませんが、技術面にはこだわっています! (記事の質にもこだわれ。量も増やせ。)
私が管理しやすく、またユーザ目線のチューニングがされているので、我ながら良い構成だと自負しています。 今や、さまざまな方法でWebサイトを公開することができますが、このサイトの構成が何かの参考になれば幸いです。
使っているモノ
Visual Studio Code というエディタで記事を書いています。 そのデータをGitLabのリポジトリに送信(push)します。 すると、直後にNetlifyがGitLabのデータを読み取って、Webサイトを構築し、公開してくれます。
静的サイト
このサイトは、静的サイトです。 サーバ上にHTMLファイルがあり、このファイルをブラウザが読み込んでWebサイトを表示します。
反対に、世の中には動的サイトもあります。 どちらが良いかは、Webサイトでやりたいことや管理のしやすさによって違います。 これらの違いを解説した記事はたくさんありますので、迷ったら探してみると良いと思います。
私は、以下の利点が良いと思ったので、静的サイトを選びました。
- サーバでサイトの構築処理が不要なため、比較的高速
- サイト構築のためのアカウント管理が存在しないため、セキュリティが高い
- サーバでプログラムを実行させる必要がないため、高性能なサーバでなくても良いし、無料でも問題ない
HUGO
静的サイトのジェネレータはいくつかありますが、私はHUGO を使っています。
選定当時は、以下の利点から選びました。
- 有名になってきた
- Webサイトの構築が高速
- なんか良さそう
今となっては、好みのテーマがあるかで選んで良いと思います。
Git
サイトのデータはGitで管理しています。 おそらく、プログラマには使い慣れているツールだと思います。 バージョンを管理でき、また、外部のリポジトリ(データ貯蔵庫みたいなもの)と組み合わせれば、複数人で共同作業にも使えます。
過去の内容に巻き戻すことも簡単ですし、データをリポジトリに送るのも簡単なので、私にとっては使いやすいです。
Visual Studio Code
私のオススメのエディタです! というと、宗教戦争が起きそうですが… (エディタの好みは、人によってわかれるものです…)
拡張性が高いですし、色づけも見やすくてわかりやすいです。 私は、レポートやプログラミングにおいても使っています。
まあ、エディタは自分が使いやすいと思ったものを使えば良いと思います。
まずは、エディタで記事を記事を書きます。
GitLab
無料でプライベートリポジトリを作成できるので使用しています。
記事データや写真データなどは、GitでGitLabに送信します。 外部のデータ貯蔵庫として使っています。
Netlify
この構成の中心となるサービスです。
私は以下の機能を使っていますが、全て無料! ただし、ドメインは他社で買っています。
- SSL
- HTTP/2
- 自動デプロイ
- カスタムドメイン
SSLは通信の暗号化に使われる技術で、URLが https://
から始まっていると、暗号化がされています。
証明書は定期的な更新が必要ですが、これも全自動でやってくれるため、手間がかかりません。
今の時代にピッタリな機能です。
HTTP/2は、通信の高速化のための技術です。 これも何もしなくても自動で対応されているため、Webサイトにアクセスする人もサクサクとページを読み込めます。
自動デプロイは、リポジトリに反映があったら、即座にWebサイトを構築して公開する機能です。 私は記事を書いてpushするだけでサイトが更新されるため、手間がかからず、非常に便利です。
カスタムドメインは、ドメイン名を任意の名前に変えることができます。 ドメインは他社で購入しています。 カスタムドメインは有料のサービスが多い中、無料で対応してくれるとは、ありがたいものです。
高速化
ページの読み込みに時間がかかると、ストレスがたまります。 また、データ量が大きいと、スマートフォンで読み込む時にどんどんとデータ通信可能量が減ってしまいます。
このサイトはユーザフレンドリなサイトを目指して、高速な読み込みとデータ通信量の削減のための工夫がされています。
現在の状況とアドバイスは、GoogleのPageSpeed Insights というサービスなどで確認できます。
(最近「はてなブログ」というサービスを使っているのをよく見ますが、あのサービスよりは明らかに速いぞ… はてなブログも簡単にブログを持てるし、リッチな機能があるという利点はあると思いますが、速度という点では勝ったぜ…)
Netlify CDN
先ほど紹介したNetlifyですが、サイトのデータはCDN上にあります。
通常サーバは一箇所にあって、世界から一箇所のサーバに接続します。 CDNとは、複数箇所にサーバを設置し、サーバ間でデータを同期しておきます。 そしてユーザがアクセスしてきたら、ユーザに一番近いサーバがWebサイトのデータを送信します。
CDNを使うことで、ユーザとサーバ間の通信が最も速いサーバが応答してくれるので、通信が速くなります。 特に、画像といったデータ量が大きいデータの通信では、この効果が大きいでしょう。
私が何かしたわけではなく、Netlifyでは最初からCDNでデータを配信してくれます。 無料でこのような機能を使えるのは、やはりユーザのことを考えた、太っ腹なサービスですね…
AMP対応
このブログのテーマは、AMPに対応しています。 これも私が何かしたわけではないので、大きな顔をできないのですが…
AMPは、モバイル向けの規格です。 様々な制約を設けることで、スマートフォンでも快適にブラウジングができることを目指しています。 Googleのサーバにもキャッシュされ、検索結果からGoogleのサーバにあるWebサイトを見ることもできます。
AMP対応によって、様々な処理が効率化されたWebページを閲覧することができます。
画像最適化
ブログ内で使用している画像は、見た目を損なわない程度に最適化しています。
画像の大きさを適度に調整し、画像のデータサイズを縮小しています。 きっと自動化する方法もあると思いますが、現状は私が手作業で調整しています。
画像がぼやけないように調整するのは、なかなか難しい印象です。 とは言っても、ある程度妥協すれば、まあまあ画像のデータ量を減らせます。
画像サイズの調整
アイキャッチ画像やスクリーンショット、スマートフォンで撮影した写真などは、そのままではWebページで表示するには大きいことが多いです。 画像を縮小して表示することはできますが、大きい画像を読み込んでいることは変わらないので、読み込む時間とデータ通信量が無駄です。
まずは、見た目に影響しない程度に画像の大きさを小さくしています。 このようにすることで、画像のデータ量が小さくなります。
圧縮
画像の大きさが小さくなったら、さらに画像を圧縮しています。 私はTinyPNG というサービスを利用しています。 このようなサービスは探せばたくさんありますが、このサービスは有名そうなので利用しています。 多数派に流されていますね…
見た目があまり変わらない程度にあまり必要でないデータを除くことで、画像のデータ量がより小さくなります。 このようなサービスを無料で気軽に使えるって、便利ですね。
まとめ
以上、思いつくものを書いてきましたが、参考になったでしょうか。
ユーザが使いやすいWebサイトを構築していくことは、ユーザにとって良いことですし、Googleからも評価されます。 速いに超したことはありませんし、データ通信量が小さければ、スマートフォンでもサクサク閲覧できます。
ただし、Webサイトのチューニングばかりに夢中になって、肝心のコンテンツがおろそかになってはいけません(私への戒め)。
世の中には無料で使える便利なサービスがたくさんあるので、それらを有効活用して、よりよいWebサイトを作っていければ良いと思います。