Posted by Alberto Medina, AMP and WordPress Developer Advocate, Google
Enabling a first-class AMP experience on WordPress is one of the ways the AMP Project aims to bring a user-first experience to websites and content on the web. There has been a lot of work over the last year to improve the quality of the official AMP plugin and today we are releasing version 1.0-stable of the Official AMP Plugin for WordPress.
Version 1.0 of the plugin integrates AMP content creation seamlessly with standard WordPress content creation workflows across both classic editing, or Gutenberg-based editing. In particular, a native AMP experience is supported in this release, allowing for WordPress sites to be built entirely with AMP, without a duplicate AMP version of a page in ‘paired mode’.
Features and capabilities of the 1.0 release include:
Content sanitizers: to help substituting HTML tags for their corresponding AMP components ones, implement optimizations, and feed validation information to the plugin compatibility’s tool (see below)
Compatibility tool: to assist the development of AMP experiences by enabling AMP debugging based on exposing extensive and detailed information about validation errors that may exist, the markup/scripts causing them, and the specific components on site (e.g theme, plugin, core) bearing the responsibility of that page content.
CSS Tree Shaking: to assist in the process of putting the CSS-house in order in cases where existing CSS rule exceed the maximum limited permitted on single AMP pages.
Core theme support: enabling full AMP validity for four default themes (i.e. 2015, 2016, 2017, 2019).
Gutenberg integration: enabling AMP content creation fully integrated with Gutenberg, the new and powerful editing experience in WordPress.
Native AMP experiences support: enabling full-site AMP experiences without sacrificing by one-bit the flexibility of the platform, or the fidelity of content.
A myriad of code, performance, and developer experience improvements: from customization flexibility, to better UI flows, internationalization, accessibility, etc. Check the full list in the release post.
Opti-in/Opt-out support: all functionality is available in an opt-in manner. And users that do opt-in have the option of enabling AMP only on specific sections of their site, and also disable AMP at a granular level (e.g. on a single post)
Compatibility enforcement: to ensure that a site stays AMP compatible and that only AMP-valid content is ever served
We invite you to try the new release by:
Upload the plugin to the /wp-content/plugins/ directory in your site
Activate the plugin through the ‘Plugins’ menu in WordPress
If you currently use older versions of the plugin in Classic mode, it is strongly encouraged to migrate to Paired or Native mode
The official AMP plugin for WordPress provides essential tools and functionality for AMP content creation, the WordPress way. It is important to note that the plugin is not a completely turn-key solution to “AMPlify your site”, but instead functions as a key enabling technology for a fully AMP compatible WordPress ecosystem.
The journey ahead is one along the road of ecosystem adoption. As we advance on this road, more plugins and themes will be available with full AMP-compatibility provided out-of-the-box, and site owners will easily find AMP-compatible components to assemble full sites when selecting plugins from WordPress.org plugins/themes page.
In the future, we expect there to be turn-key solutions site owners can leverage to easily provide awesome AMP experiences regardless of their level of savviness. Our ultimate aim is for high-quality AMP content in WordPress-powered sites to be ubiquitous.
Join us as we continue on this journey and please share your feedback on the latest release. We’re enthusiastic about the potential the plugin has to improve the user experience on the web and look forward to what is ahead.
Over the past two years, the AMP Project has been working with Igalia to identify bugs and missing features within iOS WebKit and then fix them. We create repro cases, write web platform tests, perform debugging and analysis, and, of course, write patches to actually fix things. We think this is particular rewarding work, because it helps ourselves achieve our goals faster, but also makes the web more predictable for developers overall.
In this blog post, we provide an overview of the work done in 2018 with hints about when improvements will be available in iOS releases or when they will have to be handled by Apple. Some of this work is still in progress and we keep proposing new ideas and reporting bugs.
We submitted patches for the following bugs which are now fixed in the latest iOS 12.1 releases:
We have been watching some improvements and verified that they are included in the latest iOS 11 releases. These two items were handled by Igalia in 2017 thanks to support from the AMP project:
Improving frame sandboxing, including implementations of new sandbox attribute values such as allow-popup-to-escape-sandbox, allow-top-navigation-without-user-activation and allow-modals flags. This allows apps to more securely sandbox ads from doing bad things.
Fixing flickering for fixed positioned elements in iframes when touch scrolling is on. See bug 175135
These bugs triaged by us were fixed by other WebKit developers:
We have collaborated with Igalia’s and Google’s Web Platform engineers to make the following features available in WebKit trunk. Apple does not comment on future releases but we keep watching them to verify when these improvements arrive in iOS releases.
We are thrilled to continue collaboration with Igalia and other browser developers in order to keep improving WebKit’s web platform implementations. Next year, we plan to continue the effort on the current tasks but we also have various other ideas related to networking, UI and more. Stay tuned!
Originally posted on Medium by Vamsee Jasti, Product Manager for AMPHTML ads at Google.
We’ve made a lot of progress in delivering a user-first advertising experience on AMP pages, but along the way we’ve learned that the principles of AMP pages can be transferred to display ads to make a step function improvement.
We set out to solve the issues of security & performance using AMPHTML ads (FKA A4A/ AMP ads) and have the benefits available not only to AMP pages, but also to any environment where display ads are served — regular web pages & mobile apps.
AMP’s tech lead, Malte, wrote about AMPHTML ads’ humble beginnings in this post (I’ll summarize most of it below but you should also consider reading it to know where we started and how we’ve evolved over time).
We’ve come a long way since then, and today I’d like to talk about:
What AMPHTML ads are
What AMPHTML ads aren’t
Why publishers should want AMPHTML ads
Why advertisers should want AMPHTML ads
Support status of AMPHTML across the display ads ecosystem
What AMPHTML ads are
AMPHTML ads is a framework that gives ad developers, advertisers, ad servers and publishers, the building blocks to create and deliver ads that are performant and secure.
Similar to AMP, an AMPHTML ad is only valid if it’s made of HTML + CSS + the JS from the open source AMP Project repo.
AMPHTML ads are a strict subset of the AMP page spec and ships with many good-by-default ads UI components, an analytics measurement framework, a spam detection system, viewability measurement and other goodies.
What AMPHTML ads are not (at least, not yet)
AMPHTML ads don’t ensure that the visual content of the ad is high quality.
Why publishers should want AMPHTML ads
When an ad is developed in AMP, the ad will have minimal performance impact to the web page and it gives back publishers control over the user experience of the page.
Ad creators vary a lot. Even a well-intentioned advertiser could create an ad that could lock up the CPU, janking the webpage and resulting in your visitors quitting your site. Then, there are a small minority of malicious advertisers set out to serve themselves ahead of your experience and your users. These issues can give knowledgable visitors another reason to install an ad blocker. One of the main reasons for this behavior lies in early design decision for legacy ads on the web allowed embedding ad iframes with arbitrary (a lot of times with terrible performance) JS.
Wouldn’t it be great if we could guarantee that the JS used within an ad is always performant and doesn’t deteriorate the page performance by too much? We expect AMP to meet that bar and since the code is all open source, anyone can review it and suggest changes to improve further. In addition, the following properties of AMP solve a number of issues of the display ads ecosystem:
All AMPHTML ads are statically analyzable, which means that ads can’t run:
any code that isn’t part of the public AMP GitHub repo
additional JS that isn’t part of the rendered ad code
All of the code in the AMP repo is open source which is carefully reviewed. Therefore, it can’t have things like JS that takes advantage of a chipset level vulnerability which could steal passwords entered to your websites. If a malicious actor tried to add such code, the AMP maintainers have a process in place to ensure that such code isn’t merged into the repo.
Rapid & universal upgradeability
If we discover a vulnerability in the AMP code or at lower level stack that’s taking advantage or stealing user information from your site, the AMPHTML ads runtime can be updated and most users will have the latest version of the secure ads runtime within a day.
Self-aware of page performance
Animations within an ad can have a lot of impact to page performance. AMPHTML ads automatically pause animations when they are off-screen saving precious battery & CPU.
Caching a single library
Another performance benefit of using a single ads runtime standard is that different ad functionality can reference the runtime that is in the cache across multiple AMPHTML ads served to the same browser. As the volume of AMPHTML ads increases on the web, more users will have the ads runtime available in the browser cache. Contrast this to loading two different libraries for two separate functionalities, both of which are less likely to be available in the browser cache.
Efficient rendering in same-orgin iframes
For AMPHTML ads, the ads script can serve them into iframes on the same origin as the script tag which is more efficient compared to loading the ad into a cross domain iframe. This is only possible because AMPHTML can’t have custom JS and therefore reduce risk from a security perspective.
Why advertisers should want AMPHTML ads
Built-in ad UI components
AMPHTML ads ship with a number of UI components that allow ad creators to build great looking ads, with full access to the web animations API, a first-class analytics framework and viewability support. These built-in modules are developed with performance in mind, so advertisers can be assured they are using the best in class browser/app APIs to build this functionality.
Viewability measurement without discrepancies
Viewability is probably one of the most important metrics advertisers care about, and publishers, advertisers and ad tech, each want to verify viewability on their own resulting in each inserting their own JS to collect viewability data.
Problem is, each one of them uses their own technique to collect viewabilty. This is not only a terrible waste of CPU, it leads to viewability mismatch between the three collectors. AMPHTML ads rely on browser native APIs like Intersection Observer to collect the most accurate viewability measurements and send them to anyone that requests it. Since all of this code is open source, an advertiser can inspect the collection methodology themselves if they choose to.
A lighter / more performant ad leads to more clicks and higher viewability. This should be pretty straightforward to reason, because one can’t click or view an ad if it doesn’t render on screen fast enough. This means that an advertiser should be incentivized to build a performant ad so they get more ROI on the same spend.
However, given the typical separation between advertisers, media agencies & creative agencies, the advertiser has little control over the performance of the ad created by the creative agency. AMPHTML ads ship with a development time validator which gives a boolean answer to developers as they are building an ad if it’s valid AMPHTML. If it is valid, the creator can be assured that the ad would be performant.
Create once, deliver everywhere
In the near future, an advertiser would be able to create a single AMPHTML ad and deliver across web pages, AMP pages & mobile apps. AMPHTML ads will also natively support the SafeFrame API and the MRAID API, so advertisers can take advantage of advanced host (web or app) level functionality in a uniform way.
It takes a village to make transformational changes like these, but some industry thought leaders have already spent significant amount of time & resources in helping bring more AMPHTML ads to the web. You can note current status of each of these using this link.
What’s the end goal?
With AMP’s new governance model and industry participation, we think we can help advertisers and publishers use AMPHTML ads to deliver every single ad served on the web and mobile apps. If we accomplish this, we will be in a world where:
Ads will be respectful to users’ devices and publishers’ web pages
Ads won’t impact the performance of a publisher page, earning them better revenue
Ads will earn advertisers higher ROI including better viewability
Users will be more secure on the web and therefore find fewer reasons to install ad blockers
I hope you’ll join the AMP team in helping solve one of the most important and interesting challenges on the open web — advertising.
Two key features of AMP’s new governance model are the Technical Steering Committee (TSC) and the Advisory Committee (AC). We have endeavored to ensure that these committees consist of people who bring a wide variety of perspectives, with representatives from different AMP constituencies. The initial membership of these committees is:
Charles Vazac, Akamai
Dane Knecht, Cloudflare
Dave Merrell, The Washington Post
Elisa Budelli, Automattic
Guilherme Souza, Terra
Joe Alicata, Vox Media
Léonie Watson, The Paciello Group
Levi Durfee, Bulldog Creative Services
Nicole Sullivan, Google
Pablo Delgado, El País
Senthil Padmanabhan, eBay
Sumantro Das, 1-800-Flowers.com
Tim Jones, The New York Times
Tobie Langel, CodeSpeaks
Yinhuang Lu, AliExpress
Technical Steering Committee
Chris Papazian, Pinterest
David Strauss, Pantheon
Dima Voytenko, Google
Malte Ubl, Google
Paul Armstrong, Twitter
Rudy Galfi, Google
Saulo Santos, Microsoft
Another key feature of the new governance model is the Working Groups, where most of the day-to-day work in AMP is done. A proposal for the initial set of Working Groups has been made. The Technical Steering Committee (TSC), who is responsible for creating Working Groups, had their founding meeting November 29, 2018 and discussed the proposal as well as made recommendations for additional groups. The initial list will be confirmed in the next TSC meeting in 2 weeks.
I am excited to see AMP entering this next phase, and I am looking forward to working with the entire AMP community towards achieving our vision of a strong, user-first open web forever.
Posted by Malte Ubl, Member of the AMP Project Technical Steering Committee
EC-CUBE, one of the largest open source ecommerce CMSes in Japan, has released a beta plugin to use AMP for their ecommerce stores. The plugin was built by EC-CUBE’s well known partner SUNDAY SYSTEMS, Inc. in collaboration with Mobile Solutions Consultants from Google, in just one month 😲. For websites who use EC-CUBE, you can try the plugin here.
A PHP based CMS with more than 1.8M downloads and 30K+ live merchants, EC-CUBE was seeking further opportunity to satisfy the UX of their end users. They just released their major update v4.0.0 in October 2018 which focused more on the backend performance and architecture. Now they have decided to put effort in optimizing the frontend as well, leveraging AMP and key PWA technologies. The newly released AMP plugin is still in an experimental phase but already has some remarkable features which provide faster and optimized UX/DX.
To reuse existing assets and work with their PHP developer community, the AMP plugin will convert current PHP Twig templates into valid AMP templates. No need to struggle with AMP specific syntax!
The plugin is fully integrated into the CMS admin interface. Developers will be able to turn on/off the plugin, customize layouts, build components and edit the converted AMP templates directly from a dedicated UI.
Developers will have the option of “paired AMP mode” and “AMP first mode”. In paired AMP mode the main site is unaffected, but the first landing page (such as from a search engine) is optimized using AMP. In AMP first mode, the whole site is changed to always return AMP for all pages on the site.
It also works as a PWA. Having Service Worker and Web App Manifest bundled in the plugin, developers can now add an EC-CUBE store to the homescreen of a mobile device and even think about offline use cases.
EC-CUBE has performed a trial with their default template (an ice cream shop🍦) and have seen a significant improvement in speed, as well as their canonical features being converted correctly to AMP. For example, using `amp-sidebar` for the slide menu, fetching product options with `amp-list`, changing the price once the user selects the option with `amp-bind` etc.
In their trial, they also experimented PWA features such as add to home screen and offline browsing. Merchants can now start thinking about leveraging these App-like features in their business strategy.
We’ve seen steady growth over the past year in AMP Stories and we are delighted to see the various ways content creators have taken advantage of the rich, immersive canvas for storytelling. We’ve been testing this with a handful for pilot partners and today, we are excited to give all content creators an opportunity to monetize their stories.
Introducing Story Ads
Story Ads are fullscreen ad placements that appear in AMP stories. When we set out to create the advertising experience for story ads, we built it on top of three principles:
1. Immersive We wanted to ensure that story ads were immersive and engaging. Like AMP story content, story ads use the entire screen to convey a brand or message using a combination of video, image, or animations. A user continues the tap gesture to skip over the ad if uninterested but also has a consistent way to explore the ad using the call to action button. In addition, every ad has a ‘consistent’ ad attribution label, so users are easily able to distinguish between an ad vs organic content inside a story.
Ad placement & insertion are orchestrated by the runtime and therefore story ads are shown to the user only once they have fully loaded. As a result, story ads by definition are 100% viewable.
3. Open Continuing in the AMP project’s footprints, we wanted to create an ad ecosystem where any ad provider could participate in delivering monetization solutions for story creators. AMP now has close to 100+ ad network integrations, and we hope to achieve a similar level of diversity for publishers. If you are an ad provider that wants to integrate with AMP stories, please reach out to us.
Today, we are launching support with Google Ad Manager to deliver direct sold ads.
Signed Exchanges, used by an AMP Cache, have benefits for users and publishers, beyond the visual experience of the URL bar. Signed Exchanges also:
Provide a guarantee, using cryptographic signatures, that the content is exactly what the publisher intended to show the user.
Allow the browser to treat a document as belonging to the publisher’s Origin. This allows a publisher to use first party cookies to customize content, execute service workers, and measure analytics.
Signed Exchanges are part of a wider web proposal named Web Packaging. The Web Packaging specifications, first proposed in 2015 as a W3C draft are evolving over time with feedback from members of standards bodies, other browser vendors, security experts, and publishers and web developers.
Steps to try a Google Search demonstration
Signed Exchanges are currently only enabled in Chrome version 71 or greater. At the time of writing, this requires installing from the Chrome Beta channel but it will soon be released to all Chrome channels.
If you are not using a mobile device such as a smartphone or a tablet, enable mobile emulation on your browser. AMP pages are only displayed to mobile devices. Next, visit https://g.co/webpackagedemo.
This will display a search box. From there, enter a query such as [learn amp by example] and click on “Learn AMP by Example” for the ampbyexample.com home page. There are only a small number of publishers that have implemented this feature so far, so you may want to try this specific query. If you’ve completed these steps correctly, you will see “https://ampbyexample.com” displayed in the browser’s URL bar.
That’s it! The AMP Cache has preloaded the AMP document and Chrome has cryptographically verified that the AMP document was never modified from what the publisher intended, thus enabling the publisher’s URL to be the one that populates the browser address bar.
Under the hood
The moment a Google Search returns an AMP result, the Search results page instructs the browser to fetch the AMP document, “prefetching” it by the device in the background.
When a user clicks on that result, the AMP document can be displayed instantly. This works in part because the document clicked was already fetched and partially loaded.
An important privacy principle is that until the user clicks on a document, third parties should not be able to determine that the user is interested in it. If preload caused a browser to make network requests to servers other than Google’s, then some of the intent of user queries would leak to sites the user never even clicked on.
To achieve this, neither the document nor any resources fetched before loading the document, can be fetched from third parties. Only once the user has signaled intent to load the document by tapping it do those resources get fetched. We call this mechanism “Privacy Preserving Prefetching” and it provides a buffer between the user and the publisher until the user has chosen which document to visit.
In order to preserve privacy while still prefetching documents, the referrer, Google Search in this case, must load the document from a Google server, the Google AMP Cache.
We would like to achieve the Privacy Preserving Prefetching while simultaneously maintaining the URL and Origin model of AMP documents. We are achieving this using a new collection of browser technologies being drafted under standards bodies such as the W3C and IETF, called “Signed Exchanges”.
A Signed Exchange is an HTTP Request / Response pair, cryptographically signed using a publisher’s own Certificate Private Key. In other words, Signed Exchanges provide digital proof to a browser that the document delivered by an AMP Cache has not been modified from what the publisher intended.
When a browser sees a Signed Exchange and can validate the signature, the browser can display the publisher’s URL, regardless of where the file was delivered from.
To help publishers build Signed Exchanges, the AMP team has built a tool that can be run by publishers to package and serve Signed Exchanges. The tool is called the AMP Packager.
The AMP Packager runs on publisher’s own infrastructure as a web server backend. It acts like a proxy, accepting an HTTP request for an AMP Web Package, forwarding that request to the publisher’s own backend, and then transforming it into a Signed Exchange.
In addition to packaging the document, the AMP Packager also applies transformations to the document that optimize the page for serving on an AMP Cache. These transformations modify the document itself, without changing the way it looks to users. However, publishers should be able to inspect the code that makes these transformations, so the AMP Packager code, including the transformations applied, is open source.
Developers who want to opt-in to this developer preview should be first aware that the specification is still changing, and this is an implementation of a snapshot of it.
Once deployed, allow a few days for the Google Search crawler to revisit your site, after which you should be able to try the experience by using the Google Search Demo instructions above.
Option A: Run the AMP Packager tool
The AMP Project has provided the AMP Packager, an open source tool, with detailed instructions on how to run it on your own infrastructure.
During these steps, you will need to generate a new certificate with the CanSignHttpExchanges extension from your Certificate Authority. At the time of writing, the only Certificate Authority that has built a Signed Exchange certificate request flow is DigiCert, with detailed instructions that can be found at Digicert CanSignHTTPExchanges.
Option B: Use a Signed Exchange–Enabled CDN
If you use a CDN provider, ask them if they can provide AMP Signed Exchanges.
At the time of writing, Cloudflare has announced an experimental Cloudflare Worker application implementation of Signed Exchanges as a service to its customers. See this Cloudflare blog post about Web Packaging for more information on how to enable Signed Exchanges on Cloudflare. Once deployed, allow a few days for the Google Search crawler to revisit your site, after which you should be able to try the experience by using the Google Search Demo instructions above.