bca wrote:Using XH167 the homepage was taking a while to load - over 10 tests the average time to load was 11 seconds. I cleared the browser cache each time.
Hm, 11 seconds seem to be very long. It might be worth investigating the reason for this (a very slow internet connection, a very slow server, some misconfiguration etc.)
bca wrote:I inserted an edited template stylesheet inline.
Actually, in my opinion, having an index.htm with an inlined stylesheet is somewhat bogus. Of course, that accelerates accessing the start page, but accessing any other page would trigger loading of the stylesheet nonetheless, and so the CSS would have to be transferred a second time.
Code: Select all
at the end of the html file before the /body tag.
That is somewhat I would love to see as being the default, but unfortunately that would break a lot of plugins, I presume.
bca wrote:So my question is is there an easier way of doing this?
At least there is none readily available. There is a plugin called OfflineContent (or so), which creates HTML files of all pages of a CMSimple installation, but the plugin is really old, and certainly does neither inline the stylesheet nor deal with any <script> elements.
Anyhow, it appears to me that automating the index.html isn't too hard. I would probably start with mod_rewrite so that requests to the root directory are mapped to index.html or index.php, depending on whether there's a query string in the request. That might already solve the need to fix the menu links. If that wouldn't work (what I actually assume), adding a <base> element to index.html most certainly would work.
Writing the index.html could be relatively easily been done in function XH_finalCleanUp
which is called at the end of each request. One of the problems would be that inside this function PHP has lost the current working directory, so this would have to be stored in a variable before the function is called, and then used. Before index.html would be written to disk, the HTML could be manipulated (inlining the stylesheet, moving <script> down etc.)
However, I would prefer a more general solution, namely a server side caching of the generated pages. That would involve PHP for each page request, but due to cmsimple/userprelude.php the real CMSimple could be skipped, if there is already the appropriate .html in the cache. One problem with this approach would be to automatically detect whether a cached file is stale. Perhaps that detection should best be ommitted, and instead the webmaster would have to clear the cache manually (or maybe the cache could be cleared on logout). There are other problems (for instance, to detect whether a request must not be cached at all, because it triggers dynamic behavior, e.g. form submission). And I have no clue on how much this could improve the performance. Nonetheless, an approach that might be more carefully investigated.
 Theoretically, that should be easy to solve. POST requests would not be cached, but GET requests would. However, not necessarily all GET requests offered by CMSimple_XH and its plugins are safe