The Vergecast - Google AMP’s Malte Ubl wants to make the mobile web better

Episode Date: September 25, 2018

You may not have heard of Google AMP (Accelerated Mobile Pages) but you almost certainly have used it. The Google open-source project has been making waves since it launched in 2016 in an effort to make the mobile web faster to load and smoother to navigate. This week, Nilay sat down with Malte Ubl, creator and tech lead of AMP, to talk about the controversy of bifurcating the web, forming a technical steering committee to co-lead the project, and Ubl’s vision for the future of the mobile web. Learn more about your ad choices. Visit podcastchoices.com/adchoices

This episode of Virchcast is brought to you at Microsoft Azure. Your business is built on bold ideas. Bring them to life faster, push them farther, and scale them worldwide without skipping a beat using Microsoft Azure. Stay productive with familiar tools, develop and deploy where you want with consistent hybrid environment, and build engaging apps with intelligent features. Join the startups, governments, and 90% of Fortune 500 businesses running on Microsoft Cloud by starting your free account at Azure.com slash trial. That's A-Z-U-R-E-D-com slash trial. Hey everybody, it's Neely from the Vergecast. This week's Vergecast interview is with Malte Uble, who is the head of AMP at Google.

Amp is the accelerated mobile project at Google. You might not have heard it before, but you've definitely seen it. If you click a link on Twitter, you almost always load an AMP story. If you click a Verge link on Twitter, you'll load an AMP version of our website. It's a cut-down version of the web that's being led by Google. It's hugely controversial because it's kind of forked the web. and up until now, Google has been in charge of it. In fact, Malte has been in charge of it.

He's been literally the benevolent dictator for life of the AMP project and how it's technically implemented. That's all changing, though. Google is changing how AMP is run. Malte is no longer going to be the benevolent dictator for life. They're starting a technical steering committee, and they're trying very hard to make AMP a better citizen on the web. That's what we talked about.

We talked about some of the controversy. We talked about the future of AMP, and we talked a lot about the future of the web, which for chess listeners know, is something that interests us a whole lot. Check it out. Here's Malta Uble in Google. Hey, so we have Maltauble, who is the engineering lead for AMP at Google. Thank you for joining us, Malta.

Thanks so much for having me. You and I have been tweeting at each other. You've been tweeting with Deeter. I feel like Deeter and I are the people who care most about AMP in sort of the broader tech press because we really care about the web. And we've had some very friendly interactions. But very quickly, explain what AMP is and what the goals of AMP were. because it is more controversial than you would expect.

Yeah, so, like, there's many ways to talk about AMP. The technical description maybe is the JavaScript library and a web component ecosystem. What kind of makes it unique, it tries to democratize good outcomes for websites. So you don't need, like, the fanciest consultant or read, like, 5,000 blockposts. You just, you know, do what AMP tells you, and we kind of promise you that what you will do at the end

creates something that's good from a performance perspective in user experience. it supports instant loading. So you can have something like Google search. You click a link and then it just pops up as opposed to like having a loading sequence of many seconds. That's a big thing to unpack. We can get right into it there on the weeds

and then we can zoom out a little bit. But it supports instant loading and there's a little bit of news yesterday. But it supports instant loading because Google caches the content, right? So you search for something, you see the verge result, we support AMP. You see the verge result on Google.

You click the link. and you actually go to a Google.com slash the verge slash whatever page or URL because Google has cached it. That's at least how it works when you're on the Google search website as opposed to one of the native apps. So the Google has a so-called mcash. There's a few more of those out in the world. But they play an important role in this instant loading part. And for a reason that not isn't entirely obvious. The actual reason is that there's a privacy issue with instant loading.

loading. So on a normal website, to get instant loaded, I need to download its resources before the user actually clicks, right? Because when you click, then you have to go to network, network is slow, it's not instant, right? So you have to load it before the user clicks. And it's not cool if you like search for, you know, some illness and you really want to just know what it is, but like the first result kind of gets, you know, preloaded and now they know you think you have the illness and they sent you like ads all over the web. We want to avoid this. So that's why this initial load sequence come from the Google Amcash, where we kind of control the delivery and we can control the privacy aspects of it, and so we can have what I call privacy preserving

