Accelerated Mobile Pages (AMP) introduce a powerful new tool for web authors to get their content loading faster than ever on mobile. While some might see them as just one way for Google to win ad revenue back from Facebook Instant Articles, web developers and content publishers see them as a set of cheat codes to a whole new level of mobile and search optimization.

Simply put, if your web page follows the AMP standards, Google can deliver it, fully rendered, to nearly any mobile screen in the world in under a second. But how does AMP work? Two principles make this speedy delivery possible: proximity and simplicity.

Proximity

Half of achieving AMP speeds is shortening the literal distance your page must travel to reach a user’s device. This is done by caching AMP pages on the massive network of Google Cache servers across the world. For standard web pages, Google typically only caches enough information to display it in a search results list—like the title and description—and opening the full page still requires a request back to the web server. Conversely, AMP pages are stored in their entirety on Google’s cache. In fact, the simplicity afforded by the AMP spec even allows for pages to be pre-rendered within cache. This involves things like calculating page layout and loading images in advance so there’s almost no processing left for the browser to do when it’s time to show the page.

The AMP specification simplifies things like page layout and loading images, so there’s almost no processing left for the mobile browser to do when it’s time to show the page.

Simplicity

Modern web standards, or the rules for setting the look and feel of a web page, tend to give developers a lot of freedom. In the right hands they can be used to soften the mobile web experience to the point when users can forget they are even on a website. In the wrong hands, however, it can produce the sort of battleground page where wider-than-your-screen pop-up ads fight one another for your attention. Both of these examples—and the other billion-plus web pages out there—follow the same set of standards.

AMP pages are able to load in under a second because—in addition to the classic web standards—they must also comply with the much more rigid Google-prescribed AMP standards, which cut out anything that could cause unnecessary slowness. These include major restrictions on external assets like custom fonts, stylesheets, and—of course—scripts.

CSS rules, for example, cannot exceed 50 KB on an AMP–compliant page. This is based on the principle that the time needed to style a page moves on a more-or-less linear scale with the number of CSS rules. Custom JavaScript, however, is a much bigger unknown, and is simply not allowed by the AMP spec. This is the biggest pain point for most developers, so let’s take a moment to understand why it’s necessary. First, consider these two snippets of JavaScript code:

Both do the exact same thing—add four new images to the page—in effectively the same amount of time, but the second one does it in half the code due to slightly better design. This illustrates that the sheer size of a script is not a reliable predictor of how long it will take to execute (as opposed to CSS rules). Furthermore, the work done by either of the above scripts could be easily undone in a single line as follows:

This is a good example of why even one line of JavaScript is too much for AMP to make any promises.

But…no JavaScript?

Google is aware of the enormous role of JavaScript in the modern web, which is why they haven’t kept it out of AMP entirely. Instead, Google only allows JavaScript code that was generated by them. This is possible through the AMP component library—a collection of configurable AMP tags—for example, <amp-carousel>—which, when embedded, tell Google what functionality developers want on the page. Then it can inject the necessary JavaScript during the pre-rendering phase.

Available components include simple animations, analytics trackers, and plugins for third-party content providers like YouTube and Vimeo. The library even supports banner ads, customizable for a growing list of existing ad platforms. For site owners who don’t write much JavaScript to begin with, the AMP component library might actually bring even more features easily within reach. I encourage anyone to check it out before deciding their page is too complex to fit in the AMP spec.

The “AMP Stamp”
If you’re already achieving near-AMP load speeds with nothing more than old-fashioned good engineering, well done! But there is still a pretty good reason to explore implementing the AMP spec, even if it’s not necessarily to improve performance. Each AMP article features a lightning-bolt logo which users will likely come to see as a beacon of good quality.

First, consider that AMP is more than just a speed boost. Other mobile headaches are addressed as well, such as the barrage of aggressive banner ads that drain your battery life when you tap the wrong link. If users see an ad on an AMP page at all, they can rest assured that its role was designed by Google to be as lightweight as possible, rather than being designed by advertisers to maximize click count. AMP ads are also confined to one specific area on the page, and will only load after the main content has loaded. In other words, AMP pages deliver a consistent, undeniably superior mobile experience. The fact that they are visually distinct from non-AMP pages in a search results list means users are likely to form new habits.

