I've spent a little time on a very basic FileMaker solution that loops through all of the links in a list of xml site maps. The goal is to get the pages in the site map loaded into the web server cache – a practice known as priming the cache.
This started with the move from a website powered by a CMS (Movable Type) that generated static html site files to a dynamic website driven by Concrete5. So far Concrete5 has been great but the speed, while very good, doesn't seem quite as fast as the insanely fast speed of the old static pages.
Cached pages are faster, but they only get cached after they are viewed. On a busy site with a lot of traffic that would probably be enough – all pages (even on a large site) would be visited and cached relatively quickly and most visitors would be getting the faster cached pages.
It's a little different for a niche site that gets less traffic, especially one that is undergoing changes and content additions. That often requires purging the cache (restarting Apache or the server purges the cache too) which means that the first visitor to each page will be getting slower un-cached performance.
So the goal is to pre-load or prime the cache by visiting all pages and moving them into the cache. There are definitely some existing ways of doing that, like wget or curl-loader, but it seemed like the latest versions of FileMaker would allow for the quick creation of a cache priming solution that would allow more granular control and greater functionality.
The first version of the FileMaker website cache primer/loader is available on GitHub. It is very, very basic. The goal was to get the absolute minimum functionality in place and add to it over time.
Minimum functionality means the ability to prime/load the website server cache by calling all of the pages on a list of xml sitemaps. It requires FileMaker 12 or greater as it relies, at least for now, on the Insert From URL script step. That step is used to call the page, which the server then loads into the cache.