Introducing AMP Project

[00:00:00]
>> Let's move on to the very last topic we're going to cover today, and that is AMP pages, or accelerated mobile pages. So, if you've ever seen search results that look like this, and the key to look for is that little lightning bolt and a circle with AMP next to it.

[00:00:20]
This is an attempt to particularly on mobile devices, present users with a really fast loading experience into these links. Right, ridiculously fast, nearly instant, mind blowing. So, in order to make this work, we have to play by some pretty strict rules. And the first one is the hardest, to play what, to play by.

[00:00:49]
We don't get to put our own JavaScript on the critical path to rendering. So this means you're not gonna be using any component library to build your AMP HTML. You you can create iframes that have JavaScript running inside of those. But an iframe is not on the critical path to rendering that outer page.

[00:01:13]
Right, so that is the only way that we can do that. We do get the ability to use some rich components that are centrally maintained in the AMP project. Which is a collective effort that is led by Google and Facebook and a bunch of other companies. But we can't, there is no react and there is no Ember and there is no Angular in an AMP app.

[00:01:40]
So, all AMP JavaScript, which is sort of the whitelisted stuff. The stuff we're allowed to use that is part of the AMP project that is executed asynchronously. What that means is we add the a sync option to our script tags. So that, whenever it downloads we will run it potentially later.

[00:02:03]
And it'll do what it does, when it does finally load. We wanna make sure that we can size all of our resources in advance. Similar to what we had to do with Facebook, before we even start trying to draw a Facebook tile, we already knew what the dimensions of our image are going to be.

[00:02:21]
Same goes with AMP. So we can't use a regular image tag, we have to use the AMP image component which looks a little bit like an image tag. But the key is, size is mandatory, width and height are mandatory on this thing. And the understanding here that I have is, we can compute the layout of the screen for a variety of viewports, right?

[00:02:44]
Variety of viewport sizes, we can lay everything out in advance, and really rely on that calculation being correct. So there will be no reflows, and no shuffling around that might make the layout engine have to work too hard. We don't let anything block rendering. So this a sync JavaScript makes it not block rendering the ability to not include an external stylesheet, which is the next thing here.

[00:03:11]
That makes it so we can't block rendering. We can have inline styles up to a limit of 50 kilobytes, which is a lot of style. But it probably means that we're not going to have one stylesheet for our entire application. And it means you're probably not going to be using Twitter Bootstrap and material design for your AMP pages.

[00:03:30]
You're gonna be building things that are a little bit more minimal with the goal of making them as fast as possible. A part of making sure that everything is either expressed directly in the HTML or taken off the critical path. Is that, there's a focus on making sure the heaviest thing about these AMP pages gets to start downloading right away and that is web fonts.

[00:03:55]
So typically what would happen is, you'd have a reference to an external stylesheet. You download that, parse it, start evaluating all of the statements in it, you'd encounter an at font face declaration. And now you're gonna go and start making a second request out and begin downloading these up to 400 kilobyte font that you're using for this thing.

[00:04:19]
So the fact that the stylesheet is in line, means we don't have the first HTTP request to make. And the fact that the JavaScript is a sync means nothing else blocks, the web font download from happening. It is basically one of the first priority things to happen to get that started.

[00:04:39]
So broadly there's a focus on prefetching resources as early as you can, and then evaluating them as late as possible in the game. So that means that images are not rendered, until they're actually about to be scrolled into the viewport themselves. But you may find that we pre-cache the image as you start to approach that scroll position.

[00:05:05]
There's a new standard called preconnect for trying to download content in advance. And this basically means that, your browser can start the initial groundwork for making a request before you actually say that you wanna make the request. And this might just be limited to getting DNS resolution out of the way and finding the IP address that you actually have to hit.

[00:05:33]
It might be like starting to actually download the smallest pieces of a particular file, or at least getting a list of resources that you have to fetch. But it's sort of a broad term for getting a head start before the click happens. So in terms of getting started with our first AMP app, and this is the last activity we're gonna do today.

[00:05:56]
And one that might be a little more challenging than what we've done today, although not terribly challenging, is you begin by bringing in the AMP runtime. And so, this is something that is hosted on the AMP project's CDN as part of this link itself exactly. Its job is to basically control the downloading and controlling the resource, download, and presentation pipeline.

[00:06:29]
So that they can make sure that rather than falling back to typical request priority, where first you get the HTML and then the JavaScript and the CSS. And then finally, images are coming in after that, and web fonts are very low priority. It gets to make some more dynamic decisions about what's going on.

[00:06:48]
You also have to add this amp-boilerplate style block, which I believe is already in the the starter project that I gave you. It has to be exactly this style block. It involves putting in place a CSS animation that helps kind of transition, an AMP page interview as a user taps on it.

[00:07:11]
This is also linked to an official GitHub page where you can get that style block if you need to copy and paste it from here. In terms of dealing with images, we can't use the image tag for a few reasons. First, there's this concept of source sets. And source sets allow us to, based on device pixel ratio, right, whether it's a low resolution or a high resolution or a very high resolution device.

[00:07:36]
We can actually specify a different source file to use for an image tag. But not all browsers support this yet. All browsers that AMP will show up on, right so I think this is not IE9 and above. This is mobile browsers, and so it is the latest versions of both Safari and Chrome.

[00:08:06]
They're going to support this source that'll work here, you'll notice that we have height and width explicitly to find. The alt tag is exactly the alt attribute does what you think it would do. And here, because we know height and width, we can lay the page out, we know exactly what's going to happen.

[00:08:23]
So, what an image tag does by default is, when a browser reaches it in HTML, it'll just start going to fetch that image right away. That's part of what happens when it runs into an image tag, it goes and gets it. We don't want that to necessarily happen.

[00:08:38]
And part of the reason is that, you wanna save as much data and as much battery as you can on these mobile devices. So this amp-image component has a little bit more control over when we go and download that image. And it might be that, it's so far below the fold that users are unlikely to scroll to it and so it'll never get downloaded or rendered.

[00:09:02]
But like in order to do that, in order to put more sophisticated logic in place, we have to move away from an image tag. If you write custom CSS, you just have to write amp-custom as an attribute in the open tag of your style block, and you can put your custom CSS in there.

[00:09:23]
Keep in mind that important is absolutely not allowed, so your pages will not show up as AMP pages if you attempt to use important. The sort of get rejected as doing something against the rules, so you're not in fast mode anymore. And if you use transition, only GPU accelerated properties can be used.

[00:09:45]
And so, there's no, you will do no fancy animation of left to right position or something like that. Only things we can lean on the GPU for that have to do with the compositing of layers, rather than painting of layers themselves, right? Because we don't want repainting over and over mobile browsers really slow at that.