Incremental Build RFC #763
Conversation
|
One small datapoint in favor of the currently experimental content cache: Audiobookaneers.com build: 21:10:55 [build] 5904 page(s) built in 170.55s 21:13:36 [build] 5904 page(s) built in 118.22s Second build was more than 50 seconds (about 30%) faster. I'm hoping to see similar improvements on the Cloudfront side now that they have a "beta" build cache as well, but so far the gains are a bit more minimal (from 2m24s to 1m54s, though this DID include changes to 3 posts content, though not new posts/tags/etc) and their beta build cache only seems to be holding onto In the "best case scenario" when I add a post to /src/content/posts, the following pages would need to be rebuilt:
I tell you what, this has discouraged me from implementing a 'recent posts' sidebar widget into the static build, as that would mean that every single page on the site would need to be regenerated. I'll definitely just use client-side JS for that! And it makes me think about investigating the "hybrid" approach for the pagination as this would cut down a lot of what needs to be rebuilt. |
|
Build caching idea: //Return a page hash, unique for each page variation
export function getHash() {
//return CMS.pageVersion;
//return CMS.lastUpdateTime;
//return null; //Always rebuild - Sitemap etc
return Astro.props; //Default
}
//OR
export async function getStaticPaths() {
return [
{ hash : /* required for partial building, null by default */ ,params: { /* required */ } ,props: { /* optional */ } },
];
}
---
TEMPLATEIf every page had a function (similar to getStaticPaths) called getHash that produced a unique hash for a particular page, then on a new build a list of the previous hashes and new hashes could be compared and only the ones with different hashes would be built. This assumes that the output HTML is deterministic based of its inputs, for example the default implementation of getHash would return: sha256(Astro.props).
|
|
Summary
Built-in incremental build support
Links