This CDN customisation guide can load your web application super-fast!
A content delivery network (CDN) is a system of distributed servers (network) that deliver webpages and other Web content to a user based on the geographic locations of the user, the origin of the webpage and a content delivery server.
The major advantage that a CDN server can help with is by caching the library files, be it JS scripts or CSS files.
More about it can be found in the wiki page: https://en.wikipedia.org/wiki/Content_delivery_network
When to use a content delivery network depends on the scripts that we want as dependencies for the project. Let’s take a JS library xyz.js for example. Here are the ways xyz.js can be included in the application:
- Using locally:
<script src=”/scripts/xyz.js”/>
2) Using CDN:
<script src=”https://cdnjs.cloudfare.com/blah/xyz.js"/>
3) Using Bower:
Using <script src=”/bower_components/…/xyz.js”/>
The major differences in these 3 approaches can be briefed into the following Pros and Cons.
Using local:
Pros:
1) Reliable for small libraries, that have no major advantage of caching. Thus, if xyz.js is relatively small, local include serves the purpose.
2) Can tweak or configure the library xyz.js for its impartial usage, i.e., using only specific features of the library instead of whole
3) By stitching xyz.js and many other such libraries to index.html (or something similar), we can produce one larger file to download (compared to many little ones) which browsers are efficient at retrieving. This speeds up app load times for users.
Cons:
1) Takes a blow on page loading time for larger libraries. However, it can be controlled if xyz.js is stitched to a larger index.html file
2) Have to manually keep a track of and install the specific libraries with their explicit version numbers. Thus, it gets difficult with evolution of the app as well as xyz.js. Obviously a scheme can be devised for the team to follow based on best practices, but again there is room for user error and/or ignorance.
3) When using minify task and producing something like xyz.min.js, we may hit the standard problems that anyone faces. These tasks sometimes cannot finish the job without manual intervention as they end up breaking the code and require time and intelligence to go in and debug them and/or fix the generated output to work again.
Using CDN:
Pros:
1) Browser uses cached copy if it already visited a website using xyz.js. Just make sure to properly set cache flags for the library. However, almost all CDN networks set the cache flag true for all library files by default.
2) Faster load time if the xyz.js is frequently called by applications across the web. This applies only to the library xyz.js, and not for the app using it.
3) Faster load time in sense to geographical proximity
4) Easily available hyperlinks to libraries. Makes life easy for developers.
5) We can automate the process of uploading the large index.html file to a CDN after builds or as part of deployment. This means there is only one large file to get and on top of that, it downloads faster.
Cons:
- Relying on third party service creates insecurity of application failure if CDN fails to serve the library, or if ISP blocks a certain CDN(in some cases). Always make sure to check average reviews for the CDN network you plan to work with.
2) Useful for large files only. Doesn’t serve the purpose for relatively smaller libraries as the client’s browser opens numerous connections to download many such little files. But again, if the app’s index.html file isn’t stitched with the library, then having to download 3 small files from CDN is quite ok and faster. That much a browser can handle. The chances for this to happen are 1 in 100.
3) A real headache for offline development
4) Developers may make the mistake of referring to a generic file rather than a versioned file. It lacks automation.
Using Bower:
Pros:
- Spares the need of hunting libraries and their specific versions across the development team and across inter-dependent frameworks. Thus helps everything sync up real nice in an automated fashion for all the team members for development. It can be achieved by a practice of locking down version numbers in bower.json (yes it is possible to lock them down)
Use the following symbols in your bower.json file for better version controlling:
“^” — It will update you to the most recent major version (the first number). ^1.2.3 will match any 1.x.x release including 1.3.0, but will hold off on 2.0.0.
“~” — In the simplest terms, the tilde matches the most recent minor version (the middle number). ~1.2.3 will match all 1.2.x versions but will miss 1.3.0.
“*” — can be used as wildcard.
2) All libraries can be concatenated and minified into one single file, thus single HTTP request which browsers are efficient at retrieving. This speeds up app load times for users.
3) You get pre-minified versions from the authors themselves.
Cons:
1) Depends on Github, so if Github is facing network issues, so will your project, especially in critical times such as deployment in production. But this has the chances of happening only once in a decade.
2) Installing libraries through bower increase the project size a lot, thus with bower you already have a project with more than 10k lines of code without writing a single line of code related to the application itself. But again, we can choose to publish only the required ones for deployment of the project. Checking in “/bower_components” will increase the repository size to a huge giant, difficult for cloning and deployment
3) Checking into repositories can be an issue if version tracking is not done properly with ~/^/* symbols. That’s why we never checkin bower_components and would rather follow the practice of freezing version numbers in bower.json
Overall, using or not using CDN really depends on the type of project and the type of libraries it is dependent on. There are other ways of making the application load faster, that include:
- Lazy loading of libraries,
- Using multiple server nodes instead of a single server,
I’ll be covering these two in my next article. Stay tuned!
