The Performance Beacon

The web performance, analytics, and optimization blog

How to do real user performance measurement for Google AMP sites

How to do real user performance monitoring for Google AMP sites

If you care about web performance, then you’ve no doubt been following Google’s Accelerated Mobile Pages (AMP) Project, which seeks to create better, faster experiences for mobile users. According to Google, AMP pages load 85% faster than standard mobile pages. Not only do these faster pages make visitors happier, but Google also prioritizes AMP-enabled content in its search results.

With the Spring 16 release of our Digital Performance Management platform, SOASTA is proud to offer the first product to capture real user measurement (RUM) data from AMP sites. This post will give an overview of how AMP works, its challenges when it comes to measuring performance, and how we overcame those challenges at SOASTA.

What is AMP?

The Accelerated Mobile Pages (AMP) Project is an open-source web framework that enables publishers to create very fast pages for mobile devices. AMP supports a subset of HTML5 markup tags and adds some new ones.

Google-AMP-mobileThe framework imposes certain restrictions to help speed up load times, but still allows for full featured sites. These restrictions include:

  • Like traditional web pages, AMP sites can include images, audio, video, advertising banners, and pay walls.
  • Custom fonts and CSS formatting helps keep the publisher’s branding cues. CSS, however, must be inlined in the page.
  • Custom JavaScript is not allowed outside of sandboxed iframes.
  • Images and videos must specify rendered size to avoid slow DOM reformatting.
  • Publishers cannot set custom cookies or write arbitrary data to localStorage.
  • AMP-specific tags are available to easily include third-party content like Twitter, Youtube, Instagram, etc.
  • AMP has built-in page validation to check if the page conforms to the specification. Simply add ‘#development=1’ to the URL and look for warnings in the browser’s developer console.
  • Downloading of resources that are visible in the viewport is prioritized. Resources below the fold are lazy loaded.

The project also provides a high-speed caching CDN — free of charge — which transparently hosts AMP pages.

How to add traditional analytics for AMP

There are several ways to add traditional analytics to AMP sites:

  • Analytics code could be included in iframes, although security restrictions limit the collection of timing data with this method.
  • Tracking pixels can be used with the ‘amp-pixel’ tag.
  • Built-in analytics vendor configurations can be enabled with the ‘amp-analytics’ tag.

The dataset available to be sent back to the analytics server is pre-defined in AMP and without access to custom JavaScript there was nothing you could do to get all the performance metrics needed for true RUM analytics. Traditional server log analytics and server-side APM also fall short because traffic may not hit your servers at all while being served from AMP’s CDN.

Bringing RUM to AMP

As I mentioned at the top of this post, we’re proud to offer the first product to capture RUM data from AMP sites. We’ve contributed new features to the AMP project that allow for very fine-grained timing data to be captured from mobile devices. In fact, all the navigation timing data available in browsers implementing the W3C Navigation Timing interface is now available to everyone in AMP. mPulse can filter your traffic and allows you to compare AMP versus traditional traffic in real-time.

How to add AMP to mPulse

READ MORE: New mPulse features: Availability monitoring, Rigor integration, and full support for SPAs and Google AMP

What have we seen so far?

Among our customers who are using mPulse to measure their AMP pages, typical page loads require orders of magnitude fewer resources. This translates to a number of benefits, including:

  • fewer network requests,
  • fewer DNS requests,
  • less bandwidth usage, and
  • snappier visual feedback.

But AMP isn’t magic

AMP can’t automagically fix every potential performance issue. Here are some of the reasons an AMP site could still be slow:

  • Slow page creation on backend server will cause delayed time to first byte (TTFB) on page requests that aren’t cached on the AMP CDN
  • DNS or network delays
  • A page that does not pass validation will not be cached by AMP’s CDN and may not show in Google search results
  • Images that are not optimised for mobile
  • Loading AMP extensions that the page doesn’t require

A fast AMP site requires publishers to take a step back, think, and prioritize which content is important for mobile visitors. Hopefully this thought process can also be brought to traditional web pages to make the web faster for all devices.

Getting started

If you’re a current mPulse user: See the mPulse AMP documentation to get started right away

If you’re not an mPulse user: Start your free trial

Try mPulse real user measurement for free

Nigel Heron

About the Author

Nigel Heron

Nigel Heron is a software engineer with a passion for performance. He enjoys modifying anything that can be optimized, whether it’s applications, databases, servers, or even race cars. He works on the data collection team at SOASTA for the mPulse and boomerang products.

Follow @querymetrics