ダッシュボードが重い真因は「圧縮し忘れ」だった — 推測仮説を全部外して計測に戻った話
この記事について
自宅サーバで動かしている管理ダッシュボードの「なんか重い」という体感を、推測だけで直そうとして三度外した記録だ。最後は計測に戻ったら一撃で終わった。
結論を先に置く。重さの真因は、161KBの静的HTMLを無圧縮のまま細い上り回線に流していたことだった。gzipを一枚かませたら161KB→18KBになり、体感10秒が1秒台に落ちた。 JavaScriptの量でもデータベースの遅さでもなかった。個人開発者・小規模運用で「サーバが重い」を憶測で追いかけている人向けに、誤診の中身と、なぜ計測が先だったのかを書く。
試した環境: 自宅回線常駐のサーバ上で動く自作ダッシュボード（Python簡易HTTPサーバ配信）＋ 上り帯域が細い回線（約128kbps＝十数KB/s台）。
何が起きていたか — 同じサーバなのにページによって体感が全然違う
症状はシンプルだった。同じサーバが配信している複数のダッシュボードのうち、ある一枚だけが開くのに体感で10秒近くかかる。別のページは一瞬で出る。サーバの負荷を見ても、CPUもメモリも張り付いていない。
こういうとき、頭は勝手に犯人候補を並べ始める。最初に並んだ仮説はこうだった。
- 重いページは埋め込んでいるJavaScriptが多いんじゃないか
- 裏でデータベースを叩いていて、クエリが遅いんじゃないか
- リクエストのたびにHTMLをライブ生成していて、その生成が重いんじゃないか
もっともらしい。だが、全部外れだった。
誤診その1〜3 — 「ライブ生成が重い」と決めつけて調査結果を鵜呑みにした
一番きつい外し方をしたのが「リクエストのたびにライブ生成しているから重い」という仮説だ。これは調査を投げた結果をそのまま信じて、検証せずにメモにまで書いてしまった。
実際にコードを追ったら、その重いページは毎時バッチで作り置きした静的HTMLをそのまま返しているだけだった。リクエスト時に生成なんてしていない。ライブ生成説は前提から間違っていた。
JSの量でもDBでもライブ生成でもない。候補を三つ潰して残ったのは、誰も見ていなかった一番手前——配信そのものだった。
真因 — 静的HTMLを「無圧縮の生テキスト」で流していた
犯人は、レスポンスの書き出し方だった。ダッシュボードの配信コードは、HTMLをgzipもかけずに生のテキストのまま書き出していた。
ここに回線の細さが噛み合う。重いページのHTMLは161KB、軽いページは13KB。上りが約128kbps（毎秒およそ16KB）しかない回線では、単純計算でこうなる。
| ページ | HTMLサイズ | 約128kbps（≒16KB/s）での配信時間 |
|---|---|---|
| 重かったページ | 161KB | 約10秒 |
| 軽かったページ | 13KB | 1秒未満 |
体感差の正体は、処理の重さでも生成コストでもなく、回線を通るバイト数そのものだった。「重い」と感じていたのは、細いホースに太いデータを押し込んでいただけだ。
なお、手前にリバースプロキシ（CDN）は挟まっていた。だがその圧縮はエッジからブラウザまでの区間にしか効かない。ボトルネックはサーバ→エッジの上り区間で、そこは無圧縮のまま通っていた。だから「CDNがあるから大丈夫」という思い込みも、この一区間だけは守ってくれていなかった。
直し方 — レスポンスにgzipを一枚かませるだけ
対策は拍子抜けするほど小さい。配信コードがリクエストの Accept-Encoding を見て、gzip対応ブラウザには圧縮して返し、Content-Encoding: gzip を付けるようにした。HTMLはテキストなので圧縮がよく効く。
- 重かったページ: 161KB → 18KB（約9倍圧縮）
- 体感: 約10秒 → 1秒台
- 効果範囲: 特定の一枚だけでなく、同じ配信コードを通る全ページが速くなった
回線が細いまま、コード側の数KBの変更だけで効いた。回線が太い環境に戻っても圧縮は無害なので、入れっぱなしでいい。ついでに「そもそも埋め込む行数を絞ってHTML自体を小さくする」という次の一手も見えたが、まずはgzipで9割方の体感が戻った。
やってみてわかったこと
この回でいちばん刺さるのは、技術そのものより順番の話だ。「動いていない／重い」と診断する前に、必ず実データを引く。 今回は実測に戻る前に憶測を三つ挟み、三つとも外した。JS説・DB説・ライブ生成説、どれももっともらしかったが、どれも「見ていなかった一番手前の配信バイト数」を素通りしていた。
憶測診断のコストは、直す時間より手戻りにある。推測ベースで原因を断定してメモやドキュメントを書き換えると、外すたびにそれを巻き戻す作業が乗る。実際、ライブ生成説を一度メモに書いてしまい、あとで訂正する羽目になった。
教訓はこう畳める。「重い」の犯人は、処理の奥ではなく配信の手前にいることがある。そして犯人を名指しする前に、まず実データ（サイズ・時間・経路）を一度は自分の目で測れ。 もっともらしい仮説を三つ並べる時間があるなら、一つ測ったほうが速い。
更新履歴
- 2026-07-08: 初稿