As we speak, the 1st ever AMP (Accelerated Mobile Project) Conference is taking place (and streaming). This is important as the AMP project - love it or leave it - is providing a need, the accelerated loading of mobile pages.
There is no doubt that the mobile page load is one rife with hurdles - read steeplechase. The data is the athlete, but the hurdles are : the network, the content (ads, images), the device and hell, possibly the client as well (opera mini anyone?). The data and metrics are all out there, notably the well parsed DoubleClick by Google study on how slow pages are loading.
We're a few weeks removed from the Shop Talk Show podcast special on AMP which featured AMP devrel Paul Bakaus and Barb Palser of Relay Media, an agency specializing in AMP and retrofitting/converting pages - or as she mentions: all AMP all the time. You can listen to the AMP special show here.
But very shortly after the show aired, I reached out to friends and associates of the performance community to get some of their feedback about the show, but AMP as well. Wanted to share what was submitted.
Jason Ormand. Performance Engineer, Vox Media
I think AMP is a great experiment. It's really delivered on giving users a speedy experience. We probably lose some branding opportunities given the tight constraints. There is also this feeling when reading AMP articles ... as you swipe away, that your content is just part of some herd. Overall, I'd still give it an A and really appreciate the impact it's had on pushing webperf to the forefront. What I really wanted to happen (and it's starting to) is an AMP like initiative for ads. Ads, trackers and widgets typically soak up 75% or more of browser time. I think we can all agree with that. And since Google has obvious connections to the ad industry they are in an excellent position to make meaningful changes to ad delivery/display/tracking. I look forward to the day when ads are a JSON document and that just gets ingested by some standard library ... like say Backbone, and then it's rendered/tracked/etc without any need for endless amounts of js utility libraries/viewability trackers/etc.
Google AMP intends to solve a very real and increasingly pressing issue: Web pages are slow and not often optimized for low bandwidth and low powered devices. Google intends to fix this issue as any smart minded mega-company should; Create a venue where publishers can produce content that behaves well on all devices, and reward those publishers with higher search engine placement.
This works very well for Google, but not very well for the future of the open web. While Google will increase their market share, user trust, and click through rate, users of the web will suffer at the hands of this strategy.
The famous parable about teaching a man to fish is very applicable here. Google is merely handing out fish (web performance wins) instead of teaching publishers how to fish (the value of performant content). Instead of creating yet another way to publish content so that it ends up being fast after some magic is sprinkled on top, Google should be penalizing publishers for slow content, and offering tips to help them publish content that is fast on its own. This would go on to teach the value of performance minded architecture, over the idea that obeying the largest search engine will send more visitors to your content.
Unfortunately, this strategy is not as profitable for Google and the developer community must press on, advocating for better standards, workflows, and culture, until everyone knows how to fish on their own.
Andrew Welch, Front End Engineer, Studio107
AMP is an initiative from Google that is an answer to what they view as the slow, clunky mobile web. Google cares about web performance because users care about web performance. The approach that they have taken with AMP adds new HTML tags (“components”), and Google’s AMP cache, both of which can be considered necessary evils or a heavy-handed approach, depending on your perspective. At the very least, it is a more open and extensible approach than Facebook Instant Articles or Apple News, which are AMP’s direct competitors.
You can reach the long form of Andrew's article here.
I’m not concerned about AMP. I’m concerned about people like myself who implement it as an easy fix for problems they could deal with themselves without considering all of the implications.
With the exception of Intelligent Resource Prioritization and using the Google Cache, all of the other parts of AMP’s speed and delivery capabilities can be achieved by website owners without having to adhere to a set of AMP specific rules.
By doing it yourself you also improve the performance and experience for everyone accessing your content, and not just those that come through Google on mobile.
My real concern is what Google want to do with it in the future. While Google have been clear that AMP is not a ranking consideration, the only way to reach the top of the search results (even above the highest ranked page) is to either pay for Google Adwords or be included in the AMP Carousel, thus requiring AMP. This becomes a huge carrot dangled in front of Publishers and keeps users within the Google ecosystem.
HTML on its own is incredibly fast. HTML served on a CDN is faster still. If we want faster websites then we need to use fewer things that slow it down. We can do that on our own right now, we don’t have to create a new subset of HTML to do so.
By all accounts, AMP is something that certainly will not remain as is. As an open source project, changes are bound to come. I liked this quote from the Shop Talk Show podcast:
“I do see AMP as sort of a wake up call, but I also see it as a stop gap measure - of sorts”. - Paul Bakaus, AMP devrel.
I also like this quote that he used internally @ Google, which Chen Shay mentioned to me this past week at a conference: something along the lines of the user being a wounded soldier and AMP being a army medic. Got it.
Nonetheless, let's see what the next few months bring.