Prevent layout shift in Dynatrace apps

A new guide covers Cumulative Layout Shift (CLS) in Dynatrace apps, the metric that measures how much visible content jumps unexpectedly after it first renders. The target is below 0.1, and Dynatrace apps have a pattern profile that commonly triggers violations.
Why Dynatrace apps are prone to CLS
Nearly every component fetches data from Grail via useDql. When results arrive, components grow from a skeleton or spinner to their full rendered size. If that size difference is significant, everything below the component shifts. CLS is not limited to the initial page load; shifts that occur later in the session, such as when an asynchronous query resolves, still count.
Three techniques to keep your score under 0.1
-
Match skeleton dimensions to real content—a
<Skeleton />that renders at 60px tall, followed by a<DataTable />at 500px tall, shifts 440px of content down the page. Wrapping the skeleton in a container with a matchingminHeightreserves space, keeping the layout stable as data arrives. -
Use
placeholderDatato preserve previous results when filters change—TanStack Query can show the previous result while a fresh query runs in the background, avoiding a skeleton and the resulting shift. -
Anchor dynamic notifications out of document flow—banners and toasts injected into the block layout push content down. Rendering them in a fixed or absolute container or in a dedicated notification region prevents them from contributing to CLS.
Read the full guide at Prevent layout shift in Dynatrace apps.