Imagine a world where dynamic web applications are so responsive, they feel as fast as static sites served directly from a user’s local system. That level of speed would create a seamless and delightful user experience. But is that even possible? Dynamic apps need to load HTML, CSS, JavaScript, retrieve data, render the UI, and often pull in more resources as users interact. So how do we achieve snappy performance, especially when screens depend heavily on server data? A “local-first” approach might help, but it’s not always feasible—and not every manager will agree to it. I’ll share strategies I’ve learned from blogs, X (formerly Twitter), and YouTube videos to help close the gap and improve the user experience. **We will discuss the following here** - [The Problem](#the-problem) - [Possible Cause](#possible-cause) - [Possible Solutions](#possible-solutions) - [Poorly written data fetching or async code](#poorly-written-data-fetching-or-async-code) - [`fetch-as-you-render` & `render-as-you-fetch`](#-raw-fetchasyourender-endraw-amp-raw-renderasyoufetch-endraw-) ## The Problem Before jumping into performance strategies, let’s define the problem. The perfect user experience depends on factors like network speed, server latency, and data processing. Our goal is simple: reduce loading states. We won’t focus on code optimization, data structures, or algorithms. Instead, we’ll explore solutions for SPAs that work across frameworks and can be extended to SSR apps. ## Possible Causes One major reason apps feel slow is the network waterfall. This is very well explained on [Remix’s](https://remix.run/) homepage. I encourage everyone to check it out if not already done. But how does a traditional app cause this? Common reasons I’ve seen in many codebases include: * Poorly written data fetching or async code * `Fetch-as-you-render` * Decoupled components that fetch their own data, leading to more `fetch-as-you-render` scenarios Thus the above problem statement can be rewritten as *reducing network waterfall* ## Possible Solutions Tools these days are very good and when used together can handle some of the above scenarios if used properly. Let's see some ways to resolve some of the mentioned above ### Poorly written data fetching or async code Let’s take a look at this function: ```typescript async function fetchUserData(userId: string) { const postsResponse = await fetch(`/api/posts/${userId}`); const posts = await postsResponse.json(); const commentsResponse = await fetch(`/api/comments/${userId}`); const comments = await commentsResponse.json(); return { comments, posts } } ``` This function fetches a user’s posts and comments based on userId. However, it causes a network waterfall because the comments request waits for the posts request to finish. We can improve it by fetching both at the same time: ```typescript async function fetchUserData(userId: string) { const [posts, comments] = await Promise.all([ fetch(`/api/posts/${userId}`).then((response) => response.json()), fetch(`/api/comments/${userId}`).then((response) => response.json()), ]); return { posts, comments }; } ``` By using `Promise.all`, both API calls happen in parallel, removing the waterfall delay. There are many methods available on Promise that can be useful in different scenarios >Not all API calls can be parallelized—some may depend on the results of others—but many don’t. For dependent requests, this optimization doesn’t apply, and further strategies would depend on specific cases (which we won’t cover here). >The example above doesn’t handle errors, as it’s just for demonstration. ### `fetch-as-you-render` & `render-as-you-fetch` This is an interesting one and is very very common in codebases. So, what is `fetch-as-you-render` and how does it cause delayed UI? `fetch-as-you-render` is caused when data is fetched inside a component and the Fetch-as-you-render happens when data fetching is triggered inside a component, often during the render phase or in lifecycle methods like useEffect. This is common across many frontend frameworks such as `Solid`, `Svelte`, and `Vue`. Imagine you have three nested components, each fetching its own data. This creates a scenario similar to poorly written data fetching: each component’s data fetch starts only after the component is rendered or mounted. This not only delays the rendering but can also cause additional delays as each fetch waits for the previous one to complete. Let look at a piece of code: ```typescript function UserDataViewer() { const [user, setUser] = useState(null); const [isLoading, setIsLoading] = useState(false); useEffect(() => { setIsLoading(true); fetchUser().then((_user) => { setUser(_user); setIsLoading(false); }); }, []); if (isLoading) { return

; } return ( <> ; ); } function Posts({ userId }: { userId: string }) { const [posts, setPost] = useState(null); const [isLoading, setIsLoading] = useState(false); useEffect(() => { setIsLoading(true); fetchUserPosts(userId).then((_posts) => { setPost(_posts); setIsLoading(false); }); }, []); if (isLoading) { return

; } return ( // A static component to show Posts ); } function UserCommentsViewer({ userId }: { userId: string }) { const [comments, setComments] = useState(null); const [isLoading, setIsLoading] = useState(false); useEffect(() => { setIsLoading(true); fetchUserComments(userId).then((_comments) => { setComments(_comments); setIsLoading(false); }); }, []); if (isLoading) { return

; } return ; // A static component to show comments } ``` The provided code demonstrates the `fetch-as-you-render` pattern, which can lead to delayed UI updates. Here’s how: 1. `UserDataViewer`: It fetches user data and waits for it to complete before rendering the `Posts` and `UserCommentsViewer` component. 2. `Posts` & `UserCommentsViewer`: Once `UserDataViewer` has fetched and set the user data, `Posts` fetches posts based on the user ID. In this setup, each component fetches its data only after the previous component’s data is available, causing a cascading delay. Each fetch operation waits for the component to render or mount, leading to slower overall page load times. Fetching data per component is a common pattern to have colocation but can lead to inefficiencies. Libraries like `@tanstack/react-router` and `SWR` simplify the process, but the `fetch-as-you-render issue` remains. Hoisting data fetching to a parent component helps, but what if that parent component is rendered within another component? How can we further improve this approach? `Render-as-you-fetch` is a interesting pattern that can improve this situation. This can have its own blog, maybe I will write this in more details some other time, but let's directly jump to a solution. Most frameworks provide data loaders integrated with their routers. For example, `react-router-dom` has [loaders](https://reactrouter.com/en/main/route/loader) and [actions](https://reactrouter.com/en/main/route/action), `@tanstack/react-router` offers [loaders](https://tanstack.com/router/latest/docs/framework/react/guide/data-loading), `@solidjs/router` uses a [load function](https://docs.solidjs.com/solid-router/reference/load-functions/load), and `@sveltejs/kit` includes [load function](https://kit.svelte.dev/docs/load). Let’s explore how we can leverage `react-router-dom` and its loader and composition to improve data fetching efficiency. ```typescript export async function loader() { const { userId } = await fetchUser(); const [posts, comments] = await Promise.all([ fetch(`/api/posts/${userId}`).then((response) => response.json()), fetch(`/api/comments/${userId}`).then((response) => response.json()), ]); return { posts, comments }; } function UserDataViewer() { const { posts, comments } = useLoaderData(); return ( <> ); } ``` The code above eliminates the waterfall effect by fetching data in the loader and passing it to the component as props. While this approach blocks user navigation until the data is fetched, you can adjust this behavior using `Await`, `defer`, and `Suspense` components. For more details, [refer to the guide in the react-router-dom documentation](https://reactrouter.com/en/main/guides/deferred). But this above code has one problem, the data fetching is completely moved to loaders, and the colocation with component is lost. What if I want to drop `UserCommentsViewer` in another component in another route? I have to make sure that the data loader their fetches the data and correctly pass it to component, I cannot expect that I drop a component and it just works. Let's improve this further using `@tanstack/react-query` ```typescript export async function loader() { const { userId } = await fetchUser(); void queryClient.ensureQueryData(getPostsQueryOptions(user.id)); void queryClient.ensureQueryData(getCommentsQueryOptions(user.id)); return { userId }; } function UserDataViewer() { const { userId } = useLoaderData(); return ( <> Loading...}> Loading...}> ); } function Posts({ userId }: { userId: string }) { const { data } = useQuery(getPostsSuspenseQueryOptions(userId)); return

{/* The actual code to render */}

; } function UserCommentsViewer({ userId }: { userId: userId }) { const { data } = useQuery(getPostsSuspenseQueryOptions(userId)); return

{/* The actual code to render */}

; } ``` This code tackles the waterfall issue while keeping the data fetching colocated with the component. The above code works as follows - 1. **Loader Function**: Instead of just letting the components fetch their own data, the loader triggers the actual api call parallely. This prevents the waterfall. The code above will also render the route without waiting for the data to be fetched, this can be modified by awaiting them. 2. **Colocated Data Fetching**: The `Posts` and `UserCommentsViewer` components use `useQuery` to access the already-fetched or ongoing fetch data. Since the loader has done the heavy lifting, these components can render themselves without worrying about the waterfall. Another great thing about these components is that they’re self-contained. You can drop them anywhere in your React app, and they’ll work just fine. Of course, if you move the component, the route loader will need the prefetch logic too, but that’s easily handled. There’s another cool benefit to using loaders for prefetching. Most routing libraries can prefetch data when a link is hovered over or rendered, meaning the data is ready before the user even clicks the link. This taps into the `render-as-you-fetch` pattern, where the component already has the data by the time it renders, eliminating the need for fetch calls inside the component. I personally find this approach clean and efficient. I stumbled upon this while digging through the `@tanstack/react-router` docs. You’ll find a similar implementation in the [Solid.js repo for Hacker News](https://github.com/solidjs/solid-hackernews/blob/tanstack/src/routes/stories/%5Bid%5D.tsx). Of course, there are plenty of other reasons why web apps might feel slow, and frameworks are constantly rolling out new solutions. But these approaches are relatively easy to incorporate into existing codebases and can make a noticeable difference. >Hey everyone! This is my first blog, and I’d love to hear your suggestions and feedback to help me improve. I wrote this to share some solutions I’ve come across while working on codebases and tutorials, where I’ve noticed these common issues pop up. Let me know what you think!

shubhajit_chatterjee

Performant Web Apps

Join Our Newsletter. No Spam, Only the good stuff.