Ghost: Google AMP (Accelerated Mobile Pages)

[frnco]

I am considering building this, and it is already on the wishlist (https://ideas.ghost.org/forums/285309-wishlist/suggestions/12437706-accelerated-mobile-pages)

What are the thoughts of the team, things I should consider, implications on themes etc.? Do you guys think this should this be included in Core or should it be implemented by theme builders or as a marketplace item...?

I believe ideally this should be in the core as it is a way to deliver optimized content for mobile users (Feels pretty much like "the front-end version of Ghost" to me), but it obviously has many implications to theme builders and restricts a lot of what we can do (i.e., Disqus). Still, I feel it's most likely worth it.

[ErisDS]

If you want to tackle it, that's fantastic :+1: There has been some discussion in the #dev channel on slack, so I recommend joining there - that's the best place to work through questions like this.

This is the kind of thing we usually build in labs in core to start with, see how it goes, and then make a decision how to move forward with it.

The first thing to do would be to identify exactly what AMP is in the context of Ghost. That means reading through the AMP spec / docs and identifying which parts are relevant / should be built into Ghost and if there are any parts which are not relevant and why, etc.

It is very preferable that all this gets written down in an outline of what will be implemented, a great similar example is the original issue for adding structured data. Writing it down means: 1) it's easy to write tests and see that the implementation matches the intention 2) if you get part way through and don't have time to finish someone else can easily pick up where you left of and 3) we can refer back to it in future if/when extending the feature to see how and why the existing one works.

Without a written description of the implementation, anyone looking at your PR or the code in future has to refer back to and read all of the AMP documentation to understand what you've done and why. It leaves a lot of things up in the air, and makes it much harder to be sure a PR is correct & mergable.

Would you be up for doing that first?

[quangtt]

This sounds great!

[punkeel]

+1 +1 +1

[wnda]

Hi, sorry to drop in randomly but I'm writing a book on using AMP and I've been using Ghost since the beta was posted on HN, so I thought I might be able to offer some insight. I still pointlessly use AMP for my blog posts, implemented at the theme level.

AMP strictly forbids any kind of client-side scripting, offering AMP custom elements instead—so using the public API would become problematic. I remember when I started messing with AMP I was deliberately omitting {{ghost_head}} from my theme because it was including jQuery automatically.

There are also several HTML elements and some CSS features which are invalid, notably form/input elements, and of course any kind of media like images, videos etc. which must all be handled with custom elements.

Apart from those issues, AMP is super simple to implement and I think it is best done at the theme level. Adding it as a core feature would almost necessitate the creation of a secondary theme anyway, because the main theme would have to be sanitized or even re-structured when displaying AMP pages and... yeah, I don't think that's the answer.

JSON+LD and meta tags are all permitted and even encouraged, so the structured data wouldn't need to be amended. I don't even use AMP on all of my pages and I control this using if/is blocks in handlebars.

[ErisDS]

so using the public API

