 Thank you so much for having me. I know it's early in the morning, so thank you for taking time out on a Saturday to hear my thoughts, chat with me, hopefully ask me questions. Yeah, the idea of this talk is to just share a little bit about Core Web, which is this new announcement that Chrome made, as well as how Google Search picked up that announcement and announced something called Page Experience on top of it, and what AMP does to help developers meet this, meet Core Web Vitals, and as a result, Page Experience. Do well against Page Experience. I think this talk is most interesting for developers and SEO experts, because the way I think about this is now with performance being such an important part of ranking. The worlds of performance developers or performance engineers and SEO kind of blur together. So I think it's interesting for both of you to definitely hear about it. And it's going to be interesting for publishers, e-commerce developers, and especially like Slovik mentioned, if you're creating CMSs, it's definitely important for you to be considering how you can set up your users best to meet these vitals. And introducing myself. My name is Anna Harkhani. I'm a product manager who works in the project. My really large focus on the AMP team is to just see how I can help developers be more productive, so make all of these changes that teams are browser teams or search teams, et cetera, announcing how developers can very easily deal with it. So that's my forte, at least, or at least I try to be good at it. And let's see how good I am at it, actually. Thanks. Before you continue, Anna, I'd like to give a few instructions to the audience, which is, so everyone who has joined in from YouTube and Zoom, firstly, welcome. You can use the Q&A feature if you're on Zoom. Use the Q&A feature to put in your questions. We will be taking most of the questions at the end of Nana's presentation, just in case if you have a really burning question, which really is in line with what Nana is at that point of time talking about, I might take your question at that point of time, but you should expect the questions and answer question, Q&A, and discussions to happen at the end of the Naina's talk, which will take about 30 minutes. If you are on YouTube, you can put in your questions in the comments or the Q&A chat feature. And someone from Haskeek is going to forward those questions to me. So there might be a slight lag in the questions reaching me. So better be on Zoom if you want to ask questions directly to Nana as well. Also, at the end of the, as we get into the discussion aspect of things, if you want to, you feel free to raise hand, put in your questions in Q&A, and raise hand if you are available to ask the question directly on Zoom so that we can patch you in and you can have a conversation directly with Nana as well. That's all from the instructions from my side. Over to Nana, please continue your presentation and let's hear about Pam. Yeah, so I'll quickly talk about why I think performance is incredibly important. It's no shock that investing in the web is equally important to a business's success as it's like investing in the app and ecosystem. And that's because like the web is like the only truly open platform that we as users have, right? You don't have to install something, browsers come preloaded, most web views come preloaded on like on any phone that we have regardless of whether we have a Motorola, we have an iPhone, we have a Samsung, we have an HTC, whatever. And it has no gatekeeper, right? As long as you have a phone or tablet or some kind of connection to the internet, regardless of how slow it is, how fast it is, you have access to information. You don't have to do something for that, you don't have to pay more money. And so it's like it has no gatekeeper at least, no gatekeeper there. And like the web is so rich in its amount of content choices, you don't like the answer you're getting somewhere, you don't like a recipe somewhere, you go somewhere else and you still have the options. And while this is all great, users are getting more and more frustrated with the web regardless of what they're trying to get out of it, right, pages will either load too slowly when something does load, you actually can't move or do anything with it because it's actually well still loading, surprise, surprise. And then something will load up above what you're actually reading and everything will shift or you'll accidentally end up buying something instead of hitting like the cancel button, which is like my most annoying thing. And the thing is when developer, when users see a performance website, they will spend more time on it, they will buy more things on it and they will reward that experience. So it's not like they're just asking for something and they're just saying we won't do anything with it. If they see performance, they reward it, which makes it very important from a business reason to be creating performance experiences. And the thing is this is great, it sounds like an easy problem, create a fast side, get users fine. But it actually will often, like when we talk to developers, it'll be like it requires expertise. It requires like watching a whole bunch of talks, like keeping up with standards. And it's not something everyone can afford the time or the skill to do so, right? It'll require large development teams. It'll require like hiring very specialized people. And that's not how performance should be, right? Straight out of the box, what you are creating should just be performing and that is what an ideal situation should be. And that's like really where AMP came about. And the idea is to provide like this open source HTML framework where straight away, right out of the bat, you're getting really performant experiences and performance here can mean like actual speed, but it can also mean like performing against user expectations or performing against revenue. And like just the default should be great. Obviously, if you're like, if you're a absolute genius at performance, right? You will create a very, very performant, very well tuned website, but not everyone is that 1%. And so our idea is to like help the largest group of people come up to the default and like rise to the challenge. And the great thing about like actually using AMP and like this is totally a marketing spiel, so ignore me if you want to. It's like every week we cut a new release which has like bug fixes, which has performance improvements. So you're getting automatically getting all of this performance improvements for free without having to do anything without having to update any NPM dependency, et cetera. It also means that you're getting a performance, a pit crew of like performance engineers and infrastructure engineers in the AMP team and they're making sure that you're always meeting great, that you're like doing best against speed benchmarks and like it's reliable. And also making sure that speed translates to revenue. So making sure that you're still able to have the same ads, but that those ads are performant or they're meeting user expectations without like harming the user's expectation of the internet. And the best thing it's an open source framework which means anybody can contribute to it. So like if you don't like something about it, you don't just have to like tell us, you can actually like, you know, feel like, you know what, I'm going to create a PR and make a change. And the idea is AMP is like supposed to be a web component framework that you can easily create websites with. But we then realize that this does not only apply to websites, right? Like there are other things that are slow. Ads are slow. Emails are slow and very static and dynamic. So we started extending AMP to other formats such as stories, emails, ads, emails are like my favorite thing because now I can actually like do things in emails as opposed to just having this emails just being a checklist for me of like opening links, doing something and then coming back, archiving it or marking it is done. I can actually do things in the email which really excites me. And yeah, like AMP powers like some great experience like websites, stories, ads and emails and we'll talk about all of them right now. Websites, yep, pretty simple. Like the idea is that we want to allow developers like easily create these great experiences on the web and they should be smooth. They should be instant and like they should be incredibly rich. And if you're a publisher, like what's your benefit of actually using AMP, right? The benefit here is like if your reader opens the page much more quickly, they're able to engage with it for longer, they'll be able to read the content which means their likelihood of coming back to you. Like if they remember you as being a fast website, they will come back to you when they're seeking more information. So it's just higher lifetime value per customer. And the fact that, you know, AMP does have these placements in certain, like in certain search features, like for example, in Google, it gets the top stories carousel and being also gets special treatment. And in Twitter, it also loads fast means you're just getting more reach as well. So not only are getting more engagement when a user arrives, but you're also getting more users reaching your content. If you're an e-commerce site, again, speed means they're going through the process more quickly, they're like, you know, looking at products more quickly, more, and that there's higher chance for conversion. And it also means that you're getting, a user is getting really great benefit without having to install an app and like losing, and you're not losing users to like that part of the conversion funnel as well. If you're an advertiser, the fact that these pages are much more reliable, that they're much more simple, allows your ads to really shine. You can do a lot more with it. And the fact that the page loads faster, the ads load faster, means that the user is more likely to kick on like something that is actually an image of a car as opposed to just a sign that says ad, right? They don't know what it is. They won't click on it. And obviously like you're losing revenue that way. And the great thing is like, we also have a very specific, like we've also expanded AMP to like, allow you to write ads in AMP as well. And that's something I'll talk about in a bit. And we've seen success from like, all of these verticals when they're like working with AMP, right? Whether it be advertisers, they've seen like, they've seen an increase in like actual click-through rates, whether you're an e-commerce company and you're seeing higher conversion rates or like actually lower bounce rates because the page loads much faster and they don't have to wait 10 seconds for an image of a bicycle to load. Or if you're a publisher, right? Athletes, it's an Indian publisher whose case study is right here. They see a higher click-through rate of articles add the ad view because the ads are loading faster, the ad viewability rate is much higher as well. So there's success in AMP, like regardless of what vertical you pick. And as a developer, it just makes it easier for you in every stage of your development cycle, right? It makes it easier for you to get started because you don't have to go hunting for great. I need to create like a carousel of images for like this particular event. Like I want to show like the latest, latest Bollywood celebrities wedding and I need to create a carousel. You don't have to go wondering about which carousel should I pick? There's one and it's great and you can just use it easily. And then over time, maintenance is easier and like you don't have to worry about long-term infrastructure tasks which like really makes, allows you to just focus on your product and you're on your website and you don't have to think about infrastructure tasks which so much better in my opinion. And like what does AMP actually look like? So like for example, if you had like a jQuery, if you're just like trying to load an image using jQuery, like it would you call the load command. However, in AMP, like if you, you take an image tag and you just like you're adding more information on top of it and you're converting into something called AMP image and like it's very similar to an image tag if you think a look, take a look, right? So what does, what is it like, what is the extra information you're adding in? So you're adding in a media attribute to say, you know what I want it to be, I want this image to be shown at like minimum width of this. So kind of think of media queries except put in here. You're specifying exactly like you're specifying an aspect ratio which means you're always able to preserve that. And then the next best thing is you're specifying a layout. So instead of like actually having to do all the JavaScript that you know is needed for a responsive layout, AMP is doing it for you. And like the previous step, you specify that the aspect ratio is five to three width to height. And now as long as like, as the user resizes or depending on what device they're looking at it, it will respect that aspect ratio and it will keep resizing. You specify a source that's no surprise. And then you also specify source sets depending on like what kind of device you can, make sure that you're picking an appropriately sized image so that you're not shipping a 10 megabyte image that is made for desktop for like a poor mobile form that doesn't really need it, let's be honest. And the great thing is like with, that's just like AMP, that's like an image, right? But we have like so many components. I think at one point I was looking about a few months ago and there were as many AMP components as there are countries, which is funny, but like it's always expanding as people like, you know, have more requests and have more needs. And as the web evolves, we add more components, but we also make sure that we aren't just adding components that were that they're working in a very performant user first fashion as well. And now like up till now, like so far all of these are components that don't really have JavaScript attached to them, but we also understand in some cases, you just need to write your own JavaScript, right? The AMP team can't ship your own business specific capture robot detection logic that that is something that is very specific to your team. And we have like a component called AMP script, which is basically running JavaScript in a sandboxed environment. So you're still getting, it's like on a worker. So you're still getting performance benefits and it's only being executed on a background thread and not on the main thread. So you're still getting all those performance benefits, but you're getting to write your own JavaScript if you need it, if you don't feel like one of these components like meet those needs. Another component is like AMP YouTube. It's a YouTube embed, right? Again, it's responsive. You've specified that, you specified a height and a width ratio, and you've actually like given the URL ID as a video ID. And the great thing is like, this is a very common API that you can then extend to things like Twitter. You'd have a Twitter ID, you'd have a tweet ID, Facebook, you'd have the page ID and stuff like that. It's like, once you understand the syntax, it's like very easy to make it extensible and you don't have to keep learning new things. That's all about websites. We've also recently expanded into something called web stories. And the idea is like up till now, stories have been always like something that is very specific to wall garden, right? You have to install an app to be able to see stories, but we don't see any reason why that should be the case, right? Stories have an equally important place in like conveying like visual information on the web. And that's how, and we think it can be empowered, like it can be powered by AMP really well. And so that's where we've been investing our time in like web stories. And if folks have questions, they can like talk more about stories and or like any of the other formats later. AMP ads like I talked about, we realized that a lot of AMP's power and like being able to like have really performant code is really impactful for ads as well. Because ads do tend to load like incredibly slowly. And that's why you'll see the jank where like an ad somewhere up there loaded and everything moved accordingly. And so we really believe that like AMP's power can be useful for writing ad creatives as well. So if you're an agency, instead of like writing ad creatives on HTML, you can write them in AMP instead and like get those performance benefits. And then email. So like the idea is for the emails to be more interactive than just like a bunch of links that you click to and go and open in another tab, do a task and come back. You should be able to execute. So for example, if you were joining this, if you were trying to like set up a schedule or like, you know, respond to some, like give a few free times on Doodle or on like something like Calendar, you could do that in the email. If you wanted to fill out a form again, you could do it in the email and submit it. Or my favorite thing is like, if I use Google Docs and like every time someone comments, I get an email. I don't want to have to go open Google Docs and then like find where the comment is. I can just reply to the comment like in the email and that's like changed every Googler's life in my opinion. Those are like some of the formats, but we'll spend the rest of this time talking about the web and like how AMP helps websites. So the web in 2020, I like I said before is an incredibly frustrating place for users. Slow pages, things load and everything moves around. Right. Chrome team thought that there's a good way of measuring these experiences and like actually telling you when these experiences are poor or not. So for example, and that's where core web vitals came about, right? They're the fun. And then they became the foundation for something called page experience. They're detecting three things currently at least is the page loading fast. So it's like, when is, when is the largest amount of content rendered onto the screen? That is something called largest contentful paint. Is the user able to interact? Are they able to like input information, scroll, like fill in a form? That's first input delay. Like when is the first input able to like be able to give in by the user? And then visual stability is the content moving around so that like a user accidentally doesn't hit submit instead of delete and like buys apparently how many items are there? Yeah, 56 items. Imagine that that's expensive, right? And that's like under that's measured and by something called cumulative layout shift. And so yeah, these are the core web vitals metrics and it's not just like, oh, you're good, you're bad. There's like a spectrum of like what we think makes a good experience and what makes a bad poor experience or something that needs improvement. And so like these are the metrics we've set out for like LCP, if you're like, if you're loading in four seconds, we think like you're, it's a poor experience and you should be working on it. Four to 2.5 is something that we think like it's, you're getting there, but it still needs some improvement and 2.5 seconds or 2,500 milliseconds is what we think is a good metric. And like the same we have for FID where up to 300 is poor, 300 to 100 is like needs improvement at 100 milliseconds we think like lower than 100 milliseconds we think you're doing a good job. And for CLS, it's not really time. It's like how much is the content shifting? So it's a calculation of that. And if you think that up to 0.25, if that's the score, again, it's poor between 0.25 and 0.1, we think the content is stable enough, but like the user may have still, still have some unexpected movements and less than 0.1, we think it's a pretty stable page. The user knows where everything is at all times and things aren't moving under them. And the idea is that like for about 75th percentile of your users, right, your score should fall within like a good need improvement or like poor. So if for example, up to 75% of your users see that your LCP is 2 milliseconds, we think that's a good score to have. So that's what we're checking forward. We don't want, we understand that like because there's so much varied internet access across the world, it's impossible for everyone to be like hitting a page and like seeing a largest an LCP of like one second, right? So as long as 75th percentile, which is like a larger, a very large chunk of your users are experiencing this, we think that's a good metric to be meeting. Anna, just a question in the last slide. For the CLS, what are the unit of the 0.1 and the 0.25? How is that number derived? Is there, because the other is time. So seconds and milliseconds is very easy to understand. Is this a proportion of the page size? How is this? Oh yeah. The best way to say it is like how much of the content has moved. So for example, if something was at the top of the page and it's moved by, and it's like taking up roughly about half of the full width and like half the height, how much has it moved? Has it moved by 10% that is like 0.1. So that's how it's not. So 0.1 equal to 10% is that a reasonable understanding? Reasonable understanding, yes. Okay, thank you. Area is also important, like has it moved like left, right? Like has it moved up and down? But yeah, roughly it's like how much. Is there any place where we can read more about this? How is this calculated? So yeah, web.dev slash cls. So like the short form should definitely have, and I'll collect links to all of this towards the end. But yeah, like web.dev has like, which is like Chrome's portal for sharing all of this information has like everything about all the core web vitals. And the great thing is all of this is, there's tools to measure all of this. Like if you use Chrome Lighthouse, if you use something like search console, page speed insights, all of these will give you this information, especially like for cumulative layout shift as well as largest content from paint, it's like easily measurable. Like it's like, if these are, this is real user data, you can get it. For first input delay, since like we need a user to input, I think at least Lighthouse, which like has more lab data will have like, will have, excuse me, will have time to interactive as like a proxy metric, because again, it's able to show lab data, but CLS like LCP, you can also see in Lighthouse really strong metrics. All right, thanks. That's actually a good question. And then yeah, like the idea is Google search picked up these core web vitals and added, and said these plus some other things, like how mobile friendly is your page? Does it like respect safe browsing principles? Does it have HTTPS security? And is it like not showing, like intrusive interstitials to users? Like all of these metrics combined together to make something called, is going to power a page experience signal for search. So like up till now search was like, how useful is your content? Like how accessible it is, but like this is going to be another ranking signal. So core web vitals plus some other information that's already existed, right? Mobile friendliness is something Google's talked about for a while. And the idea is page experience will now be a ranking factor, as well as the top stories carousel will now just be open for all content. And it will again like have ranking based on page experience. And it won't be like something that's reserved for AMP, which is great, right? We don't think on the AMP team as well, we're really happy about this because we think that any content that is doing performance regardless of how it's being made, should like get the special treatment and attention by the user. So currently very much a pre-announcement, obviously COVID has taken over the world by storm. And so the idea is it's not, it's this is just a pre-announcement so that like users can play with, developers can play with tools, really like ask questions and like have these conversations like we are all having. And like when they do announce, it'll be like a six months heads up thing, right? We're going to like start considering this a ranking piece in like six months time. So like if you want to make any changes or if your search console is showing that your pages are poorly performing, maybe now is a good time to like start thinking about it. So yeah, there'll be plenty of heads up that the Google team will give here. So the reason that I'm really all here, like here is like actually share with developers like why AMP is like this great tool for actually like meeting core web vitals and as a result page experience. And like it just does a lot of this work out of the box. So in AMP, our idea is to like actually put developers on this path to success to first of all, creating a great page experience or like actually meeting the core web vitals in the first place, but then allowing developers to meet it over time, right? Somebody somewhere in your team will like have committed something that is like non-performant and then your score will fall down again, right? That's an added piece of work that you have to do. And then you have to go debug exactly why that happened. So maintenance is an equally important part. And so our goal is to not just help you create them but also maintain like these great page experiences. So for largest contentful pain, like I said, like these are the break up for spectrums. How does AMP help here, right? Let's actually think about that. So in AMP, we actually believe that like we should be, the goal is for like the page to load almost instantaneously. But the way we actually do that is by making sure that we're only loading the most important things first. So for example, if something is in the first viewport of your mobile device, that has priority over loading something that is way down there that the user might never see. And then it's important for the text to be laid out and then like reserve space for the image and the image loads when it comes, right? This means that we're only loading things intelligently and allows us to like do a much quicker LCP, like a much quicker contentful paint and like paint the largest amount of content very quickly. And the great thing is like AMP pages are great because of the components and the runtime, but when you're being loaded from a cache such as the Google AMP cache or the Bing cache, we're also like able to like preload it and pre-render this page, which means as the user clicks it, it almost instantaneously paints, which again like pushes our LCP numbers much higher. So the idea of like being able to smartly load things as well as preload them in cases where they are loaded from a cache means AMP does pretty well on like largest contentful paint. Next is first input delay. And how does AMP actually do well here? So first things first is our promise is that our code will never block your user's paint, right? If we're like, for example, if you're having, if you're tracking analytics we'll always make sure that they're happening on a worker thread and not on the main thread. So we're not taking up your user's main thread time. And that means as soon as the page loads they can interact with it. Again, the fact that we're deferring layout means we aren't taking up the main thread and like actually laying things out and we're just laying them out as the user sees need for it. So we lay out the first viewport and then if like as a user scrolls we'll start laying out like two, three viewports down but not like the 10th viewport down. And the fact that we are chunking our processes also means that like chunk chunking all of our workload together means that we're able to keep our processing into like bite-sized versions which means again, like the AMP page is not clogging up your main thread. And all of our first-party codes for example, a carousel that we write or an image gallery that we write like is considered first-party code and anything that for example you're putting in an iframe will sign box at all times to make sure that it's secure but also that like, you know we're not being slowed down by iframes loading. So all of this like really comes together to make sure that when a user clicks on something when a user scrolls something they're instantly able to interact with it within like a very strong score within like a very less than a hundred milliseconds I believe was the good FID score. Cumulative layout shift, this is my absolute favorite and I think like this is one where AMP really shines. I showed you earlier an example of AMP image where you had to specify the width and the height and then kind of layout that you wanted to do. So in that case it was responsive but you can also say it's fixed like I only ever want this image to be shown 500 pixels by 300 pixels. But the fact that we can reserve the space we have the knowledge means we can always like have the space reserve. So when an image loads it just fills in the pixels in that reserve space already it's not like loading a new space or like when an ad loads it's not like causing content below it to jump. So the fact that everything is statically sized and like we have that semantic knowledge means we do pretty well here. And for example, if something is dynamic so for example, if you have a shopping list like and it's an infinite list at some point like we will make sure that a user interacts with something. So like hits the show more button and it's not just like loading things without the user's understanding. So that if they're reading things something else that some other new process doesn't just trigger and ask everything to move, right? User's intent is when like content will move. So yeah, the form will expand like an accordion will expand or the sidebar will come but we aren't just like moving things around based on like when a fetch comes in and making sure that like, you know font loading is happening really efficiently. So making sure they're a good fallback such that, you know, we're not like even like text loading or like your title loading should not be causing like cumulative layout shift. And these are really small issues which you don't really think about. We're like, it's fine, it's fine. Like, you know, it's a bunch of texts, it should be fine but no, that can also be a real cause for cumulative layout shift as well. And that's what AMP does for you straight out of the box but we really believe that like there's things that US developers can also do to push like your AMP page is really above the edge. And the good thing is here, like for example if you're being served from an AMP cache, right? You're getting like the benefit like of a Google AMP cache or a Microsoft AMP cache which is pretty well scaled but for example, if you're choosing to not be served from an AMP cache make sure that like you have a server that has like really good response times like make use a CDN like invest in that infrastructure. If you're especially if you know that a large part of your customers aren't coming from a cache page and then make sure that, you know, you're shipping images that are appropriately sized for a device or like using the source that attributed images for example, there's no need to ship a 10 megabyte image for like a like poor mobile device for a poor Moto 3. Like it's the user will not get the joy out of it, right? So there's no need to ship it. So make sure that you're thinking through these business decisions as well. And then there's also like for those things we also have tools where like there are additional tools that the AMP team also gives you that can actually help you do this. So for example, we have something called the AMP optimizer which does a lot of like, which performs a lot of the things that cache would perform for you. So for example, the AMP cache will try and provide the lowest source set image on like if it's a mobile device. But like if you're using, if your page is being used on a region they can use something called the AMP optimizer like do some of these cache optimizations on a region as well. So for example, here is an optimized AMP page which is like loaded in what was, I think it was 2.8 seconds. Whereas like the actual AMP page like took 5.2 seconds to load. And all of this is because like it was doing transformations like for example, removing any like blocking, removing any blocking JavaScript, removing any blocking CSS, sorry, making sure that the appropriate sized images being picked, et cetera. So the cache, the AMP optimizer tool like has a bunch of optimizations. And again, the great thing is we're always putting up more optimizations, right? As we see that, oh, the cache does this, we can push it on the cache which means everyone gets it, but we can also push that same change on the optimizer. And which means every time you update the optimizer NPM package, you're getting all of these new benefits for free. And the great thing is, we don't believe that you should be thinking about the optimizer. It should just be a part of your build process. So you can, yes, you can absolutely add the optimizer like into your build process. You can get the NPM package, like decide where in your build process it fits and you can deploy it. But it also comes for free if you're using a few things. So for example, if you're using WordPress, you can use the AMP plugin which will help you create AMP sites. And if you're using the AMP plugin that is created by our team, you get the optimizer for free, which means again, your origin pages are much faster. If you're using Next.js, again, you get this for free, for like server-side rendering. And if your content is more static and you're a big Leventy fan, we recently released Leventy support as well. So again, you'll get optimizer for free. And our intention is to deploy optimizer in more places such as cloudfire workers, deploy a Docker image over time, but like this is where it's currently available. So if you have questions about this, absolutely, you can ask away. And that's roughly it, right? Our idea is AMP should do a lot of the work for core web vitals for you. It should do all of the heavy lifting for you so that by default, as you're running out the gate, you're good on LCP, FID, CLS and any other core web vitals that might be coming down the line. But you can also do some things to add on top of it. So making sure you have a good CDN, making sure you're using AMP optimizer. And I've thrown a lot of terms at everyone. So the best place to like really learn about all of this is like amp.dev. It's our one-stop shop. We're making lots of improvements to it. We're adding tools to it. So hopefully you'll find some information that I can't answer there as well. And with that, like my prepared content is over and I will take a sip of water.