The main function of a CDN for a developer is not to worry about network traffic and to be able to guarantee visitors the availability of files at all times. For the user is to obtain from a second domain (parallel loading) the files, from a place that would probably be closer physically decreasing the latency (connection time, DNS resolution and download).
If your visitors are geographically close to you, or are unique to a locality (country, country or continent), there is NO MUCH need for a CDN, as users will not make that much difference. In this case, I recommend that you create a subdomain or even another domain (that's your strategy) to serve those files. So you can serve in parallel and a cookieless domain.
Ideally, you should make your pages to make the least amount of requests (both for the same domain and for many: CDN, subdomains, etc.), so you increase the speed of page loading.
Try to merge into just one .css or .js file (you can build on separate files, but when posting put it all together, or use tools that do this) all code that will be used by a particular area of your site . Compacte (remove unneeded spaces, indentations, comments, use GZIP compression), and cache these files (set the files to be in the user's cache for as long as possible, and if you update the data in the files then change the URL that the user search, forcing a new download, updated).
If you are going to provide customization and are using scripting libraries, do not provide the library for a CDN and its customization to the part of your server (or your own CDN). Put it all together into one and make everything available to your users. Initially you will increase your server traffic a bit, however you will decrease the requests from the users and will have control over the cache of these files completely.