Hacker News new | past | comments | ask | show | jobs | submit login
How fast is AMP really? (timkadlec.com)
190 points by niutech on April 1, 2018 | hide | past | favorite | 163 comments



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/


This kind of dishonest design is all too common now. If you pull back the curtain, you can find all sorts of other ways that the user is gaslighted.

One example is that the youtube mobile website will prevent you from playing a video in the background now. It didn't used to. This is to "encourage" you to use their Youtube RED app.


Okay this is a pretty bad thing to do.


I'd assume that's probably done to prevent FOUC while it's waiting for the JS to load. What do you get if you override that style?


If using uBlock Origin, you can try the example page with that cosmetic filter:

    ampbyexample.com##body:style(animation: none !important;)
One thing for sure, the result is much more pleasant than having to wait 8 seconds if one does not want to un-block 3rd-party javascript from `ampproject.org`.


I suppose webmasters could add the inline css

   body{animation:none !important;}
On mobile so I haven't had the chance to test


I should have included this in my first comment: this is a requirement from AMP to include the animation[1]:

    AMP HTML documents must contain the following boilerplate in their head tag. [...]
    <style amp-boilerplate>body{-webkit-animation: ...
[1] https://www.ampproject.org/docs/fundamentals/spec/amp-boiler...


Answer: not as fast as the D lang forums.

https://forum.dlang.org/


Really impressed! Took a quick look at page source, a couple of observations on why it's fast:

1. Plain, small html - page size is 6.1 kb (request took 700ms for me, I guess the server side rendering is pretty fast too), css file 11kb; note html, css and js are all properly minified

2. Font-awesome and jquery at the bottom of page to not block page rendering, both loaded throught cdn (although a fallback jQuery exists)

3. Site's own js is only 5.6k

4. No large static assets, only image on page is an svg dlogo

5. Did not check with js off, but saw hints of decent fallbacks for no-script


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.


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.



Not just a site too. Almost every significant government service is being migrated to that domain, linked from that site and designed to the same standards.


Holy crap. The internet on a phone can feel like this?!


I designed an API first forum written in Go, front-end in Python, that feels in the same ball park fast even for image heavy pages: https://www.lfgss.com/

Aside from making pages with few database queries, it's about removing all 3rd party dependencies and going same-origin to speed up the front-end too.

The 2 biggest things that slow me down are auth and analytics, but on the latter I trust you use an adblocker, and for auth I have a plan.


It didn't seem that fast to me compared to other sites, then I realized I'm running Firefox with uBlock while the rest of you are probably on Chrome.


This seems to rather be a case where it just happens to be crazy-fast on Chrome, whereas it does not happen to be on Firefox.

Might be Chrome pre-loading content that's behind links, which Firefox doesn't do for security, privacy, battery and not-eating-all-your-RAM-ery reasons.

I tried enabling preloading in about:config, which didn't seem to make a difference, but I'm not sure, if I did that right or if that feature is even functional at the moment. It's an experimental about:config flag after all, not a production feature.

Then again, this very much seems to be the exception on Chrome, too, so it's not exactly a reason to stop enjoying the internet without ads.


On a phone? Last time I tried adblocking on a phone I was super irritated by it. Some proxy setup that never quite worked and felt like it slowed everything down.


Android Firefox supports many of the desktop extensions and uBlock Origin works perfectly fine in it.


On iPhone you can use a safari content blocker like purify or 1blocker. On Android you can use Firefox and ublock.


Adblock on firefox on android just works.


Unless it's a Google Pixel device. Firefox on the Pixel infuriates my wife, it slow and crashes a lot. She's baffled because she watches me cruise happily with it on my Nextbit Robin.


Try Brave browser. It's a modified version of Chromium with seemless ad blocking by the co-founder of Mozilla.


Can't edit my post since it's been 3 hours, but I'm very curious why I was downvoted. Was there some negative news around Brave that I missed?


Not aware of any negative news.

I presume it was because prior to my comment, no one had yet explained to the guy that you don't need to deal with such a proxy setup to block ads in browsers.

So, your comment sort of made it sound like ad blocking not being too great for him, was because of Firefox and that Brave would be better at it, whereas it really just was because of a missunderstanding of the guy.

Besides that, Brave is also controversial. As much as some people have screamed bloody murder, because Eich's free speech was supposedly taken away by journalists/SJWs/Mozilla or whoever, a good other percentage of people do think that his donation was wrong and that he should have reflected on it and distanced himself from this (past) opinion.

Furthermore, many people think him basing it on Chromium was wrong. No matter how pissed off he might've been at Camp Mozilla, and no matter how much journalists would've slandered him again, if he started supposedly trying to work with Mozilla again by starting a fork of Firefox, there's just no way that you can work for 17 years on anything and then a few months later go "Actually, this competing product is better".

Chromium being Google software and him trying to sell his Chromium-based browser as privacy-friendly does not help it either. There's millions of lines of code in there with tens of thousands of design decisions, all made by the biggest data broker on the planet. You're not patching all of those out in any reasonable time frame.


I have uBlock.

Chrome is faster than FF with real world applications.


If you really think that's fast (and you're on the west coast...), try: https://www.changedetection.com/directory.html

