Duration 32:53
16+
Play
Video

Building a seamless web

Dru Knox
Product manager at Google
+ 1 speaker
  • Video
  • Table of contents
  • Video
2018 Google I/O
May 8, 2018, Mountain View, USA
2018 Google I/O
Video
Building a seamless web
Available
In cart
Free
Free
Free
Free
Free
Free
Add to favorites
20.28 K
I like 0
I dislike 0
Available
In cart
Free
Free
Free
Free
Free
Free
  • Description
  • Transcript
  • Discussion

About speakers

Dru Knox
Product manager at Google
Stephan Somogyi
Software Engineer at Google

About the talk

Chrome is making it cheaper and more reliable to build quality user experiences on the web. Learn about the new APIs and development patterns coming to the web that help sites achieve great performance and user experiences by default, even with embedded content.

Share

Hi, everyone. My name is Drew Knox. I'm a product manager on Chrome web platform team. I focus on making the web and easier platform to build on which is what I'm here today to talk about. So without further Ado, let's Jump Right In. I may be a little biased when I say this, but I think the web is one of the most amazing things humans have ever built not just the internet have to be true. The internet is its own Wonder but the web is an open Computing platform that stood the test of time and that's really humbling

to me right on every day. It's in every users pocket. It's on our wrists. It's in our homes, but we got there through collaboration and consensus-building. We worked across individuals businesses even governments to develop a Commons that's not owned by anybody but certainly nurtured by many people along the way and I don't think there's any other platform like that. Turn Chrome, we're really proud to play a leadership role in the web. But it always sits in this context write the web strength

stems from that collaboration and openness. So this talk is about something that we're excited to share with the Webb community. But more than anything it's about starting a discussion because once the web Community gets involved, that's really where things start to matter. Not the web success carries with it expectations. As technology is increasingly embedded in every part of users lives. They're expecting more and more from the digital experiences that they interact with. It's not just about the content or service you provide anymore

these days. You need to delight at every point if you want to keep up. And this isn't just a thought experiment we've seen again. And again the people who put the time and effort into delivering on these expectations Reef big business rewards. You can't afford to stand still or someone else is going to grab the opportunity. Requirements are increasing across the board. We see three big areas where user expectations are ramping up rapidly right now. Users want their site to load

instantly. I study found that 53% of users will abandon a site if it takes longer than 3 seconds to load. You could be losing half your customers before they even senior site. But delivering these kind of load times is really hard Crohn's official recommendation is only 5 Seconds. We know how hard it is to hit the 3-second target. But the impact of getting these load times down is very real. Internal Chrome data shows that 20% of all mobile Android page loads are abandoned because the site takes too long to load and that's not a specific

page that sent one out of five of all page loads on mobile is abandoned. The next area where user expectations are skyrocketing is the quality of your sights interactions and user expectations. Here are really draconian. In order to avoid any negative user perception you need to respond to every input within 50 seconds. And no matter what your side is doing. You need to run animations at 60 frames per second. It's true. The quality of your site's design is tougher to nail down then something like loading

speeds, but it doesn't make it any less important as we mentioned in the web keynote earlier today Pinterest improve their own engagement metrics by 60% when they revamp the quality and performance of their website. And if these issues weren't enough users increasingly expect your service to be accessible everywhere, that means all of their devices their phone their laptop you name it, but increasingly it also means across all of their services things like Facebook or SnapChat. This leave you delivering increasingly higher quality while supporting an

ever-growing Matrix of development platforms. We think that these problems represent three big opportunities for the web to go further than simply making things possible. We want the web to actively support you in finding success with these three key areas. How quickly does your experience load? How high quality is the design and interaction of your page? And where can users find you? How is all might seem daunting and we certainly have our work cut out ahead of us. Web developers. Have a leg up on everyone else here. Cwa's

and the web generally leave us well-positioned to embrace these kinds of new user expectation. For example book my shows pwa is 180 times smaller than their IOS app, which makes it much simpler to meet that 3 second load Benchmark for first time users. And in terms of building high-quality, you act new users on make my trips pwa convert three times as often. And Technologies like service worker or the purple loading pattern give you unprecedented control over how you deliver your app combined with add to

