Architecture
Transform the page, not a snapshot.
A publish-time function is only right until something it depended on changes. The edge function transforms the current page on each uncached request, so there is no output to keep in sync. This compares the generic pattern, not a specific product.
Side by side
Ten aspects, one difference.
Aspect | Function on publish | loom at the edge |
|---|---|---|
Block code changes (a fix to | Published pages do not change, so every page that uses the block must be found and re-processed or republished | Push the code. The next uncached request uses it (HTML cache is 60 s) |
Shared content changes (nav, footer, fragments) | Every page that embeds it is stale until re-processed, so the overlay must track dependencies | Resolved on each request, so it is always current |
Moving parts | Event or webhook wiring per site, auth, retries, ordering, a place to store results, cache purging | One request-driven function. No trigger, queue or second store |
Source of truth | A second copy of each page that can drift from the authored one | None. |
Failure behaviour | A failed run leaves a page missing or stale until someone notices and retries | Fail open. A failing hook is skipped and the authored page ships |
Previews before merge | Tied to publish events, so an unmerged code branch is hard to see |
|
Rollout and rollback | Roll forward, then re-process the affected pages | Redeploy the previous commit under a new version. This affects every site at once |
Many sites | Usually one pipeline and one set of triggers per site | One function, two sites live today. |
Implementation effort | Build and operate trigger, processing, storage and invalidation layers, per site | Add |
Developer workflow | Usually a separate service with its own deploy | Same repo, same blocks, same git push |
Fair is fair
Where a publish-time function is the better choice.
Speed on a cache miss
A publish-time function has no per-request cost. loom’s measured miss TTFB is about 0.28 to 0.38 s against about 0.09 s for plain EDS. A CDN hit is as fast as plain EDS.
Heavy processing
It is not bound by edge limits (at most 24 hook modules, no dynamic import(), no aem.js in edge blocks), so it suits full headless rendering.
Content freshness
It can update right after a publish, while loom relies on a 60 s TTL because a DA publish did not purge function-wrapped HTML in our tests.
For loom’s goal, making existing content and structured data visible in the first response, the edge is the simpler fit. A team that needs heavy rendering or zero miss latency should weigh the publish-time option.
Be the answer, not just a page.
Content unchanged. Authors unchanged. Crawlers and AI assistants finally read all of it.