Sadly it seems you can't register new accounts anymore because of their merger(?) with VisualPing, but their old site still functions for those with accounts and the speed is mindblowing as you can see there. I feel every website should strive to be like this.


And not NEARLY as fast as example.com!


Nice! The last time I had that fast feeling was with https://changelog.com/, written in Phoenix (Elixir).


lobste.rs is usually pretty fast but they have a silly and annoying April fools thing going on right now. I once did a dive into their CSS to see how they were doing collapsible tree style comments without any JS whatsoever.

https://lobste.rs


Wow, that site indeed feels fast! Is there a writeup about how it’s done?


And the software isn't just rendering the forums. It also simultaneously handles email, Usenet, and IRC relays.

Also, it runs on SQLite. I found that the most surprising of all.

Web development in D is incredibly fun. I love that I can compile HTML templates into machine code (which of courses catches template errors as compiler errors), I love how fast the result is, I love that there is a very lively collection of D packages around web development. In fact, the D package manager, dub, started as a package manager for Vibe.d, the main D web framework.


There's a bit of discussion about it here: https://news.ycombinator.com/item?id=3592769

Source of the site is here: https://github.com/CyberShadow/DFeed


You can find the source on GitHub it not only runs a web server... It runs an IRC bot too and an NNTP server as well so you can download all threads and post with a newsreader / usenet client.


The first point in the article is the dead killer of AMP for me. My mobile provider gives me very little monthly data, I've stopped using AMP because preloading the AMP results is eating through my cap, with images disabled.

Without preloading, AMP is slower than the non-AMP version of the same webpage with a simple script blocker. And usually causing more traffic too.

I hope Google refrains from bullying website owners into making the internet a worse experience for people without 1GB+ data plan.


No. AMP is much faster even without preloading. Here is an example of a random article on CNN: https://www.webpagetest.org/video/view.php?id=180402_4583919...


This is not my experience. AMP is consistently slower than normal desktop pages or mobile pages when offered. I've measured this myself on my own phone countless times.

CNN is also probably one of the worst offenders, so the example is rather cherry picked nor does it represent my usual browsing in any way.


how do you disable it?


I tap "Request Desktop Page" when I use google search and I mostly rely on search engines that don't pull the AMP crap at all.


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?


Which is made clear in the AMP documentation itself.

The AMP project isn't pretending they're bringing something unprecedented to the web... they're very open about the fact that most of the things you need to do to make your site "AMP compatible" are just speed-conscious best-practices (like only using CSS transitions that have hardware acceleration, or async loading of assets).


Let's see how open they are:

"The project enables the creation of websites and ads that are consistently fast, beautiful and high-performing across devices and distribution platforms."

"Web pages and ads published in the AMP open-source format load near instantly, giving users a smooth, more engaging experience on mobile and desktop."

That's directly from the AMP's project site. Those statements are half-truths at best.


Yes, except how do you propose to implement caching and stripping out the ad junk without AMP?


HN is seemingly incapable of rationally discussing AMP.

AMP solves a very real problem, which is that our web stack is open to enormous abuse because it is sometimes too powerful for its own good. While we could make simple HTML that is as fast (of course we can), the reality is that we don't, and many don't often for tragedy of the commons reasons. And the counter-argument that search rankings should just favor this -- e.g. just promote speedy pages -- ignores that abuse would be absolutely rampant (and the other argument -- just run a layer of ad blockers -- completely misses the point). AMP isn't just an ideal, it's a strict set of enforced restrictions.

