Server
Edge function
Edge function is code that runs on a provider's network close to the visitor instead of at your origin. It can answer, rewrite or redirect a request before it ever reaches your server.
How it is measured
Observe it through response headers and logs. Providers add a location header such as the Cloudflare colo code, and timing for the function itself is logged in microseconds to milliseconds. Compare request time with the function enabled and bypassed from a few regions.
Limits matter: CPU time per request (often 10 to 50 ms), memory around 128 MB, no long-lived filesystem. Count the subrequests it makes, since one call back to a distant origin can erase the saving.
Worked example
An Astro blog on a single origin in Frankfurt redirects visitors by country and adds a security header. A reader in Singapore previously waited 410 ms for the origin to issue a 302. An edge function does the redirect in 18 ms from a Singapore edge node.
The same function also fetched a user profile from the Frankfurt database on each hit. That call added 330 ms again, so the team moved the lookup into a cached key-value store at the edge.
How it differs
An edge function is short code that runs near visitors. A worker is the specific product shape of that idea, such as a Cloudflare Worker. Edge function excludes your origin app logic and long jobs. Worker names a platform, while edge function names where the code runs, and the edge location is the shared point.
Common errors
Calling a far-away database from the edge and losing the speed gain. Putting heavy CPU work under a 10 ms limit. Using Node-only libraries the runtime does not support. Forgetting the function runs on every request including bots. Not versioning the code, so a bad deploy hits every country at once.
In practice
Start with one thing that benefits from being near the visitor: redirects, header changes, A/B bucket choice, or bot filtering. Measure TTFB before and after from two distant regions and keep the function free of origin round trips.