Skip to content

1.4.0 — Partial rebuilds

Choose a tag to compare

View all tags
@gunjanjaswal gunjanjaswal released this 21 Jul 06:08
· 7 commits to main since this release
v1.4.0
02ac7ce

Editing a post used to re-render the entire site. Each page costs one HTTP round-trip to the origin and they run one after another, so a 1,400-page site paid 1,400 sequential fetches to fix a typo — the main reason large sites saw rebuilds measured in hours.

What changed

  • Partial rebuilds. Only the pages an edit actually invalidates get re-rendered: the post, its term archives, its author archive, its post type archive, the homepage and posts page, plus their translations. Everything else is reused from the export cache.
  • The export directory is now the deploy source. Rendered pages were always written to wp-content/uploads/sforge-export/, but the deploy was built from an in-memory copy and that directory was never read back. Making it the source of truth is what makes partial rebuilds possible — a Cloudflare Pages deployment is a whole-site snapshot, so the manifest must list every file even when only a few changed.
  • Memory no longer scales with site size. Files are streamed from disk for hashing and read back only for assets Cloudflare reports as new. Measured on a 400 MB export: 489 MB peak before, 73 MB after.
  • Stale pages are pruned, so deleting a post removes it from the live site. Pruning is scoped to HTML and refuses to run when a partial rebuild's URL list looks implausibly short.
  • Two rebuild buttons (changed vs full) and a per-post Rebuild row action.
  • Uploads already mirrored are no longer re-fetched every rebuild.
  • A failed render now keeps the previously exported page instead of dropping it from the deploy.

Upgrade note

Run one Full Rebuild after updating to populate the export cache.

Asset hashing is unchanged, so assets already cached at Cloudflare stay cached across the upgrade.

Assets 2
Loading