Firebase – koneta https://koneta.click DIYとデジモノとプログラミングとライフハックをコネた...小ネタ Sat, 24 Jul 2021 09:50:23 +0000 ja hourly 1 https://wordpress.org/?v=6.1 https://koneta.click/wp-content/uploads/2020/02/cropped-icon-32x32.png Firebase – koneta https://koneta.click 32 32 静的化したWordPressのホスティング先をNetlifyからFirebase Hostingに変更しました https://koneta.click/p/608 https://koneta.click/p/608#respond Sun, 03 Jan 2021 06:15:59 +0000 https://koneta.click/?p=608 以前、私はWordPressで構築されているサイトをNetlifyで公開するという記事を公開していました。その結果できたサイトが現在ご覧いただいているこのサイトなのです。

続・WordPressをwgetとNetlifyでお手軽に静的サイト化する話

前回のWordPress静的化から発展し、今回は今ご覧になっているこのサイトを静的化していきます。

…しかし公開からしばらくすると、ページ表示がなんだかモッサりしているなぁと感じるようになりました。そこで今回はNetlifyからGoogleさんのところのFirebase Hostingに鞍替えし、その作業をまとめて行こうと思います。

今回の作業で公開するサイトはwgetコマンドで静的化したサイトなので…きっと簡単に再現できるはずです。もしWordPressの静的化を行うのであれば前回と前々回の記事をご覧いただけると幸いです。

Netlifyが遅い問題

NetlifyはほぼGitリポジトリを選択するだけでお手軽に静的ファイルをホスティングしてくれる使いやすいサイトです。しかし、こちらの記事を参考にすると、Netlifyには日本国内の拠点がなくアクセスが海外旅行するようで、どうしてもレスポンスが遅くなるようです。その遅さは体感できるほどでした。

というわけで、今回はその遅さをどうにか解消したいと思い、Netlifyから同じく基本無料から利用することができるFirebase Hostingを試してみよう！…となったわけです。

ちなみに、実際の測定結果は本記事の最後に掲載していますので、Firebase Hostingとの比較と共に見ていただけるとです。

Firebaseプロジェクトを作成する

まずはプロジェクトを作成しておきます。Googleアカウントはほとんどの方が持っていると思いますので、早速 Firebase のコンソールページにアクセスします。プロジェクト作成自体はページの指示通りに入力していけば迷わずできるはずです。

Firebaseをインストールする

次にデプロイに使用するFirebase CLI をインストールします。インストールの方法は色々ありますが、node環境がないので今回はスタンドアロンバイナリを直接ダウンロードする方法で進めていきます。

手順としては以下のコマンドだけで導入(ダウンロード~パス通し)までできます。

$ mkdir /parh/to/firebase_dir && cd /parh/to/firebase_dir
$ wget -O firebase https://firebase.tools/bin/linux/latest
$ chmod +x ./firebase
$ echo 'export PATH=$PATH:/parh/to/firebase_dir' >> .bashrc

ちなみに他の導入方法は公式ガイドを参考にしてみてください。今回はLinux環境でしたがWindowsやMac環境用の説明も載っていますので指示通りに進めれば導入できるはずです。

Googleアカウントを紐付ける

次にGoogleアカウントとの紐付けを行います。基本的には下記のコマンドを実行して表示されたURLにアクセス、承認してあげるだけです。

$ firebase login --no-localhost
実行結果
i  Firebase optionally collects CLI usage and error reporting information to help improve our products. Data is collected in accordance with Google's privacy policy (https://policies.google.com/privacy) and is not used to identify you.

? Allow Firebase to collect CLI usage and error reporting information? Yes
i  To change your data collection preference at any time, run `firebase logout` and log in again.

Visit this URL on any device to log in:
https://accounts.google.com/o/oauth2/auth?client_id=.....

? Paste authorization code here: [認証後表示されたcodeを入力]

✔  Success! Logged in as [ログインしたGmailアカウント]@gmail.com

しかし、今回は承認後のlocalhostが正常に動作しなかったので(おそらくファイヤーウォールのせい)、今回はlocalhostを使用せず、codeを入力する方式でアカウント紐付けを行いました。このためのオプションが--no-localhostになります。

Firebaseプロジェクトの初期化

次にプロジェクトの初期設定を行います。

