3 ms·

I think a lot of sites end up affected by "CDN accumulation". There can quite genuinely end up being a dozen or more different servers enabling a single website

by ehnto 5y ago

I think a lot of sites end up affected by "CDN accumulation". There can quite genuinely end up being a dozen or more different servers enabling a single website, just from all the third party CSS, JS libraries, analytics and fonts. The trouble I find with relying on many disparate 3rd party CDNs is the unreliable response times, especially if any of your users are outside of the US. From Australia we often find a site serving locally in under 30ms, then sit and wait for 300ms per request for all the third party assets to load. The first thing I do when looking at optimizing the felt performance of a website is move everything back to the application host, and then add a single CDN if the traffic is likely to be high.

TonyTrapp 5y ago
Not just third-party CDNs. One of the worst examples I have seen is the FlixBus website, which loads JavaScript from like a dozen different CloudFront subdomains, each one gradually adding more functionality to the site (e.g. one subdomain seems to be responsible for autocompleting city names). They seem to have taken the notion of microservices to a whole new level. Edit: CloudFront, not CloudFlare.
- ehnto 5y ago
  One of the slowest parts of a Shopify website is their CloudFlare backed CDNs (may have improved, it's been a year since I benchmarked). The app server responds in < 60ms, then the CDNs responds anywhere between 50-300ms, which tanked the user experience. Serving lots of little files even with HTTP2 has all the same problems, lots of little requests make the likelihood of hitting a bottlenecked CDN node more likely. I'm not sure where the idea of serving JS as small loaded in modules on the frontend came from, but I've never seen it increase the feel of a website. Single monolithic JS file sites almost always feel better and load faster. It might be better to just process the small modules to be inline with the HTML, instead of using a dozen network requests.
  - d1sxeyes 5y ago
    > Single monolithic JS file sites almost always feel better and load faster. True, on a fast network, where you can get the whole JS file over the wire without significant latency or download time. For slower networks, a single monolithic JS file might not load before the user gets frustrated and navigates away.
WorldMaker 5y ago
It's interesting because there have been so many web developers over the years who been given the advice that a variety of 3rd party CDNs was "faster" and did that intentionally. It may have even been somewhat decent advice for a time. Mostly because of the 6 requests per host blocking in browsers: more hosts, more parallel requests. Of course parallelizing requests isn't always faster, especially as you point out if some of those CDNs underserve certain edges. Plus, HTTP/2 and HTTP/3 change some of the dynamics of that directly (by massively decreasing connection overhead to the same host so that even "blocked/serial" requests may finish a lot faster than the time it takes to open a full connection to a different host). Sometimes for the "if everyone uses the same CDN for jQuery the browser only has to cache it once for everyone" cache effect, and that is no longer true either as to avoid some privacy issues and such browsers have only further sandboxed their per-website/host caches and even "shared CDNs" no longer guarantee shared caches. But yeah, post-HTTP/2 and privacy-related CDN sandboxing, especially, it is further and further from good advice.
- lelandfe 5y ago
  > HTTP/2 and HTTP/3 change some of the dynamics of that directly Put bluntly: HTTP/2 and partitioned caches means using a CDN is flat out worse than self-hosting.

by ehnto 5y ago

TonyTrapp 5y ago

Not just third-party CDNs. One of the worst examples I have seen is the FlixBus website, which loads JavaScript from like a dozen different CloudFront subdomains, each one gradually adding more functionality to the site (e.g. one subdomain seems to be responsible for autocompleting city names). They seem to have taken the notion of microservices to a whole new level. Edit: CloudFront, not CloudFlare.

ehnto 5y ago
One of the slowest parts of a Shopify website is their CloudFlare backed CDNs (may have improved, it's been a year since I benchmarked). The app server responds in < 60ms, then the CDNs responds anywhere between 50-300ms, which tanked the user experience. Serving lots of little files even with HTTP2 has all the same problems, lots of little requests make the likelihood of hitting a bottlenecked CDN node more likely. I'm not sure where the idea of serving JS as small loaded in modules on the frontend came from, but I've never seen it increase the feel of a website. Single monolithic JS file sites almost always feel better and load faster. It might be better to just process the small modules to be inline with the HTML, instead of using a dozen network requests.
- d1sxeyes 5y ago
  > Single monolithic JS file sites almost always feel better and load faster. True, on a fast network, where you can get the whole JS file over the wire without significant latency or download time. For slower networks, a single monolithic JS file might not load before the user gets frustrated and navigates away.

WorldMaker 5y ago

It's interesting because there have been so many web developers over the years who been given the advice that a variety of 3rd party CDNs was "faster" and did that intentionally. It may have even been somewhat decent advice for a time. Mostly because of the 6 requests per host blocking in browsers: more hosts, more parallel requests. Of course parallelizing requests isn't always faster, especially as you point out if some of those CDNs underserve certain edges. Plus, HTTP/2 and HTTP/3 change some of the dynamics of that directly (by massively decreasing connection overhead to the same host so that even "blocked/serial" requests may finish a lot faster than the time it takes to open a full connection to a different host). Sometimes for the "if everyone uses the same CDN for jQuery the browser only has to cache it once for everyone" cache effect, and that is no longer true either as to avoid some privacy issues and such browsers have only further sandboxed their per-website/host caches and even "shared CDNs" no longer guarantee shared caches. But yeah, post-HTTP/2 and privacy-related CDN sandboxing, especially, it is further and further from good advice.

lelandfe 5y ago
> HTTP/2 and HTTP/3 change some of the dynamics of that directly Put bluntly: HTTP/2 and partitioned caches means using a CDN is flat out worse than self-hosting.