Velocity NY 2016 Session – AMP: Does it Really Make Your Site Faster?

The goal of the Accelerated Mobile Pages (AMP) project is to give publishers a way to distribute their content in a highly performant way on mobile devices, resulting in happier visitors. Publishers are beginning to invest in AMP support now that AMP pages are becoming prioritized in search results. With the lower markup complexity of AMP pages, you can also reduce your development and infrastructure costs.

As with all magical solutions, AMP has its downsides. To achieve some of its goals, AMP pages strictly limit what components can be on the page, and a major restriction is that the JavaScript is not allowed. This brings up a few serious concerns:

• Can we use our existing analytics tools for AMP? • How can we be sure that AMP pages are living up to their promised performance? • How can we bring real-user monitoring to AMP?

Nic Jansma and Nigel Heron outline the benefits, challenges, and alternatives to AMP, explain why your old performance measuring techniques won’t work, and explore how new AMP features attempt to bridge the monitoring gap. Nic and Nigel cover how the AMP project is being improved to help measure more real-user performance characteristics of AMP pages and how the boomerang team is working with the AMP project to get there.

Speakers: Nic Jansma, SOASTA | Nigel Heron, SOASTA




Nic Jansma: Today we are going to talk about AMP. Accelerated Mobile Pages and does it make your site faster? We do have some slides that you guys can follow along with if you want. I just tweeted out the link as well. You can go to my twitter to get the link and we’ll have links at the end as well.


Pat suggested we just say yes and that’s it. We can all get drinks right. Okay. Just kidding. I’m going to hand it over to Nigel until I get started.


Nigel Heron: Thank you. Well first of all, what is AMP. AMP stands for Accelerated Mobile Pages. It’s a perfect title. It’s exactly what they are trying to achieve. They want to build a better way to build websites to optimize performance.


There are 3 major components to AMP. The 1st is the AMP HTML. It’s similar to HTML 5 with some restrictions. There is also additional tags. There’s the AMP in Java Script which is the … What makes everything work and it’s what you include in the site. There’s the AMP Google cache, which is the CDN that’s free of charge and it’s used for all AMP content.


What can you include on an AMP site? Well you can pretty much make an AMP site look exactly like you would a regular mobile site. You include text, custom fonts, images, videos, advertising. Third party embeds like Youtube, Instagram, Tweets and there’s a lot more.


What you can’t include. These are some of the restrictions. You can not link your external CSS. You cannot use custom Java Script with AMP. Either inline in the page or referenced externally. There’s an exception which is an AMP iframes and we’ll get into that a little bit later. You cannot have flash or Java applets, but no one cares anymore. Forms are still experimental and coming soon.


What could performance mean for mobile devices? It could mean a lot of different things. We want faster load times. We want to use less bandwidth. Less memory usage. Less CPU. Less battery and overall we want a better user experience. These are all parts of the word performance.


AMP enforces a lot of best practices to achieve this performance. Java Script is all loaded asynchronously. The CSS is inline to avoid font downloads. The CSS has a size limit. It’s 50K I think. Element dimensions are mandatory. This means that every image you have in your page or every video element you have in your page has a thick size and this is primarily because of Dom layouts are extremely CPU intensive and take a lot of time. Also, it allows them to reserve space on the page where that if an image downloaded slow there’s less jank in the page. Because there’s a box that’s pre-ready for it to be filled out.


Resources have a priority in loading. Where things in the view-port are … That’s 1st. Things that are outside of the view-port are ready to be loaded. AMP is pre-render aware in that when it’s in pre-render mode the things in the top of the view port will be loaded and the things in the bottom won’t be. This saves resources on mobile devices.


Again with the cache on CBN. We cache, well AMP caches HTML, the Java Script, images and fonts. Java Script resources used by AMP are shared against all of AMP pages. This means that if any of your users have visited a different AMP page in the past few days and then are visiting your page. Chances are the Java Script is already in their browser cache. Which is a huge benefit.


AMP is also smart for business. Google is prioritizing AMP in search results in both native and web. I don’t think they’ve actually told anyone that are prioritizing it, but if you do a search on a mobile chances are you’ll have AMP results in the newest carousel.