In previous discussions I've noted that we need an HTML lite to counter AMP, not just the same head-in-the-sand strawmen about how it serves no purpose. An HTML lite that is a mode in the browser, enforced on the DOM and JavaScript. The anti-AMP rhetoric makes it impossible to discuss rationally.


> many don't often for tragedy of the commons reasons.

Google are some of the major culprits driving the creation of an unpleasant web experience loaded with tracking and advertising cruft, and now they're pushing this alternative format to supposedly fix the damage they wrought. That's why people are salty about AMP.

It's an imperfect analogy, but imagine if some company had torn up the roads near your house by driving their heavy cargo trucks over it, and now you're irritated by the potholes, that same company says, "Great news! If you just buy our special tires and shocks and install them on your car, you'll have a smoother ride with fewer bumps from potholes!"


Google has pushed speed in virtually everything they've done since day one. Asynchronous, deferred scripts. Always outrageously fast loads. Simple, lightweight ads. They even built a browser to try to push speed.

I despise ads, but blaming Google for the situation that we're in is seriously missing the mark.

Google wants the web to succeed, for their own selfish reasons. They don't want it to become a wasteland of zombie scripts, cryptomining, pop-overs, and abuse (which tends to be even worse on mobile, as an aside, abusers knowing that mobile users often have fewer tools). They have been pushing pro-web policies since the early days. AMP, as cynical as people can be about it, is one of those.


Google monetized links. They were the ones who showed you could make serious money from tracking and marketing to people on the internet.

Your argument is "Google is more technically competent at doing all these crappy things than Google's imitators", but Google was the trailblazer who proved there was big money in ads and scripts that do more than blink a banner.


No, that isn't my argument, and given that you're busy taking swipes at absurd strawmen I think this conversation is done.


>In previous discussions I've noted that we need an HTML lite to counter AMP

this is essentially what the AMP team is building - there's a few proposed standards that have come from AMP, with respect to making pages cacheable and pre-renderable.


Make performance (not AMP) matter in search rankings and websites would immediately start getting faster.



Good to see, however this still hasn't started, it's far too late after AMP, and only affects "a small percentage" as quoted. It also doesn't give the special carousel placement in the results page, which is only available via AMP.


I believe it already does actually

(I work at Google but not in search so I could be wrong but I believe they talked about this during orientation)


Speed has been a ranking factor in desktop SERPs for years. It was only recently announced as a ranking factor for mobile too (but we knew it was coming).


with free market!

now, seriously, I do that just fine with an ad blocker.


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


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


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.


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.


In case of Twitter PWA, it loads twitts asynchronously, so they seem to load longer, but the whole PWA loads much faster in total: https://www.webpagetest.org/video/view.php?id=180402_08c5318...


Worth noting that it would be insane to preload content that didn't pass a strict filter akin to that of AMP.

Each Google search would download dozens of MBs and produce a significant CPU workload, both resources being precious on mobile.

Perhaps it was a communication issue: AMP should have been named/marketed "preloadable pages" rather than "fast pages".


AMP is not about preloading in the first place. It's about the fast CDN. Let's compare any NYT article in the AMP and standard HTML formats: https://www.webpagetest.org/video/view.php?id=180402_16d7083... - AMP loads much much faster.


Not sure of what does webpagetest is showing evidence of. It could be anything... for one thing, AMP versions are much leaner so naturally they will load fast - even with no dedicated CDN at all.

Cloudflare and Fastly should be more than sufficient CDNs?

Admittedly, maybe the AMP CDN is an easier one to set up for the masses, but other than that I bet they all have about the same performance.


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.


A very low quality article. The whole point of AMP is to define a restricted subset of HTML that is safe to prerender and still provide working analytics to the publisher. When you prerender, the advantage of AMP is substantial as it is impossible to beat a user experience of instant, which is why users prefer it and why publishers go through the trouble of implementing two web versions of their web pages (in addition to Facebook and Apple News non-web versions).

The point of the AMP cache is not for CDN speed, as the author mistakenly believed and measured, but for same-origin or CORS prerender, and Google is not the only implementer.


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.


It is absolutely not that simple. We are a marketing company working with hundreds of publishers and this is a constant struggle.

