 Recently, a friend sent me a link to a news article she thought I'd really enjoy. I clicked on the link and waited. And waited 5 seconds, 10 seconds. My friend doesn't send me too many links and when she does, they are usually really good. So, I wanted to see what this is, but I'm still waiting. Something starts to load and I can start reading this article. Closed that full screen banner appears asking me to install the app. Oh no, close that. I can finally start reading this article and it is fascinating. But wait, why did the content just jump? Where was I? And why is it so slow to scroll down the page as I read? This experience happened to users too often. The first load is way too slow. The user experience is degraded by content that caused the content to leave low. Text flashes as fonts load and third-party scripts that cause performance issues. We put a lot of emphasis on how to stay fast using service workers to cache content. But the first impression counts. If your app takes too long to load, it doesn't matter how awesome it is or if you've got service worker set up for subsequent loads. You're really focused on the three-second number. But remember, that's the point which more than half of your potential users have left. So we need to do better than three seconds. Humans perceive events that happen in 100 milliseconds as instant. Things that happen in the one-second lens probably don't seem instant, but still feel natural to us. And then in the 10-second lens, we are beyond the attention span of most users. Ideally, we want our app to load in less than one second. But on mobile, it often takes additional time to establish a connection. If you need to do more than a handful of land trips to get the resources for your first load, you'll easily exceed the three seconds time. The current situation isn't great. Today, the average mobile site takes more than 19 seconds to load after making more than 200 requests. Often, these extras are added to try to increase the monetization or conversion on our sites to attract more users and help keep us in business. This leads to a difficult balance between improving the user experience or focusing on monetization and user acquisition. Fortunately, there is a solution that doesn't involve floor gardens, native app experience, or forcing user to uninstall ad workers. We call it Accelerated Mobile Pages, or AMP for short. Let's take a look. AMP is an open source project that uses existing web technologies and is built in collaboration with many different partners. AMP dramatically improves the performance of the mobile site on the web, often to the point where their load appears to be instant. Almost immediately after clicking on the link, the article I want to read is ready to go. AMP has another goal other than to just fix load time. It also addresses runtime performance, so pages are always responsive and usable with no more shifting content. AMP pages are built with three core components. First is AMP HTML. AMP HTML is HTML with a few custom web components, a few replacements, and a few constraints for reliable performance. Though most tags in an AMP HTML page are regular HTML tags, some HTML tags are replaced with AMP specific tags. These custom elements, called AMP HTML components, make common patterns easy to implement in a performance way. For example, the AMP image tag provides full source set support, even in browser that doesn't support it yet. Or AMP iFlame if you need to include content that may affect page performance. One key thing to point out here is that AMP pages do not allow JavaScript beyond what is provided through the custom elements. This ensures that the page is always able to maintain its performance goals. Second is the AMP.js library where a lot of the magic happens. It implements all of the performance best practices and optimizations, manages the loading of resources sufficiently, and provides the key functionality for the built-in custom tags. AMP has a static layout system, which means that resources such as images, ads, or iFrames must state their size in the HTML so that AMP can determine their position on the page before they are loaded. Because AMP.js knows exactly the size of every resource, it can pre-calculate the layout of every element on the page and prioritize loading for the resources. It will give priority to resources about the fold and lazy-load resources below the fold. AMP.js library also ensures that anything that comes from external resource is loaded encyclastically, so nothing loaded in the page can block anything else from rendering. And finally, AMP cache. Essentially, a CDN to serve cached AMP HTML pages quickly no matter where the user is. The Google AMP cache is a proxy-based content delivery network for delivering AMP documents. If fetches AMP HTML pages, cache them across Google's worldwide network and deliver them from the same origin using HTTP.2. Not only do you get the performance benefit of HTTP.2, but page load time drops because content is cached near to where the user actually is. Use of the Google AMP cache is optional, and a lot of the baked-in optimization can be done by experienced developer. When a document is served from the AMP cache, AMP can quickly pre-lender only the first viewport because it knows the size and position of every element. Even before any assets are loaded, if a user clicks on one of those pre-lendered AMP pages, they get an experience that feels nearly instant. And unlike normal browser pre-lendering, it's completely opaque to the site owner, which is critical to help maintain user privacy. They'll never know the page was viewed unless the user clicks on one of the links. AMP makes it super easy for us to start fast, but the experience will be somewhat constrained because advanced platform features like web push, notifications, and add-to-home screen aren't available. What we really want is the ideal user journey. We want their experience to start fast and allow them to stay with a fast and rich experience as they engage with all the content in our application. We want to start fast and stay fast without any limitations or restrictions. What if we could combine AMP and PWA and use AMP as an entry point to progress a web app? This way, we get the benefit of both. Use AMP to start fast and use ServiceWalker to stay fast. The question we need to solve is how we can achieve this when we can't run JavaScript on an AMP page to install ServiceWalker. For that, we can use the AMP install ServiceWalker tag, which makes it possible for you to install your ServiceWalker for your origin, even when your AMP page is served from the AMP cache. Essentially, there are three models we can choose from. AMP as a progress web app, AMP to a progress web app, and AMP in a progress web app. For sites that are study content heavy and don't have a lot of interactivity, AMP as a progress web app is a good option. We use this technique when building AMP by example.com. When the user first visits the page from the search, they get the AMP version served from the AMP cache, which includes the manifest link to AMP install ServiceWalker. While the user is leading your article, the ServiceWalker is installed, and caches the AMP content served from your domain. Then when the user clicks on the link, they navigate away from the AMP cache version to the version that's been cached by your ServiceWalker. Even though it's being served from the ServiceWalker cache, it's still using AMP rivalry to serve AMP HTML. Because it has a web app manifest, Chrome can plump the user to add to home screen too. In many cases, you probably want some more interactivity than what AMP offers. AMP to progress web app is ideal case where we have content that is good for AMP, but we also have a PWA providing more dynamic content and interactivity. When user searches for something and click on the link, the page appears to load instantly because the content is served from the AMP cache. While the user is leading your article, the ServiceWalker is installed and can pre-cache your progress web app and any initial data. Then when the user clicks on any link on the page, your progress web app shows up instantly. One disadvantage of this technique is that your backend needs to generate content in two different formats. AMP HTML that can be served and consumed by the AMP cache and on the first load, and JSON or other data format for your progress web app. That's where AMP in a progress web app comes in. An AMP page is more than just a web page. It's an efficient, ultra-portable, embeddable content unit. When pre-rendered as part of AMP cache, it's essentially embedded. Instead of having two data formats for two different experiences, we could use the AMP HTML to power both experiences. The easiest way to do this would be to load the content in an iFrame, but iFrame can be slow, and each time you load new content, the browser needs to reload, recompile, and initialize the AMP library over and over again. In the world of AMP pages, the world is simple. One window, one instance of the AMP library, and one document. If we implement this approach using iFrames, then the AMP library will be loaded, parsed, and compiled every time we load AMP document into the iFrame. But there's better way. Shadow DOM. Shadow DOM is one of the four web component standards, others are HTML templates, HTML imports, and custom elements. Shadow DOM is basically the DOM that the also of web components writes. With Shadow DOM, there's only one window and one instance of AMP library, but there are multiple documents. This results in super fast transitions between AMP documents as the library has to be compiled only once. We have a sample app on GitHub that does exactly this. It's simple react-based progressive web app that displays AMP content. When the user clicks on the link, the PW hijacks the navigation click and fetches the AMP content. When it gets the content back, it puts the content into a new shadow loop and calls at that shadow doc to tell main AMP library that there's new content available. So with these approaches, we can combine the ability that AMP gives us to get a very fast first load and the powerful capabilities of a progressive web app. In this way, we can achieve the perfect user experience, one that starts fast and stays fast. If you want to learn more, we have lots of resources to help you. Thank you for watching.