Next.js Discord

Discord Forum

Why is revalidate taking much longer than expected/not working at all?

Unanswered
philmeckley04 posted this in #help-forum
Open in Discord
Hi all, I'm trying to locally test out updating content for a blog page dynamically (using headless Wordpress to store and pull data for the blogs). I have revalidate: 10 set in getStaticProps for ISR on a dynamic blog page. However, updates to the published blog pages don't happen when I expect them. The steps I'm taking are:
- Update the page in WP
- Refresh the corresponding Next.js page on local
- Wait 10 seconds plus a few (I have waited anywhere from 10 more seconds to 5 full min) for the regeneration process to finish
- Refresh after waiting
- Updates not showing

I will share my TSX code for the dynamic blog page, let me know if something seems wrong. Thank you for your time!
Please ignore the "any" type assigments - I'm waiting to get this working before properly typing the code.

import React from "react";
import { getAllBlogs } from "@/blogActions";

export const BlogPage = ({ data }: any) => {
return(
<div>
<div style={{ fontSize: "2rem" }}>
{data?.title?.rendered || ""}
</div>
<div dangerouslySetInnerHTML={{ __html: data?.content?.rendered.replace(/\n/g, "<br />") }} />
</div>
);
}

export async function getStaticPaths() {
const data = await getAllBlogs();
console.log(data.map((blog: any) => blog.id));

const paths = data.map((blog: any) => ({
params: { id: blog.slug },
}))

return { paths, fallback: false }
}

export async function getStaticProps({ params }: any) {
console.log(Generating/Regenerating '${params.id}')
const data = await getAllBlogs();

if(!data) return;
const blogData = data.find((blog: any) => blog.slug === params.id);

return {
props: {
data: blogData
},
revalidate: 10
}
}



export default BlogPage;

24 Replies

EDIT: Just tested an update to the blog page in the CMS. It took 13 minutes for Next's regeneration process to finish and for the new version of the page to show. This seems incredibly slow - is there any way to optimize the regeneration time?
Eurasian Curlew
@philmeckley04 many WordPress hosts cache the REST API response for up to 10 minutes. I work at WP Engine and that's what we do by default. I'd check your host's details on this
Hi @Eurasian Curlew , thanks for the response. The cache expiry time for the endpoint I'm using "wp/v2" is set to the default, and 10 minutes is the first alternative option. Does "default" mean something other than 10 minutes in this context, or is the dropdown just giving two different values with the same duration?
Yes
Eurasian Curlew
sorry for all the questions, where is that UI located? User portal or WP Admin?
600 seconds is the default, and you can't actually go lower than that without fully excluding a path from the cache
No problem! Its in WP Admin. Under WP Engine > Caching > Cache Times > REST API Namespaces
Ok
Gotcha
That's how the docs make it sound, just wanted to confirm given the presence of the separate "default" and "10 Minutes" options
Eurasian Curlew
If you check out the WP Engine API section here you could wire up a POST request to purge cache on post/page update https://wpengine.com/support/cache/
This article shows a decent plugin to do that at the bottom: https://wpengine.com/builders/atlas-platform-features-deployment-previews-webhooks/
If you were using GraphQL, I could offer you a better solution 😄
My use case doesn't actually require changing the cache defaults (at least, not yet). I mostly wanted to make sure that I understood the delay in regeneration correctly. Appreciate your response, and thanks for sharing those resources! Will check them out if the need arises.
Eurasian Curlew
Ahh cool, yeah if that's the case, just setting the revalidate time to play nicely with the default cache TTL is the way to go 🙌🏻
Hi @Eurasian Curlew , was wondering if you have any ideas on why when I use a http client service like Insomnia, I see the updated post content immediately, but when I call that same endpoint inside a Next app, I get this delay. If the WP REST API does set a 600 secs expiry time, shouldn't I see the cached response returned to everywhere I call the endpoint (within that time frame, obviously)?
Eurasian Curlew
What does the cache-control header look like in Insomnia
max-age=0, must-revalidate, private
That's odd...
Eurasian Curlew
Are you logged into the backend by chance in the same browser, maybe try incognito
Or that client is somehow bypassing the network cache
Ok trying in incognito
Hmmm, same situation in Incognito