I've tried reproducing the error in a different environment in several ways, and in my latest attempt I have exported your Types content using Toolset > Export / Import. That includes your custom post types, custom fields / RFGs, post relationships, taxonomies, etc., so the Toolset structures are pretty close to identical to yours. I've imported that content in a sandbox site and set up some test posts. I'd like to ask your Safari Users if they will please log in and tell me if they experience the same slowness.
I will provide login credentials and a URL for editing in the following private message.
Also - can you tell me if there is a debug.log file on the dev site at the destination hidden link? I see a 403 error when I try to load that file directly in the browser, which is often normal depending on the server security settings. You may need to check for a debug.log file in the /wp-content directory with FTP. If a log is running there, I suspect it is quite large. If that is the case, please delete the file using FTP and then edit this post in Safari:
hidden link
After editing the post once or twice, check for another debug.log file, and please send me its contents if one exists. Let's see if that has any impact on the front-end slowness experience with Safari. I doubt it will, but I'm just trying to cover all possibilities as there were some PHP notices generated by these field conditions in my local environment. I have implemented a minor change in the RFG field conditions to prevent those notices. The field conditions for some of the nested RFG fields were:
Meeting / Activity Type = 1
OR
Meeting / Activity Type = 3
I've adjusted those to use one condition instead:
Meeting / Activity Type != 2
This seems to have resolved the notices in my local environment, without negatively impacting the field conditional functionality.
Hi Christian, thanks for continuing to delve into this. There is no debug.log file being generated or present in wp-content.
The Safari user encountered the slowdown on the sandbox site. The other one who uses Safari is on vacation, so she can't test. I tried the Sandbox site on my Mac+Safari and encountered the same 70+ second delay. Here is a link for the Timeline recording file: hidden link
The password is the same as what you set on the sandbox site for us.
Also, my Safari popped up a warning "This webpage is using significant energy. Closing it may improve the responsiveness of your Mac." which usually happens from a runaway js script. I hadn't seen that message on our staging server yet.
Okay thanks, I am looping in my 2nd tier support team because I'm stumped. We've had a similar report in the past, but like in your case we had difficulty reproducing the issue: https://toolset.com/forums/topic/performance-of-repeatable-field-groups-with-conditional-fields-on-safari-browser/
In your case I was able to see the issue a few times in your site (but not my local OR the sandbox, for some reason), and we now have timeline information I can pass on to our developers for additional analysis. I'll let you know what I find out from my 2nd tier support team as soon as I have some feedback.
Thanks for the update! Hopefully they can find the cause.
