When I first started building SaaSLaunch, I wanted to include a built-in SEO checker. It seemed like a straightforward feature to add to the starter kit. I spun up a standard Next.js API route using the App Router, deployed it, and called it a day.
But after sharing the beta with a few developer friends in Europe and Asia, I got the same feedback: "The tool works, but it feels sluggish."
I was struggling to understand why. My serverless functions were spinning up in milliseconds, or so the hosting dashboards claimed. That's when I decided to dig into the actual network latency and compare traditional serverless approaches with edge computing to see where the bottleneck actually was.
The Hidden Cost of Centralized Latency
For a tool that analyzes a webpage, network latency isn't just a minor annoyance; it's the core user experience. When a user submits a URL, the backend has to fetch that page, parse the HTML, and return the results.
If my API route is hosted in a single primary region like us-east-1, a user in Tokyo is waiting for the initial request to cross the Pacific. Then, the server has to fetch the target URL (which might also involve cross-region routing), and finally, the response has to cross back.
The cost of ignoring this isn't just a slow UI. It's user drop-off. If a free tool takes four seconds to return a basic SEO audit, users assume the tool is broken and bounce. I needed a way to process these requests closer to the user, which meant re-evaluating my architecture and comparing my options.
Comparing Approaches: Serverless vs. The Edge
I had two main approaches to compare: sticking with standard Vercel serverless functions (which my Next.js 14+ app was already using) versus moving the heavy lifting to Cloudflare Workers at the edge.
Standard serverless is incredibly convenient. It integrates perfectly with the Next.js App Router, handles scaling automatically, and keeps everything in one repository. For things like handling Stripe subscription billing and webhooks, it's the perfect fit. However, it suffers from cold starts and regional latency.
Cloudflare Workers, on the other hand, run on a global network. The code executes in data centers physically close to the user. The trade-off? It requires managing a separate deployment pipeline and dealing with the limitations of the Workers runtime, like lacking some native Node.js APIs.
I decided to build the SEO analysis tool as a Cloudflare Worker. Since SEO analysis is mostly just fetching HTML and running lightweight parsing, it doesn't need heavy Node.js dependencies. It just needs to be fast.
Here is the core of the edge worker I wrote to handle the analysis:
// Cloudflare Worker for edge SEO analysis
export default {
async fetch(request, env) {
const url = new URL(request.url);
if (url.pathname !== '/api/analyze') {
return new Response('Not found', { status: 404 });
}
const targetUrl = url.searchParams.get('url');
if (!targetUrl) {
return new Response(JSON.stringify({ error: 'Missing url' }), {
status: 400,
headers: { 'Content-Type': 'application/json' },
});
}
// Fetch target page at the edge (low latency worldwide)
const response = await fetch(targetUrl, {
cf: { cacheTtl: 300, cacheEverything: true },
});
const html = await response.text();
// Run SEO checks (regex-based, no DOM needed)
const title = html.match(/<title[^>]*>([^<]*)<\/title>/i)?.[1] || '';
const desc = html.match(/<meta[^>]*name=["']description["'][^>]*content=["']([^"']*)["']/i)?.[1] || '';
const h1Count = (html.match(/<h1[ >]/gi) || []).length;
return new Response(JSON.stringify({ title, desc, h1Count }), {
headers: { 'Content-Type': 'application/json' },
});
},
};
Breaking Down the Edge Architecture
There are a few key decisions in this code that highlight the differences between edge and traditional serverless.
First, notice the cf object in the fetch call. This is a Cloudflare-specific extension that allows us to control caching at the edge. By setting cacheTtl and cacheEverything, we can cache the target HTML response directly in the edge node. If another user in the same region analyzes the same URL five minutes later, it doesn't even need to leave the edge network.
Second, the parsing is strictly regex-based. In a traditional Node.js environment, you might reach for cheerio or jsdom to parse the HTML. But at the edge, you want to keep the bundle size tiny and execution time minimal. Regex is imperfect, but for extracting a title tag, meta description, and counting H1s, it's more than sufficient and executes in microseconds.
Practical Results and Lessons Learned
The results of moving the analysis to the edge were immediately noticeable. For example, response times for users outside the US dropped from over a second to under 200 milliseconds in many cases.
What surprised me was how little code I actually had to change. Because I stuck to standard Web APIs (fetch, URL, Request, Response), the transition from a Next.js API route to a Cloudflare Worker was mostly just changing the export syntax. The TypeScript-first approach of the main SaaSLaunch boilerplate made it easy to keep type safety intact across both environments.
If I were to do it again, I'd implement a more robust HTML parser. Regex works for basic extraction, but it breaks down on malformed HTML or sites with unusual meta tag formatting. For a production-grade tool, I'd likely integrate a lightweight WebAssembly-based parser to handle the edge cases without sacrificing edge execution speeds.
Try the Edge SEO Checker
If you're building a SaaS and need to quickly audit your landing page's technical SEO, I've packaged the core logic of this edge worker into a free, standalone tool. You can run your URL through it right now to see how fast edge-based analysis can be, without needing to deploy anything yourself.
Check out the free SEO Checker at saaslaunch.dev/free-tools/seo-checker.
Full disclosure: I'm the developer of SaaSLaunch. I built this because I needed it myself.
Top comments (0)