Splitting Code Between Multiple SSI

February 6, 2006 3:53 PM

What are the negative consequences of placing Web page HTML code into multiple SSI files?

There is a proposal at my work to use numerous server side includes (SSI) for all aspects of the HTML code in an individual Web page, except for three areas which the Web publishers need to customize (i.e.: the metadata, some side bar navigation, and the main content area). Our supervisor is thrilled, because this proposal is being presented as a "content management solution".

The proposal goes something like this: The DOCTYPE, opening HTML and head tags, and some global metadata would end up in the first SSI file. The CSS link reference and close of the head in a second SSI file. Since the opening body may or may not need to be customized with onload or other commands, this tag would not be in a SSI. The third SSI file would contain: an embedded SSI statement for the existing header and the opening code to define the structure of the page. The forth SSI file would contain the closing code and the opening code for the transition between the side bar navigation and the main content area. The fifth SSI file would contain the closing code for the page layout structure, an embedded SSI statement for the existing footer information, and all the remaining closing tags for the HTML document.

* Is there a point of diminishing return to using numerous SSI statements in one Web page?
* Will pages with 5 or more SSI statements load faster for the user - due to caching? Or does the page still need to process all the code (whether in an SSI file or not) before finishing the page rendering?
* Are there technical reasons to not put opening HTML code in one SSI and closing HTML code in another SSI file? (i.e.: can all browsers handle this?)
* Can comments be added inside the SSI statement (e.g.: something like "do not more or remove this SSI statement" before or after the file reference information)?

posted by chase to computers & internet (15 comments total)

"Are there technical reasons to not put opening HTML code in one SSI and closing HTML code in another SSI file? (i.e.: can all browsers handle this?"

It's "SSI" because this happens on the server side. The browser is irrelevant, excepting when your SSIs build something incoherent. It depends upon your server how the SSIs will affect performance, particularly with regard to any caching that it does. I'd just put a comment before the include.

There'll probably be someone who will come along and give you more complete and up-to-date info. I've been five years since doing this sort of thing. But I'd advise you to take a look at the relevant HTTP specs about SSIs, and the corresponding documentation for your particular server.
posted by Ethereal Bligh at 4:04 PM on February 6, 2006

Well, it would make it a bit of a pain to maintain in some ways, as you would need to figure out what files to edit, although of course it would be better then tons and tons of .html files.

It's hardly a "CMS" though, it's more of just a mess. You'd be better off writing some sort of database-driven system in PHP or similar that would let you customize exactly what you want specifically, rather then this mess of includes.

* Are there technical reasons to not put opening HTML code in one SSI and closing HTML code in another SSI file? (i.e.: can all browsers handle this?)

The browser never sees any of this, its done on the server, before the file is sent, and no one outside will ever know.

* Can comments be added inside the SSI statement (e.g.: something like "do not more or remove this SSI statement" before or after the file reference information)?

Yes, of course. Remember, all your SSI instructions are parsed in one step, producing an output file, which is treated as a single file by the webserver and subsequently the browser.
posted by delmoi at 4:05 PM on February 6, 2006

* No. What you're proposing is done on thousands of sites everyday for the very reason that your supervisor is thrilled. It's not a CMS, but it is easier to maintain certain web elements across multiple pages.

* This really doesn't make any difference. The client browser is not aware of what is happening on the server, client side caching is independent of SSI.

* It's not the browser that matters, it the server. Because the server is processing 5 (or more) files with each request there may be a slowdown on that end, but (depending on the hardware) it should be fairly negligible. Some server or hosting providers do not support SSI by default. It's easy to enable if you can modify .htaccess files but it's probably the only downfall to SSI.

* You can use regular HTML comments.
<!-- do not more or remove this SSI statement -->
<!--#include file="header.html" -->

Here's a good start on getting to know SSI.

