When mobile friendliness defeats mobile performance!

Recently, someone asked me the following question: “Can you explain to us why the same page, optimized to be mobile friendly, takes 4.5 seconds to open on the desktop Chrome browser, but takes almost 15 seconds on the mobile Chrome browser”. So I checked to see if they had followed the three basic rules everyone should follow when creating something mobile-specific whether it is a native mobile app or like in this case a mobile optimized website:

  1. Respect the mobile device’s battery life; do not stress CPU and network
  2. Respect the mobile phone owner’s data plan; do not load useless resources, and optimize traffic
  3. Respect the fact that mobile hardware doesn’t have the same computation power as laptops or desktops

Unfortunately, I determined that all three rules of good, mobile-friendly development had not been fulfilled. So let’s explore what went wrong.

First, look at the waterfall chart

The Android-specific CSS files seen in the chart below indicate that a genuine attempt was made to be mobile friendly, and that the initial HTML load is not to blame for the lengthy response time. It also appears an excessive number of resources (285) are required to display the web application. There is also an interesting gap between the loading of the last of four initial JavaScript resources and the downloading of the first CSS files.

Waterfall chart of real mobile browser showing mobile web performance issues
Waterfall chart of real mobile browser showing mobile web performance issues

JavaScript/CSS gap

Where does this gap come from? Looking at the details of the initial HTML loading we can see that the number of DOM nodes — 172 — is very small, and cannot contain the tags for the 285 resources that are downloaded. It contains only the bare minimum, along with the four initial JavaScript files. One of the scripts is there to determine which device/browser is loading the application, and is then inserting the correct resources on-the-fly. After the insert via JavaScript occurs, the browser starts downloading the CSS-resources.

HTML-Resource details including W3C Navigation Timings - unveiling high processing times
HTML-Resource details including W3C Navigation Timings – unveiling high processing times

The seemingly tiny gap spans 306 ms during which the mobile browser is doing nothing but determining which device it is on and then changing the DOM. A gap on the desktop browser exists but, at a mere 20 ms, is almost unnoticeable. This is real example of the difference between the computation power of a mobile device and a laptop, with mobile being 15 times slower. You should also consider the age of the device being used. How about using the good old Sun Spider test to see what your hardware can do? I did it with my three-year old laptop vs my Samsung S5 with an outcome of 225 ms vs 910 ms! Here are test results for other mobile devices, including the current iPhone 6 which achieved a 358 ms result — which is good — but is still 30% slower than my old laptop. Take a minute to check your devices.

Can the 285 resources attributed to HTTP2?

285 resources on HTTP1 are typically a sign of  bad coding. Although HTTP2 best practices are changing, and the round trips no longer hurt as much as they used to, we should try to load only what is necessary.  We cannot assume users’ devices are capable of handling the extra traffic. As shown in the image below, the number of people still using old versions of Android increases the likelihood users will have a browser that does not support HTTP2. We need to meet the needs of everyone, even the individual using Android 4.4 a Mobile Chrome 33.

Android version distribution history till April 2016
Android OS version distribution from Wikipedia.org

Because this company told me they had not thought of switching to HTTP2, we needed to look at the resources in detail, finding as many as 151 CSS files in the waterfall chart below.

Waterfall chart showing 151 CSS files leading to high blocking times
Waterfall chart showing 151 CSS files leading to high blocking times

Halfway down the waterfall the massive amount of CSS resources was followed by 121 JavaScript files. This is clearly too much for a mobile friendly web application. Looking back at the rules we defined at the beginning, this session violated all of them. With so many resources in the application overusing the network, it’s also forcing weak hardware to handle all of them. Additionally, the app runs numerous JavaScript files which consume CPU — and when combined with heavy network traffic — drains mobile battery quickly.

Payload Too Small

The stored session held one more surprise for me — a performance issue resulting from the fragmentation of the CSS- and JavaScript files into multiple files! The response body of these requests was tiny, with one file having only 97 Bytes payload vs. 349 Bytes in the header. The normal frame size (MTU) for IP traffic is 1500 Bytes! In this situation — with the request body size of all elements being between 53 and 356 Byteseach round trip wasted highly valuable space. Merging CSS and JavaScript files would help users who pay for their own data plans by reducing the number of round trips and transfer overhead.

Request payload to header ratio is very bad
Request payload to header ratio is very bad


Because mobile devices do not have the same computation power as regular laptops and desktop computers, creating a mobile-friendly experience requires more than using a different CSS layout. It’s also about the quantity and size of the resources used. Too many resources, or resources that are too small or too large, can ruin the entire mobile experience.

Klaus is a Senior Technology Strategist in the Center of Excellence at Dynatrace. Klaus influences the strategic direction and development of application performance management solutions. He has deep experience gleaned from years of developing and running large scale web and mobile applications for online businesses.