Slow initial load on SSG webpages with App Router

[ClementCardonnel]

Summary

Hello,

I have a Next.js in production (15.1.5). My website uses App Router and I'd like it to be as fast as possible for SEO reasons. On one of our previous website, we were using Gatsby and we blissfully enjoyed the amazing performance of a fully static website. But this dream has come to an end with Next.js.

Here's an extract of the build log of our website:

├ ● /[locale]/seo/things-to-do/[countrySlug]/[citySlug]                                                           38.3 kB         208 kB
├   ├ /fr/seo/things-to-do/france/cannes
├   ├ /fr/seo/things-to-do/france/nice
├   ├ /fr/seo/things-to-do/france/rennes
├   └ [+18 more paths]
└ ● /sitemap/[__metadata_id__]                                                                                    0 B                0 B
    └ /sitemap/0.xml
+ First Load JS shared by all                                                                                     106 kB
  ├ chunks/1517-15cab6433991e6fb.js                                                                               50.6 kB
  ├ chunks/4bd1b696-46058101eadbcb7f.js                                                                           53 kB
  └ other shared chunks (total)                                                                                   2.08 kB

ƒ Middleware                                                                                                      126 kB

○  (Static)   prerendered as static content
●  (SSG)      prerendered as static HTML (uses generateStaticParams)
ƒ  (Dynamic)  server-rendered on demand

Every page labeled as SSG has a slow initial load, ranging from 1 to 15 seconds depending on the complexity of the page. That initial load destroys our performance metrics, and if Google were to stumble upon a page that loads that slow, it will surely penalize SEO.

We need our pages to be cached during build time. But they are making API calls that need to be cached themselves. And these calls should be invalidated when their own cache expires (we've defined different values depending on the request). So a mix of SSG and ISR if you would.

Basically, I have the exact same problem as the OP of this Reddit post. And as you can see, there haven't been many satisfying answers besides crawling the website to trigger this initial delay.

While I'm definitely considering this solution, I'd like to know if I'm doing anything wrong. Does anyone have any idea on what I should be doing to avoid that issue?

I can provide more details if needed. Thank you in advance!

Additional information

No response

Example

No response

[dvenomb98]

Can you show some examples/snippets of your current implementation?

I'm not sure what you're currently doing, but I'd recommend pre-building all pages during build time to avoid generating routes on-demand. If you have thousands of routes, you could pre-build only the most visited pages and generate less frequently visited routes on-demand as a trade-off to reduce your overall build times.

[ClementCardonnel]

Thank you for helping.

Build time is not a concern. The website isn't huge for now, but even if it is, we want every page built and ready.

Here's a few example of what we're doing:

Some pages use generateStaticParams

export const dynamicParams = false; // or false, to 404 on unknown paths
// export const dynamic = "force-static"; 

export async function generateStaticParams() {
  const generatedParams = await Promise.all(
    locales.map(async (locale: string) => {
      const posts = await getAllThingsToDoPostData({ locale });
      return posts.map((post: IThingsToDoSinglePost) => {
        return {
          locale: locale,
          citySlug: strToSlug(post.sidebarDestination.city),
          countrySlug: strToSlug(post.sidebarDestination.country),
        };
      });
    })
  );

  return generatedParams.flat();
}

When creating pages

In the function building the content of the page, we call functions using async/await.

const post = await getSingleThingsToDoPostData({
    slug: thingsToDoSlug,
    locale: locale,
});

We request Next.js to force cache for all our requests

const res = await fetch(API_URL, {
    method: "POST",
    […]
    cache: "force-cache",
    next: {
      revalidate: 3600, // 1 hour
    },
});

We checked and we don't receive a Cache-Control: no-cache header in our API's response requests.

Edit: We've done testing, and it looks like while the page gets faster after the first load, it's only for a while. After an undetermined amount of time, the cache appears to be invalidated and page load gets slower once again.

[dvenomb98]

I do not see any immediate issues here, but I would recommend checking the following based on your response:

Are you also generating static parameters for each locale? You can find an example here: Next.js Static Generation for Internationalization.

Are you self-hosting or deploying with Vercel? If you re self-hosting, there could potentially be an issue with your cache configuration. I would suggest double-checking this. Next.js Cache Configuration.

Also when testing remember always use next build & next start, cuz in dev mode, routes are generated on each request.

Hopefully you will resolve it soon. I never had problem with load times, even when we were generating around 1 500 pages using same strategy.

[ClementCardonnel]

Thank you for coming back to me on this matter, I do appreciate it. 😌

Your intuition regarding internationalization is good, we suspect it's coming from there as well… We're using Next-intl and I'm not using generateStaticParams for the languages. I don't know if it's an issue.

Do you have any experience with next-intl? Something that's easy to forget regarding caching?

Today we've tried setting route segment config dynamic property to error. Which revealed many errors, some of them related to our next-intl configuration. So far we did not achieve any meaningful breakthrough.

We're hosting the website on Vercel. And we're always running the website with next build & next start because we always want to be as close as possible to the production environment to debug problems like this…

Thanks, we're working to resolving it.

[ClementCardonnel]

OK, we've solved it. Setting export const dynamic = 'error' to all files and then fixing all the errors that appeared did the trick. We then tested the website using next build & next start and everything seems to be static! We're alright now 😀

[codeofandrin]

dynamic = "error"did it for me, thanks!