Web Development

Using Client Side Includes instead of Server Side Includes

Reducing processing overhead can improve the performance of Web sites with heavy traffic patterns. Using Client Side Includes to perform functions on the client side is one technique developers can use to reduce overhead. Here's how it works.

A Server Side Include (SSI) allows you to write some commonly used code once and have the server insert it into the pages for you. Many Web sites use these SSIs to provide common components such as a header, footer, navigation bar, or search bar. The main advantage of them is that they provide a single point of change, no risk of missing an occurrence in the site—similar to the benefits of using CSS or JavaScript files.

SSI files themselves can have any extension, but by default a page that uses one or more of them has the extension .SHTML to signify to the Web server that this page needs to be handled differently to a standard HTML file.

If we had a text file—call it news.txt—that contained information that we wished to include, we could use a SSI command to do this:
<!--#include virtual="/includes/new.txt" -->

What is a CSI?
A Client Side Include (CSI) is usually a short JavaScript function or routine contained in an External JavaScript file and is called in the same place as the SSI would be. CSIs can be contained either in a stand-alone file or included within a global JavaScript file which contains other useful client side JavaScript functions that the site may require.

The JavaScript that they contain outputs the same content as would have been provided by a SSI, so to the end user there is no difference in functionality or display. CSI calls are identical to JavaScript function calls; see the CSI JavaScript shown in Listing A.

You could call it from within any page that had included the JavaScript file containing the function as shown in Listing B.

The benefits of CSI
Because these files are loaded when the page is loaded, external JavaScript files, like CSS files, are cached on the local machine by the Web browser, so they don't need to be refreshed every time a user moves to a different page in the site or refreshes the current page. This means that the client download for each page is reduced as these elements have already been downloaded to the client side. Therefore the content does not need to be regenerated for each page via a SSI.

While the file size loss involved may not seem much, remember that these savings are per page impression, so on a heavily used site the reduction in bandwidth can be significant. It also ensures that the Web page is displayed to the user faster than if SSIs had been used.

In some cases, the SSI is only being used to provide a JavaScript function to the pages that it is used on, such as in this example. In these cases, why not just use a CSI and remove the need for the SSI entirely?

The other major benefit is that the SSIs are running on the client's local machine and not on your server, thereby saving you some performance overhead both in terms of the functionality that is the Include (which could include calculating today's date, or the last modified date of a file, or the current total of the user's shopping basket)—and the overhead of the Web server, which has to process the Includes and merge them in with the standard HTML that it is outputting to the client.

Some hosts do not allow their customers to host SSIs, and for these people CSIs provide a useful alternative. CSIs can also be useful in situations where a Web server is not available, for example, if you are producing a Web site that will be run from a CD.

If you have a large Web site that is already indexed and want to add SSI-type functionality, you may be very reluctant to rename all the pages from .HTML to .SHTML to support SSIs. You could change your Web server's configuration so that .HTML would be handled in the same way as .SHTML, which would resolve the problem. It will also force the server to process every .HTML file as a potential SSI file with all the inherent overheads.

What about browser support?
The last thing that we, as Web site developers, want is for a site to work in some browsers and then fail miserably in others. Many people state that not everyone who uses the Web has JavaScript—or any Client Side Scripting language—enabled. However, this is truer of technophiles and developers rather than your average user; this is supported by the figures from Web traffic monitoring sites such as The Counter.com.

It is also highly likely that you will be using JavaScript to provide other functionality within your site, so if they don't have JavaScript enabled, it may cause problems with other functionality on your site.

Do we still need SSIs?
Certainly, some functionality that you require can only be appropriately achieved by using code on the Server Side, for example, if you had to load data from a database or needed to connect to another application in order to get some of the data to be used in the resultant page.

Although CSIs remove the content of an SSI, they may still need to be called. It is quite possible that your SSI may be simply reduced to call to the CSI code, which delivers the required functionality, rather than having the content embedded in or generated by the SSI. This approach ensures that changes to the functionality of the CSI—such as adding an extra parameter or changing the order of function calls—can be quickly and easily applied across an entire site.

SSIs are also still the most efficient method if the output will be significantly different depending on the user's browser, IP address, etc., as only the relevant info will be sent to the client rather than all the permutations.

If you have a lot of data of which only a small amount is used on the final page, for example, listing the headers in a section of your site; you can use a CSI if you only have a few sections, but if you have many sections, then a SSI allows you to only return the ones that you need, rather than sending the entire list and then having to process it on the client side.

Comparing SSI to CSI
Laura Lemay, in her book Laura Lemay's Web Workshop: JavaScript 1.1 (Chapter 17), provides a helpful comparison of CGI and JavaScript, which if we replace CGI with SSI, the basic ideas are still valid. Using these pages as an example, here are a few comparisons of the capabilities of JavaScript and SSI:
  • My SSI version has about 20,000 quotes available, all stored in a database on the server. This wouldn't be practical with JavaScript, because all the possible quotations would have to be loaded with the Web page.
  • The JavaScript version is much, much faster, and it places no more load on the server than an ordinary Web page. The SSI version requires a server that supports SSI, access to it, and available disk space—things a low-priced Internet account may not provide. The JavaScript version, on the other hand, works even without a server.
  • The SSI version will work with any browser, but the JavaScript version requires Netscape, MSIE, or another JavaScript-compatible browser.
  • If the quotation was displayed in a text field, the JavaScript version could update it at the touch of a button, without even reloading the page. SSI can't update part of a page.

As you can see, both JavaScript and SSI have advantages and disadvantages. Which you choose for a particular job will depend on what you need to do and what resources you and your users will have available.

This reference was taken from an online copy of this book on the Eastern Mediterranean University Web site.

An example site
My personal site uses CSIs to deliver the constant elements of the site—the header, main menu bar, submenu bar, footer link bar and the date that the current page was last modified.

Alternatives
CSI provides a useful alternative or companion to SSI, the benefits can provide improved performance and functionality without a significant loss of performance due to it being rendered on the client side.
0 comments

Editor's Picks