[MUSIC PLAYING]
KINUKO YASUDA: Hi, everyone.
I'm Kinuko.
I'm the tech lead of
[INAUDIBLE] projects
for the web platform in Chrome.
RUDY GALFI: And I'm Rudy.
I'm the lead product
manager for AMP at Google.
KINUKO YASUDA: This
presentation is
a bit of preview of two
upcoming APIs, web packaging
and portals.
With these APIs we
believe that you'll
be able to take
that low friction
agent to the next level, and
create a zero friction user
experience.
I hope you like it.
Let's dive right into it.
RUDY GALFI: All right, so
here's a slide showing a slide.
To be more precise, this
is one of those old school
projector slides.
In their day, slides like
these were a useful way
to communicate, or held
important memories for people.
To view the slide's
content, the projector
needed to mechanically
position it
into place, so that the light
source would shine through it.
And for those of you
who might have watched
one of these old
school slide shows,
you probably
remember how tedious
it was to progress
through each slide.
This kind of makes
me feel, you know,
like how we think about the
web today, the same feeling.
Just like progressing
through cylinder slides, when
you browse the web today you
can feel all the navigations.
Today the web is
used a lot on the go,
say in between meetings,
in an elevator,
or maybe you're on
a poor connection.
When I've got limited
time, focused on my phone
before the next
distraction comes along,
spending five seconds or longer
staring at a white screen,
waiting for the
content to come in,
for the page to be interactive,
that's incredibly noticeable.
Many of you may have
observed we used
some exaggerated long
transitions on our own
slides so far in this talk.
Don't worry.
We're going to put
an end to that soon.
Those were just
one second fades.
Think of how used to
the cycle of reading
and then waiting,
reading and then waiting,
that we've kind
of grown used to.
We think it's time to do better.
And we have some ideas to
help you create seamless,
zero friction user experiences.
And that's what this
talk is all about.
KINUKO YASUDA: So
our desire to see
seamless user experience
on the web, it's not new.
In Chrome 13 back
in 2011, we launched
a feature called Instant Search,
which provides the search
abilities for user experience.
It did so by pairing the
[INAUDIBLE] user would
most likely click on.
However, the feature only
worked in limited scenarios
for various reasons.
In particular,
for privacy reason
it only worked for
the search results
the user had already
visited and for which
we had a high confidence
of user interest.
Then in 2015, another
example with [INAUDIBLE]
user experience was launched.
I'm talking about AMP.
Rudy is going to walk
us through what it took,
and where things are headed.
RUDY GALFI: So as
Kinuko said, advancing
the state of the
art in page loading
has always been of intense
interest to us at Google,
and for Google Search.
We point users to a
whole lot of web pages.
And thinking about the
totality of the experience
that the user gets,
we really want
it to feel as fast and
as seamless as possible,
even as the user
goes off of Search
and into the whole
great world of content
that they're looking to explore.
When we started AMP,
we were intent on using
the full power of the web
platform that was available.
But where we wanted
to get was here.
And we felt that
what we could achieve
in a scalable way on the web
kind of just got us up to here.
So we gave it a
bunch of thought,
and came up with an
architecture for instant loading
that could work on today's web.
It's still what we use today.
First, there's the AMP
JavaScript library.
It helps to ensure that the
experience is fast by default.
And this is enforced by
a validation step, which
helps keep the
experience fast, even
as the site is getting updated.
The next layer was thinking
about how server response
times can vary a lot globally.
And not every site is situated
on great infrastructure.
Also, as we've seen earlier,
sticking huge images
into pages intended for mobile
viewing is still pretty common.
And so for these reasons
we added the second layer
of caching, where we can
ensure that the content is
pushed to the edges of the
network for faster delivery.
And we can do common
sense optimizations.
And last, truly
the best thing we
can do to get load
times down to zero
milliseconds is to
prerender the content,
use our psychic powers.
As we just discussed, this
was attempted in Search before
with Instant Search.
However, you need
to think really
carefully about the privacy
implications of such a design.
And we had trouble scaling it.
The cache will actually help
us complement this prerendering
very well.
And Kinuko will explain
more about that in a moment.
So we got all of this stood up.
And this is where we ended up.
Most of what you're
looking at here
is what we call the AMP viewer.
That's the page you're visiting.
It's responsible for
displaying the content served
through the AMP cache for
speed and privacy reasons.
However, you'll notice by
looking at the address bar
that the URL is still
saying google.com in it.
To help the user
understand where
the content they're
viewing came from,
we had to add an
extra piece of UX
to the top of the
content area of the page.
The idea of the instant
loading was achieved.
But the design
constraints that we faced
and the work arounds that we
had to build for them ended up
being put on full display
in the product experience,
and that wasn't great.
So we hear a bunch of
feedback on this, maybe even
from some of you.
So earlier this
year we started down
this path to make the
URLs for AMP pages better.
And after having AMP in
the wild for two years,
we decided it was time to
take all that we had learned
and develop the necessary
primitives in the web platform
directly.
So we could make all the
content across the web
be able to benefit from
this kind of technology.
So this means that
for the cases where
you click on a link in
Search and it's just
a simple navigation, then
we want the publisher's URL
to be the one that shows
up in the browser's address
bar, while still having the
instant, or nearly instant,
loading experience.
KINUKO YASUDA: So Rudy
talked a lot about the
how AMP has been pushing
with the goal of highly
optimized user experience.
There was a lot of special
handling required because
of a gap in the web platform.
We are now taking inspiration
from past efforts,
like AMP and the Instant
Search, and trying
to eliminate this gap by
extending the web platform.
And by doing so, we also want to
enable this zero friction user
experience across all
content on the web.
We are working on multiple
proposals to achieve this goal.
But in this talk, we'll
introduce two new [INAUDIBLE],,
web packaging and portals.
So let me start
with web packaging.
As the name implies,
it's meant for packaging
a piece of web content.
We think it will enable
various interesting use cases.
But let me start
first explaining
how it can help instant
navigation both for AMP
and non-AMP content.
So stepping back, [INAUDIBLE]
wanted to make web content
load instantly and reliably.
Here's why it's hard.
When you publish
something on the web,
in the simplest setting,
you'd have a server.
And your content would
be a project there.
Then someone browses
your content.
But the server
might be overloaded.
And your content
will load slowly.
Then the experience not good.
So what could we
do to improve this?
One way would be to
prefetch your content.
Suppose that your content's
linked from a popular traffic
source site.
When a user visits the site,
it can trigger a prefetch
when it thinks that the user
is about to visit your content.
Then because the content is
already in the user's cache,
the navigations
happen very fast.
Unfortunately, the
prefetched websites
can learn about the
user's interest,
even if they don't
visit the website.
One way to fix this would
be for the referral site
to add a cache here.
Then the referral site could
bootstrap the [INAUDIBLE]
in a privacy-preserving
manner, because it
could let the browser prefetch
your content from this cache.
This fixed the privacy
concern and the content loads
instantly.
So is this the holy grail?
No, not yet.
As already explained,
this design
ends up in full
display in the product.
The browser's address
bar shows the URL
of the referral site instead
of the UI's because this
is where the browser thinks
the content is coming from.
This is confusing to the users.
The issue is that
the web platform
doesn't provide a proper way to
let others bootstrap your page
loads.
But what if your render
critical resources
could be shared with
popular traffic sources,
and [INAUDIBLE] on your behalf.
This would let traffic
source bootstrap [INAUDIBLE]..
And when the user
navigates, it's
just a regular page load from
your servers, only much faster.
So how can we achieve this?
The browser needs
a way to verify
the true origin
of resources that
are served by a fast cache.
This can be done by
adding a proof of origin
on these resources,
which is exactly
what web packaging provides.
So let's see the actual
standard proposals.
Web packaging is not the
name of a single proposal,
but an umbrella concept for
multiple spec proposals.
The most important one
is Signed Exchange.
It's basically a format that
represents a single HTTP
exchange, or a pair with
HTTP request/response.
Very simple, except
that it's digitally
signed so that the browser can
verify the origin of resource.
There's another
proposal building
on top of Signed Exchange
called the Bundled Exchange.
This is a bundle of exchanges.
Therefore it can represent
multiple resources
in one package, like
a whole web page.
We think that the
Bundled Exchange
will enable other
interesting use cases,
while we start to do
the Signed Exchange,
since that's the
key building block.
And after a year of work,
we are pleased to announce
that we are starting
an on-prem experiment
of the feature on Chrome
71, which is in beta now.
You can play locally with
it by enabling a flag,
or can join the experiment
to enable it on your site.
Please visit bit.ly/try-sxg
to find out how.
We'd love to get your
feedback on this.
That will help us improve
this feature more quickly.
So in order to create
published Signed Exchanges
for your resources, you
need to first acquire
a certificate that can
sign exchanges and host it
at a public URL.
Such a certificate can be
created at DigiCert today.
Once you do that,
you can generate
Signed Exchanges
for your resources
by using an open-source tool.
This process is very manual.
But we'll talk about the
options later in this talk.
RUDY GALFI: So the
origin trial process
is needed for sites
that are going to link
to Signed Exchange content.
That could be your own site.
But it also includes
platforms like google.com.
So we've gone ahead
and enrolled google.com
in the Signed
Exchange origin trial.
And we'd now like
to show you a demo
of using Signed
Exchanges for delivering
AMP content from Google Search.
To walk you through
it please join me
in welcoming to the stage
Sumo from 1-800-Flowers,
and Rustam from Cloudflare.
[MUSIC PLAYING]
SUMANTRO DAS: Cool.
Hey.
Thanks, Rudy.
AMP has provided a
prominent pathway
for user discovery of
results and brands.
You could use it to close
a gap between discovery
and speed to engage, thanks
to an active developer
community and thanks to a roll
out of new web components.
Web packaging further
deepens the experience
of providing native UI,
while serving the benefits
from the AMP cache.
Today we're excited to demo an
example of web packaging live.
Are you ready?
Check it out.
Let's search Christmas greens.
Here we are.
So notice in the search
result the AMP badge.
It's prominently featured.
So you know instantly this
is an AMP search unit.
I click on it or tap on it.
And instantly, as
Rudy was mentioning,
you see that there's no
Google in the URL head, which
is pretty key over here.
Because now you instantly
feel that you're
natively on the website versus
being on a separate cache.
Boldly enough you also see
that there's no viewer header.
So that adds further to
the prominence that you are
actually on, in this
case, 1-800-Flowers.com.
Furthermore, having
attribution so seamless just
adds to a much more
confident realization
for a lot of brands,
that now there
will be absolutely 100%
attribution going from the SERP
to the native site.
And a big shout out
really to the AMP team
and to the Google Mobile
consultants team, who've really
been pushing the boundaries
of UI/UX enhancement,
and really making
sure that the web is
taking all the strides possible
to go to the next level.
Rustam, do you want to go
through how this works?
RUSTAM LALKAKA: Sure.
Thanks, Sumo.
SUMANTRO DAS: Cheers.
RUSTAM LALKAKA: So let's
look under the covers
and talk about how you would
actually deploy something
to support Signed Exchange.
So at the top here in green
we have the request flow
from your origin
through a front end
proxy to your user's device.
On the bottom, you
have the request flow
into the AMP cache.
And in between you
have an AMP packager.
This prepares the
documents for the cache
and signs them to
support Signed Exchange.
Now at Cloudflare, we
sat down and thought
about how to use our
global programmable network
to make this all simpler.
And this is what
we ended up with.
We took all the logic necessary
to support Signed Exchange
and built it into a
Cloudflare worker.
This sits at our
edge and supports
both the cryptographic
operations, the packaging
operations, and the logic
necessary to arbitrate
between the user and
AMP cache request flows.
So you might be asking,
what's a worker?
And simply put, it's
V8 running on the edge.
This allows you to write
JavaScript targeting
the service workers API,
deploy it to our edge,
and have it running
instantly in 155 locations.
Supporting Signed Exchange
and this packaging experience
is a great example of what
Workers is capable of.
So in addition to
releasing the code that
supports this demo,
so that you can all
build your own Workers
to try Signed Exchange,
we also plan on building a
full fledged Cloudflare feature
to support it at launch.
Cool.
Back to Rudy.
Thank you.
[APPLAUSE]
RUDY GALFI: All right,
thank you, Sumo and Rustam.
So if you're
publishing AMP content,
we'd like to invite you to
try out a developer preview
of Signed Exchange AMP
content in Search using
the instructions at the
link up on the slide,
g.co/webpackagepreview.
You can learn more about
creating packages and building
an end-to-end flow,
like you just saw,
for your own AMP content.
KINUKO YASUDA: [INAUDIBLE]
will we be seeing the benefits
that Signed Exchanges
bring to AMP publishers.
But it's important not to forget
that this will also benefit
all pages on the web too.
Now, I want to show
an additional example
of regular cross navigation.
On a slow network, the
content will load slowly.
On the other hand,
the right side
shows how it can be done with
a prefetch with web packaging.
You can see that the
user is navigated
to a page on a different
site instantly.
The prefetch is down from the
cache of the referral site.
So they are [INAUDIBLE] in
a privacy-preserving manner.
So [INAUDIBLE]
how to use the web
packaging to realize
privacy-preserving instant
navigations.
But you know, we're still
doing navigation, right?
So it still feels
like we're progressing
through pages at a
disjoined experience,
not a nice, seamless experience.
And we've been wondering
how we could improve this
even further.
And let me introduce our
latest proposal, portals.
So let's see what we mean by
navigation versus transition.
Maybe it's not too surprising.
Again, this shows
regular navigation.
This loads slowly,
depending on connectivity.
And it breaks users flow.
And the right side shows
an example of a transition.
As you can see, when the
user taps on the article,
a nice and seamless
animation is triggered,
creating a sense of continuity.
The navigation just
happened without being
felt. The navigation
[INAUDIBLE] that it's worth
taking a closer look and can
be seen from the address bar.
So user starts their journey
from a page on feed.glitch.me.
And when the animations
are finished,
the user ends on another
website, news.horo.jp.
So it's a cross-site transition.
Combining portals and
the Signed Exchanges
enables these types
of user experience,
while preserving
the user's privacy.
It might not be interesting yet.
But portals are not limited
to cross-website navigations.
Let's take a look at how
it can improve the user
experience of a single website
built with multiple page
architecture.
I'd like to thank
Hatena at Yeung Jump Web
Comics, our partners
in Japan, who
we worked with to create
this early exploration
for their reading
manga on the go website
called the [INAUDIBLE].
So let's see the user
experience without portals.
When you reach the
end of a chapter,
you see an instance
to [INAUDIBLE]..
As you can see, it takes time
to load the next chapter.
That's because the website
is using multiple page
architecture.
And it needs to load a
new page for each chapter.
Now, let's see how that
could look like with portals.
At the end of a chapter, we
can prelaunch the next chapter.
It makes the
transition seamless.
Pretty cool, right?
The beauty of this is that
you can have this smooth user
experience without
having to re-architect
your website into single
page app, which is,
as you know, a non-trivial
amount of work.
So what are portals?
Portals are like iframes.
You can create one
as an embed element
of a page using a portal tag.
At this point, it looks pretty
much the same as an iframe,
and then navigate to an element
by calling an activate API.
When that API is
called, the element
is detached from the page and
becomes the new top-level page.
You can also add an animation
to smooth out the transition.
So what are the differences
between portals and iframes?
The biggest difference is that
portals can be navigated into.
And as I understand
the differences,
the portals are always created
as top-level browsing context,
whereas as it can
still be embedded
in a page like iframes.
Let's recap the benefits.
Portals enable seamless
page transitions,
like what you get
with single page apps,
but without having to
re-architect your site,
and even across
different origins.
So you can just build you
website using multiple pages,
and can connect
them with portals.
So here's the example of
code snippet of portals.
You can create a portal
as an HTML element,
and then can append it to
the page to help it embed.
Then when the user touches
the embedded portal,
you can show a nice animation.
And the calls activate the API
to make the actual transition.
That's it.
Exciting, isn't it?
And you probably want to
know the current status.
We have an explainer on GitHub.
Visit bit.ly/portals-spec
to learn more.
Chrome implementation
is in progress.
We are aiming for an
origin trial next year,
and are eagerly awaiting
your feedback that will
help us refine this proposal.
So that's basically all
from us about low friction
to zero friction.
But I have one more
topic, Bundled Exchanges.
So remember that we hinted
at Bundled Exchanges earlier?
They allow multiple resources
to be bundled in one package.
And you might be
wondering about the kind
of status of the development.
So while the Chrome team has
started building a prototype
to explore the
possibilities, we think
this could enable
interesting use case
scenarios, like offering PWA
installation, and much more.
Here's an example up
at News-Reader PWA.
This is based on
[INAUDIBLE] read up
built by one of our
awesome [INAUDIBLE] folks,
and now runs on a custom Chrome
build to use Bundled Exchanges.
The app allows the user to read
a news site in a reliable way
by letting [INAUDIBLE]
circle download
and save the
articles as bundles,
if the news site provides them,
so that the user can later
read the saved articles
from multiple sites,
even while offline.
Notice that the
articles are still
shown as coming from
the original news sites.
And the sites keep maintaining
the control over them.
Here's another example.
As you may know, loading a large
number of resources is costly.
In the bundling of them,
in one big JavaScript file
using bundles like webpack
is a very popular technique.
We did an experiment to see
if Bundled Exchanges can
be used there, which
could allow the browser
to process in the cache
individual resources
in the bundle, without
executing the JavaScript.
And one of our results
looked like this.
While still preliminary, it
looks promising, we think.
So we think there's
some potential
and want to know what you think.
RUDY GALFI: All right, so let's
go back to the main topic,
and wrap up this talk.
So we talked about two new
proposals for zero friction
user experiences.
First, web packaging enables
privacy-preserving instant
navigations.
And second, portals enable
seamless transitions
between pages or sites.
Combined together to enable
zero friction page transitions
on top of any web pages,
even across origins.
KINUKO YASUDA: And here's
a look at the roadmap.
Our plan is to ship
Signed Exchanges on stable
by the middle of 2019,
and also, to start
on origin trial for portals
sometime around then, as well.
RUDY GALFI: And so
for Google Search,
we're really excited about both
Signed Exchanges and portals
as a path to building more
zero friction user experiences
across the whole web.
Following the
footsteps of the demo
you just saw
earlier in AMP, we'd
like to launch support for AMP
Signed Exchanges next year.
We're also actively working
on how non-AMP pages can
adopt these same technologies
for highly optimized user
experiences.
KINUKO YASUDA: We believe that
there will eventually just
have highly optimized
content on the web,
regardless for whether
it's AMP or not
with all the standard
work we are doing today.
And we've been engaging
various partners as well
as other browser
vendors, because we
want to refine what we have, and
want to make sure that it will
help them and developers like
you achieve highly optimized
user experiences.
For instance, such teams
at Bing, [INAUDIBLE]
Japan, Bai [INAUDIBLE],, content
publishers and web developers
at 1-800-Flowers, Hatena,
Yeung Jump Web Comics,
CDNs and certificate
authorities, such as DigiCert
and Cloudflare, as
well as folks working
on the decentralized
web at Protocol Labs.
RUDY GALFI: We hugely
rely on your feedback,
and are eagerly awaiting
to hear what you think.
Here are the important
links that we referenced
and that you can check out
to learn more and share
your opinion, and give us input.
You can also come to the Ask
Chrome area in the next break.
And we'll be there to
answer your questions.
We're really excited about
the future of the web
and enabling the
kinds of experiences
that we showed today,
and will appreciate
your help in joining us to move
these technologies forward.
Thank you.
[MUSIC PLAYING]