$ cd /path/to/web/dir
$ firebase init hosting
実行結果

     ######## #### ########  ######## ########     ###     ######  ########
     ##        ##  ##     ## ##       ##     ##  ##   ##  ##       ##
     ######    ##  ########  ######   ########  #########  ######  ######
     ##        ##  ##    ##  ##       ##     ## ##     ##       ## ##
     ##       #### ##     ## ######## ########  ##     ##  ######  ########

You're about to initialize a Firebase project in this directory:

  /path/to/web/dir/


=== Project Setup

First, let's associate this project directory with a Firebase project.
You can create multiple project aliases by running firebase use --add, 
but for now we'll just set up a default project.

? Please select an option: Use an existing project
? Select a default Firebase project for this directory: project_name (project_name)
i  Using project project_name (project_name)

=== Hosting Setup

Your public directory is the folder (relative to your project directory) that
will contain Hosting assets to be uploaded with firebase deploy. If you
have a build process for your assets, use your build's output directory.

? What do you want to use as your public directory? [document_root_dir_name]
? Configure as a single-page app (rewrite all urls to /index.html)? No
? Set up automatic builds and deploys with GitHub? No
? File [document_root_dir_name]/404.html already exists. Overwrite? No
i  Skipping write of [document_root_dir_name]/404.html
? File [document_root_dir_name]/index.html already exists. Overwrite? No
i  Skipping write of [document_root_dir_name]/index.html

i  Writing configuration info to firebase.json...
i  Writing project information to .firebaserc...
i  Writing gitignore file to .gitignore...

✔  Firebase initialization complete!

今回は最初の手順でプロジェクトを作成済みなので、既存のプロジェクトを選択しました。また、デプロイするファイル群はWordPressから作成済みなので404.htmlやindex.htmlの生成は不要、また今後のデプロイは自作のスクリプトから実施する予定なので、GitHubの項目もNoで回答していきます。

ここまでできれば準備は完了です。

デプロイする

では最後にデプロイしていきます。とはいえデプロイもコマンド1つです。

$ firebase deploy --only hosting
実行結果
=== Deploying to 'web-konetaclick'...

i  deploying hosting
i  hosting[web-konetaclick]: beginning deploy...
i  hosting[web-konetaclick]: found 1583 files in [documentroot_dir]
✔  hosting[web-konetaclick]: file upload complete
i  hosting[web-konetaclick]: finalizing version...
✔  hosting[web-konetaclick]: version finalized
i  hosting[web-konetaclick]: releasing new version...
✔  hosting[web-konetaclick]: release complete

✔  Deploy complete!

Project Console: https://console.firebase.google.com/project/[project name]/overview
Hosting URL: https://[project name].web.app

処理が終わると、ホストされたURLが発行されますので、ここから正常にデプロイされているかを確認することができます。

作業前後

最後に作業前後それぞれでのレスポンス時間を比較して終わろうと思います。冒頭でも書きましたとおり、作業前の環境はNetlifyにデプロイされています。

計測にはGo製のベンチマークツール「hey」を使用しました。お手軽簡単にベンチマークを取ることができるのでおすすめしておきます。

作業前 (Netlify)
$ hey https://koneta.click

Summary:
  Total:	2.1298 secs
  Slowest:	1.3774 secs
  Fastest:	0.1981 secs
  Average:	0.4127 secs
  Requests/sec:	93.9070
計測結果詳細
Summary:
  Total:	2.1298 secs
  Slowest:	1.3774 secs
  Fastest:	0.1981 secs
  Average:	0.4127 secs
  Requests/sec:	93.9070

Response time histogram:
  0.198 [1]	|
  0.316 [143]	|■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
  0.434 [2]	|■
  0.552 [0]	|
  0.670 [4]	|■
  0.788 [0]	|
  0.906 [2]	|■
  1.024 [42]	|■■■■■■■■■■■■
  1.142 [5]	|■
  1.259 [0]	|
  1.377 [1]	|


Latency distribution:
  10% in 0.2010 secs
  25% in 0.2040 secs
  50% in 0.2094 secs
  75% in 0.9042 secs
  90% in 0.9809 secs
  95% in 1.0159 secs
  99% in 1.1090 secs

Details (average, fastest, slowest):
  DNS+dialup:	0.0794 secs, 0.1981 secs, 1.3774 secs
  DNS-lookup:	0.0138 secs, 0.0000 secs, 0.0944 secs
  req write:	0.0000 secs, 0.0000 secs, 0.0003 secs
  resp wait:	0.1262 secs, 0.0957 secs, 0.3134 secs
  resp read:	0.0098 secs, 0.0003 secs, 0.4600 secs

