How the checkout packet dodges Jurong

How the checkout packet dodges Jurong

The gap between a customer clicking “Pay Now” and seeing the confirmation screen is rarely a straight line. For a Singapore-hosted e-commerce store, that path can detour through a Taipei data center, a Hong Kong edge node, and back to a server in Jurong before the browser finally renders the success page. Every detour costs milliseconds, and in e-commerce, a single extra hundred milliseconds can turn a 4% conversion rate into a 3.6% one.

The cloud hosting community in Singapore has spent years talking about server response times, PHP workers, and database indexing. Less attention has gone to the question of where the checkout data actually travels after it leaves the cloud instance. That geography matters more than most store operators realize.

A store hosted on a standard Singapore cloud instance with no CDN will route traffic the way the underlying cloud provider decides. For a customer in Jakarta, that might mean packets passing through a transit hub in Singapore, then to a secondary hub in Batam, then to an edge node in Jakarta proper. The actual checkout request — the one carrying credit card details and shipping information — makes that same round trip. A CDN with edge nodes in Singapore, Jakarta, and Kuala Lumpur changes the geometry of that trip fundamentally.

The specific gain of 300ms isn’t a marketing figure. It’s what a mid-sized electronics retailer in Singapore measured after shifting their checkout flow behind a properly configured CDN with regional edge presence. The store’s own testing showed checkout page loads dropping from 1.8 seconds to 1.5 seconds on average. The improvement came almost entirely from reducing the physical distance the checkout page’s static and dynamic assets had to travel before the customer’s browser could begin rendering the payment form.

For the retailer, that 300ms translated into roughly 12 fewer abandoned carts per hundred checkout attempts. The math on that was straightforward: average order value of SGD 85, multiplied by 12 extra completions per hundred, meant an additional SGD 1,020 of revenue for every hundred customers who reached checkout. Not every store will see those exact numbers, but the relationship between latency and abandonment is one of the most consistently documented patterns in e-commerce operations.

Why a Singapore-based CDN beats a generic global one

Global CDNs — Cloudflare, Akamai, Fastly — have points of presence in Singapore, but their edge infrastructure isn’t designed around Southeast Asian traffic patterns. A global CDN’s Singapore node might serve traffic for customers in Japan, Australia, and India simultaneously, which means cache configuration and routing logic are optimized for geographic breadth, not regional depth.

A Singapore-based CDN, by contrast, builds its edge network around the specific latency corridors that matter in this part of the world. The nodes are positioned to minimize hops between Singapore, Malaysia, Indonesia, Thailand, and the Philippines. The routing tables are tuned for Singtel, StarHub, and M1 last-mile connections, not for generic peering agreements that prioritize global consistency over local speed.

The practical difference shows up during peak hours. A global CDN’s Singapore edge node handling traffic from multiple regions will see cache contention — popular assets from Japanese and Australian sites competing for the same memory space as assets from a Singapore e-commerce store. A CDN that only serves this region keeps its cache dedicated to local traffic patterns, which means the checkout page’s CSS, JavaScript, and payment gateway assets stay warm in the edge cache longer.

One operator of a watch e-commerce store in Singapore tested both approaches. Running through a global CDN, their checkout page had a 70% cache hit rate at the edge. After switching to a regional CDN with nodes in Singapore, Kuala Lumpur, and Jakarta, the hit rate climbed to 92%. The difference came from cache eviction policies tuned for regional traffic rather than global averages.

The regional CDN also handled TLS termination differently. Global CDNs often terminate TLS at the nearest edge node and re-encrypt for the origin server, adding a full round trip of latency for the handshake. Singapore-based CDNs that terminate TLS at the origin — keeping the encrypted session intact from customer browser to cloud instance — shave off that extra handshake entirely. For a checkout flow that already involves multiple API calls to a payment gateway, eliminating one TLS negotiation per checkout can save 80 to 120 milliseconds on its own.

What a 300ms improvement actually requires

Shaving 300ms from a checkout flow isn’t a single configuration change. It’s a stack of small optimizations that compound when the CDN is chosen and configured correctly.

The first layer is static asset delivery. The checkout page’s CSS, JavaScript, and images — the product thumbnail, the shipping option icons, the credit card logo images — should all be served from the CDN’s edge cache, not from the origin server. A properly configured CDN will serve these assets from the nearest edge node to the customer, with cache headers set to expire aggressively enough that the browser doesn’t revalidate on every page load.

The second layer is API response caching. Most e-commerce checkout flows call a backend API to check inventory, calculate shipping, and validate the coupon code. These API responses can be cached at the edge for short durations — three to five seconds — which is long enough to serve the initial checkout page load without hitting the origin server, but short enough that the inventory data stays fresh. The CDN needs to support cache key customization to make this work, since the default cache key will include URL parameters that change with every request.

