The System Audit Info page is usually the first place I go to track down performance issues... From here you can enable tracing on the search cache, schema, database, IdocScript, or overall request time. If you enable verbose requestaudit tracing, you'll usually get stuff like this:
>requestaudit/6 02.10 21:47:48.528 IdcServer-2442095 SS_GET_PAGE [dID=123] [dDocName=SITE_FOOTER][dDocTitle=My Footer Content][dUser=guest][dSecurityGroup=Public] 232.53741455078125(secs)
Woah! One single Site Studio page taking almost four minutes! It would be nice to know what page that was... unfortunately, as you can see the information in the log is not all that helpful. Although the dID and dDocName are in the trace logs, you can tell that these are the dID and dDocName for the last item rendered on the page: the global footer.
In order to dump out more useful information, we need to use the magic flag RequestAuditAdditionalVerboseFieldsList, like so:
Once this is set, the dump would look like this instead:
>requestaudit/6 02.10 21:47:48.528 IdcServer-2442095 SS_GET_PAGE [nodeId=9876][siteId=MySite][dID=123][dDocName=SITE_FOOTER] [dDocTitle=My Footer Content][dUser=guest][dSecurityGroup=Public] 232.53741455078125(secs)
Now that we know the site and the node ID, we can track down the offending page with an explicit SS_GET_PAGE call:
Once we know which page is causing the ruckus, we can audit the code on that page to look for anything that might slow down the whole system.