Is there a way to serve Html and dynamic imports from CDN?

[dirkgently]

Meteor generates split bundles if you use dynamic import, is there a way to serve them from CDN like the main bundle, rather than DDP? Same for the main html.

[tathagatbanerjee]

can you explain your use case a little bit please. this seems a super interesting topic, and i’d be keen to follow the discussion. sorry - have no idea about answer.

[alawi]

I don’t think this is possible right now, but I’m wondering how useful that would be? I found the fetching of the bundle to be extremely fast if they’re divided into reasonable junks.

Can you elaborate on why do you think this is good to have?

[dirkgently]

I enabled CDN on our app, the bundle size was ~1.7MB so I thought that doing so would improve load times on mobile, but it doesn’t seem to make a big difference for users in same country as hosting provider.

Next step was to split code into chunks using dynamic imports. But these then get served from the app server via DDP. If you do this in webpack usng common chunks plugin etc, you get a bunch of static assets that can be served from a CDN.

The other advantage to this is once you enable code splitting, a lot of times the chunks won’t change. With a single bundle (the default in Meteor/webpack), any change to your code means new hash/bundle. With splitting, only some of them will change, and the rest can continue to live on the CDN, and be cached on user devices, meaning faster downloads.

Same thing applies to using 3rd party libs - its better to load them from external cdn so they are cached and don’t have to be updated.

At least that’s my thinking. I know there’s only so much that can be done.

[avalanche1]

With splitting, only some of them will change, and the rest can continue to live on the CDN, and be cached on user devices, meaning faster downloads.

Arent they supposed to be cached on user browser after being downloaded once via DDP?

[alawi]

If you split the the code, then the initial bundle size will decrease and it will be cached on CDN. The modules are loaded via sockets when needed and for first time and I think this operation would be extremely fast since you’ve dedicated socket connection established (I mean if serving those files via sockets is slow, then so is the data). The Second time the user request the files, it will use the local storage of the browser.

If you’re too concerned about the initial fetch time of the module then those which are commonly used can be eagerly fetched and cached at the client and only rendered when a page needs it. So I still don’t see how caching the modules on CDN would speed the initial load or the load for returning visitors.

From what I’ve seen the bottleneck seems to be the time it takes to evaluate and initiate the JS scripts, the larger the file the more processing it will require. Even on local host, initiating a react app takes around 2.7 seconds on my machine, the only way I can think of to speed this up is SSR or using something lighter than react, others have wrote about this. With SSR you can achieve a meaningful first paint of less then a second and interactive site within 2.7 seconds.

[drone1]

Aside from the fact that loading assets from a CDN vs. directly from the a server will on average probably be a lot faster, it is also not a scalable solution – as your audience grows, the cost of adding Meteor containers (on Galaxy) is going to be a lot more expensive than using AWS/CloudFront, for example.

It simply isn’t a great use of resources, is literally more costly and is likely to be slower.

[coagmano]

It seems this should be possible now.
Meteor switched from DDP to HTTP POST for dynamic import requests and Cloudflare’s workers allow you to cache POST requests: https://blog.cloudflare.com/cache-api-for-cloudflare-workers-is-now-in-beta/

Not sure if you can cache POST requests for other CDNs but there’s at least one way!