It's splitting whatever little dev time they have on yet another format that adds nothing to the already universally accessible "web" version.


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.


It’s a continuous pita as it’s buggy as hell and as a publisher we are the ones who get blamed.


Isnt that going to depend on your publishing platform?


AMP is a cancer on search results. The purpose of a search engine is to provide the best links it can to content related to a user’s search. The search engine should not be providing the content of the search result as a primary link. Having a backup cache of the link is fine in case it changes or disappears. It’s the responsibility of the original site to be able to serve its visitors.


You're right! Users are looking for something very specific when they search. Generally, they are looking for a particular bit of information. Sometimes the best way to get that is to click through to someone's site and read an essay.

At other times, well, it's possible that it might be the best experience for the user to have information presented to them immediately. It's definitely negative for people whose entire business model depended on those clicks, though. I understand their pain, fear, and anger.


Most users think otherwise. Most users prefer results that load instantly, which is why the dominant search engines in the US, Japan, China, and Russia as well as the dominant short message sharing services in the US and China all provide special support for AMP results.


It's hardly surprising that the dominant search engine in the US and Japan uses AMP, since that search engine and AMP are products of the same company.


The dominant search portal in Japan until very recently was Yahoo! Japan, which runs its own AMP cache and is a product of Softbank. The dominant search engine in the US is Google. These two companies hold no significant investments in each other.


I think the point of AMP is it gives Google a simple and reliable way to detect fast rendering pages that render well on mobile in a way that can't be easily gamed. When you allow unrestricted usage of JavaScript that's changing page content, loading styles etc. for example, detecting pages like this is more difficult.

You can write performant pages without AMP but how would Google reliably detect pages like this?

I'm not saying AMP is the best solution and I can see why some developers have objections against it but I think I understand what it's trying to do.


> I think I understand what it's trying to do.

It's appifying the WWW on Google's domain and allowing them to dictate how sites are monetized. On the most basic level, it isn't motivated by speed.


Fast page loads means a better UX on the web.

Better UX on the wide web means people enjoy using Google more. If I'm using Google, it means I want to find something. If Google has encouraged the entire web to be faster, I will find what I'm looking for faster.

People using Google and enjoying it is good for Google.


> Fast page loads means a better UX on the web.

Not necessarily. AMP has terrible usability. For people who block 3rd party JS from loading, AMP pages take 8 seconds to load.

AMP will hurt publishers in the long run:

- giant back button to take users back to Google Search instead of deeper into your site

- broken referrers

- bad inbound links (that point to google.com)

- someone else dictates your monetization strategy

- someone else limits how you publish online

- not faster than DIY optimization

- etc. https://www.google.com/search?num=100&q=amp+sucks


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


> 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

You have evidence of these two claims or you're speculating?


AMP tech leads especially. For a quick glimpse you can read this: https://amphtml.wordpress.com/2018/03/08/standardizing-lesso...


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 management support. Thus we set out to create a framework that would provide a well-lit path to building great web-based experiences: AMP would be well documented, easily deployable, validatable, and opinionated about user-first principles.


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 entirely opaque process inside Google


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


What's your point? Of course the user gets superior performance - you tap a link and it 'loads' instantly.


My point is: AMP was never really motivated by speed. Proof is in all other discussions around AMP, the OP article, the links in the comment I linked to etc. etc.

The only reason AMP is perceived to be fast/instant is because Google lies.


> Google reliably detect pages like this?

The same way it reliable detects the content of the site and everything else. Take a snapshot and keep the latest history.

