Another perspective on “Why mobile web apps are slow”

The recent post from Drew Crawford “Why mobile web apps are slow” has received a lot of attention and provides a rather powerful argument for the topic. I’m not here to dispute anything in that post; it’s good information, go read it if you are interested in the topic. The point at the end of the day is that today’s smartphones, while awesomely powerful, are not at the same performance level of modern computers, particularly the browser platforms, not by a long shot. The conclusion is that smartphone browser-based technology is “too slow” for “mobile app use.”

Think about iPhone 4S web development in the following way.  It’s a computer that runs 10x slower than you expect (since ARM) and performance degrades exponentially if your memory usage goes above 35MB at any point, because that is how garbage collectors behave on the platform.  Also, you get killed if at any point you allocate 213MB.

The quote above speaks about the iPhone 4S specifically, but I would say the same holds across the board for all smartphone platforms.

Again, I don’t disagree with the points of the article. My first question is the definition of “too slow” and when exactly does a “website” become a “mobile app” – these are both gray areas with no single agreed upon definition. A key point here is that Smartphones are completely different animals and need to be looked at as such. You cannot simply apply the same tools and techniques used for full size modern browsers to smartphones and tablets. Chrome is not Chrome, in other words.

Ultimately there are limits, as pointed out by Drew’s post; a mobile web app is going to reach the “too slow” mark at some point. However, it depends on the app feature set; some set of feature requirements can certainly be provided with a reasonable level of performance using mobile browser-based technologies (i.e. in a Web App). But it is not easy. Quick fixes like responsive CSS media queries and typical Javascript libraries aren’t going to get it done. And this is where most projects go wrong. Over recent years, browser-based app development has been maturing for the desktop/laptop browser platforms. However, these exact tools and techniques that work so well for that environment make things far worse in a mobile browser context. Trying to use those same tools and techniques in a mobile web app is going to severely restrict the feature set options before crossing over the “too slow” mark.

And there are lot of problems that aren’t even covered in the “too slow” post. Below are a few of the most common reasons that I’ve seen for “why web apps are slow”:

The high cost and performance penalty of TCP/HTTP connections.

Typical browser-based apps and JS libraries load in a zillion little (and some huge) JS and CSS files. Each of these separate connections are REALLY expensive on mobile (even on wi-fi, due to memory limits of the device). So the first step in improving the performance of your app (or even your regular content site for mobile users) is massively reducing the number of HTTP connections the browser has to make, by reducing your <script> and <style> tags to name a few. Some of the fastest mobile apps actually assemble all Javascript and CSS on demand on the server and simply embed it directly into the HTML page beging loaded (everything in one HTTP connection).

Unrealistic expectations of “responsive design”

Another problem I see frequently is a common expectation among developers of a miracle from “responsive design” and specifically CSS media queries (and maybe some Javascript) – or, IOW, client-side responsive design. I’m amazed how often I run into web developers that don’t understand how browsers work. In the case of CSS media queries, what we see all the time is a CSS file with the hacks to adjust the CSS for smaller screens. The problem with this approach is that all the CSS was already downloaded by the mobile browser, so all that time (and bandwidth and memory) was already used up. Adding the CSS media queries actually makes the CSS file bigger (and thus slower), not smaller. On a fast computer with a high-speed connection, this is not noticed, but on a mobile device with high latency, limited bandwidth, and a lot less memory, it’s a user experience killer.

These two approaches, that work perfectly fine in a full screen browser environment absolutely destroy the performance of the same app on smart phones. It might be okay for a “content” site, if you can live with your content being slower and more difficult to use for smartphone users, but they simply don’t work for anything trying to deliver an app-like experience on smartphones or tablets.

Summary: Mobile web app development is hard and there are limits to how far you can go with a web app

Drew suggests that you can never make web apps that are not “too slow” and I suppose I wouldn’t go quite that far. As I note, there is a limit to what feature-set a mobile app can have before hitting the “too slow” mark, and at some point a native app is the only answer, but I wouldn’t go so far as to say the maximum feature-set for mobile web apps is zero. Mobile Web App development is hard. There are no quick fixes. You cannot simply wrap your full-size browser app around some extra CSS media queries and additional Javascript to make it perform well on a mobile device. It requires server-side delivery of completely different mobile-optimized content and code to even attempt to deliver decent performance on mobile devices. And that is tedious and difficult – and it means abandoning most if not all the tools you use in developing full size browser-based apps. Very few sites do this… because it is difficult and expensive. A few megabytes of Javascript here and few there may have little impact to your full size browser users. But even just a few extra Kbytes of Javascript or CSS can have massive performance impact to mobile users. It’s a whole different way of thinking and most developers aren’t prepared to go there. And that’s why so many mobile web apps are slow unusable.