instant loading. And kind of bring this instant effect together with something that meets user quotation in terms of privacy. So for example, if you're using Twitter and you click a link, Twitter opens AMP pages, right? Right. Are they doing the same preloading as you scroll through Twitter? They don't. And so they don't use an Amcash. Okay. And then yesterday the news was that Bing is now supporting AMP, and they have their own AMP cache. So if you click a Bing link, you'll see Bing.com slash whatever. Exactly. So Bing has actually also used Amp for actually quite a while, but only in like,

I think their news native app. I know they rolled it up out to their main search product, and they built their own Amcash. There's another one from Cloudflare. People are not familiar to one of the biggest content delivery networks in the world. They have built one also a couple years ago, and it's available for platforms to use kind of more as a service you could purchase from Cloudflare. there. One of the most controversial parts of AMP is that when you click on the link from Google

search, you end up at a Google.com URL instead of the URL of the site that you thought you were going to. And I know you have wanted to change this for some time. What are the challenges with changing it and how soon do you think you'll change it? It's been a bit of a journey because we all agree that this isn't an ideal situation. And so we have like multiple strategies going on at the same time and they land at the same time. The first thing we did was just put a link of like the real URL, right? This was the thing we could do like basically in like a week. Then we talked to browser vendors, Apple's and Chrome in particular, and told them, hey, you have this share button. Wouldn't be nice if you like share the real URL. And they were like, yeah, that's

kind of makes sense. And they actually did it in the way that's great for the entire web. So you might have not noticed this, but if you're like on a website and that's a stupid URL with all kind of tracking stuff in the URL, if you share it, that goes away because now she has the canonical So I think it was a generally good change. Another thing we did is in our native apps where we can actually control the display of the URL. We updated this, so it shows us the right format. And then finally, we're working on a technology called web packaging that has been in development actually for a few years.

And we kind of saw it and figured out, okay, this is actually exactly what we need. With that, you'll be able to kind of get the best of both worlds, where you can get this privacy preserving instant loading through infrastructure that's trusted, but then through the integrity guarantees of HDPS. It can be proven by the browser that this content actually, for example, came from New YorkTimes.com, and then they show it as New York Times.com.

And I think that's kind of our desired end state. I think the progress on that is that we announced January that we're going to do it. We started working on it together with a Chrome team. At that time, we had already kind of a prototype. Then at I.O. this year, showed everything kind of working end to end from Google Search up to real websites

from Pinterest and Food Network, but certain things were not really production code, and we didn't support the final version of the standard yet. And so now people are working on getting everything tied up so that we can actually launch it as a user-facing product. The main challenge I think there is that this will initially launch, if at all, because web standards are complicated and take a long time. But it will be implemented in Chrome, right?

And we very much care about other browsers. So I obviously can't give you any form of timeline how long that'll take. But we'll definitely do everything we can to make it go as fast as possible. There's some news about AMP that I want to talk about, which is you're changing how it's being run as a project. And so right now, you're the engineering lead for AMP. You're in charge of AMP. You are the person who makes all the decisions about implementation.

But you're changing that, right? Right. That's also literally what we wrote and how it works. But in practice, of course, things are different, right? So we're not changing that much, but we change how it officially works. Like in every company you have delegation, right? So while in theory, Sundar makes every decision at Google, right, and practice, that's obviously not how it works.

And that's also not how it works for AMP. So we've from the start had a very open and inclusive culture of how we run the project, but it's very important in the end to recognize that it really matters how decisions are made at the top and, you know, when there's disagreement. And so we're updating that called governance of how the project works. But it very much is in spirit of how we always thought about the project. So the way you're changing it is you're basically forming committees, right? You're framing a technical steering committee, a committee that advocates for the open web, right?

Like the big criticism of AMP is that it has bifurcated the web. There are regular mobile web pages and there are AMP pages. Do you think the new governance model will resolve that conflict, will make that conflict easier, to manage, we'll make it worse. How are you expecting to handle that? I think that this is a topic we've always cared a lot about, and I could go into like massive depth there. What we need to ensure and where it would be really helpful to have people who think about it

