Best Practices for Accelerated Mobile Pages
The Accelerated Mobile Pages project is in response to Facebook’s Instant Articles (and to a lesser extent Apple News), in which publishers put their content on a closed platform in return for fast performance.
Facebook’s argument for Instant Articles is that the majority of article pages load far slower than they could (and should) do.
However, this locking-in of articles into Facebook’s platform is disadvantageous to its competitors, especially Google, whose business model still primarily relies on web-based advertising.
Their alternative, launched recently, is “Accelerated Mobile Pages”, a new open source format designed to load as fast as possible.
What does that Actually Mean?
Accelerated Mobile Pages HTML is a highly restricted subset of HTML, giving up a lot of control for fast load time and high performance.
What are the Major Restrictions Regarding AMPs?
Here’s just a few highlights of the Accelerated Mobile Pages and practices associated with the same:
• Custom JS is allowed only in pre-approved components
• No iframes
• No forms elements, although buttons are allowed
• Images, audio and video tags are replaced with custom versions that can be controlled by the Accelerated Mobile Pages runtime
• All CSS must be in a single <style> tag in the page head
How Does that Make it Faster?
There are countless optimizations built into Accelerated Mobile Pages and it’s practices’ HTML’s architecture, but the main things are:
• Very small number of initial server requests
• No risk of out-of-control external JS
• All JS and media is lazy-loaded
• “Above-the-fold” content (visible without scrolling) is prioritized
• Element dimensions are known by default, so there is no “jumping” when they load in
These are all good things, and most of Accelerated Mobile Pages HTML’s techniques (themselves not necessarily original) are applicable to your own website.
What Custom Components are Available?
To provide anything beyond basic HTML and CSS, we must use pre-approved widgets (known as “ACCELERATED MOBILE PAGES HTML Components”).
In theory, anyone can submit a new component to the official list, but they must be approved by “the creators of the Accelerated Mobile Pages component project” (which includes Google and a few other organizations).
The technical specifications are relatively strict: for Accelerated Mobile Pages, loading of external resources is controlled by the Accelerated Mobile Pages runtime and the component must have a fixed, known aspect ratio at initial page load.
In addition, all insets must also be open sourced with an Apache 2 license.
None of this is magic, just good ideas. However, Google has pledged to store Accelerated Mobile Pages HTML content on their own high-performance cache, further speeding up load time.
Even more attractive is the idea that Google may prioritize Accelerated Mobile Pages HTML content above standard web pages – something they have not announced, but is believable considering that Google search results already rank “mobile friendly” sites higher.
Presumably breaking the Accelerated Mobile Pages HTML standard (and failing the Accelerated Mobile Pages Validator) will disqualify your pages from these bonuses.
Overall, it’s great for readers, who get their articles delivered to their devices faster. But if it becomes the norm, Accelerated Mobile Pages will restrict our ability to experiment with article design and interactive content.
The best defence against Accelerated Mobile Pages and practices is offence: turbocharging our own websites’ performance so there’s no need to go along with these locked-down technologies.