アプリ/フロント基盤

htmxとは|断片だけ返す方式が有利なのは、1画面あたり50回の操作までだった

何を送り、どこを書き換えるのか転送量はどれだけ減るのか有利でなくなるのはいつか

操作20回までなら、断片だけ返す方式の累計は297KBです。全ページを取り直すと2520KBでした。

ところが50回では547KBで、画面側で組み立てる方式の502KBに追い抜かれます。

この記事の要点

  • 20回で297KB
  • 全ページなら2520KB
  • 50回で逆転する
  • 返すのはHTML

断片だけ返す方式が有利なのは、1画面あたり50回の操作までだった

最初の配布が軽い分だけ先に立ちます。操作が積み重なると、その差を使い切ります。

htmxが受け取るのはHTMLです。出典はこう定めています。

htmxは、自らが行う呼び出しへの応答がHTMLであること、多くの場合はHTMLの断片であることを期待するという記述です。

断片なら小さくなります。どこまで小さいのかを数えました。

操作の回数を積み上げる

ページ全体を120KB、うち毎回変わらない外枠を96KBとしました。書き換わる領域は操作ごとに引き直します

text
ページ全体 120KB、うち毎回変わらない外枠 96KB
1回の操作で書き換わる領域は平均 8.4KB。画面側で組み立てるなら別に 190KB を一度配る

操作の回数  全ページを取り直す  断片だけ返す  画面側で組み立てる
1回                       240KB         139KB               319KB
5回                       720KB         172KB               334KB
20回                     2520KB         297KB               390KB
50回                     6120KB         547KB               502KB
200回                   24120KB        1798KB              1065KB

20回の時点で、断片だけ返す方式は297KBです。全ページを取り直す2520KBの8.5分の1になります。

1回だけの利用者でも139KBで、画面側で組み立てる319KBより軽くなります。

逆転する位置

50回の行で入れ替わります。547KBと502KBで、差は45KBです。

200回になると1798KBと1065KBで、1.7倍の開きがつきます。

理由は最初の190KBです。画面側で組み立てる方式は、その190KBを操作の回数で薄めていきます

だから判断の基準は1画面あたりの操作回数です。検索して並べ替えて詳細を開いて戻る、という使い方が50回に届くかどうかで決まります。

最初の軽さと、1回あたりの軽さが入れ替わる。

断片が軽い組み立てが軽いそこまでの累計の転送量1画面あたりの操作の回数 →断片だけ返す(最初139KB)画面側で組み立てる(最初319KB)並ぶのは20回と50回のあいだ200回では1798KBと1065KBで1.7倍の開き※ 軸の目盛りは省略。ページ120KB・配布190KBという値は置いたもので、自社の実測で計算し直す必要がある。
図1 ── 操作の回数と累計の転送量
出典htmx 公式ドキュメント「Documentation」2026-08-18 確認
Htmx expects responses to the AJAX requests it makes to be HTML, typically HTML fragments (although a full HTML document, matched with a hx-select tag can be useful too).
原文htmx 公式ドキュメント「Documentation」 この内容の有効期限2027-02-18

どこを差し替えるかは、返す側ではなく呼ぶ側が決める

同じ応答でも、差し替え方の指定によって置き換えにも追加にもなります。

htmxには差し替えの方法が複数あります。出典はhtmxは、返ってきたHTMLを画面へ差し込むための、いくつかの異なる方法を提供すると述べています。

選べるのは呼ぶ側です。返ってくるHTMLは同じでも、置き換えるか、前後に足すかを指定で変えられます

差し替えの決め方

  1. どの要素を対象にするか。押した要素とは別でもよい
  2. 中身を置き換えるか、要素ごと入れ替えるか
  3. 前後に足すか。一覧の追い読みはこの形になる
  4. 何も差し替えないか。送るだけの操作もある

3番目が転送量に効きます。追い読みなら、すでにある行を送り直しません

前の計測の平均8.4KBは、この使い方を含んだ値です。置き換えの範囲が広い操作ほど、この値が上がります

どこに書くか

指定は要素の属性として書きます。その場所を見れば、何が起きるか分かります

その代わり、画面の挙動が要素に散ります。全体の流れを1箇所で読むことはできません。

呼ぶ側が対象と方法を決め、返す側は断片だけを返す。

全 3 段対象と方法を決める属性の指定で呼び出す平均8.4KBサーバーが断片を返す置換・追加を選ぶ指定の場所を差し替える返ってくるのはHTMLなので、画面側に組み立ての記述を持たない。差し替えの範囲だけが転送量を決める。
図2 ── 1回の操作で起きること
出典htmx 公式ドキュメント「Documentation」2026-08-18 確認
htmx offers a few different ways to swap the HTML returned into the DOM.
原文htmx 公式ドキュメント「Documentation」 この内容の有効期限2027-02-18

既存のHTMLを返す作りに、そのまま足せる

返す形式が変わりません。すでにHTMLを返している仕組みなら、載せ替えが要りません。

htmxを使うとき、サーバー側の返し方は変わりません。出典はhtmxを使うとき、サーバー側では通常、JSONではなくHTMLで応答すると念を押しています。

つまり取り込むのに、返す形式を作り替えなくて済みます

段階的に入れられる

画面全体を作り替える必要がありません。1つの一覧、1つのフォームから始められます

前の計測でいえば、操作回数の多い画面だけを別の作りに残すという混ぜ方ができます。50回を超える画面は別扱いにする、という判断です。

動く部分だけを配る考え方はAstroの記事でも測っていて、配る量は22.5%まで落ちました。狙いは近いものです。

向かない場面

  1. 操作が50回を超える画面。転送量で不利になる
  2. 通信を挟めない操作。往復のたびに待ちが入る
  3. 同じ画面を複数人で見る場面。差分の配り方が別に要る
  4. 画面側だけで完結する計算。サーバーに聞く理由がない

2番目は転送量に出ません。1回8.4KBでも、往復の待ちは別にかかります

余談 この計測での注意

ページ120KB・外枠96KB・配布190KBという値はすべて置いたものです。書き換わる領域の大きさも式で作りました。印の少ない形にすると0.45倍になるという係数も置いた値で、実際の比率は中身によって変わります。ここで見せているのは、最初の配布が重い方式は操作回数で薄まるという関係で、逆転する位置は自分のページの大きさから計算し直せます。

出典htmx 公式ドキュメント「Documentation」2026-08-18 確認
Note that when you are using htmx, on the server side you typically respond with HTML, not JSON.
原文htmx 公式ドキュメント「Documentation」 この内容の有効期限2027-02-18

よくある質問

htmxは何を送りますか
HTMLです。呼び出しへの応答がHTMLの断片であることを前提にしています。
転送量はどれだけ減りますか
操作20回の時点で2520KBが297KBになりました。8.5分の1です。
ずっと有利ですか
違います。この計測では50回のあたりで、画面側で組み立てる方式に追い抜かれました。
どこが書き換わりますか
指定した場所です。返ってきたHTMLをどう差し替えるかは、いくつかの方法から選べます。

まとめ

  • 応答はHTMLの断片
  • 書き換えは指定した場所
  • 操作が少ないほど有利
  • 多い画面では逆転する

今日から始められること

  1. 1画面あたりの操作回数を数える
  2. 1回で書き換わる領域の大きさを測る
  3. 全ページの大きさと比べる
  4. 50回を超える画面がないか探す

実務で組んだhtmxのワークフローには、値段が付きます

同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。

出品の仕組みを見る