There’s support for ads. There’s over 60 vendors like Google AdWords and things like that. There’s Google AMP cache which is a free of charge and it could really affect your IT budget.


For developers why is AMP important. Well AMP is actually very easy to learn. If you know HTML, learning AMP is just a matter of looking at the documentation for a few minutes. It’s no surprise that there are a lot of Word Press sites out there. Having an AMP version of a Word Press site is easy it’s simply a matter of installing a plug in.


There’s a built in validator in AMP and it’s easy to view and see the errors in your AMP pages. Simply add #developer=1 in your URL. Look at your favorite dev tools and look at the console logs for errors. There is also a really nice chrome extension that does the same thing. The documentation app is excellent and there is a lot of examples for you to draw examples from.


It’s an open source project. If you want to see how something works you just look at the code. If you have an issue with AMP, look in give hub, open a pull request. Maybe it’s been popular before and you can get help that way.


Coming back to CDN again. CDN uses HTPS. They use H2, QUIC and SPDY. The backend servers that the publisher owns doesn’t have to support those protocols. You just need HTPS and it will automatically take advantage of H2 or QUIC. There’s a throttled cache re-validation that means that your servers don’t have to be as strong as the AMP cache does. Cache will let you serve a stale page to the user and then re-validate it’s cache in the background.


The Google AMP cache also does image optimization. We’ve seen large images get scaled down through 1,024 in width from like something massive. Obviously, this saves a lot of bandwidth. They are also able to change the encoding and use web p for browsers that support it.


The fonts are cached also on the AMPs CDN. There are 4 white-listed font providers that you should choose from. The HTML script from the CDN is also re-written a little bit so that the fonts and the images are also served from the CDN. They do some HTML sanitation. It’s not exactly indemnification. They remove HTML comments and make sure that the Dom elements are properly closed. There is also AMP validation. If the page is not a valid AMP it will not be cached by the AMP CDN and probably will never end up in Google search results.


Nic Jansma: Okay, Nigel told us why AMP should be fast. We should validate that. Trust but verify. How do we measure these AMP pages in the wild? There’s a lot of ways to do this for traditional websites. You can do things like web server logs. That doesn’t work with AMP because often the CDN is going to be serving the content and Google is not going to give the server logs for that.


We would use something like navigation timing. To look at the page load times. The DNS times. That kind of stuff. With a regular website, but since we can’t use Java Script in AMP we can’t do that either. Nigel mentioned that you can have an iframe and have Java Script running inside the iframe, but they’re sand boxed. Your Java Script and the iframe can’t actually get the performance data of the main page.


We have to end up going back to something like Synthetic or RUM. We are actually going into synthetic 1st. Synthetic monitoring is using something like webpage tests. Where you’re in a controlled environment. Re-loading things side by side. Over time with 1 or a few number of devices not looking at real world data, but a controlled environment’s data.


Let’s take a look at some Synthetic AMP pages. In this case we are actually going to take a look at Buzzfeed. They have both a desktop website and AMP versions of a lot of their articles. Here you can actually see an article on some LEGGO Batman cool stuff. You get to see a lot of the same content in both AMP pages and regular pages. The regular page on the left has a lot more navigation, side bars. Below the fold there’s a lot of related content links and that kind of stuff. On the right you see AMP and it’s a lot more stream lined right. There’s actually a bigger image, but there’s less navigation before and after the content, but it has all the same text for example.


We can send both these pages to webpage tests. They’re different URLs, so we can use something like one of the emulated devices or a real mobile device. To actually do page loads of both these pages on a mobile device and webpage tests. You can even see on the left right here, which is the regular site, the waterfall is huge. We’ve downloaded a bunch of resources. It actually scrolls below the fold.


Compare that to the waterfall on the right which is really teenie, but that’s good because that means not a lot of resources are being fetched. You can see this actually play out in the data that you get. The top is the regular website. You see that it loads in about 29 seconds. Loading 5.9 MEGs worth of data. Compare that to the AMP version of the same page which loads in about a 10th of the time at 3 seconds and is loading less than a MEG worth of data.


