Answer: not as fast as the D lang forums. https://forum.dlang.org/
How fast is AMP really?
111–120 of 167 posts
Re: How fast is AMP really?
#112The Twitter Lite PWA, arguably the 'flagship' PWA ("developed in partnership with Google"), takes longer to display tweets for me than regular desktop Twitter.com, and the old 'static' mobile twitter site (which loads INSTANTLY[1] you can only get with user agent trickery)
[1] Just did some testing. According to Chrome Dev Tools, old Twitter Mobile displays tweets in 124ms. PWA Twitter takes greater than 1.4s (it stopped recording screenshots), 2s according to a screen recording https://gfycat.com/PlushThornyIcefish
Re: How fast is AMP really?
#113Earlier quoted context omitted.
Publishers go through the trouble in order to get the boost in Google's rankings. As an iOS user I find AMP to be quite buggy, and AMP versions of pages like reddit are borderline non-functional. I don't prefer it at all.
It's a trouble of writing template once though and it is not that much work. I worked on this at my previous employer and it was alright, little frustrating but once it was done, it was done until you redesign the pages. Disc: Googler but nowhere close to AMP.
Re: How fast is AMP really?
#114Heh. This reminds me of a recent pet peeve and observation of mine: progressive web apps are not faster. The Twitter Lite PWA, arguably the 'flagship' PWA ("developed in partnership with Google"), takes longer to display tweets for me than regular desktop Twitter.com, and the old 'static' mobile twitter site (which loads INSTANTLY[1] you can only get with user agent trickery) [1] Just did some testing. According to C…
Re: How fast is AMP really?
#115Earlier quoted context omitted.
> On the most basic level, it isn't motivated by speed. So you think Google has no interest in making search results load faster and this factor is just a ploy?
There are employees there who probably buy the idea that it's motivated by speed, but the project wasn't created primarily for speed, just like Chrome wasn't primarily motivated by the need to make a better browser. (Both are about advertising.)
We have a mobile web where publishers are very bad at making websites. The fill them full of various trackers, ad networks, bad practices and slow them down. This is bad because it makes the web a bad experience on mobile and drives users into native apps.
Facebook and Apple 'realised' this as well and launched their own proprietary solutions for their native platforms (for slightly differing reasons): Facebook had Instant Articles and Apple had their News app, all entirely closed platforms operating outside of the 'web' and without Google. This is a fundamental threat to Google as a business.
If you're in Google's shoes, what do you do? The web standards just don't provide a compelling enough solution to compete with FB Instant Articles and Apple News, which get to leverage being native apps, defining their own formats (fun fact: Apple News articles are JSON!) and preloading content however they Desiree.
AMP was their solution - based on 'open web standards', combined with a shitty hack to preload content when coming from their search results. They said from the beginning their taking the efforts of their AMP project and proposing standards for it, and that's what they're doing.
You can't properly judge Google's AMP efforts without first looking at what they were up against from Facebook and Apple.
Re: How fast is AMP really?
#116Earlier quoted context omitted.
Where does this say AMP wasn't motivated by speed? From the link: > We started working on AMP because we were seeing the mobile web feel clunky and slow, falling behind the tightly-integrated, highly-optimized user experiences that walled garden platforms can offer. Yet we also knew there wasn’t a fundamental technology problem: you could build great experiences on the web with the right knowledge, resources, and man…
I was actually just pointing out the "There are employees there who probably buy the idea that it's motivated by speed" :) If the project was motivated by speed, it: - wouldn't be implemented in a way that breaks Google's own speed guidelines - would be implemented in a way that favours speed, not placing in search and inside Google's ecosystem - would be open to input from the web community, not in through an entire…
How? How do you 'load' pages instantly without their search iframe hack?
Re: How fast is AMP really?
#117Heh. This reminds me of a recent pet peeve and observation of mine: progressive web apps are not faster. The Twitter Lite PWA, arguably the 'flagship' PWA ("developed in partnership with Google"), takes longer to display tweets for me than regular desktop Twitter.com, and the old 'static' mobile twitter site (which loads INSTANTLY[1] you can only get with user agent trickery) [1] Just did some testing. According to C…
PWAs aren't literally faster — caching aside, they load the same data and it takes the same amount of time over the same connection. But there is a percieved performance boost if the PWA uses caching and preloading intelligently. The first load might take a little longer, loading the first tweets will take just as long, but scrolling through the timeline should be faster and page transitions can be almost instantaneo…
The main use case of Twitter is to look at your timeline, yet Twitter Lite somehow screwed that up and made it slower, even on subsequent loads. Not only that, the particular implementation provides arguably a worse experience, doing things like showing three different 'loaders' on the path to the timeline (Twitter icon 'splash screen' (wtf, I thought this was all preached?), spinner for the whole 'app', and then spinner for the timeline).
Reminds me a lot of people's obsession with Webpack and code-splitting - I'm sure a huge majority of projects will find >75% of their JS bundle weight being their dependencies.
Re: How fast is AMP really?
#118This is an entirely artificial delay, implemented through an inlined style CSS animation in AMP-based pages:
animation:-amp-start 8s steps(1,end) 0s 1 normal both}
@keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}
I can't see any good reason for such delay. If you are not aware of this 8s delay, you might be misled into thinking the page is broken and that `ampproject.org` is really needed, while the page renders just fine without it, except for the delay.Example: https://ampbyexample.com/
Re: How fast is AMP really?
#119Stopped using AMP. Created a site in pure AMP. All competitors didn't use AMP then (1 yr ago). My site was the fastest, didn't have any ads, was the lightest, the most beautiful, had the best UX flow. SEO-wise my site still doesn't list on the keywords which are in H1 and the page title but all the crappy, non-AMP, megabytes big slow-loading, ads-heavy competitor sites are still in the top ten SERP. Guess that even G…
Now, I don't believe that is actually occurring, but it's one of the many ways that our interests and Google's interests do not align.
Re: How fast is AMP really?
#120Earlier quoted context omitted.
Truly impressive is https://www.gov.uk/ A government site, lightning fast, try the search! No bullshit design.
Yes, I'm always impressed when I have to deal with it. Truly amazing to find such competence in a gov site. A lot of that is done in the open, too. https://alphagov.github.io/