Only if you use it via Ajax rather than the {{#get}} helper 😉

I think it is best done at the theme level

That may well be true, but perhaps there are additional features we can provide to make it easier to support? Something beyond the existing if/is blocks?

[wnda]

Only if you use it via Ajax rather than the {{#get}} helper 😉

Yes, that's true, I should have been clearer in how I expressed myself. I mainly use Ajax to return search results for the search controller I've added. Oh and for a Ajax'd contact form I added as well, but obviously both can work without Ajax so AMP need not cause too much trouble.

Something beyond the existing if/is blocks?

I think that would be pretty effective. A helper like {{#amp}} <something> {{/amp}} or {{^amp}} <something> {{/amp}} would definitely be the best approach. Then the AMP boilerplate code would need to be added to he <head>—this could be done easily in helper/ghost_head.js but it might not belong there long-term.

It might be better off as a separate amp_head.js helper or something. It could just be a flag in the admin system like the Ajax API helper, but then there would be no flexibility to have both standard and AMP pages, which is the approach most publishers have adopted.

Maybe it needs to be a module in its own right which generates two pages, one available with /amp/ appended to the URL. I suppose that's where it gets complicated, i.e. would it be worth it?

[dandv]

Massive support signal from Google at the end of last month: the 2016 Founders' Letter mentions AMP as one of Google's major investments in the mobile web:

We also continue to invest in the mobile web—which is a vital source of traffic for the vast majority of websites. Over this past year, Google has worked closely with publishers, developers, and others in the ecosystem to help make the mobile web a smoother, faster experience for users. A good example is the Accelerated Mobile Pages (AMP) project, which we launched as an open-source initiative in partnership with news publishers, to help them create mobile-optimized content that loads instantly everywhere.

As a Developer Advocate at Google helping with PWA (see the PWA feature request) and AMP efforts, please let me know if there's anything we can do to help Ghost launch AMPed posts.

[aileen]

Integration of AMP for posts in Ghost

Hello everyone,

I will start now to integrate AMP for posts in Ghost and want to put out, what kind of changes I'm going to do. Especially when it comes to questions like theme development I'd love to hear your thought on that.

These are the major requirements:

• The default template will be in Ghost core, but can be overridden by a custom amp.hbs template should be included in themes root directory, so developers can adjust the style to their themes, or create their own amp template.
• We cannot import css, so it has to be inline or in the section of the template as <style amp-custom>.
• AMP support for posts only.
• Modify/add/change ghost helpers to output content in amp html way (means, replace prohibited html tags with amp conform one and add width and height to every kind of media).
• For every amp component we might use (animated images, embedded videos, depending on the original html content) we need to include the amp component for this specific amp tag in a <script> tag in our head!

---

Based on the requirements, these changes will be done to our codebase:

As soon, as the url has an appended /amp (e. g. https://myghostblog.com/my-blog-post/amp), we will render an amp.hbs template, which will provided in our Ghost core, but can be overridden by an amp.hbs template in themes root directory.

It is necessary to serve width and height properties for every kind of media. As we don't have a proper image handling yes (see #4453), I want to include a npm module called amperize (https://github.com/jbhannah/amperize or modify this version to a more suitable one) to simply get those properties. Plus, and even more important: this module will also translate our html to be amp conform.

Some helpers will need to be added or updated, to work with amp html:

• {{ghost_head}} needs a canonical link to its according amp page
• {{amp_head}} will output everything we need in our <head>, like our application/json+ld, the meta data and the mandatory script tag to load the AMP runtime and the script tags to load extended components.
• {{amp_content}}: will output the html of the content, but amp conform. The html needs to be checked (see amperize module) and some tags have to be replaced for amp specific ones (<img> with <amp-img>, <img> with a .gif as a src with <amp-anim> and <iframe> with <amp-iframe>). This module returns also the necessary width and height property to all kind of media.

Most of the helpers can still be used, especially the {{post_class}} and {{body_class}}, so we're able to reuse the rendered classes in our inline css in <head>.

---

Edit 15.08.2016:

Instead of creating a new helper {{amp_head}}, I reused {{ghost_head}} with little changes, so it fits to AMP posts.

---

Edit 18.08.2016:

Changed it slightly again. We're now using {{amp_ghost_head}} as the helper for all structured data and meta data, but it will call the changed {{ghost_head}} helper in the background.

Important: Code injection will not be included in {{amp_ghost_head}}.

---

ToDos:

• [x] Code up AMP template
• [x] Implement AMP as app in Ghost core
  
  
  
  • [x] Add new helpers for AMP
  
  
  • [x] Write tests
  
  
  • [x] Implement Amperize lib to parse HTML into AMP-HTML
  
  
• [x] Add /amp route and amp context to render AMP post
  
  
  
  • [x] Add context amp in frontend controllers
  
  
  • [x] Add /amp route to render default amp.hbs template
  
  
  • [x] Incl. new canonical URL to amp page in {{ghost_head}}
  
  
  • [x] Write/update tests
  
  

[nuclearpengy]

cool \o/

[jetrois]

So loving this was a onside ring amp support myself

[aileen]

This is merged to amp branch, but will stay open until it's merged to master.

[punkeel]

Is this real?

[aileen]

@PunKeel yes, very real 😊

[tuannh99]

Amazing!
Upgrade Ghost from 0.7.* (Yes, 1 year ago, I'm sorry) and SO AMAZING!
Thanks so much for intergating AMP feature to the core!