In this one example we are seeing a webpage that the AMP version is significantly better user experience for the visitor. You can see that in the 1st byte time, start render time. All that kind of stuff. AMP pages don’t necessarily guarantee performance. I’d just like to point to a counter example of that.


Again, we’re using webpage tests. We’re actually using another version or another page on the same site. In fact we’re actually looking at, in this case, Buzzfeed has an actual mobile optimized website. We’re comparing the mobile optimized website to the AMP site specifically. They have about the same amount of resources in this case. The mobile optimized website on the left has a much smaller waterfall. Much less resources are being fetched. We’re comparing it to the AMP page of the same version. The AMP website loads in about 12 seconds. Less than a 1/2 a MEG worth of data, but for some reason the AMP page took 70 seconds to load 6 MEGs worth of data.


We looked into this a bit. It’s actually because of an animated GIF. It’s like surveillance footage. A long scene of surveillance footage. For the mobile optimized website Buzzfeed wasn’t actually fetching this data until you hovered over it and scrolled it into view. However, on the AMP page all of the images were fetched immediately to try to render. To try to show right away. It’s actually trying to download this 6 MEG animated Gif. Whether the user cares about it or not right away. You definitely needs the tests. AMP does not guarantee performance in any way. Test your real sites versus the other sites. Look into it. Do deep eyes into it.


Synthetic monitoring can be good to look at your AMP pages to make sure they are working well. It’s not the final say in everything. You are not getting real world data here. You’re not getting real devices. Well maybe you are getting real devices synthetic, but you are not getting the wide variety of devices that your customers would actually be loading data on. It’s not real use monitoring.


How do we do real use monitoring? Exactly, how do we do it? If we are not allowed Java Script in AMP how do we do it? Well, we are lucky it’s built into AMP. There are 3 ways to do this. The first is using an AMP pixel tag. This is a tracking pixel. You set up the tag with a source that points to a beacon server and it uses a template system to use variable replacement to embed metrics into your query stream. There’s no extra extension download required for this. AMP pixel is built into the base of AMP. It’s triggered during the page layout, but with a very low priority. It’s not tied into the on-load event, so perf data that you are looking for might not be available at the time.


Here’s just a little example of where we are sending a beacon to You can see that the variable replacement look a bit similar to a bash environment variable. Here we’re sending back the URL in the AMP page and it’s title, back to our beacon server. A bit more about this variable substitution. There is a lot of information you can gather from AMP and it’s all built in. There’s information about the document, like the URL, the referrer etc. Navigation priming API is fully supported. You can get info about DNS, TCP connection times.


The navigation type is also supported. That is either a normal navigation or if the page was issued during a re-load or someone uses a back button to navigate to it. The number of redirects that happen to it before landing on the page. We can also get a persistent client ID and we’ll get into this next. There’s a total engage time. This is like a … Kind of an estimate of how much the user is interacting with your page. If there’s touching things. If they are moving around this is considered engagement time. You can also get the screen and the viewpoint dimensions. There’s a lot more and the documentation link is at the bottom.


About this client ID. In AMP, we are not aloud to set cookies. We’re not allowed to set the plate and local storage. The reason for this is because most of the content is served from the same CDN bot for all publishers. If we were allowed to set cookies on it, we could leak it. Private information from one publisher to the next.


This cookie is maintained by the AMP library. It’s just a randomized number. It lives for about a year. The 2nd way to get data through AMP is through AMP analytics tag. They have 27, I think, built in developer configurations. Impulse is one of them. There is also Google analytics, Com scorer, Parsley and a lot more. AMP analytics with built in vendors is extremely easy to use. It’s simply add the AMP analytics tag, the name of the vendor and probably an API key and that’s it. The pre-defined list of metrics that this vendor has defined is sent back to their servers for processing.


It’s available as an extension. What does an extension mean? An extension is just simply an extra data script that you include in the page that points to a part of the Java Script library in AMP.


If you don’t want to use a built in vendor you can certainly do it yourself. You can use AMP analytics with a customized configuration. It’s a bit harder to do yourself, but it’s certainly doable. You can send the data back to your own servers. It uses the same variable substitution that we saw with AMP pixel. The big difference with AMP pixel is you can use get or a post request and you can configure when the beacons are being sent. These are called trigger events.


