React 19’s new use() API is often introduced through data fetching: pass a Promise, suspend while it’s pending, and render when the data is ready. But for many React apps, the bigger performance problem is not just waiting for data — it is shipping, executing, and hydrating too much JavaScript too early. Because use() can suspend on any Promise, it opens a bigger performance opportunity: what if a React app could wait not only for data, but for any resource that determines when different parts of the UI should load, render, or hydrate?In this talk, we’ll explore use() as a primitive for resource-driven performance. We’ll start with the familiar data-fetching pattern, then expand the model through several different use cases: selectively loading component code and remote modules, delaying hydration and interactivity based on viewport and user intent, prioritizing critical UI, and even creating SSR-only components.Through practical examples, we’ll see how these use()-driven patterns can help us avoid common performance problems in heavy React pages: too much JavaScript, too much hydration work, and too many components competing for network and CPU before the user actually needs them.By the end of the talk, you’ll see use() not just as a data-fetching API, but as a new way to control when React components should load, render, and hydrate — helping us build faster pages and more intentional user experiences.
