AMP – Accelerated Mobile Pages
The Accelerated Mobile Pages (AMP) Project is a website publishing technology developed by Google.AMP is an open source framework developed by Google in collaboration with Twitter. Accelerated Mobile Pages create better, faster experiences on the mobile web. At its core, the framework allows you to build lightweight experiences for mobile by simplifying the HTML and following streamlined CSS rules.However, over the years, it has become a powerful platform for delivering content directly from search results at almost lightening speed.
Benefits:-
1. Web page speed improves the user experience.
2. AMP page-building is easy.
3. Reduce complexity in your code.
4. 6x More overall traffic.
5. 23% Increase in returning users from mobile search.
6. 3x Faster page load time.
7. Maintain flexibility and control and reduce complexity in your code.
8. Web page speed improves the user experience and core business metrics.
9. Building blocks that ensure performance,
10. Build for a sustainable future in the open web for everyone.
11. Web page speed improves the user experience and core business metrics.
12. AMP can be applied across various web touch points.
Drawbacks:-
1. JavaScript & CSS Limitations.
2. Tracking Problems.
3. Serving Cached Pages.
HTML Tags:-
Example :-
1. Attribute names starting-with “on” are disallowed in AMP HTML for example onclick,
2. AMP class names prefixed with -amp- and i-amp- are disallowed in AMP HTML.
How AMP works?
1. Execute all AMP JavaScript asynchronously
JavaScript is powerful, it can modify just about every aspect of the page, but it can also block DOM construction and delay page rendering (see also Adding interactivity with JavaScript). To keep JavaScript from delaying page rendering, AMP allows only asynchronous JavaScript
AMP pages can’t include any author-written JavaScript. Instead of using JavaScript, interactive page features are handled in custom AMP elements. The custom AMP elements may have JavaScript under the hood, but they’re carefully designed to make sure they don’t cause performance degradation.
While third-party JS is allowed in iframes, it cannot block rendering. For example, if third-party JS uses the super-bad-for-performance document.write API, it does not block rendering the main page.
2. Size all resources statically
External resources such as images, ads or iframes must state their size in the HTML so that AMP can determine each element’s size and position before resources are downloaded. AMP loads the layout of the page without waiting for any resources to download.
AMP uncouples document layout from resource layout. Only one HTTP request is needed to layout the entire doc (+fonts). Since AMP is optimized to avoid expensive style recalculations and layouts in the browser, there won’t be any re-layout when resources load.
3. Don’t let extension mechanisms block rendering
AMP doesn’t let extension mechanisms block page rendering. AMP supports extensions for things like lightboxes, Instagram embeds, tweets, etc. While these require additional HTTP requests, those requests do not block page layout and rendering.
Any page that uses a custom script must tell the AMP system that it will eventually have a custom tag. For example, the amp-iframe script tells the system that there will be an amp-iframe tag. AMP creates the iframe box before it even knows what it will include:
4. Keep all third-party JavaScript out of the critical path
Third-party JS likes to use synchronous JS loading. They also like to document.write more sync scripts. For example, if you have five ads on your page, and each of them cause three synchronous loads, each with a 1 second latency connection, you’re in 15 seconds of load time just for JS loading.
AMP pages allow third-party JavaScript but only in sandboxed iframes. By restricting them to iframes, they can’t block the execution of the main page. Even if they trigger multiple style re-calculations, their tiny iframes have very little DOM.
The time it takes to do style-recalculations and layouts are restricted by DOM size, so the iframe recalculations are very fast compared to recalculating styles and layout for the page.
5. All CSS must be inline and size-bound
CSS blocks all rendering, it blocks page load, and it tends to get bloated. In AMP HTML pages, only inline styles are allowed. This removes 1 or often more HTTP requests from the critical rendering path compared to most web pages.
Also, the inline style sheet has a maximum size of 50 kilobytes. While this size is big enough for very sophisticated pages, it still requires the page author to practice good CSS hygiene.
6. Font triggering must be efficient
Web fonts are super large, so web font optimization is crucial to performance. On a typical page that has a few sync scripts and a few external style sheets, the browser waits and waits to start downloading these huge fonts until all this happens.
The AMP system declares zero HTTP requests until fonts start downloading. This is only possible because all JS in AMP has the async attribute and only inline style sheets are allowed; there’s no HTTP requests blocking the browser from downloading fonts.
7. Minimize style recalculations
Each time you measure something, it triggers style recalculations which are expensive because the browser has to layout the entire page. In AMP pages, all DOM reads happen first before all the writes. This ensures there’s the max of one recalc of styles per frame.
Learn more about impact of style and layout recalculations on rendering performance.
Vision & Mission
Vision :-A strong, user-first open web forever.
Mission :-Provide a user-first format for web content, supporting the long-term success of every web publisher, merchant, and advertiser.
Design Principles
1. User Experience > Developer Experience > Ease of Implementation.
-> When in doubt, do what’s best for the end user experience, even if it means that it’s harder for the page creator to build or for the library developer to implement.
2. Solve problems on the right layer.
-> E.g. don’t integrate things on the client side, just because that is easier when the user experience would be better with a server-side integration.
3. Don’t design for a hypothetical faster future browser.
-> We’ve chosen to build AMP as a library in the spirit of the EXTENSIBLE WEB MANIFESTO to be able to fix the web of today, not the web of tomorrow. AMP should be fast in today’s browsers. When certain optimizations aren’t possible with today’s platform, AMP developers should participate in standards development to get these added to the web platform.
AMP validator:-
AMP Code standard check in https://validator.ampproject.org/ this site.
And your live page check page error or not so use this link https://www.google.com/search?client=firefox-b-d&q=amp+validator and add URL.
