Make the messages page load fast

What happens when you open the page

This is the normal entry path for a creator with existing conversations, after the route chunk has loaded and the user profile is in the store.

That comes to roughly 1.9 s until the history shows and 2.4 s until it settles, measured from the moment the component starts. Chunk download, guards and the profile request all come before that. The 1.5 s of timers is there on every network, even a fast one.

Direct links (?user=, history.state.user_key, tip-back id) add a GET user/:name lookup and sometimes a group-creation call on top of this.

The biggest costs, ranked

Frontend changes

Ordered so each phase ships on its own and gets measured before the next.

Phase 1. Stop waiting (1 to 2 days, no backend)

1. Delete the timer in getUserEmail(). When a conversation is selected, take the participant from the inbox row and start history and validation in two independent streams. Render each result when it arrives.
2. Give history and validation their own switchMap streams keyed by groupId. Switching from A to B cancels A's requests only, and a response for A can never overwrite B.
3. Split msgrightLoader into historyLoading and permissionsLoading. Show history as soon as it arrives. Render the composer with send, tip and unlock disabled until permissions arrive. If validation fails, keep authorized history readable, leave actions disabled, and offer retry. The server still enforces payment rules.
4. Stop calling checkNewUserValidation() from the inbox response handler. Permissions belong to the selected thread, not the list.
5. Replace the full-screen loader on the first inbox call with a list skeleton built from app-skeleton, following .guides/skeleton-guide.md. Replace the 500 ms scroll timer with afterNextRender.
6. Remove ngAfterViewChecked(). Anything that relied on it is a missed update that needs a targeted markForCheck().
7. In searchResults(), partition first and sort each tab once. Track conversations by groupId and messages by sk, or by uinqueId for optimistic sends.
8. Give search a stream with debounceTime, distinctUntilChanged and switchMap, so a slow old query can't overwrite a newer one.

Expected: history readable at about 0.6 s after component start instead of 1.9 s, with no backend change.

Phase 2. Load less code (2 to 4 days)

1. Wrap the emoji picker in @defer (on interaction) behind a small placeholder button.
2. Render audio messages with a native <audio> placeholder and @defer (on viewport) for ngx-audio-player. Better still, replace it, since it drags in Angular Material for one slider.
3. Put the automated messages tab (app-table, AutomatedMessageModalComponent, dynamic forms) behind @defer (when active === SET_UP_AUTOMATED_MESSAGE).
4. Open NewMessageModelComponent, EditParticipantsModalComponent, MessagePriceModelComponent, the share modals and the image overlay with await import(...) at click time. Remove them from imports, and change the viewChild.required queries that point at them to optional ones.
5. Stop calling lazyCssLoader.loadForVideoPlayer() in the constructor. Load it when the first video renders. Use posters for offscreen videos and instantiate playback on demand; current video elements preload metadata. Many photos already use lazy loading, so check actual requests before changing them.
6. Prefetch the messages chunk when the sidebar Messages link is hovered or focused, or during idle time after login. NoPreloading stays for every other route.

Expected: route JavaScript beyond the shell drops from 630 KB to around 200 KB gzipped. That helps first visits and phones most.

Phase 3. Start earlier and remember (3 to 5 days, pairs with backend)

1. Move inbox and thread state into a providedIn: 'root' MessagesStore service. Kick off the inbox request when navigation to /messages starts or the link is pressed, so the request runs while the chunk downloads.
2. Keep a bounded cache of the inbox and recent threads in MessagesStore. Scope entries to account, tenant, permission context, tab, search, and conversation. Paint cached history, then revalidate and merge. Clear on logout, account switch, or tenant change; reconcile edits, deletions, read receipts, and permission changes.
3. Patch a single row on each websocket message instead of refetching the inbox. This needs the event payload described in the backend section below.
4. Turn history pagination back on. onUp() is commented out, although requests accept timeStamp. Add loading, end-of-history, error/retry, and duplicate-page guards. Preserve the first visible message when prepending. Scroll to the bottom only on initial open or when the reader is already near it.
5. If inboxes regularly exceed about 100 rows, virtualize the conversation list with CDK virtual scroll. Leave the message list alone until profiling says otherwise, because variable-height media makes virtualization tricky there.

