AMP is a way to ensure that web pages render fast on mobile devices, for a better user experience (UX). Visit and browse https://www.ampproject.org/learn/overview/ to learn more about AMP. Other than fast rendering, one advantage of AMP pages is that Google will cache AMP pages for you for free. There are some restrictions as to what a valid AMP page can include (such as no custom JavaScript), but it allows you to use the full power of CSS. We use the 'dynamic', server-side features of Node.js to help with serving AMP pages where appropriate. It is, however, possible to create a completely static site that serves AMP. In this tutorial, we show how both AMP and non-AMP versions can share common resources to limit content duplication.
In VS Code, reopen the 'topseed' project you installed in Lab 5. Then select menu 'View-Integrated Terminal'. Ensure you are in directory /demo-topseed-io and type 'node index [Enter]'.
In a browser, go to http://localhost:8092 and see /page/one/ come up. Rightclick on the page to 'Show HTML source'. You will note that the head tag has AMP-specific content. To compare, review the HTML source or the non-AMP version at localhost:8091.
In production, we would likely map port 8091 to www.mydomain.com and port 8092 to m.mydomain.com. Behind the scenes, we have a Node module at /server/util/Decider.js. The function of Decider with regard to AMP is twofold: (a) if a request of /page/one/ is on the first port, it will return the HTML from /page/one/index.html; if the request is on the second port, it will return the HTML from /page/one/indexA.html. (b) it will attempt to return the alternate version if the requested one does not exist, no matter what port the request arrived on. You can change port numbers in /config/ServerConfig.js (restart with 'node index').
Let us inspect how AMP pages are composed differently, but share some resources. Inspect /page/one/indexA.pug. Our convention is to post-fix AMP-specific resources with a capital 'A'. See how /indexA.pug uses _baseShellA.pug and _headerA.pug, but uses the same _footer.pug as non-AMP /index.pug.
Likewise, both /index.pug and /indexA.pug share the use of _hello.html.
indexA.pug also has a required 'canonical' link that points to the non-AMP version of the resource. Also note that /indexA.pug does not have the 'script' element, since AMP does not permit custom JavaScript. AMP has some custom tags/components to help building AMP pages; see https://www.ampproject.org/docs/reference/components. For example, JavaScript is allowed inside an amp-iframe (example at https://m.appthings.io).
Inspect /_part/_baseShellA.pug. It includes '_topA.pug', which is a non-JavaScript version of '_top.pug' that uses the '#sidedrawer' anchor combined with CSS to obtain the slide-out functionality without JavaScript. Also inspect /_part/_headerA.pug. It includes '../_sass/mainA.css' inside a 'style(amp-custom='')' tag. This means that the CSS for AMP is served inline rather than from a separate request. mainA.sass has the same content as main.sass, but having a separate file for mainA allows us to compress or mininize it (we use Prepros on the individual file) for inline use, since AMP files have a total size limitation.
Both AMP and non-AMP versions have the same responsive design features: they adapt to screen size. The AMP version should just be served faster, as optimized and privileged by Google caching. This may be especially important for the home page, where you do not want to let the user wait unnecessarily for the page to render. For custom behavior, you can force the non-AMP version by using the whole path /page/one/index.html in links or in the browser. We could make all 'a href' links in the app to go to non-AMP versions by adding /index.html to them. We usually do this to take advantage of the (JavaScript-based) Topseed Turbo feature that provides for a smoother single-page application feel.
In summary, the app supports fast AMP responses but provides for non-AMP fallback versions where necessary. For example, a 'Contact Us' page that uses JavaScript to validate submissions would not have an AMP version. Decider.js on the server-side helps to automatically serve the available version.
You can use an AMP validator to ensure your AMP is valid; see https://validator.ampproject.org. Your markup has to be valid to be indexed and cached by Google. If your page is online, you can re-validate and submit it at https://search.google.com/search-console/amp.