For most of the web's history, an application lived in one place — a data center in a region — and every user, however far away, paid the cost of that distance in milliseconds. As applications became more interactive and users more global, those milliseconds stopped being a detail and started being the difference between a product that feels instant and one that feels sluggish.
The content delivery network was the first answer: cache static assets in hundreds of locations worldwide, so images, scripts, and styles are served from a point near the user rather than from a distant origin. That alone transformed page-load times, but it only helped the parts of an application that did not change.
Edge computing extends the idea to the logic itself. Instead of only caching content near users, code runs near them — request routing, authentication, personalization, and increasingly whole application backends executing in the same distributed network that serves the assets. The origin server, when it exists at all, handles only what genuinely must be centralized.
The performance gains are the obvious benefit, but resilience is the quieter one. An application distributed across a global network has no single point of failure to take down; traffic simply routes around a location that goes dark. Scale, likewise, becomes a property of the network rather than a capacity a team has to provision and pray over during a traffic spike.
The architectural shift this demands is real. State has to be handled deliberately when code runs in many places at once, and data has to be positioned thoughtfully so the logic near the user can reach it quickly. But for applications where speed and reliability are features rather than nice-to-haves, the edge has stopped being an optimization and become the default place to build.