How I Fixed Global SaaS Latency with Edge Workers

When I first launched my side project, I thought standard serverless functions were enough. I deployed to a major cloud provider, hooked up my database, and called it a day. But when friends in Europe tried to use it, the lag was unbearable. Every API call felt like it was crossing an ocean. I was struggling with cold starts and inconsistent response times, and my users were bouncing before the page even loaded. I realized that if I wanted to build a truly global SaaS, I couldn't rely on a single region's serverless setup. So I decided to build something different.

The problem with traditional serverless APIs for global SaaS products is simple: physics. If your functions run in us-east-1, a user in Tokyo is waiting for network requests to cross the Pacific. For a simple CRUD app, this might add 200 milliseconds. But for a SaaS dashboard making multiple sequential API calls, that latency compounds. Users notice the sluggishness. They don't blame the network; they blame your product. The cost of ignoring this isn't just technical—it's retention. When you're competing against established players, a snappy, responsive UI is often the only differentiator you have as an indie developer.

To solve this, I rethought the architecture. I needed a stack that could run compute at the edge, close to the user, without sacrificing the developer experience of Next.js.

I chose Next.js 14 with the App Router for the frontend and core logic, but I offloaded latency-sensitive API routes to Cloudflare Workers. This hybrid approach keeps the heavy lifting (like rendering complex React Server Components) on Vercel, while pushing data fetching and lightweight processing to the edge.

A perfect example is the SEO analysis tool I built. Fetching and parsing external URLs from a central server is slow. By moving this to a Cloudflare Worker, the fetch happens from a node geographically close to the user.

Here is what that edge worker looks like in practice:

// 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' },
    });
  },
};

In this setup, the Worker intercepts the request. We use Cloudflare's native fetch with caching options to grab the target HTML. Because it's running at the edge, the network hop to the target URL is minimized. We then run lightweight regex checks for the title, meta description, and H1 tags. This avoids the overhead of spinning up a headless browser or loading a heavy DOM parser at the edge. It returns a clean JSON payload in milliseconds.

For the core SaaS logic, I integrated Stripe for subscription billing. Handling webhooks reliably is critical, so I built a dedicated Next.js API route that verifies Stripe signatures and updates the database via NextAuth.js sessions. TypeScript-first across the entire monorepo ensures that the types for Stripe products and NextAuth sessions remain strictly aligned, preventing a whole class of runtime errors.

Moving the API routes to the edge changed the feel of the application entirely. The dashboard interactions went from feeling "web-like" to feeling almost native. What surprised me most was how easy it was to deploy. With one-click deployment to Cloudflare Pages for the edge workers and Vercel for the Next.js app, the CI/CD pipeline practically built itself.

If I were to change one thing, I would abstract the edge worker configurations earlier in the process. Initially, I tried to mix edge and serverless logic in the same files, which made environment variable management a headache. Separating the workers/ directory from the app/ directory in the repo made the mental model much clearer. Also, relying on regex for HTML parsing in the edge worker is fast, but for highly complex, malformed HTML, a lightweight HTML parser might be necessary in the future.

If you're building a SaaS and want to see how edge-based SEO analysis works in practice, I've packaged the core logic of my analyzer into a free tool. You can test it out and see how fast edge computing can be for your own projects.

Check out the free SEO Checker tool here: https://saaslaunch.dev/free-tools/seo-checker

Full disclosure: I'm the developer of SaaSLaunch. I built this because I needed it myself.