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:
- Respect the mobile device’s battery life; do not stress CPU and network
- Respect the mobile phone owner’s data plan; do not load useless resources, and optimize traffic
- 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 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.
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.
Payload Too Small
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.