Learn Remix - Network Performance & Caching

#Introduction

Episode 9 covered caching at the page level. Episode 14 extends that to the network level: how data moves from the server to users as fast as possible, and how CDNs and the edge help along the way.

A key point that's often misunderstood: Remix doesn't run its own cache — it works together with HTTP infrastructure. Remix sets the Cache-Control headers correctly, and a CDN in front of the server stores copies of pages so users at the edge of the world are served from the nearest location instead of the origin server.

Episode 14 covers HTTP caching strategies, CDN and edge cache integration, prefetching, and optimizing the first load and subsequent navigation.

#HTTP Caching Strategies for Remix

#Building Cache at Every Layer

A cache can live in three places: the browser, the CDN, and the server. The Cache-Control header decides where and for how long data may be stored. Remix's approach is to maximize safe caching, not to apply one policy to every page.

Cache policy per page type

export function headers({ loaderData }) {
  if (!loaderData || loaderData.bersifatPribadi) {
    return { "Cache-Control": "private, no-store" };
  }
  return { "Cache-Control": "public, max-age=60, s-maxage=3600" };
}

The headers function receives loaderData so the policy can adapt to the page's contents. Private data is never cached publicly; public pages are cached aggressively.

#The Two-Level Key: max-age and s-maxage

max-age speaks to the browser, s-maxage to the CDN. Separating them gives you control: the CDN can cache longer than the browser, or the other way around. This is the foundation of the caching strategy in almost every production Remix application.

#CDN and Edge Cache Integration

#Placing a CDN in Front of the Application

A CDN like Cloudflare or Fastly stands in front of the Remix server. When a user requests a page, the CDN checks its cache; if it's empty or stale, the request is forwarded to the origin and the result is stored. The Cache-Control header from the Remix page directly determines the CDN's behavior.

curl -I https://aplikasi-kalian.dev/posts

The curl -I command shows the response headers, including Cache-Control. Use it to verify that both the CDN and the origin send the correct policy.

If the expected header doesn't appear, check the CDN configuration and make sure the Cache-Control policy isn't altered or overridden at the proxy layer. Often the problem isn't in the Remix code, but in how the platform respects headers.

#Edge Cache for HTML

For near-static pages — blogs, documentation, landing pages — edge caching delivers very low latency: users are served from the nearest CDN node without touching the server. Login pages, dashboards, and private pages are excluded.

#Prefetching Data and Links

#Link Prefetch

Remix provides built-in prefetching through the prefetch prop on Link. The "intent" value loads data when the link is hovered or focused; "render" when the link is visible on screen. Prefetch moves the data wait time to the moment you know the user is about to click.

Prefetch when the cursor approaches

import { Link } from "@remix-run/react";
 
export default function Daftar() {
  return (
    <Link prefetch="intent" to="/posts/berikutnya">
      Posting berikutnya
    </Link>
  );
}

With prefetch, the next page already has its data when clicked — navigation feels instant. Mind the bandwidth: prefetching every link can be wasteful, so apply it to the links most likely to be clicked.

Also remember that prefetch works best on pages whose data doesn't change too often. For highly dynamic data like live match scores, prefetch can show stale data when the page opens. Choose your prefetch targets based on how often the data changes.

#Resource Prefetch

For data that isn't part of navigation — for example, the weather shown in a sidebar — use manual prefetching in a component. This pattern complements Link prefetch and makes the app feel responsive without waiting for interaction.

#Optimizing First Load and Subsequent Navigation

#A Light First Load

The first load defines the first impression. Prioritize: send HTML with content (Remix's default), shrink the CSS and JavaScript for the first page, and defer non-critical assets. Measure the first load with Lighthouse and target high scores for metrics like LCP.

#Instant Subsequent Navigation

After the first load, navigation speed is determined by the combination of: nested routes (only the changed parts re-render), prefetch (data is ready), and client caching. Every internal navigation in Remix uses the data cache so the same route is never loaded twice without need.

#Monitoring the Results

Apply real metrics: time to first content (FCP), time to largest element (LCP), and slow interactions. Episode 22 covers observability and real user monitoring at production scale.

Just as important is measuring the impact of every change. Record scores before and after adding prefetch or caching — if there's no meaningful improvement, consider whether the change is worth the added complexity.

#Conclusion

Episode 14 ties network performance together: two-level HTTP caching strategies, CDN and edge cache integration, Link and data prefetching, and optimizing the first load versus subsequent navigation. Your application is now fast on any network.

The key takeaways:

• The Cache-Control header determines browser, CDN, and server behavior.
• max-age for the browser; s-maxage for the CDN.
• Private pages must not be cached publicly.
• A CDN in front of the origin serves users from the nearest node.
• prefetch="intent" prepares data before the link is clicked.
• A light first load and instant subsequent navigation need different strategies.

In the next episode, episode 15, we'll discuss advanced patterns and state — client-side state with React hooks, shared state and server-driven UI, progressive enhancement with optimistic updates, and long-lived data with background revalidation. The network is fast; now let's make interactions feel alive.