The AMP is a lie

Size all resources statically

 

I thought with the introduction and adoption of responsive design, we wouldn’t be doing any more custom formats for mobile pages — but I guess I was wrong. The web is complicated enough, and we don’t need another code base to maintain, causing more problems for more websites. AMP is fairly lean right now, but as more and more functionality is added and required, AMP will bloat.

One thing everyone knows is that AMP is fast — but why?
On the page How AMP Works, we see the reasons why AMP is fast:

Execute all AMP JavaScript asynchronously
Size all resources statically
Don’t let extension mechanisms block rendering
Keep all third-party JavaScript out of the critical path
All CSS must be inline and size-bound
Font triggering must be efficient
Minimize style recalculations
Only run GPU-accelerated animations
Prioritize resource loading
Load pages in an instant

Do you need AMP?

I’d add another important point is that the content is loaded over HTTP/2 when most of the web still is not. Nearly everything in the list above can be done without AMP. If you know your website has problems, why ignore the main website and go to a separate code base instead of fixing your issues? If you want to deliver a faster website to your mobile users, then do it. It requires as much work to implement AMP as it would to improve your website without AMP. Pare down your website the way you’re forced to in AMP, and you’ll end up with a website nearly as fast.

I say “nearly as fast” because AMP’s secret sauce is really in the prerendering. Loading things ahead of time reduces the perceived load speed. Would you rather have a website that was perceived to load faster by users but actually takes longer, or a website that actually loads faster but is perceived to load slower to users? I’d argue it’s more important to feel fast than to actually be fast.

 

  1. I’d add another important point is that the content is loaded over
  2. I’d add another important point is that the content is loaded over
  3. I’d add another important point is that the content is loaded over
  4. I’d add another important point is that the content is loaded over
  5. I’d add another important point is that the content is loaded over
  6. I’d add another important point is that the content is loaded over
  7. I’d add another important point is that the content is loaded over
  8. I’d add another important point is that the content is loaded over

I randomly checked about 50 different articles with Chrome DevTools emulating mobile and loaded pages with the AMP prerendering from Google, without the prerendering (directly to AMP), and the mobile non-AMP website. I found that the prerendering shaved 0.5-5.5 seconds off the load time of the page, and most websites seemed to benefit by about a 1-second difference in the actual load speed, but the difference in perceived speed is even greater. Here are a couple of the timings I received from Search Engine Land on recent articles:

Page #1:

1.3s prerendering
2.0s no prerendering
4.9s mobile
Page #2:

1s prerendering
2.1s no prerendering
1.9s mobile
That’s right — on the second article, the mobile website was actually faster than the AMP page without prerendering with regard to the actual load time. Now, perceived load is different, and the AMP page definitely appeared faster. AMP pages can also be slower than non-AMP pages. The worst offender in the pages I checked came from The Guardian, where the actual load time was 10 full seconds longer for the AMP page with prerendering than the mobile website.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s