Jun 23, 2013, 4:35 AM
Performance Arguments...
Ran some numbers...
Filesize: 1.4mb
http://cdn.sencha.io/ext/gpl/4.2.1/ext-all.js ~750ms
https://extjs.cachefly.net/ext/gpl/4.2.1/ext-all.js ~650ms
http://speed.ext.net/ext.net/2.2.0/extjs/ext-all.js ~1.5-3.5 seconds
http://www.myserver.com/extjs/ext-all-js/ext.axd?v=39808 ~11-15seconds
Filesize: 284kb
http://cdn.sencha.com/ext/gpl/4.2.1/...e-gray-all.css ~120ms
https://extjs.cachefly.net/ext/gpl/4...e-gray-all.css ~140-300ms
http://speed.ext.net/ext.net/2.2.0/extjs/resources/ext-theme-gray/ext-theme-gray-all.css ~200ms
http://www.myserver.com/extjs/resources/ext_theme_gray/ext-theme-gray-all-embedded-css/ext.axd?v=39808 ~300ms-1.6sec
As you can see, cdn helps my website first-time load performance SIGNIFICANTLY if I can stream even this one major component. Bandwidth throttling has a massive consequence on my server's simultaneous load times. Cutting down the single file, ext-all.js, reduces my website load times from 15+seconds to <= 3 seconds. Of course, I can't cdn if I use anything from the trunk per current cdn strategy.
Part of the very high load of the ext-all.js from ext.net's cdn is from the lack of gzip streaming (as was previously noted as being currently addressed, as not yet). However the first time cache hit is pretty heavy still which means even after compression may still run the risk of > 1s load times first time. Not really a major deal but still noting for the basis argument.
I'm sure different users will have different experiences depending on their location and the effect of time and load on cached servers. Also speed.ext.net and https cachefly servers seem to have a first time lag whereas the cdn.sencha.com servers do not. I'm guessing this is probably related to frequency of use. Sencha resources are probably in higher demand which makes them cache more.
Anyway, another argument to justify loading from the sencha cdn is greater parallelization. Most browsers are limited to how many resources can be simultaneously loaded from the same domain. Separation would increase browser parallelization opportunities. That is, browsers more often may be able to load the larger extjs and extnet resources at the same time this way. Older browsers limit at 2 at a time and extnet resources will load at minimum 4 resources, 5 if linking, upwards from there if ux controls or images are loaded. So you can see where I'm going with the importance of this.
Filesize: 1.4mb
http://cdn.sencha.io/ext/gpl/4.2.1/ext-all.js ~750ms
https://extjs.cachefly.net/ext/gpl/4.2.1/ext-all.js ~650ms
http://speed.ext.net/ext.net/2.2.0/extjs/ext-all.js ~1.5-3.5 seconds
http://www.myserver.com/extjs/ext-all-js/ext.axd?v=39808 ~11-15seconds
Filesize: 284kb
http://cdn.sencha.com/ext/gpl/4.2.1/...e-gray-all.css ~120ms
https://extjs.cachefly.net/ext/gpl/4...e-gray-all.css ~140-300ms
http://speed.ext.net/ext.net/2.2.0/extjs/resources/ext-theme-gray/ext-theme-gray-all.css ~200ms
http://www.myserver.com/extjs/resources/ext_theme_gray/ext-theme-gray-all-embedded-css/ext.axd?v=39808 ~300ms-1.6sec
As you can see, cdn helps my website first-time load performance SIGNIFICANTLY if I can stream even this one major component. Bandwidth throttling has a massive consequence on my server's simultaneous load times. Cutting down the single file, ext-all.js, reduces my website load times from 15+seconds to <= 3 seconds. Of course, I can't cdn if I use anything from the trunk per current cdn strategy.
Part of the very high load of the ext-all.js from ext.net's cdn is from the lack of gzip streaming (as was previously noted as being currently addressed, as not yet). However the first time cache hit is pretty heavy still which means even after compression may still run the risk of > 1s load times first time. Not really a major deal but still noting for the basis argument.
I'm sure different users will have different experiences depending on their location and the effect of time and load on cached servers. Also speed.ext.net and https cachefly servers seem to have a first time lag whereas the cdn.sencha.com servers do not. I'm guessing this is probably related to frequency of use. Sencha resources are probably in higher demand which makes them cache more.
Anyway, another argument to justify loading from the sencha cdn is greater parallelization. Most browsers are limited to how many resources can be simultaneously loaded from the same domain. Separation would increase browser parallelization opportunities. That is, browsers more often may be able to load the larger extjs and extnet resources at the same time this way. Older browsers limit at 2 at a time and extnet resources will load at minimum 4 resources, 5 if linking, upwards from there if ux controls or images are loaded. So you can see where I'm going with the importance of this.