Live data from Hacker News

How fast is AMP really?

timkadlec.com

111–120 of 167 posts

Re: How fast is AMP really?

#112
Heh. 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 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?

#113

Earlier 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.

Isnt that going to depend on your publishing platform?

Re: How fast is AMP really?

#114

Heh. 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 instantaneous.

Re: How fast is AMP really?

#115

Earlier 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.)

Okay so lets _actually_ look at the market when judging AMP and deciding what Google's purpose of it is.

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?

#116

Earlier 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…

> - would be implemented in a way that favours speed, not placing in search and inside Google's ecosystem

How? How do you 'load' pages instantly without their search iframe hack?

Re: How fast is AMP really?

#117
post #114

Heh. 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…

Okay so this actually goes straight to the heart of everything that's wrong with the web development communities obsession with PWAs. The technologies behind PWAs are fine, but people need to learn how to properly assess these buzzwords and learn if their suitable for the particular use cases of their site.

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?

#118
One detail which I feel must be mentioned: if you block `ampproject.org` by default -- directly or by blocking 3rd-party javascript by default, -- you will be "punished" with a 8-second delay before the page becomes visible.

This 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?

#119

Stopped 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…

Isn't it in Google's best interest to list the ad heavy sites first? They don't receive any commission sending users to your ad free site, but they'll earn 32% of AdSense profits from your competitors.

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?

#120
post #108
post #106

Earlier 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/

The uk gov website is a blessing, now leaving in the UK I can compare with the french ones and those are not playing in the same league.
Post reply on HN