Personally, I prefer templating systems as a lot of them have caching capabilities which can reduce the server overhead. They're a little harder to implement (regardless of the preferred language) which is why SSI is so popular.
posted by purephase at 4:07 PM on February 6, 2006

Since everything happens on the server side, there will be no client-side caching advantage to having common page elements on different pages be drawn from the same file, nor will browsers have trouble with opening HTML code in one SSI and closing HTML code in another SSI.

What I'm not sure about is how well modern webservers deal with serverside includes. They could well cause more load on the serverside because each page has to be parsed to find the include points.

I can see how this approach might make certain things easier, it would still depend on the page author including the right SSI includes in the approprate positions of each file.
posted by Good Brain at 4:07 PM on February 6, 2006

If I were in your position, I would use a database with the following tables:

doctypes
sidebars
csslinks
content.

Each PHP file would then simply run a query requesting those separate items. so if you need doctype A, sidebar B, css C and content D you could run a queries like "Select HTML from doctypes where id = 'A'";

You could also add a "pages" table that just included four fields, containing the ID numbers or names of the blocks of HTML in the other tables, then you'd just do a join query to link them together.

I'm not saying that this is the best way to do it, but it would be much simpler then your SSI system as far as maintenance, and not much more time to write. (want to update the sidebar on pages meeting a certain criteria? Rather then a ton of editing, you just do two queries, one insert on sidebars, and one update on pages). It all really depends on what specifically you want to optimize.

Finally, with this system, you could write a program that would run through your whole database and generate all of your pages in one run, and spit out all your HTML pages. That way, you could run this program whenever you change something in your database, and all the pages will be updated, while at the same time not requiring the server to do any work at all to build the pages from multiple sources using SSI.
posted by delmoi at 4:14 PM on February 6, 2006

Well, to expand on some other people's points...

"It's hardly a 'CMS' though, it's more of just a mess. You'd be better off writing some sort of database-driven system in PHP or similar that would let you customize exactly what you want specifically, rather then this mess of includes."

That depends, of course. It's not a CMS, but it does make a certain kind of site much easier to maintain. And that certain kind of site doesn't need a db-driven design.

"Yes, of course. Remember, all your SSI instructions are parsed in one step, producing an output file, which is treated as a single file by the webserver and subsequently the browser."

I think delmoi misunderstood your question.

"Because the server is processing 5 (or more) files with each request there may be a slowdown on that end, but (depending on the hardware) it should be fairly negligible. Some server or hosting providers do not support SSI by default. It's easy to enable if you can modify .htaccess files but it's probably the only downfall to SSI."

When you compare a plain-old http server without SSIs and one with SSIs, it's obviously the case that parsing each file for SSI statements is a quite significant addition of work to the server. However, in today's world, almost everything is dynamic and thus all pages are parsed in one sense or another. That being the case, I would strongly suspect that any modern web server will not see much of a load increase when asked to parse the HTML.

purephase's mention of templating systems is really what you're reaching for here, but you do not necessarily need that much of a solution for your problem. When the server can identify page components for changes and thus intelligently cache the page it delivers to the browser, you get all the benefits of a dynamic pages with the maintainability benefit you get from breaking pages up into components.
posted by Ethereal Bligh at 4:24 PM on February 6, 2006

The only drawback I can see is that editing the content may be a bit harder - unless your editor deals with SSI directives, you won't see what the site actually looks like if you're shoving things like, say, stylesheets and stuff into an SSI. If your editors don't use a WYSIWYG editor or if that doesn't bug them then it's not an issue. That said, this is exactly what I do on many sites, except I use PHP instead of SSI. The load increase will be negligable - very slightly more than just a big chunk o' file, and a good deal less than using an actual templating engine. Be sure you keep things organized, though, or you haven't solved the problem. (FWIW, if your host doesn't support SSI but does support PHP, using the PHP include() function will do the same thing, as PHP files don't necessilarily have to include any PHP.)
posted by mrg at 4:38 PM on February 6, 2006

