4 ms·
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 subdomain
by 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 agoOne 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.