home screen and push notifications. Just let you deliver deeply engaging experiences that can load instantly for users. And perhaps most obviously the web is cross-platform by default, right that's been true since the very beginning being everywhere is built into the DNA. It's just how we do things. To building a pwa and choosing the web is like starting 100 m down the track. But these Technologies they only make it possible to build incredible pages in the power and flexibility of The Primitives. I just mentioned for a lot

of people who just want to get their business out there. They just want to focus on delighting our users. Unnecessary, they just make building their sight more complex. So we think it's the web can do more to make incredible pages easy to build not just possible. To talk about what we're doing to make them easier to start things off. Let's hear for my colleagues at the van about what we're doing to create more options for Content delivery. Hi there. So, my name is Jeff and I'm also a product manager on the Chrome platform team. And today I'd like to talk to you about some standards-based

technology that were very actively working on right now to improve how to deliver content on the web. If you look at this very standard progression of sharing a link with a friend via chat. You get the link through the menu you paste a link we provide a nice screenshot of it, but wouldn't it be cool if we could share the actual content rather than merely the link but we'd like to be able to do is to save the pay range or potentially a web app, just like what you was talkin about this allows for useful new applications for example offline pwa installs.

What we need is a way to distribute content on the web. That doesn't rely solely on it coming from exactly the same place that it was originally published from now as useful as this notion is we also need to make sure we don't break anything while we're doing all this so we don't want to break attribution. We don't want to break things like integrity. So in order to do that, we're working on some technologies Under the Umbrella of web Packaging. This is currently being done as part of the ITF standards development process. What packaging is currently and

ITF draft and we think this collection of Technologies in this approach is going to be very powerful new set of Primitives which allows for simpler loading architecture and potentially very interesting to use cases. So the first step along the way to getting when packaging is this notion of signed exchanges? Signed exchanges provide a way to associate shared content restored content with its origin in a way that is verifiable and secure. Assigned exchange is basically an HTTP exchange

with a digital signature wrapped around it that has a number of notable features. One of which is the duration of validity how long this web package is intact valid. We want to create a default mechanism that encourages the browser to verify at appropriate intervals that the content is still the most current if the package has a problem or if it has a very short contact Half-Life you want the user not to have spell contacts you want to have a guarantee of Integrity. So there's a hash in there which is again within the scope of the digital signature and the hash

tells us that the content has not been changed in any way since it left the publisher and finally within scope of the signature is also the web origin of the publisher. This is going to come in handy very shortly. Now in the future we're still working on it. So there's still stuff that needs to get done. We will also have things called bundled exchanges bundle exchanges have all the characteristics of a signed exchange plus actually come with all the assets. So it's everything that you wanted with some guarantees about provenance and about integrity.

So let's imagine the near future world that has web Packaging. Let's say we had you know, the news aggregator for example, and let's call it a procrastinator you subscribe to a bunch of content you have headlines delivered to you when you want to procrastinate and it all just seems like a very straightforward type of application now for site like this. There are several facets of a packaging that can serve you very very well now imagine we have a friend Dave. Davis very enthusiastic Davis also a bit of a click bait Cannon. So he tends to send us lots of links with

very hyperbolic introductions. And so he says this is a mind-blowing article Center success rate is generally pretty good. We're going to click on this link. So when we do this is what we get. It turns out they was right. This was a mind-blowing Lee popular link and the originating server collapsed into the load. Now let's imagine. This was a site that you already subscribed to and procrastinator are server the procrastinator server could very well have already downloaded a bundle exchange with all the content that belongs to that page and it can then display

for you. The site is down or super super slow. But you're still getting your content because the article the CSS the images it's all coming from the procrastinator Service as part of the web package. No matter what happens. The content is available and although this content is served by someone other than the original publisher. You still have the guarantee that it's the same thing that the publisher originally sent out. Now what happens if you have no conductivity at all fortunately is open web all the way down.

So if there's no conductivity, it turns out we're using a service worker to render this and service worker can cash resources one of which can be the bundle exchange. So despite the fact that the originating blog Server doesn't intrinsically support offline by using these mechanisms you effectively get offline reading for free which is incredibly handy when your conductivity fails or you're in an aircraft without Wi-Fi. Now this is a visualization of a potential future of web packaging including bundled exchanges which are a little ways off still but let me give you

