Does AMP Counter an Existential Threat to Google?

Monday, December 14, 2015 at 9:06AM
HighScalability Team in AMP, google, web

When AMP (Accelerated Mobile Pages) was first announced it was right inline with Google’s long standing project to make the web faster. Nothing seemingly out of the ordinary.

Then I listened to a great interview on This Week in Google with Richard Gingras, Head of News at Google, that made it clear AMP is more than just another forward looking initiative from Google. Much more.

What is AMP? AMP is two things. AMP is a restricted subset of HTML designed to make the web fast on mobile devices. AMP is also a strategy to counter an existential threat to Google: the mobile web is in trouble and if the mobile web is in trouble then Google is in trouble.

In the interview Richard says (approximately):

The alternative [to a strong vibrant community around AMP] is devastating. We don’t want to see a decline in the viability of the mobile web. We don’t want to see poor experiences on the mobile web propel users into proprietary platforms.

This point, or something very like it, is repeated many times during the interview. With ad blocker usage on the rise there’s a palpable sense of urgency to do something. So Google stepped up and took leadership in creating AMP when no one else was doing anything that aligned with the principles of the free and open web.

The irony for Google is that advertising helped break the web. We have fouled our own nest.

Why now? Web pages are routinely between 2MB and 10 MB in size for only 80K worth of content. The blimpification of web pages comes from two general sources: beautification and advertising. Lots of code and media are used to make the experience of content more compelling. Lots of code and media are used in advertising.

The result: web pages have become very very slow. And a slow web is a dead web, especially in the parts of the world without fast or cheap mobile networks, which is much of the world. For many of these people the Internet consists of their social network, not the World Wide Web, and that’s not a good outcome for lots of people, including Google. So AMP wants to make people fall in love with the web again by speeding it up using a simple, cachable, and open format.

Does AMP work? Pinterest found AMP pages load four times faster and use eight times less data than traditional mobile-optimized pages. So, yes.

Is AMP being adopted? Seems like it.  Some of those on board are: WordPress, Nuzzle, LinkedIn, Twitter. Fox News, The WSJ, The NYT, Huffington Post, BuzzFeed, The Washington Post, BBC, The Economist, FT, Vox Media, LINE, Viber, and Tango, comScore, Chartbeat, Google Analytics, Parse.ly, Network18, and many more. Content publishers clearly see value in the survival of the web. Developers like AMP too. There are over 4500 developers on the AMP GitHub project.

When will AMP start? Google will reportedly send traffic to AMP pages in Google Search starting in late February, 2016.

Will Google advantage AMP in search results? Not directly says Google, but since faster sites rank better, AMP will implicitly rank higher compared to heavier weight content. We may have a two tiered web: the fast AMP based web and the slow bloated traditional web. Non AMP pages can still be made fast of course, but all of human history argues against it.

The AMP talk featured a well balanced panel representing a wide variety of interests. Leo Laporte, famous host and founder of TWiT, represents the small content publisher. He views AMP with a generally positive yet skeptical eye. AMP is open source, but it is still controlled by Google, so is the web still the open web? Jeff Jarvis is a journalism professor and a long time innovative thinker on how journalism can stay alive in the modern era. Jeff helped inspire the idea of AMP and sees AMP as a way publishers can distribute content to users on whatever form of media users are consuming. Kevin Marks is as good a representative for the free and open web as you could ask for. Matt Cutts as a very early employee at Google is of course pro Google, but he’s also represents an engineering perspective. Richard Gingras is the driving force behind AMP at Google. He’s also a compelling evangelist for AMP and the need for a true new Web 2.0.

Here’s a gloss of the discussion. I’m not attributing who said what, just the outstanding points that help reveal AMP’s vision for the future of the open web:

Origin Story

• Jeff Jarvis and Richard Gingras started discussing the idea of containerized news a few years ago at newsgeist, a conference on the future of news. It’s the idea of an embeddable article that travels to any site with its brand, revenue, analytics, and links attached. AMP is the child of that vision.

