Every great user experience begins before the page loads.
The moment a user taps a link—whether from a Google ad, an email campaign, or a stale bookmark—a flurry of decisions and optimizations happen invisibly across the edge and deep inside distributed systems. Most of the time, the user simply sees a fast page. But under the hood, something more elegant is happening: a tiny choreography between Akamai and Harper that ensures they land in the right place, as quickly as possible.
This is the story of how redirects and Early Hints—two deceptively simple concepts—can shape a user’s first impression, and how Harper’s Platform turns this pattern into a high-performance dance.
The Race to First Paint
Let’s start with a real-world scenario. A user taps www.customer.com, maybe expecting a storefront or a dashboard. It’s a routine interaction, but behind that tap, a chain of network events begins. The request flows to the nearest Akamai edge node, where a decision needs to be made: do we serve them this site, or redirect them to a more suitable location?
This is where the redirect logic kicks in. Akamai’s EdgeWorker quickly consults Harper’s distributed redirect service. Because redirect rules are already replicated across global Harper nodes, the answer is near-instant, usually finalized in one millisecond or less. For perspective, this could be 10 times slower, and it would still be imperceptible to a human. The system either returns a 301/302 or proceeds to the origin without missing a beat.
Then, after the redirect decision is finalized, another optimization kicks in: Early Hints.
Before the origin server begins assembling the full response, Harper has already looked up metadata about the requested page from the same node as the redirects. This node holds information about critical resources—scripts, fonts, stylesheets, largest contentful image—and generates a 103 Early Hint telling the browser, “You’re going to need these; start loading them now.”
This happens before the page has even been built. And because the browser now knows what to fetch from the CDN while the origin server is still working, rendering can begin sooner. That’s the beauty of the model: routing and rendering paths are optimized in parallel, with each decision delegated to the part of the stack closest to the user.
💡 Want a deeper dive on how Early Hints work with preload and preconnect? Check out this guide on Harper’s Dev Center.
The Split‑Second Decision Tree
As the visual shows, the first stop is Akamai Property configuration—where all requests are evaluated against criteria you define. If a match is found, the request is handed to an EdgeWorker, a lightweight compute layer at the edge.
This EdgeWorker is where the real optimization starts. It doesn’t just forward the request blindly—it runs logic (onClientRequest) that issues a sub‑request to a Harper endpoint, asking: “Does this URL have a redirect rule?”
The sub‑request travels through Akamai’s GTM (Global Traffic Management) service to reach the most optimal Harper region—Los Angeles, Dallas, Washington, or Chicago in this example. The selected Harper node checks for a redirect match and responds quickly:
- HTTP 200 if a matching redirect is found
- HTTP 404 if no match exists
If the result is 200, the EdgeWorker fires off its final response (onClientResponse), returning either a 301/302 redirect, or—if applicable—a 103 Early Hint header that primes the browser to begin rendering early.
💡 Curious about how EdgeWorkers handle these sub‑requests?
Early Hints: The Performance Hack You Didn’t Know You Needed
Once the redirect decision is complete, the next phase kicks in: delivering the page from the origin. But before that full response is even ready, Harper enables a subtle but powerful performance boost.
At this point, Harper generates a 103 Early Hint, a response that includes preload instructions for the browser. These hints specify which assets (like images, fonts, or scripts) are likely to be needed so the browser can begin fetching them right away.
The impact is significant: rather than waiting for the origin server to fully render the page before knowing what to load, the browser is already pulling assets from the CDN in parallel. In real-world scenarios, this can accelerate time to first paint or largest content paint by over a second, depending on the speed of the system before early hints were applied.
By decoupling resource loading from full page rendering, Harper helps Akamai shift more of the loading experience earlier in the lifecycle—turning wait time into active work.
Distributed Intelligence: Harper’s Global Layer
So why is Harper even in the picture? Because managing redirects is more than just logic. It’s data—data that needs to be:
- Instantly available across geographies
- Versioned for rollback or expiration
- Replicated without inconsistency
Plus, most redirect systems often have hard limits on the number of redirects they can manage. Many limit teams to 300,000 redirects or fewer. Harper does not have that limit, enabling single-digit millisecond redirect resolution even with upwards of a billion redirects under management.
Harper’s redirect engine is built for this. When you push a new redirect rule, via API or UI, it’s automatically propagated to every node in the cluster. Whether your user is in Berlin or San Francisco, the EdgeWorker gets a consistent, fast answer.
The Invisible Win
Here’s what the user experiences: they click a link, and the page just loads. No delay, no flash of white, no waiting on assets. The redirect, if needed, was invisible. And thanks to Early Hints, the browser started painting before it even knew where it was going.
Under the hood, Akamai made a smart sub‑request to Harper, got a fast answer, and returned the right redirect and the right hint at the right time. No origin load, no unnecessary overhead.
This pattern, redirects + Early Hints, backed by distributed logic, isn’t just for edge nerds. It’s how we make global apps feel local, and how Harper ensures the first impression is always the right one.
.jpg)
%20(1).png){kind=icon}
.png){kind=icon}
.png){kind=icon}