Build notes › topic

Performance

Where the time actually goes in a WhatsApp inbox, measured with real traffic rather than guessed, including the investigations where the obvious suspect turned out to be innocent.

Covered here: WhatsApp inbox · cache busting · Cache-Control immutable · change detection hash · Cloudflare GraphQL Analytics · Cloudflare Workers polling · Cloudflare Workers Static Assets · conversation list performance · conversation list polling · D1 query plan

• 17 August 2026 · performance

  The WhatsApp inbox that re-downloaded itself every visit

  We were sure the WhatsApp inbox was slow because of the database. Two missing indices and a message-processing path re-fetching the same settings row up to five times, all real, all fixed, none of it the answer: a synthetic request touching no database at all cost the same 502ms as the real conversation list. Real Cloudflare RUM data put the dashboard's median load at 5.0 seconds. The actual cause: over 40 dashboard JavaScript files, every one served Cache-Control: no-cache, including files already carrying a cache-busting hash whose entire purpose was the caching that wasn't happening.

• 10 August 2026 · performance

  The WhatsApp inbox that rebuilt itself every five seconds

  When a WhatsApp message arrives, Meta's webhook delivers it to the server, but the server has no way to push it to the agent's browser. So the inbox polls every five seconds. Until this fix, every poll destroyed and recreated 50 conversation-row nodes, even when no new message had arrived. A four-field hash now compares the list shape before rendering; if it matches, the function skips the rebuild. Full DOM rebuilds dropped from roughly 5,760 per 8-hour shift to a few dozen. Because Klaros is self-deployed, operators can query their own D1 and measure exactly how much redundant work the server does on their behalf.

• 10 August 2026 · performance

  The WhatsApp inbox skeleton that made things worse

  Shimmer skeleton loaders replaced stale content during WhatsApp conversation filter switches. But loadConversations() was a zero-argument function called from 30 sites, including the background poll that checks for new webhook deliveries. The skeleton fired on every poll, flashing every 5 seconds, but only on inboxes smaller than the page size: exactly the state a shop starts in after completing Meta's Embedded Signup. The fix was one parameter: 9 user-initiated call sites pass { skeleton: true }; the ~20 incremental updates (resolving, assigning, sending templates) and the poll do not.

• In progress

  The half of a sale that nobody demos

  Every platform shows you the payment landing. Almost none show you the twenty minutes afterwards: who gets told, who packs it, what the buyer hears while they wait, and what happens when it ships four days later and the messaging window has closed.

• In progress

  Where the ask ends and the shop begins

  A payment request is messaging machinery. A product library is a commerce application, and the part most likely to be replaced by a real one. On finding that seam in our own code, and making it a documented extension point instead of a function that happened to sit in the middle of a file.

• In progress

  What a feature looks like when nothing consumes it

  Contact limits computed on every request and enforced nowhere. A tier ladder that is marketing copy at runtime. On the difference between building a capability and shipping one, found in our own codebase.