TIL: Adobe EDS architecture suffers when network latency is high

Would you expect a site powered by EDS (like www.aem.live) to have an LCP above 14 seconds? That’s the reality in Ulanqab, a city of 1,7 million in China - if the site doesn't time out entirely.

Today's lesson learned is: Edge Delivery Service (EDS) architecture, which relies on a large number of small HTTP calls, suffers when network latency is high.

I used a remote desktop in Mainland China (skill borrowed from Tad) to evaluate how the Great Firewall impacts website performance for content hosted entirely on a CDN (Cloudflare in this case). Here's a video of
one of the runs:

The results were interesting/disappointing (depending if you are a tech nerd or not):

• The website failed to load in 2 out of 5 runs.

• Latency for static JS/CSS files ranged from 300 ms to 1 second.

• Lazy-loaded images took up to 10 seconds to load.

And I tested only static content - no search, no dynamic data, no gated experiences involved.

For comparison, I tested www.streamx.dev and www.ds.pl, both hosted in Europe without a CDN.

With browser cache disabled, LCP was 2.23 seconds and 1.89 seconds, respectively. Without streaming the data to China edge locations.

There’s no one-size-fits-all architecture. EDS works well for static sites with infrequent updates, especially when a CDN can reliably cache and serve content close to the user. But when latency is unpredictable - or in regions with strict internet controls - performance can degrade severely.

Have you experienced similar issues? Join the discussion on LinkedIn.