much more concrete example much more immediate examples. Well now what amp appeared on the scene about 2 years ago. It proved that we could deliver a user-focused Snappy with experience. And if you were at the state of the web session earlier on you know, the median low time display time of am page is still very very low. One thing that didn't work out. So well with an was the user confusion caused by seeing a page from a publisher but not having that Publishers URL in the address box. So let's see what happens in an old free world. We

look up chocolate chip cookies. We find an app page which has the recipe and if we look in the address bar, it still says google.com amp. This is today without web packaging not ideal. So in a world with web packaging we enter the same query chocolate chip cookies. We got the same package in this case Chrome is telling us what packaging is involved. That's what that blue Banner is Will tap on the recipe. It's the same thing. It's very responsive. And when we go up into the address bar, it shows Food Network rather than Google

a lot of technology behind the scenes to make this happen, but the user experience is one where there is no longer any confusion where it's very clear where the content is coming from our friends at Food Network who stunk a bunch of time and energy into getting their content ready and working with our tooling to enable this particular demo. Sweet also like you to try this for yourself. It wouldn't be very sporting if we just kept all this to ourselves. So if you are using Chrome Beta or do I have at the moment on Android if there is a flag that you can flip to enable signed HTTP

exchanges the Chrome loading team, which is based in Tokyo has been doing a ton of work to make this happen. You can try this out on your own if there is other tooling available to help create somebody signed exchanges and in combination, once you flip the switch, you'll be able to test it out for yourself and get a better sense of how this technology works. For those of you who are interested in delving even deeper and really understanding the full scope of why packaging. I'd encourage you to take a look at the speck here at this link and is probably way more information than you will

immediately know what to do with and with that fact of Truth. Thanks very much. All right. Thank you. Stefan has already feeling good about halfway through her. So so will power through. Now we just heard about how we're thinking about making loading easier. Let's talk about how we're going to make it easier to build pages that stay fast and responsive after they've loaded. I'm going to think about what makes this hard on the web today. I think of an overgrown jungle. Another wave is a

thirty-year-old platform and its focus on backwards compatibility for most of his lifetime. They don't get me wrong. This is a huge strength to specially for the stability of your business. But it also means that there's a lot of crust that we've accumulated along the way. And if we go back to the person who just wants to Delight users are just trying to get their business out there. If you're just going from point A to point B, there's a lot of best practices and rules of thumb that you need to keep track to keep your page successful.

Then this reminds me of board games versus video game. video games track a bunch of rules on your behalf And this allows them to have far more complex experiences and interactions. Another hand with board games you find yourself spending a lot of time. Just moving things along making sure the rules are being followed. What's the web did something similar to video game? What if we could make the platform aware of all these rules and best practices that you keep track of today and then based on your needs and goals you can ask the

browser to manage any of those automatically on your behalf. Before we go any further. There are a lot of tools out there like Lighthouse that help track best practices and these tools will continue to be vital. They can be much more opinionated then to Bear platform which allows them to take you further and give you bigger performance game. We can also offer more holistic analysis techniques like the lighthouse report. We want developers to be able to jump right in and start building their website. We don't let them have to commit to an entire tool chain up front. So

we need something that doesn't require any configuration catches problem from the first line of code you write. We want something so that when you apply Lighthouse your very first score is even higher. Handkerchief that we think that the web needs to make these best practices available directly in the platform. Now we're not just guessing when we say this Google's own internal JavaScript development framework has best practices based directly into the platform API surface. This means things like removing dangerous apis or prohibiting calling

patterns that are a performance or security Auntie better. If you use react with something similar of dangerously came out, right they try to get you to avoid certain apis. We found that these rules make developers more productive because they catch errors earlier. They also improve the security of our site. We found it when we turn these rules on WE reduced cross-site scripting vulnerabilities in Flagship Google products by over 75% Xoriguer today to start a discussion with the rest of the web Community. What are the best practices that make the most sense for the web and what's

the best way to build them into the web platform? Rethink future policy is going to play a big role here future policy for those who don't know is across browser standard that's currently implemented in Chrome with positive signals from other browsers. Feature policy allows the browser to express features of the web as a configurable policy. The skin produces and allow attribute where we is the developer can specify what features Chrome should disable. A concrete example shown here is this allows think xhr which is available in Chrome today? You can see it used on an iframe

