I'm not sure why anyone would use old-hat SSIs when we're at a point now where countless more robust solutions exist. Particularly, solutions that can provide the dynamism of SSI and the performance improvements of static pages via smart, easily-configurable caching.

Firstly, the performance argument is ridiculous. Do these people think every page on Facebook is a static HTML file somewhere? Of course not; it's a combination of highly-dynamic information and cached rendering of static/unchanged data; it could not function otherwise.

Secondly, using client-side Javascript for things like including footers or changing a copyright date is simply stupid. If you need to offload something like that to the client you've got some serious problems.

Basically, anytime a developer says SSI is not the way to go (in favor of purely static content, i.e. copying and pasting a footer onto each page of a site) they are wrong. Always. Take Wordpress for instance. Everything is dynamic and performance seems practically an afterthought, but there exist caching plugins that take those dynamic pages, save them as static files, and show those to the user until they expire. Instantly, the best of both worlds. A large number of web frameworks now exist that allow you cache your entire site with as little as a single line of code!

Moore's Law should make it pretty obvious why it is always better to put developer performance before hardware performance: The latter continues to increase whereas the former will, at best, stay roughly the same over time. If I needed to edit 20 files to change a copyright date in the footer of our site, I would never get anything done. And I would have lit myself on fire by now.

Honestly, just reading about SSI in this day and age makes me think I'm back in 1998. To think people still believe dynamic content generation/inclusion does not provide adequate performance for a high-traffic site is... preposterous. Moreover, that people believe that about a system such as SSI -- one which couldn't be much simpler or better performing on average -- is... I don't know; what's a word for something more unbelievable?

The only time I have used SSI post-1999 was actually very recently, in an environment where I was supervising the development of 7 semi-independent websites (all developed by other people) that all needed to be tied to each other through a common navigation bar. The server was Windows/IIS/nothing/ASP, so I ended up making the navigation bar an asp file and having the other, inexperienced developers call in the file with a virtual SSI. It was honestly easier than having them do about anything else, even though I would have much rather used simple ASP to call it in.

So, there you have it. SSI is now a kludge for solving problems that are a result of poor planning, inexperience, or both. I honestly can't think of another reason to use it, now that we have incredibly dynamic tools at our service.

As others have mentioned, server-side includes are rare these days, but it's not for performance reasons, as far as I know. Most sites these days are using at least some basic PHP, ASP, or what-have-you and those languages all have built-in methods of including files, rendering SSI unnecessary. It still does the same thing--including a file that is hosted on the server--but the technology is different. If another server-side language isn't in use, I don't see any reason not to continue using SSI to pull in files.

I'll try to present what I believe both of the previous commenters were trying to convey, before they got side-tracked by blindly bashing SSIs:

If something like PHP, ASP, etc. is already being used, there's no reason to use SSIs.

Now, what they didn't say: If you're just making static HTML anyway, SSIs are fine. They have much higher performance than invoking PHP or ASP to do what would essentially be the same thing. For a small site, even this "much higher performance" would be trivial, but for a very large site, it could well add up.

That said, it's likely that for very large sites, they are using some sort of server-side scripting (be that PHP, ASP, ColdFusion, Python, a monkey with an abacus, or whatever else)- so SSIs don't make sense, because you already have the overhead of something that can do them.

The one final valid use-case left over is for small sites with administrators that don't want the complexity of managing something like PHP or ASP. In this case, SSIs tend to be much easier to configure (in most server software, you just need to turn them on), and if all that's needed is the sort of modularization you mentioned, then they're sufficient.

Static HTML is the fastest

Include files may require the server to access and process the files. Still blazingly fast. SSI probably do less processing then PHP includes but both are very quick.

Any content management system based on templates will be slower still (but much more flexible). Wordpress, Joomla, Drupal, etc are all quite quick.

Unless you're site gets over a 100,000 hits a month server performance will not generally be an issue in terms of any of these techniques. Your performance will be more gated by bandwith and file-size.

Meh, i use php includes.

I echo other readers' comments regarding how SSI in the traditional sense (to include headers etc. in static HTML pages) is somewhat old hat these days. It's a rare web server that doesn't allow a bit of PHP or ASP, and using either of those languages to output a site allows very easy including of this over-arching content. Obviously every change away from static HTML does add another performance hit, but unless you're running a high-traffic website from a calculator with Linux installed I doubt it would be an issue.

The main performance hit these days is with badly written SQL queries (or more particularly a site that uses a ridiculous number on every page load). Some generic CMSs I've seen use 20+ queries every page load, and without caching this is where a performance hit might actually become evident. So keep the queries to a minimum, cache what you can and don't fret about includes.

With all of the CMS options out there right now, I haven't even thought about SSI's much. I find myself in Joomla or Wordpress for the most part these days.

There's a time and place for SSIs. I still use them on smaller HTML sites where I want to include a global element. If the site is already using PHP, then of course I'd just use a PHP include. I doubt the performance issue of SSI vs. PHP matters on these small sites. I don't want to use a CMS for every project. If I did, I'd spend more time doing security upgrades than I would developing new sites.

Thanks for such a nice information about SSI. It seems they have gone the way of the splash page.

I've never used an SSI, just PHP includes and no I've never had a performance issue even when including 10-20 files.

SSI are great. We had our full navigation in ssi at one point. It allowed us to easily edit the navigation without touching the text and vice versa. High traffic site with several thousand pages. And we used htdig as internal search engine, just searching on the content pages. Each content page pulled the appropriate navigation based on from where it was called and hierarchy / taxonomy. Fan-tas-tic! The dynamic pull of the ssi was heavy on performance, but using ssi just like that is very fine, imho.

SSI is new for me, just use php and mysql with a cms. Good article!

Thanks for good article and good discussion :) was interesting read... i am using php includes on all of my web sites, even at some that get 4000+ uniques a day and include 10+ files per page and it works fine for me :)

Dejan M.

Yeh, I always use php includes and mysql for a cms. In fact I just published one at my blog. Although its not that great, as it is several of my scripts clumped together :D This was an interesting article though.

Thanks for good information through this article

I use PHP includes and active page indicators in almost all of my websites. I've only been doing websites about about 15 months, so all these old school SSI techniques are not really relevant to me :)

Our shop uses SSIs for smaller sites all the time. No real performance problems, even for sites that get 100,000s of hits a week. It's a really useful way to make things easy for our "non CMS" sites. Never bought into the "performance suffers" bash- much easier to tell a client that their site may display a couple hundredths of a second slower than to tell a client changing their footer will take 3 hours...

What CMS spits out static pages? I can't think of a single one.

'site.com/pages/article/1' isn't necessarily static. It's most likely using php, or whatever server-side language the CMS uses, to populate the content and pull from a global array of parameters (header, footer, links, copyright, sidebars, etc)

Not exactly static but if you use Drupal and the Boost module, you can create "static" HTML pages of your nodes to reduce server load.

We've actually very effectively used server-side-includes on very high traffic websites!

Our use is somewhat different from the norm though.

But we use it as a part of our caching algorithm. If a page only contains static content, we serve it via memcached and does not even touch the server (In our case running RubyOnRails). But on more and more sites, we have login and session functionality which is really really hard to effectively cache (if possble at all). In these cases - for instance for "You are logged in as xxxxx" texts, etc. - we use server side includes.

The cool thing about SSIs is that they can be cached by memcached as they're just text until it's served. So we load dynamic parts (or fragments as we call them) using cached server side includes texts on already cached pages! The result is that RubyOnRails (in our case) is only touched on the dynamic parts of the page.