We tried to enable the page output cache on our Intranet (O365) but didn't not get any performance improvement. We enabled the debug and noticed the following message “8 Output cache not used. Reason: User can view an unpublished version of the current page”. We would like to be able to set the CacheForEditRights settings, but this is disabled through web.config settings. The link to the Cache Profiles list is also hidden online, but we were able to create a new profile anyway with this set (Allow writers to view cached content).

Since there's already a check if the page is not in publish state and the user has edit rights on the current web I'm not sure why the check is needed. My guess is that it’s for content by query-web parts showing old data? From my understanding there’s a check if the user has any edit permissions somewhere on the site collection. Is this check on web level or list/folder/item-level also? I made a PowerShell which checked my regular user’s EditListItems-permissions on all webs on our Intranet and made sure to remove them but still have not succeed to get a cached output.

Since we have project sites e.g. available most users have some edit rights somewhere on the site. It would be great if the forced settings in web.config would be removed since we prioritize the page load improvement over the sometimes perhaps “stale” data showing.

Also, there's a lot of requests being made for O365 which occurs for each page request which should be cacheable (localStorage or cache headers), e.g. SuiteServiceProxy.aspx. GetOwaUserConfiguration. GetPersonaPhoto, SearchCenterUrl. These should be valid for some minutes at least since they contain basically the same result over and over again.

We would appreciate any help to allow us to reduce the page load. As always, any reduced amount of requests would be welcome (minification / bundling) since there’s over 70 request being made on a fresh load.

FYI, we don't use any custom master. We have the “donut” cache set up for our content by search web parts. We've tried disabling navigation to exclude the navigation as the culprit but without luck. Also “basic pages” / article pages without any query web parts feels like they need a boost.