 So hello. Welcome to a session here on AMP and productive of development powered by AMP. My name is Ben Morse. I'm a developer advocate for Google. My job there is to help the web be faster and easier to use for users and for developers as well. I used to be a full-time musician, which we can discuss if you're interested also. But I'm not here today as really a Googler or, of course, a musician. I'm here today as representative of the AMP open source project. AMP is joining OpenJS. And we're very excited about this. So today my Googler hat is not on. My AMP open source hat is on. So why AMP, first of all? What is this AMP thing? And why do we think it's a good idea to try out AMP? The thing is that the web is a wonderful place full of endless possibilities. It's like cooking. You can use any ingredients you want to in any way you want to, mix and match things however you want to, and do whatever you want, which is great because web should be free. So in a website, you can, for example, have lots of stuff if you want to. You can have lots of images and lots of CSS and code and third party libraries. And you can put on chat widgets and complicated elaborate menus and video embeds. And you can have pixels on there, various sorts, analytics, lots of things, which is all fine and good, useful functionality. The problem can be that when you have a lot of these things on there, it can become a little more like this. It can become a little more of a giant, wonderful kind of mess. And that's fine. That's good, too. You have this right as a web developer. The problem may be also that not just things are kind of complicated to use or might taste funny and strange combinations, but also that a site with lots of JavaScript on it and lots of CSS may be slower. What happens then is people like this here looking at your site, loading up your site there on their phone, and it's not loading. They're looking at their site. They're getting frustrated by it. This guy over here, you see he's taken up smoking and drinking because his site's loading so slowly. And the frustration. So you're going to shorten his lifespan. So to save this guy's life, give him more years to enjoy everything there is to enjoy about Montreal, the poutine here is incredible, for example. You should make your site faster for him. And it isn't just this guy over here. I mean, you may also say, well, my site has a lot of users who have 4G connections and LTE. They live in nice cities where they get great connections. They have top-of-the-line iPhones or Galaxy phones. But remember, also, it's about inclusion. It's about accessibility because last time I checked, 40% of connections in the world were still 2G. And 2G is quite a different experience. I know because I have T-Mobile. And when I travel, I get free, unlimited 2G data roaming. And many sites don't work at all. You can tell, actually, OK, this site's going to load up. I can load Wikipedia. It's going to work. Other things, you're like my banking site. It's never going to work at any point. Or it'll be slow and hard to use. I mean, you guys know this already. You've heard arguments about performance before. We often forget that people in other places in the world or even in this country often can't use sites unless they're made carefully so they can load quickly. Not too much code, not too large images, and so on and so forth. Amp was created to make these problems easier to solve. Problems like slow loading, which we just discussed. But also, if content already has loaded up, and JavaScript is still loading, and parsing, and executing, event handlers are still attaching to things in the DOM, you may have things you can see that don't actually work yet for a little while. You can have a menu or an accordion that you can see there. You can tap on it. But for five or 10 seconds, nothing happens. Also, we think of bad user experience. And also, looking on the right over here, something else which happens on a site. You're looking at a site in your phone, looking at text, or you're about to do something, and then suddenly an image pops in. Everything moves down. Or an ad pops in. Or a video pops in. Something else appears on the screen. I think shift around. Sometimes several times as a site loads. And this kind of unstable content loading is kind of disturbing for the user. And hard to make things kind of feel likable, and trustworthy, and accessible. So AMP was designed to fix these kinds of problems. Of course, you don't need AMP for these things. You can't fix it yourself right away. You're supposed to get it to programmers. You can use JavaScript to make things better. And you can make things easier for the user in all these ways. The problem is, it's pretty hard to actually do. Because we see on the web that most people don't do these things at all. We see that very few people lazy load images. We still see a web full of a megabyte of unidentified JavaScript. It's hard for people to actually make things fast out there. So this is what AMP was created to make easier for people on the web. So it's why people do say sometimes things like, yeah, everyone's doing AMP. Should I use AMP too? Yeah, you should because Google kind of wants it for SEO. So just kind of do it because Google really expects you to do it. OK, so I'll make this AMP thing. Should I make my site better or change it for AMP or rework it? No, just kind of use a plug-in. And then you just watch the money kind of roll in or something. And some truth to be things because Google does actually give certain AMP pages a nice little badge on search, which shows it's an AMP page. So someone this has some truth to it, but it makes me sad because it wasn't why AMP was created. It wasn't to make these kind of sort of haphazard sites that aren't great and maybe load faster in some way. So what is AMP? I keep saying this word AMP. What is this thing? Simply put, AMP is a web component framework. And it's web components. And it was designed several years ago to create websites that are easier to make and then faster for users. That was the idea. And also, it's since then been adopted to other kinds of purposes as well. So for example, there are now AMP stories out there. The kind of story format that Snapchat pioneered, Instagram made famous on Instagram. These open web stories now exist powered by AMP. Also, AMP is being used in emails now to bring a bit of the web power embedded into emails. Little features you can do with AMP components, like refreshing data or sending things to a server somewhere. Those kinds of things are possible now in email using AMP. And also because AMP makes things faster in general and it can sort of discourages extra JavaScript, AMP has been useful in making ads. Ads are less intrusive and ads that also load more quickly for users. So I said AMP is web components. Here are a few of the possible components you can use in one big jumble, there'll be a quiz later on. Now this is just to show you some examples of the kinds of things AMP can do. So it can embed things, it can embed tweets and there's music players and there's also interactive AMP components, there's iframes, there's all kinds of things. Here's what AMP looks when you use it as a programmer. It's basically an HTML framework. So here's an example of web components. This here embeds a YouTube video on your site. Instead of using YouTube's JavaScript, use this component instead. A few things that are notable about this over here. The first attribute is called layout. It says layout equals responsive. When they have AMP sees this automatically, it will take your YouTube video, it will shrink it and grow it as the container shrinks and grows. It does this all for you out of the box. The width and height are there because AMP wants to know the size of things in advance, that way AMP can leave space for things as your page loads up. So in this case YouTube videos over here on the page, it leaves a blank space for it and then as it loads up, it pops into its space. So AMP guarantees stable layout in your page as well. And then you provide the video ID on the bottom over there and AMP just kind of sticks the YouTube video on your site and that's it. A simple example can get much more sophisticated than this but this is simply what it is. If you make a valid AMP page that follows AMP's rules, there also are web spiders out there like Googles and like bings. They're looking out there for pages that are valid AMP which don't have the JavaScript in the wrong places that will make performance worse, which don't have too much CSS, which follow the various rules for accessibility that AMP encourages. If you follow these rules, web spiders will find these things and they will tell AMP caches to cache your document on the caches. So for example on Google's AMP cache, Google will find these things and then serve your page from its own servers. It gets a little bit of a badge there on the search and then in some cases it will get pre-rendered in an iframe so it loads up almost immediately when the user clicks on it. In other cases it just loads a lot faster. So AMP has this sort of search tie-in as well. So AMP really is this thing about components and about validation if you want to get into these AMP caches. AMP also is used in various contexts these days. It was used at first for simple publisher sites but now we're seeing it all over the place. So on the left is an e-commerce example. This is Aliexpress, you know Alibaba, the very large Chinese company. They made an e-commerce experience for mobile sites with AMP a couple of years ago. Alibaba's a very large company and it's been pretty good for them in production. Various interactive features are possible on AMP. You see the second example there is I think from SBNation. There's a quiz there done with AMP and there's many components now like one on the far right there that have nice UI features like this automatic light boxing over here. Again, doing things you can do as a programmer yourself but AMP tries to make them faster for you and easier for you. So also when AMP was first created, it was used in this paired approach where people would make an AMP page and also a regular desktop page and use both these pages together but we're seeing that more and more it's easier to have a one page than two pages so sites out there like Action Network for example are making their sites AMP all the time. So this is an example of a page image is responsive working on desktop and mobile all created with AMP. That's the basic overview of AMP but now for more details about AMP. I wanna bring up over here my colleague Chris to discuss much more detail. Let me advance the slide for you to your face over here. Yeah, let's do it. Hi there, I'm Chris, it's very nice to meet you all. I'm a performance engineer at Google. My job is to try to make the internet faster. Specifically my goal is 1% faster for all users every single year. So I work on lots of open source technologies and frameworks but I also work on AMP. I wanna talk a little bit about improving the return on investment for your development time. We think that AMP can support this concept of accelerated developer workflows to allow you to focus more on the content and the things that make your domains unique and less on your infrastructure. But first a brief aside, we've talked about AMP but not the AMP project. The AMP project as a whole is larger than just the web component framework. AMP submission is to try to make a user-focused format for the web not locked within walled gardens available as HTML documents that render within any browser. And we think by doing this we can sustain a healthy open web ecosystem for merchants, publishers, and advertisers. If you're using AMP you can also use it across many different surfaces. Sorry, my notes are very large here. So the surfaces that Ben kind of briefly touched on. You can make websites using AMP technologies. You can make stories which are rich visual storytelling tools. You can make advertisements that use the same AMP runtime and cache as documents. And you can also create interactive emails. Interactive emails is fairly new and I think also very interesting. So a good example of this is you can respond in line within your email client to Google Doc directly without having to leave your email client and go to the doc. No waiting 10 seconds for the Google Doc to load. Just reply instantly. AMP stories are captivating and beautiful because they use the landscape, they use the format, the vertical format that your phone is designed with. The way that we all consume format on our devices. This means that we can pair that with great rich visual imagery and we can get a good experience for users of all sorts of different devices. But AMP works across all sorts of things. Not just mobile phones, but browsers and desktop machines as well. It supports every single user agent we can. There are course limitations. We can't support IE 8 anymore but we can support IE 10 which is a huge compatibility matrix that is not found across many technologies. And if you were looking at a high level view of how AMP works, this is kind of it. You've got Origins that contain AMP documents. Those AMP documents can either be served directly from the origin or via a cache that is a distributed CDN by huge CDN partners. Then you have devices that will pre-render that content to make it feel almost instant the moment you touch it. And AMP is really great as a result of this instant pre-loading for a lot of things but it's not perfect for everything. If someone comes up and says to you, there's one framework or one technology that can build every single thing on the planet, you should call them out for it. They're wrong. The web is an open, healthy ecosystem because of so many tools that work together and different technologies and different approaches. AMP is no different. We think AMP is great for content-focused experiences, things that are focused more on bringing information to users but not say Gmail. So as a result, you should use AMP on things like article pages and product details. But if you have more sophisticated workflows like say settings pages or shopping carts or you've got advanced search capabilities, AMP isn't a great fit there. You should use a different technology. You should use something that's more fitting to that use case. AMP is an open source technology. I may work at Google but AMP is not a Google product and I think that's very important to reinforce. The AMP project is open source. It's joining the OpenJS Foundation and we think as a result of this, it will make it much easier to use in the long term. We have public meetings for all of our working groups. I lead the UI and the performance working group ones. There's ones for outreach as well as several other facets. We would love to have new people joining and helping us make a better experience of the web. I want to briefly talk about AMP as a service or affectionately how you can worry less with AMP. Here are the segments they'll briefly dive into as fast as I possibly can get through them. More content, less code, caching and distribution, being always up to date, guaranteed performance, workerized JavaScript and PWA support. So more content and less code. One of the things that's really interesting and been touched on this is that AMP is not a JavaScript framework, it's an HTML framework. And the intent here is to allow you to express your interactions and all the complexities of those types of documents but enrich them in a way that happens over time. It doesn't require a large amount of JavaScript upfront to be functional and usable. But as a result, there is a trade-off. And if you look at what AMP kind of lies in this matrix here, we think this is a fairly realistic representation of it. Vanilla JavaScript, you can do almost anything unless you need WebAssembly, then you can do anything. With a JS library, you probably don't write a lot of vanilla JavaScript, most people don't anymore when it comes to front-end documents. You can use a JS library like a React or a Preact and you're able to achieve a lot of that functionality that you wanted with a little bit less complexity. AMP pulls the complexity down significantly but as a result of that, it's slightly less flexible. And we think this is an interesting trade-off for large swaths of the web. If you're familiar with building content-focused websites, this is a bit what your time looks like if you're using a JavaScript framework. A lot of time spent on performance optimization and build tools and Babel configuration and Webpack, it's a lot of work and a lot of expensive time that you could be using to focus on your content instead. With AMP, our partners that have used it have seen a shift in the way that they work. This is more like their work style now. They spend far more of their time on the things that are custom and unique to their domains. Some of the AMP components also have a little bit of a super power. So AMP Analytics is a great example. Analytics are incredibly important to any page that's making money because you need to be able to track how it's being seen. And so as a result, what happens often is you have several of them and they all starve and compete for attention. Each vendor is monitoring the DOM. Each vendor is spending CPU cycles, capturing information. None of them are coordinating with one another and as a result, you get huge micro task chunks on browsers. So AMP changes this slightly because there's an intermediary later. AMP Analytics measures once for all vendors and then distributes those responses to the vendors using the most efficient form that it can to each vendor. So for instance, it prefers Beacon over using XML HTTP request. And in order to use one of these vendors with AMP, there's a collaboration that happens between people on the AMP project and the vendors. And that makes sure that those things work efficiently on AMP documents. That might make it seem like we won't have very many vendors that work with AMP Analytics, but the great news is that there's already 100 plus that do and this is growing by the day. There isn't a problem about a specific vendor at this point. Most of them are supported, but done performantly. The next item is being always up to date. When you NPM install something, you tend to get a hat version of something like React, but that's the version that you ship. And until you update React, you don't ship a new version. This is great in many ways, but there are also trade-offs. It means that the React team, for instance, couldn't operate it fully independently from your website. They would need you to pull the new version of React in in order to leverage their new code on your site. AMP acts differently. You point to the AMP CDN to grab JavaScript. AMP has a cadence and a release cycle on different release branches that allows you to pick how flexible you want to be, but you always get an up-to-date version of AMP, one that changes and improves over time. A good example of this is animation support. Animations may start by implemented being implemented directly with CSS, but over time, without changing the API contract, move to being implemented by Houdini. But how do we make sure we don't break these documents? Because there are over 100 billion of them in the web. We can't break them is the answer. And so we do a lot of testing, a lot of testing. We have one of the biggest test matrix that you've ever seen for a front-end framework. It's not perfect, of course, but we do our absolute best and we feel reasonably confident here. For four years, we've been doing this and we've not had to roll back a crazy number of times. AMP is built for speed from the very core concepts of how it works. It's a very small runtime that guarantees static layout on the document and allows it to do some performance enhancements along the way. However, if you're like me, you've probably had this conversation a few times. I just want one more beacon library on the page or can you just add that one more third-party vendor? And every single time this happens, I feel like Sad Batman, who realized that he picked the wrong comic universe to build movies in. Well, AMP is also a technical tool for you. If something doesn't work in AMP, you can't put it on a valid AMP document. And in order for that thing to be on a valid AMP document, it has to meet AMP's performance guarantees. This means that we work with those vendors to ensure their code is performant and will work on across the corpus of documents. Good example of this is the above-the-fold layout system, which ensures that only the JavaScript that is necessary for where you're looking at any given time on a page is used. Because we have a static layout guarantee in AMP, we can effectively understand when a component will become on-screen. And in advance of it becoming on-screen, fetch the JavaScript, eval, and parse it lazily. Every one of AMP's constructors in their classes does nothing. The goal is to just set it up to be invoked lazily later. And as a result, we can also deprioritize specific content on a page. So if we're a little CPU bound at any given time, we can tell the ad unit that it's gonna get a bit less CPU. And that's great for user experience, because it means the article remains consistently usable. Now, computers have multiple CPU cores, you can do multiple things in tandem, but the browser doesn't really work that way in general. It tends to be single-threaded. There are exceptions, of course, to this. So if you have JavaScript that's interfering with the main threads processing, it's very difficult to understand how to process the next input. Looks a little like this, and it ends up with something called rage clicks. Brief aside, it's a bit like how the DMV used to work. You'd go to the DMV, you'd wait in line until you got to the front desk, they'd ask you to fill out a form, and then you could move on. But most offices realize that this wasn't efficient, and so they moved to the doctor model, and the doctor model is effectively that you come in, they give you a form, you go sit down and you fill out the form, and then you take it back and you go get your results. The result is that they're able to process, they have more people filling out forms simultaneously instead of a single person. This has been possible on the front end of the web for a long time, too, with web workers. We just haven't used them because they're difficult to use. So AMP makes this transparent. Most of AMP can run within a worker, and we think as a result of this, we can offload a lot of the CPU time from the main thread. That's where I was supposed to say that, sorry. So workerized JavaScript, we think is made much easier with AMP, and quickly too, AMP doesn't hate JavaScript, AMP loves JavaScript. All of AMP is written in JavaScript. You can use JavaScript in AMP. Just because it's an HTML framework doesn't mean you can't use JavaScript. It's just, we think that the future of JavaScript isn't on the main thread. We think the future of JavaScript in a browser runs off main thread and only interacts with the main thread as necessary. The way that this works in AMP is that we built an implementation of the DOM from scratch that runs in a worker. So you load your application code that's specific to your domain. It runs within a worker. It has no idea that it's not running on the main thread. And as a result, the main thread stays less contentious. There's less competing resources on the main thread. And this changes that equation I talked about earlier. With AMP Script, allowing you to run your custom code off of the main thread, you get to retain the productivity benefits, but you get a little bit more flexible. And as a result, you start to look a little bit more like this, AMP moves to be a bit more capable without being more complex. So what's supported in AMP Script? Because it can't be perfect, right? There are things that are synchronous about the DOM and you're in a worker. They can't be synchronously known at that point. It's a really good question. The compat tables here, we're also happy to answer questions about this. There's a few people here that work on AMP right now. Caching and distribution is also built into AMP. It's an important part about how it stays performant. AMP pages aren't just web documents. They're ultra-portable, embeddable content units. The idea is to be able to distribute them and load them independently of a root origin. And this is what we call instant loading. So for instance, here on our Google search results page, AMP documents can be loaded in the background. So when the user clicks on them, they're instantly available. To support this, AMP has something called a pre-render mode internally inside of it. All of the components do not expose this through their API contract, but deal with it internally. Pre-rendering comes with a bunch of catches though that are difficult to do unless you design for it up front. So if you were to pre-render in advance, you would leak a person's identity. And we think this is terrible for users. So if I went to a search results page and then I loaded a document from another domain, I would expose who that person is to the other domain without them having clicked on it. And this is why we have an AMP cache. The AMP cache allows that document to be pre-loaded safely without saying who the user is. And it allows the origin then to be given the information about the user once they click on the result. So it looks a little like this at the end. When they click, now an XHR request can be made or a fetch and you can stitch together the two separate sessions. We think this is awesome because it means you get the speed benefits of pre-loading but you retain privacy. You don't compromise who you are or it can't be used as an advertising signal. Now, when you run an AMP document locally on your domain and you run an AMP document on the cache, they're very different. Because there's static guarantees about how AMP documents look and feel and operate, the cache can perform a series of optimizations on those documents. Every image can be modified to be compressed in a lossless manner. Every part of the document can be restructured as needed. In order to make this available to things besides a cache like say your canonical domain, we've open sourced the AMP optimizer. The AMP optimizer is a series of transforms written in JavaScript that work on your documents and do pretty much what the cache does. This allows you to get the benefits of the optimizations of the cache but on your local domain. Lastly, AMP and PWA work really well together. Even better than this animated GIF shows. We have a one line service worker that's built and customized for AMP documents so you can retain that functionality immediately without having to build complexity within your service worker implementation. And now, back to Ben. Thanks for doing all the hard work there, Chris. So that was a lot of content over there. If you want to hear about more of these things in detail, you can come to us or other folks here work with AMP or you can of course go to our site amp.dev which of course is created with AMP and you can find over here many things that are useful, interesting, kinds of things on the site. For example, there are courses you can take to learn how to use AMP using a project-based approach. There's tools you can use to build your site better, to optimize things, lots of nice node modules, things like that, templates that are built in that you can then download and you can use to build your site quickly and of course lots of documentation. Examples, advice on how to actually work and interactive playgrounds you can use to try AMP code out in and modify things and see what they do. And if you're curious what we're working on in the future, then come visit over here. Our roadmap is public because it's an open source project. Go to amp.dev slash community slash roadmap. I see what's happening with AMP in the future. Thank you very much.