3 ms·

This is really good. Having worked at news sites and for a CDN its kindof fascinating how most web developers understanding of http basically ends at "GET or PO

by cagenut 10y ago

This is really good. Having worked at news sites and for a CDN its kindof fascinating how most web developers understanding of http basically ends at "GET or POST". IMHO this stuff is increasingly becoming table-stakes for a successful online business. If you're not caching and/or serving your app in some kind of geographically distributed way, you're handing hundreds of milliseconds of performance delta to your competition. If you're nj.com then sure you can get away with serving everything from secaucus, but if you're any random sass app that even just wants to target the greater english speaking anglosphere of both brits and aussies you need to solve for this. Hell even the performance delta between the east and west coasts of the US can have a meaningful impact on ecommerce shopping carts.

tyingq 10y ago
I agree with everything you're saying, apart from this: >performance delta between the east and west coasts of the US can have a meaningful impact on ecommerce shopping carts Assuming a mid-sized, US sales only, ecom site, I would think serving it up somewhere in the geographic center (Dallas?) would suffice fine. Things like lazy loading images on category pages tend to make a bigger performance impact than a CDN in this restricted use case. Chart that illustrates latency with US city pairs: https://i.stack.imgur.com/0pP3S.png https://i.stack.imgur.com/0pP3S.png
- cagenut 10y ago
  You are correct that zoomed all the way into single packet RTT you could split the difference with servers in texas. And if your shopping cart experience was somehow single http request-response steps with everything else async/lazy-loaded in a way that had no impact on the experience. But in real world scenarios, open up the the chrome devtools network tab and click your way through a checkout process on any given ecom site. You'll probably make well north of 1000 requests overall, and even if a ton of it is fluff there's a solid 5 - 10 requests that are the blocking core of any page. And thats just a single-user best case scenario example. When you zoom out a bit to the aggregate user base, a 5-hop/<100km-away network connection is going to have much less packetloss, jitter and latency than a 15-hop/>2000km one, such that the 95th percentile experience will be much better for the former.
  - tyingq 10y ago
    All you can edge cache, though, is static content. Once the end user makes a product comparison, puts something in the cart, etc, it's no longer cacheable. That page-blocking stuff in the checkout path isn't usually able to be served by the CDN. And, for content like javascript and css, that will be cached in the browser after the first request. Shopping cart software tends to use the same js/css on every page, with a few exceptions. The CDN, then, tends to serve up mostly product images. Lazy loading on category pages fixes the most pathologic problem there, if you don't have a CDN. Just my real world experience that solely for this restricted use case, a CDN doesn't add much. Other optimizations matter more. Edit: Not saying a CDN wouldn't be useful at all. But, if you're starting with typical cart software, like Magento, there are probably 100 other things that you should optimize before you worry about a CDN. We're able to get our ecom pages down to an average of 14 requests/page, many of those 14 being cachable at the browser and shared across pages. If you have customers more broadly spread, a CDN would move up the list quickly.
    - rgbrenner 10y ago
      All you can edge cache, though, is static content. That's generally true. This was one of the problems I worked on at NuevoCloud.. for dynamic pages, it would look at the page, and determine which sections of the page are static or dynamic/unique. A PoP near the server would do the analysis, and then send the unique sections to the edge PoP (near the visitor) for it to be reassembled. So the static portions of a page would be cached, and you would only be sending the unique parts of a page over long distances... and that would also be compressed, encrypted, and sent over an optimized connection (ie: no handshake delay, etc). Of course, the difference is more significant the further away you are from the origin. I don't know of any other CDNs doing that.. but I imagine they'll eventually get to it. So I would look for that in the future, even if you don't use our CDN.
      - Tushon 10y ago
        That sounds like Raygun from Cloudflare and ESI (potentially) from Fastly. https://www.cloudflare.com/docs/railgun/intro.html https://www.cloudflare.com/docs/railgun/intro.html https://www.fastly.com/blog/using-esi-part-1-simple-edge-side-include https://www.fastly.com/blog/using-esi-part-1-simple-edge-sid...

by cagenut 10y ago

tyingq 10y ago

I agree with everything you're saying, apart from this: >performance delta between the east and west coasts of the US can have a meaningful impact on ecommerce shopping carts Assuming a mid-sized, US sales only, ecom site, I would think serving it up somewhere in the geographic center (Dallas?) would suffice fine. Things like lazy loading images on category pages tend to make a bigger performance impact than a CDN in this restricted use case. Chart that illustrates latency with US city pairs: https://i.stack.imgur.com/0pP3S.png https://i.stack.imgur.com/0pP3S.png

cagenut 10y ago
You are correct that zoomed all the way into single packet RTT you could split the difference with servers in texas. And if your shopping cart experience was somehow single http request-response steps with everything else async/lazy-loaded in a way that had no impact on the experience. But in real world scenarios, open up the the chrome devtools network tab and click your way through a checkout process on any given ecom site. You'll probably make well north of 1000 requests overall, and even if a ton of it is fluff there's a solid 5 - 10 requests that are the blocking core of any page. And thats just a single-user best case scenario example. When you zoom out a bit to the aggregate user base, a 5-hop/<100km-away network connection is going to have much less packetloss, jitter and latency than a 15-hop/>2000km one, such that the 95th percentile experience will be much better for the former.
- tyingq 10y ago
  All you can edge cache, though, is static content. Once the end user makes a product comparison, puts something in the cart, etc, it's no longer cacheable. That page-blocking stuff in the checkout path isn't usually able to be served by the CDN. And, for content like javascript and css, that will be cached in the browser after the first request. Shopping cart software tends to use the same js/css on every page, with a few exceptions. The CDN, then, tends to serve up mostly product images. Lazy loading on category pages fixes the most pathologic problem there, if you don't have a CDN. Just my real world experience that solely for this restricted use case, a CDN doesn't add much. Other optimizations matter more. Edit: Not saying a CDN wouldn't be useful at all. But, if you're starting with typical cart software, like Magento, there are probably 100 other things that you should optimize before you worry about a CDN. We're able to get our ecom pages down to an average of 14 requests/page, many of those 14 being cachable at the browser and shared across pages. If you have customers more broadly spread, a CDN would move up the list quickly.
  - rgbrenner 10y ago
    All you can edge cache, though, is static content. That's generally true. This was one of the problems I worked on at NuevoCloud.. for dynamic pages, it would look at the page, and determine which sections of the page are static or dynamic/unique. A PoP near the server would do the analysis, and then send the unique sections to the edge PoP (near the visitor) for it to be reassembled. So the static portions of a page would be cached, and you would only be sending the unique parts of a page over long distances... and that would also be compressed, encrypted, and sent over an optimized connection (ie: no handshake delay, etc). Of course, the difference is more significant the further away you are from the origin. I don't know of any other CDNs doing that.. but I imagine they'll eventually get to it. So I would look for that in the future, even if you don't use our CDN.
    - Tushon 10y ago
      That sounds like Raygun from Cloudflare and ESI (potentially) from Fastly. https://www.cloudflare.com/docs/railgun/intro.html https://www.cloudflare.com/docs/railgun/intro.html https://www.fastly.com/blog/using-esi-part-1-simple-edge-side-include https://www.fastly.com/blog/using-esi-part-1-simple-edge-sid...