The third layer is origin offloading. The CDN should handle as many requests as possible before they reach the cloud instance. A checkout flow that generates 12 HTTP requests per page load — two CSS files, three JavaScript files, four images, and three API calls — will send 12 requests to the origin server without a CDN in front. With a CDN handling cacheable requests at the edge, that drops to three origin requests per checkout load: the uncacheable API calls for inventory and payment tokenization, and the checkout form submission itself. The cloud instance spends less time serving static assets and more time processing actual transactions.

The fourth layer, and the one most coverage misses, is DNS resolution. A CDN’s DNS servers need to be in Singapore or close to it. Every DNS lookup for the CDN’s edge domain — the one serving the checkout page’s assets — takes time. If the CDN’s authoritative DNS servers are in the United States or Europe, a customer in Jakarta waits for a DNS response to travel across the Pacific and back before the first asset can even load. Singapore-based CDNs typically run their own DNS infrastructure in the region, keeping DNS resolution under 20 milliseconds for most Southeast Asian customers.

Choosing between the available Singapore-based CDNs

Several CDN providers operate edge nodes in Singapore and target the regional market. The major options break down by architecture, pricing model, and cache configuration flexibility.

Singapore CDN 1 (regional specialist, nodes in SG, KL, Jakarta, Bangkok). This provider runs its own edge servers in four Southeast Asian cities and prices by bandwidth usage with no monthly minimum. The cache configuration allows custom TTLs per URL pattern, which is useful for the short-lived API caching described earlier. The control panel supports real-time cache purging, something that matters when a store operator needs to invalidate a cached payment response that returned incorrect data.

Singapore CDN 2 (cloud provider integrated, nodes in SG and KL). Built into a Singapore cloud hosting provider’s ecosystem, this CDN integrates directly with the provider’s cloud instances. The advantage is zero additional configuration for origin pull — the CDN automatically detects the origin server’s IP and region. The tradeoff is fewer edge nodes and less flexible cache key customization. For a store already hosted on this provider, the integration convenience may outweigh the performance gap.

Singapore CDN 3 (pure-play edge, nodes in SG, KL, Jakarta, Manila, Bangkok, Hanoi). The most extensive Southeast Asian edge network of any CDN based in the region. Pricing is slightly higher per gigabyte than the others, but the additional edge nodes in Manila, Hanoi, and Bangkok make a measurable difference for stores with customers in those markets. The cache configuration supports regular expression-based URL matching, which gives fine-grained control over what gets cached and for how long.

Singapore CDN 4 (budget-oriented, nodes in SG and KL). A lower-cost option that fits stores with smaller traffic volumes. The edge nodes are rented rather than owned, which means cache performance can vary depending on what other tenants are sharing the same edge server. For a store processing fewer than 500 checkout attempts per day, the cost savings may be worth the occasional cache contention.

The right choice depends on the store’s customer geography, traffic volume, and the complexity of the checkout flow. A store serving mostly Singapore customers doesn’t need nodes in Manila and Bangkok. A store with customers across six Southeast Asian countries will benefit from the broader edge network even at the higher per-gigabyte cost.

Configuring the CDN for checkout specifically

Most CDN documentation focuses on general website acceleration. Checkout flows have specific requirements that generic guidance doesn’t cover.

The first configuration decision is which parts of the checkout flow get cached at the edge. The checkout page itself — the form with the customer’s name, address, and payment details — should be served from the edge cache on initial load. Once the customer starts typing, the page becomes dynamic and uncacheable. Setting a short cache TTL of 30 seconds for the checkout page URL ensures the form loads fast on first visit but doesn’t serve stale content if the customer refreshes after starting to fill in details.

The payment gateway’s response page is trickier. Some payment gateways redirect the customer back to the store’s confirmation page after processing the payment. That confirmation page URL is unique per transaction, so caching it at the edge won’t help. What can be cached is the payment gateway’s redirect endpoint itself — the URL the gateway calls to tell the store the payment succeeded or failed. Caching that response for one second at the edge prevents duplicate calls without introducing enough delay to confuse the gateway’s timeout logic.

The shopping cart API endpoint — the one that returns the current cart contents, subtotal, taxes, and shipping options — should have a five-second cache at the edge. The cart contents don’t change between page navigations within the checkout flow. Caching the response means the checkout page can load the cart data from the edge node instead of waiting for the origin server to query the database, then compute taxes, then return the result.

One detail that trips up many store operators: the CDN must preserve the original visitor’s IP address in the checkout request headers. Payment gateways and fraud detection services use the visitor’s IP as part of their risk assessment. If the CDN replaces the visitor’s IP with its own edge node’s IP, the payment gateway may flag the transaction as suspicious. Every Singapore-based CDN mentioned here supports the standard X-Forwarded-For header, but it needs to be enabled explicitly in the CDN’s configuration, not assumed to be on by default.

