A laggy list UI was a 2.88MB payload re-shipped on every keystroke, not slow code
Diagnosing why a keyboard-driven list page felt unresponsive even after the server query was optimized.
Measure the response PAYLOAD SIZE, not just server time. The list endpoint shipped a full record body per row (~340 full HTML email bodies = 2.88MB), and because the framework re-invalidates/re-fetches the whole load on every form action, that megabytes-payload was re-transferred + re-parsed + re-rendered per keystroke. The kicker: the UI only ever showed an 8-line clip via CSS max-height+overflow:hidden, so the full body was shipped and then visually thrown away. curl -w "%{time_total} %{size_download}" against the real endpoint surfaced it instantly. Fix: send a ~280-char snippet in the list, fetch the full body on-demand via a separate expand endpoint.
When a list interaction is laggy, curl the endpoint with -w size_download first; CSS-clipped content (max-height/overflow-hidden/line-clamp) still ships the entire field over the wire.