Why Your Mobile Site is Slow (And What That Means for User Engagement)
Some stats: 85% of users expect a site to be faster on mobile than it is on a desktop. On top of that, users perceive page loads to be 15% slower on average than they actually are. In fact, to be allowed in an app store, your app must meet certain load time standards; for iOS the limit is 15 seconds. But it’s not as simple as raw speed; speed is related, but the real challenge is optimizing the visitor flow to engage the user. A user’s context switches every second, which is why page and application load times are important as a first step, but you are forever competing against context switching, so quite literally every second counts.
The rise of mobile computing has raised the bar for online businesses. Browsing increasingly occurs on the go, which requires websites to immediately engage users and then focus their attention with an engaging experience that responds to their device, browsing context and on-page interactions. Getting this right means setting aside all of the assumptions you make for desktop site and app development and to start over.
Here’s how to get started: We have compiled a list of gotchas that will lead you into trouble if you apply any ‘givens’ from previous web development experience. Getting these fundamentals right for mobile sites and apps is a critical first step in creating a foundation for engaging users. Then, if you need a complete, holistic approach, check out our list at the bottom on how to re-think your approach to mobile and find the big solution.
Slow network = challenging user experience
3G, 4G, LTE – Really, all users want is to be engaged and involved. Users have been conditioned to want the fastest network because they feel it will provide them the best possible experience. In the cellular space, breaking developments in network speed are typically accompanied by resilience. If you watch AT&T and Verizon fight for cellular dominance, they’re actually focusing on reliability over speed because of the variable nature of cellular service. And now, mobile users will only maintain their focus on any given mobile site or app for 75 seconds before context switching, according to recent data from Microsoft, so reliability doesn’t cut it.
Networks are shaky, and speed isn’t the point. Networks that promise to be faster might help you initially engage users, but the new battleground, beyond performance, is about challenging the unreliability of networks. This means that you have to be smarter about how you code your application. Wireless networks are constantly in competition to be the fastest, most reliable service. This was an important factor in a pre-app world, but now the focus is on being aware of what users are browsing, how they are browsing, and from what location and context, so you can engage them quickly and then hold their focus while they transact.
What to do next:
For this, forget testing your site or web app with a full connection – see how it behaves in typical situations where the wireless is less than ideal. If you’re a DIYer, find a basement or elevator, walk in and out of WiFi areas, or find slow WiFi in a common spot, such as a coffee shop.
You’re not caching your data
Taking advantage of the browser’s local cache is web performance 101. But when it comes to apps this step is often overlooked. Why? Because on mobile apps, even when caching is supported by a platform, it is off by default. Seventeen percent of mobile traffic is duplicate downloads, and reading from local cache is 75-99% faster than downloading from the web, so you have to take advantage of using the device’s local cache.
What to do next:
Specify a time (in seconds) for your local cache to clear with a Cache Control Header. For information that changes frequently, this can be a matter of minutes; but for icons, images and other items that may be more stable can stay cached for days or weeks, and the app will not check the file on the server until the max age is reached. You can also insert an ETag in the file, which your application will use to verify with the server that it can reuse the file. This alone should show a boost in speed!
You have ungrouped connections and too many requests
Grouping the connections that you make to the origin to request information or transmit information back saves time and battery life for users. Sometimes developers don’t think about grouping connections, so instead of all three operations being performed during one connection, they’ll open, transmit, close, and repeat three times. This impacts battery time and radio connections, draining power and requiring more return requests. Coupled with how busy the radio will be at any given point in time while it tries to keep a user’s device connected to a last mile network, the less frequently your app uses the radio, the more your users will be able to focus and become immersed in your app. Every time there’s a delay for content, you’re inviting the user to context-switch away from your app.
What to do next:
Group your connections! You can thread downloads instead of having serial downloads, pre-fetch assets, and reduce the overall number of individual requests. Reducing round trips from server to browser not only speeds page loading but also lowers network congestion. Lightening the payload with fewer assets to request means less data needs to be delivered to the browser, while still providing a rich experience for your customers.
Bigger problem: You don’t know what to build or how to start
There are a lot of options when it comes to building the “perfect” mobile solution for your business. HTML5 comes with the tempting promise of “build once, run everywhere”; which is all the more alluring when you realize there are over 200 combinations of operating systems and browsers in the wild. HTML5 also provides relatively simple ways to ensure backward compatibility.
All things HTML-based require JavaScript, however—including backward compatibility using polyfills (legacy JavaScript that works in old browsers and can make them render content in a similar fashion to modern browsers). This adds page weight, and hinders page load progress. When it’s done well you can argue it’s fit-for-purpose, but when you take a desktop implementation of JavaScript and try to render it on mobile the experience will suffer. Initial rendering speed, interactivity and look-and-feel will be impacted, which is why some developers turn to native apps as an alternative.
A native mobile app, on the other hand, is built specific to the device and operating system, which means a bigger investment in multiple apps, more time, and potentially a higher cost. But in return you provide your users better functionality, support and performance across the board. It also means fewer security vulnerabilities and richer functionality. Still, is it worth the investment?
What it really comes down to is the type of app you want to create and how your users behave when they use it. LinkedIn originally built an HTML5 website for efficiency and agility, but it lacked proper testing and profiling and the apps ran out of memory. In terms of user behavior, they expected mobile users to use the app for short periods of time, but in reality they ended up using it for much longer, which crashed mobile browsers. The social network shouldn’t have needed a native app, but user behavior forced their hand, and now the majority of their traffic comes from mobile and they have better features.
How to implement the right solution
For a holistic solution, you need to take into account goals, user behavior, and resources.
- Each business is different, requiring different solutions to the mobile challenge. So for starters, identify your goals with mobile, including business and engagement metrics
- Identify your budget and existing investments. There’s no point in planning something that’s untenable from a resource or time perspective
- Test! Using free resources likewebsitetest.com, you’ll be able to dig down into your performance metrics. Then consider moving up to an application performance management solution or something that optimizes from end-to-end like Yottaa
- Correlate your website testing with your user demographics/analytic data
- Revise your goals based on your findings
- Plan mobile first, or if it’s already not first, then mobile primarily for this initiative . Example: When Fathead originally launched their mobile site, they only saw a small percentage of mobile traffic over desktop. They then did extensive testing, tried out different column formats, and created the ability to visualize their virtual stickers via the user’s camera. After 3 months, 1,5000 staff hours and $250,000, they re-launched their mCommerce app. This new app resulted in a 90% increase in mobile conversions, 275% increase in traffic, and a mobile revenue increase of 538%.
- If you’re developing a native app, learn about simulators vs. emulators, and leverage a tool like AT&T ARO, which provides real-time testing across multiple variables while you’re building your app
- If you’re developing HTML5, you’ll want to get familiar with polyfills to support the legacy browsers your demographics identified. You’ll also want to ensure you’re performing multivariate testing, at least for the browsers your demographics highlighted. From there, use websitetest.com’s waterfall chart (which shows performance bottlenecks and problematic page assets) to highlight where you want to retool or rethink your use of JavaScript assets