Understanding cache tags & Deployment Best Practices - Astro/Vercel

[accounts]

Hi,

I’m currently starting up a new project for a client using Astro for the first time. I’m a relatively experienced FE dev, and I’ve used DatoCMS before, but I’ve never fully focused on getting the most efficient deployments. Now looking into static, SSG and specifically how that incorporates caching and cache-tags. I’m a little lost and confused.

I’ve really appreciated the Astro blog posts explaining their setup - and have begun scaffolding my project using the astro starter. But I’m really wanting a resource to guide me on how to perfect an astro deployment, ideally on vercel.

Vercel seems to have ISR which in my mind will allow me to (somehow) achieve what Dato have done with Fastly? I appreciate this is a very specific issue and one which relates more to deployment and frameworks. But if anyone has resources which would help or advice I’d greatly appreciate it.

Thanks.

[roger]

Hi @accounts,

Great question!

First, a disclaimer: I am not an expert on this; if anyone knows better (@m.finamor, maybe?), please chime in…

Vercel alternative: Use time-based ISR instead?

I don’t believe Astro can use cache tags on Vercel; as far as I can tell, Vercel’s CDN doesn’t allow generic tag-based revalidations across frameworks. (Yes, Vercel can do tag-based invalidation with Next.js, but that’s because it’s built into the Next.js framework and not their CDN… maybe they have some internal APIs that Next uses but that aren’t exposed to the general public or Astro? You can double-check with their support too).

However, Vercel does support time-based ISR on Astro: https://vercel.com/docs/frameworks/astro#incremental-static-regeneration.

To your users, this should function similarly: They still get the performance benefits of statically built pages, and Vercel processes the invalidations & rebuilds in the background.

To you (as the developer), I think the primary downside is more API calls, since every revalidation check will have to query our API — but still less than serverside rendering would use, uncached. Serverside rendering would typically query our API on every page load, while static generation would limit that to once per revalidation period. If a page were set to isr: {expiration: 60} // in seconds, it would make at most one revalidation check per minute to our API.

Other options: Hosting providers that support tag-based invalidation

If you absolutely want cache tags, is Vercel the only option? Netlify has a similar one-click deploy workflow, and their CDN does natively support cache tags: https://developers.netlify.com/guides/how-to-do-advanced-caching-and-isr-with-astro/#on-demand-revalidation-with-cache-tags or read their blog writeup that explains how it works.

That’s basically the missing piece on Vercel. Fameworks other than Next.js have no way to ask Vercel “please invalidate your cache for objects _____, _____, and ______”. Next.js has the revalidateTag() function internally, but I could find nothing like that in the Vercel API outside of Next. Netlify and Fastly both provide an API for that, which is what makes cache tags work there.

There are many other CDNs that support cache tags, like GCP, AWS, Bunny.net, Cloudflare (for enterprise only), etc. Hopefully Vercel will someday, too!

[roger]

(Note: Sorry, edited my post a few times while you were replying.)

[accounts]

Thank you for the detailed response.

You’ve confirmed what I “thought” I knew, which is good as now that is firm knowledge. Rather annoying that vercel doesn’t have that piece of the puzzle.

I will take a look into netlify and other options - the reason for vercel was that my client already does some hosting on the platform so it made sense to continue on it.

I’m really wanting to get this project to run as efficiently as possible with Astro/Dato together which is why I’m so keen for the cache tag setup. Hopefully I should find a solution with another host!

[roger]

Yeah, or give ISR a try and see if it’s good enough? Before cache tags came around, ISR was the default method for fast-performing & quickly-invalidated static pages, and it worked (and still works) well.

It’s also a lot easier to set up: just one line of config will usually make it work, vs the several hours of setup (and endless debugging) that cache tags usually require. There’s a tradeoff between granularity & complexity, and for simpler sites with everyday amounts of reasonable traffic, ISR can be the much simpler and almost always “good enough” approach. It may not be the latest & greatest, but compared to SSR it’s still a huge improvement, and compared to cache tags, it’s only a little slower (depending on your revalidation period).

I also hope Vercel improves their cache tags implementation (and hosting configurability for other frameworks overall), but I’d assume their focus would mostly stay on Next (since they built it). “leerob” is often active on Hackernews and Twitter, if you want to try to reach out to them directly to discuss the situation.

[accounts]

In regards to ISR and keeping requests to a minimum - would another option be to use a webhook to trigger a rebuild of the site when a page has content published?

With ISR it seems that pages are either rebuilt much too often, or pointlessly, as content might rarely be changed. Or you set the expiration much longer, but content changes would not be seen/published quickly when an author has posted a new blog for example.

Obviously triggering a rebuild would only be suitable if content is not being updated overly frequently. But it would mean that API requests only occur when necessary. Is this an approach that you’ve seen used and view as good practice? Or are there issues with this approach.

Thanks

[roger]

Yes, you can use a webhook to trigger a full-site rebuild. That works fine if 1) you don’t have too many pages and 2) you don’t mind rebuilding the whole site whenever any page changes. It’s an approach commonly used for smaller sites, like no more than a few hundred pages at most (it doesn’t scale well for much larger sites because it takes too long and uses too many API calls). This is in fact the use case our built-in “Build Triggers” are meant to cover. Webhooks can do the same thing. (The build triggers are basically just an abstraction over webhooks, with the distinction that they’re easier to set up for Vercel & Netlify than a webhook. And they can also be manually triggered by your editors in Dato using a button in the upper right of the CMS UI.)

I think you also mix-and-match your caching approach, mixing ISR (if you want it) with full-site rebuilds. On Next, you can set different expiration values for each route/page, but that doesn’t seem to be possible with the Astro ISR implementation on Vercel

Instead, you can bypass certain pages from ISR altogether (https://docs.astro.build/en/guides/integrations-guide/vercel/#excluding-paths-from-caching), which I guess means you either statically render them (and manually full-site rebuild them as necessary) or just serve them with SSR. That gives you some granularity, but not as good as Next’s, or Astro on another host.

On Netlify and other hosts, you can also use cache-control headers to tweak ISR behavior (https://developers.netlify.com/guides/how-to-do-advanced-caching-and-isr-with-astro/), but I am not sure if this is possible on Vercel.

In summary, if your Astro site is small and simple enough, a full-site rebuild hook is fine. If it’s going to be pretty complicated or big, and/or requires different caching behaviors depending on content type, I think it might just be easier to convince your client to host it elsewhere (or consider using Next instead of Astro if the project complexity warrants it and they insist on Vercel).

Vercel works very well for Next, but it only has barebones support for other frameworks, and you don’t have full control over its CDN behaviors.

In fact, I don’t know if you already know this, but last year we moved away from Next and rewrote our own homepage (www.datocms.com) in Astro. We serve it using self-hosted SSR on a VPN we control, plus cache tags on Fastly: https://www.datocms.com/blog/why-we-switched-to-astro

[accounts]

Thank you for such a detailed response, it’s really appreciated!

This all makes sense and as you say, it’s probably worth us having a conversation with the client around how important vercel is. I will definitely be looking into other hosting solutions. I definitely feel more concrete in my understanding and going back to the client with this info.

I’ve been following along the blog series keenly - it’s actually what drove me to suggest Astro as a framework in the first place. Looking forward to the next blog entries in the series!

Thanks again!