March 20th and 21st marked the dates for SMX Munich 2018 – and we had a great event, again. In addition to having our Peak Ace booth, Marcel and myself both gave talks on the second day of the event. I have to say the SMX Munich agenda is simply world-class and the quality of sessions is crazy good, so being part of it all and contributing our share kind of feels like a compliment in itself. Now, I know this might sound biased. As some of you might know I am sitting on the advisory board… but loads of reviews say pretty much the same (here, here, here, etc.)
One of the sessions I spoke at took place on Wednesday morning at 9 am – straight after the SEMYs. (Thanks, Sandra! ) It was titled “Accelerated Mobile Pages (AMP) and Beyond – Do Fast Sites Need AMP?” and boy, that one was discussed a lot during the day and afterwards, and it sparked a very lively Twitter conversation as well. In case you missed it (or couldn’t make it to SMX), here are the slides:
[slideshare id=91398390&doc=smx-muenchen-2018grimmampfinal-180321080317]
I don’t want to recap the entire talk; however, I think I should reiterate some points I made during my presentation one more time – as well as provide some context. Before we get into that, please understand:
- In my opinion (see here) the entire discussion Google created around performance optimisation, the need for fast loading websites and also AMP as a topic itself, certainly helped to raise awareness as well as the fact that “performance” is now on a lot of companies’ agendas.
- Furthermore, I stated (here) that AMP as a framework could eventually help to enforce certain guidelines with its restrictions such as limited CSS inlining or minimising RTRs, etc. It could also enable overarching teamwork – which can be especially valuable in larger organisations.
Before I touch on some more details, please take the time to re-read the following (probably most important) slide from my presentation:
So, to be clear:
I strongly believe that you should take care of your website first and foremost.
Make it as fast as you can – and don’t let any “framework” (including AMP) serve as an excuse not to cover all the important basics (some are in here if you’re interested).
This is especially important if you’re not fully on AMP because in this case, you wouldn’t have dedicated AMP URLs but instead, you’d be using one URL which serves AMP mark-up straight away. One of the better-known websites doing exactly this is the official AMP site, of course. However, during my talk, I mentioned bmw.com as an example which apparently was perceived as “bashing”.
The opposite is true: Peak Ace and our teams are used to working with some of the biggest international brands in the world – therefore we understand that especially in large, global projects, there are always things that can go wrong or are not best-in-class for various reasons. And of course, that’s OK. The core message of that slide is: “You’re not done with performance optimisation just because you’re doing AMP.” Far from it.
I’d also like to highlight two other parts of my presentation, which I hope will provide some additional background:
- I pointed out (here) that implementing AMP will certainly result in additional effort. It doesn’t matter whether you go full AMP or not. In both cases you’d need to understand how AMP works, what it can do etc. – as well as that potential CMS adjustments and additional staffing will increase costs and maintenance effort (here).
- As a matter of fact, AMP implementations are not necessarily faster. The “magic” (and that’s a bonus you’ll only get if you are using AMP) is in Google pre-fetching/pre-rendering your AMP URLs when a search engine result page (SERP) is generated. Essentially this means that Google kind of “preloads” the URL in the background, so when someone clicks/taps, it is there straight away because it is already “cached”.
Looking at some real-world data for four major German publishing companies and excluding SERP pre-fetching, this all looks very different:
If you’re interested in more data, make sure to check out Tim Kadlec’s post which concludes: “If we’re grading AMP on the goal of making the web faster, the evidence isn’t particularly compelling […]”.
In conclusion, for me it’s not really about using or not using AMP; because – let’s be honest for a second – say I am a publisher and create newsworthy content, I simply cannot say no to AMP. I need to be in the carousel because that’s where all the traffic is. Simple as that. The same is true if I care about the lightning bolt (aka the AMP icon in organic, eventually more CTR?) or if I want to succeed in the recipe space (cards anyone?). Right now, you don’t really have a choice; Google is making you use it – otherwise, you would have to accept a significant competitive disadvantage. And that sucks.
