One additional second of page load time costs commerce conversions. Walmart’s published data shows up to 2% per second. The relationship holds across mid-market commerce: slower stores convert less.
The question isn’t whether page speed affects revenue. It does. The question is what’s causing the delay and which part of the stack controls it.
Why the number is worse on mobile
Mobile traffic represents the majority of commerce sessions for most mid-market merchants. It also has worse latency characteristics than desktop. Network variation is higher. Device processing power is lower. The conversion impact of a given latency increase is larger on a mobile device than on a wired desktop connection.
If performance metrics are being measured in lab conditions or on desktop sessions, they’re likely understating the latency real shoppers encounter. The 90th percentile mobile experience on a carrier network in the merchant’s largest customer geography is the number that matters for conversion.
What infrastructure controls that code cannot
Development teams spend significant effort optimizing at the application layer. Image compression, lazy loading, script deferral and request bundling all deliver real gains. They also have a ceiling.
Most application-layer optimization stops at the application boundary. The network distance between origin server and shopper is a network topology problem. A cache layer that misses on dynamic content is a CDN configuration problem.
These are infrastructure problems. Edge delivery that puts content close to the shopper, and a CDN purpose-built for commerce that understands how to cache pricing and inventory content correctly, address latency at the layer code can’t reach.
Where the remaining gains live
For merchants who have already optimized images, deferred scripts and tuned application code, the application layer’s remaining gains are small. The infrastructure layer is where the next conversion improvements live.
Edge delivery that reduces time to first byte for shoppers far from origin. A CDN configured to cache dynamic commerce content correctly. Origin paths optimized for the mobile carrier networks the storefront actually serves. These are the levers code can’t pull.
For merchants who have optimized the application layer and are still looking for conversion improvement, the infrastructure layer is where the remaining gains sit.
What to measure and how
Synthetic performance tests measure what the infrastructure can do under ideal conditions. Real User Monitoring measures what shoppers experience on their devices, from their networks, in their geographies.
Before accepting a performance benchmark from any vendor, two questions are worth asking: what device and network mix was the test run against, and how does that mix compare to the merchant’s actual traffic distribution?
A performance number from a data center’s local region and a performance number from a mobile device on a carrier network in the merchant’s top customer city aren’t the same number. The conversion data reflects the second one.
Where to look first
Most ecommerce performance issues trace to a small number of causes: high time to first byte from an origin server too far from the shopper, dynamic content that isn’t caching correctly and third-party scripts loading synchronously on product and category pages.
The first two are infrastructure decisions. The third is a configuration discipline. All three are addressable without rewriting the application.
See how Webscale’s edge layer handles commerce performance: webscale.com/application-delivery
