Why I Moved My SaaS API Routes to the Edge with Workers

When I first started building my SaaS, I relied entirely on standard serverless functions for my API routes. It worked perfectly fine during local development and initial testing. But when I finally launched and started getting traffic from Europe and Asia, I noticed a significant drop in performance. Tasks that involved fetching external data or parsing HTML—like the SEO analysis tools I wanted to build—were suffering from high latency. I was struggling with slow response times and unpredictable cold starts that frustrated my early users. So I decided to build something.

The Problem with Standard Serverless for Global SaaS

When you build a SaaS, you want your application to feel snappy no matter where your users are located. Standard serverless platforms are incredible for many use cases, but they often execute in a single primary region or rely on routing that can introduce latency for global users.

If your API routes need to fetch a webpage to analyze its SEO, or if they need to interact with third-party APIs, doing that from a server in a single region means users on other continents are waiting for data to cross the globe twice.

The cost of ignoring this isn't just a few extra milliseconds. For interactive tools, it means a sluggish user experience. For SEO checkers, it means timeouts on slower sites. I needed a way to process these requests closer to the user without completely rewriting my stack.

This led me to evaluate two main approaches: sticking with traditional serverless and adding a CDN cache, versus moving the compute to the edge using Cloudflare Workers.

Technical Approach: Moving Compute to the Edge

I needed a SaaS foundation that could handle the heavy lifting of billing, authentication, and frontend rendering, while offloading specific API tasks to the edge. I ended up structuring my boilerplate, SaaSLaunch, around Next.js 14 for the core app, Stripe for subscription billing, and Cloudflare Workers specifically for edge-side API routes.

The trade-off with edge computing is that you lose access to some heavy Node.js-specific APIs, and you have to be mindful of execution time limits. However, for I/O bound tasks like fetching a webpage and running regex checks on the HTML, the edge is highly effective.

Here is an example of how I implemented the edge SEO analyzer using a Cloudflare Worker. Instead of routing the request back to a central server, the worker intercepts it at the edge:

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

Notice the cf object in the fetch request. This is a Cloudflare-specific extension that allows us to cache the target page's HTML right at the edge for 300 seconds. This means if multiple users check the same URL, the subsequent requests are lightning fast because we aren't re-fetching the external site.

By keeping the Next.js App Router for the UI and standard serverless functions for things like Stripe webhook handling (where execution time can be longer and Node.js libraries are helpful), I got a balanced architecture.

Practical Results and Trade-offs

What worked really well was the latency reduction. For example, an illustrative scenario might see a user in Europe running an SEO check experience response times dropping from around 800ms to under 150ms, simply because the HTML parsing happened at a local edge node rather than routing across the ocean.

I was also pleasantly surprised by the deployment workflow. Setting up one-click deployment to Cloudflare Pages for the edge workers, alongside Vercel for the Next.js frontend, turned out to be much smoother than I anticipated. The TypeScript-first approach ensured that type safety carried over between the main app and the worker scripts.

If I were to do it again, I would change how I handle environment variables across the two platforms. Initially, managing environment variables in Vercel and env bindings in Cloudflare Workers required some mental context switching. I've since updated the boilerplate to abstract this more cleanly, but it's a trade-off to keep in mind when mixing deployment targets.

Another trade-off is debugging. Edge environments don't always support the exact same debugging tools you might be used to in a standard Node.js serverless environment. You have to rely more on structured logging and edge-specific inspectors.

Checking Your Own Site's SEO

Building these edge tools made me realize how much developers struggle with basic SEO checks when launching their projects. To help with that, I extracted the core logic from my edge worker and built a free, standalone SEO Checker.

You can use it right now to analyze your landing pages, check your meta tags, and ensure your H1 structures are correct before you launch. It runs entirely at the edge, so it's fast and doesn't require an account.

You can try the free SEO Checker here: https://saaslaunch.dev/free-tools/seo-checker

---

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