Habit Loops

Human habits (such as googling) are stored in the brain similarly to how applications are stored in computer memory. These habit loops consist of three parts: cue, routine, and reward. An example of a cue is a TV commercial that triggers the thought, where do I know that actress from? The reward in this case is when the answer presents itself on your mobile screen. The routine—crafted by your years of using Google—is the series of motor and cognitive functions needed to navigate from cue to reward. The difference between a habit loop and a software application is that only the latter needs a user’s permission to push an update. Indeed, you might already be scanning for that “AMP Stamp” without even knowing it. Google has expressed that they are not updating their search algorithm to demote non-AMP pages, but rank won’t matter if the next massive habit loop update makes those pages effectively invisible to users who will come to prefer AMP without even realizing it.

Flip The <Script>

So, how should publishers and web developers decide whether or not their strategies will include a dash of AMP this year? The factor that will best determine the size of the effort is how script-heavy the current implementation is, so we’ll explore the following three scenarios: no script, simple script, and heavy script.

No Script
If your page already doesn’t use JavaScript and contains less than 50 KB of CSS, the task ahead could be as easy as adding a few required tags. AMP away!

Simple Script
This refers to a page that does contain JavaScript, but each script has only one job within the page and does not depend on any other script. A common example is a script-based analytics tracker, which normally employs a few lines of JavaScript to listen for user interactions and send live reports as necessary. Because all custom script must be removed before your page can be AMP–compliant, you’ll want to replace it with an equivalent AMP tag from the component library.

AMP tags tell Google about some functionality you want on your page, then it injects the necessary JavaScript as part of the pre-rendering process. Replacing a block of custom JavaScript with its equivalent AMP tag is what I like to call “flipping the script.” In this case, developers would add a tag called <amp-analytics> with your own account data, as illustrated here.

The library is surprisingly robust in terms of integration with third-party tools as well. If you’ve checked it out and all your scripting needs are covered, feel free to get flipping.

Heavy Script

This is for the pages crafted with lots of developer love, where custom script flows like honey. An example is the “one-page app” model, popular on mobile, but ironically a very bad AMP candidate. As its name implies, a one-page app consists of a single HTML page whose job is basically to kick off a custom-built JavaScript app and let it take charge. The app creates the illusion of multiple pages by listening to user interactions or URL changes and updating the view as necessary. For sites like these, URLs tend to refer to individual “views” (or visual “states” of the app) rather than physical pages.

If this sounds like your website, we obviously wouldn’t recommend scrapping what you’ve built and starting over—not that you ever would. As a web developer myself, I can certainly appreciate the beauty of a well-choreographed JavaScript dance. Deeply custom web experiences like yours are likely to grow in demand as AMP pushes the web in a more homogenous direction. The problem is that AMP tags are designed to be simple and lightweight, and developers would go insane trying to teach them all those sophisticated dance moves. Developers could focus instead on just teaching them enough steps to produce a single view.

For example, suppose the main feature of your page is a JavaScript widget for booking flights. The functionality of that widget is likely beyond the capabilities of the AMP component library. However, if users can only access that widget by first going through a “home” view (i.e., home is where users land if they come in from Google search), and the most complex feature on the home view is an image carousel, then AMP is still on the menu. The trick is to create AMP “replicas” of the site’s most popular entry points, then simply link back to the full experience. This way, your website benefits from all the power of AMP, but you can still immerse users in the same custom experience.

At a glance, its similarity to Facebook Instant Articles suggests that AMP is limited to simple, self-contained news articles. Indeed, the success stories thus far have been from news publishers, probably because those content rich pages with few bells and/or whistles are the easiest to bring up to the AMP spec. However, this pigeonhole might be blinding other would-be adopters to what AMP truly offers to web pages of any kind: a means to win the Google face-off on mobile. Think of it this way: the same technology that was conceived to keep users from clicking out of the Facebook ecosystem is now freely available for you to funnel users into your own ecosystem.

The next frontier appears to be ecommerce, with Ebay leading the charge. Once more online retailers begin to see AMP for its potential, the ripple might leave many of them wishing they had taken the trend more seriously.