stale-while-revalidate cache control header, what is the expected behavior when a cached page is requested after the stale time has passed?The stale-while-revalidate strategy serves the stale cached content immediately to the user, ensuring fast response times. Meanwhile, it triggers a background fetch to update the cache with fresh content for future requests.
revalidate: 10, what happens when a user requests the page after 15 seconds since the last generation?export async function getStaticProps() { return { props: { time: Date.now() }, revalidate: 10 }; }
ISR serves the existing cached page immediately even if the revalidate time has passed. It then regenerates the page in the background so future requests get fresh content.
export default function handler(req, res) { // Set cache control header here res.status(200).json({ message: 'Hello' }); }
The correct syntax separates directives with commas. Option D correctly uses commas between public, max-age, and stale-while-revalidate.
revalidate: 60. After deployment, the page content never changes even after 5 minutes. What is the most likely cause?export async function getStaticProps() { const data = await fetch('https://api.example.com/data').then(res => res.json()); return { props: { data }, revalidate: 60 }; }
If the API data does not change or is cached upstream, ISR will regenerate the page but the content remains the same. The issue is likely with the API data source, not ISR itself.
let lastGenerated = 0; export default function handler(req, res) { const now = Date.now(); if (now - lastGenerated > 10000) { lastGenerated = now; } res.setHeader('Cache-Control', 'public, max-age=10'); res.status(200).json({ timestamp: lastGenerated }); }
The max-age=10 header tells caches to keep the response for 10 seconds. Since the second request is within 5 seconds, it receives the cached response with the same timestamp.