Thanks for that Kirk
It's Framework & CMS version 3.4.1
I'm not sure that partial caching is going to help with the initial latency (TTFB) but I'll look into it.
I've tested it and it runs fine on an alternate linux hosting - which makes me think it has to do with something particular to the IIS hosting setup - I'll talk to the hosting guys about the PHP setup and see if something can be done there.
I've run debug and get the following info (which I think looks ok?)
Debug (Director::handleRequest() in Director.php:351)
sitemap.xml =
GoogleSitemapController
admin/cms =
->admin/pages
admin =
AdminRootController
Security//$Action/$ID/$OtherID =
Security
CMSSecurity//$Action/$ID/$OtherID =
CMSSecurity
dev =
DevelopmentAdmin
interactive =
SapphireREPL
InstallerTest//$Action/$ID/$OtherID =
InstallerTest
JSTestRunner//$Action/$ID/$OtherID =
JSTestRunner
SapphireInfo//$Action/$ID/$OtherID =
SapphireInfo
SapphireREPL//$Action/$ID/$OtherID =
SapphireREPL
=
RootURLController
$URLSegment//$Action/$ID/$OtherID =
ModelAsController
StaticExporter//$Action/$ID/$OtherID =
StaticExporter
RebuildStaticCacheTask//$Action/$ID/$OtherID =
RebuildStaticCacheTask
RemoveOrphanedPagesTask//$Action/$ID/$OtherID =
RemoveOrphanedPagesTask
SiteTreeMaintenanceTask//$Action/$ID/$OtherID =
SiteTreeMaintenanceTask
Debug (line 122 of ModelAsController.php): Using record #1 of type HomePage with link /
and debug_request returns:
Debug (line 250 of RequestHandler.php): Testing '$Action//$ID/$OtherID' with '' on HomePage_Controller
Debug (line 258 of RequestHandler.php): Rule '$Action//$ID/$OtherID' matched to action 'handleAction' on HomePage_Controller. Latest request params: array ( 'Action' => NULL, 'ID' => NULL, 'OtherID' => NULL, )
Debug (line 184 of RequestHandler.php): Action not set; using default action method name 'index'