There’s a lot of trigger events. The most notable is on page visible. You can also do it on page hidden or you can do it on an app element. When it comes visible either as a percentage of how much of the element is in the view-port or how much time the element has spent in the view-port. This is really used for advertising tracking. You can even tell how much a user has seen part of or a least part of the add and track it that way.


You can have click events. Where if you have a Facebook like button or a share button, you can beacon when the user presses on one of these buttons. There is scroll event primers so you can beacon and track the scroll depth of the page. There is also a primer like an interval beacon. You can set it up say it beacon every second and capture this engagement prime over time.


What we are really interested with RUM performance data is the navigation priming API information. We made a contribution to have this nav priming variable substitution where that you can capture any metric you want from this massive set of metrics. If you specify 1 metric you’ll get a UNIX time stamp. If you specify 2 of them you’ll get the delta between them.


Here’s a very short example of a config that you can use to send data back to your own server. You can see in the request section of the JSON. You set up the URL that the beacon is going to be sent to. With some variable substitutions. We’re sending back the URL as long with the load time. The trigger defines when it is going to be sent. What’s important here is the on variable and it’s going to be sent on visible.


We’d like to do a live demo with you today. If you can all try to hit this link with either your laptop or your phone. We’ll see if the wifi holds up. What we’re doing is we took the site called cloned it. We added our own analytics tag just to show how it works and we’re sending all of the RUM data back to ourselves. We’re using a little node js server to receive the beacon with a lot of the RUM priming in it. That node server is then forwarding the data to influx db where it’s going to capture the prime series information. Then we’re using Grafana to view this data. Here’s an example of what you should be seeing if you went to the link. We’ll show the link again in a sec, but this is … I want to show [inaudible 00:19:38].


Here’s an example of the beacon we just sent out by hitting the page. You see we’ve captured all of the RUM priming we wanted. All your UNIX time stamps and the URL should be in there as well. There we go. All that is using variable substitutions.


Thank you for hitting the page. We can see data coming in. This is being refreshed every 5 seconds so if you’re surfing around the site we’ll see it show up pretty much immediately. We’re capturing all the RUM priming in the top here showing the 95th percentile. What’s that 15 seconds or something? It’s running on the [inaudible 00:20:27] that’s probably why. It’s pretty slow. Let me see. You can see hits per second. Upfront end versus back end prime. All this is probably 1/2 hour of work. We’re going to be sharing the code in [inaudible 00:20:42] to do this.


We’ll just have to work from back up. Okay, we looked at how you can send your own data to yourself. How you can actually capture this data or you can send it to a vendor like Impulse or Google analytics or something like this. Let’s actually look at real world data that we are seeing. System now supports AMP data being sent to it. We’re capturing it with some of our customers. We’re getting everything from where they are in the world. All the navigation timing data you might expect. Page groups, all the kind of stuff you might expect from RUM data.


We’re actually going to take a look at 1 of our customers that has an AMP enabled website. This is a news website with a blog or articles. It’s about 30 days worth of data. What we’re really doing is we’re comparing thousands of articles that have a regular page and a AMP version of the same page and just those 2 data sets. We’re not looking at the home page or anything else like that. We’re only comparing a page that has an AMP version and a non-AMP version. This is a breakdown of what those pages would like to. Very similar to what the Buzzfeed pages. The regular site. It used 350 requests. 3 MEGs worth of data. It takes about 35 seconds to load on mobile device. The AMP page. AMP optimized site on the other hand, 19 requests. 350K worth of data and only 3.6 seconds to load.


Why is the regular site so much bigger? Well it has interactive navigations. The nav on top is very interactive. A lot of Java Script paneling up. It has very high resolution images. Full screen desktop resolution images. It has a lot of other content links. After you view the article it’s suggesting other things that you may want to look at as well with images for those. Frankly, 3rd party content most of it’s Waterfall. I’d say over 1/2 of it up here is 3rd party content.


You compare that to the AMP version of the exact same page. Same text. You still see the header for the site. You still see a simple navigation, but it’s not as interactive as a regular site. You see article text and you see the images that you have on the desktop version, but they are scaled down to the appropriate size and are a lot smaller. The biggest thing is that there is no 3rd parties in this 1 one site we we’re looking at.