• AMP started with the question of “how do you make a healthy ecosystem for publishers?” and it worked backwards from there. AMP is about making pages fast. The ideal content access time is instantaneous. Anything less than instantaneous reduces engagement. When you look at the ecosystem and the need for publishers to drive engagement and have their content be more readily available on all kinds of platforms, AMP is a good solution.

• AMP has been a collaboration from the beginning. It started with discussions with publishers and technologists back 6 or 8 months ago. It’s been a very collaborative effort since then in terms of developing the spec and in terms of developing the overall approaches taken.

What’s Wrong with the Web

• Ad blocker use in Germany up to 40% and up to 20% in the US, so action was necessary.

• AMP is important in markets where mobile is 3g or even 2g. It will speed up their experience and greatly reduce data costs.

• The slowness of the web is more pronounced on mobile where bandwidth is constrained and users are paying for the bandwidth. Advertising experiences on the web have become far more annoying and far less compelling. These factors have led to serious concerns about the state of the web.

• Speed concerns and annoyance with the ads has had a number of challenging after effects. For mobile web users in developing countries, where data plans are more constrained, their definition of the Internet does not include the World Wide Web. It includes social networks, maybe YouTube, but it won’t include the World Wide Web, part of the reason why is because the web is slow.

• The poor implementation of ads has given rise to a precipitous increase in the use of ad blockers and a rise in quick views and reader views, which strip put the business model entirely. This is not good for an ecosystem of high quality content that needs to sustain itself economically.

• A further effect given the speed of the web is that it has opened up an opportunity for proprietary platforms, social networks for example, and Facebook with Instant Articles, who says the web is slow, we can make it fast, simply host your content with us. It makes great sense for Facebook, but it underlines the core issue that the web is not as fast and as compelling as we all hope it would be and should be.

What is AMP?

• AMP does four things:

  • Provides a shared library of scripts so they don’t have to downloaded every time.

  • Caches and prefetches content closer to the user. Google can cache the data, but other CDNs can cache content as well.

  • Sets standards for the architecture of advertising so advertising doesn't infect pages.

  • Shared mechanism for collecting data for analytics so you don’t have N different packages on a page gathering stats.

• For example, the code to display a tweet will be coded once in the shared library so it is only ever downloaded once to a browser.

• The genesis of AMP is could we rearchitect how the web works while respecting web principles and respecting web technologies so content could be made instant everywhere? Clicking on a search result or a link that goes into Facebook should be instant. We can do a far better job of removing the friction between the content experiences and the platforms that are driving audiences to those experiences.

• AMP is a huge boon to the publishing community, particular to all the tail publishers who don’t have the technical ability to build all the things they have to build to get their content delivered at speed.

• How do we smartly rearchitect how the web works without diminishing any of its capabilities? Or diminishing the freedom of publishers and content developers to create the kind of content experiences they want to create? It’s all very doable. Given the alternative it’s very crucial we go down this road. When we look at the situation in the ecosystem today, steps need to be taken because the challenges we are facing otherwise are very steep and very concerning.

• AMP can be thought of as a middle ground.

  • It solves 80% of the problem for those with rich content that’s relatively static. It will help a lot of publishers like the Washington Post.

  • AMP solves the problem in an open source way and we all love the free and open web.

  • It’s OK if AMP doesn’t cover 100% of the cases. Gmail can’t be done in AMP, for example.

  • That Google approves the javascript in AMP is a tradeoff. You want the javascript to be minified, secure, compact, and standardized. But you also want new things in AMP and there’s an open process for that.

• A lot of AMP comes down to being smarter about how content is handled in the browser. For example, some sites when a page is loaded will load four different images sizes even though they only use one. Google stepped out with an approach in an attempt to address these issues.

• When Google looks at the architecture of the web it sees a lot redundancy.

  • So Google took an engineering approach. How do we optimize this? How do we make things faster?  

  • The most obvious point is let's look where there is redundancy and there’s a huge amount of redundancy that's almost entirely in javascript.

  • The idea is to factor out the redundancy into core functions without reducing creativity.

  • The slideshow module, for example, is very basic, publishers can compose on top of so they can make the slideshow look act and feel the way they would like.There's no reason to have many thousands of approaches to the guts of the slideshow.

  • Eventually perhaps slideshows can be moved into HTML via a slideshow element.

