WordPress is a beast with over 26% of the websites on the internet using it, and Azure offers a wizard for installing WordPress into Azure. Azure and WordPress are like two peas in a pod; in fact, Sunitha Muthukrishna has stated on Scott Hanselman’s Azure Friday webcast that about 25% of Azure Web Apps are WordPress installs from the gallery.

“…I took the site you are reading right now from loading in 4.66 seconds to, well, much, much faster.

However, you might find that once it is installed, the performance isn’t quite what you thought it could be. You aren’t alone. WordPress is notoriously heavy. Often, WordPress is installed on managed WordPress hosts like WordPress.com, WPEngine, or GoDaddy WordPress hosting in part because getting the environment and settings right for WordPress’s unique needs can be painful. Dedicated WordPress hosts are fine, but there are benefits to using Azure: you have more control over the environment, you have control over speed and scaling, and if you have all your other hosting through Azure it makes billing a bit easier.

But never you worry, you’ll get a faster site by the end of all this. Today I’m going to show you how I took the site that you are reading right now from loading in 4.66 seconds to well, much, much faster. You’ll see.

All you need is a trusty Azure account. There’s no affiliate links, no sponsored or premium plugins, no CDN, and no special sauce or secret code of any kind. Let’s get started.


First, I started with installing a site using Azure’s WordPress installation in their gallery.

This is where you go step-by-step and install WordPress, I used an S1 Standard Web App and the Basic Azure Database for MySQL Server. I also tried this with the ClearDB MySQL hosting with unnoticable performance differences between the two. You also have the option for MySQL In App, which could make performance better on small sites, but scalability could be an issue. Azure does not recommend this for production apps.

After creating the site how I wanted it for testing, I ran a baseline with Pingdom’s Website Speed Test:

  • 4.66 second load time
  • 4.5 mb page size
  • 113 requests
  • Faster than 34% of tested sites

Not great. Faster than 34% of tested sites means slower than 66% of tested sites. My goal was at least to be better than 50% of sites, in the fat center of the bell curve. I noticed a few things that I’d like to address:

  • Initial response time from server was over a second
  • 113 requests seems excessive
  • 4.5 mb is a large site (average site is ~1.6 mb)
  • Images are a big part of the data

Image Tuning

Images are the first place to look when it comes to page load time. It’s all too easy to just upload an image straight from a camera, especially if one is in a hurry. In our case, the difference between a full-fat image and a compressed and resized one was 2,200 kB (or 2.2 MB, as you can see in the image above) and 265 kB, or an astounding 730 percent improvement.

“…an astounding 730 percent improvement.”


Compressing and resizing before


Compressing And Resizing After

There are many tips and tricks for resizing and compressing images. Fast and loose, there are two simple rules I try to follow: don’t use images larger than the largest container in which they will sit and play with GIF, PNG, and JPG formats to see the tradeoff in quality vs. size. I personally use Photoshop to resize and export; there are many tools equally as adept. Google’s PageSpeed Tools Insights are great for tips and tricks in this and other general performance tuning areas.

All told, after going through this process with every image on the home page, here are the results:

  • 4.38 second load time, a 6% improvement
  • 1.5 mb page size, a 200% improvement
  • 113 requests, no change
  • Faster than 36% of tested sites, a 6% improvement

Why did the page size decrease so much, but the load time didn’t decrease quite as much? Network latency is a big factor. For every request a page makes, there’s time involved with it going all the way across the internet and opening a connection with the server there. Once the page knows a resource is there, downloading it can be quite fast. A few requests of large sizes can be much faster than a lot of small requests. And with 113 requests, that’s a lot of chatty network talk. We’ll tackle that next.

Bundling And Minifying

So what’s the solution? Bundling and minifying. Bundling takes your JavaScript and CSS files and puts them all into a few files, minifying takes out the whitespace and renames variables to reduce the total file size. I used the Merge & Minify & Refresh plugin for WordPress, although there are many plugins out there that will do the same.

Azure Performance Bundle And Minify

After doing so, the requests dropped from 113 to 21. Thus is the power of bundling and minifying. Here are the results:

  • 2.16 second load time, a 102% improvement
  • 1.4 mb page size, a 7% improvement
  • 21 requests, a 438% improvement
  • Faster than 67% of tested sites, an 86% improvement

The one big thing left was to reduce the time it took for the server to respond, which represented over a second of that load time.

Time To Respond Azure WordPress Response


Caching is a powerful tool. If you ask the server for the same pages again and again, it makes sense to take those pages and keep them in fast RAM rather than from slow persistent memory. And, it can avoid making the server follow the same logic paths again and again in PHP just to serve the same page over and over.

There are many caching strategies, but the one solution I’ve found that is easy to set up and works well with Azure is using the WP Super Cache plugin. Trust me, a lot of trial and error has led to me sharing this particular plugin as my suggested solution. I’ve found W3 Total Cache is full of spammy upgrade options and is difficult to configure, other highly rated caching plugins don’t work with IIS (and therefore Azure Web Apps), and enabling caching on the Azure Web App itself ignores the intricacies of WordPress comments and other dynamic areas.

WP Super Cache Settings

With a few simple checkboxes, I was able to greatly improve the performance of the initial page response. Here are the results:

  • 1.81 second load time, a 23% improvement
  • 1.4 mb page size, no change
  • 21 requests, no change
  • Faster than 74% of tested sites, an 10% improvement

And now the initial response comes in about 25oms, a much more acceptable timeframe:

Nebbia Tech Site With Caching Response


The load time is a 157% improvement over the original 4.66 second load time

There are many more steps we could take to improve this. Using a CDN would make page load times more even across the world, using PageSpeed Insights from Google indicates we could leverage browser caching, eliminate render-blocking JS and CSS, and minify our JavaScript. We could also do more with caching or upping our Web App from Standard to Premium, and our MySQL database from Basic to Standard. These are all long-tail solutions, the 80% of effort to get the last 20% of improvement. I’m really happy with the results so far, even if the process is not completely over. Here are the final results over our initial test:

  • 1.81 second load time, a 157% improvement over the original 4.66 second load time
  • 1.4 mb page size, a 221% improvement over the original 4.5 mb page size
  • 21 requests, a 438% improvement over the original 113 requests
  • Faster than 74% of sites, a 117% improvement over being faster than 34% of sites

All of these improvements came without paid plugins, special CDNs, or anything else. If you liked this article and it helped you in some way, in return my only ask is that you share it.