Optimistic Navigation: Creating the Illusion of Performance

In a world where speed defines digital success, slow websites drive users away. Even optimized websites suffer from slow navigation due to weak internet connections or server overload. Web developers usually solve this problem by using prefetching, which wastes more server and client resources. Optimistic navigation offers an alternative solution: by masking network delays, the user interface updates optimistically, creating the illusion of faster or even instant navigation.

The Problem: Slow Navigation and Unresponsiveness

Picture this: you click a link, and for a second, nothing happens. The website appears broken as the interface freezes, displaying no progress. In the demo application below, you can experience slow navigation firsthand. Click on the article card and the "Home" link; repeat until you get bored.

What Are Optimistic UI Updates?

Optimistic UI updates provide instant feedback on user actions. They can be implemented in two ways:

Rendering with Predicted Data: The UI is rendered using cached or predicted data, assuming the server response will match. For example, when a user likes a post, the like count instantly increases by one.
Rendering without Predicted Data: A skeleton or loader is displayed while the server response loads.

When implementing optimistic UI updates, adhere to these guidelines:

Synchronize with Server Data: If the server response differs from the predicted data, update the UI to reflect the actual server data.
Handle Errors Gracefully: If the server returns an error, revert the UI to its previous state or display an appropriate error message.

Optimistic UI updates enhance perceived performance and deliver immediate responsiveness to user actions.

Optimistic Navigation and the Illusion of Performance

Navigation feels incredibly fast, when the page is rendered optimistically with predicted data that fills the entire viewport. Users can interact with the page instantly, and by the time they scroll to unloaded sections, the actual data may already be there.

Even if users notice loading, engaging with predicted content beats staring at a blank screen. Optimistic navigation is like a waiter serving you an aperitivo while the main course cooks.

Traditional Navigation: Click → Wait → Render.
Prefetching: Preload → Click → Render.
Optimistic Navigation: Click → Render Predicted Data → Sync with Server.

The demo app below shows optimistic navigation in action.

Recycling Data: Utilizing What’s Already There

In the demo app above, clicking on an article card takes you to the article page, which displays the same thumbnail, title, and description. From a data perspective, on the main page we make a request for a list of articles, and on the article page we request the article detail object.

Typically, a query for a list of entities returns partial data, while a query for an entity object returns the full data of that entity. Use the data from the list of entities to render the detail page optimistically. The more data you get in the entity list, the more content can be rendered instantly.

While optimistic navigation doesn’t reduce server response times, it keeps users engaged during delays, potentially lowering bounce rates. A well-designed optimistic navigation can hide 3-10 seconds of network lag from the user, depending on how fast they are scrolling the page. I achieved this in that Tanstack-Start starter. Reduce your internet speed to 3G (via the developer console) and test it yourself.

Building Trust Through Consistency

Optimistic navigation renders the opened page in 16 milliseconds. It feels seamless, like flipping through a glossy magazine. This reliability builds user trust and increases the number of links being opened over time.

After implementing optimistic navigation, the "Interaction to Next Paint" metric became evergreen (≈16 ms.), and user engagement increased by 11.3%. Which led to an increase in Google search results. This result is based on a six-month study of a media site with 10,000 daily users.

Drawbacks of Optimistic Navigation

No solution is flawless. Here are the trade-offs of optimistic navigation:

In some cases, it requires returning more data for entity lists.
Memory Usage: Storing predicted data can increase memory consumption by 1–2 MB.
Potential Confusion: If predicted data mismatches the server response, the page re-renders.
Hard to implement.

Implementation with <Suspense/>

Modern SSR meta-frameworks offer to achieve optimistic UI with the Suspense component. Suspense allows showing a fallback UI while data is fetching in the actual view. Below is an example of using the React Suspense component:

<Suspense fallback={<SkeletonArticlePage />}>
  <ArticlePage />
</Suspense>

As written above, an optimistic UI can be rendered in two ways; let's consider how Suspense copes with each of them:

Rendering the skeleton version. Suspense works fine in most cases.
Rendering with predicted data: the page content rendered via the fallback property will be removed from the DOM and replaced with the final component (<ArticlePage />) when the page content is loaded. Such a replacement will cause the interface to flicker and the state accumulated in the fallback version to be lost.

The Suspense component is only suitable for displaying the non-interactive skeleton version of a page; showing predicted data will cause UI flickering and bad UX.

Implementation with React Query

During soft navigation, meta-frameworks freeze the interface, waiting for the async function that loads data (getServerSideProps/loader). To achieve the effect of a glossy magazine, you need to:

Skip the call of the data request (getServerSideProps/loader) during soft navigation
Run those data requests from the client via React Query.
Utilize the placeholderData property of the useQuery hook, to pass predicted data.
Handle loading state.

To implement the first step in Next.js, I had to create the `next-query-glue` library, which modifies the behavior of the Next.js router. Tanstack-Start is the only meta-framework where such a level of freedom is available without hacks.

If you want to see a complete implementation of optimistic navigation with react-query, here are two starters I made:

The example of code below shows how you can optimistically render an article page with react-query .

const ArticlePage: React.FC = () => {
  const { data, isLoading } = usePageData<ArticlePageProps>();

  if (!data || isLoading) {
    return (
      <SkeletonArticlePage />
    );
  }

  return (
    <div>
      <img src={data.thumbnail} alt=""/>
      <h1>{data.title}</h1>
      <h1>{data.description}</h1>
      <ArticleContent />
    </div>
  )
}

const ArticleContent: React.FC<PropsWithChildren> = ({children}) => {
  const { data } = usePageData<ArticlePageProps>();

  if (!data?.content) {
    return (
      <SkeletonText />
    )
  }
  return (
    <div>{data.content}</div>
  )
}

Prefetching vs. Optimistic Navigation

Prefetching is a common alternative to optimistic navigation. It triggers when a link enters the viewport or is hovered over, significantly reducing perceived load times when the user clicks.

Pros:

Ease of Use: Supported by most routers and meta-frameworks.
Can significantly speed up navigation.

Cons:

Inconsistency: Users with slow internet and weak processors may experience delays.
Resource Consumption: Drains batteries, wastes internet traffic, and raises hosting costs.
Data Staleness: Prefetched content can become outdated once used for rendering.
Environmental Impact: Increases CO2 emissions due to more network requests. By opening Amazon/Facebook/Twitter and looking into the network tab, you'll find hundreds/thousands of wasteful prefetching requests.
SEO Penalties: May negatively impact SEO due to excessive use of user resources.

Conclusion

Modern web development increasingly bets on prefetching content for fast navigation. Optimistic navigation takes a different path, crafting the illusion of instant content loading to elevate the website’s perceived performance.