Live data from Hacker News

How fast is AMP really?

timkadlec.com

121–130 of 167 posts

Re: How fast is AMP really?

#121

Earlier quoted context omitted.

You must be American then because that's the American format. Different countries and languages have different format of numbers. That's one of the most common issue in internationalization. If you send a bill for a 5,000 dollars service, expect your international customers to send you back five dollars. The comma is broadly interpreted as the decimal separator.

I think it's less to do with country and more to do with language. All English speaking countries use the comma as separator, and the decimal point as the decimal separator. So, if you're reading an article that is written in English, from context you know that decimal points will be used as decimal separator and comma will be used as digit grouping. No confusion. However, confusion happens when non-native English sp…

The locale is the country and the language.

American English is not equivalent to Australian English or Canadian English.

Re: How fast is AMP really?

#122

Earlier quoted context omitted.

You must be American then because that's the American format. Different countries and languages have different format of numbers. That's one of the most common issue in internationalization. If you send a bill for a 5,000 dollars service, expect your international customers to send you back five dollars. The comma is broadly interpreted as the decimal separator.

Not just America uses dot as the decimal separator, see: https://en.m.wikipedia.org/wiki/File:DecimalSeparator.svg Blue uses the dot, green uses the comma. By population dot wins (since India and China use the American style).

The map is largely inaccurate. Things got very divergent in the last decades with the rise of computers.

There are hard limitations in hardware and software that people have to live with. A keypad only has a dot key.

Re: How fast is AMP really?

#123
The most infuriating part of AMP for me is that I can't count the number of times I'd read an AMP version of an article, and graphics in it were just plain missing without any heads up. Why newspapers and the like would gimp their own work like that is beyond me.

Re: How fast is AMP really?

#124

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{visi…

Okay this is a pretty bad thing to do.

Re: How fast is AMP really?

#125

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.

The AMP team actually got up on stage and tried to tell a bunch of developers that sites could be converted in a couple of hours. Worst developer outreach I’ve ever seen.

I work for a major news publisher. Rendering is tied to legacy systems with esoteric business logic, journalists could embed any one of hundreds of first or third party embeds, and many pieces of content embed arbitrary HTML directly. It seems crazy, but this is how a lot of news organisations are dealing with content.

AMP is designed to fail on any error, is incompatible with existing HTML and CSS, and to do CSS inlining right means completely rewriting existing build pipelines.

In a Google world implementing AMP wouldn’t be that hard; code is generally high quality and you control the stack. In media organisations responsibility for domains might extends between different (poorly communicating) teams and many critical components are handled by third party systems. Doing something simple like implementing AMP’s custom CORS logic was a nightmare.

Building an AMP site is not hard. Building an AMP site that runs on legacy publishing systems IS hard. This is something the AMP team should understand, but they seem incapable of accepting any sort of feedback.

Re: How fast is AMP really?

#126
post #87

So nowadays 61 requests per page load is considered an "accelerated" page? Might not be so bad with http2 but still wow. Maybe publishers should start working on that number if they want actually faster web pages.

It depends on if you pack your data or not, really

With simple development on a moderate website you might have a couple of html resources, a few css files and some js files to fetch, not to mention all the media (images, videos and audio).

It's easily half that just by doing sane development where you split functionality into files and if your site is media rich it's not surprising at all.

Re: How fast is AMP really?

#128
post #5

So basically Google could get 90% of what AMP provides without AMP itself, because the magic is in the caching and forcibly reducing the ad junk the page loads. Does that about sum it up?

yes they basically broken internet the same way it was broken with wap, including broken sharing and deeplinking, for no good reason at all... well except to run amp you need to run it on their resources and all your users are now profiled across all websites...

Re: How fast is AMP really?

#129
post #106
post #10

Answer: not as fast as the D lang forums. https://forum.dlang.org/

Truly impressive is https://www.gov.uk/ A government site, lightning fast, try the search! No bullshit design.

My hope is that a trend towards server side, text only sites becomes a thing. You can make things beautiful with typography, and layout, without superfluous pictures and designs.

Re: How fast is AMP really?

#130

Earlier quoted context omitted.

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?

Indeed. "Search iframe hack". That's basically all you need to know about their "instant loading" and "caring for speed".

See, they are not really optimised for speed. They are optimised for being pre-loaded from Google's CDN in search results. Or, as OP's article says: "the incentives being placed on AMP content seem to be accomplishing exactly what you would think: they’re incentivizing AMP, not performance"

Actually recently I wrote quite a long comment about what's wrong with AMP: https://news.ycombinator.com/item?id=16549828 that covers that, and more.

Post reply on HN