Last week around one hundred contributors joined us in NYC to catch up face-to-face and discuss exciting new developments in the world of AMP.
We mixed in a lot of different formats this year; pairing up expert talks with active breakout sessions. We also opened the floor up to more informal conversations, which gave the community more opportunities to share ideas.
The big news this year? AMP is joining the OpenJS Foundation incubation program! It’s an exciting development, which will open up key support services while allowing AMP to maintain our own identity, technical focus, and product direction. Check out the ripples the Summit made on Twitter here.
The excitement builds!
With contributors arriving from around the world – there was plenty of buzz descending on NYC. It was so awesome to see groups that usually communicate through Slack and Github come together to build stronger friendships.
Bombshell after bombshell
There were some big announcements throughout the event – from new features to the big news about AMP joining the OpenJS Foundation. On top of that, the breakout sessions got everyone working together to build their skills and grab a sweet treat in the form of AMP cupcakes!
The dust settles
Nothing brings people together more than shared interests. The last few days have been a fantastic opportunity for the AMP community; everyone jumped in with two feet to share their knowledge and build offline friendships.
The feedback on this year’s Summit has been so positive – and we’re pumped about the direction our wonderful contributors are taking AMP in. For everyone that came along for the ride – we’d like to sincerely thank you for helping to build and improve upon AMP.
We can’t wait to see the exciting times ahead for AMP, but we need your help. If you’re interested in contributing, join one of our working groups and get involved today! Have specific questions on getting involved? Join in the conversation on our Slack channel. Curious about the talks given during the summit? Check out the presentation decks here and stay tuned to our YouTube channel, where we’ll be uploading videos of all the talks in the coming weeks.
Written by Alex Durán, AMP Project Marketing Lead at Google
Email is still the preferred method of communication for marketing campaigns, transaction alerts, handling customer grievances, mass communication, etc. According to The Radicati Group Inc., the number of worldwide email users will increase to over 2.9 billion by the end of 2019. Over one-third of the worldwide population will be using email by the end of 2019. But can it be even more powerful? Can we make email more engaging and interactive as if someone is browsing a website? Can we serve real time dynamic data no matter when an email is opened? Can we collect information from within the email itself without leaving our Inbox?
Yes, yes. With the AMP Project introducing AMP for Email, all these things are now possible.
What is AMP for Email aka dynamic email?
Wait, I have heard about AMP
You must have. But AMP for Email is different from AMP for HTML, though both are open sourced and part of AMP project. AMP for Email has a few more rules than AMP for HTML in order to ensure a smooth email experience for users; for example, file upload using <input type=”file” /> is not supported (as of now) in AMP for Email but it’s there in AMP for HTML.
Okay, but how is it going to work?
Email consists of MIME (Multipurpose Internet Mail Extension) parts such as text/plain for plain text email and text/html for an HTML email. To make the email clients recognize the AMP for Email, a new MIME type text/x-amp-html was introduced. This MIME part will contain AMPHTML markup.
Most email sending libraries and services already started support for this new MIME type e.g. Nodemailer (a library to send emails in node.js) put support in v6.1.0.
Hmm, interesting. Show me AMP for Email in action
Yes, of course. Here is one demo in which an imaginary company “Beautiful Flowers Shop” is asking its customers to provide feedback for different flowers offered by company.
Awesome! I want to learn AMP for Email too. Tell me everything.
To develop a dynamic email, you will need the following four things:
1. A valid AMP for Email markup. This would be your email template which would be rendered in Email. You can validate your markup here at https://amp.gmail.dev/playground/. A sample hello-world markup would be something like:
2. An email library which supports text/x-amp-html MIME part in email body. You can use Nodemailer in node.js. An example snippet can be found here. If your dynamic email is going to contain API calls then you will have to meet CORS requirements.
3. Testing dynamic email in Gmail. Gmail won’t allow dynamic emails to be rendered (it would be rendering html instead) unless your email address is officially whitelisted by the Google team (step 4). But to test your email on some particular Gmail account, you can use the dynamic email developer setting to whitelist from address. https://developers.google.com/gmail/ampemail/testing-dynamic-email
4. Whitelisting your email (sender address) by Gmail so that your dynamic email is rendered to end users. Once you are ready with your production email, you will have to send it to firstname.lastname@example.org for whitelisting along with filling the registration form. A complete guide can be found here.
Note that Gmail doesn’t whitelist per domain, the whitelist works per email sender (e.g. if email@example.com is whitelisted, it doesn’t apply to all @example.com addresses).
The last two steps are Gmail specific. If you are using Microsoft Outlook, equivalent steps will have to be performed there as well. You can refer to Outlook’s official documentation. Information about AMP for Email on mail.ru can be found here.
I am overwhelmed by so much information
That’s okay! Take your time. When we at Goibibo started this Proof Of Concept, it took us only 2 days to develop a dynamic email and test it in our personal Gmail accounts, but it took us 2+ weeks to make our email use case production-ready and get it whitelisted by Google so that we could send it to our end users. We wanted to send our hotel partners a dynamic email to collect feedback about Extranet (hotelier’s platform for managing rates & inventory) and this is what we came up with:
We specifically used AMP for Email to allow hoteliers to “Reply to Reviews” from their checked-out guests. For example, after a customer stays at the hotel, checks out, and leaves a review, the hotelier has the ability to respond to the review within their email.
Earlier we tried this using a hyperlink to Hotelier’s platform called Extranet, and this used to have a B2B email open rate of 14% to collect replies to reviews from the Hoteliers (B2B). During Proof Of Concept, which we ran on 2 different occasions, we got an amazing response with path-breaking email open rates.
AMP for Email is really promising and we at Goibibo are going to use it moving forward in our email campaigns. There are some initial challenges like setting up infrastructure for handling AMP API requests and training our email-design and marketing teams, but the end results are going to be really awesome.
On behalf the AMP Project, I am happy to announce that AMP is joining the OpenJS Foundation incubation program.
AMP was founded as an open source project four years ago to provide a framework that allows web developers to more easily create fast, user-friendly experiences. We have sought to make AMP a welcoming community for contributors, and have now had nearly 1000 people contribute code to AMP.
Last year we worked with the community to develop an improved governance model to ensure AMP’s technical and product direction were made from a diverse set of voices from the community, representing many AMP stakeholders and constituencies.
At the time we made these governance changes, we announced our intention to move AMP to a foundation after the community had adapted to the new governance model and when we found the right foundation for AMP. That time has now arrived. After considering many options for a foundation that meets all of AMP’s needs, the OpenJS Foundation stood out as an ideal home for AMP.
There are many reasons that the OpenJS Foundation is the right choice for AMP, including:
The OpenJS Foundation offers projects the independence to maintain their own identities, technical focus and product direction while offering key support services that projects look to a foundation for, such as a funding mechanism, legal support, etc.
We are already aligned on governance philosophies as AMP’s new governance model was significantly influenced by the governance models of the two organizations that formed the Open JS Foundation, the JS Foundation and Node.js Foundation.
For more details on the foundation search and our reasons for choosing the OpenJS Foundation, see the presentation from AMP Advisory Committee member Tobie Langel and OpenJS Foundation Executive Director Robin Ginn at the AMP Contributor Summit today.
With approval from AMP’s Technical Steering Committee and Advisory Committee, AMP recently kicked off the OpenJS Foundation’s Project Proposal Process. After reviewing the proposal the foundation’s Cross Project Council (CPC) has accepted AMP into the foundation’s incubation program. Over the coming months AMP will work with the OpenJS Foundation to complete the on-boarding checklist and join the foundation.
Google will continue to be a strong supporter of AMP. Google is already a platinum member of the OpenJS Foundation, and will continue to provide additional financial and other forms of support to the foundation to ensure a thriving AMP community and ecosystem. The team of Google employees contributing full time to the AMP open source project will also continue to do so.
We are looking forward to working with the broader OpenJS Foundation community during the incubation phase and beyond to keep the web open and sustainable.
Malte Ubl, on behalf of AMP’s Technical Steering Committee
When AMP launched in 2015, Simon was starting his career with Online-Results A/S. He’d been researching AMP in his spare time to hone his skills and stay up-to-date with industry trends. Eventually, he learned enough to build a static site generator for AMP pages from his home.
Having developed a passion for AMP, he brought his site generator into work to show its capabilities to the SEO team. This started a journey that transformed Online-Results A/S’ business offerings, and propelled Simon from intern to company partner in half a decade.
Could you give us a bit of background on your company, and what attracted you to AMP?
Online-Results A/S is a remote digital arm – we analyze patterns in digital behavior and use those insights to build conversion-focused websites and marketing strategies for small & medium sized businesses.
If you’re a company of 10-20 people that focuses on car repairs, you might not have the time or capacity to have a website developer on staff. We can build them easy websites that are intuitive, high-performing, and highly-convertible.
Loading time has always been a huge part of our offerings; we use the Page Speed Insights tool as a big motivator to sell our websites. When we saw that AMP loads instantly on Google Search we made the switch – we wanted to make our fast sites even faster. I give a lot of credit to my management team; after a couple of tests they were willing to throw a lot of time and resources behind making the switch. It’s really paid off.
Did integrating AMP present any challenges?
No, it was really plug-and-play. Turning our static html sites into AMP sites was fast – optimizing them was the journey.
We’d been using a bloated CMS up until that point; a massive infrastructure with constant performance bottlenecks. For the small sites we were building it was like shooting at birds with cannons! So I built a static site generator, then leveraged the AMP community to troubleshoot it.
You mentioned optimizing AMP – do you have any examples?
We never stop optimizing! Just last week I implemented CSS tree-shaking into the static site generator. Now we have an automatic way of going through every page, checking to see if the CSS is actually used on each individual site, and then stripping unused CSS away.
How did AMP impact your business?
The static site generator is at the core of how we use AMP. Every time a designer or developer comes up with a new idea, we go back to our HTML roots and get it built quickly.
Back when we used the CMS, it’d take us hours to build something like a functional slider. Now we can just style it like we would any other HTML element.
How has AMP helped you innovate?
It’s made it very easy for us to create websites – one employee can go from a blank page to a completed site in three to four days now. That’s an optimized site with analytics, call tracking, the works.
Websites used to account for around 3% of our business, now it’s up to 20-25% of our total revenue. We made AMP really easy for our clients to understand. They see the little lightning bolt in Search results and instantly get that AMP’s speed adds credibility and trust to the sites we build.
What advice would you give to anyone considering AMP?
If you’re a developer that wants to use AMP, I can’t recommend the Roadshows highly enough. You should hang out in the Slack chat too, that’s where you get a lot of inspiration. If it all comes crashing down on your first build, then there’s always someone there to help out!
You should also embrace getting back to your roots. It’s easy to fall into the habit of throwing new plugins at each new issue, but we see the 50 kilobytes of CSS limit as an opportunity to express your creativity in new ways.
In my opinion, you can’t build a bad AMP page. It won’t be valid AMP if it’s not high-functioning – so get in there and play with it.
Has AMP helped you achieve any personal or professional goals?
Well, I’m a partner now! It’s helped me massively, and throughout the journey I’ve been so supported. I’m just one guy, I can’t keep building and updating sliders for my entire life. But with AMP, I feel like I’ve got a global team of open source developers working together to create the best components possible.
It’s been such a timesaver, which has helped me to focus on personal development.
What excites you most about the future of AMP?
I can’t wait to see it expand into AMP for Email and AMP Stories. I really want to see how AMP shakes up email. It has the potential to change everything.
If you ask any developer, they hate working on emails. Coding an email is way too difficult! You have to use some 1998 standard, it’s just so annoying. So having an AMP email library will be incredibly exciting.
Are you interested in mirroring Simon’s journey? Check out the resources on amp.dev for everything you need to further your career with AMP.
Editor’s Note: The following post was written by Leo Postovoit, Strategist at XWP.
NOVA Entertainment is one of Australia’s most recognized media brands with a history of radio, media, and local content stretching back 19 years; and GOAT is NOVA’s pop culture, news and entertainment platform built for a mobile-first audience.
GOAT is the first of NOVA’s sites to benefit from development of a progressive-focused WordPress build. As GOAT’s editorial goals include bringing their content to people in a format they find accessible, convenient, and speedy—performance and usability are top priorities. This study reviews how AMP and PWA brought impact to Goat’s recent technical relaunch.
The GOAT website experienced issues with performance and usability. To improve user experience and compatibility with many devices, priority one was to improve the performance of the site. The site’s delays in rendering content and assets were barriers to users and their onsite and sharing behavior. This is not surprising, given that research studies consistently demonstrate how critical performance is for the level of engagement a site receives.
At a tech conference in Tokyo this year, Googler Jeany Halliman opened her speech about a study that Google conducted on site visitors of Media sites about “the one thing they disliked the most when browsing a site”.
“Coming from the ad business, I always thought it would be ads (visitors disliked). But the majority of users said it was a slow website.” – Jeany Halliman
This response correlates clearly with the well observed impact on bounce rates that page speed has, yet its precedence over on-page ads is a surprise to many due to recent attention and “backlash” many Media sites have received about overbearing Ad strategies.
NOVA reached out to XWP, an ecosystem leader in WordPress engineering, and maintainer of the official AMP Plugin for WordPress in partnership with Google. Well known for producing elegant and complex solutions for major publishers such as Rolling Stone, News Corp Australia, and Rogers, and technology partners — such as Cloudinary, Google, BigCommerce, and Automattic, XWP work focuses on building a better web.
Since performance, scalability, and usability were key goals outlined by stakeholders at NOVA, it was clear to XWP that a progressive AMP approach was the way to go.
While the primary objective of the migration to an AMP-first strategy was clear: to create a fast experience that users love to return to and share, it was important to also ensure scale and stability through best development practices including CI/CD, automated testing and high-availability hosting. Combined with high code quality and modern WordPress practices in mind, the GOAT site was made not only to be quick, but also built to last.
With XWP’s experience with AMP and other ways to impact performance, they considered various implementations to achieve NOVA’s goals for the GOAT website. An AMP-first strategy was the best fit because it allows for streamlined development around a single code base.
Going one step further, GOAT seemed to be a great use case for the PWA feature plugin (another collaboration between XWP and Google). This added the ability to provide capabilities such as offline mode, notifications and the like, powered by service workers. And the solution defined leverages the amp-install-serviceworker component, which makes it easier than ever before to combine the benefits of AMP and PWA.
While the PWA features included today are limited in scope, the long-term goals are to add installability on desktop and mobile devices, richer offline mode and pre-fetched pages, native push notifications and the like—just like other powerful PWAs across the web.
When ad loading is not configured properly it contributes towards poor page performance, especially on media-rich sites like GOAT. Working with AMP means the approach XWP took to implementing GOAT’s ad stack had to adhere to AMP standards. Whilst some concessions had to be made to accommodate ad providers which were not fully AMP compatible the overall effect was a highly performant ad-reliant media site. The best of both worlds: a good user experience that isn’t degraded through sub-optimally loaded ads.
As discussed, Goat is the first of Nova’s sites to go live with a unified editorial workflow and performance-focused theme build—as a PWA site, with all templates built as Native AMP. The performance results are noticeable:
The unification of the editorial experience across multiple properties
Google Pagespeed Insights score went up from 7 (yes 7) to 77 on mobile
WebPageTest 3G test: before / after . Key things: start render time decreased by 1.5s. The time to interactive went down from 43s to just 10
Lighthouse test: before / after . First contentful paint went down from 5.8s down to 2.5s (a 3.3s reduction). The performance score went up from 7 to 65. First CPU idle time went down from 16.2s to 5.9s
GTmetrix: before / after . The PageSpeed Score went up from a D (63%) up to B (82%)
Start Utilizing AMP
Based on results as the ones obtained by Goat’s site AMP-first strategy, we recommend learning more about how AMP can be the solution to your current business challenges.
To find out more about AMP, visit the project homepage at amp.dev.
To evaluate your site’s compatibility and see if you can also gain the performance and user experience benefits of AMP, check out AMPized.com, XWP’s service to bring the benefits of AMP to your WordPress sites.
In early August, we announced a midterm election for the AMP Advisory Committee (AC) with the goal of increasing the diversity of the AC’s membership.
Right after we announced the election, Dane Knecht of Cloudflare resigned from his position on the AC, thus freeing an extra seat, but also reducing the presence of CDNs in the committee to zero (Charles Vazac having left Akamai earlier this year). With Web Packaging being such a hot topic, not having a CDN representative onboard was—understandably—a real issue for many on the committee.
We initially wanted to add about four new members to the committee, which we increased to five following Dane’s departure. We gave ourselves a bit of leeway however, in case we couldn’t find the right people or on the contrary where overwhelmed with great candidates. Fortunately, the latter is what happened. And despite opening up two extra seats (including Dane’s), we had to reject some amazing candidates. Hopefully, they’ll apply again when we run our regular elections at the end of the year. We’ll make sure to remind them.
So, without further ado, we’d like to introduce you to the six new members of the AMP Advisory committee, in alphabetical order:
Ali Ghassemi is passionate about the Web and started his career in 2005 finding workarounds for IE6 quirks. Ali currently works at LinkedIn Inc. on LinkedIn.com’s Web infrastructure. He was previously a tech lead in AMP working on UI components.
Jervay Singh is a performance marketing solutions expert for a large financial services company in South Africa. He wishes to bring an emerging economies perspective to the committee, along with his passion for driving AMP takeup within the South African and African market.
Maggie Wettergreen is a web developer and designer focused on building quality user experiences. They have developed AMP pages in multiple environments, notably WompMobile’s third-party AMP system. Maggie wants to ensure that AMP is moving consistently toward being a staple development framework.
Melanie Sumner is a software engineer who is passionate about improving “accessibility by default” on the web. Melanie is concerned about AMP’s accessibility and intends to contribute her expertise as an engineer and advocate for an accessible, open web.
Melissa DePuydt is a frontend engineer currently working as an engineering manager. She previously led solution architecture for clients at Arc Publishing at The Washington Post, where she became interested in build processes and practices that make AMP integration more sustainable and push news websites toward better performance.
Ted Shuter is a product leader at Akamai, focused on making the web a faster, better place to play and work. Ted loves the concept of improving performance, but wants to make sure it is fair and balanced for all users. In particular, Ted brings the perspective of business users and the impact to Content Delivery Networks.
Hopefully, you’ll get to meet some of them at the AMP Contributor Summit in New York, which is just around the corner.
We’re very excited to welcome these new members to the AC and look forward to working together.
Posted by Tobie Langel, AMP Advisory Committee facilitator.
Editor’s Note:The following post was written by David Vogelpohl, VP of Web Strategy at WP Engine. WP Engine is a digital experience platform for WordPress.
In the web development world we often use tools for automation, read books on project efficiency, and deploy an army of techniques to deliver innovation at a faster and faster rate. While we often ask ourselves, “How can we be better at fishing?” many of us rarely ask ourselves “How can we enable our marketers and content creators with the tools they need to fish for themselves?”.
This article tells the story about how and why WP Engine invested in leveraging AMP to help developers create performant, beautifully designed, and feature-rich experiences that content creators LOVE to use.
Why does WP Engine care about development & design efficiency?
In mid 2018, WP Engine purchased Genesis, a theme framework for WordPress and the Atomic Blocks plugin as part of our strategy to deliver intuitive and powerful design and development solutions. Atomic Blocks is a WordPress plugin that includes a library of pre-designed and configurable website components called “blocks” and arrangements of blocks called “layouts” that make it easy for site creators to design and deploy new experiences.
Atomic Blocks users can now leverage the power of componentized page building while creating 100% AMP validated experiences.
This is often achieved with Genesis and Atomic Blocks by leveraging the new block based editor in WordPress which was code named “Gutenberg” during its release to WordPress #core in late 2018.
Users can style WordPress blocks in any fashion (Genesis helps with this); providing configurable design controls to fit branding, pre-loading blocks with content, and integrating blocks with other extensible systems or software.
Here is an example of the block editor in use with Atomic Blocks.
Here is an example of a StudioPress theme which uses this modular-block approach, is highly configurable by content creators, was updated to use AMP, and has an incredible score of 95 on Google’s Page Speed Insights (up from a score of 54 pre-AMP). Genesis users can also make their own custom themes. Here is an example of an AMP site using a custom built Genesis theme. Regardless of the choice of pre-designed or custom themes, thanks to AMP our customers can build incredibly fast sites faster than ever!
Why did WP Engine decide to add AMP support to Genesis & Atomic Blocks?
Considering the desire for certain brands to adopt AMP and the fact that our agency and developer customers felt they were without product support from us or even other products in the WordPress ecosystem, we felt it was imperative to support them when building with AMP.
Of course, with our stated mission of providing developers with tools that make it easy to create experiences content creators love to use, we had to go about this in a way that not only made it frictionless for the developers to create those experiences, but also to do so in a way that allows content creators to not have to think much about AMP compatibility when creating the landing or web pages they need to create.
The content creators had to LOVE creating AMP compatible experiences for their brand.
Adding new features or support for certain standards such as AMP is a tall ask for design and development tools as popular as Genesis or Atomic Blocks. There are considerations for the >600K sites that use those products and an army of developers around the world who rely on those products as part of their daily workflows.
As with many of you, we take great care every time we consider adding something new to our products. When it came to AMP support, we started by getting a pulse from customers on how often they use AMP, what they like about it, and what they don’t.
The feedback we received was somewhat typical of what you’d expect from a broad audience of web developers relative to AMP. Most had actually never built a site with AMP and claimed that their downline customers rarely asked for AMP sites. That being said, many acknowledged that they did have certain key customers (particularly in publishing) that would request AMP sites and that those asks were often rooted in a desire for performance and improved search/social visibility within various platforms.
We then asked, “For customers pursuing an AMP strategy, what tools or techniques do you use to satisfy those demands?” The answer was a bit shocking. The overwhelming response was “We don’t have any!”
How we approached AMP support within Genesis & Atomic Blocks
Google and other contributors released an AMP plugin for WordPress in 2019. This plugin enables many of the key capabilities of AMP for WordPress sites and is optimized for the WordPress core themes. Core themes are themes which are included with WordPress itself; however, most WordPress sites are powered by custom themes created by developers or premium themes created by companies like WP Engine.
Custom themes and premium themes (created with Genesis or otherwise) require the developers of those themes to optimize their code to help ensure AMP compatibility even when using the AMP plugin for WordPress. For example, some of WP Engine’s premium themes included elements which weren’t AMP compatible, so any users of those themes would experience failures in AMP validation.
Additionally, plugins which power front end experiences such as our Atomic Blocks plugin also must make sure their code is optimized to ensure 100% AMP validation.
The AMP plugin for WordPress does take care of a ton of the work in making a WordPress site support AMP; however, certain aspects of your site may require additional work as illustrated above.
Because of these requirements, we embarked on a mission to add capabilities to Genesis for developers to create custom themes with 100% AMP validation, update key premium themes for AMP compatibility, and to replace elements of Atomic Blocks which failed AMP validation.
Building custom AMP themes with Genesis
In our Genesis 3.0 release we added capabilities that allow developers to more easily create 100% AMP validated custom themes.
Creating a 100% AMP validated theme with Genesis starts with installing the AMP plugin for WordPress. The contributor team on the AMP plugin did an outstanding job, so Genesis theme developers get a lot of free wins just by running this plugin.
Here’s a screenshot of what WordPress users see when using the AMP plugin.
Two of the key benefits in the Genesis world related to the AMP plugin is the fact that it automatically converts markup to AMP HTML and handles CSS tree shaking to help theme developers stay within the 50KB CSS limit.
In Genesis 3.0 we replaced these dependencies or made them optional / disabled when running with AMP.
Some of the benefit to Genesis developers is that child themes no longer need to include their own responsive-menus.js script or do any of the work to enqueue it. Genesis now includes this script and handles all the work of enqueueing it, if you utilize the new responsive menus API.
The end result is that it’s easier to build 100% AMP validated themes with the Genesis framework than ever before. Using these capabilities we have been able to easily update two of our premium child themes to be AMP compatible and countless other custom child themes in the Genesis ecosystem have also been updated or created with AMP compatibility.
Since the launch of Genesis 3.0, the community response has been largely positive with many examples of developers not only adopting AMP as part of the sites they build, but also sharing their knowledge and experiences with others as seen here in this great post titled “Building a Native AMP WordPress Site”.
AMPing up the WordPress block editor with Atomic Blocks
Just as custom themes require developers to optimize their code for AMP, plugins which control front end experiences must do the same. In our case, the Atomic Blocks plugin provides a rich experience for site creators to use website components called “blocks” to create new experiences regardless of the theme they use.
Making Atomic Blocks AMP compatible was actually a somewhat easy undertaking as only a few elements of those blocks were failing AMP validation. To me, this is a great example of how many design and development tools are largely AMP compatible as is without the need for a complete refactor.
In the case of Atomic Blocks, we were able to refactor the parts of the blocks and layouts the plugin enables to be AMP compatible. The work was so light, we were able to accomplish this in just one sprint!
In the example below, you can see how easy it is for content creators to create beautiful, performant, and functional AMP experiences without even realizing that those experiences are 100% AMP validated.
These are the types of frictionless experiences that deliver great value to marketing teams and help keep roadmap-zapping, soul-crushing landing page tickets out of dev teams’ backlogs. In this way, brands can leverage the power of AMP while creating new experiences in hours vs. days or weeks.
The future of AMP for WP Engine’s design and development products
For the Genesis theme framework, our engineering teams are keeping up with the evolution of AMP to ensure that our customers are armed with the latest capabilities within the themes they build with Genesis. We are also looking at expanding AMP support across our inventory of premium Genesis themes so customers have more choices when leveraging premium themes and AMP.
For the Atomic Blocks plugin (which is also used in our premium AMP themes), we are continuing a 100% AMP validation approach so users of Atomic Blocks can enjoy the full feature set of Atomic Blocks in an AMP context.
While we realize that some customers or the downline brands they serve may not choose to deploy an AMP focused strategy, it’s important to us that when they do, we arm them with tools that allow developer teams to be able to create beautiful, performant, and functional experiences that content creators LOVE to use.
Written by David Vogelpohl, VP of Web Strategy at WP Engine
AMP stories are a new way of telling stories on the open web. The stories are hosted on your domain, and the format allows you to add assets best suited for the job. Since the 2017 launch, we’ve seen many, many, many examples of engaging and informative stories published to the web.
Analytics capabilities of AMP stories
AMP stories use amp-analytics, the same robust measurement tool behind billions of AMP pages. Publishers can instrument their stories using simple JSON configuration, and the component does the setup, collection and reporting of metrics. If you’re using one of the 75+ analytics vendors that are already integrated with AMP, you can start collecting insights with very minimal setup.
A typical user-journey for a website is very different from stories. On a website a user might read the headline, scroll to the bottom of the page, interact with a form before clicking on a link to the next page. Stories occupy the full viewport and users do not scroll but tap to move forward.
Many in the web analytics community would consider each new page in the story as a new pageview because the content from screen to screen is substantially different. However, as we just covered, the page is just a single element in a full story — and a user usually needs to see many pages to get a full sense of the story. Thus, the question of how we count something as simple as the pageview has enormous implications for our analytics approach. As you see from above, treating every new story page as a pageview could be perceived as inflated metrics.
A better default configuration
AMP Analytics makes it easy to implement the above using any analytics vendor. For instance, with Google Analytics’ Global Site Tag it looks like so –
This default config should give you a complete working configuration for your AMP stories.
If you’re interested in going beyond what the default config can give you, read on to find more advanced use cases with Google Analytics.
Insight #1: What’s my most visited page/slide for a given story?
Create a dashboard in Google Analytics’ web interface by going to Customization > Dashboard
Assuming you assign unique names to your AMP stories in “event_category”: “Title of my story”, we can see what pages were visited mostly by creating a bar graph in your custom dashboard picking dimensions “event_category”, “event_label” and metrics “Hits”.
Make sure to add a filter so that you are filtering “Event Action” to exactly match “story_progress”:
Insight #2 What’s my most visited story across the site?
Create a dashboard in Google Analytics’ web interface by going to Customization > Dashboard.
Assuming you assign unique names to your AMP stories inside your <title></title> tag pair, , we can see most commonly visited pages by creating a bar graph in your custom dashboard picking a grouped by dimension “Page Title”, and choosing the metrics “Pageviews”.
Insight #3 : For a given story, how far into the story users typically go
Since the story progresses from slide 1 to slide N, it is natural that slide 1 is seen by almost everyone, slide 2 a little less and the number progressively goes down. If there are any problematic slides, you will see a dramatic drop in slide viewership from the previous one. The following dashboard will help you visually capture any problematic pages.
You can use the dashboard that you created before ( Insight 1 : Most visited pages by story) to visually capture this
Insight #4: What’s the average number of pages my users see per story?
It is also possible to track events on an average. For instance, story progress can be used to track average story depth.
Navigate to Behavior > Events > Top Events.
With “Event Category” as the primary dimension, click on the pie chart icon.
Add a Secondary Dimension as“Event Action”.
Click on Advanced. Select “Event Action” and select “Story Progress” in the filter and apply.
Select “Avg. Value” from the drop down.
Insight #5: How long on average do users spend on my stories
This post is from the AMP Design Team. We’re product designers and researchers responsible for making sure AMP’s components and overall experience are usable, accessible, and elegant. You can find us hanging out with the UI and Accessibility Working Group on GitHub or in the Contributor Slack.
One of the biggest ways that AMP improves web users’ daily experience is by helping developers make sites that are fast. A unique advantage of AMP is that it’s always improving behind the scenes – we can roll out speed improvements to sites that use AMP without developers needing to do anything.
Performance best practices have always been baked into every corner of AMP, but actual speed is only half the story. While engineers continue to sweat the technical details, on the design team we set out to improve perceived speed. Waiting will always be a part of life – there are some parts of AMP pages our engineers can’t make faster because they come from a service we don’t control (like a Facebook post or YouTube video) or just because they’re large. But there’s plenty of evidence that the environment you’re in affects how you feel about having to wait.
If you’ve used more than a few AMP pages, you may be familiar with the loading indicator we’ve used since AMP launched in 2015:
Today we’re beginning to roll out a new one:
Let’s look at how we got here. We started with three goals:
Make loading feel faster.
Let readers know what’s coming. Since 2016, we’ve used a different loading indicator for ads on AMP pages so people could immediately tell them apart from the main content. We wanted to extend that to more types of content – videos, tweets, Facebook posts, and more – so you don’t have to wait for a video to load only to realize you’re not in a situation where you can watch one, for example.
Modernize the design. We can’t put numbers on this, but many folks on the AMP team felt our loaders could be more visually elegant.
We also needed to keep the design elegant, but neutral. UI that ships with AMP needs to fit in well with the design of any AMP page – that means no dramatic colors or noticeable styling.
We did some prototyping and asked a panel of 2500 web users to look at one of ten different loading indicator designs that “loaded” content after a set amount of time and predict how long it took. The accuracy of the predictions wasn’t important—humans aren’t good at estimating very short durations—but the trends were. Participants estimated that they were waiting nearly a second less with some of our new designs compared to traditional options like the existing AMP loading indicator or a basic spinner. Based on this data and some observations we got excited about during the design process, we chose a design.
We landed on three principles:
Sometimes no loader is better. Showing a loader before you’ve even noticed you’re waiting can be distracting and make the site seem slower.
Keep it interesting. Having to wait isn’t helped by seeing the same repetitive spinner you’ve seen a million times.
Keep it consistent. Having multiple things loading on one page, each with its own loader design and timing, is distracting and sloppy.
To satisfy the last principle, we made sure our design could be adapted to different sizes, content-type icons, and backgrounds. To satisfy the first two, our loader animated in several stages: first we would show nothing, then we’d show an intermediate animation, then finally we’d finish on a spinner that looped until the content was loaded. People wouldn’t see a loader at all if the content took less than a half second to load, and they wouldn’t see a repetitive spinner unless the content took a full 3.5 seconds.
Our design met all three of our goals: we had encouraging data on its perceived speed, we felt strongly that it was more elegant, and it did a good job letting readers know what was coming.
There were some additional details to figure out to maintain AMP’s flexibility for developers. We didn’t want the new design to conflict with AMP’s ability to show a placeholder image, message, or even a custom loading indicator before content has loaded. For content with a simple placeholder image, we still want to indicate to readers that something more is coming, so we’ll show a special version of the loading indicator that will stand out on any color image. For any placeholders more complex than that – messages or custom loading indicators, we won’t show the default loader at all to make sure our design doesn’t clash with yours.
The final proof will be in the live experiment we’ll be running in the upcoming weeks: launching our new loading indicators to a small percentage of AMP pages and keeping a close eye on site performance metrics as well as community feedback. Based on this feedback, our aim is to roll out our new loaders to all components on all AMP pages.
We hope you enjoy the new design and support us in making the user experience of the web better, one small detail at a time.
Posted by Andrew Watterson, Product Designer for the AMP Project at Google
If the above examples interest you, do give <amp-script> a try. Do keep in mind that, in order to preserve AMP’s performance guarantee, there are some constraints:
Content jumping: To avoid unexpected content jumping, <amp-script> generally requires user gestures to change page content.
Page load: Since <amp-script> doesn’t change page content without user interaction, it doesn’t modify content on page load either.
Script size: The script used in a single <amp-script> must be smaller than 150kB. Please note that you’re welcome to use your favorite JS framework, but it must fit within that 150K limit.
API support: Not all APIs are supported inside a Web Worker and WorkerDOM has a list of allowed APIs. In addition, some DOM methods and properties are not yet implemented. The full list is available publicly in WorkerDOM compatibility. Please file an issue if there is an API that you want to see added.
<amp-script> is compatible with frameworks you may already be using such as React, Preact, Angular, Vue.js, jQuery and D3.js.
This was one of the most important requests from developers using AMP. AMP Project is excited that we could help address this while still retaining AMP’s value proposition of speed. You can learn more about how <amp-script> works under the hood here and try out <amp-script> by following this guide. It’s a great way of unlocking a large number of use cases that weren’t possible before!
Please let us know if you have any issues or feature requests, when using <amp-script>.