Over the past few years the majority of the WPO (Web Performance Optimization) experts I know have focused their attention almost exclusively on the US & European markets – so have we. However this year we’ve been asked to look further east and see how our friends that build and run large ecommerce websites in countries such as Saudi Arabia, Kuwait, Egypt or United Arabic Emirates are doing in terms of end user experience, performance and adhering to the latest web performance optimization best practices.

Turns out that we all deal with the same challenges: Optimizing page load times across different browser types, versions and devices and making sure content gets delivered as fast as possible to the end user regardless the actual geographical location. Here is one of the early findings I tweeted last week when comparing Internet Explorer 10 and FireFox 32 when loading http://www.souq.com – the “Amazon” of the Middle East:

Web Developers make sure you look at the Key Web Performance Metrics across all major browsers – don’t just do it on Chrome, Safari or Opera
Web Developers make sure you look at the Key Web Performance Metrics across all major browsers – don’t just do it on Chrome, Safari or Opera

Test Bed: Diagnostics and RUM of souq.com and others

My colleague David Jones and I split up the analysis work we did. He setup comparative external and last mile tests using Dynatrace Synthetics from some of the top locations in that Arabic target market: of special interest here are end user response time, availability and web site complexity. I on the other side focused more on “good old fashioned” web performance diagnostics using free browser plugins such as Dynatrace Browser Agent, Firebug, YSlow and others.

Diagnostics Finding #1: Overloaded Landing Page

Using the Dynatrace Free Trial I walked through a sequence of actions on www.souq.com including loading homepage, searching for specific items, hitting the Ramadan Special Deals pages, and adding and removing items from the cart. It did this for both Internet Explorer 10 and FireFox 32 on my Windows 7 laptop. The first screenshot in the initial paragraph already shows the high page load time for both browsers with FF32 taking the lead with 8.4s on my machine. Looking at the waterfall chart makes it clear where this time comes from. The metrics in the following screenshot speak for themselves:

8.4s Homepage Load on FF32 caused by: 49! Domains (many single resource domains), 33 JavaScript files, unnecessary redirects
8.4s Homepage Load on FF32 caused by: 49! Domains (many single resource domains), 33 JavaScript files, unnecessary redirects

A reminder to web developers, designers and businesses: make sure you are not putting everything that you think might be necessary on the first landing page. The goal of the landing page is to load as fast as possible by focusing on the content that matters most to your end users. Then delay load content that is less important or only needed if users start browsing and navigating through the page. Check out some of our best practices: 5 WPO Best Practices You Can’t Miss!

Diagnostics Finding #2: Excessive JavaScript in onLoad

A key metric for me is Client Time. What is that? Client Time is JavaScript execution time that happens until the page is done with the onLoad event. The goal is to at first only load JavaScript that is really essential and delay other JavaScript that is necessary for features the user “might” use on your page. I found three very interesting JavaScript hotspots on several of their pages where initial page load was heavily impacted by excessive JavaScript before onLoad was completed.

The first two can be seen on home page: Creating 9 ActiveX objects and doing up to 177! DOM object lookups spots where one of these lookups was done 68 times for the same DOM object:

When needing the same object multiple times it is best practice to cache the result. This reduces expensive DOM lookups especially on slower browsers such as IE 10
When needing the same object multiple times it is best practice to cache the result. This reduces expensive DOM lookups especially on slower browsers such as IE 10

Best Practice in the above case is to cache the result of a DOM Lookup and reuse it multiple times if needed. I’ve seen this many times on other web sites in the past. Especially on older browsers that don’t support native lookups this can become your number one hotspot.

The other thing I saw was kind of new for me – at least to such an extent: The “Special Deal” page on iPhone 6 with 64GB took 8.3s to load. A large portion of that time was spent in creating 76k new Date() objects, calling getTime() 153k times and spending a lot of time in string manipulations. Here is the hotspot view of one of the JavaScript blocks that executed during onLoad:

Loops in JavaScript that create a lot of objects and manipulate strings will consume a lot of memory and high CPU causing the browser to freeze for the end user until these operations are done!
Loops in JavaScript that create a lot of objects and manipulate strings will consume a lot of memory and high CPU causing the browser to freeze for the end user until these operations are done!

Developers: perform a sanity check of your JavaScript that gets executed when loading a page but also when users interact with dynamic elements. Use the browser plugins to profile your script executions, memory allocations and find the hotspots in both call count to individual methods or long running methods. I typically sort these hotspot tables by Execution Time, but also by Invocation Count to identify my real hotspots.

