Two guides for faster apps: lazy loading and SWR
Two new performance guides are live, and they tackle the same goal from opposite ends: ship less upfront, and reuse what you've already fetched. Lazy loading splits your bundle so the browser only downloads the code for the view in front of the user. Stale-while-revalidate serves cached Grail results instantly while refreshing them in the background. Together they cover both first load and every navigation after it.
Lazy loading: ship less upfront
By default, an app bundles every page and component into one download, even the ones the user never opens. Lazy loading splits that bundle into chunks that load on demand, using React's lazy() and <Suspense>. The App Toolkit now supports this out of the box.
The highest-impact, lowest-risk place to start is the route level: load only the page the user navigates to. From there, you can defer in-page views that sit behind an interaction (tabs, drawers, modals), and even fire a Grail query while the browser is still downloading the component that will render it. The guide also covers where not to split: anything above the fold, or smaller than ~20–30 KB, usually isn't worth a separate chunk.
Read about how to Understand lazy loading.
Stale-while-revalidate: reuse what you've fetched
Grail queries can take seconds, and much of the data an app shows such as host lists, topology, or configuration, doesn't change second to second. Stale-while-revalidate (SWR) renders cached data instantly, then quietly refreshes it in the background and swaps in the new result if anything changed. No spinner, no blank screen.
You mostly get this for free: useDql from @dynatrace-sdk/react-hooks is built on TanStack Query and ships with SWR support. The guide walks through setting staleTime per data type, using placeholderData to avoid a flash of loading state on filter changes, and the key distinction between isLoading (first load) and isFetching (background refresh).
Read more about Stale-While-Revalidate (SWR).
Why both matter
The two techniques map neatly onto Core Web Vitals: lazy loading reduces the JavaScript the browser parses before first render, which helps LCP; while SWR removes loading states from repeat navigation, which helps INP.