A slight diversion from photography for a moment; after all, I do make technical solutions too! :-) I was checking out the new version of the Jungfrau Zeitung website a few days ago, looking at the new layout and site logic, trying (and failing) to find the RSS feed which used to keep me up-to-date on English news from the Bernese Oberland and looking “under the hood” – at least, the one which is publically accessible – to see what changes had been made from a programming point of view.
Content delivery networking
While I was still working for the paper as co-developer, we decided to improve the performance of the website by implementing a load-sharing CDN (content delivery network) solution; namely, to move dynamic content images and extraneous files such as CSS and layout icons to a second web server, to allow the main web server to concentrate on delivering database content in the form of news articles. This made the main server run much faster, as it had to handle many fewer requests per web page.
(When you call up a web page, the web server has to deliver not just the page itself, but also CSS files which control the layout, images and so on.)
One aspect of the website which we didn’t change was where the Javascript files were stored. Those remained on the same server as the web pages themselves, as we were under the impression that for security reasons, Javascript files could not be called from one domain for use on another domain. (For example, if the website pages were at domain1.com, then the Javascript files couldn’t be loaded from domain2.com.)
Since the team re-released the website with a new code structure, I was surprised to see that the Javascript files had been moved to a different server after all and seemed to be working in exactly the same way. I did some research online and discussed the solutions with a few developers before coming up with the explanation, which I thought I would share (as most websites dealing with similar – but not identical – issues cover a different topic).
Security limitations in Javascript
In order to stop a malicious programmer disrupting a website or gaining sensitive information, it is not possible for a script on a website to access another window (or iframe) which has been served from another domain. This issue also covers making XMLHttpRequest (“AJAX”) calls to a domain other than that of the website making the request. (A search at Google will turn up a vast number of websites explaining why in more detail, so I won’t go into that here.)
If you call Javascript files in the head of your HTML document from a different server, then you can refer to the functions and variables in those files! The reason behind this is that you have full control over which functions are being called and which script files are being loaded. The functions in the external scripts can also access local variables, or variables in other scripts in the same window. The key point is that all of the scripts, functions and variables are being accessed from the same browser window.
What are the benefits?
* By putting all your Javascripts on an external server, the load times can be improved for the main web server, as it will have to deal with less individual requests.
* Browsers add an artificial brake which means that only a certain amount of concurrent requests may be made from the same domain. That means that if you have a lot of files being requested by each web page, some of them will be queued until others finish loading. By putting some of the files in other domains – for example scripts.permanenttourist.ch, layout.permanenttourist.ch and images.permanenttourist.ch (none of which are actually implemented here, they’re just examples) – you’ll increase the loading speed of your web pages.
* If you maintain several websites and programme all of them using the same code base and logic, you can share Javascript functions across all websites. This requires rigorous debugging and a considerably well thought-out logic, to make sure that a changes to functions at a later date don’t break one of your websites which has been coded in a slightly different way.
—
If you’d like to find out more about my website and programming projects, please drop me a line. I intend to put more details of specific web projects online when I can, but I can’t guarantee when they’ll start appearing! Follow the blog – using the RSS reader is easiest – and keep an eye out for new entries in the Internet category to see more geeky stuff.
Leave a Reply