• Analytics are a good example of redundancies.

  • The road to performance hell on the Internet comes with a vendor coming in and saying add one more line of javascript so we can give you more analytics.

  • What you find is you just increased page load times by three seconds because off all the stuff that’s happening behind the scenes that you don’t have much of a window on.

  • Google said how do we fix this while supporting third party analytics packages?

  • The solution was to build into the runtime all the core analytics gathering for the page. It’s not necessary to have N different packages measure the scroll point. We only need one.

  • All the data is passed back to a publisher endpoint so analytics providers can make use of the information.

  • It’s a sound and reasonable approach that removes redundant functionality on the page. It’s open source, the spec is there, Google is engaged with all the providers and participants, they will do their best to come up with the right solution and earn the trust of all the participants.

How does AMP Work?

• The core approach to the architecture is to find optimal efficiency by eliminating redundant code and turning those bits into code primitive modules that can be built upon.

• It’s hard to slim down a site with as much javascript as is being used today. Each web page is its own app. It has its own menuing structure written in JS, it has a slide show written in JS, all this code is redundant and can be addressed with core runtime modules. Google wants to create a base layer of functionality for the web in a fashion that doesn’t take away creativity. So, simplify the models, expand the capabilities of the runtime as things progress, but also leave in escape hatches for people to do more so it doesn’t take away creativity.

• There’s no javascript in an AMP file itself. It’s simply tag calls to javascript runtime components.

• Escape hatches are provided. If along with an article someone wants to trigger an interactive data visualization then there’s a way in the specification to do just that.

• One concern is native HTML elements are being replaced with custom elements, particularly audio, video, and image are replaced with AMP-audio, AMP-video, and AMP-image. Which means AMP pages aren’t HTML because without the javascript library the pages will not load.

• In some ways AMP is a new HTML created using javascript.

• AMP’s javascript for the core runtime is served from amp.javascript.org.

  • This means everyone is loading the same library from the same site so there’s only one copy of the code in the browser.

  • Javascript outside the runtime can be included in proscribed circumstances.

• One key principle in AMP is to leave the publisher in control of their content, their page, and their business model. AMP pages are served by the publisher.

• Google caches pages to surface them on their properties. Google is making that cache available to any and all comers who want to pull content from Google’s cache. This is a huge boon to publishers for many of whom the largest cost outside of people is a CDN. Google is giving away a free CDN, use it if you would like. I assume this is part Google’s new Cloud CDN product.

• Built into the runtime are certain basic restrictions on ads.

  • Content displays before ads.

  • Ads have to communicate a predetermined size.

  • Ads can’t reach outside the document, eliminating pop ups.

  • Javascript associated with ads will not be allowed to run.

  • More ad networks are supporting AMP every day. The advertising industry has to evolve its own sense of how to create and deliver compelling advertising.

• AMP allows for gradual adoption and experimentation. You don’t have to completely rebuild your website. You can offer alternate, very fast, mobile pages. So take your current article pages and create AMP versions. WordPress already has plugins.

Doesn’t Google Have Too Much Power?

• The interests of Google and the web are aligned. There’s a common objective: how does the World Wide Web remain a vibrant and open ecosystem of knowledge that benefits all? Google needs an open and rich ecosystem of knowledge. If that’s not there then Google search won’t be relevant. Which is Google’s direct self-interest, which is also the same objective of the publisher. Publishers need access to an open ecosystem of distribution. Otherwise they’ll have a harder time building audiences if they have to appeal to closed platforms. Yes, Google is a private company that has business interests, but that philosophy and that core similar objective is something very important when considering Google’s role in AMP.

• AMP is open source, but there’s a concern Google has too much power over AMP. Today everyone is at parity with the free and open web.

  • The counter argument is that AMP is still the free and open web. You are free not to use AMP.

  • And large companies, including Google, have long played a role in the advancement of protocols. That’s what Google is doing with AMP.

  • Since AMP is open source you are encouraged to jump in and express yourself.

• Google understands there’s a trust issue. Google will have to earn trust every day. But somebody has to step up. Logically Google is the best position to do so.

