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?
The benefits of CSI
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.
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?
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
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.
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.