in a positive, but like essentially different perspective to kind of to make these points clear. So if you think about how other like instant loading formats work, You literally like published some entity. And then it's like with them and it's definitely not on the web. And for AMP, we really try to make it so like there is no way to like publish an AMP document to Google. Like sometimes people ask me like, how do you publish an AMP document to Google? And it's like, you can't.

You just put it on your app server. And it has to be there. And it's accessible there. And as we discussed earlier, Twitter is using it like that. Right. So we very much cared. It has to be on the web. It cannot be not on the web.

And you mentioned this other somewhat controversial technique that I'm actually very much think was right, which was that we allowed people to say, I have an amp version of a document. That was, the alternative would have been to say, like, hey, you need to rewrite your website. You know, and people were like, maybe that's not such a good idea. Maybe I just did that, and I don't want to. Right. And so I think it was important for the success of the format to have a way for people to say,

look, I'm just going to try it out for a few pages and put it to the site. And obviously, at some point, they will say, like, now I have to maintain two things. And that's, you know, maybe not the most pleasant situation, but you, at least, least them mitigated the risk of like a full rewrite. So when I talk to people who make websites, they say, well, does Google want us to develop AMP first, right? Is the power of AMP is such that the pages are much faster. It seems as though Google Search tends to prefer AMP pages.

That's a question I want to get into. But it seems that way. And if you want to build big, rich mobile web experiences, they probably don't conform to the more limited set of AMP things. So the real question is, are you looking at a world in which AMP is, you looking at a world in which AMP is the sort of primary format for people with the secondary mobile web stuff. Or are you hoping that with the new governance model, it can be more open, and you'll actually see more convergence between the regular web and AMP?

I think I see most of those things. They don't usually actually run against each other, and I don't really think that the governance model per se has so much to do with this. So when we say AMP first, I want to just make really clear what we mean. I just talked how you can put something on the site. And some people realize, okay, this is actually really nice. And I want to make it so that this is how I run my website. And so we say very much, this is now something that's supported.

Three years ago, Amph was like 10 weeks old. And no, you should probably not have used it for your website. It's the primary technology. And that certainly has changed. And also, yes, three years ago, Amph was very much focused on use. You could put images on a page and make a headline and put some ads. we've come from there to like, for example, Ali Express, being one of the largest e-commerce sites in the world,

use it for their website, right? And so the limitations, the perceived limitations, are effectively eliminated in many ways. And so it's a production-ready technology that you can use for your website, but there's also thousands of reasons to not do that. I'm like very much also in favor of, like, having technology and say it's great for certain things

and it's not great for other things. And AMP is very much good for certain types of experience on the web and not great for others. So I do not think everyone should use it, but it's an option. And so that's one thing. The second part of your question was, like, should the web develop as well

and, like, be at scale as good at the same things that AMP is good at? It's always a difficult conversation because AMP is part of the web. But, like, we're definitely working on a lot of proposals for the web platform to, like, bring some of the things that we learned to the web platform, right?

And that's basically happening at the same time, and there is no zero-sum game going on, basically. I mean, definitely from Google's point of view, every time the web gets better, that's certainly great for us because that creates more good pages that users can find in our search engine, which in the end is what matters. This episode of Virchcast is brought to you by Qualcomm. Here's an easy question. Do you want faster data speeds in your phone? Of course you do. Everyone wants more speed. Why? Because waiting is annoying. Whether it's in line, in traffic, or when you have one bar of signal and it's taking forever to finish downloading your music playlist. So how can you get

faster data speeds without switching carriers? Turns out all you need is the right phone. analyzed over a million real world results from the speed test app, taken by users like you on AT&T and T-Mobile in Q2, and found that Android phones with Snapchat 845 from Qualcomm technologies had up to 192% faster data speeds than non-Android phones with Intel modems. Seriously, 190%. So check out all the data for yourself at Qualcomm.com. Forward slash Vox. Then upgrade your data speeds with a phone powered by the Snapdragon 845.

That is Qualcomm.com slash Fox. So let's talk about search. I think that's really interesting. The big incentive for a publisher like The Verge or Vox Media or the New York Times or whoever to adopt AMP is that it appeared to us that if we make AMP pages will get ranked higher in search. You guys have always sort of denied this. You've said it's just speed is one of many criteria and AMP pages are really fast. But if you make AMP richer, if you open the governance model, if people are able to add more stuff to AMP, is that going to change the dynamic of how things are ranked in search? No, I don't think so. I think what's really interesting is we announced this like in early this year, January timeframe and then launched in July a new iteration on actually ranking by speed.