Backend changes

These give the biggest gain for large inboxes and busy creators, and they unlock the one-round-trip path. Each one can ship behind a new version while the old endpoint keeps working.

Keep enforcing send, tip and unlock permissions server-side at action time. The permissions in the thread response are a UI hint that can go stale.

• Use stable, opaque cursors. Order history by timestamp plus unique message ID, and inbox summaries by activity plus conversation ID. Equal timestamps must not skip or repeat records. If DynamoDB is confirmed, use its query continuation keys.
• Remove duplicate backend work and run independent reads concurrently. Combining existing serial queries into one endpoint does not make them fast. Keep optional enrichment outside the first-paint path.

Expected effect

Estimates from the component starting to a readable conversation, with 300 ms per API call. Replace them with measured numbers after Phase 1.

Phase 2 doesn't show up in this table because it happens before the component starts. It shortens chunk download and parse on the first visit to the page.

How to verify

• Add performance.mark calls at route activation, inbox painted, history painted and composer enabled. Log them from a production build, not the dev server. Build with --max_old_space_size=10048.
• Compare ng build --stats-json before and after Phase 2, and check that no emoji, Material, datepicker or share-modal chunk loads until it's used.
• Record Chrome traces on a mid-range Android profile with a throttled network, at least 10 runs per build, for an empty inbox, a 20-row inbox and a 500-row inbox.
• Test fast switching between conversations, overlapping searches, incoming messages during load, reconnects and direct links (?user=, tip-back id, history.state.user_key).
• Cover fan, creator, delegate, paid DM, tip-required, guaranteed reply, broadcasts and mailing lists, on TopFans and on one generated white-label project.
• Also test failed validation, pagination retries, equal timestamps, duplicate events, expired reconnect cursors, and account/tenant switches. Assert disabled actions, correct-thread history, stable scroll position, and cleared private state.
• Trace p50/p95 handler and query time, database reads, and compressed response bytes alongside browser timing. Keep message content and credentials out of captures.

Things that must not break

• Paid DM and tip-required prompts. While permissions are loading, the send, tip and unlock buttons stay disabled rather than defaulting to "free".
• White-label behavior. applyDefaultWhiteLabelChatTarget() opens the owner's chat for fans when the user list is hidden, and WLSAllowDMs controls the list.
• Default conversation choice. setInitalDisplay() prefers Priority, then General, then Bulk for creators, and Bulk when history.state.groupId is set. The paginated inbox and the inline first thread must follow the same order.
• Unread counts in the header badge (coreService.messageCount) once pages and deltas replace the full list.
• Optimistic sends and the message queue, which match on uinqueId today.

Roll out without losing messages

1. Feature-flag the new read APIs. Backfill conversation summaries, then compare old and new rows, counts, and default selections before moving clients.
2. Release to a small cohort first. Watch p75/p95 load times, missing-message reports, send failures, duplicate events, unread-count mismatches, and backend load.
3. Keep the old read path available during migration. Expand after TopFans and white-label checks pass; roll back if correctness or latency worsens.

Open questions for the backend

1. How big is a typical and a worst-case get-chatGroups-and-users response, and how long does the handler take at p95?
2. Does getpreviousMessagesFromHttp already cap the page size? The frontend never asks for more, so either it returns everything or old messages are unreachable.
3. Is chat-user-validation slow? It checks subscriptions, free DM quotas and guaranteed replies, and it may be the slowest of the three calls.
4. What's the storage model (DynamoDB keys, GSIs) behind conversations and messages? It decides whether a summary table is needed or a query change is enough.

Code references

MC is src/app/modules/messages/components/message-container/message-container.component.