Power Pages: Many Layers of Caching

What is Caching?

Caching is the technique of storing the output of an expensive operation so that the next time you need that output, you can just use the value you stored, instead of performing the operation again.

There are many reasons an operation may be considered “expensive”. It could be a complex calculation that takes up computer resources. Or, and this is probably the most common thing that causes something to be expensive when it comes to developing on the web, it’s that the value is coming from a different server. The time it takes for the request to go to another server, and then come back, usually makes it expensive.

The main challenge with caching is what happens when the output of that expensive operation changes. If you simply rely on the answer you’ve remembered, you are now dealing with stale data. At some point, you need to forget what you know and get the updated value. Knowing when to do that is an imperfect science.

The goal of this post isn’t to solve the world’s caching problem. Instead, it is to make you aware of the various layers of caching that exist for a Power Pages site so that you don’t waste your time debugging something that is only broken due to a stale cache.

Server-side Power Pages Cache

This is the big one. This is why the podcast is named Refresh the Cache. If someone is talking about caching in Power Pages, this is probably what they are talking about.

The architecture of Power Pages follows a pretty standard setup for a web application – a web server that connects to a database (in this case, the database is Dataverse). The server-side cache is a cache that exists between the web server and Dataverse. When the web server makes a request to Dataverse, the result of that request is stored in memory, and the next time that request is needed, the result is returned from the cache (assuming the cache hasn’t expired), instead of making another request to Dataverse.

The server-side cache typically expires after 15 minutes. Depending on what types of data is being requested (configuration data versus business data), how it is cached may be different. I’d recommend checking out the Microsoft documentation for more details.

To manually clear this cache, click the Preview button in the Power Pages Design Studio, or use the clear cache buttons available at [your portal url]/_services/about if you are logged in as an administrator.

While there are lots of areas that I could go into on this particular type of caching, I feel like this is a topic has been well covered over the years, so let’s move on to some of the other caches that you may not have considered.

Header/Footer Output Caching

When it comes to rendering a Power Pages site, a particularly expensive operation is generating the header and footer. It’s expensive because it generally requires a lot of Dataverse queries to render elements like menus, and because it needs to be done for almost every page.

To assist with performance, Power Pages has a special layer of caching just for the header and footer called output caching. This caching layer means the header and footer don’t need to parsed and rendered for every page request.

You can disable output caching for the header and footer using Site Settings, but I would caution you against doing this. It has a pretty significant impact on performance.

Often, I see people disable the output caching when they are attempting to build custom per-user logic into their header. With the output caching enabled, any per-user logic won’t work by default because the header will be cached based on the first user to browse the site. However, there is a way to solve this problem without disabling output caching. Instead, look into the substitution Liquid tag, which allows you to disable the output caching for certain parts of your template.

If you make changes to your header or footer web templates, you can use the same techniques (Preview button or /_services/about) to manually clear the output cache.

Static Variables

This one is a little more obscure.

I mentioned earlier the Power Pages architecture includes a web server. This server is running an ASP.NET web application (if you’re interested in looking at the code, or at least a version of the code from 2017, check out the xRM Portals Community Edition, which is a GitHub repository created by Adoxio of the source code Microsoft released).

There are certain settings, primarily related to authentication, that are loaded into static variables when the web application is initialized.

If you change these settings, clearing the server-side cache doesn’t help. Instead, you need to restart the site via the Power Platform Admin Center.

So, if you’re ever changing authentication settings, and it seems like your changes aren’t being reflect, try restarting the server.

Browser Cache

After the server-side cache, the browser cache is the one I see cause the most problems.

This isn’t specific to Power Pages – all browsers implement a caching strategy to reduce network requests to improve the time it takes to load a web page. For the most part, it works fine. But for developers that are making lots of changes over short periods of time, it can cause some pain.

I typically see most browser caching problems with CSS and JavaScript files. Browsers generally assume these types of files aren’t changing that often, so they’ll cache them for hours or days.

When I’m building a Power Pages site, I find the best way to avoid browser cache issues is to have the browser’s developer tools open. On the Network tab, there will be an option to disable cache. I’ll always have that checked, so that I don’t have to worry about the browser remembering old versions of my files.

Another option, if you suspect browser cache to be an issue, is to check the site using private/incognito mode. This should also not use any previously cached versions.

Content Delivery Network

A great feature that Microsoft has added to the Power Pages product is the Content Delivery Network (CDN). This can improve the performance for sites, especially for those where users are all around the globe.

A CDN is just another layer of caching. Without a CDN, if the browser makes a request to your site, it has to go to the main web server hosted in whatever Azure data center you’ve set it up in, which could be on the other side of the world for some users. With a CDN, certain files are copied to servers all over the world, so there is a version of the file on a server that is closer to them, resulting in less time to get the file, and overall better performance.

Of course, this can cause problems when the original file changes, since it make take time for those changes to make their way all over the world. Even if you clear your browser cache, the browser is going to request a new version from the CDN server, but the CDN server still has the old version. There is no way for a browser to bypass the CDN server.

For this reason, I don’t typically enable the CDN for development environments, as the performance benefits are not worth the hassle.

If you do need to clear the CDN cache due to an issue in a production environment that you want to make sure gets out to users as quickly as possible, you can do so via the Purge Cache option in the Power Platform Admin Center.

Design Studio

So far we’ve talked about caches that impact your actual Power Pages site, but there is another cache that can impact those building with Power Pages: the cache of the Design Studio.

Just like how the Power Pages web application has a layer of caching so that it doesn’t need to go back to Dataverse every single time, the Power Pages Design Studio is also a web application with a similar layer of caching.

So, if you make changes to something in Dataverse, say through the Power Pages Management app or VS Code, you may not see it immediately reflected in the Design Studio. This is where the Sync button, in the top right corner, comes in.

The Sync button is the clear cache button for the Design Studio. Clicking it will cause the cache for the Design Studio to be emptied, and you’ll get all of the latest data from Dataverse.

—

As you can see, there are lots of caching layers when it comes to Power Pages. And I’m sure there are more that I haven’t mentioned here.

While we love to hate caching, the alternative is much worse – no one would use the product without caching because the performance would be terrible. So you best bet is to learn how it works so it doesn’t slow down your development, and to appreciate how it makes life so much better for Power Pages users.