Pros and Cons of Server Side Includes

[ellenjones6]

I do a web site for a nature center in the Adirondacks (http://adirondackvic.org/index.html). The nature center has changed its trail system, creating the need to rework the navigation for the site. I need some advice.

The site started small, with about thirty pages, so I created it using Dreamweaver templates, making it pretty easy to update. However, now it has grown to over 250 pages. I need to modify the navigation panels and footers, which means updating and re-uploading over 250 pages. Because additional revisions are likely in the future, I am considering a move to server side includes, with three separate include files: vertical navigation, horizontal navigation, and footer. I have two issues I am grappling with.

-- The first step to implement this plan was to test it out on one page. I did that, and the resulting page is available here: http://adirondackvic.org/Adirondack-Nature-Walk-2-August-2013.html. I want to make sure this page works before I proceed. I am testing it with all the browsers on my system, plus on IE tester and Sauce Labs. It seems to work fine for most of the browsers and operating systems I have tested. The page does not work with IE 6 but so few US users use it that I have decided to ignore the problem. Is that a reasonable decision? Also, does this page work for other people, using other operating systems and browsers? Do you have any advice about other testing strategies?

-- Second, before I rework the Dreamweaver template to incorporate the SSIs and revise and upload all the pages again, are there any major disadvantages of server side includes which I should consider before I go through this lengthy process? Do pages with SSIs take much longer to load?

Let me know. All advice gratefully received. Ellen

[Beverleyh]

The only disadvantages I can think of is that there will be a little extra work/time for the server to 'knit' all the pieces together and also for it to parse your SSIs in an .html page (as you didn't need to change your file extension to .shtml its probably because the server is setup to parse .shtml as an .html automatically, which makes it work a tiny bit harder) But if your files/images are well optimised anyway, there will be no noticeable delay to visitors.

Another possible disadvantage is how WYSIWYG web builders (such as DreamWeaver) display your segmented files during editing - they're not going to look quite so pretty and if you rely heavily on visuals, you might find it a bit off-putting at first. If you're comfortable editing the code/markup directly though, it wouldn't make much difference to you.

[molendijk]

Server side includes:
- 100% reliable;
- are not cached (as far as I know), which may affect loading time;
- unless you're able to configure your .htaccess file, SS-includes must have a specific extension (like .php, .shtml); if configuring the .htaccess file is not possible, you must rename all your files (which you probably don't want).

Client side includes:
- not 100% reliable, although jquery-includes are quite stable today;
- are cached, which speeds up loading time;
- no need to rename your files.

On your demo, the included files don't have menu-items that fly out onmouseover or onclick. So you could also consider using iframes for your includes. That method always works.

[djr33]

The answers above are probably good enough. So I'll keep mine short (and please feel free to ask additional questions).

The "right way" is probably to use serverside code. It simply allows more options and allows things like using a database or running statistics on things later. Technically, there's no disadvantage.

But the cost is simple: your time. So you need to decide if it's worth doing it the "right way" for what sounds like a relatively small site. If you need to make lots of changes, then some initial setup will be worth it. If it's just a one time change and you can leave it alone for years, maybe it's not worth it.

Personally I'd use serverside code, but I already know how, so there's no learning curve for me.

Either way, you can end up with the same result (with some slight technical differences), so the question is what's best for your situation. If you have the time, use serverside code. It's more stable and will save you time in the end (using a database will also save you time), but it will take some time to set up in the first place.

In general, anything on the server (anything "server side") is completely hidden from the user. Unless you have really complicated code (really complicated), you won't notice any speed differences or anything else. That's the great part of serverside code-- it's silent. And it runs on the server so it works exactly the same way for everyone. What each visitor gets is just plain HTML code, nothing extra to worry about like Javascript compatibility.


So again, if you have the time and this project is worth the time, then use serverside code. If not, and if it's better for your situation to cut some corners, that's fine too. The result can be the same effect for the users.

Based on what you've said, you might want to take a look at Beverley's signature for "Fast Edit", a simple but useful serverside tool for this sort of thing. It could be the right balance for you.