And focus on mobile and also like using modern technologies that are better at actually measuring this. So I think it's a big step, but it's a technology independent step. So to do well on this ranking factor, you have to make a fast website, but it doesn't matter how you build it. And so I think it continues to be the case that we don't consider, you know, a ranking factor. And like I don't really see at all of this is changing anytime soon. I'm like certainly not a ranking engineer. And I like don't even talk to these people much. But it's like not the way we think about it, right?

The way we think about it is we want to rank good websites as high as possible. And it just so happens at all good websites pick up. If you look at the distribution of AMP pages, we obviously started in the news space, And we have a product on the mobile web that's exclusive to AMP, click the Top Stories Carousel. And so that's a good chunk of AMP pages, but the vast majority of AMP pages do not fall in the category of being illichable to the Top Stories Carousel

because they're not news pages. So Pinterest, for example, is a heavy user of AMP. So it's Reddit, and I mentioned L.A. Express in the e-commerce space before overstock.com. There's many of these. So this very specific product of the top-star's carousel, which is new-specific, isn't presence there. So there's nothing like it that they could take into consideration that would influence the published in the format, except that they found it's a really nice way to, in the end, increase conversions because you kind of ease out that funnel coming from search by not, for example, waiting 20 seconds of white on a point-click.

Right. So just to put some context, you mentioned other instant loading formats. The one that immediately comes to mind is Facebook Instantal. articles, which came and went, basically, it didn't succeed. I think it didn't succeed for the reasons that you are describing, which is it wasn't part of the web. It was really, it was hard to develop for, it didn't seem like it was moving. Eventually, Facebook through its travails decided that news wasn't important. And so the trade we, as a publisher would make, was published in its articles, Facebook will boost you in the ranking in the news feed. That trade went away. Instan articles went

away. You're saying that AMP is a bigger technology. It's a bigger step than just publish an AMP and we'll put you in the carousel and get more traffic. You're saying it's so much faster that an e-commerce site can actually see more sales because their site loads faster. What specifically about AMP makes it so much faster than what a Pinterest could do by itself? There's a few things, but I do want to mention that AMP itself is completely built on web technologies. There's no magic code in Chrome and certainly not in Safari that kind of makes it faster. it has no access to any private API or anything like this.

So you can make a non-amp page that's as fast or even faster with the right expertise. I think we have a few innovations that lead to AMP in practice having good results, which is like a core goal of the project. One of them was actually an insight which I had in my previous work at Google, where we learned that it's very hard to teach people how to do stuff that's like, performs well at scale, even if they're all like really smart Google engineers. And so we also decided we've been building webpages for like 15 years, kind of know how it works so we can write tests that kind of ensure that you do it the right way.

We don't have to like tell you, you know, read these all these block articles, it's how to do it. We'll just tell you if you get it wrong. And so that's something that we move forward into AMP with the invalidator. And so the learning process of creating AMP pages has been very successful in that way. So that's kind of why, while it's not, nothing's unique here, in the end, the outcomes are better at scale. The second part I think I mentioned earlier is that the access to instant loading does create basically something that we just can't do for non-AMP content for the privacy reasons that I mentioned earlier. So do you think if you had developed AMP in a vacuum, there's just a bunch of people who had a cool idea for a new standard, and you didn't have the carousel and you didn't have Google's infrastructure to do instant loading and search, do you think AMP would have won, as a web format sort of on the merits?

Or do you think its growth was accelerated by the things that Google was able to do on the search page? So I think that there was two things to this equation. We have some experience at Google with trying to move ecosystems based on search incentives. And they don't actually have,

even though I don't want to go into detail, it's like the greatest track record. Wait, now I want you to go into detail. Yeah, but I won't. So I think there's a, you know, you can't just say it's less because, you know, just because Google says something, like, you know, people are going to do it. Like, there's a, in the end, the ROI has to be right.

