SSI would be processed on your server, not over the client connection where JS lives. That said, it all depends on what you want to do and how processor intensive it might be. One reason I still use Perl.

If you're including a static file, I wouldn't worry about it.

SSI includes are no slower than any other file requested from the server, e.g. image files, css, etc.

Depending how they're used in the mark-up could affect rendering, but again, every file does that.

The benefits in editing management far outweigh the hit on resources.

Yes these ssi's contain very little info, i.e., header, footer, logo etc.

Thanks for the info.

SSI includes are no slower than any other file requested from the server, e.g. image files, css, etc.

Depending how they're used in the mark-up could affect rendering, but again, every file does that.

The benefits in editing management far outweigh the hit on resources.

What you're suggesting is simply impossible from even a rudimentary computer science standpoint. The processing work a given instance of web server software must do to serve a static file is negligible; file open, connect the input file handle to stdout output handle, pass the data through as it is read. The processing work web server software must do when server side includes are enabled, and the request is for a file containing the specified extension, is apply a pattern match against a sliding window of five characters looking for the presence of <!--#, then when found, continue reading to see if a valid SSI directive is present, if that is found, then execute further code to process the given directive. It has to do this for every single file with the enabled SSI extension, whether that file ends up containing SSI directives or not. Strictly from a processing standpoint, those two things are significantly different amounts of work, and any additional work any type of software does means decreased performance.

A modern web server would hopefully has some optimal type of web server software in place in front of whatever is required to parse SSI, nginx vs apache for example, so the penalty for enabling SSI on a commonly requested extension is not an insignificant amount, especially if we're talking a high traffic site.

You'd be much better off making SSI files have a unique extension so that the back end SSI-enabled web server only sees the request when it is for a file that would contain SSI tags, and then only parses the document for SSI when that SSI-specific extension is present. If SSI is only being used for includes, could just iframe it instead, then the visitor can request it in parallel with all the other content in the page.

SSI was (and apparently still is) often used as a sort of templating system that works with otherwise static files. Instead of duplicating a header in every web page, you include a file that contains only that header, and so updating a header, footer, or any other commonly used code, becomes a breeze. That's a process that needs to happen server-side, an iframe (client-side) cannot realistically serve the same purpose.

I do agree that, ideally, any files containing SSI directives would have a different extension, like .shtml, that is recognizable to the web server, to prevent unnecessary processing. Even so, it's likely less expensive than if you were to hand the job to, say, a PHP parser.

Welcome to WebmasterWorld, by the way.

a different extension, like .shtml, that is recognizable to the web server, to prevent unnecessary processing

Sure, if some of your files have includes and some don't. (And even then, you can often do the X-bit Hack thing instead.) But if all of your existing files are changed in one fell swoop to use includes, there's no need for a different extension--especially if the changed name would require redirecting or rewriting, which is another kind of work for the server.

Fair point, especially if it's used for things like headers and footers, you'll probably want to process all HTML files. The processing power required is negligible anyway.

the X-bit Hack thing

That sounds amazing. A quick search returns a page from 1999. It did have a 90s ring to it, though it may have been the rapper I was thinking about. This thread is a time machine.

With SSD and HTTP/2 everything is so fast I don't worry about those extremely slight processing differences.

Personally, I often use HTML files in my Includes so I don't have to add Handlers for extra file types. HTML w/ CSS is also the easiest (for me) to control presentation so it seamlessly fits into my markup.

Hi sysadmMgr and welcome to WebmasterWorld [webmasterworld.com]

Thanks! I am more involved on the application coding side of things so spend a lot of time digging through code optimizations in web apps; sometimes boring work trying to reduce execution by a fraction of a second here or there lol. The 'slow down the server' part of the thread title caught my eye; hadn't seen SSI in a while because I generally want static content to be served by something that can't even parse for SSI, which would necessitate using some other technique for common elements that cross files if you don't want to send the request in for heavier lifting.

This thread is a time machine.

I did Xbit blahblah for a brief time, when I had started to use SSIs in some directories but not all of them. I think it's in the Apache docs buried somewhere in the SSI HowTo page (which is surprisingly readable, as Apache documentation goes).

Just to clarify I use txt files as the SSI's and the content of the files are all simple html. Nothing complicated. And all the pages have at least 3-4 includes (header, footer, nav). These are all static pages.

I use txt files as the SSI's and the content of the files are all simple html.

No difference between using text files w/ html code or just using html files as the include.

But using html files, I can (could) use an html editor to preview the code and see if it renders like I want it to.

Got to ask ... what kind of nano seconds v volume are we talking about to introduce any measurable deficiency? Even in the event of setting SSI to a dedicated extension the server STILL has to read to see if it exists. Color me not impressed. MEANWHILE the iron on which we run has gotten so much better and the server software that much quicker and leaner (re: resources).

An SSI is whatever you want it to be. (Server Side Include)

Apache knows the extension of the file requested because it was in the request, unless a rewrite was involved, and it still knows what it's going to ask the operating system to read before it does so, even if there is a rewrite, so if SSI's use a dedicated extension, it will know whether or not it needs to parse for SSI tags before it opens the file.

