Your team carries on working exactly as they do now. Visitors get a separate front end that serves pages already built — so the public side of the site has less in it to be slow, and less in it to go wrong.
The CMS sits on its own address, reachable by the people who actually edit the site. It is the admin they already know, with the same page builder, the same media library and the same drafts and previews.
What the internet points at holds the built pages and little else. There is no editing machinery on it, which is both why it is quick and why there is less of it exposed.
A conventional CMS page is assembled on demand — load the framework, load every active plugin, query the database, render the template — and it does that again for the next visitor, and the one after. A headless front end serves a page that was already built when somebody pressed Publish.
The plugin stack that runs on every request is the usual reason a CMS page is slow. On the public side, most of it is simply not there.
If something breaks while editing, visitors keep seeing the last published version of each page rather than an error.
The login, the admin and the editing endpoints are not on the domain the internet points at, so routine probing has less to find.
Rather than one arrangement, there are three, and which one fits depends on how much of your site is public content and how much happens while somebody is signed in.
Firms, practices, portfolios, publications. Almost everything is published content, so almost everything can be pre-built. The clearest fit, and the simplest to look after.
Where some visitors sign in for gated documents or a client portal. Public pages are pre-built; the signed-in parts run live, so people see their own content rather than a copy of somebody else's.
Catalogue and product pages pre-built; basket, checkout and account always live. This is the arrangement that needs the most care, because getting caching wrong around a basket is worse than not caching at all.
It genuinely does not suit every site, and it is cheaper for everyone to establish that before a rebuild rather than during one.
If most of what your site does happens while someone is logged in, the pre-built portion is small and so is the gain. We would look at caching and tuning what you have instead.
Anything personalising content per visitor, or writing to the database on a page load, needs checking first. We go through the list with you rather than finding out later.
Visitors use your domain; your team uses a separate one to edit. It is one extra bookmark, but it is one more thing to explain to a new starter.
The CMS still needs patching and still needs looking after. A smaller public surface is not the same thing as nothing to maintain.
A well-tuned conventional site on decent hosting is fast. If that would get you most of the way, we will say so rather than sell you a rebuild.
You are changing how the site is delivered, not how it looks. Worth doing deliberately, and worth not doing at the same time as everything else.
How much of it is public content, how much happens behind a login, and which plugins the business actually depends on. That is what decides whether this is worth doing — and we will tell you honestly when it is not.