Ask earlier, ask once, and stop asking for what has not changed

Performancekamo-internal
Ya
14 Agosti 2026, 02:25 UTC
Mwandishi
kamo
Ahadi ya
fd3f86d

Three more things standing between opening /messages and seeing mail. Nothing was requested until the bundle had landed. /messages pulls several megabytes of JavaScript, and the component that knows how to ask for mail does not exist until all of it has arrived and parsed — so the first request left the browser only after the last byte had been dealt with. The route is now a server component whose first child is a small client module that does nothing but ask for the folder tree and the first page; it lands in its own chunk and runs while the mail client is still downloading. Whoever needs the data joins the request already in flight, so it stays one request. It has to be a client module even though a server one could start sooner, and the reason is this app's session model. kamo-internal keeps its session per tab in sessionStorage and sends it as X-***-Token; the *** cookie is planted only by the session-extend route, so it is absent for a member who has just logged in and belongs to a different member for someone with two tabs open as two accounts. A server render sees cookies and nothing else. Fetching mail there would fail outright on a fresh login and, on a second tab, could put one member's inbox on another member's screen. Not one dynamic import existed in the messages tree, so the advanced search panel, the label picker, the shortcut overlay, the confirmation dialog, the context menus, the mailbox switcher and the HTML sanitiser behind the reading pane were all in the first chunk. None of them is needed to show an inbox; all of them now load when the member reaches for them. Provider and mailbox-accessibility answers — the two lookups every page load waits on before it can show anything — are cached in Redis for a minute and half a minute respectively, keyed by session and dropped by any write that could change them. Session-keyed and nothing broader: a cache over an authorisation answer is the kind that leaks one person's access to another if the key is too wide, and the session is what the request was authenticated with in the first place. Coalescing is tested from the direction that matters — that it stays one request when two callers want the same page, that it never merges two mailboxes or two folders, and that it does not quietly become a cache and freeze the unread counts the sidebar reloads specifically to refresh.

Mabadiliko yote

Je, unaona nini kuhusu usafiri?

Kila moja ya hizi updates ardhi katika nafasi yako ya kazi moja kwa moja. Kuanza bure na kuangalia kukua wiki baada ya wiki.

Kuwa Huru MileleMtazamo wa bei