Implementation
Connect Fast with one DNS record, and go back in seconds
Your site stays on your hosting and nothing is installed on your server. We change one record, at a time agreed with you, after you have tested the site on a preview address.
How a site gets connected
- A free comparison first. The speed test measures your page with and without Fast. If Fast doesn’t win, you know before anything is agreed.
- Terms and a snapshot of your DNS. You accept the terms for your domain, and we write down your current DNS records, so there is an exact state to return to.
- Server and certificate, prepared in advance. We set up your site on our node and issue a certificate for your domain. Your DNS hasn’t changed, so visitors notice nothing.
- A test on a preview address. You and your developers go through the site there: logins, cart, checkout, forms. We also measure one page with and without Fast on the same host.
- One record changes at an agreed time. We email you the record, its type and its value. Usually that is the value of the
wwwrecord. Mail, subdomains and everything else in your DNS stay as they are. How to change a DNS record. - The first 30 minutes, watched. We follow server errors and compare your key funnel steps with the same hour a day and a week earlier. After that, a separate check opens your site every minute.
What we need from you
- Someone who can change a DNS record at the agreed time, or access for us to do it.
- Your Cloudflare settings, if you’re behind it. We check the SSL mode for your host, and we’ll ask for a token to issue the certificate in advance.
- The paths to leave alone. Tell us what should never go through optimization, such as an account area or a checkout.
Who still sees the original
- Logged-in visitors. We note which cookies mean a person is signed in to your site, and their requests skip optimization.
- Paths you exclude. They pass through our node unchanged.
- Your developers. A link with your token opens the original of the whole site in that browser for 8 hours, so nobody debugs code they didn’t write. The response header
X-WS-Mode: off; reason=devconfirms it, and?_ws_dev=endends it early. It covers pages, not what’s already cached: files stored by your CDN or the browser can stay until a hard reload.
How long going back takes
Measured on our test site on 12 October 2026, from the command to an answer checked from outside.
| What changes | Time | What to know |
|---|---|---|
| Switch on our node | 159 ms | Takes effect on the next request. Visitors get what your server sends. |
| Our configuration, with a release | 3 s | The same result, for when the switch isn’t enough. |
| Your DNS record, put back | 10–24 s | 9.6 s to Google’s public resolver and 23.6 s to Cloudflare’s, with a TTL of 60 seconds. It works without us, even if our node is down. A longer TTL or someone else’s cache takes longer. |
Nothing was installed on your server, so there is nothing to remove afterwards.
Limits
- WebSocket connections aren’t proxied. If your site relies on them, tell us before the switch and we’ll check what that affects.
- PageSpeed measures public pages only. Pages behind a login get no score from us.
Fast and Growth start with a 14-day free trial. See the plans, or leave your site on the monitoring list if that’s what you came for.