My build times on Vercel increased 6x when I added generateStaticParams

[JamesSingleton]

Summary

I have been facing a lot of issues with Fast Origin Transfer in Vercel for a single project of mine and I reached out to @leerob on Twitter to find out a solution for taking care of this. I asked if adding generateStaticParams to my app/(website)/[slug]/page.tsx could potentially help reduce it and the answer was yes. I use Sanity CMS for all my articles which is roughly 400+ articles. Builds were previously taking 2-3 minutes to build 18 static pages, which I thought was a long time but it was whatever at the time.

I introduced generateStaticParams to my slug page roughly 25 days ago and the last 3 deploys have taken:

• 11m 28s
• 12m
• 13m 46s

I was not expecting a 6x increase when adding generateStaticParams. I use the next-sanity library per Sanity's recommendation. I have it setup like so:

export async function sanityFetch<QueryResponse>({
  query,
  params = {},
  tags,
}: {
  query: string
  params?: QueryParams
  tags: string[]
}): Promise<QueryResponse> {
  return client.fetch(query, params, {
    next: {
      tags,
    },
  })
}

My page's generateStaticParams looks like so:

export async function generateStaticParams() {
  const postPaths = await getPostsPaths()

  return postPaths.map((path) => ({
    slug: path,
  }))
}

Where getPostsPaths() looks like

export function getPostsPaths() {
  return client.fetch<string[]>(postPaths, {}, { token, perspective: 'published' })
}

And that query just grabs the slug from Sanity

export const postPaths = `
*[_type == "post" && defined(slug.current)][].slug.current
`

For the generateMetadata(), I use the same function that I use to populate the page, which is getPostBySlug()

export function getPostBySlug(slug: string) {
  return sanityFetch<PostPayload | null>({
    query: postsBySlugQuery,
    params: { slug },
    tags: [`post:${slug}`],
  })
}

And that postsBySlugQuery looks like:

export const postsBySlugQuery = groq`
*[_type == "post" && slug.current == $slug][0]{
  _id,
  _updatedAt,
  title,
  publishedAt,
  "mainImage": {
    "caption": mainImage.caption,
    "attribution": mainImage.attribution,
    "crop": mainImage.crop,
    "hotspot": mainImage.hotspot,
    "asset": mainImage.asset->
  },
  division->{
    name,
    "slug": slug.current,
  },
  conferences[]->{
    name,
    shortName,
    "slug": slug.current,
  },
  "slug": slug.current,
  "author": author->{name, 'slug': slug.current, bio, role, socialMedia, image, archived},
  excerpt,
  body[]{
    ...,
    markDefs[]{
      ...,
      _type == "internalLink" => {
        reference->{
          _type,
          "slug": slug.current,
          "divisionSlug": division->slug.current,
        }
      },
    },
    _type == 'top25Table' => {
      ...,
      votes[]{
        ...,
        teams[]->{
          _id,
          name,
          abbreviation,
          image
        }
      }
    }
  },
  featuredArticle,
  "estimatedReadingTime": round(length(pt::text(body)) / 5 / 180 ),
  "wordCount": length(pt::text(body)),
  "relatedArticles": *[
    _type == "post"
    && _id != ^._id
    && (count(conferences[@._ref in ^.^.conferences[]._ref]) > 0 || count(tags[@._ref in ^.^.tags[]._ref]) > 0)
  ] | order(publishedAt desc, _createdAt desc) {
    _id,
    title,
    publishedAt,
    "mainImage": {
      "caption": mainImage.caption,
      "attribution": mainImage.attribution,
      "crop": mainImage.crop,
      "hotspot": mainImage.hotspot,
      "asset": mainImage.asset->{
        _id,
        _type,
        url,
        metadata
      },
    },
    division->{
      name,
      "slug": slug.current,
      longName
    },
    conferences[]->{
      _id,
      name,
      shortName,
      "slug": slug.current,
    },
    "estimatedReadingTime": round(length(pt::text(body)) / 5 / 180 ),
    "slug": slug.current,
    "author": author->{name, 'slug': slug.current, archived, "image": { "asset": image.asset->{_id, _type, metadata, url}}},
    excerpt,
  }[0...3]
}
`

How can I reduce these build times because it sounds like a me issue as others are building more pages and "heavier" pages in seconds. What else can I look into?

Additional information

Deps that I think would be relevant:

"next": "^14.1.0",
"next-sanity": "^9.0.20",

[versecafe]

@JamesSingleton This would make sense depending on how many pages you generate now statically generating hundreds or thousands of pages can take several minutes to fetch, process images, load, process, save, and send the caches. I'd recommend trying putting a cap on the generation first 100 or 200 and see if the time increase is linear or not, and writing out the build time and article title to something like redis to quickly grab the data and see if there are some outliers causing the issue to begin to narrow it down.

[JamesSingleton]

That's a good idea. Although, don't you think 2-3 minutes for 18 static pages is also a long time? I'm building 24x more static pages and the build time went up 6x. Someone also suggested to use some sort of in-memory cache and to minimize the number of unique queries. But not really sure where to implement that/how that would help.

[versecafe]

Not really that long if you have to build a large number of components for those pages, and there is caching per component so a lot of the recycled parts should be cached as you keep going, and you could always use vercel data cache to limit querries instead of hitting Sanity which is much faster when fetching data for everything.

[JamesSingleton]

I would say by my data usage that I am definitely hitting Vercel's cache 😅

With a lot of fast origin transfers

I feel like my article pages article extremely heavy though (https://www.redshirtsports.xyz/should-maine-move-future-games-against-merrimack-and-stonehill-to-portland)... Although according to PageSpeed maybe it is 😬 looks like some unused JS, roughly 90 KB

[versecafe]

Damn that's impressive, my recommendation is maybe to tier your articles so only generate the top 30% trafficked cuts down a lot on excessive pre generation and the rest can be left to ISR, it's what I plan on shipping with one site with around 4k articles.

[JamesSingleton]

And how do you determine the Top 30%?

[versecafe]

I'd recommend adding a way of tracking page views, you can use upstash assuming a pro account on Vercel you can just spin up KV for free for tracking it pretty easily with a little component that pings an endpoint.

Client Request -> Page (CDN or ISR) -> Client -> Ping to API -> Update Redis View Count [key: slug, value: views]

[JamesSingleton]

Ah gotcha, I used to do that using Plausible which is what I use for Analytics tracking. It kind of slowed things down a little, but maybe using upstash to track it would be slightly better.