How about Discourse Support Google AMP?

(Nam Nguyen) #1

I think if Discourse can support Google AMP, it would be better for reader, and slow host discourse. and in the future may be help website have higher rank on Google search result.

Google AMP ( help pages load quickly on mobile devices.

Discourse Comment Embed to Support Google AMP?
How can I insert amphtml's rel link into a topic?
(Rafael dos Santos Silva) #2

@riking did a experiment on this

(Kane York) #3

The killer was the fact that amp needs to know the height of every element in advance. The best route IMO is to do something similar, but without the actual AMP script.

(John_Betong) #4

Good idea unfortunately a mammoth task because I think Discourse relies heavily on JavaScript and the AmpProject only allows their own JavaScript Components.


I like this answer, for I see Discourse’s devs on par with Google themselves.

Understanding AMP’s mechanisms of action, their parts, how they work together, flow then becomes a blueprint for Discourse; by adding these little JavaScript parables and lessons to their own Ember.js foundation.

Sam, you already do this behavior elsewhere and for the same reason as I stated above. You did it by creating launcher in lieu of using Docker Compose.

This be only a suggestion–one that, if taken, can be tackled over time (as you all do well already in other areas) and improve Discourse’s perf: the reason. *smile*

(Sam Saffron) #6

These days when I search on mobile I do notice the enormous amount of extra weight Google are placing on AMP content.

I like that AMP stuff is snappy, I very much dislike the way it is confusing and downright pretty evil that this turbocharged content lives on Google servers.

Today Google announced they are making some tiny tweaks to AMP to better expose the origin URL Google Developers Blog: What’s in an AMP URL?

I am super mixed on wanting support for AMP

On one hand, as an end user it is often the fastest content I can get.

On the other hand it is sleazy the way Google places itself between you and your content and then gives extra bonus points for exposing content this way.

I am not particularly concerned about the “technical” cost of implementing AMP, much more concerned about if it philosophically belongs in the product and is something we should be encouraging.

But… Google seem to be pushing really hard to get people on the AMP train.

(Erlend Sogge Heggen) #7

This does indeed appear to remedy my primary concern with AMP, but I’m still not very comfortable with a vendor-specific standard.

Discourse also doesn’t stand to gain as much from AMP as the average media outlet does, since in our case the amount of “dumbing down” we need to do in order to serve AMP pages means you’re probably only using 5-10% of Discourse’s interactive features. I’d love to serve these types of user segments, but the fact remains that they’re an increasingly smaller minority.

My hope is that AMP eventually turns into a globally recognised standard for low-bandwidth, more secure (because simpler) web content, the same way SPDY paved the way for HTTP/2.

Considering Google rewards speedier pages in general, I’d imagine we stand to gain much more from implementing Service Workers before we revisit AMP.

(Edison) #8

Will discourse support GAMP?

(Sam Saffron) #9

No idea what a GAMP is but, as the days pass by more and more people are getting more and more dissatisfied with AMP

(Edison) #10

ok… but I need AMP, so do you have an idea?

(Glenn Sims) #11

(For anyone and those interested in #ux)
Perhaps Discourse could use AMP with topics, so that when they’re loaded you could easily scroll through the conversation (in a read-only format?), but then add an “Access Mobile Site” button on the page somewhere so you could like/reply in a different tab? That way it would just be an up-to-date snapshot of the actual topic.

Then again, the standard mobile interface works really well for these platforms…I’ve had no issues with it recently (or…ever…)

(Matt Palmer) #12

No, you really, really don’t.