Last week’s Velocity New York conference by O’Reilly Media was held on the heels of new research published from DoubleClick by Google that concluded that mobile page load times of more than three seconds result in a 53% site abandonment rate. That’s not much margin for error for the devices that now account for 65% of all Internet usage today, according to Comscore.

So the mobile track on the first day of this year’s Velocity was particularly compelling to me. I took in Google developer advocate Pete LePage’s presentation on the future of the mobile web, then later caught Google software engineer Malte Ubl’s talk on what lies ahead for the Accelerated Mobile Pages (AMP) project.

LePage pointed out that mobile users were becoming less and less patient; that 53% abandonment rate for mobile pages that take more than 3 seconds to load, is up from 40% the last time Google DoubleClick conducted its survey. That desire for faster and faster mobile performance has led users to all but abandon the mobile web in favor of mobile apps. LePage cited Comscore research that says mobile apps account for a staggering 87% of all mobile traffic, yet 80% of mobile Internet usage comes from just three apps on the typical mobile user’s phone.

You can see where this is going. If mobile users spend all their time on just three apps, they become resistant to installing new apps beyond those three for content consumption, to say nothing of all the privacy concerns and device real estate issues they might have from having so many mobile apps.

The challenge then isn’t to get your app moved to the top of the pile but to make your mobile website more app-like, that is, faster, more predictable and reliable and delivering a more immersive experience—all the benefits of a mobile app without your users having to download another mobile app to the crowded real estate of their phone.

Both LePage and Ubl talked about building “progressive web applications” using caching technologies like ServiceWorker and AMP. This wasn’t the first time I had heard about ServiceWorker—I blogged about it after taking in a session at last fall’s Velocity New York conference. Only this time, the technology seemed much more ready for the world with real world examples of progressive web applications developed by the Washington Post and the BBC.

ServiceWorker is a client-side JavaScript proxy that caches Web content for future use. It decides whether to serve content from the cache, network or both, adding an app-like lifecycle to the mobile web as new content is fetched from the network and pushed to the end user. The user can also be notified of new content available from the site. When the network is down, the ServiceWorker can store previously cached content, such as a crossword puzzle for a newspaper site. The user may not be able to reach the site, but can still be kept engaged with the brand.

AMP is an open-source project backed by Google that’s used to build static content pages that are optimized for mobile devices. AMP governs what functionality can be used by an HTML webpage while supporting components that add rich content like video to these pages. AMP pages can be cached in the cloud, including the Google AMP Cache. AMP is gaining in cross-industry support: Microsoft just announced this week that its Bing search app would show and prioritize AMP pages in its results.

screen-shot-2016-09-28-at-2-47-28-pm

ServiceWorker and AMP are coming together through the ServiceWorker for AMP spec, now in development. This will allow devices to cache AMP pages that can be updated with every new network connection.

The end result of ServiceWorker and AMP is mobile web pages that are not only faster but more interactive and engaging. The Washington Post has reported that its AMP pages load 88% faster than its traditional mobile web pages and have produced a 23% increase in mobile search users.

Technologies like ServiceWorker and AMP are not only raising the bar for mobile web performance but making the mobile web, as opposed to mobile apps, relevant again. But caching tools like these only solve part of the mobile performance problem. You still need a mobile performance monitoring strategy that takes into account everything that contributes to mobile performance—network, DNS, CDNs, APIs.. etc– to make sure these new technologies are living up to their capabilities. When it comes to mobile especially, your customers won’t wait.