To further improve loading performance for webpart loading, the following caching mechanism has been developed for webpart rendering.
- When a new webpart is placed on a page, the very first render will always be a live render from SharePoint list data
- At the same time, the app will take a snapshot of the graphic
- The next time the same webpart renders, the app will display the snapshot if there is one available
In the following situations, the app will discard the snapshot and display the live version of a graph, and cache the new result
- Google maps cannot be snapshot, because it involves loading map data from Google servers live
- Item universe will not be snapshot, because the nature of this graph is to provide interactivity to users
- The app uses an internal list to store the cached data, when caching happens, the current user must have at least “add item” permission to store the cached data. In general, if you can save/publish graphs, when you load a webpart, the app will cache successfully. Readonly users will see the live version if no snapshot is available.
- If the list data has been modified since the snapshot was taken
- If the graph’s configuration has changed since the snapshot
- If the size (height or width) of the webpart has changed
- If a list contains items with unique permissions (with permission inheritance broken), the graphs created from this list will not be cached. The reason being, with items with unique permissions, different users may load a different sub set of data from the same list, hence the correct graph for one user may be incorrect for another user
- In addition to the above, all snapshots older than 30 days are discarded.
This caching mechanism is automatic, and it is switched on by default, however, the user always override this configure the graph to never cache.