Status code distribution:
  [200]	200 responses
作業後 (Firebase Hosting)
$ hey https://koneta.click

Summary:
  Total:	0.9511 secs
  Slowest:	0.4694 secs
  Fastest:	0.0224 secs
  Average:	0.2059 secs
  Requests/sec:	210.2747
計測結果詳細
Summary:
  Total:	0.9511 secs
  Slowest:	0.4694 secs
  Fastest:	0.0224 secs
  Average:	0.2059 secs
  Requests/sec:	210.2747
  

Response time histogram:
  0.022 [1]	|
  0.067 [0]	|
  0.112 [0]	|
  0.157 [129]	|■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
  0.201 [17]	|■■■■■
  0.246 [1]	|
  0.291 [2]	|■
  0.335 [12]	|■■■■
  0.380 [8]	|■■
  0.425 [14]	|■■■■
  0.469 [16]	|■■■■■


Latency distribution:
  10% in 0.1220 secs
  25% in 0.1397 secs
  50% in 0.1482 secs
  75% in 0.2916 secs
  90% in 0.4160 secs
  95% in 0.4473 secs
  99% in 0.4690 secs

Details (average, fastest, slowest):
  DNS+dialup:	0.0437 secs, 0.0224 secs, 0.4694 secs
  DNS-lookup:	0.0007 secs, 0.0000 secs, 0.0034 secs
  req write:	0.0000 secs, 0.0000 secs, 0.0007 secs
  resp wait:	0.1325 secs, 0.0171 secs, 0.1564 secs
  resp read:	0.0046 secs, 0.0004 secs, 0.1526 secs

Status code distribution:
  [200]	200 responses

というわけで、思っていた以上の高速化を実現することができました。今回はレスポンス時間という観点でのみの比較ですが、Firebase Hostingを利用したほうが調子が良さそうなので本格的に使っていきたいと思います。

おまけ (ConoHa1GB + WordPressそのまま)

最後におまけとして静的化前のWordPressでも調査してみようと思います。こちらは現在ConoHaの1GBプラン上で動作しています。また、これはwget用に用意しているだけなのでだいぶスペックは制限しています。そのため調査時も並列は1つで調査しています。

$ hey https://[origin domain].com -c 1

Summary:
  Total:	22.6286 secs
  Slowest:	13.3695 secs
  Fastest:	0.1897 secs
  Average:	4.7227 secs
  Requests/sec:	8.8384
計測結果詳細
Summary:
  Total:	22.6286 secs
  Slowest:	13.3695 secs
  Fastest:	0.1897 secs
  Average:	4.7227 secs
  Requests/sec:	8.8384
  

Response time histogram:
  0.190 [1]	|■
  1.508 [20]	|■■■■■■■■■■■■■■■■
  2.826 [20]	|■■■■■■■■■■■■■■■■
  4.144 [49]	|■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
  5.462 [37]	|■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
  6.780 [37]	|■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
  8.098 [22]	|■■■■■■■■■■■■■■■■■■
  9.416 [5]	|■■■■
  10.734 [0]	|
  12.052 [6]	|■■■■■
  13.369 [3]	|■■


Latency distribution:
  10% in 1.1740 secs
  25% in 2.9277 secs
  50% in 4.7938 secs
  75% in 6.3292 secs
  90% in 7.7741 secs
  95% in 8.6856 secs
  99% in 12.5423 secs

Details (average, fastest, slowest):
  DNS+dialup:	0.0227 secs, 0.1897 secs, 13.3695 secs
  DNS-lookup:	0.0075 secs, 0.0000 secs, 0.0292 secs
  req write:	0.0001 secs, 0.0000 secs, 0.0005 secs
  resp wait:	3.4589 secs, 0.1632 secs, 13.3391 secs
  resp read:	0.3117 secs, 0.0180 secs, 2.8701 secs

Status code distribution:
  [200]	200 responses

Totalの項目は並列数が違うので無視するとして…その他の項目を見ると静的と比べるとだいぶ遅くなっているのが見えてきます。端末のスペックがそもそも違うので厳密ではありませんが、やはりスピード面では静的サイトに軍配が上がるようです。

参考

Firebase Hosting 公式ガイド … ほぼ ここをみるだけでこの記事は不要です。

]]> https://koneta.click/p/608/feed 0