Oh no, you're thinking, yet another cookie pop-up. Well, sorry, it's the law. We measure how many people read us, and ensure you see relevant ads, by storing cookies on your device. If you're cool with that, hit “Accept all Cookies”. For more info and to customize your settings, hit “Customize Settings”.

Review and manage your consent

Here's an overview of our use of cookies, similar technologies and how to manage them. You can also change your choices at any time, by hitting the “Your Consent Options” link on the site's footer.

Manage Cookie Preferences
  • These cookies are strictly necessary so that you can navigate the site as normal and use all features. Without these cookies we cannot provide you with the service that you expect.

  • These cookies are used to make advertising messages more relevant to you. They perform functions like preventing the same ad from continuously reappearing, ensuring that ads are properly displayed for advertisers, and in some cases selecting advertisements that are based on your interests.

  • These cookies collect information in aggregate form to help us understand how our websites are being used. They allow us to count visits and traffic sources so that we can measure and improve the performance of our sites. If people say no to these cookies, we do not know how many people have visited and we cannot monitor performance.

See also our Cookie policy and Privacy policy.

This article is more than 1 year old

How to make your HTML apps suck less, actually make some money

Google is here to help, really

Chrome Dev Summit Your web apps probably suck, according to Google, but there are solutions if developers get progressive.

Not just because of mediocre coding, legacy baggage, and half-hearted optimization, but also because the mobile ecosystem is full of pitfalls like slow network speeds and underpowered devices.

At the Chrome Dev Summit on Monday, Google returned to its long-running campaign to make web apps suck less, because web technology has finally evolved to the point that web apps can compete with native apps in terms of performance while outdoing them in terms of discovery and distribution.

Such evangelism is necessary because much of the web code out there was written before Progressive Web Apps (PWAs) arrived and companies are still trying to figure out whether they can implement the technology.

In a conversation during the conference, a web consultant from Dallas, Texas, described dealing with web apps served through Java and JSP and talked about PWAs as a pipe dream. A developer with Expedia meanwhile said his firm had been focused on native apps but is now thinking about PWAs.

Native mobile apps for the past few years have been preferred for both technical and business reasons, but lately that's changed, because web technology has matured and because most people are not downloading and installing a lot of native apps anymore.

In the US, more than half of users, by comScore's measure, don't download any apps in a given month. Our phones, in short, are full; but the web has room for everyone.

Proposed in 2015, PWAs describe a set of requirements for web apps that don't suck. Basically, PWAs need to be fast, engaging, and work offline. PWAs don't mandate specific technology – there are many ways to make apps fast and engaging – but for offline functionality, Service Workers, a relatively recent API, are probably involved.

Interactivity

Addy Osmani, a web tooling engineer at Google working with the Chrome team, framed the problem with figures. For 90 per cent of websites on mobile devices, it takes 35 seconds or less before interactivity begins. For 70 per cent, time to interactivity is 22 seconds or less.

According to Google the average time to load a mobile landing page is 22 seconds. So the typical web experience is just too slow, considering that 53 per cent of mobile visits are abandoned after three seconds.

PWAs can help. Google software engineers Ilya Grigorik and Bryan McQuade, described how Pinterest's newly minted mobile web site – a PWA – took time-to-interactivity from 23 seconds for the previous incarnation down to 5.6 seconds.

Pinterest's PWA can begin functioning after transferring 150KB, plus successive loads as needed. Its native apps demand far more resources to get started: 56MB for its iOS app and 9.6MB for its Android app.

Comparing Pinterest's PWA experience to its legacy mobile web site, the value is clear: 40 per cent more time spent, 44 per cent more user-generated ad dollars, 50 per cent more ad click throughs, and 60 per cent more core engagements. ®

Similar topics

TIP US OFF

Send us news


Other stories you might like