here, but you could also specify this policy sitewide with a request header. But essentially what's happening is by enabling vsync xhr policy anyone who tries to use the synchronous xhr request will immediately get an error even that new hire who still learning the ropes and doesn't really know that synchronous network access is kind of old school. No, we want to go further than this. We don't just want to turn off API that's only half the battle. We want to create policies that allow you to control more abstract best practices things, like images must have

sizes or don't render content this more than three window Heights off screen. Let me think. There are three areas. That would be a good fit for this. The first area that we think there's a lot of opportunity is images a survey of 1000 sites found that 25% could save 250 kg just too straightforward image optimization techniques on media network connections. That's about five seconds of load time does 5 Seconds you could get back with essentially no extra development work. We want to make it easier to find these kind of low-hanging fruit and a tackle them incrementally.

We have four policies that we've been working on recently. the first requires all images to have sizes this prevents the user experience from jumping around his new images load and resize the page because the browser knows ahead of time how big those images are going to Next we have a policy that requires modern image format this make sure you can take advantage of the fastest coding and high compression rates of modern images. Next we have a policy that prevents image downscaling so it can help you avoid things like loading a desktop image on a mobile device.

And finally, we have a policy that detects poorly compressed images highlighting them to you for further optimization. These policies what happens when an image violates the policy is that Chrome renders it in inverted colors. So is your testing your site that you're looking at? What's going on? You can immediately see those images that need further attention. We're still refining the exact shape of these API out the best way to bake these policies into the platform so that they're useful to you for either for feedback. And so we have a few of policies

available in Chrome Flags. If you go turn on the experimental productivity features flag, you can get access to explicit image sizes and modern image formats today. Will the other time mentioned coming soon. The next big area for improvement is reducing payload size of websites a big site payload is something that our cruise slowly over time. There's not just one massive resource. We wanted to help infrastructure teams that budgets they could enforce across their website automatically so that as each little regression came in they could catch it

and prevent it before they needed to do a full site redesign. So similar to Future policy, what is using something called size policy which creates an attribute that allows you to limit the size of each individual resource type. You can say things like images should never be larger than a hundred KGB or JavaScript files should be smaller than to kilobytes. The specificity of these probably policies allows you to track down individual regression that they're committed resource flexibility means that you can set whatever policies make the most sense for your site your

multimedia side. You're obviously I said bigger policies then a news site. NYC area that I want to talk about today is animation. We want to give developers the ability to specify which properties are safe to anime. Count as save requirements in browser implementations involve you can fine-tune which properties do you want to go out? What is a proof-of-concept to show here today? We have a policy that only allows accelerated animation like transform and opacity no matter what's going on for the rest of your site.

White pill I mentioned before this policy is available behind the same experimental productivity Futures flag. Okay, so I just ran through a bunch of different policies. If you're interested. You can try them behind a flag. Like I mentioned you can also go to this link to find more precise API documentation and information on how to start using these policies in your development environment. Today really excites me is because these features give most of their value at development time, you can start using them and experiencing them even though they're behind Aflac you just

turn them on while your development. But most important is that we want to start hearing feedback on what use cases were missing and which policies are the most exciting. So, please go to the GitHub repo file issues Express support for what matters most to you. Right now automatically tracking best practices is only part of the battle. Another problem is that the web comes with a lot of assembly required? This is great for those of us who want to experiment and push the platform to its limit. Again going back to that person who's just trying to get from

point A to point B. It makes sense really difficult. If you have to build everything yourself or find that perfect library from a third party. And it's even harder when you think about trying to keep the size of your tight payload small? What traditionally the platform has shied away from building high level of productivity features like this because they're easy to get wrong anyone who knows about app cache will probably agree the increase the cost of the runtime even for pages that aren't using the API, right? Everything is global on the web. What we think there's a way to

provide more of these high-level features while avoiding these problems and we're calling the idea layered API. Now that's a brief aside. It turns out the JavaScript modules to provide a pretty good set of characteristics for solving this problem. The future is in the modules are imported. So you only pay a cost for what you use. JavaScript has no special privileges. So if an API doesn't fit your needs you're not left with nothing else to use. You can just dig in and build something that works for your use case could do you could do to it's really just there for

