AMP is a web components library designed to facilitate the development of web pages that are highly performant and provide a compelling, engaging, and fast experience to users. The library does that by packaging a punch of coding and performance best practices, as well as a variety of clever design decisions that help developers achieve their goals while maintaining good performance and efficiency. All these capabilities combined make it much easier to achieve and maintain the desired CWV thresholds that are so important to the success of our sites.
The following is a partial list of the things AMP gives you to help you excel as a web developer:
Asynchronous loading of resources #
One of the main premises of AMP is: never, never, ever, block the rendering of a page. This means that any obstacles that may obstruct the rendering critical path must be removed. And this is achieved by loading all resources asynchronously
Static Layout System #
In a normal HTML page, the browser does not know what the layout of the page will be until the assets are loaded. In contrast, AMP effectively decouples document layout from asset layout, which allows that only a single HTTP request is needed to layout the entire document.
Inline-Size-Bound CSS #
Often pages include one or more external stylesheets and this means that additional HTTP requests are needed to load them with a consequent impact on performance, especially in high-latency scenarios. In AMP, you can have only a single inline stylesheet allowed with a maximum size of 75KB. This means that one or more HTTP requests are removed from the critical rendering path, as well as a bound on the amount of CSS processing to take place in the loading of any AMP page.
Lazy-loading and Extensive use of the pre-connect API #
In AMP resources are loaded only when it is likely they will be seen by the user, and the pre-connect API is extensively used to ensure HTTP requests are as fast as possible. This makes lazy-load requests to happen faster when they are eventually made
Minimize style/layout recalculations #
Every time you measure and change something in a page, the browser has to do a recalculation of the layout of the page, and these operations are quite expensive. To avoid this, there is a simple rule: do not interleave the execution of DOM reads and writes. This is really hard to do in practice; especially in teams with multiple developers because the chance of elements colliding in this way increase. AMP carefully batches DOM operations to minimize style recalculations
GPU-accelerated Animations #
Your graphics card (i.e your GPU) is very efficient computing what needs to be rendered on the screen. GPUs can execute animations. AMP forces you to stay on the fast lane by allowing only CSS animations that can be run on the GPU: transform and opacity.
Resource Prioritization #
From AMP perspective, all of the components making a web page are considered relative to the position of the viewport. Images and ads are loaded only if they are likely to be seen by the user. Also, intelligent resource handling can be done. When something is in the viewport, elements cannot be resized unless the user interacts with the element (i.e. add a resizing UI element). When something is below the viewport, and it wants to be bigger than originally planned, AMP is fine with it. When something is above the viewport, dynamic resizing is still allowed, because we can subtract the potential shift from scroll top so that the elements in the viewport end up at the same exact spot as before.
Optimized Analytics reporting #
Analytics measurements are a really important aspect of web development. If there is no revenue, there is no content. The problem is that sometimes, several analytics library are added to the same page, and that is bad for performance. A solution to this issue is to separate the instrumentation of pages from. Rule: Instrument once, report many times. AMP knows how to talk to major analytics vendors. Events on a page can be measured once and reported to different analytics vendors
The AMP Cache #
The AMP Cache is a kind of CDN for caching AMP documents and make them available for anyone to use close to where they are, for free.
It ensures that served AMP documents are actually valid AMP, which this guarantees that served AMP pages are consistently fast. And it performs a variety of optimizations to make AMP pages to load faster. Such optimizations include: HTML optimizations, removal of duplicate script tags, image optimizations, and others.
Furthermore, the AMP cache allows AMP pages to be pre-rendered safely and efficiently. This is very important because this pre-rendering takes seconds from load time significantly improving the UX.
Pre-rendering #
The AMP Cache works tightly together with the prioritized loading and static layout system of AMP. Since AMP knows exactly where each page element is positioned, even before any assets are loaded, it is able to load just the first viewport, without any low-priority content getting in the way. The rest of the page is rendered once the user has already decided to go to that part of the page. At this point, only images are downloaded; no other resources are loaded.
An important aspect of the AMP cache is that it is privacy-preserving. The site owner won’t ever know that preload/pre-rendering took place. If this was not the case, there would be privacy issues, as the site could otherwise write cookies and mark the page as “seen”. Similarly, on the publisher’s side they don’t want to know that there was a pre-render because that would impact their conversions.