Comparing Azure Static Web Apps and Github Pages

I host my personal website on Github pages. At Build 2020 I watched a demo of a new service called Azure Static Web Apps. This service is still in preview and its free to use for the moment. I decided to try it out by deploying my Github pages project to it.

This was surprisingly easy to do given how complicated other Azure services can be to configure. I opened the Azure portal and typed “static” in the search bar and it popped up immediately. The configuration page did a good job of walking me through the process where I created a new resource for it, pointed it at my Github repo, approved the automatic creation of a new Github Action to grab the static files from the repo. In just a couple of minutes I could play with the demo site.

There are a couple of things I don’t like about this though. If you pop open the site in your browser’s dev tools by hitting F12 in Chrome and refresh the page from the “Network” tab; You’ll see that requests are being served using the HTTP/1.1 protocol with SSL enabled. This is unfortunate because on Github pages my site is served up using HTTP/2 when the client’s browser supports it.

This protocol support handicap manifests itself as performance hit if you compare the two services by hard refreshing them in side by side browser windows. A warm copy of the Azure Static Web App Preview takes 20 milliseconds to render in Chrome whereas the same site on Github pages takes 5 milliseconds.

Acknowledging that both page load times are well below what would be perceived as slow by a user, a 3x performance hit is not ideal. What is worse is that a cold refresh on the Azure Static Web Apps version is typically much slower, between half a second and 3 seconds in my testing.

Then there is the issue of the security headers, which are non-existent. You can see that the site fails the SecurityHeaders.com checker. To configure how the web server responds to requests for your static content you have to create a separate Azure function which sort of defeats the purpose of hosting a static site if I need a back end to modify the web server’s responses.

Ideally, I would be able to select the headers that I want the web server to respond with from a list of support options as a global configuration option for the site. In defense of Azure’s Static Web App Preview, sites built on Github pages also fail this security headers test.

Finally, we have the Google Lighthouse scores which are identical at 100 for both services. Azure’s Static Web Apps Preview does get dinged 7 points in the “Best Practices” category for not using HTTP/2, but we already knew about that issue.

In sum this preview is a good start and the concept of quickly yeeting some static files into a website hosted on Azure has legs. But the current implementation has room for improvement before it can compete effectively with existing free services like Github pages.