Does Ariadne Slow Down My Site?

Short answer: no, by design

Related-posts lists are never scored while a visitor is looking at your site. They’re computed once — when a post is saved — and cached. Viewing a page is a plain read of that cached list, the same cost as loading any other piece of that post’s content. This is true even on a fully-cached page: the cached HTML already includes the related-posts markup from whenever that page was last generated, so there’s no separate lookup happening at all.

What actually happens on save

Saving a post does a small amount of real work — re-indexing that post’s own text for local matching, and computing its related list using whatever data currently exists. If AI-powered matching is enabled and this post’s content changed, generating its semantic signal is queued for the background rather than run immediately, specifically so that an external API call is never part of what a real visitor (or an editor hitting Publish) has to wait on.

How background processing stays bounded

A few deliberate safeguards keep background work predictable rather than open-ended:

• How many candidate posts are ever compared for one post is capped (500 by default, adjustable), regardless of how large your site’s matching pool is configured to be.
• Background jobs process a small, budgeted batch at a time, on a short interval, rather than attempting your whole site at once.
• Jobs continue advancing on their own even on a quiet site with little traffic, so a large backfill finishes in reasonable time either way.

Does it work with page-caching plugins?

Yes — since nothing is computed at render time, a related-posts block behaves like any other part of your cached content. The only thing worth knowing: if you change a matching weight or make another sitewide setting change, a cached page won’t reflect the updated related list until that page’s cache is cleared or naturally expires, same as any other content change would need a cache clear to show up.