 Hello, everyone. Why? Oops. Am I on? Okay. You can hear me. And let's see. Is my presentation going? Yes, it is. Okay. Hello. So, yes. I am on Google's product partnerships team. At Google, a lot of what I'm doing lately is focusing on trying to work to improve web performance through partnership engagements with large CMS platforms, primarily Word Press. So, I really have spent the better part of this year immersed in the Word Press world community ecosystem, going to Word Press events, trying to understand more about how Word Press works and talking about performance. One of the products I'll talk about today is AMP, but this really isn't a talk about AMP. This is a talk about performance on the open web. And I think it fits well within the theme of this event, taking back the open web, because that theme, I would suggest, is not just about how we respond to external threats or walled gardens or, say, world of native apps versus web. It's really about a challenge that we're confronting internally as individual website owners, as an industry, as a platform about how to make our websites and the web overall a more welcoming and frictionless place to be for content creators and consumers. So, I hope that as we go forward, think about this talk certainly from your own individual perspectives as website developers, owners, agencies, but also from the perspective of a participant in and custodian of a healthy open web. So, here's the meandering path of my talk today. Again, I'll spend probably about two-thirds of it talking about web performance overall, state of web performance, some useful tools for measuring web performance, and then we'll talk about AMP as one example of a well-lit path to performance and spend a little bit of time on the state of AMP in WordPress. So, let's start out with a statement of the obvious. Speed is important. Certainly, it is not the only factor in the success of a commercial site or a publishing site, nor is it a magic bullet for all of the challenges facing the industry and publishers trying to make a business on the web. There is a growing body of data which affirms the connection between speed, loyalty, and business results. So, no matter how good your content is, no matter how good your product is, when you slow down your site, you lose engagement, add dollars, and potential subscribers. In fact, the Financial Times proved just that in A-B testing. They correlated a 5% variance in engagement across all customer segments for every second of site speed. So, for every second that their site was faster or slower, they were able to track a 5% change in user engagement. And they were then able to correlate that change in user engagement to millions of dollars in advertiser and subscriber revenue. And the thing I like about that stat as well as the Pinterest stat, correlating 15% change in sign-up conversions based on landing page is that both of those case studies involved only a change in the speed of the site. So, this is no change to site design or other changes to user experience. This is simply the effect that speed can have on a site. So, I think it's really, first of all, really great that we have large brands and sites like this doing these kinds of experiments and then sharing the results publicly. And I would also point out that in these examples, we are talking about premium brands that already have highly unique content and high user loyalty. And even they are finding that speed and performance significantly impacts their business success. So, probably if you've been to other talks about performance, you have seen stats like that. And we're all kind of going, okay, we've heard about this. We've been talking about this for years. It was really, it's great to see that speed and performance has been a recurring theme of this conference so far. It seems very intuitive. We probably don't need the case studies to tell us this. We get it, right? At scale, not really. Because the weight of the web in terms of both desktop sites and mobile sites has been doing nothing but growing up and up year after year. To the point now where the median mobile website is heavier than the median mobile desktop experience. And I will say for developed regions of the world, fortunately, network speeds have also grown. So if you're a US-based publisher, your audience is probably looking at your site on 4G. And so your website is usable. When we give a talk like this or talk to publishers and agencies in developing regions of the world, the reality is the web has become almost unusable in a lot of places. And this just for anyone I think doesn't look sustainable. Nor is the rate of growth abating. Just this year, we have seen median mobile page weight grow 6%. And I'd like you to look at that number, that 1.5 megabytes for a typical mobile page. This is the web overall. The next slide I'm going to show you is WordPress. Yeah. Over 2 megabytes is the average weight of a WordPress site according to HDP archive. Now there are probably folks in the room who could explain more authoritatively than I could exactly why this is. And I don't want to rabbit hole on this yet. I also do want to acknowledge that with WordPress representing what 30% of the web, there is a huge range of sites in the WordPress platform. And there are many, many sites that are extremely fast and extremely performant that are built on WordPress. So this is not meant, and there's also a very, very long tail obviously on the WordPress platform. So that median number is not meant to say that it's hard to build a fast site on WordPress, but it might suggest that it's not too hard to build a slow one. So with those caveats in mind, let's look a little bit deeper into user experience. So this is more WordPress data. A colleague of mine, Rick Viskomi, who's on the developer relations team, did this analysis in the early part of the year looking at Chrome user experience report and a sample of about 800,000 WordPress sites. I will talk more about this methodology in a moment. We're going to look at three KPIs. The first is First Content Full Paint. That means the first point at which consumable content is available on the site. So that may be an image, it may be text, something that a user can read or look at. So again, I'll dig deep into this methodology, but I think the key takeaway here would be that typically users are having a fast experience with WordPress sites about half as often as they're having a fast experience on other sites. Next metric, similar results. This is DOM content loaded, so this means that the HTML document is loaded. There may be style sheets still coming in, images still coming in, but the HTML document is there. Again, WordPress at large slower than everything else. And then the last one is Onload. So this is your page is finished loading. And there, the margin or the delta is even wider, but I would argue that this really doesn't look good for anybody. When you've got something like 68% of users experiencing WordPress sites and 44% of users experiencing other sites having a slow experience in terms of waiting for the full site to load, this is basically a visual representation of the janky web. So I do want to dig a little bit deeper into the data that I was just showing you, how you can pull that data yourself for your own site or for other sites. So there are a couple of tools I want to talk about. And again, I think the key point here is that you can run these tools on any site, including your own, but also other sites that you think are best practice examples or maybe in your competitive cohort. So the first tool is Lighthouse. I'm just going to spend a minute on Lighthouse. Generally, when we talk about Lighthouse, some of you are probably very familiar with it. It's very common for folks to say, yeah, I've heard about it, but I'm not sure what it is or where to go get it. And so I created this animation. Pick Taco is where we had our speaker sponsor dinner the other night, so I didn't want to use news site. I just thought I'd pick this one in. So you can see in the animation, Lighthouse is available in Chrome browser in Chrome Developer Tools under a navigation menu called Audits. It's a little bit hidden, so you kind of need to know what you're looking for in order to find it. But once you've found it, you can run an audit on any URL against these five dimensions, which are performance, progressive web app features, accessibility, best practices, and SEO. It will run an audit on the site based on those five dimensions, provide a score for each one, and then make recommendations in cases where there was a suboptimal result. So in this case, Pink Taco is doing really well in terms of overall performance and SEO. We'd have to dig a little deeper to see what some of the best practices are that they're missing. Next one I want to talk about and spend a little time on is the Chrome User Experience Report. So this one, I think, has added a dimension to the way we look at performance that I think has been badly needed, which is an understanding of how real users are experiencing the web. And so you can use a tool like Lighthouse or like Webpage Test, which will run essentially a lab diagnostic and sort of simulate performance and also analyze the components of a site. What the Chrome User Experience Report does is it uses actual real human user data for folks who are using the Chrome Web Browser to understand what the actual experience is of users looking at the top, it's now four million origins on the web. The Chrome User Experience Report or CRUX is accessible in two ways. The first is Google BigQuery, which is this massive, scary data warehouse that I honestly don't know how to use, and PageSpeed Insights, which is a very simple, user-friendly data visualization. So we're going to spend a little time on PageSpeed Insights. So if you just Google four PageSpeed Insights, you will hopefully end up in a form that looks like this. It's very simple. You enter any site URL and provided that it is in the CRUX dataset, it will give you a result. This is the familiar green, yellow, red graph that we were looking at a moment ago showing how this site performs both on mobile and desktop. And if you were to scroll a little further down in the report, it would give you some optimization recommendations. So to talk a little bit about how you read this PageSpeed Insights graph, what this is looking at is essentially it's an average benchmark. So in this example, if you look at the top bar, which is first contentful paint, it means that 52% of experiences with this site, with this domain, saw first contentful paint that's in the range of fast as defined by the fastest third of sites in the CRUX dataset. So we take that four million sites, divide it into thirds. What's the average speed of the top third, middle third, lower third, and then it will benchmark any other site against that. So those are the tools themselves, but I'd like to talk a little bit about how you can use that data in order to understand, really gain insights about how your site performs and ideally help tell that story or connect the dots within your organization that help make that case for performance. So first thing I want to show you is a, this is actually a tool that was made publicly available yesterday. So it is brand new. This combines the CRUX report with Google Data Studio so that you can run essentially what we used it for in this case is to run a monthly report of performance for a particular domain. And I had, I actually had used a generic, I had sort of random site for this one, but yesterday while Tyson was speaking, and he was talking about work that they've been doing on the Gatehouse properties and he mentioned his Ames Iowa property. I ran this report on ames-trib.com. And so this is what you're looking at. This is the real performance from November to July for ames-trib.com. And as you can see, it's telling a, it's telling a pretty good story. So I shared this with Tyson. He talked with his team. They confirmed that around the time where you saw performance starting to improve, they had made several optimizations on their web properties. So this is a validation in this case that the change that they were making had a real impact on people consuming their site. So this is something that you could do either sort of forensically to look back in time and understand how your, how your user experience has changed or if you are deliberately embarking on a cleanup effort or adding some really heavy stuff to your page. You may be able to see the impact of that reflected here. And overall, these are really good-looking scores, especially as you see them progressively getting better. With the crux report and Data Studio, you will also, you can also run reports like these which look at sort of user variables. So if you're wondering whether something like device distribution or connection speed is having an impact on that crux data, this also is using the same property. So you can see how device distribution changes from mobile to desktop, as well as connection distribution. And having done this on a bunch of US-based sites, that connection distribution is pretty consistent. It's like 95% 4G most of the time. Again, if we were in another part of the world or perhaps another community, we might see a different distribution, which would result in very different-looking speeds. So here's another exercise. This isn't an automated dashboard. This is something I just did using the crux report because I was curious what it might look like to take essentially a competitive cohort. So I looked at seven local news publishers in Chicago. These are two newspapers and five local TV station websites. I ran the crux report on all seven and then created this graph myself. And so the good news is there are a couple of very high-performing sites at the top of that graph. There are also a couple, one in particular, relatively poor performing sites. And I think part of the story is that unless you have extraordinarily unique and sticky content, you can imagine how the impact of this kind of user experience affects loyalty and ultimately your business and site engagement over weeks, months, years. So I think we're the owner of that site in the bottom. This is something I would definitely want to take a look at internally. So having looked at some of the data, and again, I think that the data itself is probably not a surprise. Nor are the root causes or say the technical causes of the slow janky web. You guys all know what is going on here, right? It's images. It's code bloat, legacy code, blocking scripts. It maybe ads. It may be the new thing that your marketing manager wants to put on the page. It may be the new thing that your business manager wants to put on the page. We know what the culprits are from a technical standpoint. And that hasn't changed or translated into change for most of the web. So perhaps we need to up-level the conversation a little bit and talk about some of the other causes and issues at play, particularly what are some of the levers available to us to propel change. This is certainly, again, greatly simplifying a complicated problem involving like 15 or 20 years of accretion on the web. But I'd like to sort of start this conversation about how we can look at prioritizing performance organizationally and start to make some headway in this respect. And so this wasn't intended to be alliteration, but I kind of like how it ended up as alliteration. I bucket this challenge really into these three categories, courage, capacity, and compatibility. I'll talk about capacity and compatibility in a couple of minutes. That's really about the reality that we're living in an ecosystem. And so the whole ecosystem needs to change in order to rise the tide for everybody. But to spend a couple of minutes on courage, I chose the word courage because it often can feel like a risk or a bold move to make the right long-term choice for your business and for your users. It may not always be the popular move, and it may involve a short-term impact. One reason that I chose the quote that's on this slide is not only that I identify speed as table stakes with regard to loyalty, but in this essay, this SVP at NBC News Digital also talked about how they had turned off autoplay video, knowing, expecting, that it would have an immediate negative impact on the scale of their reach, but hoping that over time that impact would be overcome with loyalty, and that's what they found. Nine months later, they were back up to the same level, in fact beyond the level of video consumption on their site than they had been when they made the choice to turn off autoplay video. And so what that has in common with this concept of speed and performance is that you're no longer kicking people out of your consumer funnel before they have a chance to come in it. And, you know, we really hope that everyone is thinking about your website and your strategy as a funnel. Whether you are an advertising-based business or a subscriber or a membership-based publisher, at the end of the day, you are trying to convert users to encounter your property, your brand, into something. Whether that's something as a paying subscriber, a member, or just a user who wants to stay on your site and come back to it. The other kind of theme in here that I like a lot is this notion of treating performance as a product. And when you start to put that frame around performance as something that you should be tracking, planning and strategizing for and measuring, you start to assign value to, you start to think differently about it as an organization. And that actually reminds me of the Financial Times example that I was talking about earlier. In a talk a couple of months ago, the Chief Product Officer for the FT said that speed was the FT's second most valuable feature in terms of monetary value to their business, second only to their robust personalization and membership service. And so by sort of elevating or framing speed as a feature and a product and assigning value to it, she's sort of recognizing the important role it plays, more important than many other site features in terms of user loyalty and success of their business. So the other thing you'll see on this slide is this revenue impact calculator was something that was created by Google's ad products team. It was designed primarily with e-commerce sites in mind, so kind of some of the inputs you'll see are e-commerce oriented. But it's had really long legs because it is such a simple and clear illustration of the value that speed and performance can have on a site. So this pulls speed data from the crux report and then you can input your average order value and conversion rate and there's a little slider bar that lets you estimate the potential value that is either left on the table or that you could capture as your site is faster or slower. Again, it's very simple and obviously there are a lot more factors that go into success than just speed alone. But it sort of represents this approach and manner of thinking around speed that helps get business stakeholders interested and engaged in it in a more profound way than speaking about speed and performance as an abstract or a relative concept, which we often do. And then last in this category is this notion that there are ecosystem and marketplace forces which are starting to align toward a quality user experience and I think many of you who've been in this space for a long time know that this hasn't always been the case. There certainly has been a long time where revenue is really driven by tonnage of impressions or the level of obnoxiousness in your ads and that is starting to change. I think we've seen this coalition for a better ads graphic a couple of times so far in the last couple of days and I think the thing I want to note about it though is that the coalition for better ads is made up of advertisers, publishers, and buyers who admittedly are at sort of the top premium end of the space but this is their recognition that if they don't take action soon to improve the experience of the open web then the opportunity declines for them and everyone else. So again, I understand that there is still some pretty objectionable behaviors happening in certain corners of the web but there does seem to be this alignment of quality user experience with business opportunity which is encouraging and then of course Google as another ecosystem player is recognizing that users have a better experience when sites are fast and that users are moving to mobile and so that's reflected in the way Google is looking at search. And then last of all, you in the room, all of us are an ecosystem force and I mean that individually as website owners, as owners of groups of websites, as agencies, as an industry and as members of this platform that makes up 30% of the web. You all make choices internally, you also make choices about the vendors and integrators that you use and for me, having been in the local new space for a long time, I don't think it's very often that a say a product is rejected because it has too much code or I should say I wish that would happen more often. One of the things that we found with the AMP project which we'll talk about in a moment is that some like 200 of the top ad tech and analytics companies were able to build highly performant versions of their products when it was a requirement to participate and you have to wonder what the web would look like today if all of us had made speed and performance a requirement in our decisions to buy or work with other integrators in the space. Which brings me to the last section of this talk which is about addressing this challenge of modernizing the web at scale and this wide lens I think is important because while any of you might have full faith are capable of writing beautifully optimized code the reality is that this is an ecosystem that we're all working in and what ultimately matters for the health of the web overall is not only that a handful of us are able to build super fast sites but that the web becomes a performant smooth super fast experience so that consumers, advertisers and the new creators who are coming online and deciding where their presence should be decide to choose the web. So this is something that I think we're hopefully see that we're all in together. And that concept brings us to the concept of well-lit paths meaning that it should be first of all easier for an average developer to build and maintain over time a first class web experience but let alone the non-technical website owner we do a lot of thinking and honestly a lot of the focus on Google is about how we make the web a better experience for the torso and tail and make performant web experiences accessible to everyone. So well-lit paths can come in many forms they can be a template, a platform a set of instructions and best practice recommendations a code framework Gutenberg could be a well-lit path. The... Oops, wrong way. So the example of a well-lit path I want to spend a few minutes talking about now is the AMP project and I wanted to set it up with this context because that really was the thinking behind AMP it was a response to the fact that despite everything we know and viscerally experience the open web has been getting more encumbered every year with no end in sight and that's just not healthy for any of us it's one of those things where it's very easy to say that we could change but the reality is we haven't changed and the AMP project itself was initiated and launched in concert with a group of news publishers working with Google recognizing that it's time for the open web to take a step forward and devise the standard that would produce a consumer experience which ideally would not only be fast but also as engaging and as monetizable as the best walled garden experience. So the AMP project launched about three years ago and the first AMP pages appeared on the open web about two and a half years ago so given that short time frame the progress has been amazing but there also is a lot of confusion there is confusion around why AMP exists around what AMP can or can't do around how a publisher should think about incorporating it into their overall strategy and in retrospect I think I'm not the first Googler to say part of that is probably self-inflicted certainly from a roll out and messaging standpoint there's a very complex thing to communicate it's also a function I think of how rapidly AMP has evolved so unless you're paying really close attention you may not be aware of where it stands and what it can do. So the really quick elevator speech for AMP open source framework for web pages that are not only fast but also embeddable which opens up new distribution and monetization opportunities for publishers offering a smooth and fast page load it's now used by 56 million domains globally and because AMP is accessible and surfaceable on the open web anybody can link to it and more and more large platforms are so it's not just Google we see more in the US but also globally search and social platforms choosing to link to AMP pages when they're available because they see in their metrics that it leads to more user engagement. So in terms of what AMP looks like today if your first experience with AMP or your current vision of AMP is that of a stripped down version of a standard page that's something we very much would hope to correct AMP is now being used to build rich content and commerce experiences not only for news publishers but across verticals and with regard to news publishers specifically I want to call out I think I mentioned earlier the number of hundreds of third party integrators that are supporting AMP this again I think is key because in order for AMP to be a viable path for publishers it needs to support your business and analytics needs and so that is a crucial component of AMP success would also note you know as I said a moment ago it's certainly a fast developing roadmap so you know if last time you paid attention was six months ago there's probably a lot there today that you didn't see before and six months from now there'll be a lot more there as well so rapidly developing format and then just one quick note on the top stories carousel I haven't really talked about that yet because that's really not the point it is an example of what a highly performant web experience can look like but it is not intended to be the reason that publishers make AMP this is more in line with what we're hoping that AMP will become so more and more publishers are now creating fully responsive canonical or native AMP experiences so you know they're making the decision to build either their whole site as AMP or just leaf pages or posts as AMP there are many patterns and ways that you can look at implementing this but you know the idea is that almost everything in the AMP roadmap today is centered around how we could make this a viable performant choice for as many developers as possible again understanding it's a choice it's not the only path but we want it to be one of those clean well-lit paths for developers who choose to use it AMP's embeddability is also coming to the fore so this is something that I think a lot of the focus around AMP has been on speed which is key but we're also finding now that there are new use cases for this concept of embeddability and AMP for email is one of those so this was announced I think in February of this year it's in developer preview we should see there are a lot of companies who are starting to build some really interesting use cases for this what it is basically is AMP sent as an email document which means that when you open that email that can be fresh up to the moment as opposed to whatever the content was that you sent three hours ago or six hours ago it also means that users can interact directly in the email so users can take action dynamic actions within the email itself and if you get in credit for that engagement without having to click out of email and I think last but not least you've all heard about AMP Stories as news publishers the new visual storytelling format that is based on AMP that one is now at the point where it's open for all developers to work with and there is a project in flight now to build AMP, authoring for AMP story support in Gutenberg and so I'll kind of get close to the end here with an update on where specifically AMP and WordPress stands so if you were one of the early adopters of the AMP WordPress plugin you may have experienced that stripped down version of AMP and Google and XWP and Automatic have been working really hard this year to get the AMP plugin for WordPress to a state where it can produce beautiful native AMP or paired AMP pages that match the look, feel and full functionality of your main site so this morning Leo and Ryan from XWP gave a great workshop on how to implement the AMP plugin if you missed it I think they recorded video of it and there will of course be a lot of documentation about it as well on XWP's website on GitHub we're building a product site for it but essentially it is a huge leap forward I think from the previous versions of the AMP plugin for WordPress it's in stabilization right now which means that we're doing a lot of testing and a lot of refinement and so keep an eye out for that stabilization release we'll be talking a lot about that as well in the coming months and then lastly alongside that plugin work there's also a lot of work going on to try to move the WordPress ecosystem meaning building more themes and plugins that either are AMP compatible or natively support AMP so here you're looking at a native AMP theme built with Gutenberg blocks and we're finding more and more ecosystem partners who are interested in working to make AMP an achievable default experience for WordPress publishers so I think I had... there are a couple other things I was going to get but I actually would like to err on the side of leaving more time for Q&A so I think to tie it up what I would say is on the one hand the web has been getting heavier and heavier on the other hand I think there seems to be more of a recognition of the importance that speed plays in a site performance and also more of these beautiful reference examples and frameworks that allow a publisher to... well, we'll do two things first of all, allow us to imagine kind of what a performance web might look like so AMP is one of them, PWA is another and more and more reference examples as well for us to follow so at the end of the day we're feeling extremely optimistic about the potential for us to do it is basically a massive upgrade of the whole web and really happy as well to be working with the WordPress community on that so I will thank you all very much and take any questions Who's got questions? We'll come to you with the mics Also, Brian, if you're in the room, if you can come up and get wired up to start immediately What did you say was available, that became available yesterday? Oh, yeah, so it was the Chrome... just flip, flip, flip... the Chrome user experience combined with Google Data Studio that will let you generate this report that will show how your site or any other domain in the Crocs database has performed month over month And it's available for free? Yes And you should be able to... if you go to developers.google.com. You should find the announcement and there will be a video that will walk you through how to set that up Awesome, thank you And then M for email so you said the content changes within You open it today versus tomorrow changes Is that the first... I've never heard of that before Yeah, I know, I think it is the first Because it's using an AMP document which is sort of self-contained and secure You can deliver AMP as the payload of the email which allows you to do so much more with it allows you to interact with it within the email and for the content itself to be fresh Thank you Yeah, also about AMP for email Is that only for targeting Gmail users or is that going to work in any JavaScript? Any email platform can build with it So much like the rest of AMP, anyone can contribute to it So Google with Gmail is sort of piloting certain integrations of it but it's open source so we really hope to see more other email providers using it But as a publisher, it won't necessarily work if I send it to Earthlink Yeah, you're right So your email platform needs to support AMP for email Who's got another question? Excellent presentation Thank you Thanks, is there any integration between crux and the lighthouse reports? So I don't think that there are I will say we're on a lot of fronts doing work to integrate various tools but I'm not aware currently of an integration between crux and lighthouse because they're really looking at two different things like crux being the actual user experience and the lighthouse being the diagnostic on how a site is built but I also am not the PM on that so for all I know it could be happening If I'm wrong, I'll tweet it out Thank you You guys made it easy for me Okay, thanks everyone