Google AMP (https://www.ampproject.org/) help pages load quickly on mobile devices.
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.
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*
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.
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.
No idea what a GAMP is but, as the days pass by more and more people are getting more and more dissatisfied with AMP
(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…)
I don’t think anyone has properly identified a use case yet.
AMP sounds nice on the surface, but even light research uncovers a litany of issues, particularly if you decide to try and disable AMP down the line.
AMP gets placement priority, but it’s not a magic SEO bullet for communities. Discourse already has a snappy mobile experience, AMP can’t beat that. If it doesn’t add something meaningful then why use it?
I have done my own testing with AMP on my site, and haven’t really seen much advantage in terms of driving more traffic to AMP pages. After splitting up my pages into AMP and non-AMP I found the sum of traffic to the two versions of the pages roughly equalled what my traffic was before the split.
To be honest, I never analyzed the results there, but I do run adsense on both versions of the pages. This is only one section of a very large site, so I never took the time to parse out the ad revenue just to that area before and after.