If you are looking at a content breakdown by bytes for the regular website. Images really dominate how many bytes are being fetched to show the page over 60% essentially of the sites images. 25% is Java Script. Interestingly, on the AMP page that skews quite a bit. Because we’re looking at a much smaller image. The actual bytes being sent for that image is only about 30% and you actually see Java Script being the biggest content size on the app page. That’s not 3rd party Java Script. That’s not even embedded Java Script. That’s actually just the AMP project itself. We’re only downloading 250k worth of data, so the AMP Java Script itself is actually taking a big chunk of that.


Let’s look at the real data that we are collecting. To set some basis for what type of visitors are visiting these 2 different sites. The regular site gets a lot of chrome and IE traffic. Mobile Safari, Firefox. All of the browsers that you would expect. The AMP site is mostly Chrome. Mostly Chrome. A little mobile Safari. We actually don’t see any IE traffic. We don’t know if IE is just, IE mobile specifically, is just not being directed to AMP content or if it’s so minuscule it just doesn’t show up in our charts. You see that to with what type of OS, what type of devices are loading the AMP pages versus the regular page.


The regular page is about 50% windows. 0% on the AMP site. Android OS basically dominates who’s looking at the AMP content. Let’s get to the interesting stuff. Page load times. How long does it take to load each? We see the AMP sites about 3.8 times faster than the regular site. From 4.8 seconds for the regular site down to less than a second median times. AMPs a lot faster, so much less content. You can download so much faster. It’s pretty much expected. That’s for all visitors to the site. Both desktop and mobile visitors to the regular site and all to the other site although that’s in practice only mobile visitors.


If we look at just mobile visitors to the regular site. Basically what AMP is targeting. The core audience that you want AMP to improve on. We actually see that it’s even larger improvement. Mobile visitors to the regular website are taking over 6.2 seconds and the AMP pages are about 5.7 times faster to load. Much better user experience. If we break this down into DMS times. TCP times and stuff like that. We find a couple of interesting things. We’re looking at median times here. Often, we actually see a 0 essentially median DMS look up time. We think most browsers and AMPs that are looking at this content are already speculatively doing their DNS fetches before the user is going to them. We have actually don’t see much time being spent looking up the domains.


Interesting thing here, the regular website is still seeing some TCP connect times, SSL times. Looks like about 65 milliseconds total. While the median time for AMP content is 0. We believe this is because the AMP content is actually being pre-fetched, pre-rendered. We’re actually connecting to the server before the user is looking at it. Often like a carousel of the news results that are within you AMP. Chrome is pre-fetching or pre-rendering this content so by the time the user navigates to it there is no connection that needs to be done. No SSL handshake.


One of the biggest benefits to AMP is the presentation layer right. Which is the pages are actually getting pre-rendered a lot of the time. The overall response time goes down from about 404 milliseconds to about 316 milliseconds. A lot of that is just from the pre-rendering benefit that you get.


Now, if we take out the pre-rendering. If we’re only looking at actual times where the user connected. They had to connect via TCP. They had to do DNS look ups. That kind of stuff. We actually see a different story. AMP in this case this 1 customer, just to be clear, is taking a lot longer time to do all these. A lot longer DNS, a lot longer TCP, SSL handshakes and everything.


Looking at it, it’s actually because of the actual website in this case. The websites a very geo targeted website. It’s not US centric. They actually have data centers very close to the customers. If you were to ping both the regular website and the AMP CDNs the ping to the regular website is probably … From where the customers will be loading the page, is probably under 10 milliseconds. Where the AMP CDN today is over like 40 milliseconds or so away.


For this 1 website day and time, we actually found cases where the CDN if you had to connect to it would actually be slower than the customers data center. That’s okay, because we still find that overall the page load time is better. In fact we looked at … With AMP content you can either load the page from the AMP CDN or you can load it from the origin. Where you actually put your content.


We found in over 99 cases the AMP content was being served from the CDN. Google basically almost always sends you there. In fact, we think the other 1% of the time is us loading it or other developers loading it or bots crawling the traffic on the non CDN. We don’t think that much if any traffic should be loaded from you own origin at all.