• True governance is a balance between satisfying the needs and desires of the collective group and those who lead the collective group. It’s up to Google to prove every day that they can be trusted. That’s what’s happening in the project today.

• If Google didn’t take leadership we would still be complaining a year later about the slow web and ad blockers. Google knew they’d take a hit on AMP. People would ask: what’s google’s agenda? But Google stepped up, put itself in a position of risk, and took leadership when nobody else was.

• It would be better if AMP came from a standards body, but there’s an urgency based on the business case related to the growth of ad blockers.

  • The response of the ad industry to the ad problem has been weak sauce.

• If you don’t like AMP, what’s the alternative to the problem set we are seeing out there in the market?

  • One alternative is for publishers to use less HTML and javascript. Which is unlikely to happen because it means losing capabilities.

  • It sounds like Google is saying you guys crapped up the web, let us handle this, no javascript except what we provide from our servers is allowed. Is this a non-starter for the majority of the world that says Google is an advertising company?

• A lot of people expected Google to have a response to Facebook’s Instant Articles. Google didn’t respond with a proprietary format. That’s not what the ecosystem deserves or needs. Early on Google established a collaborative open source effort is what was needed. And Google would use their technical expertise to drive the process.

• AMP will sink or swim based on its adoption. People could decide to abandon AMP and go back to slow web. The problem is great enough that someone had to step up and show leadership. In being a leader you make yourself vulnerable to criticism.

• Private initiatives like AMP are a way to push the industry forward.

  • Chrome launched because Firefox was getting a little slow. Firefox is now much faster. Chrome also allows Google to experiment quickly with new approaches and prove them in the field, much faster than any standard can be set. 

  • Even if Google fiber doesn’t provide service to everyone in the US, it wakes the cable providers out of their slumber.

  • Google’s SPDY was folded into HTTP/2.

• AMP is crucial to the future of the World Wide Web. It would be incorrect to think of this as a Google project, it’s going to take the leadership of many, not just the leadership of one.

• The alternative is devastating. We don’t want to see a decline in the viability of the mobile web. We don’t want to see the poor experiences on the mobile web propel users into proprietary platforms.

• Governance on AMP is an engineering centric effort. Google has been the enabler for AMP and is leading the effort, but the success will depend on Google doing the right job and satisfying the larger community of interests. That’s Google’s core objective.

• Isn’t AMP a unilateral effort with Google in charge? AMP hasn’t been a unilateral effort from the beginning. Google is clearly playing a key role.

• Why create AMP outside the standards process? Why not go through a standards body like W3C? Aren’t we just proliferating the number of standards?  

  • Setting a new standard takes years. We don’t have time. The urgency of the situation calls for action. If you have a better approach Google is all ears.

  • Google has put an approach into the market that can evolve into a de facto standard or an official standard as time goes by.

  • There has been an evolution of how standards are made. It used to be standards were created first then people would implement the standard. We’ve moved to an implementation first model and then standards as documentation of implementation.

  • There’s a mistaken idea that standards are legislative bodies that tell everyone what to do. That process failed in W3C for HTML2 where there was as assumption if they wrote the standards then all the browser vendors would adopt them. Browser vendors didn’t want to do that, so we got HTML5, which was developed outside W3C and brought back in. That sort of pattern repeats itself. There’s nothing necessarily wrong with building this thing and then asking for adoption.

  • There are concerns with how AMP replaces HTML with custom bits of HTML, it might be better if they used HTML.

Thematic Unicorns

• AMP is not WAP, though they have much in common spiritually.

• AMP pages look kind of ugly, they are bare bones, but that’s worth it for all the people who are usually cut out of the web, those who have to pay a lot for their bandwidth or who are on slow networks.

• The valley itself has to get its act together. The valley is seen as monolithic enemy to regulators in places like Germany. It does not serve the industry well for Facebook, Apple, and Google to have separate agendas. It’s important to build bridges among technology companies to present a common face to the rest of the world. Bridges need to be built not only between the East Coast and West Coast, Europe and US, publishing and technology, there must bridges among the technology companies too.

 

On HackerNews

Article originally appeared on (http://highscalability.com/).