Gil Eckstein

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.

Rendering a React app with server-side rendering (SSR) can feel bittersweet - on one hand, SSR ensures fast page load and great SEO by rendering the entire page on the server, however the client must download and hydrate all these components to make the page interactive. For pages with lots of content, this can lead to a significant amount of JavaScript being loaded and executed, causing slower interaction times and major performance issues. 

At Wix, we faced a significant challenge: how could we deliver blazing-fast interaction times while avoiding the performance bottleneck of downloading and hydrating every SSR-rendered component on the client? For a long time, this felt like an unsolvable problem - until the new Suspense API changed the game.

In this talk, I’ll share the story of how we tackled this problem head-on, leveraging the new Suspense API introduced in React 18 to dynamically load and hydrate React components only when they enter the viewport. While Suspense's promise-based rendering capabilities aren’t widely documented, they proved to be the game-changing tool we needed to break free from the limitations of traditional hydration and improve the performance of millions Wix websites.

Prepare for a technical deep dive with lots of code examples that will equip you to tackle hydration challenges and boost React performance!

In this talk, we'll dive into Wix's journey towards achieving unmatched web performance through advanced code-splitting techniques in React, tackling the significant challenges posed by large JavaScript bundles and excessive main thread usage. 

As Wix's application expanded, facing increased complexity and demand, traditional performance optimization methods fell short. This presentation will trace the evolution from basic dynamic imports to sophisticated strategies like React component splitting, server-side logic separation, and the adoption of modern techniques including SSR, Suspense, and React server components. Emphasizing the necessity for scalable solutions in large-scale applications, we will also discuss the implementation of the Inversion of Control (IOC) pattern for efficient feature loading. 
Importantly, for each solution, I will provide code examples of both the issue and the solution, suitable for both beginners and advanced React developers. 

This story not only showcases our significant performance improvement but also highlights the importance of evolving optimization strategies to align with the scale of the application, offering insights into transitioning from simple fixes to advanced, robust solutions for enhancing web application performance in React.

Over the past two years, we’ve dramatically improved Wix Website performance, beating all of our competitors in Core Web Vitals. This project was a company-wide effort to finally solve the number one user complaint in the company – live site performance. 
In this talk, I will take a deep dive into the design changes that were implemented to achieve this significant improvement, and explain why and how those solutions could be applied in any web application to achieve similar results.