And so it actually has to be great. It actually has to be something that people want. And it has to be a pass towards participating that doesn't involve, like, throwing everything away that you have. So on the other hand, if I had done this by myself, I would have certainly struggled to get the same kind of publicity, for example, like talking to you even. And then if I was Google, right?

Like, we have done over 25. road shows around the world. We have invested in making our documentation internationalized. So if you look at most web frameworks out there, it's all English. And not everyone in the world speaks English, but everyone in the world should make web pages. And so there's all these reasons why adoption is where it is that are not some incentive system. But you had the incentive system. I just want to be clear, you give the incentive system some credit, and you're saying Google's additional resources carried you the rest of the way. The only reason I ask this is I'm curious, What evidence do you have independent of just sort of adoption that AMP is a success?

Do you have user data that says people are happier and spend more time on AMP pages? Do you have data that says people are happier with a search product? Is there something outside of adoption, which is driven in part by incentives and part by the other work you're describing? Is there some other data that tells you AMP is a success that users like? So there's all kinds of data like that. There's no way how this could have launched at Google as a product if it wouldn't have been for those user. benefits. In fact, one of the original goals of the project was to make tradeoffs driven by user experience. So it's not actually, unfortunately, how web development works in general. So there's two other

main things that people think about. One obviously is business success and one is developer experience. So how does it feel like as a web developer to work on this? So there's a tradeoff between these three. And while we try to make the developer experience and the business outcomes as good as possible, we always prioritize user experience. And it comes to a fundamentally different outcome. And it's important to understand where Am came from. So we talked to all these publishers and they came to us and said, like, it's difficult out there and the web isn't doing really well. And, you know, you have to like remember this was 2015. And people were like singing the death thong of the web and things were not in greatest shape. And so we came from... I wrote an article in 2015 headline,

the mobile web sucks. So... Exactly. Right. So this is like, we probably printed this out and printed on the wall, right? So coming from there, what we heard from publishers was like, okay, we know we have to do something. But if we're the only ones, for example, stopping doing pop-up ads, then we'll lose money. Everyone else makes more money. And users still hate the web. And so there was this agreement that you needed this industry-wide effort to say, like, we're all at the same time make this jump and prior this user experience so that in the end, obviously everyone's happier and everyone has the right business outcome because users are happier

and the end that's good for business, right? So the flip side of user experience on the web is always revenue. You got to put ads on the page. As you think about AMP user experience, there are a lot of people out there who would say there are libraries I can't load, there are ads I can't use,

I'm making less money on the AMP page than I am on my regular mobile web page. How do you reconcile that? Do you say, well, look, you're going to load way more AMP pages. You'll make it up in volume. Or do you say, well, look, we're fixing the web, and that's just the price we're paying. So in 2015, we literally said, like, you have to expect some revenue drop.

It's part of the experiment, and it was really an experiment. And then we launched and people were like, no, actually, this is okay. And since then, we extended what you can do in terms of advertising while keeping the user experience benefits. So, for example, what AMP really very much does not allow is, like, an ad in front of you to, like, get bigger and, like, push the text that you were reading away from you. We don't allow this. Initially, it wasn't even possible, but now you can do this as an ad, but it has to be somewhere

maybe in the middle of the article. So that happens, you know, while the person is still reading the first couple paragraphs. And when they scroll down, the ads already, like, perfectly in place. So we try to make these compromises that don't compromise on the user experience, but when we can, obviously, we do allow

these things that generate higher revenue. And so there's definitely no way to say, like, we make less money on the app. many publishers make more money on AMP. There's all kinds of reasons why you might not. And so thankfully, right now, my colleague Vamsi is writing this many, many article medium series that kind of goes through all the things you can do to optimize your ad experience and your revenue on your AMP page.

But basically, we kind of eliminated all the fundamental reasons why you should make less money, except where we don't allow pop-up ads. And I will not compromise on that. And I don't think my future steering committee will change their mind about this item. I think everyone agrees with you that we should not allow pop-up ads or interstitials. Two things we wouldn't do, actually, and I think a lot of publishers wouldn't do. And a lot of people, everyone just hates. So the change to the governance model, you're adding a steering committee, you're bringing in more people, you have roles to fill, you want that to be a diverse group.

