 Hello, everyone, and welcome back to the state of the web. My guest is Ben Morse. He's a developer advocate at Google. And today we're talking about AMP's role in the web ecosystem. Let's get started. All right, Ben, thanks for being here. So how and why did AMP come into existence? That's a good question. I think that the thing that AMP was designed to fix was the problem of web performance. As you know, as your viewers also know, to follow what you do, performance on the web is a problem. And it's gotten a little better in some ways over the years and gotten worse in some ways, especially as mobile devices have proliferated. People have slower connections. They have lower powered devices. And performance isn't always that good. But those who are working on performance found that often performance didn't get any better. They would try to advise people to reduce their JavaScript. But then afterwards, people would actually add more JavaScript afterwards, after all, because the company wants to add in more tracking pixels or a new library or new dependencies. And things would get a little faster and then a little slower. And other things like CSS, images, similar thing. Performance tended to degrade over time. Plus also publishers were struggling because publisher websites on mobile devices were in some cases almost unusable. If you're a user looking at a publisher site, say some major publisher, on your mobile device, you would find things loading slowly in many cases as extra JavaScript that wasn't needed, loaded up. And then also things would move around the screen. Like as an ad would begin to load in, suddenly things would pop around and move around. As an image loaded in, things would shift down. So the experience of the user looking at an article on a mobile device was often very confusing, unstable, really hard to use. So publishers were struggling. So in 2015, Google got together with a group of publishers and had the idea for Web to came out. How would you describe AMP to somebody who might be a junior developer? It's a little complicated because AMP is a series of different things that work together using web standards to make for faster web pages. I think that the fundamental thing is that AMP is just web pages. So like I just said, I guess it uses web standards that exist to make things that are usually faster than other things on the web. Not always, but usually faster. I think the most important thing is HTML. So HTML was developed about 30 years ago, as you know, of course, as a document description language. And back then, the web was just text. So it was for things like, this is a paragraph. This is an bold face. This is part of a page. The web didn't have things like images back then. Didn't have things like interactive image carousels or embeds from YouTube or Twitter. Those things didn't exist. So as the web got more full-featured and now there's things in it like Google Docs and Glitch and Facebook, people use a lot of JavaScript to make things that are interactive on the web. So what AMP does, first of all, is adds new tags, HTML, that do the things that JavaScript would normally do. So for example, instead of making an image carousel, where you can slide images around the screen with your fingers or by pressing buttons, use AMP carousel, a new HTML tag that wasn't there before. To embed a tweet, for example, you would use AMP Twitter. And these things are called web components and they run via little bits of JavaScript that AMP creates that are made as small as possible that make magic work behind the scenes. So part of it really is extending HTML to do things it didn't do before, meaning you can write less code than you used to write. Conversely, it discourages making your own JavaScript, which is controversial because we all love JavaScript, but it's discouraged. It can be used in certain contexts, not all contexts. This actually is changing these days, which we can discuss I think later on. So there's that. It also discourages other things. For example, if you use one of the 50K of CSS, it's considered to be invalid AMP. If you do certain things that AMP doesn't make are very performant, it's called invalid. You can do these things, your site will still work, but while your site is out there and published to the web, there are web spiders out there from Google, from Bing, other companies that are looking out there for valid AMP pages. Pages that pass the rules of AMP. If your page passes the rules of AMP, it will then get stored in AMP caches like Google's and like Bing's also, and then you get this treatment in search where you get a carousel if you're a publisher and most importantly, your site is served from someone else's CDN, Google CDN, Microsoft CDN, Cloudflare CDN, someone else's. And this is done because it makes your site faster. In fact, in certain cases, your site or your page will be loaded in search in an iframe behind the scenes. When the user then taps on that link, it pops up almost immediately. So it gives you the promise of near instant loading that didn't exist before. Pre-rendering. There's pre-rendering happening behind the scenes. And it's limited because AMP controls the page and using AMP components, so things like images or YouTube videos won't load in that pre-rendered area. So it's safe for the user, it also preserves privacy because AMP is controlling what's going on. So it's a complicated set of things, but basically there's web components or new HTML tags that give you new capabilities in your page. There's rules you're supposed to follow. You follow these rules, you can then get put in AMP caches and especially fast treatment from search. So the speed of AMP comes from one, less JavaScripts, less CSS, all these kinds of things, and two, the use of a cache. That was a long answer, I'm sorry. It's okay. So for websites that start to adopt AMP, what kind of performance gains do they start seeing? It tends to be a dramatic increase in performance. I mean, certain sites out there have worked on performance already and have a lot of discipline. It's hard to do. My own sites I've made myself often are pretty slow, I have to admit. Sometimes I forget these sites exist, but often things are faster because you have less JavaScript, you have less CSS. Also I didn't mention before that your CSS you use has all be in line. So there's no request for CSS, there's no blocking request for that. So things just get faster right away. And as websites use the AMP cache, does that refer or the URL affect the way that websites analytics work if the URL is different? That can happen. So the AMP cache, it is a cache and there are certain things that you have to work around with the cache because you don't control the cache anymore. So for analytics, for example, one problem that happened when AMP first came out was that if you went to your site on the AMP cache and say it was on the Google.com's domain, these are then clicked on the link on your site, you go back to your domain, it'd be different to a main. So you would have a balance in analytics. Fortunately, there's a solution for that. Google Analytics, for example, has a simple solution called client ID. You set up some meta tags and something in the interface and it's all done. Not all providers allow this but some providers do allow this now. So you might start implementing AMP and see your numbers go down and say this AMP thing isn't working and pull it out, right? It has happened more than once, yeah. Not everyone knows this exists because you have to actually figure out that it exists to use it. But there are fixes for the analytics problem. It's not perfect because also analytics require support to work in AMP because you can no longer add your own JavaScript to the site. Instead, you use AMP analytics, which is a tag or AMP pixels, which is a tag that AMP provides. Analytics are a little harder in some ways, not everything is supported, but most things are supported that were supported before. Sending a pixel, for example, when you take a certain action or scroll somewhere, clicks on a certain button, those things are all supported. The nice thing also is that AMP batches things up. So a problem with a lot of sites out there, I've worked on also especially, is that you have a lot of analytics tags and you have a lot of JavaScript being added to the site. All the JavaScript is sitting there in the background measuring things and then when it finds something it sends off a request to the site. So you get a slower load, visible content often is blocked and then as your site is being used things are always happening in the background. But AMP controls all this now. So AMP analytics will measure things once and then batch all of the sends that are required and send all those things off when there's a bit of a break in the action. So it works hard behind the scenes to make analytics smoother. Gotcha. So it's a mix of both network and CPU optimizations. Yeah, exactly. Yeah, for example, AMP encourages you to use CSS animations and certain AMP animations that are GPU accelerated for example, not things that are JavaScript intensive. So yeah, there's network optimizations with AMP and also CPU optimizations as well. Are all websites good candidates for AMP or are some better candidates than others? That's a good question too. These are all very good questions, thank you. It really depends who you ask. I mean, AMP was designed for simpler sites for publishers, but then as soon as AMP came out to the people that surprised who made it, eBay began to use AMP for some of their landing pages and that normally expected. AMP began to grow beyond the simple thing for publishers into more of a full-featured web components library. So now you see it used mostly by publishers still, but also for a variety of different kinds of applications. For example, Aliexpress, Aliexpress, Alibaba, the very large Chinese company, about a year and a half ago, a small team there made an AMP version of their mobile site. So it still exists now. Some parts are AMP, some parts are non-AMP, but they use this to sell things online. And it's a pretty full-featured, nice e-commerce experience. So I think the answer is that it's easier to do it for sites that are a little simpler, but it's possible to do it for more complicated sites as well. It just depends what you want to do. But for me, the real purpose of AMP is to make things faster. So I think if there are cases where you can use AMP, you should try it, see if you like it, because if you like it, it can be an easy path to making your site faster in general. I mean, most sites out there that you look at aren't that complicated. They may have a lot of JavaScript that are rendering the page or doing other kinds of things, but mostly they're just text and images and menus and interactive things, some things that are pretty simple. And I think those are all good candidates for AMP sites. If you're making the next version of Google Docs or an online code editor or a mortgage calculator that's very interactive, those things can be done with AMP, especially with AMP scripts. Maybe it's not quite as useful, though. I think also one of the interesting uses for AMP is in CMSs, because, for example, most WordPress sites aren't that complicated either, but often they have a lot of JavaScript and a lot of CSS because people use a lot of different plugins and modules that add JavaScript and CSS to every page. So you'll see, for example, a WordPress site with things for captures and emojis and e-commerce on a homepage that has none of those things and a lot of JavaScript and CSS is not being used. There's a plugin for WordPress for AMP that's quite nice. It allows you to make sites that essentially are AMP without even knowing that they're AMP at all. So it just puts out AMP instead of HTML. So it gives you the chance to make really fast sites out of the box. So as part of your work as a developer advocate, you've gone directly to websites and helped them amplify their websites. What are some common problems or footguns you've seen websites have? I like that word footgun. Like, should I use up on the foot? English is a wonderful language, full of new terms all the time. Actually, what I usually see is people not knowing what AMP really is and not using it very well. So I'll give you an example. I was visiting a major publisher in this country actually last month and they have on their main site a nice menu that comes down from the top and various fancy things occur as it comes down from the top. Their AMP menu comes from the side and is much simpler. I asked them why this was and they said, well, because the AMP sidebar component we used allows you to make the menu come out from the side, not from the top. In fact, in terms of the top, it's pretty easy as well. We have to use a component called AMP bind to do it. Where you bind an action to a thing in the DOM and so you press the button over here and then it slides down from the top. I've done it myself. I've actually made a video about this that wasn't published at the time, but they didn't know this. They also didn't know about AMP scripts or other features that AMP has. People often don't know about the fixed-ramp analytics, for example, the problem between the cache and the origin. People don't know the things AMP can do and they see the examples that exist on our site, for example, and they're quite surprised that they see all the animations and nice things AMP can do. That's the most common thing people just don't know what AMP can do. They regard it as a tool that's made for a simple, kind of basic, not-good-looking site spin. In fact, you can keep your design the way it was before. You can keep a lot of nice features. It's just a matter of making some of those things again without JavaScript or with JavaScript to use it in a different way or with CSS or with AMP components. So I want to give you a chance to dispel some of the misconceptions about AMP and the myth-busting lightning round. Are you ready? Sure, I'm ready, lightning round time. Is there music for this, I hope? Yeah, we can do that in post. So AMP is a Google-owned project, true or false? Google did start AMP and it's still true that people that work on AMP are mostly from Google. Most of the engineers who work on it are from Google. But AMP is an open-source project and it's run by an independent governing board that consists of people from Google, other companies and people that are sort of just general people that like the web. So it mostly is run by Google still but it's important to Google that it not be part of Google or Google thing because I think Google's intentioning and creating AMP was just to improve the web because the web needed some help, we thought. So it is largely run by Google still but not entirely and anybody can get involved in AMP. How about the M in AMP stands for mobile? Yeah, when AMP was created, that's what it was. AMP was accelerated mobile pages but it's been realized since then that AMP is good for all kinds of sites. Making responsive sites is pretty easy in AMP. All the AMP components are responsive out of the box. There is a layout system that involves also things that are responsive automatically. So we're trying to just call it AMP now, not use any of the words that were in the acronym and just say AMP. Also when it was first made, people use this paired approach where they made a desktop version of each page and an AMP mobile version and use link tags to associate those two things together for search engines. But now people are more and more making sites that are just AMP all the time because maintaining two sets of code is harder than one set of code. So these are in many cases just have your desktop site and mobile site all be the same thing. How about the UX of an AMP site is restrictive and less interactive? It takes sometimes a little more background to do it if you just know JavaScript and go and make an AMP site, you may say, I can't do this, I'll just leave these things out. That happens sometimes. But most interactions you can make with JavaScript are doable at AMP as well, especially design. I mean design is mostly CSS out there, so why not make that however you want it to be with AMP? And then just find ways to use AMP components to make the UX that you want. Also, AMP script is a new part of AMP that allows you to use JavaScript in almost any way you want to. So in that case, if you have certain interactions, AMP components can't do that easily. Make them yourself in JavaScript or import your old libraries you used to use. AMP script just has certain restrictions. To keep the performance promises AMP has, it can't run on page load as to have a user action first to run it. And then also runs in a worker. So it runs on a worker using a copy of the DOM. So AMP can always make sure things are fast on the main thread. Your code runs in separate threads. Not a JavaScript usually works. And that way your user interactions can run without blocking the main thread. So AMP script is kind of a safer way to use JavaScript. Not that JavaScript is that dangerous in the first place, but- It could be. It kind of makes you be honest that the JavaScript program are not to use JavaScript which is too big or too intrusive or blocks rendering of the page in the first place. The last one's a big one. You must use AMP to rank well in Google search. We hear this one a lot. Yeah, people in agencies sometimes say, am I forced to use AMP? Well, Google in some way be mad at me if I don't use AMP. And please don't think that. The idea of AMP is to give you a chance to make sites faster in a certain way. It's not a ranking factor in Google search. And it's really a tool you can use if you want to. If you don't like it, you shouldn't feel obliged to use it. In fact, if you're a more advanced developer or especially working by yourself on your own site, it's quite possible to make sites that are faster without using AMP at all. It just takes a lot of work. And if you're working at a larger company, it can be harder because maybe you, the developer, think, I love performance. Maybe your product manager thinks, I love this new tracker I've got to put in there. A marketing person loves some third party JavaScript or a chat widget or something. Often you lose control of your site and your site's speed. So AMP really keeps you more honest. And AMP can also be a helper for your people, for your product managers and so on because AMP gives you performance guidelines. Following those guidelines gives you a bit of a boost if you're a publisher and it gives you access to the AMP cache, which is nice in general. So it can be a way of really just making sure that, I don't know, it's kind of like a nice, a benevolent parent, perhaps, that's there trying to keep your site fast. Gotcha. So as AMP has matured, so has the web platform as well, how have the standards and capabilities of the web platform helped push AMP forward and vice versa? I think this is an important thing because I think the goal of AMP throughout hasn't been to make this other, waving websites, the goal of AMP is to make the web in general to be faster. So we're seeing the web push AMP and vice versa. These days, some things that were complaints about AMP when it came out, I've been addressed in various ways. So for example, one complaint that's a pretty good complaint is that when you use AMP and you're on the cache, your domain changes. And you don't want to have ampproject.org or google.com, necessarily, in your domain. People don't often see it on their phones, but it's there and it can create problems for things like analytics, as we discussed. Also, certain browsers now block third-party cookies. If you're on a cache and your cookies actually are from your domain, but the cache has another domain, some browsers will block your own cookies from your own site. Those things are all problems. This is part of why people are excited to see the advent of signed exchanges and web packaging, which are a way of letting people keep their domain even on CDN. So CDN can serve your content, but you can verify that it is your content and the browser can then know it's your domain. So that solves that problem. It's available on Chrome now. It's, I think, an evolving standard. I'm hoping to see it on other browsers soon. What else? Things like the way that AMP restricts or at least has guardrails to prevent you from straying too far into non-performance things, like it's like feature policy. Newer APIs like that enable developers to say, like, toggle off some suboptimal features of the web, maybe large images, for example. It's very similar. Yeah, it's the same idea. The developers have to choose to actually opt into this, like opting at the AMP. Once you do, then these things are watched for you. And of course, web components are a popular thing these days. They were around before AMP was around, but they were a similar way of making sites. Also, we're seeing now the advent of some things in Chrome where Chrome is making it possible to have certain standard JavaScript libraries you can use for certain features on their evolving web standard. For example, the first one I've seen is for key value storage or placement for local storage. That lets Chrome, if you're using Chrome, you can just import this library of JavaScript, which is very similar to using AMP components. But in some ways, it's more exciting because it's just the thing that Chrome will provide out of the box and other browsers as well, hopefully. You've mentioned AMP Script. What other features are in the pipeline? AMP Script is a big one. It's available now to use, but it's not widely adopted yet because it's new, but it's a big change to AMP. Other things that we're seeing in AMP, I mentioned sign exchanges before, I guess, we're seeing various new components that are being used all the time and improved in various ways. AMP Stories is a thing. It's been around for a little while. AMP Stories is a web-based Stories format, like Stories in Snapchat or Instagram, but on the open web. That's a nice one. AMP is coming into email too. You may have seen this. AMP is a way of packaging up a bit of the web up and email doesn't usually use JavaScript because we don't trust JavaScript in email because it could do anything strange or track people in some strange way or affect their devices, but AMP is a very strict set of JavaScript. So right now Gmail and other email providers are starting to support this where you can take actions inside an email. If you have a component like an AMP Form, for example, you can submit data to a site and get a response back. You're gonna get fresh data in an email about, say, like a hotel price or messages you've gotten or a stock price. You can now use things like AMP lists to import those things into emails. You can use tabs in emails now. It gives you various new capacities with email. How about Bento? What is that? That's a new idea. So there are those who think that AMP is kind of annoying because they're forced to use AMP all or none because AMP wants you to use the whole of AMP components in the AMP runtime or nothing. But since AMP began, there are those who've been using AMP just as a series of components and mixing them components with other things and using non-AMP pages that combine AMP components. It's never supposed to actually work, but it's worked pretty well so far. It's just not really guaranteed to work. So Bento AMP, the idea is to make that guaranteed. People will be able to combine AMP components with their own web pages however they want to. And it's being worked on now. So I think that some of the, yeah, people are trying to make it so AMP is more part of the web in general and not like this kind of separate way of working on websites but really part of what the web is. Finally, what resources would you recommend for developers who want to learn more about AMP? I thought one more important thing, sorry. Go ahead. One more important thing about the web is that people complain because AMP has a little badging that happens on Google search and other search engines and you get in these special carousels. So these can be only gotten to if you're using AMP. But it seems kind of unfair to sites that are fast that don't use AMP. There's an effort out there also now to give non-AMP pages that have stable layout and that are fast, the same treatment as AMP pages in search that's being worked on now. They've been working for a while into what kind of metrics to use. Is it first contentful painted at something else? How do you measure layout stability? But this should be appearing, I think, in search engines pretty soon. So you can use AMP in the future or your own ways in the future of making your sites fast and get a similar treatment. All right, how can people learn more about AMP? Oh, good question. Well, watch this video for one. We already have done that, so it's too late for that. AMP.dev is a great resource. We make this site that has all kinds of stuff about AMP. So documentation, it's got two tutorials. It's got nice features like a playground where you can go and try AMP components out and modify things and see results immediately next to you. It's got videos. It's got even templates you can load and start with immediately. So you can have design that you start with for your site. There are all these kinds of things. There also are now some AMP courses we've made. Three courses you can use to take AMP like it was actually a class. Especially if you're a new developer and you're newer to the web, you can learn how to make web features by using these courses. If you're more advanced, you can use a more compact version of these things. These are available also on AMP.dev, also as YouTube videos, made in this very studio in some cases. And also, teachers can download these resources and use them in classrooms. We have slide decks you can use. We have a syllabus, all kinds of things like that. All right, Ben, this has been great. Thanks for being here. Thanks for having me. I appreciate it. So you can check out the description for links to everything we talked about. Thanks for watching and we'll see you next time.