Edge Computing for Web: What Belongs There and What Does Not

Edge computing moves code closer to users, which helps for work that is fast and data-light and hurts for work that is not. This guide covers what belongs there, drawing on FISTA Solutions' web and mobile work.

What belongs at the edge?

Work that is fast, data-light, and benefits from proximity.

Workload	Edge or origin?
Routing and redirects	Edge
Authentication token checks	Edge
Geographic personalisation	Edge
A/B test assignment	Edge
Header and cookie manipulation	Edge
Database-backed rendering	Origin, usually
Long-running computation	Origin
Anything needing regional data	Depends on replication

Why does data locality decide it?

Because the latency saved by running close to the user is lost on the round trip to data in one region.

An edge function in Sydney reaching a database in Virginia is slower than an origin function in Virginia doing the same work. The edge placement helped with the first hop and cost more on the second.

Edge compute pays off with edge-local data, regional replication, or workloads that need no data at all. Establish which applies before moving anything.

What are the runtime constraints?

Execution time limits measured in milliseconds to seconds, restricted APIs compared with a full server runtime, memory limits, and package compatibility.

Libraries assuming a standard server environment — file system access, native modules, long-running processes — frequently do not run. That constraint shapes what can be moved and is discovered late if not checked first.

Check your dependencies against the target runtime before planning a migration. A single incompatible library in a critical path can block the whole approach.

What about cold starts?

Edge runtimes generally start faster than traditional serverless, which is one of their advantages, and the behaviour still differs from a warm origin server.

For latency-sensitive paths, measure rather than assuming. A function that starts in a few milliseconds is fine; one that pulls a large bundle on first invocation in each location is not.

Bundle size matters more at the edge than at the origin for this reason.

How does personalisation work at the edge?

Well, for anything derivable from the request: geography, device, language, cookies, and experiment assignment.

That allows cached pages to be personalised at the edge without breaking cacheability, which is a genuine architectural benefit. A single cached page with edge-applied variations serves faster than per-user rendering at origin.

Personalisation requiring user data from a database is a different case and belongs where the data is.

What does observability need?

Location as a dimension in every metric and log.

A problem affecting one region is invisible in aggregate metrics, and edge deployments distribute the failure surface across many locations. Latency, error rates, and cold start frequency all need breaking down by location.

Log aggregation matters more too, because the logs are produced in many places and investigating requires them in one. See observability for web apps.

How does this interact with caching?

Closely. The strongest edge pattern is a cached response with edge-applied variation, which gives cache performance with per-request behaviour.

That requires the cache key to account for the dimensions being varied, and it requires discipline about what varies. A cache key including too many dimensions produces a cache that never hits. See CDN strategy guide.

What are the common mistakes?

Moving data-dependent work to the edge. Not checking runtime compatibility. Aggregate observability without location. Cache keys with too many dimensions. And assuming edge is faster for everything.

How do you test it?

Test from several geographic locations rather than from one, test cold start behaviour, and test what happens when the origin is unavailable.

The last matters: edge functions that depend on origin availability inherit its failures, and the behaviour should be designed rather than discovered.

What does it cost to operate?

Usually per-invocation and per-millisecond, which favours short fast functions and penalises long ones. Frequently cheaper than origin compute for the workloads that suit it.

Data transfer between edge and origin is a cost dimension that catches teams who moved compute without moving data.

What should you measure?

Latency by geography, cold start frequency and duration, error rates by location, and origin round trips per edge request.

Does AI inference belong at the edge?

Rarely, today. Model inference needs compute and memory that edge runtimes do not provide, and calls to a provider from the edge add a hop rather than removing one.

What does fit is the surrounding work: routing requests to the right model or region, authentication, rate limiting, and caching responses. Those are edge-shaped and they reduce load on everything behind them.

When is this the wrong approach?

When the application is data-heavy and the data lives in one region, when the runtime constraints block necessary libraries, or when the team cannot debug a distributed deployment. The origin is simpler and frequently fast enough.

What should you do first?

Check what proportion of your request latency is network versus compute. If compute dominates and the work needs regional data, edge placement will not help.

How FISTA Solutions helps

FISTA Solutions builds and operates production systems through web and mobile, AI enablement, and staff augmentation: edge placement decided by data locality rather than by default, observability broken down by location so regional problems are visible, decisions documented with their reasoning, and handover that leaves your team able to maintain what was delivered. The record is 150+ projects for 50+ companies across 12+ countries.

To scope this work, message FISTA on WhatsApp, or read CDN strategy guide.