Are you doing that now because AMP is ready to get slower and be run by a committee? Or are you doing it because you need AMP to be more participant in the sort of broader web community? So we certainly don't do it to be slower. The blockposts we put out kind of has a bit of the goals, and it's certainly one of the goals that we try, that we maintain velocity. And it's not the most difficult way to get there, because just like we right now obviously have some kind of delegation going on

for decision making that will still be in place. So we're not actually worried about it in the end. What we do want to recognize and like formally recognize, not only do we want to prioritize, for example, user experience, but actual users need to have this official voice in these matters, right? And I can bring their perspective into the mix. And so I think one of the things we mentioned in the blog post was that we were very interested in talking to people who have, like, experiencing consumer protection. Because I think they can be very valuable in the decision-making process when you try to balance these things between I need to make more money and I need to make that easier to develop and then someone else saying, well, yes, but we need to think about the end users and what impact these.

decisions have on them. So when you talk about that really broadly, do you think end users know what AMP is? Do they understand when they see the Google.com link that they've actually arrived at the Washington Post or the verge or whatever? Do you think that the broad Google user base understands what's happening with the web when they land on an AMP page? Well, I actually know that they don't know what AMP is because we've ran studies on that. So in a way, it's a bit of an accidental consumer brand. We started like in a developer preview and it made sense to put an icon on the search results so people actually know what to click.

And then it kind of develops an inertia and it stuck around. It certainly is not actually a consumer brand. We want people to understand and that's something we measure. they learn, okay, I can click this and it'll be fast, and it'll not jump around in front of me, but that's obviously very different from a true consumer brand. I think it's not, and it's not necessary to be a brand. But it's necessary to have that understanding. And the reason I ask is, you know, we have a great reporter named Casey Newton who covering tech companies and democracies every day and the sort of trust in the media, the trust in companies like Google and

Facebook and Amazon, whoever, is perilous, right? And so do you think that there's any effect on how much consumers trust what's happening because they don't see, there's not transparency into how necessarily AMP works for them? So I don't think so. Because maybe for some of the reasons they don't really understand what AMP is, right? I think that's also because we were talking about other formats. AMP really emphasized from day one, while we want all these documents to have these, like, properties that are similar, the non-jumping around, the instant loading, etc.

We actually have no opinion about the design, and we want the brand of the publisher be forward and for stuff to look like the publisher intended. And so I think from a user point of view, it's completely clear to them that they choose to read the New York Times, so they choose to read The Washington Post, they choose to read the work, and I don't think they're confused about what they're doing there. So last question. Obviously, you've changed the governance model. staffing out this committee, what's next for AMP? Are you going to be able to make the change to how the URLs work? You know, people complain about scrolling. What's the next big move for AMP

that users will see? We're working on a whole kinds of things in parallel. The URL staff is certainly on the horizon. We are working on a technology called AMP Stories that kind of brings modern mobile first form of storytelling to more publishers. So that's something I'm very excited about. We are extending the capabilities of AMP. So one of the primary limitations right now is you can't write JavaScript. So it's one of the three big web technologies besides HTML and CSS. And so we are working on making that available to AMP pages. At which point also, they will be almost indistinguishable from non-amp pages because you have no access to all the three big web technologies.

So those are kind of the things that are top of my mind. But we are working on many fronts and are definitely very excited about this stuff coming up over the next few months. Very cool. Well, thank you so much for taking the time today. I love being in the weeds about this stuff, and I think it's important that our audience hears from the people who make the web, how it's made. So I really appreciate it. Thanks for having me. It was great. Thanks to Malta Uble for talking to us about the future of AMP and the future of the web. I really want to know how you think these episodes are going if you like the interviews, who you want me to interview and what you want me to talk about. So let me know. I'm at Reckless on Twitter, and we'll see you on Friday for the regular Vergecast. This episode of Vergecast is brought to you at Microsoft Azure. Your business. business is built on bold ideas. Bring them to life faster, push them farther, and scale them worldwide without skipping a beat using Microsoft Azure. Stay productive with familiar tools,

develop and deploy where you want with consistent hybrid environment, and build engaging apps with intelligent features. Join the startups, governments, and 90% of Fortune 500 businesses running on Microsoft Cloud by starting your free account at Azure.com slash trial. That's A-Z-U-R-E dot com slash trial.