When I use the phrase server side processing (SSP) I am refering to what is commonly called SSI or server-parsed html, or a number of other things. What these all boil down to is that the server parses the HTML file, looking for magic strings that cause it to add content or remove from the HTML that is going to be delivered to the client.
Typical uses for SSP are including the current date, the date the file was generated, the clients login name, visitor counters, or selecting alternative text based on the HTTP headers of the request.
To see how useful these things are, notice that the two are things the reader already knows, one is at best a useless brag, and the final two generate documents that don't change when you reload them.
The last sentence reveals the fundamental problem of SSP. The useful things done with SSP are are static, and could have been generated when the document was generated. Parsing a source document once to generate the documents actually served will use much less CPU than parsing the document every time it is served.
To select between documents, having the server select between static documents (as with the aws module headerfilter) takes much less CPU than parsing the HTML as it passes through the server.
Further, SSP doesn't work with caches. If the document is cached (and there is no universal method for disabling this), users start seeing the wrong version of the document. For the cases where the document is not cached, it must be refetched - even if unchanged - for every load. This increases the network load across the entire network. Until the average end-user bandwidth starts going up instead of down, this will be a bad thing.
SSP appears to serve no useful purpose which pre-processing documents cannot provide. Further, it causes both extra CPU usage on the server and extra bandwidth usage on the entire network while doing so. As such, it is best avoided at all costs.