So actually I think the issue is more related to the number of characters in the XML document. Setting models to load after page load did not fix the issue, but removing 17 (semi-unnecessary) models, each with 50 conditions, did fix the issue. 

Is it possible that Salesforce is now limiting something with the number of characters in a long text field that can be queried at one time? 

I was getting close to the limit in Spring '18, hit it a few times and had to remove models, etc to get under. But in Spring '18 don’t have any issues with the same page that fails in Summer '18. 

Another thing that may have had some impact - I was seeing the page load for internal users and not for external (Customer Community) users. I noticed I had several conditions referencing page parameters that were not being provided. Removing those seemed to help, not sure if that makes sense since the condition should have just deactivated. It might have also been a persistent caching issue. 

The page I got working yesterday is not working today. Anyone else having an Apex CPU time out issue?

I have heard of other client’s experiencing this, but I haven’t seen anything specific on it. Do you mind sharing the page that is giving you the problem with me? The XML limit is quite long… Feel free to email me the XML. Also, by chance, are you seeing it anywhere with just custom objects (unashamedly hoping).

What’s your email? 

What do you mean by ‘just custom objects’, like standard classic/lightning Salesforce pages for custom objects causing Apex CPU time out?

Stephen, here’s a link to download two xml files. One labeled with _Backup is the one that was causing time out pretty much every time, internal and as customer community. the second one labeled with _New still occasionally causes time out issues, but less so, and only with Customer Community users. 
https://www.dropbox.com/s/8uln6ndf4l50ait/Archive.zip?dl=0

Thank you for giving me access to the XML. I’m unable to reproduce what you’re seeing in my org but I’m not surprised given the amount of __c I see in the XML.

When a page approaches this size and complexity, I would highly recommend looking for ways to break it down so that some of the page’s contents are contained in Page Includes. Moving some sections into separate pages, and then including those pages via the Page Include component can improve the performance of the page overall, avoiding issues like the above, and it can make it easier to add and manage content. 

For sure. We’ve actually done that, just haven’t deployed yet - we ended up creating (up to) 38 models dynamically using a snippet, much more elegant. 

Still strange that on Spring '18 no issues, and on Summer '18 issues. Makes me nervous when I don’t know what changed. 

However, it helped spur much needed refactoring of the page, so all good in the end.