Now. Excuse me. Comparing those cases, this is looking at AMP traffic itself. If just the AMP traffic is being loaded from your origin versus the CDN. You actually see the CDN overall, provide the better load time. Even with those cases where the data center is actually closer than the AMP CDN. We think a lot of the times this is the case because on your origin, your probably more likely to be serving up dynamic content. That your servers actually have to process and put out there. Whereas the AMP CDN by itself is a static cache. It doesn’t need to do any calculations. It can just immediately send the content back to the user.


We see between these 2, between the AMP CDN and your origin, for this customer is was about 13% faster to be serving it up from the CDN. Which is also loading up your bandwidth for you for free. How does this correlate to business metrics? Session length. How many pages is the user looking at on your site? Well, for this customer the average session length was about 2.9 pages. For the regular website AMP was only 1.4 about 48% less pages. This could be kind of disappointing looking at these numbers.


We think this is for a couple of different reasons. One of them is a lot of times the AMP content is being displayed. It’s being displayed in something like a carousel. Highlighted new articles. That kind of thing. The visitors going through it and maybe they are just looking at your article reading it really quickly. Going to the next article. Maybe it’s a different site or something like that. They’re not necessarily, in this case, focused and engaged on diving into the rest of the sites content.


There is also another difference with how this site compared or built their AMP page versus their regular page. Where their AMP page didn’t put as many related article links in the bottom. As many links to other content within their own site. It’s always good when you are looking at your RUM data to see the differences in this. Maybe you would want to at this point go and look at your AMP pages and see why they are not engaging as much.


In fact if you look at the actual bounce rate. How often visitors will only go to one page and then leave? The regular page only had a bounce rate of about 58% AMP was much higher than that. Most people looking at these AMP articles are only looking at 1 article.


We also found that only 3% of visitors transitioned from looking at an AMP page to the regular page. Visitors that are viewing AMP content are rarely actually going to the real site. This is the IP address over 30 days.


One interesting thing that we found when looking at the referred data, how people are coming to look at this AMP content? For this site we found that the Google Play news stand app. You can get that on your android or IOS phones. Was sending about 62% of traffic was coming from there.


The News Stand app will send visitors to your AMP pages if you opt into it I think, but it seems to be sending a lot of traffic to this one site. Obviously, the other big referrers there are Google as well. and www and we just had a bunch of unknown referrers that tripped all the time. This is a screen shot of the play News Stand app. In this app it doesn’t actually say whether it’s AMP or not, whereas some of the other Google apps would actually give the little AMP icon.


We have a couple of conclusions. Again, we are just looking at 1 website’s data We want to get more. We want to continue looking through this data. We are in the early stages of looking at it. We think in this case AMP is a forcing function for doing best practices. It’s also a good way to get rid of your 3rd party content. Maybe your marketing team isn’t going to be to excited about that. A lot of the pages that we are looking at there is just so much less 3rd party downloading, another 3rd party downloading, another 3rd party crap. It could be good for you.


We also think you could get the same experience of AMP just by hand tuning it to. AMP is best practices that you can apply on your own. You can do all these same things or even better. I think Buzzfeed is actually doing a mobile tuned version of their website and trying to put a lot of their energy into that. I believe they are going to be even better than the AMP pages.


You can use the Google CDN or the AMP CDN to give you a free performance boost. Download some of your favorite content. AMP does have some SSL benefits but as we saw with the data you’ve got to be really careful about it to because some of your users may not be as engaged going to your AMP pages versus your regular website.


Are there downsides to AMP? Yeah, you’ve got to understand it. You’ve got to dedicate technical resources to it. You’ve got to maintain it. It’s a whole separate view. It’s easy to have validation errors and your AMP content suddenly isn’t working. You have to have people that understand it.


We think hand tuning in many cases can be just as good. Tim has a similar proposal for the content performance policy that he’s working on with some other people. It’s kind of a similar way of thinking about AMP stuff, but with a slightly different focus. If your interested in that please take a look at the article. There’s other competing ways of doing this such as Facebook instant articles. You can’t actually get the analytics out of that that we can out of AMP pages. That’s why AMP pages are great for this. You want to talk about some of the stuff we’re working on in the future.