Testing whether the 300ms gain is real for your store

The 300ms figure from the electronics retailer came from a controlled A/B test. They ran their original checkout flow — cloud instance with no CDN — against a test flow behind the Singapore-based CDN, measuring page load time from the customer’s browser using real user monitoring data. The test ran for one week, capturing 4,200 checkout attempts across both variants.

The results showed not just the 300ms average improvement but a narrower distribution of load times. The original flow had checkout pages loading anywhere from 1.2 seconds to 3.1 seconds depending on the customer’s internet connection and geographic distance from the cloud instance. The CDN-accelerated flow compressed that range to 1.0 to 1.9 seconds. The worst-case checkout loads — the slowest 5% of attempts — improved by 400ms, not 300ms. The slowest customers saw the biggest gains.

Testing this in a store’s own environment requires two things: a way to serve half the traffic through the CDN and half through the origin, and real user monitoring to capture actual load times from customers’ browsers. The CDN’s routing rules can be set to serve traffic to a percentage of visitors based on a cookie or a random sampling value. The monitoring tool needs to capture the Navigation Timing API data from the browser, specifically the responseEnd and domContentLoadedEventEnd metrics, to calculate the checkout page’s actual load time.

Running the test for at least three business days captures the weekly traffic cycle — Monday’s browsing traffic, Wednesday’s payday spending, Saturday’s relaxed shopping. A shorter test risks catching an anomaly. A longer test delays the decision.

What happens when the CDN introduces problems

A CDN isn’t a guaranteed improvement. Poorly configured, it can make checkout slower and introduce errors that the store operator doesn’t immediately notice.

The most common problem is cache poisoning. If the CDN caches a checkout response that contains another customer’s data — a cached order summary showing the wrong name and shipping address — the next customer to hit that edge node sees incorrect information. The CDN’s cache key must include a session identifier or authentication token to prevent cross-customer cache hits. Without that, the entire checkout flow should be excluded from edge caching and served only from the origin.

A second problem is CDN node failures. A CDN edge node that goes offline forces traffic to route to the next nearest node, which can add latency rather than reduce it. The CDN provider’s SLA matters here — how quickly can they detect and route around a failed node. The electronics retailer’s CDN provider had a 99.9% uptime SLA for each individual edge node, which meant an average of 43 minutes of downtime per node per month. That was acceptable for their traffic volume, but a store that processes thousands of checkouts per hour would need a provider with faster failover.

A third problem, specific to the checkout flow, is the CDN terminating the customer’s session prematurely. Some CDNs have aggressive connection timeout settings that work well for static content but break a checkout flow where the customer pauses to find their credit card or type a long address. The CDN’s connection timeout should be set to at least 60 seconds for the checkout page URL pattern. Setting it lower saves the CDN’s resources but risks timing out customers who need a moment to complete the form.

The electronics retailer discovered this the hard way. Their CDN had a default connection timeout of 30 seconds for all traffic. Customers who took longer than 30 seconds to fill in their credit card details — which was more common than the retailer expected — saw a blank page when they clicked Submit. The support tickets rolled in within hours. The fix was a simple timeout override for the checkout URL pattern, but the incident cost the store roughly SGD 3,000 in lost sales over the three hours before the timeout was identified and changed.

The non-technical edge: choosing a support team that understands e-commerce

A CDN provider’s support team that treats all traffic as equally important will not help when a checkout-specific issue arises. The store operator who needs to know whether the CDN is caching the payment gateway’s redirect response or whether a particular edge node is dropping connections to the payment gateway’s API will get faster answers from a support team that understands e-commerce infrastructure.

Singapore-based CDN providers tend to have support teams with more exposure to e-commerce workloads than the global CDN providers’ regional support desks. The support engineers have seen the same problems before — payment gateway timeouts, cart synchronization failures, checkout page assembly issues — and can diagnose them without escalations to a product team in another time zone. The difference shows up in response time during peak shopping hours. A store operator who encounters a checkout issue at 10 PM on a Saturday will get a response within minutes from a dedicated regional CDN’s night shift, not an email the following Monday.

That responsiveness is worth evaluating during the selection process. A store operator can test a CDN provider’s support by sending a technical question during evening hours before committing to a contract. The speed and quality of the response is a reliable indicator of what the store will get during an actual incident.

The 300ms gain won’t come from the CDN alone. A store operator who treats CDN selection as a cloud infrastructure decision will get cloud infrastructure results. The one who treats it as an e-commerce conversion decision — and vets the support team accordingly — will get the 300ms. The Saturday-night timeout that costs real money is the test that separates the two approaches.

📷 Photos: Bing Hui Yau (Unsplash), Hanna Lazar (Unsplash)