Faster than AMP

tldr;  You might not have noticed, but AMP suddenly got slower for most websites, to fix the problem engineers behind AMP are using Merkel trees - which a core component of every blockchain.  AMP is not a cryptocurrency or token, but it is using the same technology to make AMP faster and possibly safer.

AMP is a new(ish) platform that is not without it's own controversy.  According to the documentation, AMP is supposed to be about speed, and renewing interest in performance on the web is a wonderful thing.  I attended the Google AMP roadshow in Venice Beach in 2018 and opening statements a Google eningeer said: "AMP empowered developers to make the right choices." - which is ominous statement at best.  Any platform that is worthwhile should be controversial, ruffling fathers is a good attribute of a platform because it means people give a damn - just look at Torvalds and Linux. Fast page loads is something that everyone can benefit from, and understanding why pages are slow helps us as humans us build a better shared experience - a noble pursuit.

The mark of any good platform is giving developers enough rope to hang themselves.  A noose is shockingly simple, and if rope couldn't make a noose then it wouldn't be useful in tethering a ship to a dock.  So AMP is about speed right?  Then what is the slowest AMP content, and why is it slow?  I'm not talking about making a page intentionally slow, but rather finding a page that fills a legitimate business need, and yet still falls short of ones "desired performance."

A Cleat Hitch

Part 1 - Slow AMP

So, I set out a journey to find the slowest AMP content online.  There are three tools that I use to measure performance; the tried and true,  Google's new and Chrome's Audits Lighthouse which is a new tool built into everyone's Chrome browser.  The first two are cloud-based services, which avoid the problem of my client's variable connection speed as a bias,  but testing a "real world" scenario with a real client provides a good datapoint.

The winner? Drumroll...  Fox News, by several miles (or 'km' for everyone who isn't American).  Fox's website is phenomenally slow, and gets the worst ratings of any page I tested across all three tools.  All three profiling tools suggest easy performance gains can be obtained through minimized JavaScript and CSS, a simply luxury that is ignored by the indelible Fox News.  One would say performance isn't a priority on this site, after all this is more of a concern for the developing world - which is totally fair.

Virtually all AMP'ed sites have an original desktop version, and an AMP version.  They often have a similar URI,  either having an "amp.*" subdomain, "/amp/" directory, or in this case an ".amp" file extension. This is the original non-amp'ed desktop version:




The .amp content above is the one served by Google Search to mobile devices - this ~28 second render time is the exact page that all mobile browsers will load.  Both pages are extremely slow, but one thing that caught my eye is that the .amp content was slower than the non-amp'ed page.  In fact it was 3.5 seconds slower,  which is crazy to think about because plenty of web pages load in under 3.5 seconds.  The report is says that by AMPing the page the performance went from a 15 to a 14 - which is a score out of 100. The number of HTTP requests increased by 149 by simply switching to the '.amp' version of the page...   Getting a F- on an exam with a score of '14', would be a good reason to drop the class, and try again next semester.

Ok Yes, something is clearly is wrong here. The purpose of AMP is to make pages faster, and if you know AMP really well then you know that the above ".amp content" isn't served over an AMP cache.   The AMP Cache is *magic* that is more than just a static cache.  An AMP cache renders an AMP content in an instrumented version of Chrome that runs in the cloud. The cache will preload and optimize the final page so that it is rendered faster for all future clients.  Keep in mind this is a free cloud service that uses introspection in order automate the process of improving performance...  Humans have been using profiling tools that depend on introspection to improve performance for a long time,  but this is *purely automated* and that is a hard problem to solve - all for free - which is something I have never seen before.

But clearly automation is failing here, Google search isn't directing us to an AMP Cache endpoint - no, in fact they are sending everyone to the pre-rendered .amp content on - which takes ~28 seconds to load.  Google use to serve these pages over{%host%}/{%path%} which served out fully optimized AMP content, but that doesn't seem to be happening any more (Perhaps a Security vulnerability...)   Is there something a skilled engineer can do to correct this problem?


The AMP content above was served up by a Google Search, and it is the page that mobile client's see. The first thing that comes to mind is load from an AMP Cache!  One of the big drawbacks of using an AMP cache is that the URI is ugly:

Of course no developer would choose a URI that is this hard to read.  You can't run your own AMP Cache, this performance optimization is secret sauce and it hasn't been open sourced.  In order for *your* domain act as an AMP Cache endpoint, the web application needs to cryptographically sign AMP content using MICE (Merkle Integrity Content Encoding). Some readers might be thinking "Merkel, as in the Merkel tree used by Bitcoin?"  Yes,  the very same Merkle tree, and Cloudflare has an excellent writeup on MICE used by AMP cache.  Politics aside,  this is an amazing application of cryptographic signatures!  Taking politics into consideration - this change means websites are delegating content distribution to some of the largest companies on the web, all for free.

There is a significant benefit from using an AMP Cache, loading that slow 28 second page over an AMP cache sped up the page by 40%:

470 fewer requests, and a 40% improvement in speed!  Damn, that AMP Cache really improved speed.  This is great and all, but no one is getting this 17.4 second page speed,  mobile devices are getting stuck with a ~28 second load time.  Also, 17.4 seconds?  That is still horrible, and by all accounts a failing grade.  Clearly there is more that can be done here.  Plenty of people would just stop here and call it a day, but the hardcore engineers want to fix the root of the problem.

In part 2 of this blog post I will dig into the results of the profiling tools and show you better performance gains.  Yes, I'm that kind of geek.