Extend First-Party Cookie Lifetime With Cloudflare Edge Workers

Why Cookie Lifetime Matters

First-party cookies set by your domain track user behavior across sessions. By default, most cookies expire after 30 days, 90 days, or whenever you explicitly set the expiration. Once a cookie expires, you lose the session identifier and must treat returning users as new visitors. This breaks attribution chains and forces re-identification on every return trip.

Extending cookie lifetime keeps users recognized longer, which improves conversion tracking accuracy and reduces the cost of re-acquiring user context. The challenge is doing this without modifying your application code or database logic.

How Cloudflare Edge Workers Refresh Cookies

Cloudflare Edge Workers run JavaScript at Cloudflare's edge servers, intercepting every request before it reaches your origin. You can inspect cookies in the request, update their expiration date, and send the refreshed cookie back in the response. This happens transparently, outside your application layer.

The flow is simple: user sends request with an existing cookie, Edge Worker reads the cookie, extends its expiration by a set interval (7 days, 30 days), and returns the modified cookie in the response. On the next request, the user's browser sends the refreshed cookie, and the Worker extends it again. This creates a rolling window where active users never see their cookies expire.

Set Up an Edge Worker for Cookie Refresh

First, create a new Worker in your Cloudflare dashboard. Go to Workers & Pages, click Create Application, and select Create a Worker. Name it something descriptive like cookie-lifetime-extension.

Paste this Worker code into the editor:

export default {
  async fetch(request) {
    const response = await fetch(request);
    const newResponse = new Response(response.body, response);
    
    // Define which cookies to refresh and their new lifetime (in days)
    const cookiesToRefresh = {
      '_ga': 365,
      '_gid': 1,
      'session_id': 90,
      'user_token': 180
    };
    
    // Get existing Set-Cookie headers
    const setCookieHeader = newResponse.headers.get('set-cookie');
    const allHeaders = newResponse.headers.getSetCookie ? 
      newResponse.headers.getSetCookie() : 
      (setCookieHeader ? [setCookieHeader] : []);
    
    // Refresh cookies on incoming request
    const cookieHeader = request.headers.get('cookie') || '';
    const cookies = cookieHeader.split(';').map(c => c.trim());
    
    cookies.forEach(cookie => {
      const [name, value] = cookie.split('=');
      if (cookiesToRefresh[name]) {
        const expiryDate = new Date();
        expiryDate.setDate(expiryDate.getDate() + cookiesToRefresh[name]);
        const refreshedCookie = `${name}=${value}; Path=/; Max-Age=${cookiesToRefresh[name] * 86400}; SameSite=Lax`;
        newResponse.headers.append('Set-Cookie', refreshedCookie);
      }
    });
    
    return newResponse;
  }
};

Update the cookiesToRefresh object with your actual cookie names and desired lifetimes (in days). Common cookies to extend: _ga (Google Analytics), _gid (GA session), session_id (your app), user_token (authentication).

Deploy and Route the Worker

Save the Worker code. Next, attach it to your domain by creating a route. In the Workers dashboard, click Routes and add a new route. Enter your domain pattern (example: example.com/*) and select your Worker. This tells Cloudflare to run the Worker on every request to that domain.

Test the setup by visiting your site in a browser. Open DevTools (F12), go to Application > Cookies, and check a tracked cookie's expiration time. Reload the page. If the Worker is running, the expiration date should shift forward by the interval you set.

Handle Multiple Cookies and SameSite Attributes

The basic Worker above extends cookies one at a time. If you have many cookies to track, loop through the incoming cookie header and match each one against your cookiesToRefresh list. For each match, calculate the new expiration and append a Set-Cookie header.

Pay attention to the SameSite attribute. Set it to Lax for cookies that need to work across navigation (most tracking cookies). Use Strict only if the cookie should never be sent in cross-site requests. Omit SameSite entirely if you're serving only over HTTPS and want the broadest compatibility (though this is less secure).

Also preserve the Secure flag if your site runs on HTTPS. This ensures cookies are only sent over encrypted connections.

Avoid Cookie Conflicts

If your origin server also sets cookies, the Worker and your app might both try to refresh the same cookie. This causes duplicate Set-Cookie headers and unpredictable behavior. To prevent this, either:

• Exclude cookies your origin already handles from the Worker's cookiesToRefresh list.
• Modify your origin to skip setting cookies that the Worker will refresh.
• Use a naming convention (prefix) so the Worker only touches cookies it owns.

Test both scenarios: request with the cookie already present, and request without it. The Worker should extend existing cookies and leave new cookies from your origin untouched.

Monitor and Troubleshoot

Cloudflare Workers include built-in logging. In the Worker editor, use console.log() to debug. Deploy a test version with logging, make requests, and check the Logs tab in the Workers dashboard.

Common issues:

• Cookie not refreshing: Verify the cookie name matches exactly (case-sensitive). Check that the route pattern covers your domain.
• Session breaks after Worker deployment: The Worker may be stripping the cookie. Ensure the cookie value is preserved in the refresh logic.
• Multiple Set-Cookie headers: If your origin and Worker both set the same cookie, browsers may ignore one. Use the conflict-avoidance approach above.

Use the Network tab in your browser's DevTools to inspect the actual Set-Cookie headers returned. Compare before and after deploying the Worker to confirm the expiration is changing.

Performance Impact

Edge Workers run at Cloudflare's edge, not your origin, so the latency impact is minimal. Parsing and refreshing cookies adds microseconds per request. For sites with millions of daily requests, this can accumulate, but Cloudflare's infrastructure is designed to handle this at scale.

If you notice slowdown, profile the Worker code. Avoid nested loops or expensive string operations. Keep the cookiesToRefresh object small (under 20 cookies). If you need to refresh more than that, consider splitting into multiple Workers or batching refreshes.

Alternatives and Limitations

This approach works best for first-party cookies you control. It does not extend third-party cookies (those set by external domains), since browsers block third-party cookie writes in most modern browsers anyway.

If you need to extend cookies set by a third-party service (like a CDP or email platform), you'll need to coordinate with that vendor. Some vendors offer cookie refresh options in their own dashboards.

Another option is to refresh cookies server-side in your application code. This gives you more control but requires code changes and adds load to your origin. The Edge Worker approach is lighter and requires no application changes.

What to Do Next

Start with one or two cookies (like _ga and your session cookie) to test the Worker in a staging environment. Verify that users stay recognized across sessions and that no duplicate cookies appear. Once you're confident, deploy to production and monitor for a week. If you need help setting up custom tracking infrastructure or want to review your cookie strategy before deploying, consider an audit of your current tracking setup.

FAQs

People Also Ask