Warning: Text content did not match. Server: "..." Client: "..." – rendering window in a Next.js page component

The goal is to choose an ISR fallback strategy for a page that accesses browser‑only globals (e.g., window) during initial render, so that hydration mismatch warnings are avoided in development while the HTML served to crawlers remains accurate for SEO.

Constraints include preventing the mismatch warning under React StrictMode, ensuring search‑engine bots receive non‑stale content, and limiting extra JavaScript bundle size that could delay interactivity. The uncertainty lies in whether fallback: true or fallback: 'blocking' better balances these concerns when client‑only data is involved.

Which fallback mode reduces the likelihood of hydration mismatch warnings? Does either mode serve stale HTML that could harm SEO for frequently changing content? How does each mode affect the timing of hydration and the size of the client‑side bundle?