Faster AMP on the Origin: AMP and SSR
blog.amp.dev
blog.amp.dev
Anyone fancy going through the AMP library and inspecting it for cruft?
I just don't get it. Maybe it works great in the Google News app, but nowhere else I've seen and I refuse to use Chrome on Android. With the lack of ad blocking the web is borderline unusable on a phone.
AMP’s main benefit has been making it harder to do expensive things. (Not impossible, by a long shot; merely harder.) And they’re deliberately planning to scuttle that benefit by allowing you to run your own scripts (see worker-dom). At that point, I believe that the only benefit of AMP will be how Google search treats it, rather than anything about actual performance.
And Google has communicated in multiple other ways that it thinks websites should be developed exclusively in AMP, a replacement of the open standard everyone agreed upon in HTML5.
I'm also curious how you explain link aggregators other than Google using AMP caches.
> And Google has communicated in multiple other ways that it thinks websites should be developed exclusively in AMP,
It doesn't support everything that full HTML supports, so this statement is obviously false.
> a replacement of the open standard everyone agreed upon in HTML5.
That's like saying RSS is a replacement for XML. It's a replacement for Apple News and Facebook Instant Articles, not for HTML5, which it is built on.
"In this special episode of Amplify, discover how to go "AMP First" and use AMP as your main development framework to significantly increase your productivity as developer. You'll also learn why "paired AMP" was never really meant to be an end state for AMP."
I take it you've admitted the rest of your mistakes as you have left them unanswered?
Its sole purpose is to enable safe prerendering. If you think it's supposed to make things hard, you don't understand it at all.
If option one makes prefetching possible and option two doesn't, why would a comparison with prefetching be unfair?
(Signed exchanges could in theory change this and allow safe cached serving and prefetching of arbitrary HTML pages, but the crowd that hates AMP seems to despise signed exchanges even more. Such is life.)
Incidentally, there was just a large scale study made on the performance characteristics of AMP in the real world.
https://blog.apnic.net/2019/08/08/amp-up-your-mobile-web-exp...
TL;DR is that the AMP pages from the origin were loading on average in 3.1 seconds compared to 7.7 seconds for the matching HTML. (Not all sites are as diligent as you about keeping their HTML light). And then pre-rendering sped that 3.1 seconds to 1.2 seconds. Though the bandwidth used for the prefetching was more than I would have expected.
Scripts forced on us by biggest Ad company are privacy-preserving? Was it sarcasm?
I sheepishly haven't even seen an AMP page yet because I rarely surf on mobile. But it seems like you'd click into an HN AMP page from google results which of course is cached unauthenticated. And then you'd have to click into the website proper if you want to up/downvote or write a comment.
"Features like service workers are touted as a solution to many problems in the web, but their ergonomics are so under-designed that people actually have to change domains to bust the cache from a broken build (I’m not making this up)."
Service Workers is drafted by 4 people. 3 of them are from Google. [2]
A lot of standardisation work on web standards is completely taken over by Google. A lot of discussions on JS and HTML are being handled by the same group of ten or so people who are in every open issue and every open proposal on GitHub.
A common thread is "oh yes, we should involve the wider web community that's why we reached out to Angular and Polymer for comments", which are, unsurprisingly, also Google projects. A recent proposal where I saw this happen is a proposal by Apple, Template Instantiation [3] Which is now almost entirely taken over by Google. See for example this issue: [4]. Three engineers from Google decided on the future of the project and chose only Angular and Polymer as the frameworks to talk to.
And you can see this everywhere.
[1] https://dev.to/dan_abramov/comment/6kh1
[2] https://w3c.github.io/ServiceWorker/
[3] https://github.com/w3c/webcomponents/blob/gh-pages/proposals...
Quote: “This spec (whose three editors are all Googlers) was shipped in Chromium and presented as a fait accompli despite objections.”
More at the link
That kind of thing will prevent rendering unless you wait for the timeout, which is 60 seconds I think, and then content will appear.
- Wait a few months until amp pages become as heavy, and then heavier than their html counterparts.
Amp is at best a hacky temporary patch, it doesnt solve the problem.
Creating a custom HTML fork that puts more pressure on limited publisher dev teams to end up with another copy o the site (and now SSR) is a worse approach than placing loading speed into search results ranking and letting sites optimize the site for everyone with a browser.
No, it doesn't. If it did, there would be no need for Facebook Instant Articles, Apple News, or their successor, AMP.
> Creating a custom HTML fork that puts more pressure on limited publisher dev teams to end up with another copy o the site
They're already doing this with Facebook Instant Articles and Apple News. Imagine if they had to do separate integrations with Bing, Google, Yahoo! Japan, Baidu, and any future link aggregators. AMP lets them publish one page and support all of them.
Facebook IA and Apple News are also attempts to control ads and data, just like AMP. They're all bad for publishers. IA and AN have both failed in providing anywhere near the benefits and revenue they promised. AMP only survives because it's compatible with existing ads served by Google's ad network and given higher placement in their search results.
It's rather amazing how Google is specifically offering the solution to a problem caused by their own adtech software.
You can't get faster than prerendered, which is what Apple News and Facebook Instant Articles offer, which AMP is the open alternative to.
> AMP only survives because it's compatible with existing ads served by Google's ad network and given higher placement in their search results.
If that's the case, why does Bing use it?
> It's rather amazing how Google is specifically offering the solution to a problem caused by their own adtech software.
What's rather amazing is that after having repeatedly heard the problem that AMP solves (instant loading pages), you continue to straw man what it solves and what technologies it competes with.
> Facebook IA and Apple News are also attempts to control ads and data, just like AMP. They're all bad for publishers.
Yet only AMP gets the rabid hate. Why is that? AMP is essentially RSS items with support for above the fold prerendering, interactivity, and monetization. You probably love RSS, even though it is even worse for publishers. Why?
You also seem to argue that because Facebook Instant Article and Apple News exist, AMP must also compete. I'm saying none of them are needed and creating yet another standard to push onto publishers because others have done it is poor justification. It's more work for no gain. Google already has vast control over UX by using search results, the very same search results it currently uses to pressure sites to implement AMP.
If Google wants to, it can force speed standards that change the majority of websites overnight. It can implement rules and restrictions in its adserver that change the majority of ads overnight. It can optimize Google analytics that change the majority of tracking overnight. It can do all of this if the intentions were pure, but it doesn't, because the only intentions are more control over publishers and data.
Facebook doesn't pressure IA and normal links work just fine. Apple News is new inventory and doesn't take away from Safari or the web. And RSS is completely irrelevant and nothing more than a feed of updates where pubs can share as much or as little as they want.
If that were true, Bing et al would not spend resources maintaining AMP caches. It's clearly not true.
> If AMP was so good then this entire SSR wouldn't even be necessary
This just shows that you don't know what AMP does. It allows prerendering from the link aggregator, and it does this well enough that every competent search engine implements it. The problem this solves is that people share AMP links directly, which can't be prerendered because they aren't loaded until someone puts the link in the location bar. In this case, it is slower than plain HTML, but this isn't the case AMP is meant to solve. By using SSR, they can make it faster than most plain HTML and just slightly slower than hand-optimized HTML with above the fold optimizations.
> You also seem to argue that because Facebook Instant Article and Apple News exist, AMP must also compete. I'm saying none of them are needed and creating yet another standard to push onto publishers because others have done it is poor justification.
The publishers use it, and as we demonstrated above with Bing's A/B testing, the users want it. What more justification do you need?
> If Google wants to, it can force speed standards that change the majority of websites overnight. It can implement rules and restrictions in its adserver that change the majority of ads overnight. It can optimize Google analytics that change the majority of tracking overnight.
Who says they don't? None of those solve the problem that AMP solves, which is instant loading of pages .
> Facebook doesn't pressure IA and normal links work just fine. Apple News is new inventory and doesn't take away from Safari or the web.
It's the same with the search engines and AMP.
> And RSS is completely irrelevant and nothing more than a feed of updates where pubs can share as much or as little as they want.
So what you're saying is that RSS is exactly like AMP, where pubs can share as much or as little as they want.
Google can influence site speed through SERP rankings, speed that is lacking primarily because of its other products, but instead it's forcing AMP pages. This is the fundamental problem that you are not acknowledging. There is no way around AMP if you don't want to lose ranking on an existing search results page.
FB doesn't treat IA ranking differently from links. RSS doesn't treat content differently. Apple News doesn't even support the web and can already accept RSS feeds. They also get plenty of critique that you're ignoring. Have you ever worked with a publisher?
> Users dont care about AMP, just fast sites.
Then why does every major search engine support it? They're trying to please their users, so they just need fast, not instant
> "Instant" is a marketing gimmick and makes no material difference when sites are fast enough.
Instant means actually instant, not just fast. Of course it makes a difference, or the search engines, Apple, and Facebook would not put in the resources to enable it.
Your current problem is that you're confusing your hatred for Google's search results ranking with AMP. If you don't like how Google ranks its results, just use a different search engine. Bing ranks differently and also uses AMP.
The only speed that search engines are responsible for is the results page. AMP has nothing to do with their user experience. And as stated several times, Bing joined for the same reason Google forces it, for more control over data by never leaving their domains.
And no, the ranking is not my problem. I don't know where you came up with that. The argument is that publishers lose ranking unless they use AMP and the same effective speed can be provided in much more neutral and friendly ways that doesn't require an extra copy of the site.
Anyways, it's clear that you're religiously defending AMP at this point with no acknowledgement of any of the arguments by myself or others on this page so I'll end it here.
The comments on this page are from people who don't understand what AMP does and have a blind hatred for anything produced by Google, as I have repeatedly demonstrated. If people actually didn't like AMP, Bing wouldn't spend the money to support it.
> And as stated several times, Bing joined for the same reason Google forces it, for more control over data by never leaving their domains.
Where has that been stated several times? This is the first time you have used "Bing" in any comment in this thread. If it were really the case that people prefer slower loading articles, it would be a competitive advantage for a search engine not to support AMP.
> And no, the ranking is not my problem. I don't know where you came up with that.
Let me refresh your memory:
"There is no way around AMP if you don't want to lose ranking on an existing search results page. FB doesn't treat IA ranking differently from links. RSS doesn't treat content differently."
Notice how you even confuse a publishing technology (RSS) with ranking.
> The argument is that publishers lose ranking unless they use AMP
Because users prefer fast loading results! If users preferred slower loading results, a competing search engine could rank non-AMP results higher than AMP results or not show AMP results at all to win users from the search engine that shows instant loading AMP results.
> with no acknowledgement of any of the arguments by myself or others
I've quoted your arguments and addressed each one. As I've shown above, you've pretended arguments were made that weren't, and now you're blaming me for not acknowledging these phantom arguments.
Bing cares about control like Google, that's why they also implemented it. I stated this, you quoted this, and yet you're changing the argument to be about slow sites for some reason. They are not related. Users can get fast sites as a secondary benefit of more control by search engines through AMP.
Nobody is confused about RSS, but you brought it up first and said AMP was the same. However using RSS does not give you higher placement. Are you disagreeing with that?
As for the rest, I'll try one last time: Users want fast sites, and nobody said they didn't, but Google can influence this speed through rankings without AMP. Rank sites by speed and you get the same outcome with sites that are fast enough. Instant is not necessary and doesn't nearly outweigh the extra cost of implementation and maintenance. This has been the argument this whole time, one that you haven't provided any rebuttal against.
I don't see anybody complaining about Bing's AMP usage, do you? Most of the commenters don't understand what AMP does, but they still hate it. You yourself didn't understand how AMP worked when we started this discussion, wondering why origin SSR was necessary when it is obvious to anyone who understands what AMP does, yet despite not understanding the problem AMP solves, you still hate it.
Google does some shady things, but contributing to AMP is not one of them. In fact, AMP is far less shady than its competing technologies that get far less attention on HN.
> However using RSS does not give you higher placement. Are you disagreeing with that?
What does that have to do with anything? Publishers implement RSS, which allows instant loading but gives even less control to publishers than AMP does, yet you are not complaining about RSS. As far as placement, implementing RSS gives them placement in news aggregators including Apple News. Forget about poor ranking — you can't get placement at all in these systems with just a plain HTML page and instead have to hand full control over to the aggregators.
> Google can influence this speed through rankings without AMP.
Who said they don't?
> Instant is not necessary
Says who? If instant weren't necessary, explain Apple News. They could have implemented it as links to existing web pages, but they instead make publishers give them a feed to ingest.
> This has been the argument this whole time, one that you haven't provided any rebuttal against.
I've repeatedly rebutted it by saying instant is necessary. You've been sticking your fingers in your ears and pretending it isn't. I strongly prefer to click on AMP links, and I can guarantee that most other users do as well, or why would the search engines bother labeling them with an icon?
If it were just about control, there is no reason to tell the user ahead of time that a particular link is to an AMP page. If it were just about control, what is the point of SSR on the origin and signed exchanges to make shared links not go to Google or Bing?
RSS is completely voluntary and used for inventory that is not serviced by websites. It has nothing to do with instant loading and can carry as little data as the pub wants. Apple News is Apple also wanting control, the same reason as FB-IA and AMP, and was also designed for offline use and device-local recommendations. Pubs willingly trade-off the loss of control for the extra reach but both FB-IA and AN support RSS feeds now because of pushback to use an existing syndication format.
You haven't actually provided as reason for why instant loading is necessary other than saying it exists and therefore it must be. That's not an argument, it's a tautology. If Google highly ranked sites loading under 1-second on the top half then you would get fast sites like HN. No AMP and yet here we are on instant loading website. Stackoverflow and dev.to are other examples, with no AMP required. Perhaps if publishers had both the incentive and didn't have to waste resources on AMP for SERP ranking, we could all be enjoying faster sites now.
You yourself provided a counterexample earlier in the thread. Here's another: https://news.ycombinator.com/item?id=20666920
These comments are highly upvoted, so the readers of the comments also don't understand AMP. If they haven't bothered to understand it but hate it anyway, that is clearly irrational, is it not?
> RSS is completely voluntary
Just like AMP.
> and used for inventory that is not serviced by websites.
Nonsense. RSS items almost always link back to plain web pages with the same content but with more publisher control.
> You haven't actually provided as reason for why instant loading is necessary other than saying it exists and therefore it must be.
I showed you an example of users preferring it. These results are clearly labeled, and users like me click them on purpose. If it was purely about control, they wouldn't be labeled.
As far as it being about control, you still haven't explained why Google ceded control to all other link aggregators just like RSS instead of following Apple's and Facebook's path.
This is also why AMP is not used for much other than news sites, and yet another reason why it's limited, wasteful and unnecessary.
Results in general shouldn't be written in AMP. The AMP documentation is very clear that it is meant for content pages and by attacking it for a problem it isn't meant to solve, you are engaging in strawmanning.
> This is also why AMP is not used for much other than news sites, and yet another reason why it's limited, wasteful and unnecessary.
It is far less wasteful than Apple News, FBIA, and RSS, which are limited to the same problem but solve it in a much worse way for the publisher. Once again, why aren't you complaining about them?
You mean those same publishers who now say that AMP is bullshit, doesn't deliver on any of the original promises and causes problems? https://digiday.com/media/google-amp-beat-facebook-instant-a...
> as we demonstrated above with Bing's A/B testing, the users want it.
Users want faster webpages. Thank you, Captain Obvious.
Continuing in the Captain Obvious role, how do you propose to replace FBIA, Apple News, RSS, and AMP with something that both users and publishers love? AMP is just as fast as the first three, and it provides more control to the publishers than the first three, yet you are not ranting about the first three. Why?
It's not an open alternative. All decisions on what AMP should look like and what it supports are done by Google behind closed doors. See, for example, AMP 4 Email [1]
The only reason AMP exists is because Google needed its own way to control content. That is it.
> If that's the case, why does Bing use it?
Because you're forced to compete against the behemoth on the behemoth's terms.
> What's rather amazing is that after having repeatedly heard the problem that AMP solves (instant loading pages)
AMP's problems are well documented. You chose to ignore all of them and go for "instant loading pages".
> Yet only AMP gets the rabid hate. Why is that?
Because it reaches a wider audience and Google has the gall to call it "open" and "good for the web". It's neither.
> AMP is essentially RSS items
It is not like RSS in any way, shape, or form.
Your examples predate https://www.google.com/amp/s/blog.amp.dev/2018/11/30/amp-pro... and no longer seem to apply.
> The only reason AMP exists is because Google needed its own way to control content.
That's nonsensical. Why then does Bing use it?
> Because you're forced to compete against the behemoth on the behemoth's terms.
Why are they forced to use it? I would really like to see your position stated coherently.
> AMP's problems are well documented.
How do you propose to achieve instant loading web pages, while working around all of iOS's bugs?
> It is not like RSS in any way, shape, or form.
This just demonstrates that you don't understand AMP, don't understand RSS, or don't understand both. AMP allows the link aggregator to cache and directly serve the article contents, exactly like RSS does.
Advisory Committee has no say in anything that AMP does. Everything is designed and specced inside Google (or Google-dominated work groups) and then vetted by the Technical Steering Committee. Advisory Committee's findings and advise is non-binding: https://github.com/ampproject/meta/pull/37 And all the WG's are assigned projects that have already been accepted into AMP (such as AMP 4 Email).
And yes, my example is important because it was a huge change that no one asked for, but now it's in AMP. As are all the other changes that already hurt the web.
> Why are they forced to use it? I would really like to see your position stated coherently.
Google has near monopoly on search. In order to compete with it you need to provide nearly all of the same features.
> How do you propose to achieve instant loading web pages, while working around all of iOS's bugs?
There are no bugs in iOS that preclude instant pages. And the bugs that AMP introduced are, well, the bugs that AMP introduced. AMP broke the behaviour on purpose and refused to implement any suggested fixes.
> This just demonstrates that you don't understand AMP, don't understand RSS, or don't understand both. AMP allows the link aggregator to cache and directly serve the article contents, exactly like RSS does.
I perfectly understand what AMP and RSS are. You don't understand what either one is. RSS was never about caching or link aggregators.
RSS is a web feed. That has a standard XML format and can be read by anyone: a client app on your phone, a client app on your desktop, a link aggregator that can be built by a half-decent engineer in about two evenings. Additionally, it is trivially discoverable by including a standard meta tag on a page.
Also, RSS always leads to the original URL.
AMP is not a feed. It's a collection of specially constructed HTML pages (which are not valid HTML5, by the way). They are not "instant". They are underperformant by Google's own standards (try running Google's own Lighthouse tools report against one from cold cache).
They are only "instant" when significant effort has been spent setting up an AMP cache so that some or all content is already on the client's browser before the client hits the AMP page.
They are not discoverable. A meta tag linking to an AMP version will only link one URL, that's it. There is no feed.
An AMP cache destroyes the very essence of the web: linking. You will not get the original URL, you will get the cache's URL.
Implementing an AMP cache is a significant endeavour, and only a handful exists (as far as I know, there are no opensource AMP caches).
Why did you focus on one irrelevant aspect of that document? The document also includes the Technical Steering Committee, a majority of whose members do not work for Google. That doesn't fit your narrative.
> In order to compete with it you need to provide nearly all of the same features.
In other words, users want it.
> There are no bugs in iOS that preclude instant pages.
iOS had broken iFrame scrolling for years. If you can implement safe instant loading while working around that iOS bug, let's hear it.
> RSS is a web feed.... There is no feed.
I was talking about items in the RSS feed as you quoted yourself in an earlier comment and then somehow forgot, but lets ignore this strawmanning and continue.
> That has a standard XML format and can be read by anyone: a client app on your phone, a client app on your desktop, a link aggregator that can be built by a half-decent engineer in about two evenings. Additionally, it is trivially discoverable by including a standard meta tag on a page.
So exactly the same as AMP.
> They are only "instant" when significant effort has been spent setting up an AMP cache so that some or all content is already on the client's browser before the client hits the AMP page.
Aside from effort, this is exactly the same as RSS. The additional effort is from doing things that RSS cannot do like monetization, interactivity, analytics, A/B testing, and above the fold optimizations. Cloudflare handles that effort fine.
> An AMP cache destroyes the very essence of the web: linking. You will not get the original URL, you will get the cache's URL.
Exactly the same as RSS. A link to an RSS reader is a link to the reader's URL, not the original URL.
Because that irrelevant part was the only one that would give AMP any semblance of being open.
> iOS had broken iFrame scrolling for years. If you can implement safe instant loading while working around that iOS bug, let's hear it.
I advise you learn something for yourself. Several fixes were provided to AMP but they were rejected without discussion.
> Exactly the same as RSS.
Let's see how AMP is "exactly the same as RSS":
- RSS is a feed, AMP is not
- RSS feed is discoverable via a meta tag, AMP pages are not (you have to search in a search engine, or have a cache of pages)
- RSS is a simple format that can be trivially parsed to retrieve data such as: author, publish date, url to original page, description, and content. AMP requires a near-full HTML parser with AMP-specific extensions: AMP is not valid HTML 5, AMP validator will allow some non-valid HTML5. Additionally, AMP relies on custom elements.
- Any and all RSS readers and aggregators link to the original website in a trivial and discoverable way. There's no url hijacking. AMP all but requires AMP Caches to be fast, and AMP Cache design all but requires to display content not at the original link, but at the Cache's URL. For several years the "open" AMP would deny this was a problem and pretended "it was an implementation detail that AMP is not concerned with" and "we will work with browsers on how to present the canonical URL". And even now the largest AMP cache regularly employs dark patterns to prevent users from visiting the canonical URL.
So yeah. I see how AMP is exactly like RSS.
No, that is the only part of the document when taken out of context that gives AMP any semblance of not being open. The TSC is what makes AMP open, and you ignored it and continue to ignore it after I explicitly called it out.
> Several fixes were provided to AMP but they were rejected without discussion.
Where?
> RSS is a feed, AMP is not
You need to work on your reading comprehension. That quote that you took out of context says that AMP is exactly like RSS on that particular point. I have repeatedly explicitly pointed out that AMP is like RSS items, not like RSS feeds.
Let me know when you're ready to continue the discussion in earnest instead of going to great distances to strawman every point.
It's a legit excuse, but not enough if a privacy leak in my opinion to slow down everyone's browsing substantially.
Wait, does this mean that websites could serve plain HTML but set this flag and this avoid being penalized by Google? Win!
https://www.google.com/xjs/_/js/k=xjs.av.en.1ic8JaUStX4.O/m=...
Ask yourself... Is that really the minimum amount of script needed to render a basic fast text and images only webpage? Notice the handcoded crypto functions? Notice the copious numbers of debugging functions and log messages and error messages? Notice the large numbers of copyright notices and complete license texts.
This stuff, if Google's dream comes to fruition, will be downloaded billions of times per day. For every byte of cruft in this file, an ethernet cable needs to be installed/upgraded somewhere.
We shouldn't let Google get away with such massive inefficiency in the name of efficiency.
I don't know much about javascript, but could someone explain what happens with the 20 that don't get caught? Do they bubble up and get caught by another "catch"? Or is this indicative of lots of "holes" in the code path?
Try blocks without a catch are a sign of any of these: poor coding, remnants from refactoring, features started and abandoned, possibly result of some build steps combining and optimising code.
async showImage() {
this.showLoadingSpinner = true
try {
this.imageData = await fetchImageData()
} finally {
this.showLoadingSpinner = false
}
}
Who's right? Is everyone else breaking copyright agreements?
I'm seeing an "expires" tag of "now", a cache-control header of 'private' and 'max-age' of 50 minutes. You'll also see the 105KB Javascript used to support animated gifs, 46KB amp-bind which allows documents to "add interactivity", and several others.
"Compiling HTML" would've been Star Trekian techo-babble a few years ago. And yet, here we are, where a straight-faced Google developer advocate is telling us to do just that. Should we laugh or should we cry?
The days of maintaining two versions of a website - a "mobile version" (in AMP) and the normal - are back again. Takes me back to the WAP days (not saying it's that bad). Then there are those that are going AMP-only - getting locked into AMP and all the excessive-yet-limited JS baggage (try building a full-fledged site and you will have a lot of AMP JS). JS compilation and execution isn't cheap on phones either. I sure as hell can make faster-rendering sites without that AMP bloat that can compete despite their prefetch.
This proprietary tech isn't helpful and is a massive dev resource sink. And let's not kid ourselves, there were many better ways for Google to prioritize and encourage speedy websites.
That's not the goal, though. Better tracking of your social graph is the goal of AMP. It's like alt.test to see how fast your link propagates, and where it goes. Useful information for influencing you and others.
But its all just javascript, html, and css. It is the open web. They're also taking bits, like Signed Exchanges, to the standards bodies to make then "standard web" as well.
Is there a term for creating something with two purposes? Where one seemingly benevolent purpose hides a malevolent one?
I mean many of their actions, on the surface, could be euphemistically called "helping humanity" when in reality they're only helping Google.
Penalizing non-https sites: "we're making the web more secure" - and lock out advertisement surface to the benefit of our ads quasi-monopoly (admittedly, a weak case though)
Android Stagefreight bug: "we're disabling MMS to protect Android users" - and by the way close a channel for easy publishing with carrier billing that is part of the highly regulated 3G/4G stack
HTML5: "we're advancing the web and make it fully portable" - and also capture HTML standardization and make it so overcomplicated and never-ending that even MS (and long-time pioneer Opera) are forced-out of producing web browsers alltogether
User -> Internet -> Website
Into
User -> Google -> Internet -> Google -> Website
So that they can sell more ads.
Received 150+ Billion searches
Solved 48.96% of those searches without a click
Sent 6.01% of all searches (~12% of search clicks) to websites owned by Alphabet, Google’s parent company
Directed a click to non-Alphabet-owned websites (aka, the rest of the web) after 45.03% queries
https://sparktoro.com/blog/how-much-of-googles-search-traffi...
" AMP SSR is for everyone
If you publish AMP pages, you should publish server-side-rendered AMP pages. Similar to minifying your HTML or CSS, running AMP Optimizer or the Go transformers should be a normal part of your build / rendering chain. The improved rendering performance makes a big difference in FCP times, but more importantly, in the user experience.
" Other than being the most heavy handed, imperative/authoritarian style call to arms I've seen, the part of this that really bakes my cake is "makes a big difference... in the user experience." Ya know what makes the experience of visiting my website great for a user? When they actually visit MY website. It's like, the single most fundamental part of a website visiting experience. When their browser and my server host kanoodle around in cyber space together, instead of having some creepy cuckold experience involving Google's server. So I'm thinking that AMP, and all derivative technologies, should really make like 'Google Health' and retire to the trash bin.