Module Cache Expiration does a great surgical job in expiring just the necessary pages (the changed page and its relations) from various cache backends (Boost, Varnish, Fastly, Akamai, Acquia Purge, etc.) This is way better than clearing the whole cache after every content adjustment.
However, the few pages that are expired from cache still need to be re-cached. Far too often this happens at the expense of an unfortunate website visitor, who happens to be the first to request a page after it was expired.
There are various other cache warming solutions, e.g. Cache Warmer and HTTPRL Spider (both Drush tools), Cache Warmer Connect (employing an external caching service), or various solutions crawling the site's sitemap.xml (see e.g. this one), etc.
Recacher is different in that it is more targeted. It tracks URLs expired by Cache Expiration and then re-caches only those URLs using the excellent HTTPRL.
- First ensure dependencies: Cache Expiration and HTTPRL. Make sure that Cache Expiration works well on your system and cache backend, and also verify that HTTPRL works for you (check the Status page).
- Make sure to TICK the option "Include base URL in expires" on the Cache Expiration config page admin/config/system/expire.
- Download Recacher and enable it like any other module.
- Optionally tweak the settings at admin/config/system/recacher.
Re-caching is triggered by this module's cron hook. Typically you would want to have this process run as often as possible so as to quickly warm recently expired caches. High frequency (even every minute, or less) has no downside, because the process will not do anything most of the time. (Of course, your cron has to be triggered at least at the same or higher frequency.)
It is recommended that you use Elysia Cron or another granular cron manager so that this cron job can run more frequently than most of the other ones. If you do use Elysia Cron, make sure to set "Minimum time between re-caching" to "default" at admin/config/system/recacher.
Since 7.x-1.2 it is possible to also attempt re-caching immediately using hook_exit. This may be too fast when expiring external caches such as Fastly, Akamai, etc., but even then it is more beneficial than not. It is recommended to keep the relevant config setting on. See more at #2828873: Optionally trigger recaching via hook_exit.
Recacher exposes several hooks that can be used for tighter integration in other modules.
Re-cached URLs and their response codes can be reviewed via watchdog messages. This depends on the selected configuration (only failed, all, none).
Note about compression
Recacher sets its "Accept-Encoding" header to "gzip". This is what the vast majority of browsers do as well. GoogleBot requests compressed content, too.
Should there be demand for warming cache with non-compressed content, please raise feature request in the issue queue.
It appears that non-browser crawling agents (such as cURL, Wget, or Googlebot, but also HTTPRL that is used by Recacher) will not see a cached version of Authcache ajax blocks unless the (evil!) Drupal core cookie "has_js" is removed. Fortunately there is the excellent little Force JS module that can do it for you — much recommended. ( See #2692075: Not working with Authcache ajax blocks)
Let's make this module better together! Ideas, patches and inspired co-maintainers welcome!
Project page and download
cache Drupal PHP module performance cache warming Varnish Fastly expiration