Accelerated Mobile Pages (AMP) are feathery pages shaping a faster and engaging reading experience for mobile users. AMP is backed by Google, primarily the reason why you’ll find most AMP pages as a top search result.
Publicists and publications have come to protest the favourability towards AMP, alongwith the monetisation Google achieves by having cache serve others’ content on its server.
In this article we’ll see what AMP is, how it works, and why online users are averse towards using the lightweight Google-supported pages.
What is AMP?
AMP uses a cleaned out code called as AMP HTML to accelerate the loading of content. Pages that take no user inputs can be rendered in advance and AMP HTML does exactly that.
AMP was launched in response to kindred projects like Facebook Instant Articles, where Facebook hosts and renders content within their news feed with FIA.
Unlike FIA, AMP uses an open-source framework. Meaning other companies can host and serve content generated on sites akin to Twitter, Tumblr, Pinterest and Google search.
AMP is its own architecture. While the users are technically browsing your content, it’s not being supported by your framework. Many a times people fetch the AMP version of an article instead of the main website. This creates a confusion about ad revenue holdings.
More than half the population with internet access does it through mobile phones. A bigger load time increases the bounce rate of the page.
All the work that goes into the content creation is flushed due to AMP compressing large files. The elements displayed may also differ depending on rendering speeds.
Publications like Wired have boasted about a 25% increase in their site engagement. Other giants have come to reap AMP’s benefits too.
Smaller outlets don’t have such skilled developers for resources. Popping out a chance for a higher Search Engine Results Page (SERP) placement for them.
Also read: How to change WiFi on Google Home?
How does AMP work?
A page’s download time reduces 15-85% through an AMP plugin. The 2018 AMP HTML documentation claims an 800% performance jump, albeit there aren’t any sources to second these numbers.
Notwithstanding, users found their loading times reduced by 20-30%. The following features explain how:
- Static sizing of all resources: Every external resource of the page such as images, iframes, or ads should state its size in the HTML. AMP determines the size and position of each element beforehand and loads the page layout nonetheless.
- Avoiding rendering blockages: Extension mechanisms always impede the rendering of a page. AMP can take in additional HTTP requests for extensions of embeds, tweets, lightboxes, etc.
- By allowing third-party JS but only in sandboxed iframes doesn’t block any further execution.
- They’re told to trigger simultaneous re-calculations but an undersized DOM causes not latency.
- Efficient font triggering: Web fonts come in large sizes. Thus the importance for web font optimization. A page with few sync scripts and external type sheets waits to download the fonts until these requests are completed.
- AMP doesn’t declare any requests until the fonts have started to download. Owing to its async feature, the browser can download fonts faster.
- Resource loading: By loading what is needed, AMP controls other facets of resource downloads. It also prefetches lazy-loaded resources.
- Resources that are to be loaded as late as possible, are fetched the earliest. Images and ads are only downloaded when the user has to see them.
Why isn’t AMP preferred by users?
The implementation of the AMP format is what has raised concerns among numerous publishers and developers alike. When viewing a Google recommended piece or when opening a shared AMP link, a user remains within Google’s ecosystem.
The publisher’s domain ends up getting obscured through the google.com/amp prefix. Google has rolled out Signed HTTP Exchanges which ensure that the site’s original URL is displayed. This merely covers the fact that you’re viewing an AMP page.
Preferencing faster-loading pages isn’t a problem, although clear flaws like disallowing non-AMP pages to pre-load can’t be overlooked. Should publishers allow it and if Google sees it fit, all pages could be subject to pre-loading instead of just AMP ones.
Furthermore, Google and the publisher of the said AMP may each collect data about you. As it specifically says so in Google’s support article. The above flaws are solely regarding AMP cached pages.
Non-cached AMP pages only utilise the AMP framework. This offers a small improvement in performance but with a less feature-rich experience. AMP’s implementation has made the framework to act against the abundance of open-web and privacy.
Many developers now inculcate AMP cache’s optimisations in their build process, including steps like:
- Caching images and fonts,
- Creating additional sizes and adding srcset for support,
- Automating resource hints inclusions like ‘dns prefetch’ and preconnect.
AMP is now a much broader project and looks into amplifying mail, stories, and the UX of websites. Google’s Top Stories carousel was only limited to AMP pages until this year. Many users took notice and stated it to be Google’s bid to reinforce their web dominance.
Come 2021, Google looks to open the carousel to non-AMP pages.
Tech Enthusiast. An Engineering student who loves writing, music, memes and cinema.