3 ms·

Code splitting can be a nice optimization but it can also be a lot of effort for little gain as it is in our case. It is an optimization for the few times a use

Code splitting can be a nice optimization but it can also be a lot of effort for little gain as it is in our case. It is an optimization for the few times a user hits our app with a stale or empty cache. And we have no mobile users, this is an enterprise analytics app. We do not grow organically by people stumbling on our app and thinking "wow that was fast". We go through months of enterprise sales process to ink a deal, then onboard maybe 20 key users at the company. To put the effort into code splitting would be purely an exercise in keeping up with the new hotness. That's not to say we don't keep a close eye on the package size, just that it's not much of a great optimization for a regular user's experience in our case. Also serving all assets from the same domain saved us some time in domain resolution.

nullwasamistake 7y ago
The last part, absolutely yes. CDN's are obsolete, although they'll jump through all sorts of hoops to convince you that's not the case. As long as your service uses HTTP/2 it's far more efficient from DNS and multiplexing/TCP/TLS handshake standpoint to serve from your own domain. And better for security most of the time since hardly anyone uses CSP and hash signatures for their third party scripts. The original sell of CDN was that everybody would have the same libraries cached. With the massive poliferation of JS you would have to have a 100 gig cache for that to be remotely true. A couple years back I moved a C# app to .NET core for the HTTP/2 support. I tried removing the ~4 external CDN dependencies just to see what happened. Load speed improved around 30% because no additional DNS lookups and TCP window stuff worked around by multiplexing. An aside, try not to use multiple subdomains. They trigger DNS lookups and don't work as well with CORS. It's easy to accidentally trigger cors and a bunch of meaningless round trips by using different subdomains
- billyhoffman 7y ago
  I think you are conflating general Content Delivery Networks with “shares JavaScript library repositories that happen to use a CDN”. While the “it’s a shared repo of common JS files so it’s already cached” idea never really worked (you are right about the added cost of DNS + tcp/TLS) general Content Distribution Networks absolutely provide performance benefits by delivering your static (and optionally dynamic) content from edge nodes that are much geographically closer to the visitor. Usually these CDNs front the entire site origin, so you dont have extra dns/overhead for subdomains like shared JS repos. (I work with many IR Top 100 retailers, and I’ve helped to build the dashboards comparing edge vs origin. It’s valuable even for sites where the majority of the visitors are in the US, and especially so if you have a substantial international audience)
  - nullwasamistake 7y ago
    When they front the origin there's definitely an advantage, I agree. But that implies: You allow a CDN to host your initial asset, possibly a security risk You only use that one CDN for most/all non-dynamic content. When latency becomes that important I would rather host my own AS. Giving CDN the origin and your first content load is effectively handing off your entire site security to a third party. At that scale you could easily and cheaply run multi-homing on your own AS in maybe 10 colos across the world. Maybe 100k a year to eliminate third party risk. Maybe worth it? I think so
- jabart 7y ago
  Looking at our metrics, we have over a 95% cache hit ratio using CloudFront. We use it to store large JS libraries, think Excel, table plugins, HTML editors, and it works great. It keeps the pressure off our origin app server and we version each release of the vendor code, so it rarely changes. It also helps that our users share the same office space, so its always cached for the 20+ users in the office. The phrase "CDN's are obsolete" is not true, it is not a simple true/false statement but a complicated one. HTTP/2 is not always faster depending on if your link connection has any loss to it (wifi, spotty 4g).
  - nullwasamistake 7y ago
    Cache lookups are cheap, if these users are all in the same office you would be much better off just storing everything at a close by datacentre. By using hash fragments you can prevent lookups completely and get the same hit rate as the CDN without using one at all
skybrian 7y ago
Yes, it's a trade-off. But if you move towards frequent or continuous deployment, all your users could see a stale cache quite often.
fooey 7y ago
The latest version of create react app makes code splitting easy using lazy/suspense
madeofpalk 7y ago
> Code splitting can be a nice optimization but it can also be a lot of effort for little gain as it is in our case. We came to the same conclusion when investigating as well, but because of the structure of our site - we had just a handful of layout primitives that were reused across the site so page splitting had no benefits because every page used the same code anyway. Still an optimisation to look into if you can benefit from it!

nullwasamistake 7y ago

The last part, absolutely yes. CDN's are obsolete, although they'll jump through all sorts of hoops to convince you that's not the case. As long as your service uses HTTP/2 it's far more efficient from DNS and multiplexing/TCP/TLS handshake standpoint to serve from your own domain. And better for security most of the time since hardly anyone uses CSP and hash signatures for their third party scripts. The original sell of CDN was that everybody would have the same libraries cached. With the massive poliferation of JS you would have to have a 100 gig cache for that to be remotely true. A couple years back I moved a C# app to .NET core for the HTTP/2 support. I tried removing the ~4 external CDN dependencies just to see what happened. Load speed improved around 30% because no additional DNS lookups and TCP window stuff worked around by multiplexing. An aside, try not to use multiple subdomains. They trigger DNS lookups and don't work as well with CORS. It's easy to accidentally trigger cors and a bunch of meaningless round trips by using different subdomains

billyhoffman 7y ago
I think you are conflating general Content Delivery Networks with “shares JavaScript library repositories that happen to use a CDN”. While the “it’s a shared repo of common JS files so it’s already cached” idea never really worked (you are right about the added cost of DNS + tcp/TLS) general Content Distribution Networks absolutely provide performance benefits by delivering your static (and optionally dynamic) content from edge nodes that are much geographically closer to the visitor. Usually these CDNs front the entire site origin, so you dont have extra dns/overhead for subdomains like shared JS repos. (I work with many IR Top 100 retailers, and I’ve helped to build the dashboards comparing edge vs origin. It’s valuable even for sites where the majority of the visitors are in the US, and especially so if you have a substantial international audience)
- nullwasamistake 7y ago
  When they front the origin there's definitely an advantage, I agree. But that implies: You allow a CDN to host your initial asset, possibly a security risk You only use that one CDN for most/all non-dynamic content. When latency becomes that important I would rather host my own AS. Giving CDN the origin and your first content load is effectively handing off your entire site security to a third party. At that scale you could easily and cheaply run multi-homing on your own AS in maybe 10 colos across the world. Maybe 100k a year to eliminate third party risk. Maybe worth it? I think so
jabart 7y ago
Looking at our metrics, we have over a 95% cache hit ratio using CloudFront. We use it to store large JS libraries, think Excel, table plugins, HTML editors, and it works great. It keeps the pressure off our origin app server and we version each release of the vendor code, so it rarely changes. It also helps that our users share the same office space, so its always cached for the 20+ users in the office. The phrase "CDN's are obsolete" is not true, it is not a simple true/false statement but a complicated one. HTTP/2 is not always faster depending on if your link connection has any loss to it (wifi, spotty 4g).
- nullwasamistake 7y ago
  Cache lookups are cheap, if these users are all in the same office you would be much better off just storing everything at a close by datacentre. By using hash fragments you can prevent lookups completely and get the same hit rate as the CDN without using one at all

skybrian 7y ago

Yes, it's a trade-off. But if you move towards frequent or continuous deployment, all your users could see a stale cache quite often.

fooey 7y ago

The latest version of create react app makes code splitting easy using lazy/suspense

madeofpalk 7y ago

> Code splitting can be a nice optimization but it can also be a lot of effort for little gain as it is in our case. We came to the same conclusion when investigating as well, but because of the structure of our site - we had just a handful of layout primitives that were reused across the site so page splitting had no benefits because every page used the same code anyway. Still an optimisation to look into if you can benefit from it!