Today I continue my performance audits of Microsoft properties. Today it is the Azure marketplace. Just like the Microsoft Store I noticed the marketplace was slow to respond to request. Again they are suffering from unacceptable time to first byte issues.
Taking action on these issues will improve their user experience, helps search engine rankings and should improve user egagement stats, like sales
By providing a better user experience where vendors can acheive success they should also be able attract more service vendors to the marketplace, which increases the value of the Azure Marketplace.
The pages on the Azure Marketplace could use some simple refinements and load almost instantly across all devices and platforms. As usual I use Web Page Test to record synthetic performance results.
Bad Time to First Byte
Similar to the Microsoft Store the Marketplace suffers from poor server-side optimization. Normally the server constitutes 5-20% of a page's load time.
However, the Marketplace has an inverse ratio.
My first Web Page Test run recorded a time to first byte (TTFB) of 13.861 seconds.
Slow even in the days of dial-up!
The second run recorded a more acceptable, but still poor 4.146 seconds.
The second run primed the server, which means the server goes to sleep if not used. When a new request hits the server it must spin up resources, wasting valuable time.
Most likely the marketplace site is an ASP.NET web site. This means the pages are most likely rendered each time they are requests. Since these pages rarely change they should change this to a static web site. The pages can still be rendered using ASP.NET, but a utility like Varnish can improve page load times and reduce server loads.
Rather than rewrite this section from the Microsoft Store article here are some bullet points to remember:
- Cache Static Markup - Output Cache, Static Site Generation
- Use a NoSQL Front-End Data Store
- Target < 250ms
Suggestion - Azure Search Service
One thing that caught me about the Marketplace is how slow search results return. I know the Azure Search Service is remarkably fast. I don't know how they currently store their data and query it for search results, but I recommend they move it to their own search service.
Not only would this improve the performance, but it would also be a good case study for them to share. All things Azure should dog food their own services on their own properties.
Over-Sharding Domains
I have long been an advocate of sharding domains. This means you host different assets on different domains. The reason you want to spread assets across domains is to speed up delivery. Browsers limit parallel connections per domain. If you split content across domains you can double or triple your simultaneous downloads, which in theory improves your page load time.
This practice diminishes as you add more domains because the browser must do DNS resolution and create new connections. These operations can be expensive. I have listed 3 different domains used by the Azure Marketplace along with their DNS lookup times.
Images hosted on
- 106c4.wpc.azureedge.net DNS Lookup: 99 ms
- prodpublishingstorage.blob.core.windows.net DNS Lookup: 334 ms
CSS & JavaScript Hosted on
- acom.azurecomcdn.net DNS Lookup: 130 ms
My advice is to consolidate the domains and use folders to isolate files by type. The good news about these domains is they are CDNs, which you should use to improve performance.
Domain sharding should meet its demise in the next year or so as HTTP/2 becomes standard. HTTP/2 fixes some of the issues inherent with HTTP/1, our current standard. More on HTTP/2 in another post.
Pick A Single Analytics Package
I mentioned this in the Microsoft Store article as well. The store was not too bad, but the marketplace is a poster child for what not to do. I counted 6 different analytics packages in use. I can't justify 4 of them. They use Google Analytics, yet Azure offers HDInsights, a similar service. They should switch to their own product. New Relic is aimed at web performance monitoring, a good sign, so I can justify their presence.
- Google Analytics
- Kissmetrics
- UserVoice
- Visual Web Optimizer
- BizOGraphics (linkedin)
- New Relic
The other packages are questionable. The scream marketing guy X thought it was cool and somehow added it to the build.
One problem I have with these packages is developers often have no idea they are added to the application for the final deploy. These third party scripts tend to be poorly written and break applications. Not only is the code base low quality their hosting is questionable as well as their back-ends. These deficiencies propagate the application.
The application testing process often does not incorporate these third party scripts, so bugs are not caught until customers experience their crushing blow. Often they go unreported. Instead customers go elsewhere. The online news industry is plagued by third party scripts and is starting to suffer. Don't let third party scripts kill your business.
Unnecessary JavaScript
The only place where JavaScript is used is the menu. The menu could be done in about 10-20 lines of JavaScript, no need for jQuery or other frameworks or plugins here. The only other place I could see JavaScript being used is the search experience. As the user types the results could automatically be filtered.
The marketplace is not a single page application. It is a very read-only experience. As it stands the search must be manually posted back to the server. The menu has a 'mildly' dynamic experience. The menu could be handled by some simple scripting, again I envision 10-20 lines of code. Most of the work lies in crafting a modicum of CSS.
Poor Image Optimization
The marketplace displays a brand tile for each product in the results. Each tile is 115 x 115 pixels. Examining the waterfall I saw one tile taking a very long time to download. Looking at the image details you see the tile image is just shy of 1MB. The tile is not sized correctly, it is massive.
When you see an example like this image tile you know the business does not have proper systems in place to ensure consistent quality. I assume the marketplace has a content publishing process in place where images are uploaded and properly stored. Most images are created as large as possible to ensure details are included. These large images are then properly sized for display. This poor image was never resized.
This oversight says too much manual labor is involved in the content publishing process. The administrative tools should have a backend process that properly sizes and optimizes the images before publishing them to the CDN. This workflow is common for applications. In fact Scott Hanselman has an article on using Azure web jobs to optimize images when they are uploaded.
Summary
The Azure Marketplace is another example of a Microsoft property that is not using the web platform Microsoft builds. Instead of being a well managed example of Microsoft's products and services they demonstrate how not to use the resources the company sells. A company like Microsoft needs to have a set of quality standards and internal resources for any business unit to achieve a successful online presence.
Microsoft offers a top tier web plartform, unfortunately the Azure team and the online retail store have chosen not to use the company's platform correctly. As a result they are a poor company ambassador. My advice to Microsoft is make an intentional effort to get their online presence organized and enforce a high level of quality. They are always being scrutinized by everyone. Any small slip is exposed as an example to say, 'see, Microsoft sucks'.
Azure is a platform to build highly scalable, highly performant web applications. The Azure marketplace does not exemplify how the platform benefits customers. It is a deterrent. If the Azure team fixes the marketplace they stand a much better chance at competing and expanding their Azure brand.
