AMP Pages

[mkiser]

I have a plugin for the Google AMP Pages, but I'm not sure it's configured correctly. I think there's both some scheme issues and some formatting issues.

[mark-monteiro]

The plugin you have added is not supported with GitHub pages; there is a very limited set of plugins supported on Github Pages as listed on this page.

Here are three options I can see to get this working:

1. Build the site locally before every commit and include the _site folder in the Github repository. This way you can add any plugins/custom ruby code that you want, but the deployment strategy becomes a bit more complicated.
2. Use an alternate hosting provider that allows for a custom build and arbitrary plugins. I have used Netlify in the past for other Jekyll sites and found it to be superior to Github Pages. Netlify also provides real HTTPS which is a plus. (the GitHub Pages + Cloudfare solution doesn't provide real HTTPS)
3. Create a custom template to render the pages in AMP-compliant format without a plugin. The posts for this site aren't very complicated so this might not be that difficult but you might just end up recreating the functionality of the plugin.

[mkiser]

I should probably update the project description. I'm no longer using GitHub Pages – I'm building with Travis CI and deploying to S3 (CloudFlare in front for CDN and SSL).

[mark-monteiro]

Ah okay, I've got a better handle on this now. Here's a list of things I think that need to happen based on this post and its AMP validation:

• CSS on an AMP must all be included inside a single inline <style amp-custom> tag. Should we just inline all the CSS?
• custom Javascript is not allowed. so any <script> tags should be removed for AMP pages. I'm not sure how extensive Javascript is used on the site, but from what I can tell the two ways you can replace custom Javascript functionality is by using an AMP element instead, or an amp-iframe.
• There are some metadata tags in the footer that need to be removed on the AMP pages

[mkiser]

I was trying to use the Jekyll Amp plugin to do this. Obviously a few things aren't working correctly. There are two files (https://github.com/mkiser/WTFJHT/blob/master/_plugins/amp_filter.rb) and (https://github.com/mkiser/WTFJHT/blob/master/_plugins/amp_generate.rb) that generate the pages, I believe.

I'm guessing this just has to get cleaned up?

[mark-monteiro]

Yeah, I'll make a fork of the plugin and take a stab at those changes

[ElijahLynn]

There is one issue with AMP that I don't know has been resolved yet. And that is once you go AMP it is hard to go back/turn off. I wonder if that is easier now? It wasn't a few months ago.

https://news.ycombinator.com/item?id=13414570

[ElijahLynn]

There are other issues as well but that is the biggest one.

[mkiser]

They've made it somewhat better: http://searchengineland.com/google-makes-easier-see-share-publishers-real-urls-amp-pages-268699

[ElijahLynn]

That is just the URL part of things, which that is a hack, but sorta works. I am talking about once Google has you setup for AMP and let's say you don't like it for whatever reason. How do you turn it off?

I love the idea of AMP and the simple guidelines, I am a chearleader for AMP but I do see that as the one big thing that would stop be from implementing it. I am just throwing this out there, I don't have any experience implementing it yet other than playing with some tutorials and watching some videos on it.

[mark-monteiro]

You should be able to just delete the AMP versions of the webpages and they will eventually get removed from Google's cache. This is from their documentation:

cached content that no longer exists will eventually get removed from the cache, using update-ping or update-cache is faster.

The plugin being used generates an AMP version of each post without modifying the original, so it should be as simple as removing the plugin from the site.

[mkiser]

@ElijahLynn good points.

@mark-monteiro thanks! makes sense.

I think the only requirement from my side is the ability to still capture email sign-ups, which the amp-form component seems to suggest is still possible.

[mark-monteiro]

Twitter embeds will have to be addressed as well. There is an amp-twitter element that can be used for this. We can extend the plugin to handle this in the same way it deals with amp-image elements

[coreyward]

Is AMP really desireable? Article for consideration: Kill Google AMP before it KILLS the Web

[mkiser]

@coreyward I've read the criticism of AMP. Not sure I really understand what the issues is other than a philosophical attack on the principles of the web/internet. Care to expand upon the argument?

[coreyward]

Quoting Daring Fireball here:

It implements its own scrolling behavior on iOS, which feels unnatural,

and even worse, it breaks the decade-old system-wide iOS behavior of being able to tap the status bar to scroll to the top of any scrollable view. AMP also completely breaks Safari’s ability to search for text on a page (via the “Find on Page” action in the sharing sheet). Realistically, I don't know that it's necessary for WTFJHT anyways. Everything about AMP that makes it good (minimal bloat, less tracking, fast loading) you can do with HTML already without straining yourself. AMP just enforces it, which is what you need when you're in an enterprise-scale company that doesn't value end users and you want to deliver something fast.

…

-- Corey Ward

On Sat, Jul 15, 2017 at 3:55 PM, Matt Kiser ***@***.***> wrote: @coreyward <https://github.com/coreyward> I've read the criticism of AMP. Not sure I really understand what the issues is other than a philosophical attack on the principles of the web/internet. Care to expand upon the argument? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#100 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAE9SFlmEkCtKBdA7QrZGsk07SaAfDB-ks5sOSczgaJpZM4N6Twk> .

[mkiser]

Yeah, saw the Gruber takedown on AMP. I get it. Looks like some of these concerns are being or will be addressed by Google: https://www.ampproject.org/latest/blog/amp-roadmap-update-for-end-of-q2/

My goal with AMP (and FB Instant Pages to a lesser extent) is about being featured in the search carousel. It's about reach.

Second reason: I don't have the time rewrite my HTML to conform to anything better/faster than what I have now. I'm already mired in technical debt as it is (in particular #32).

I guess I'm still not convinced that this is as atrocious as people make it out to be, but I'll keep an open mind. My guess is that this doesn't get implemented anytime soon, because I simply don't have the time to do it myself at the moment.

[mark-monteiro]

Totally understand and agree with the concerns about AMP. I also don't think the performance improvement we'll see from using AMP will be all that relevant for a statically generated, heavily text-based site. That being said, implementing AMP should definitely help with prominence in search results; being featured in the results carousel could be huge.

I already did some work on this a few weeks ago and got all the site posts generating as AMP pages. My fork/branch is here: https://github.com/mark-monteiro/WTFJHT/tree/amp-support

There are still quite a few issues that must be resolved to bring the site up to full AMP compliance, namely updating all the stylesheets to use the AMP subset of CSS and eliminating all Javascript usage on AMP pages. I might be able to get to that some time soon, but any other contributions would be welcome as well.

[mkiser]

@mark-monteiro nice! are you rewriting the generator by hand or using one of the jekyll-amp plugins out there?

[mark-monteiro]

Ah, yeah I should have explained that. I forked the existing amp-jekyll plugin to make it work with the site. My fork is here: https://github.com/mark-monteiro/amp-jekyll

I changed the way the generator works so that we can reuse all the existing layouts for the site for the AMP pages. I also added an isAmp boolean variable and modified the existing layouts with a few conditional blocks for some AMP-specific markup.

[mkiser]

This guy makes a pretty cogent argument

https://www.alexkras.com/i-decided-to-disable-amp-on-my-site/

[mark-monteiro]

I've gotten the AMP pages on my fork to a point where they validate successfully. The AMP pages can be reviewed here: http://markmonteiro.info/WTFJHT/ by prepending /amp to any of the post urls (example). You can also get a validation of the AMP markup in the console by appending #development=1 to the URL. Obviously I haven't validated every single page, I've only checked a few so far.

To get the validation this far I've taken the quick route of just removing some elements from the site. We will have to address how to update/replace each of these elements:

• search box in the header
• Mailchimp email subscription
• DonorBox embed

Before we go any further with implementation discussion can we confirm that we actually want AMP support? I understand the problems with AMP and I also don't like the direction that Google is taking with this, but in the end if we are getting increased page views on the site I think that trumps the other issues. If we can make an official decision I would be more than happy to move forward and address the remaining issues. @mkiser, do you want to make an executive decision here?

[mkiser]

Closing. Doesn't make sense to move forward with AMP.