Regardless, we're definitely not talking nanoseconds of difference. I turned on mod_include and added an SSI extension; it seemed to incur just under a tenth of a second penalty. However, there's more to the equation than just SSI on or off. If it's off, it enables what would have been SSI-parsed files to be served as static files, by a web server with a more optimal configuration for static file serving. For example, if you can have those now-static files served by an optimized nginx, versus having to pass them back to an SSI-enabled apache, you're likely going to see as much as three tenths of a second cut off the overall request time, less memory footprint, dramatically more connections per second, so on and so forth.

Apache's own documentation says SSI without a dedicated extension is a bad idea:

[httpd.apache.org...]

The thing to keep in mind is that, by doing this, you're requiring that Apache read through every single file that it sends out to clients, even if they don't contain any SSI directives. This can slow things down quite a bit, and is not a good idea.

It goes on to outline even more downside to using SSI:

In its default configuration, Apache does not send the last modified date or content length HTTP headers on SSI pages, because these values are difficult to calculate for dynamic content. This can prevent your document from being cached, and result in slower perceived client performance.

The ways around that are xbithack, as mentioned earlier, or setting your own expires times.

Strictly for including content, I'd still say a simple iframe or similar would be better given the performance gain to be had, whether it's a small site just fighting for TTFB to help with Google, or high traffic where reducing load starts to matter.

Modern web servers using event based notifications for read and write can handle tens/hundreds of thousands of connections trivially. The other week I wrote something very basic that could transfer 2GB/s on my local (not very good) laptop using epoll with a couple of hundred lines of code. Serving static files as-is is definitely optimal, but for maintainability if you were truly serving static stuff, why not throw it on a CDN and forget about perf.

Turning SSI on means your web server has to scan those SSI enabled files byte by byte. It will be orders of magnitude slower. As mentioned, if you restrict the server to only consider files that actually do have SSI includes in them, then the optimal method remains the same for everything else.

SSI will be faster than using some other scriping language on the backend of the server.

The XBitHack was pretty cool in that it prevented the need to change URLs on the front end.

Unless you're serving hundreds of thousands of requests a day or trying to fit something into a very small hardware footprint, the question is not worth a huge amount of deliberation wrt performance, your time and anyone else working on the site is probably worth more in terms of gains.

Someone else told me they thought the SSI's were slowing down the server. I haven't figured a tool that measures the SSI speed. webpagetest doesn't that I can see.

An external resource would have no way of measuring the impact of SSI. For time to serve the files specifically, you'd need to test what you have, then disable SSI completely on the server, optimize for static content serving if any config changes are warranted as a result, and re-test. Server resource consumption differences could only be measured by a/b testing with SSI on or off and the same live traffic hitting it for some period of time while the measurements are collected.

You could use something like ApacheBench (ab) to test two versions of the same page, one with the SSI includes and one with SSI disabled (via httpd.conf or a .htaccess file). Couldn't find any benchmarks, and I don't have an active Apache installation anywhere, or I would have run a quick test for you. Maybe just get the person who told you to prove it ;-)

The pages I always use SSI's on are all hand coded (no code bloat) static pages, with images optimized, minimal JS, and g-zipped, with page speed always in mind. I can see where using another method might be very important for a shopping cart, but I don't see it as an issue on small static pages.

Apache's own documentation says

Well, Apache's own documentation says a lot of weird stuff. For example, they infamously say that you should make your redirects using mod_alias rather than mod_rewrite, which for most people ranges from a terrible idea to flat-out impossible.

you're requiring that Apache read through every single file that it sends out to clients, even if they don't contain any SSI directives

That’s a pretty iffy “even if”. On most sites, if you use SSIs at all, you use them everywhere. (Pawing through my html files, the only page I could find that doesn't have at least one SSI is the custom 500 page--which also uses no stylesheets--on the obvious grounds of “the server has got problems enough, thank you”.)

I guess you could rewrite selected html files to shtml, but that too creates work for the server.

I've always used SSI for site nav, header, footer as it makes SENSE. However, these are static sties running for a few hundred to perhaps 20k pages, and while having decent traffic (for the niche) are not in the hundreds of thousands or millions per day category. I've never encountered any problems with SSI, that's why I asked. :)

I don't see it as an issue on small static pages.

The "someone else" could very well have been wrong in his assumption that it's SSI slowing you down. Is anything even slowing you down, you think? Is the server under stress?

One rather rudimentary way of testing his hypothesis, assuming you have a stable connection, would be to open the network tab of the developer tools in your browser, load an SSI-enabled page on your site, reload it a couple of times and jot down the Wait or TTFB time of the document (disregarding any other resources loaded). Then you would do the same for a static resource, i.e. anything that doesn't involve SSI or another type of server-side processing, like an image or a stylesheet or whatever. Comparing the averages of both should give you a basic idea of the additional processing time required for these SSI-enabled pages.

Or you could have Apache spit out the processing time as described here [prefetch.net].

re: is anything else slowing you down?

According to the webpagetest site there are no glaring problems. The page in question is loading under 3 seconds. It was loading at 1 until we added hundreds more words recently.

Hundreds or even thousands of words are not going to add seconds to your load times.