Nigel Heron: Sure. These are some of the RUM features that we’d like to see implemented. The first 1 is resource priming. We started actually at 4 requests about this and we’re getting great feedback. We just need to continue working on it to finish it up. It should be great to have. We’ll be able to look at the … How big the resource sizes are? Compare images on AMP versus your mobile and see if the AMPs you gain is actually reducing the sizes of some of your images. Maybe this is stuff that you should be doing on your regular site as well.


User priming, I think [inaudible 00:35:07] added that this week. Some of the AMP internals are tracked now with user priming. We’d like to get some of this data in RUM. We’d also like to … Instead of having beacons being triggered, we’d like to trigger user time in marks and then be able to beacon them as groups. We’d also like to know how long a page was in pre-render mode and get some information about that. Because navigation priming tells how long the page took to get constructed. It doesn’t actually give you an indication of when the page was presented to the user. We’d like to have a pre-render time. Yeah, so that’s what we got today. Thank you.


Nic Jansma: We do have a couple of minutes for questions if you guys would want to go get drinks that’s fine as well. We can always take questions down here by the stage as well.


Speaker 3: Have you seen anybody just boldly switch over to AMP, [inaudible 00:36:17].


Nic Jansma: The question was have we seen anybody just have basically only an AMP page? I haven’t seen that personally. I’d be a little hesitant to do that with just some of the business metrics that we saw, but you could certainly try to do it and let us know. Simon.


Simon: [inaudible 00:36:34]


Nic Jansma: The question is is there any ability with AMP analytics today to be able to know whether or not the page has been pre-rendered at all? I don’t believe there is yet.


Nigel Heron: We don’t think there is. That’s why it’s something we want to implement or propose to be implemented.


Nic Jansma: Because that would certainly modify the performance characteristics of what you’re doing and whether it’s just swapped in or actually having to be rendered for the user.


Speaker 5: Do you records on the engagement rates for [inaudible 00:37:09]. As well as AMP versus non AMP [inaudible 00:37:14].


Nic Jansma: The question is do we have any records on engagement rate? Are you saying from the search result page with an AMP article would more likely to be clicked on? We don’t have that data. I don’t think from RUM. I’d be interested to figure out how we could do that. Maybe if Google would let us see their data that would be nice.


Speaker 6: [inaudible 00:37:44]


Nic Jansma: I’m sorry I couldn’t hear the first part of that how?


Speaker 6: [inaudible 00:37:55]


Nic Jansma: Oh. HTPS. How do they compare HTPS versus non HTPS. The question was, if I could go back over it, how do AMP HTPS pages on the AMP CDN or not?


Nigel Heron: The AMP CDN only serves on AMP HTPS whereas the origin servers have the choice for it. Since it’s your servers you can do what you want. The AMPs again only serve over HTPS, but they have …


Speaker 6: [inaudible 00:38:22]


Nigel Heron: Yeah. They have H2 though and QUID, SPDY. These are performance benefits.


Speaker 6: [inaudible 00:38:30]


Nic Jansma: An example AMP site that’s running today. A lot of publishers.


Nigel Heron: Almost all of the publishers in the US.


Nic Jansma: We’re looking at Buzzfeed for example and that article.


Nigel Heron: New York times, Washington Post, [inaudible 00:38:52].


Nic Jansma: You can also see if the site has an AMP version looking at the broad HTML. There’s is a rel AMP tag basically and you can see if they have an AMP version of the app that you are looking at. Sorry, one guy over here.


Speaker 7: Yes. Real quick. [inaudible 00:39:15]


Nic Jansma: It’s not something we looked at because … I’m sorry …


Nigel Heron: Are we seeing the same type of engagement with Facebook or instant articles? The answer is we haven’t really looked into it because currently, the Facebook instant articles doesn’t allow for any RUM data to be collected. The analytics portion where you are allowed to inject code is a sandbox iframe. It’s out of our scope unfortunately.


Nic Jansma: We’ll take any more questions that you guys have afterward. Otherwise go enjoy the party. Thank you.