If you've learned about Progressive Web Apps,
you might know that the core of it
is a technology called service worker, a client-side proxy
that sits between your server and web app
to provide things like faster loads
and offline functionality.

But what if you built the most amazing Progressive Web App,
and nobody discovers it?
The problem with service workers is
that they won't make your first page load fast.
On a cold start, your service worker
will only activate on the second page load.

Even though the service worker API
allows you to cache away all of your site's assets
for an almost instant subsequent load,
like when meeting someone new, it's
the first impression that counts.
If the first load takes more than three seconds,
our latest DoubleClick study shows that more than 53%
of all users will drop off.
Don't feel too bad though.
The overall landscape of today's web looks a lot grimmer.

The average mobile page loads in about 19 seconds,
with 77% of it taking longer than 10,
doing 214 survey requests, 50% of which are ad-related.
Yeah.

Take a moment to wipe away your tears.
Turns out we found a solution for the first page load.
And surprise, surprise, we call it AMP.
AMP, short for Accelerated Mobile Pages,
is an ecosystem consisting of web components library that
allows you to declaratively write
HTML we call AMP HTML, because it's
both a superset and a subset.
And AMP caches,
basically CDN's, or more technically correct,
reverse proxies that accelerate the delivery.

Now, if you've already read about the individual advantages
and disadvantages of Progressive Web Apps versus AMP,
you have surely struggled with this question before.

AMP or Progressive Web App?
Instant delivery and optimized delivery, or the latest
advanced platform features and super flexible application
code?

In the end, what matters is the user journey.
The first hop to your site should feel almost instant.
And the browsing experience should get more and more
engaging afterwards.

AMP and Progressive Web App are both critical components
to make this happen AMP pages for the first navigation,
and your Progressive Web App for the onward journey.

There are two ways of combining the two-steps I personally
call AMP up and AMP down.
Now, AMP up is the background bootstrapping
of your Progressive Web App shell.

While the user is enjoying your AMP page.
And then number two, AMP down, describes
reusing AMP pages as a data source for your Progressive Web
App.

So the basics with AMP up are that the first click
will be an AMP page, usually served from the AMP cache.
But any links on that page will navigate
to your Progressive Web App
Now normally, that second click would still
be considerably slower than the instant-feeling, preloaded,
first click to your AMP page.

But there's a powerful component baked into AMP--
the tag.
It allows you to install your service worker
for your origin--
yes, even when your AMP page is served from the AMP cache.

That means while the user is reading the article,
the service worker can warm up and precache
the entire Progressive Web App app
shell and some initial data.

When the user now clicks on any link on the page,
or call to action at the bottom, your Progressive Web App
shows up instantly.

Start fast, stay fast.
This is what I call AMP up.
But now you're in the Progressive Web App,
and chances are most of you are using
some Ajax-driven navigation that fetches content via JSON.

Now, you can certainly do that, but now
you have these crazy infrastructure
needs for two completely different content backends.
One generating AMP pages, and one offering a JSON-based API
for your Progressive Web App.

The AMP team has asked themselves
the logical next question-- what if we could dramatically
simplify backend complexity by ditching the additional JSON
API and instead reusing AMP as a data format for our Progressive
Web App?

We started with a proof of concept many months ago
and iterated on it for a while, rewriting many parts of AMP
to make it a reality.

So how do we do it?
The process looks like this.
The Progressive Web App hijacks navigation clicks,
then does an Ajax request to fetch the requested AMP page.
Third, puts the content into a new Shadow Root.
And fourth, tells the main AMP library, hey,
I have a new document for you.

Check it out.
Which, in other terms, means calls
attachShadow Doc on the runtime.
And then you have things like Shadows Slots
and advanced CSS classes to insert advanced widgets
and functionality into your AMP pages
from the Progressive Web App.

Now of course, you can do that last step manually
by regexing the source of the AMP page,
but the key is that the above is easy for everyone.

OK, finally, time for an even more advanced pattern I
call AMP Konami Code, because it's up, down, left,
right-- all the things.

So we have a pretty good experience now,
but if you are in the Progressive Web App,
copy a link, and share it on Twitter,
that link will open the Progressive Web App directly.

And for a new user who doesn't have a warmed up service worker
cache, it won't feel instant.
That, too, is a problem we can solve in the final step
of our development journey.

Instead of creating a separate URL space for the Progressive
Web App-- for instance, pwa.yourdomain.com/article--
like we did before, we reuse existing AMP URLs
to load the Progressive Web App on the site's origin.

All we need to do for this is to listen for navigation requests
in the service worker.
Then, instead of serving a cached AMP page,
we serve the cached PWA shell, which
then does an XHR to fetch the requested AMP doc.
This means that in just one request,
your Progressive Web App would show up along
with the requested content.

Best of all, we now progressively
enhance our AMP pages with our Progressive Web App.
And showing that no matter what, your users
will get a super fast experience.
For browsers that do not support service worker,
they'll simply see AMP pages.

So now, one additional thing we build
is called fallback URL rewriting.
And this means that even for browsers
that do not support AMP caches, we're giving to you the ability
to rewrite links to another URL space that
is a fallback URL for your Progressive Web App.

And there you got it.
We've successfully combined AMP with a Progressive Web App.
Now the user always gets it fast experience, no matter what.
Your site is progressively enhanced.
You have less backend complexity because you have just one data
source, and profit from the built-in performance of AMP
everywhere, even in your Progressive Web App.

Before I leave you, keep in mind this is just one pattern
to build sites, and it won't work for everyone.
You probably shouldn't build the next Air Horn or Gmail with it,
but focus on sites that have lots of leaf nodes--
individual sites with static content.

By all means, find out if the pattern
is the right one for you, and feel
free to get in touch to discuss.
Check out our React-based demo and learn more about AMP
and Progressive Web Apps individually on amp.dev
and developers.google.com/web.
I can't wait to see what you will build.