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.
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
Unrealistic expectations of “responsive design”
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
Good post. This echoes my sentiments shared here a few days ago:
[…] Another perspective on “Why mobile web apps are slow” | Mr Blog […]
Actual problem with mobile web apps is not rendering. But cache’ing of js files and image files. native apps have script and background and other images required already saved in client side, and those are updated only with app update. but web apps need to download js and image files too often depending on browser. there should be mechanism to tell browser that some js, css files and image files should be kept on client side, and no need to download repeatedly. like a js/css file can be given long expiry date like 6 months.
[…] Among the several responses to Crawford’s post, David Beckemeyer mentions a couple of other drags on mobile app speed: […]
its really great to read your blog its really informative and use full…. I usually face this problem not only me its a common problem for every mobile user … before reading your blog i thought the fault is in my Mobile or in the internet speed.. thanks dear… there is a bad programmer behind this 🙂