SSI or Subroutines

which is better/faster?

[SuzyUK]

My ASP site is built using "templates" which I then call using the <include file/virtual> directive..

but would I be better to write say the header/footer/menus as subroutines(modules)? then include the one file in all pages calling the routines as required?

Is there any benefit to either way of doing this?

Suzy

[korkus2000]

I use includes because it is pretty quick and done before processing. It also allows me to see my code flow easier. I use multiple includes on my websites.

[phollings]

I use SSI. The major benefit is that I can standardize the page header/footer/side nav bar throughout the site. Where I need to (e.g., on the header, where each page has a unique title), I pass a text string via JavaScript that is written during the rendering of the included file. This greatly simplifies site maintenance, since a single change to any of the included files takes effect site-wide.

However, (and now I'm posing a question) it seems a shame that each of the included files has to be transmitted repeatedly each time another page is accessed. Wouldn't it be great if these files could be cached in the browser and "included" at the time the page was rendered? I suspect there is some way to do this using JavaScript, but what is it? Why isn't this widely implemented?

Peter Hollings

[JuniorHarris]

Remember search engines are not too hip on JavaScript, and if it was used to replace the SSI pages for header and footer content then it is very likely that the search engines will not see this [content]. Not a good thing for those which use the header/footer area to provide a site map, links, etc to the rest of the site.

I too use SSI not only for header and footer information, but also for functions and subroutines (I tend to use them from several different pages). I may have one or two which have inline functions/subroutines, but typically they are specific to that page only.

[rogerd]

Hi, phollings, welcome to WebmasterWorld! I guess the fact that server-side includes are server generated and the client never sees this is the fundamental factor that precludes browser caching. Images, of course, which may be the biggest bandwidth-hog, CAN be cached by the browser even when part of an include.

[phollings]

Hi, rogerd!

Yep, that's the fundamental part of it. The SSI get's stuffed into the page before it is shipped to the browser, so the browser gets no choice in caching it. You're right about the images, but still it seems inefficeient to me to repeatedly send the same HTML.

I don't know enough JavaScript to know how to do this, or even if it was possible, but I was wondering if the includes could be treated like <SCRIPT> and then written at the appropriate point in the HTML. If something like this would work it would significantly reduce my page sizes.

Peter Hollings

[SuzyUK]

Thanks for the replies...I too at the minute am using multiple SSI's, (some of them calling other SSI's too)..because the logic of the flow is easy for me to follow

I just wanted to know if using many includes slowed down loading times, but I take it from your replies that it doesn't or at least not particularly noticeably!

Peter...I hadn't even though about that one!

Thanks
Suzy

[RossWal]

Phoolings,
I think the document.write() javascript method is what you are looking for. However, you may not gain the efficiencies you might expect without some other changes. True, you can cache the code on the client, and that is good. But, the client may do a handshake with the server to check timestamps before using the the cached script.

This handshake (actually exchanging some http headers) will likely be more costly than simply sending the html instream in the first place. I say 'may' because I'm only familiar with the behaviors of IE5.5/6 and IIS servers. I don't know how NN and *nix behave.

On IIS there are a couple of options to tell the client to use the code it has in cache without the handshake. One is a file/directory setting in the MMC. Another is the ASP Response.Expires command. You can also manually post the HTTP expiration headers, nut I forget how that works. Also, you need a plan for 'uncaching' your stuff should you make changes to the javascript code, but I'm already getting long winded and possibly off topic here.

Ross