Independent comparison · no paid rankings
Home / Blog / Edge computing: what exactly should be accelerated near the visitor?
Guide

Edge computing: what exactly should be accelerated near the visitor?

Edge is not "run everything on Cloudflare". It is choosing which milliseconds — TLS, cache, auth, personalisation — deserve to be won near the user without moving your SQL database.

3 min read Updated Jul 19, 2026

A visitor in Sydney loads your site hosted in France. The CDN already serves images in Sydney. But every HTML request returns to Europe to verify a session cookie — 400 ms extra. The team talks "edge computing" without knowing whether to put the cart, static blog or Postgres full-text search there.

Edge computing means running a little logic as close to the visitor as possible — not moving your whole stack. The useful question: which milliseconds cost dearly in origin round-trips, and which do not need the database?

Three layers — do not confuse them

LayerRoleExample
CDN cacheServe precomputed bytesCSS, images, JS
Edge computeLight per-request logicAuth, geo redirect, A/B
OriginBusiness truth + DBCheckout, customer account

Accelerate at edge what is idempotent, cacheable or short-lived stateless. Keep at origin what writes to database or needs transactions.

Putting Postgres "at edge" is an anti-pattern. Putting a routing decision at edge is a good one.

Concrete use cases

Geo routing/fr/ vs /de/ from Accept-Language or country without app round-trip.

Edge auth — JWT or signed cookie validation at POP; origin receives verified identity.

Light personalisation — promo banner, feature flag, maintenance page.

Read-only aggregation — merge 2–3 public APIs into one 60-second cacheable response.

Protection — rate limiting, bot score before origin — see WAF and small-site DDoS.

Complement with CDN first steps if you are starting with static cache.

Technical limits

Limited CPU time — milliseconds to seconds, not long jobs. No durable local disk — edge KV or TTL cache only. Complex consistency — cache invalidation is hard, stale content possible. Painful debugging — reproducing a "Brazil POP only" bug needs edge logs. Vendor lock-in — Workers, Lambda@Edge, Fastly Compute@Edge: different APIs.

GDPR and sovereignty

Edge implies processing — sometimes personal data — on vendor infrastructure, sometimes outside the EU. Ask: which POPs for EU visitors? Do session cookies cross US POP? Where are edge logs with IP and user-agent stored?

For sensitive data, limit edge to static or choose vendors documenting EU POPs. See GDPR host choice and Cloud Act.

The climax: accelerating the wrong component does not speed the site

Decide and move forward without blind spots

Analyse the network waterfall via WebPageTest from 2–3 regions. Identify avoidable origin round-trips. Prototype a Worker or edge route on one read path. Measure p95 before/after plus origin load. Document GDPR scope for edge processing. Compare CDN/edge in the directory and compare tool.

Frequently asked questions

Does edge replace origin?

Not for stateful core. Edge caches, filters, decides; DB stays at origin.

CDN vs edge compute?

CDN serves files; edge runs code at POP.

US edge and GDPR?

Map personal data; EU POP or origin-only for sensitive paths.

Are Cloudflare Workers enough?

Often for rewrite/auth/selective cache. Test CPU limits and load.


Edge computing: accelerate what does not need your database — not move your database for proximity's sake.

Compare European hosts

Filter by compliance, location and use case — then open the sheets to verify the real scope.

Browse the directory
Blog

Related reading

All articles →