こんにちは！スタッフのやまさきです。
先日、デジタルスタジオで使用するための「タイマーアプリ」を作成しました。
その投稿はこちらから↓
ところが、困ったことが起きました😫
やばい、通信量が多くて無料プランに収まりそうにないぞー💦
Firebase Hostingの無料プラン（Sparkプラン）には、通信量の制限があります。
小規模なWebアプリを作っているときはあまり気になりませんが、
「管理画面をずっと開きっぱなしにする」
「大型モニターに常時表示する」
といった使い方をすると、思った以上に通信量が増えることがあります。
今回、私はFirebase + Next.jsでタイマー表示アプリを作っていたのですが、
- 修正前：約1.2GB/day
- 修正後：約200KB/day
まで大きく減らすことができました。
この記事では、
- なぜ通信量が多かったのか
- 何を変えたのか
- なぜそこまで減ったのか
を、初級エンジニア向けにできるだけ分かりやすく解説します。
というか、自分用のメモとして残しておくのが一番の目的です。
作っていたもの
今回作っていたのは、こんな感じのシンプルなタイマー管理システムです。
- 管理画面
- 利用開始
- 一時停止
- 延長
- 残り時間調整
- 表示画面
- 残り時間を大型モニターに表示
Firestoreを使ってリアルタイム同期していました。
最初の構成（通信量が多かった）
最初は Next.js を使っていました。
構成としてはこんな感じです。
Next.js
↓
Firebase Hosting
↓
FirestoreReact + Next.js で作ると、開発はかなり楽です。
あと、以前から興味のあったReactに触ってみたいということもあって、学習も目的でした。
ただ、今回のような「常時表示するだけのアプリ」では、実は少しオーバースペックでした。
まずやったこと
キャッシュ設定
最初に追加したのがこちらです。
{
"hosting": {
"headers": [
{
"source": "/_next/static/**",
"headers": [
{
"key": "Cache-Control",
"value": "public,max-age=31536000,immutable"
}
]
}
]
}
}最初は「なんだこれ？」という感じだったのですが、簡単にいうと、
「このファイルはしばらく変わらないので、毎回ダウンロードしなくてOKです」
という設定です。
たとえると
キャッシュなしだと、
毎回コンビニに行くたびに、
「この雑誌、また最初から全部持って帰ってください」
と言われる感じです。
でもキャッシュを使うと、
「前回の雑誌をそのまま使ってOKです」
になります。
つまり、
- 初回だけダウンロード
- 2回目以降は再利用
できるようになります。
Next.jsは実は色々ダウンロードしている
初心者のころは、
「Webページ = HTML1枚」
みたいなイメージを持ちがちです。
でも Next.js は違います。
実際には、画面を開くと裏側で大量のJavaScriptが読み込まれています。
たとえば：
/_next/static/chunks/xxx.js
/_next/static/chunks/yyy.js
/_next/static/chunks/zzz.jsなど。
さらに、
- React本体
- Next.js本体
- ページ表示用JS
なども読み込まれます。
つまり、
「HTMLを表示している」
というより、
「JavaScriptアプリをダウンロードして動かしている」
に近いです。
そして次にやったこと
Next.jsをやめて静的HTML化
今回は思い切って、
- React
- Next.js
をやめて、
admin.html
display.htmlという普通のHTMLファイルに変更しました。
すると何が起きた？
通信量が激減しました。
理由はシンプルで、
「読み込むものが減った」
からです。
修正前
ブラウザ側では、
HTML
↓
Next.js
↓
React
↓
大量のJS
↓
画面描画という流れでした。
修正後
今は、
HTML
↓
少しのJavaScript
↓
表示だけです。
かなりシンプルです。
今回のアプリはReactが不要だった
ここが今回かなり大きなポイントでした。
今回のアプリは、
- 画面遷移なし
- フォーム少ない
- SEO不要
- シンプル表示
- 常時表示用途
でした。
つまり、
ReactやNext.jsの強みをあまり使っていなかったんです。
逆に、
- ライブラリの重さ
- JSのダウンロード量
だけが増えていました。
「Reactは常に正義」ではない
最近はReactやNext.jsが人気なので、
「とりあえずNext.js」
になりがちです。
もちろん便利です。
ただ、
- サイネージ
- タイマー
- 管理画面
- 社内ツール
みたいな小規模アプリでは、
素のHTML + JavaScriptの方が軽い
ことは普通にあります。
今回まさにそれでした。
ちなみにFirestoreはそのまま
今回減ったのは主に「Hostingの通信量」です。
Firestoreのリアルタイム同期はそのまま使っています。
db.collection("devices").onSnapshot(...)この部分です。
つまり、
- Hostingは軽量化
- Firestoreの便利さは維持
という状態です。
最後に
今回かなり勉強になったのは、
「新しい技術 = 常に最適」ではない
ということでした。
Next.jsは本当に便利ですが、
用途によっては、
- 普通のHTML
- 普通のJavaScript
の方がシンプルで速いこともあります。
特に、
- 常時表示
- 単機能
- 小規模
なWebアプリでは、今回のような構成はかなり相性が良いと思います。
同じようにFirebase Hostingの通信量で困っている方の参考になれば嬉しいです。
これでなんとか１ヶ月の上限には収まるんじゃないかなー
