Google: Accelerated Mobile Pages / AMP
AMP stands for Accelerated Mobile Pages, a Google-backed project designed as an open standard for any publisher to have pages load quickly on mobile devices.
When a page isn’t optimized for mobile use, you risk the chance of increased bounce rates—30% of users leave a page if it does not load within 3 seconds. The end product of AMP drastically improves the performance of mobile websites on the internet—so much so that the load time is often appearing to be instant.
AMP JS
The AMP JavaScript (JS) library uses all of the best performance practices, is managing loading resources, and gives the user their custom tags—all to make sure that your page is rendered as quickly as possible. One of the biggest advantages is that is has every element, even those from external sources, synchronized so that nothing within the page may be blocked from rendering.
Other techniques used for performance include pre-calculating the layout of all elements on page before the resources can be loaded, disabling slow CSS selectors, and sandboxing all iframes.
AMP HTML
This is HTML that has a number of restrictions related to dependable performance and a few extensions for putting together rich content that is more than just the basic HTML. The AMP JS library works to help render AMP HTML pages in a speedy manner, and Google’s AMP Cache works to aid the cache of AMP HTML pages.
In short, AMP HTML is standard HTML that incorporates custom AMP properties. Most of the tags in AMP HTML are standard tags, but some of them are replaced to fit with the AMP components. These custom elements work to ensure that common patterns are simple to use.
GOOGLE’S AMP CACHE
Google’s AMP Cache is a delivery network that is proxy-based, used to distribute all valid AMP documents. It transmits AMP HTML pages, then caches them, and then automatically improves upon their page performance. When using this AMP Cache, the document with all of its JS files and images will load from the same origin that is using the HTTP 2.0 for the most efficiency. There is a validation system that comes with the cache system that will confirm if a page will work without depending on resources that are external. The validation system will go through a checklist of sorts to affirm that the markup of the page meets the AMP HTML specifications.
A different version of the validating mechanism comes with each AMP page by default. This one is able to log the validation errors right onto the console of the browser when the page is rendered. This lets the user see how the intricate changes in the code will have an impact on the performance as well as the user experience.
How it Works
JavaScript may be used to modify almost any portion of a web page, but it may also be used to block DOM construction and delay the rendering of pages. To avoid the delay of rendering pages because of JavaScript, AMP allows for only asynchronous JavaScript. These AMP pages forbid the use of any JavaScript that has been written by the webmaster, and rather than using regular JavaScript, an interactive page must be comprised of only custom AMP elements.
Resources that are external, like iframes, ads, or images, have to state their size within the HTML of the page so that AMP is able to determine the size of each element as well as its position before all of the resources are downloaded. AMP will load the layout of the page before the resources have been downloaded.
AMP is conducive to extensions for things such as Instagram embeds, lightboxes, tweets, and the like. These things require additional HTTP requests and those requests are not able to block page layouts and rendering. Pages that use custom script have to notify the AMP system that it will need a custom tag eventually.
Third party JavaScript prefers to use synchronized JS loading. Say that there are 5 ads on a page, and each one of those causes 3 synchronous loads—each one of those having a 1 second delay, you will then have 18 seconds of nothing but load time simply caused by JA loading. AMP pages allow for 3rd party JS, but solely in iframes that are sandboxed. When the third party JS is restricted to iframes, they are not able to be blocked from the execution of the main page. Even when they have triggered many recalculations of style, the small iframes have just a little DOM. The time that it takes to recalculate style and layouts is restricted by the DOM size, and iframe recalculations are quite speedy compared to the recalculating of styles and layouts for the page.
