Blog

Azure Static Web Apps - Performance

March 29, 2024

While doing some performance profiling of an app made for Azure SWA we noticed a rather large discrepency between the client times we were seeing and what our server side logging was outputting. While some difference was expected due to request latency, the difference in this was was both higher and more variable. Performing a traceroute to try dive into the problem deeper we quickly realised something - although SWA is a global service, it's not served by every Azure data center. Thus the api traffic was flowing from New Zealand to HongKong then back to Australia (where the Azure Functions were hosted).

a diagram of a software application

Diving into this deeper we made a bare bones reproduction of the issue, using an Azure Function that just returned a string and hosted two copies, one in Australia East the other in HongKong.

Azure Function Direct (AUE) - ~60ms
Azure Function Direct (HK) - ~160ms
Azure SWA (AUE) - ~300ms
Azure SWA (HK) - ~180ms

The result was pretty clear - in terms of performance (for our current location) we were going to be best off hosting the functions in HK.

It was about this point when we remembered the Enterprise Edge feature of SWA and decided to try it out - while there was quite the battle enabling it (that's another story) a really curious thing happened. Static content went way faster (dropping from 150ms to less than 50ms) which wasn't surprising as there was a node in our country, however API traffic jumped up to the 800ms mark. We never quite got to the bottom of this change, but suspect enabling enterprise edge changed which data center traffic was directed to for the SWA proxy (potentially USA) thus meaning instead of jumping NZ (Location) -> HK (SWA) -> AUE (Func) whereas now it was doing something like NZ (Location) -> NZ (Edge) -> USA (SWA) -> AUE (Func).

We could probably fix a lot of that by hosting the functions in america, but suspect (admittedly didn't try) that the result would still be higher than the 180ms mark.

In the end we took a slightly different approach, ditching the SWA proxy feature and went directly to Azure Functions directly from javascript, meaning we had to deal with CORS and Auth but the resulting overhead for each api call was only 60ms instead of the original 300 (or 180 if hosted in HK). Pity as it means we lose some of the advantage of SWA, but gave the best result and would be fairly easy to rever later if Microsoft ever release something that fixes the issue.

Since then Microsoft have released a new feature for distributed functions  and announced (in LinkedIn comments at the least) that they're looking into making the SWA service more global, potentially increasing the number of regions its in next year.

Until then we'll likely continue on with the little bypass hack, at least for clients located within Australasia. Especially once the NZ North data centre is live this little hack will have even more impact.

Want to stay updated with what we are doing?

Subscribe to our newsletter for our ideas about development, marketing, and technology. See our latest work, find out about career opportunities, and stay notified about upcoming events.

Subscribe to our newsletter