CDK virtual scroll with fixed item heights or a custom VirtualScrollStrategy for a variable-height Ionic feed

Short answer

For a chat-style feed with mixed text, images, and preview cards, enforcing fixed (or at least pre-reserved) heights is the pragmatic default, and a custom VirtualScrollStrategy is only worth the maintenance cost if your design genuinely cannot reserve space for media. The deciding factor is not whether a custom strategy works — it does — but whether you can keep measured heights stable after render. If heights change after the viewport has positioned content, you get visible scroll jumps, and mobile WebViews make this worse, not better.

Why the default strategy struggles here

cdk-virtual-scroll-viewport with itemSize assumes every row has one known height. It computes total scroll extent as count × itemSize. In a feed where a one-line message might be 48px and an image card 320px, any single itemSize mis-sizes the scrollbar and causes drift between the rendered window and the scroll position. So your two candidate paths are the right ones; there is no third built-in option in current CDK versions.

Option A: normalize to fixed heights

Reserving aspect-ratio boxes for images and preview cards before the media loads is the key move. The item height is then known before render, so the default strategy works as designed:

• Text messages: cap at a max height with line-clamp, or bucket into two or three fixed size classes if your design tolerates it.
• Images/cards: use a CSS aspect-ratio placeholder sized from the media metadata your backend already sends (width/height), so the row height never changes when the image finishes loading.

This eliminates the entire class of async-height bugs and composes trivially with ion-infinite-scroll: appending items just extends the array, and the extent math stays correct. The cost is UI compromise — short messages waste vertical space if you pick one height for everything.

Option B: custom VirtualScrollStrategy

A custom strategy that measures rendered items (via ResizeObserver or explicit measurement after change detection) is reliable in production if heights are stable once measured. The documented pitfall class you asked about is real: when an async image loads and changes an item's height above the current scroll offset, the content under the user's finger shifts. Mitigations:

• Reserve aspect-ratio boxes anyway, so measurement rarely changes after first layout. At that point the custom strategy mostly handles text variation.
• When a height changes above the viewport, adjust scroll offset by the delta instead of letting content jump.
• Cache measured heights per item ID, not per index, so pagination prepends/appends don't invalidate everything.

Expect to own the test surface: scroll retention across pagination, font-size changes, and orientation changes on real devices, not just desktop Chrome.

Interaction with ion-infinite-scroll

Appending at the bottom is the friendly case for both approaches: new items extend the list past the current viewport, so existing offsets are unaffected. Two things to verify:

1. Fire the infinite-scroll threshold from the CDK viewport's scroll events (e.g., elementScrolled() / rendered range) rather than assuming ion-infinite-scroll sees the inner scroll element — depending on your DOM structure, the scrollable element is the viewport, not the ion-content. This is the most common integration bug in this migration.
2. If you ever prepend (loading older chat history), fixed heights make offset restoration simple arithmetic; a custom strategy must recompute and restore position manually.

Recommendation and verification

Given that your backend can supply media dimensions, I'd normalize: aspect-ratio placeholders plus a small set of text height classes, default itemSize strategy, done. Reserve the custom strategy for when design rejects clamping. Either way, verify on-device:

• Scroll to mid-feed, append a page via infinite scroll, confirm the viewport does not jump.
• Simulate a slow image (delay load ~200ms) and measure scroll-position delta; it should be ~0 with reserved boxes.
• Confirm the exact ion-virtual-scroll deprecation/removal status against your installed Ionic major (v7 vs v8) before scheduling the migration.

One detail that would change this recommendation: if your backend cannot provide media dimensions up front, fixed heights become much harder and the custom strategy with delta-compensation becomes the better bet.