Forum Moderators: phranque
Kaled.
Any "optimization" would be in the network or client-side caching, if the page is tagged as cacheable. But if it is marked as cacheable, then that's likely to be an error, for the reasons cited above.
In short, it all depends on precisely what the SSI includes are used for, and only relatively-static pages could be cached to prevent the page from being re-requested from the server each time the browser renders it, and therefore prevent the server from having to process the page on each request.
To put this in perspective, though, a modern server can parse a page very quickly though, since the SSI tokens are quite obvious and easy to discern from 'normal' page content. It's likely that the additional server load is much higher for PHP pages than for SSI pages, simply because PHP is a much more powerful scripting environment, supports many more directives, and therefore is probably used much more heavily on the page(s).
Jim
1) Each .shtml page is treated like a script and compiled into tokens. The tokens contain the original file name (and the position of the ssi instructions on the page), together with the length of the file (for validation) and checksum (if OS makes this available).
2) Each .shtml file would have an associated .ssic file containing the tokens. When the .shtml file is requested, if the date-time stamps of the two don't match (or other checks fail such as file-length and/or checksum) then the .shtml file would be parsed to update the .ssic file.
This should substantially reduce the CPU requirements for SSI.
Any thoughts?
Kaled.