Performance & Speed
Our middleware is designed to be invisible. Here's the proof.
TL;DR — Zero Impact on Your Page Speed
The Nexting middleware SDK adds 0ms to your page load time. It doesn't wait for anything, doesn't block anything, and if our servers vanish from the internet tomorrow, your website won't even notice.
What Happens When a Visitor Arrives
Let's walk through exactly what the middleware does on each request. Spoiler: it's very boring, which is exactly the point.
A quick string check — is this visitor GPTBot, ClaudeBot, or another AI crawler? This takes microseconds. If the visitor is a normal human browser, we're already done.
Did this visitor come from ChatGPT, Claude, Perplexity, or another AI platform? Another quick string match. Still microseconds.
We send a tiny event to Nexting's analytics API. The keyword is fire and forget — we don't wait for a response. We don't even check if it succeeded. Your page continues loading immediately.
The middleware passes through. Your visitor sees your page at the same speed as if Nexting wasn't installed at all.
Show Me the Code
Here's the core of what runs on every request. Notice what's missing: no await.
function trackAIVisit(request) {
const ua = request.headers.get('user-agent') || ''
const referrer = request.headers.get('referer') || ''
// Quick string matching — microseconds
let aiAgent = detectAIAgent(ua)
let aiSource = detectAISource(referrer)
if (aiAgent || aiSource) {
// Fire and forget — no await, no waiting
fetch(NEXTING_API, {
method: 'POST',
body: JSON.stringify({ ... }),
}).catch(() => {}) // Errors? Silently ignored.
}
}
export function middleware(request) {
trackAIVisit(request) // Non-blocking
return NextResponse.next() // ← Immediate return
}No await = No waiting
fetch() call fires off in the background. Your middleware returns NextResponse.next() immediately. The network request to Nexting happens in parallel with your page rendering — it never blocks the response to your visitor.How We Compare
Many analytics tools add middleware that blocks page loads. Here's how Nexting is fundamentally different:
| Approach | TTFB Impact | If Service Down |
|---|---|---|
| Blocking middleware await fetch() before responding | +200–800ms | Page hangs or errors |
| Server-side auth check await db.getUser() on every request | +300–700ms | Auth fails, page breaks |
| Nexting SDK fire-and-forget, no await | +0ms | Nothing happens. Page loads fine. |
What About Proxied Pages?
The AI tracking middleware and the page proxy are two separate things. For pages served through the Nexting proxy (your SEO/AEO content), there is an additional network hop to fetch the HTML from our servers. But this is optimized too:
- Pages are pre-rendered as static HTML — no server-side computation
- Responses are edge-cached worldwide — typically served from a server near your visitor
- Your hosting platform caches responses too — repeat visits add zero latency
- Typical first-visit overhead: 50–150ms
Only proxied paths are affected
/seo/*). All your other pages — homepage, blog, app — are completely unaffected.Even Better on Cloudflare
If you're on Cloudflare Workers, we use ctx.waitUntil() to ensure the tracking request is fully decoupled from the response lifecycle:
export default {
async fetch(request, env, ctx) {
// Your page response goes out immediately
const response = await fetch(request)
// Tracking happens entirely in the background
ctx.waitUntil(trackAIVisit(request))
return response // Already sent to visitor
}
}With waitUntil(), the tracking request continues even after the response is sent. The visitor literally cannot be affected.
Common Concerns
“But it still makes a network request, right?”
Yes, but it's like tossing a letter into a mailbox while walking past — you don't stop and wait for a reply. The fetch() call starts a background network request. Your middleware returns the page immediately without waiting for that request to complete.
“What if Nexting's API is slow or down?”
Nothing happens to your visitors. The background request will eventually time out and the error is silently caught by .catch(() => {}). No retries, no error pages, no impact.
“Does it affect my Core Web Vitals?”
No. Core Web Vitals measure user-visible metrics like LCP, FID, and CLS. Since the middleware doesn't add any delay to the response, these metrics are unaffected. We verified this across multiple customer deployments.
“I have high traffic. Will this cause issues?”
The middleware only sends data when it detects an AI visitor, which is typically a small fraction of total traffic. For normal human visitors, it does nothing beyond two quick string checks. Express/Node.js users also get built-in event batching that groups up to 10 events before sending.
Verify It Yourself