> ## Documentation Index
> Fetch the complete documentation index at: https://stytch.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# SWR & Caching

> Understand how the Stytch SDK implements caching and revalidation strategies

On first load, many websites must make a network request to determine whether a Member is logged in before the site can start rendering the user interface. This slows down users' ability to interact with the application and ultimately leaves them with a sluggish experience.

Stytch SDK's embraces [stale-while-revalidate (SWR)](https://web.dev/stale-while-revalidate/#what%27s-it-mean) - a caching and data fetching strategy that promises faster time-to-interactivity and snappier UX. While SWR is most closely associated with React, the principles can apply to any web application.

Here's how it works:

* The page first loads. Stytch's SDK checks cached data to determine if a Member has logged in previously on the same device, and returns that data to your app immediately.
* Stytch's SDK refreshes the Member's data in the background while your app starts.
* Your app makes requests to your backend to pull in application-specific data. Your backend validates the session stored in the request's cookies, and then completes the request.
* In the rare case that the Member's session has been terminated from another device, your backend will fail the request and return a 401 error. The Stytch SDK will also notify your app that the session is no longer valid through the useStytchMember and useStytchMemberSession hooks or HOCs.

If a SWR approach isn't right for you, you can explicitly call `stytch.member.get()` to refresh the Member object with a network call, and/or `stytch.session.authenticate()` to make sure the Member is still logged in.