your convenience. Two layered apis are just ordinary one platform features like a div or indexeddb, but they have one really important twist. And that's that they have to share the same discipline as a JavaScript module. They must be imported and they can't do anything that plain vanilla JavaScript couldn't do. That doesn't mean that we can't format in JavaScript, but they behave identically to instead of specifying a remote URL. He's Best Buy a standard platform identifier, but using the same module import

syntax. It just loads of future shipped with the browser. No layered apis because they only do a JavaScript could do they are easy to polyfill right out of the gate which is why we're including a fallback syntax baked in so I'm browsers that don't support a layered API you get graceful degradation without having to worry about feature detection or doing anything special. It just works the same but on browsers that support a given layered API, there's no data to load off the network. It's like standard live, but for the web This is an area that we are actively

exploring food bill to prototypes for layered apis an infinite list components that were calling virtual list and an async local storage API, you can turn these on using that same experimental productivity features flag I mentioned for policies. Speaking of turning things on we tried building something with these ourselves. For any of you who tried to take a look at the HTML spec page, which admittedly might be a small group. It's huge it take a long time to load in your frequently staring at a white screen if you try to scroll because

it's loading a lot of texts all at once. So you can see her on the left the normal HTML spec page and then on the right using the virtual list layered API to incrementally load content as we go you can see that it loads much more smoothly. Right? We don't see these white screens is often. What we're getting here is a modern incremental loading view recycling infinite list implementation and it didn't require loading a third-party library or writing any custom code this work right out of the box. This is just a Prototype 2 that the concept where are you going to keep working with browsers

in the web Community to understand Laird apis generally and the specific shape of these apis, but that process is feedback from you. So take a look at this link. If you want to find out more about layered apis and try them for yourself with the experimental productivity features black just make sure to provide feedback in the GitHub repo to help us evolve this in the best way for Okay, the last topic of you mentioned was getting your content everywhere. So here on Chrome so platform team we want to make it easy for you to

author One definitive experience. We wanted to be portable high quality interactive. Even if a user come to that experience from somewhere other than your top-level, url. I want to make it easy for other services to embed that content and all of its interactivity while preserving users privacy. What packaging is a key First Step here, right the sign exchange allows you to make sure that all resources are attributed to your site so that use your cookies that use any storage your interpretation you set up. And they also allow you to

eventually bundle all your resources in one easily shareable package. But we want to go even further than that want to go out different sites and authors to move seamlessly between one another. This means things like fluid animations from one page to another even if they're separate domain. Animals moving from an embedded interaction to a full-page experience without losing any interactions while you were in bed. Designs here are still evolving. So if it sounds a bit babe, you're not allowed

think of this is a sneak peek or a call to get in on the action. We have a proposal and we are interested in starting a discussion around it. We need to hear others thoughts before we really know what it's going to look like. So if you're interested in how we build something between an iframe and a link something that sits in that middle ground go to the link here and join the discussion. instant loading high quality design and interactions getting your content everywhere. These things are

quickly going to become table Stakes for successful web experience. We want to make it easy to make this transition who want to make it easy for you to find success with the web. So this is really just the beginning of how we can make user experience has more seamless how we can foster content Discovery and composition will making it increasingly easy to build these experience. If you take two things away today, the first is turn on the experimental productivity features flag and start playing with some of the things we've mentioned and send all of your feedback to the GitHub

repos that I linked in the slide.

Cackle comments for the website

Buy this talk

Access to the talk “Building a seamless web”
Available
In cart
Free
Free
Free
Free
Free
Free

Access to all the recordings of the event

Get access to all videos “2018 Google I/O”
Available
In cart
Free
Free
Free
Free
Free
Free
Ticket

Interested in topic “Software development”?

You might be interested in videos from this event

September 28, 2018
Moscow
16
159
app store, apps, development, google play, mobile, soft

Similar talks

Tom Greenaway
Senior Developer Advocate at Google
+ 1 speaker
John Mueller
Software Engineer at Google
+ 1 speaker
Available
In cart
Free
Free
Free
Free
Free
Free
Steve Orvell
Software Engineer at Google
Available
In cart
Free
Free
Free
Free
Free
Free

Buy this video

Video

Access to the talk “Building a seamless web”
Available
In cart
Free
Free
Free
Free
Free
Free

Conference Cast

With ConferenceCast.tv, you get access to our library of the world's best conference talks.

Conference Cast
558 conferences
22059 speakers
8245 hours of content