Before I hand it over to David and his analysis I just want to remind you that these types of hotspots can be easily spotted. Every modern browser comes with built-in diagnostics tools that give you these KPIs, or you can use tools such as Dynatrace Free Trial and do this across browsers. These tools are easy to use and should act as a sanity check before releasing websites into production. Please also read my Functional Test Revolution blog where I explain how Manual and Acceptance Testers can do the same thing.

External and Last Mile eCommerce Comparisons for #Ramadan2015

As my colleague Andi has shown us, the way in which sites are designed can significantly impact performance. While Andi focused on the details on how www.souq.com was being delivered, I focused on running some controlled tests against www.souq.com and some other eCommerce vendors who would be seeing higher traffic during Ramadan. For the comparative testing I ran simple home page tests using a Chrome Browser from global locations in Europe, the Middle East and Asia. I also ran tests from real end user machines in Egypt and Saudi Arabia. What you will see corroborates Andi’s finding in that site design plays a significant role in how end users will experience an eCommerce site.

To start with let’s look at how these sites performed from various regions. When I looked at the response times from real user machines (this is called the Dynatrace Last Mile Network) in Egypt, Saudi Arabia and the UAE, I see the average response time (this is the “over the wire” time it takes a page to load) of the sites being monitored is 18 seconds.

Average Response Time across different geographical regions allows pinpointing content delivery issues per region
Average Response Time across different geographical regions allows pinpointing content delivery issues per region

So I can see for the Middle East, geographic latency is consistent across these countries. Now that I have established a baseline, let’s look at the individual test results. Below is how the various sites ranked compared to each other. While Sukar.com ranked fastest, it actually is a site that redirects the user to Souq.com which means that injoo.com was the fastest site at ~7 seconds and Costprice.ae was the slowest at an average response time of ~28 seconds.

Synthetic monitoring allows easy comparison of response times of different competing websites. There is clearly a huge difference
Synthetic monitoring allows easy comparison of response times of different competing websites. There is clearly a huge difference

Now if I look at the same sites in terms of how successful (availability) it was to load the home page I see that there is a three-way tie with Souq.com, Alshop.com and Jadopado.com all with a 98.57% success rate over a 5 day period. During the same period of time Careem.com, Innjoo.com, Costprice.ae and Awok.com had a success rate of 99.64%.

Measuring and comparing Availability as a key quality indicator across major eCommerce sites. Who is up and available more often?
Measuring and comparing Availability as a key quality indicator across major eCommerce sites. Who is up and available more often?

So far I have compared the overall response time and success rate for the Ramadan focused ecommerce sites. Now let’s start to look at some of the details as to why some of these sites are faster than others. I can do this first by looking at how fast the server requests are being responded to. In the chart below I am looking at the W3C browser metric called response time. This time is an indicator of how long it takes the server to respond to the initial request from the browser.

Initial Response / First Byte Time: A key metric that typically indicates a connectivity or server-side issue if slow
Initial Response / First Byte Time: A key metric that typically indicates a connectivity or server-side issue if slow

Slow sites that have long W3C request times typically have issues on the server side that would map back to a specific tier, server, api, database call, method, etc… While Dynatrace Synthetics allows us to compare the end user results I need Dynatrace Agents installed on the server side generating PurePaths to understand what specifically is causing the slow down.

Server side responsiveness is one aspect to look at, however there are other Key Delivery Indicators (KDIs) which Ramadan retailers can look at to improve their end user performance. The chart below shows the ranking by response time along with other KDIs. These metrics include the number of Hosts (3rd parties), The number of Bytes (page weight) and the number of Objects and Connections (page complexity).

Keep an eye on these Key Delivery Indicators: Page Load Time, # Hosts, # Connections, # Bytes ,# Objects
Keep an eye on these Key Delivery Indicators: Page Load Time, # Hosts, # Connections, # Bytes ,# Objects

Andi pointed out, requests to third party domains will impact end user experience. Sites, which use more third parties, have larger “over the wire” transfers and are more complex (have more objects and connections) will perform slower than sites that are more optimized.

Do Your Homework & Level-Up your Engineering

Retail eCommerce for Ramadan (or for any seasonal event) is a highly competitive event. End users will not tolerate slow responses, and retail studies have shown that customers who are made to wait for a page to load or for a transaction to occur are much more likely to abandon their sessions and look for that product or services from a competitor.

Andi has highlighted what developers can do to improve the performance of their applications on the client (end user) side. It is up to the digital business owners to ensure that their developers are using industry best practices like Web Performance Optimization or DevOps methodologies focused on end user performance to ensure that their developers are creating compelling engaging experiences for end users. The goal for eCommerce managers for Ramadan is to increase their conversions and once of the easiest ways to do this is to focus on improving end user experience.

Ramadan Kareem.