You can easily change the content on a page with javascript so Google still needs to load everything to get an accurate representation. Since there are plenty of tools already (including Google's own) that measure page loading speed, it would be trivial to combine them into a performance score for search rankings.

If speed was actually made into a strong signal, major websites would've become as fast as AMP within months.


> The same way it reliable detects the content of the site and everything else. Take a snapshot and keep the latest history.

Wouldn't benchmarking page speed accurately for all pages on a website for a variety of screen sizes on a regular basis cost significant resources? If it's so easy, why are they not doing this already?

What I meant about AMP is that when a page validates as an AMP page you know there's certain things it can and can't do. This makes the task of identifying performant pages significantly easier.


Benchmarking is just logging the time taken during the process of waiting for the content to load, which is already happening to index the page. No special framework necessary.

They aren't doing it because AMP gives far more data and keeps first party cookies because of the cached domain.


> Benchmarking is just logging the time taken during the process of waiting for the content to load

I don't think it's as simple as you make out at all. Compared to just downloading the HTML and checking its contents, this requires executing JavaScript and rendering content in an actual browser which is orders of magnitude slower and more resource intensive.


That's exactly what happens already because javascript can also change content, including all the React/SPA sites now. They've been doing it for years: https://webmasters.googleblog.com/2014/05/understanding-web-...


And can be gamed by detecting Google and serving different content to users that if slower.


Nope. The point of AMP is for Google to boost certain high-traffic pages with ads in its search results. Because ads == revenue.

Google already has the tools to detect fast rendering pages, though they've more or less stopped talking about them after the introduction of AMP.


You might not realise how much AMP you come across every day.

Your web browsing isn't it at all.

If you are on an Android phone go install NetGuard and take a look at the logs.

There are a few domains that come up for almost every app:

1. graph.facebook.com

2. graph.accountkit.com

3. .crashlytics.com

4. .ampproject.net

5. .segment.io

AMP Project is up there. The majority of the apps on my phone now do their content via WebView + AMP.

In this AMP have found their niche.


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.


If you want to test how fast are AMP pages compared to full pages, check out the AMP Browser Extension: https://chrome.google.com/webstore/detail/amp-browser-extens...


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 Google stopped giving AMP sites any special rank power except they are news sites (then you will see them probably in the carousel but only if they are accepted with Google News).


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.


How fast could google.com be if they trimmed the JS fat?



Thanks. And I have a feeling that it would be much worst (aka better) for a mail.google.com inbox page, even if you keep the useful Javascript. But their javascript is so obfuscated that it is not too easy to test. One time I extracted a simple feature for gmail's javascript... it was fun (probably would be easier for a programmer though)


gmail has a basic html mode that is lightning fast.


Do you want to hack into your spouse's phone remotely without touching his or her phone You can hack into any devices to access facebook , whastapp , text mssg , call logs etc to know who they have been talking to and if they're cheating on you remotecyberhacker@ gmail com he's the fastest,reliable and cost-effective you can ever come across cos his name has never been SOILED , in shrot....he's the best working for me . text/call ; + 1 3 4 7 89 93 01 7 whatsapp ; +1 267 52 6 53 4 6


i tried to turn these tables into graphs because charts of numbers weren't doing much for me. but i suck at spreadsheets, so i don't know how to label these: https://docs.google.com/spreadsheets/d/1ZFWiqXesq8SlOZ3uW9Om...

(the bars are raw/cached/canonical, and the groups on the X axis are min/max/median/90th)


Alternate answer : not as fast as Dan Luu website.

https://danluu.com/


it's a pain to read it on desktop without reader mode. the width is just too wide.


I'd put the blame on crappy user-agents that can't present a readable view by default for a reasonable, semantically marked up document. Arguably that is their raison d'être, and they fail horribly at it.


Is it really hard to use the whole of my screen? I'm well aware that modern websites have to scale to lots of different screen sizes. My laptop is a 17" job so why the blazes do I only get to see a block of text using the middle third of it? It looks shit. I'd probably have to peek under the lenses of my specs on a smaller screen. I spend far too much time using CTRL + these days.


See http://bettermotherfuckingwebsite.com/ for the reasoning behind this trend. Line width, namely the number of characters shown in one, is regarded as a prime factor in readability, which I personally agree with.


it's funny how so many people use to ridiculed ColdFusion and Asp.Net WebForms for "re-inventing" and "polluting" HTML with their custom tags and server components respectively. This is exactly what AMP is.


Don't use AMP... Aweful for everyone involved, except Google.


Maybe just once tell the readers what AMP stands for.


AMP stands for Accelerated Mobile Pages.


As someone with limited mobile data, not cool, Google. This after Google created a cell carrier for people who use less data (Project Fi) and want per-gb billing.


Please stop saying "performant" when you mean "fast". If you just mean "fast", say "fast".


I built a simple bash/javascript to get the AMP URL for a given URL, did reduce my data usage by tons. Look here:

https://developers.google.com/apis-explorer/?hl=en_US#p/acce...

   curl -X POST -H "Content-Type: application/json"  -d "{urls: ['$1'] }" 
   https://content-acceleratedmobilepageurl.googleapis.com
   /v1/ampUrls:batchGet?key=YOUR_AMP_API_KEY
For android app use:

       public static String GET(String url){
        String result = "";
        String ampString = "https://content-acceleratedmobilepageurl.googleapis.com/v1/ampUrls:batchGet?key=YOUR_AMP_API_KEY";
        HttpURLConnection conn = null;
        try {
            URL ampurl = new URL(ampString);
            conn = (HttpURLConnection) ampurl.openConnection();
            conn.setReadTimeout(10000);
            conn.setConnectTimeout(15000);
            conn.setRequestProperty("Content-Type", "application/json");
            conn.setRequestMethod("POST");
            conn.setDoInput(true);
            conn.setDoOutput(true);

            JSONObject jsonObject = new JSONObject();
            jsonObject.accumulate("urls", url);

            OutputStream os = conn.getOutputStream();
            os.write(jsonObject.toString().getBytes("UTF-8"));
            os.close();

            InputStream istream = null;
            istream = conn.getInputStream();
            InputStream in = new BufferedInputStream(istream);
            if(in != null){
                result = convertInputStreamToString(in);
            }
        }
        catch (Exception e) {
            Log.d("News exception", result);
        }finally {
            // Close Stream TODO
            // and disconnect HTTPS connection.
            if (conn != null) {
                conn.disconnect();
            }
        }

    private static String convertInputStreamToString(InputStream inputStream) throws IOException {
        BufferedReader bufferedReader = new BufferedReader( new InputStreamReader(inputStream));
        String line = "";
        String result = "";
        String id = "";
        String ampUrls = "";

        while((line = bufferedReader.readLine()) != null){
            result += line;
        }
        inputStream.close();
        try {
            JSONObject jsonObj = new JSONObject(result);
            // check if jsonObj has ampUrls string - how to do it?

                if (!jsonObj.isNull("ampUrls")){
                    JSONArray contacts = jsonObj.getJSONArray("ampUrls");
                        for (int i = 0; i < contacts.length(); i++) {
                            JSONObject c = contacts.getJSONObject(i);
                            id = c.getString("cdnAmpUrl");
                            }
                    }

            } catch (JSONException e) {
                // TODO Auto-generated catch block
                e.printStackTrace();
            }
        return id;

    } //end of convertInputStreamToString


You can try the AMP Desktop Extension, which uses this API: https://chrome.google.com/webstore/detail/amp-browser-extens...


A suggestion for the author: Please avoid commas (or dots) as thousands separators. My brain parses "4,604ms" as "about four milliseconds", which would be amazing, but is very much not what you mean.

ISO recommends half-width spaces as thousands separators to avoid this kind of confusion. Also, I think thousands separators can just be skipped if your numbers are only four or five digits wide.


This seems to be a European issue perhaps? I've never once been confused by a comma in a number. In fact, it makes them easier to read, not harder.

Can you describe your experience with numbers? Are you a mathematician or in some other scientific field?

Also, it seems odd to make a request like this of a (seemingly) random author on the internet. It feels similar to making a demand to change writing style. (ie, oxford comma, em-dash, etc...) Do you think it's reasonable to ask someone else, for what seems to me, is a cultural or occupational perspective should be adhered to just because of an individuals momentary state of confusion?


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 speakers start using their native language's digit grouping and decimal symbols when writing in English. They should use the English scheme when writing in English.


The locale is the country and the language.

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


We told you that Esperanto is a better choice, but since you insisted for English to be world’s language, please let us write how we like. I’m not going to isolate me from the world of non-native writers in favour of English sirs’ better understanding of digits. Sorry for my tone if I got wrong feeling that your comment is arrogant.


> please let us write how we like.

I did not mean to tell you what language to use. You can write and converse in whatever language you please.

> I’m not going to isolate me from the world of non-native writers in favour of English sirs’ better understanding of digits.

It's not about which system is better, but it's about following the grammar and conventions of the language you are using. For example, would you knowingly use the wrong verb form in an English sentence just because it resembles the usage in your native language?

> Sorry for my tone if I got wrong feeling that your comment is arrogant.

I don't think it is possible for my tone to be arrogant in this regard since I myself am a non-native English speaker I meant no disrespect :)


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


What that map show is that space wins because otherwise someone is bound to be confused.


No, it's not possible to be confused if you are reading English. It's a comma for thousands and period for decimal. That is how it's done in English.

If someone wrote it in German or French and used the wrong decimal separator, then it's an error.


Logged in to my AliCloud account and saw a bill for 18.021 USD. Almost got a heart attack...


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.


Are you saying China and India don’t use dot as the decimal point?


I'm saying that the alleged comma users are actually mixing both dots and commas.

Western keyboards descended from an American layout that's missing the comma. It's common for comma users to use a dot instead, because they don't have a choice. Also, a lot of software will refuse the input even if they go out of their way to write a comma.

China and India have numerous languages with their own numeric representation. It's not really relevant. Don't think for a minute that there are any standard for the entire population.


Is it not called the decimal point elsewhere? What do you call your comma that separates the integer from the fraction?


I thought it was broadly the English-language format. AFAIK the comma is the thousands separator in the US, the UK, Australia and Canada.


I was actually taught the SI English style in school in Australia (i.e 1 108 512.33) but the comma style (i.e 1,108,512.33) seems to be a lot more common here in everyday use. I guess the SI version is mainly used in scientific publications?


I agree, also Australian and space is the right one to use. But we do use the comma too.


Five of the seven largest economies - including the three largest - use the decimal separator. Those countries have three billion people in them.

So which international customers are you talking about?


1,000,000 is easy to read, 1.000.000 too. It’s values like 1.350 that trip me up. Using a small space is not confusing to anybody.


I can only imagine. I already hate it when I see something like 1.375€. I can't imagine how infuriating it must be for you. However, I don't know how to half width space. Thoughts?


I've been using &thinsp; for my own blogs, but there are more options available, e.g. here: https://stackoverflow.com/a/8515417/539443


Generally, nobody will be confused if you use a full-width space.


>> Please avoid commas (or dots) as thousands separators.

You might as well say 'please ignore the standards of your country in favour of mine.'

Are you really not aware that this is the standard in Europe?


While it is an odd request, that's not really fair to the parent commenter. He's asking for a _neutral_ representation to be used, so that those used to both format find it easier to read. He even goes out of his way to specify that he doesn't want his format used.

It's the same reason I write dates YYYY-MM-DD, a habit I picked up after working in a large company with employees from all over the world. (Though I generally wouldn't request other people to use it as well)


Parent is clearly a European (or denizen of another local that uses commas as decimal markers), as they interpreted 4,604ms as slightly over 4ms. Also, they advise using an ISO (International Standards Organization) standard, specifically to avoid misinterpretation while remaining locale-independent.


I think the confusion is more about secondes vs ms. Like 4.604s parses easier in my brain.


No it isn't. Your parent comment was correct.


No, the request is "Please use a method people from all countries can understand". As OP said, the idea here is to use half-spaces as thousand separators. For the decimal separator, it doesn't matter much what you use. I'd guess the period because it is slightly more prevalent.

This method is clear to all users, rather than confusing all of mainland Europe.


IMO we should introduce locale-dependent number formatting to HTML.


Excel has it and it's a complete nightmare. Never know in advance what's the locale of the document and the excel.


It certainly doesn't help that it also make export as csv locale dependent :(


You can probably hack one together by styling a <input type="number">


I really appreciate commas a separators within numbers. One man's trash, I guess...


The problem is that many countries don't use the comma as thousands separator and rather use it as decimal separator. (And then the dot as thousands separator.)

So, "1,234,567.890" becomes "1.234.567,890".

If all you have is "7.890" or "7,890", you need to know what system the author uses.

What the guy proposes is always using spaces as thousands separators, independent of the system you're in.

So, then it would be written as "1 234 567.890" or as "1 234 567,890".

The spaces are almost universally understood and don't collide with other meanings.

It would still be possible for someone to be confused, if you're at the decimal separator and write your regional separator there, but it would cut out half the confusion.


All good points.

The proposal, however, does make the think about this: https://xkcd.com/927/, so I don't know if we'll ever come to a good solution :/.


Well, this new standard is backwards-compatible to the old standards, as in people will understand it, regardless of what they've learned beforehand. So, I don't think this new standard is really competing with the others.


No spaces is my preference.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: