Web Parts Caching - Why, How and When – BindTuning Help Center

SharePoint Online Caching Limitations

SharePoint Online is distributed over the cloud and the number of web servers that build this network makes caching content queries unfeasible. Information on SharePoint Online’s caching limitations can be found below:

SharePoint Caching Objects.

Since content queries can be a bottleneck in performance, we devised some strategies to store list content in a place where the information can be stored and retrieved relatively quickly so the content queries can be removed altogether from the Web Parts. Two viable options were found for this:

Page Caching: Store the content somewhere on the page.
Local Storage Caching: Store the content on the browser’s local storage.

Page Caching

This option avoids the content queries by saving the Web Part’s HTML inside its script editor. This way, when the page is loaded, the entire structure of the Web Part will already be there practically ready to be shown.

When this option’s enabled, you should think of the content on the Web Part like any text or HTML typed into a SharePoint page. This content will not update on its own, you will need to Check Out the page if necessary and Save the Web Part once again for changes to take effect.

Note: The content is on the page as soon as the page loads, but some processing still takes place to bind certain events to the Web Part. This shouldn’t have too noticeable an impact on the performance but can explain if loading is not immediate.

Cache refresh mechanism

With this option enabled, the content should be treated as living directly on the page just like any static content. In other words, if the page requires to Check Out for editing, you must check out the page for any changes to take effect.

The Web Part will update in the following situations:

The Web Part properties are saved
A new item is added using the Web Part’s custom forms
An item is edited using the Web Part’s custom forms
An item is removed using the Web Part’s controls

The Web Part will not update in these situations:

A new item is added directly to the list
A list item is edited directly from the list
A list item is removed directly from the list
The Web Part’s list is edited from another Web Part

Limitations

With this option, the Web Part content lives directly on the page. Whatever is stored using this cache is visible to all users who view the page. Some features were designed to be dynamic in nature and storing the results on the page doesn’t make sense. For example, it’s important for a Weather tile to show current information. Having to save the Web Part every time we want to check the weather can end up requiring more page loads than a simple google search.

As a result:

Items with user targets will not be displayed
Users who lack access to one of the lists will see the content anyway (except for dynamic content)
Weather, Twitter, Power BI and Smart Tiles are not saved. These individual tiles will take time to load but the Web Part will load instantly.
Smart sliders still retrieve content from the list so the main bottleneck remains. There’s little improvement to performance in this instance.

Recommended Uses

This sort of cache is recommended for the following situations:

Web Part content will suffer little to no changes over time.
Changes to content will be made directly on the Web Part.
The list won’t be shared with other Web Parts.

Local Storage Caching

This option avoids the content queries by saving the Web Part’s HTML on the browser’s local storage. This storage is marked as expired if any of the connected lists has suffered any changes. Once the Web Part’s files finish loading, the HTML is retrieved from the local storage and it gets injected into the page. This takes some processing so it’s not as fast as the page cache, but this one has fewer limitations. The content gets immediately injected onto the page even if it’s expired. This is to avoid having the Web Part waiting the 2 or 3 seconds it takes to retrieve content from a list before showing any content. After the content is shown, if the content is expired,the Web Part retrieves changes behind the scenes and updates the local storage. What happens next depends on the Refresh Cache option explained below.

Cache Refresh Mechanism

With this option, the cache is updated automatically if the list suffered any changes since the Web Part last checked. The update occurs after the content has been loaded so as not to interfere with the performance of the page load or the loading perception.

The expiration check is done while the Web Part loads and then every 30 minutes if the page stays open.

Below are the steps for the caching mechanism:

The local storage information is retrieved.

If it doesn’t exist yet, the Web Part is loaded normally. After loading, a new entry will be saved to local storage to be used on the next page load.

The stored HTML is injected and displayed on the page.
The Web Part retrieves the last modified date from the connected lists.
If the cache is expired a new request is made to the lists to retrieve the latest data (after the Web Part is loaded).
Once the data is retrieved, the new HTML is saved onto the local storage.
What happens next depends on the Web Part option:
- Automatically:
- Manually (Button):
- On page Load:
A 30 minutes timer is set to revalidate the cache.

Limitations

Browsers have limited space available for local storage per domain. For IE9 it seems to be 5mb on win10. Because of this limit, it’s possible to run out of space if you have too many applications using local storage on your intranet. If no more storage is available, the Web Part will simply not store anything in cache. Note: This cache lives on the client’s browser. The cache may be updated on one browser but not on another for the same user.