Are there technical reasons to not put opening HTML code in one SSI and closing HTML code in another SSI file? (i.e.: can all browsers handle this?)

Technical reasons, no. Organizational/legibility reasons, yes. It just creates a lot of opportunity for confusion when trying to troubleshoot something on a page. Not that I've never done it. But I find that in cases where you would have to split up, say, a <div> and a </div>, it's generally better to put that structure into the main page files themselves, even if that means a bit less flexibility should you ever need to completely restructure all the pages. (If you foresee a need to do that, you should probably be looking at some of the templating or database-driven solutions others have suggested.)

Also, if your server is running PHP and there's no particular reason not to use .php files, I would recommend using PHP includes instead. It's really just as easy:

<?php include('/my/path/to/my/file.inc'); ?>

vs.

<!--#include virtual="/my/path/to/my/file.inc"-->

But by using PHP, you then have the option to add various kinds of conditional logic or customized display at some future date. You can also put the path into a variable at the top of the page in case you ever want to move the included files.
posted by staggernation at 4:54 PM on February 6, 2006

I second the PHP include solution. Apache's SSI has very limited built-in template logic and no ability to extend it, or write your own logic, which is something youc an do with PHP.

Also note, you can't nest SSI files more than one deep, meaning you can't have an SSI file includ another SSI file, leaving you with no ability for fine-grained file-based site architecture (i.e. Primary catories and Subcategories).
posted by camworld at 5:16 PM on February 6, 2006

Putting the sort of global items you mention (like doctype) in includes should be no problem at all, and not a management problem as long as they're genuinely global--the value or functionality is the same everywhere. I've done this in an IIS environment before with moderate traffic, it's been trouble-free.

(Except of course, if the include file itself goes missing, you could get a 500 error for every page.)

Actually, the only big red flag I see is with terminology. This isn't really what most people think of as a 'content management solution'. There could be a danger that if you want to suggest an actual CMS in the future, that management could respond with 'What, don't we already have that?"
posted by gimonca at 5:22 PM on February 6, 2006

"Also note, you can't nest SSI files more than one deep"

Depends on the server. I made some changes to my company's intranet site recently that involved #including an ASP script from the header, which in turn was #included in every page on the site.

And to address the original poster -- why so many includes? I don't see a need for more than three on your "standard" layout of top/sidebar/content/bottom. (Those three being, of course, top, sidebar, and bottom.)
posted by CrayDrygu at 5:44 PM on February 6, 2006

I've included SSI files ten deep before getting an error from Apache. It's an intentional feature, although they had to fix up the problem where "index.html" included "./" in cases where "./" is "index.html"...

I don't see a need for more than three

If there isn't a split between <html><head> and </head> then individual pages won't be able to have individual CSS and titles and so on.

I'm thirding or fourthing what everyone else is saying -- it won't cause major problems or slowdowns technically, and the browser neither knows or cares, but it's not a sensible content management solution. It's a hack.
posted by AmbroseChapel at 6:48 PM on February 6, 2006

SSI works quite well actually. You just need to accompany it with a naming convention for your includes that relate them to the page they will be appearing on. Such as:

/inc/nav_left/products.html
/inc/nav_top/products.html
/inc/content/products_overview.html
/inc/content/products_foo.html
/inc/content/products_bar.html
posted by o0o0o at 8:40 PM on February 6, 2006

can't nest SSI files more than one deep

chase doesn't say what technology they're using, but IIS nests includes without problems.
posted by normy at 1:35 AM on February 7, 2006

AmbroseChapel said : If there isn't a split between and then individual pages won't be able to have individual CSS and titles and so on.

This is where PHP could be better than SSI. You can create a PHP function for the header and pass it the title, css, and so on as parameters. That way, the whole header will be contained in one file, instead of split between two of them.
posted by RobotHero at 10:29 AM on February 7, 2006