Elm ports and Task scheduling under concurrent messages: controlling UI update latency

Goal

An Elm 0.19 application receives messages from several ports and HTTP tasks at roughly the same time. The goal is to keep UI updates responsive when these asynchronous sources emit in bursts, rather than having renders queue up behind a backlog of queued messages.

Constraints and uncertainty

Elm's runtime is single-threaded and schedules updates on the JavaScript event loop, so messages from concurrent requests are processed sequentially. The ordering of port messages arriving from multiple sources appears unspecified, and Task exposes no built-in prioritization or throttling. It is unclear whether observed latency comes from message queueing in the Elm runtime, from batching behavior in the 0.19 scheduler, or simply from the browser's event loop under load.

Questions

• Does Elm 0.19 guarantee any ordering or batching semantics for messages arriving from multiple ports in the same event-loop turn?
• Is there a supported way to throttle or coalesce high-frequency port messages so update does not run once per message during bursts?
• What is a reliable way to measure whether frame drops come from Elm's message queue versus browser rendering, using DevTools?