We can’t send you updates from Justia Onward without your email.
Unsubscribe at any time.
The third annual AMP Conf happened this April in Tokyo, and one of Justia's own was there for the whole thing. Check out what is new with the AMP Project in our wrap up of the announcements from AMP Conf 2019.
Spring is here, as is the beginning of tech conference season. In the last month Google has had two major conferences. First was its annual conference on Cloud Computing and Enterprise technology called Google Next, which took place in San Francisco, and then a week later Google devs traveled to Tokyo for the third annual AMP Conference.
Among those in attendance at AMP Conf this year was Justia Engineering team member Luis who was excited to get time with the Google devs and other AMP developers from around the world.
In the space below, we describe some of the most recent developments in the AMP project.
AMP is no Longer an Acronym
One of the smaller announcements at AMP Conf is the decision to change AMP from an acronym to a word. When the AMP project began it was an acronym for Accelerated Mobile Pages. As time has gone by and the AMP project has grown, the project is less and less about Mobile Pages and more about Accelerating the internet as a whole. As such the new governing body of the AMP project has decided to change the meaning of AMP. While it is still stylized in all caps, AMP is now a single name representative of the speedy experience it is meant to bring to email, news, and the web—mobile and otherwise.
reCAPTCHA on AMP Pages
As we mentioned in our post two years ago, shortly after the project introduced support for forms on AMP-enabled pages, it became clear (from numerous issues added to the GitHub repository) that these forms needed CAPTCHA support to prevent spam. As a workaround, webmasters could implement a custom CAPTCHA solution using a combination of <amp-form>
and <amp-list>
to pull in the dynamic data necessary to generate the form field, but there was no official support for more advanced CAPTCHA options, including Google’s own reCAPTCHA project, on AMP pages.
We were pleased (though not surprised, given the recent activity on the GitHub issue) at the announcement at AMP Conf 2019 that the <amp-recaptcha-input>
plugin is now generally available, allowing developers to add reCAPTCHA to their forms.
AMP Cache on Your Own Domain
One of the main ways AMP accelerates your webpages is by allowing Google (and others) to pre-process and cache the content so that it can be loaded directly from the search results. In order to do this, when someone taps on your snippet in the Google Search Results from their phone, instead of loading the copy directly from your web server, they instead load this pre-processed copy from Google’s AMP Cache. A similar action happens for people searching through Bing and tapping results on Twitter. While this has the effect of making the page load incredibly fast (nearly instantly), it also means that the URL in the address bar of the browser is not actually your own website but instead the URL of the particular AMP Cache you are using. This has long been a point of contention and is one of the main complaints publishers have had about AMP, as they believe it negatively affects their branding.
The most recent version of the Chrome web browser (and the upcoming version of Microsoft’s Edge browser) have added support for a new IETF standard called signed HTTP exchanges. While the technology behind signed exchanges is complex, the goal and general idea are fairly simple. Signed exchanges basically use the concept of signing content to ensure that it wasn’t tampered with in transit. Normally this protocol is used for ensuring the validity of a single data transfer, but using signed exchanges you can actually package web content, sign it at the source, then transmit that entire package to a verified third party. The browser is then able to read that signature and verify that the content received wasn’t modified in transit (or at least wasn’t modified in an unauthorized way). What this means in practical terms is that you can serve your website (or an AMP version of your website) from anywhere while still verifying that it comes from you. Browsers that verify the signed content will show the original URL in the address bar, instead of the URL of the cache that served it.
Watch this clip to learn more about Accelerated Mobile Pages.
At AMP Conf, it was announced that AMP and the amp-cache protocol now support signed exchanges, and a pilot program will allow publishers to use this new technology to make the amp-cache served content show as coming from their original URL.
At the same time, one of the AMP project’s biggest supporters, Cloudflare, announced that it is adding automatic support for signed exchanges to its CDN so that Cloudflare customers can serve their AMP content from their own domain without having to implement anything on their own servers.
AMP for Email Rolling Out
One of the more exciting announcements from the AMP project in the last year was in regards to AMP for Email. Email has long had a number of limitations, and AMP for Email aims to solve a lot of them.
Support of HTML in different email clients is so spotty that creating an email that looks good in every email client is an incredibly difficult (if not impossible) task. Because the degree of HTML and CSS supported in each client differs significantly, adding functionality to email for one client risks making your email look poor in other clients. Companies often spend substantial amounts of time trying to layer HTML and CSS on top of each other to produce an email that will render properly in all (or most) of the different clients. While AMP emails aren’t directly supported in many (or even most) email clients, they get around requiring this layered HTML and CSS problem by separating the advanced AMP portion in a separate MIME envelope. This is nothing new; most emails already actually have at least two separate email layouts in them—a plain text version used by older email clients that don’t support HTML and an HTML portion. Email clients that don’t support HTML (or where the user has disabled HTML) simply ignore the HTML version and display the plain text version only. AMP emails extend on this same technique by including a third content section containing the AMP version.
Email is by its very nature not interactive; the most interactivity you get in an email is the ability to click a link that takes you away from your email client to a regular web page. The contents of an email can’t change based on your actions, and when an email asks you to do something (like confirm your email address or update your account), you must always leave the email to take that action. Since AMP for Email supports many of the dynamic functionality of AMP including amp-form, amp-bind, and amp-list, an AMP email can allow a user to take action on the content of that message without leaving email, which is much more convenient for the user.
Using remote data retrieval methods such as amp-list also allows the content of an AMP email to change over time. For example, with an email notification about an upcoming flight: if that email is an AMP email, you can see whether your flight has been delayed after the original email was sent.
Shortly before AMP Conf, Google announced that AMP for Email is now rolling out for Gmail. Yahoo Mail, Microsoft Outlook.com, and Mail.ru all announced support for the new standard as well.
Javascript Is Dead, Long Live Javascript
In addition to pre-processing with the AMP Cache, there are a number of other ways AMP accelerates web pages. One of the main ways it does this is by limiting (or restricting) features that are known to slow the rendering of web pages. Chief among these is custom Javascript. AMP actually uses Javascript to accomplish most of its features, but this Javascript has historically been whitelisted, only allowing properly vetted Javascript that doesn’t slow performance. The reason it took over two years to implement reCAPTCHA (discussed above) is that the Javascript needed to make reCAPTCHA work was not compatible with the requirements of AMP.
Unfortunately, restricting custom Javascript severely limited extending the features of AMP pages. While AMP components allowed AMP pages to be very functional and powerful, there were always limits to what developers would ever be able to do. With the announcement of <amp-script
>, it is now possible to add powerful custom Javascript to fill the gaps that AMP simply didn’t allow before.
Javascript under amp-script still has limitations to prevent developers from slowing down their web pages: amp-scripts don’t have access to directly modify the DOM (Document Object Model), changes to the content of the web page must first work within a special separate DOM called worker-dom, and then changes are applied to the normal DOM using an API. Additionally, amp-script files are limited to run within a certain amount of time (five seconds max from last user interaction or the results of an asynchronous external fetch) and must either affect only a very small area of the page or be directly triggered by user actions. Finally, amp-script is size-limited to very small Javascript sources only.
While to many developers these limitations sound significant, amp-script is still extremely powerful, and one of the most popular REACT javascript libraries, Next.js has added first party support for AMP thanks to amp-script
. The amp-script
component is still experimental and not for use on live AMP pages yet, but the AMP team has enabled it for origin trials, which is a big step forward in interactivity on AMP.
Use AMP Components on non-AMP Pages with Bento AMP
One announcement in particular addresses a complaint many developers new to AMP have expressed: AMP requires an all-or-nothing approach. That is, in order to implement AMP you need to make a 100% valid AMP page, which can be challenging. A page written in HTML and CSS can still load and render correctly (or mostly correctly) even with some errors in the code (although you should always validate your HTML). In contrast, if an AMP page is not valid, Google and others will completely ignore it. This all-or-nothing approach has led many developers to avoid AMP altogether.
In response, the AMP project team announced the ability to use AMP components on non-AMP pages with a new feature called Bento AMP. Bento AMP would allow developers to use AMP Components as normal Web Components on any web page.
Whether you simply want the efficient lazy loading of <amp-img>
without lots of your own javascript, or there is a logistical reason that a particular page cannot be AMP (e.g., the page needs Javascript that won’t work within the confines of <amp-script>
), Bento AMP will significantly extend the possibilities.
The team is quick to note that this is a work in progress and will require a major rebuild of the way many of the AMP components currently work, but it is a major goal for the project over the next year.
So Much More AMP
This post is already getting long, but there were other exciting announcements at AMP Conf. Several improvements to AMP Stories increase the ability to tell rich multimedia stories using AMP. A new amp-autocomplete component
is in experiment phase which is useful for search forms. A number of new improvements to carousels are on the way that will help you present other types of content than images.
If you are interested in learning everything that came from the AMP Conf 2019 including things we didn’t talk about in this post, you can check out the recordings of the live stream on the AMP Channel on YouTube and see all the presentations.
I asked Luis if he had anything he wanted to say about his experiences in Tokyo at the conference and this is what he had to say:
In my opinion, the AMP Conference this year was full of exciting announcements for both developers and end users. AMP is getting more features that will allow us to deliver better and richer products to our clients. Here at Justia we are great supporters of the AMP ecosystem, and we have plans to increase its usage and contribute more to the open-source project.
Stay Tuned for Updates from Google I/O 2019
While we are on the topic of announcements from Google conferences, Google’s flagship conference of the year, Google I/O is just a couple weeks away. I’ll be there, as I have each of the previous Google I/O developer conferences since the very first. Once again, I’ll be live blogging several of the sessions here on Justia’s Legal Marketing and Technology blog. Stay tuned here on May 7–9, 2019, as I bring you the latest announcements from #io19.