This Website is Basically AMP HTML

#amp #webperf

AMP HTML is a way to build web pages for static content that render with reliable, fast performance. It is our attempt at fixing what many perceive as painfully slow page load times – especially when reading content on the mobile web.

AMP HTML is entirely built on existing web technologies. It achieves reliable performance by restricting some parts of HTML, CSS and JavaScript. These restrictions are enforced with a validator that ships with AMP HTML. To make up for those limitations AMP HTML defines a set of custom elements for rich content beyond basic HTML. Learn more about how AMP speeds up performance.

I have written in the past about web rendering, and techniques I've experimented with[1][2], but as time goes on, thoughts crystalize and it is worth an ongoing discussion. AMP (Accelerated Mobile Pages) is essentially a set of constraints designed to make websites render faster and ensure they can be sanely cached by interested parties. The protocol subject to the politics, commercial interests and technical complications that are unavoidable, so I have conflicting ideas and general uncertainty about the future. AMP HTML gives applications a realistic way to cache and serve content with great immediacy and I think that is fascinating. Google is the driver, but I would love to see Twitter serve outbound links this way. That would really improve the experience for clicking through to outbound links on the Twitter app, while still giving the content creator a lot of agency over the experience. But, like I said, everything about AMP is debatable.

Regardless of AMP politics, the general mantra is very sound and more websites should be built in this style. This application you are reading from was built with AMP-esque constraints and I think it is wonderful for the user experience. The site loads extremely quickly, internal navigation within the site is blazingly fast, and nothing takes priority over the content.

Inline and Async

The guiding design principle of this application's front end is that everything necessary for the initial render is "inline" and as little computation as possible occurs before the initial experience is rendered. Essentially, that means there is a <style> tag instead of an external CSS script for the styles needed for the page, and then the external CSS and JavaScript files are loaded asynchronously as to not block the render while the assets are being fetched from around the world. There is no code duplication, as all the CSS is written once, in a SCSS file and then required inline as needed. Everything is then cached on the edge via a CDN and served as served to you, the reader, with as little latency as possible.

The edge caching constraint means that supporting information relevant to the functionality of a page, such as whether you are logged in, are fetched asynchronously. The design, both software architecture and aesthetics, needs to support this constraint, but I think that is a great thing. Well-defined opinions and constraints are the lifeblood of a growing system.

More thoughts on AMP

As we move forward, we need to consider the various needs of the application, the needs of the user, opportunities that present themselves, and how we can creatively take advantage of those. As I write this, we have put off the task of making all the pages AMP-compatible because there are no use-cases so compelling that it is worth taking on that ongoing dependency. However, if AMP were to be adopted by Twitter in the manner described above, we would rush to include it.

AMP is on the roadmap either way, but the fact that our basic implementation is 99% compatible already and it would just be a manner of addressing a few particular concerns speaks to the notion that a dependency like AMP is a waste of developer resources if you are not certain about its role in your overall publishing strategy. Any news organization should have integrated AMP long ago because of Google's use of the technology in its mobile news results carousel. I experimented with AMP and wrote about it as soon as I heard about it, but I am glad we did not rush to make it part of our strategy. Time makes us wiser and I am happy to sit on this until the path becomes clear.